Day 5 – Tuesday
Tuesday was spent covering topics such as text input, using table views, and controlling app navigation. If using XCode’s interface builder to construct views, it becomes very trivial to configure a keyboard based on its reason for being on the screen. From the interface builder, you can configure the keyboard to be numeric only, control autocorrect and autocapitalization, and choose context specific keyboards (e.g., an email keyboard) to better enhance user experience. For example, if the user is to enter a number, you can present them with a keyboard that only allows them to input numbers.
For the sample app we were building, we used table views to display lists of items on the screen. I felt that table view was a bit of a misnomer because unlike HTML tables, iOS’s table views only have one column. They are quite easy to use, however. iOS development relies heavily on the delegate pattern. Much like implementing an interface in other languages, in order to interact with much of Objective C’s built-in features, you implement the methods needed for a given component to get the data it needs or to handle the events it generates. For table views, you implement a data provider delegate in order to supply the data for each of the rows in a given table view.
If you’ve ever used an iPhone’s Settings app, it makes heavy use of the UINavigationController. A navigation controller allows a user to “drill down” a series of menus and provides the “back” button at the top of the app to traverse back up the navigation hierarchy. At the end of the day we learned how to interact with an iOS device’s built-in camera. In this lab, we added a button to our app that allowed the user to take a picture, and then that picture was added to a UIImageView inside our app.
Day 6 – Wednesday
Wednesday was a fun day for different reasons than just learning new iOS features (which I’ll talk about shortly). There was a two-hour block of time in the afternoon set aside for those who wanted to go on the zip lines. HBM has over 90 zip lines available for use at their facility. We had the opportunity to do the stage 2 and 3 level zip lines. Over the course of the two hours, we did six different zip lines, the fastest of which had us moving at speeds of about 50-55 MPH according to the guides. We had a really good time. Thankfully the high that day was a whopping 45 degrees (a heat wave compared to the previous few days), so for those of us who went, we had a blast.
On this day, we went down the rabbit hole of using XCode and iOS’s auto layout features. One of the more challenging aspects of learning iOS code is how to build your app in such a way that everything looks right on an iPad or iPhone regardless if it’s in portrait or landscape mode. For many views in an iOS application, you build one view and use auto layout to configure how it looks in landscape mode or on a bigger screen. Much of the time is spent designing the view in portrait mode for an iPhone and then configuring it to look right in other sizes/orientations. It is possible to have code that allows you to use different views based on device or orientation but this can potentially become a maintenance headache. Image you want to add a new button that controls some new feature you’re adding to your app. The more your app’s code diverges based on device/orientation, the more places you have to add/support the new button. When possible, it’s best to use one view and use different constraints to support other devices/orientations.
We also learned the first of the two most common ways to store persistent data for an iOS app: archiving. Unlike a traditional operating system, iOS apps only have access to a dedicated location on a device’s file system. iOS gives apps access to the folders: Documents, Caches, Preferences, and tmp. iTunes backs up data stored in the Documents and Preferences folders. Anything in the Caches or tmp folders do not get backed up and can be purged by the operating system at any time (as long as the app isn’t running). If it is a normal file (e.g., an mp3 downloaded from the Internet), you can save the file straight to disk. If you need to persist data generated in memory, most commonly you implement the NSCoding interface on whatever class you wish to encode/decode.
Day 7 – Thursday
The first thing we learned about on Thursday was the second of the two most popular ways to persist data in an app: Core Data. Archiving is good for persisting fewer than 1000 objects. The problem with archiving is that the whole file must be read/written at a time instead of being able to append/modify objects one at a time. Core Data can turn Objective C objects into data that is stored in a SQLite database file. This allows developers to work with subsets of much larger datasets.
iOS allows developers to use web services to access/send JSON data to a web server. Unfortunately, the serializer used by iOS can only work with arrays, dictionaries, strings, and numbers. This means you can’t go directly from JSON to an Objective C class if the class contains properties such as dates. A developer must deserialize JSON into a class that only has string and number properties and then map that class to a class with more types of properties.
The last major topic discussed on Thursday was the UIGestureRecognizer. While it is possible to handle touches, touch movement, etc. manually, the UIGestureRecognizer gives developers the ability to easily recognize common gestures such as tap, flick, pinch zoom, finger rotate, etc.
Day 8 – Friday
Friday was the last day of training. We only had a half days’ worth of material. Most of this day was spent covering how to use XCode as a debugger and all of the profiling features it offers. The debugger is quite easy to use. One of the best features of using XCode is that it is able to give performance statistics (CPU/memory usage) on whatever device you’re running your code on. If you’re running the simulator all the numbers are in relation to what CPU your Mac is running and how much RAM you have. The nice thing is the same holds true for running the device on you iPhone while tethered to your Mac. You can use your own device to run your code and XCode will gather all the performance numbers for whatever device you have. This can be very handy when testing your app, not only on different size devices, but also different versions (iPhone 4, 4S, 5, 5S, etc.)…assuming you have all of these devices lying around somewhere.
After lunch, we all said our goodbyes to each other. There were a lot of friendly people I chatted with over the week, and I met a lot of very smart people. One of the best resources you get once attending a BNR training seminar is access to their user forums. They encourage students to stay in touch and use the forum to work through challenging tasks together. The instructors also remain available as valuable resources for any future roadblocks one might encounter during iOS development.
If you ever have the chance to do a BNR training session, I highly recommend it. Sure there may be a few topics that aren’t relevant to whatever purpose you’re going for (which is true for any broad topic training sessions), but it really helps overcome the initial hurdle of learning how to develop applications for complex frameworks. iOS development is unique and complex but can become very manageable given an opportunity like mine.