Last week, we completed our first projects for Advanced Mobile App Development. I decided to create a 14ers checklist app that allows users to keep track of which of Colorado’s 14ers they’ve climbed. In addition to recording how many times they have climbed each peak, users can also write down notes about their climbs and view how many peaks they’ve climbed in each of Colorado’s mountain ranges.
What went well?
First of all, I was definitely excited about my concept. I personally love to hike and climb Colorado’s 14ers, and the inspiration for the app came from a website called 14ers.com, where users can maintain lists of peaks they’ve climbed. Being passionate about the topic and trying to develop an app that I could see myself using helped the development process be more fun and exciting.
Moreover, all of the data that I needed about each peak (hiking class, rank, elevation, name) was readily available on the 14ers.com website. It took some time to add all of this data into a property list (see more on this below), but at least I knew exactly where to find the information I needed for my app.
I also had lots of reference material from class to go off of when it came time to set up my table views, which was very helpful. Having all of these examples to reference gave my app a solid foundation in terms of functionality that I could build from.
What did not go quite as well?
Unfortunately, I had some problems with figuring out how to send data and updates between screens, especially when I was trying to trigger a data update from a table view deep in the navigation hierarchy. For one of these issues, it turned out that I was creating a new “Mountain” object for my data model but just forgetting to actually use it to update the data model. It is always the silliest mistakes that cost the most time! 🙂
Putting all of the data into a property list by hand also proved to be very time-consuming, especially since I had to find a photo for each mountain and fill out several fields of information (imageName, rank, peakClass, elevation, notes, ticks, name) each time. I underestimated how long this part of the process would take me, but eventually I got everything into my property list!
Last, I struggled with autolayout for way longer than I should have. I forgot to test my landscape orientation early on, and ended up trying to retroactively put everything into a scroll view. For some reason, I couldn’t get this to work! I ended up varying for traits to create a different layout for my landscape views, but I would love to jump back in sometime and try to get the scrollview working because I think I must have been close!
What would you do differently next time?
The biggest thing I would do differently next time is to just find some sort of API for loading all of the peak data into my app. I looked very briefly for a 14ers API when I started this project and didn’t find anything, but it’s very possible that there is one out there. Using an API instead of putting all of my data into a plist by hand would have saved a lot of time!
Secondly, I think that testing in smaller chunks and shorter intervals would have saved me time in the long run. I think I had so much momentum going into this project that I wanted to jump right into developing and getting large parts of the app working, but this definitely slowed me down in the debug/testing phase. Next time, I will be sure to test each component individually and test more frequently in general.
nate bennett 