This Friday marked the end of week 3 of my Mobile Engineering course at The Iron Yard, and I must say it has been a tough one. On Monday, we covered basic animation and gesture-recognition: very important concepts in the world of touch screen devices and apps. An interesting thing about gesture-recognition is the fact that as the developer, there is very little coding required on my side to actually detect the user’s movement. Instead, Apple’s UIKit framework is already equipped to detect such events.
For example, while creating a basic pong game app, I added some UISwipeGestureRecognizers into my code that were used to fire a method that made the user’s paddle move to the left upon swiping left, and vice verse upon a right-swipe. Without these UISwipeGestureRecognizers, developers would have to use other (often unreliable) tools such as touchesBegan and touchesEnded and then calculate where on the screen the touch began and ended, and finally calculate what kind of swipe or tap the user undertook. Needless to say, that is very difficult and time consuming so I am grateful that the UIKit framework is available. This material, albeit unfamiliar, was pretty simple and easy to understand. The next day, however, was a different story.
Tuesday was where it started getting messy. Up until then, our daily assignments and labs were all single-page applications that did one single task and that was the end of it. Now, we were diving head first into actual multi-page, complex apps with a lot of features. We started off the day covering how to set up ViewControllers on the Xcode storyboard. Looking back now, I literally had no idea what the significance of all of these items was when I first started; I just used them so my assignments were complete on time. No longer was I allowed to disregard the importance of these items. They are the heart and soul of what makes applications run.
After a brief lecture on how to set up multi-page applications, it was our turn. This assignment, a grocery list manager, was the first true test of applying several day’s worth of lectures and foreign concepts into a functional, realistic application (that there are probably already hundreds of on the app store). The assignment was to allow the user to create a new grocery list with a name of their choice. Then, once the list has been created, the user can select that list (which was displayed onto a table- similar to the first page of the settings app if you use an iPhone) and add grocery items onto it. I know it sounds simple, but you give it a try. It was not simple at all. But, after three days, two intentionally-deleted Xcode project files that I felt like I had messed up too badly to fix, and one disastrous accidental storyboard deletion, I was finally able to get a functioning prototype that did the job. See the end of this post for a preview.
The major lessons I learned while completing this project were about the concepts of segues (pronounced “seg-ways”), view controller management, classes, and perhaps most importantly, protocols and delegates. A segue (at least in the application-development context) is a how you navigate to another view controller within an app. In English- another screen comes up on your phone when you press something. It often is used to declare an instance of another view controller and set that new view controller to be a delegate (code used that is capable of sending information) of the one performing the segue method. Protocols, on the other hand, are used like an iron-clad, rock solid contract that cannot be unbroken between two (or more) different views. These are used in iOS development to be able to send data from one screen to another. Whenever I declare that one of my classes goes by a particular protocol, I’m really saying that I need any other classes who use this protocol to be able to handle some data that I’m going to send them eventually, so they need to have the appropriate methods implemented to be able to receive this data. I cannot express enough how important I can see these becoming in my future apps. Every time you play angry birds or something on your phone, the app is using delegates and protocols in many, many ways to be able to save your score, generate the next level, etc., so be thankful for them.
The next step in finishing this grocery list app will be for me to let the user save their lists- perhaps the only reason you would make a list in the first place. All sarcasm aside, being able to save data is probably the most fundamental and most important part of software, but it is a new (and pretty challenging) concept I haven’t had time to fool around with yet. Up until now, every time we have created an application, it will forget everything the user has done in it after it has been killed (aka. double-tapping the home button and swiping the app up). To fix this, I am going to implement a concept known as NSUserDefaults. The NSUserDefaults class is used for storing data and interacting with the iPhone’s central database. Every app, regardless of its type, is saved in this database after being serialized, or transferred into a kind of text document readable by the operating system. I’m sure that I’ll be extending on this topic in the future without a doubt, but for now, see you next time.