the matt milner

Exploring the Programming Universe

3…2…1…Blast Off!

Hello everyone, I’m Matt Milner.  Yes, the Matt Milner- programmer, golfer, and aspiring iOS Developer. For starters, I’d like to tell you a little bit about myself. I am from Houston, Texas (more specifically Katy, Texas), I have two dogs named Samson and Maggie, and I am a developer-in-training for iOS apps. In my spare time, I enjoy hitting the golf course as much as humanly possible. Interesting fact about me: I played on the practice team (with other guys) of the Texas A&M Women’s basketball team for a year while attending Texas A&M. My favorite shows include The Office, It’s Always Sunny in Philadelphia, Family Guy, and Silicon Valley. As far as my programming background goes… I first became sincerely interested in programming around a year ago when I was assigned the project of renovating my company’s outdated website into something a little more modern with the help of a friend who had a significant programming background. Prior to this, I had minimal experience writing HTML and CSS for a website I created in my junior high days and from eBay postings I created using HTML. Currently, and for the past 6 months or so, I have been learning the core concepts of programming. Originally, I started by learning Python, but then I switched over to Ruby in hopes of landing a career as a backend developer. My tastes have changed since then, however, and I now am fully immersed into a programming bootcamp (called The Iron Yard) where we are learning iOS development using Objective-C and Swift. Although I didn’t have any prior experience with Objective-C, I am finding it to be pretty quick to pick up since I have more or less (but probably less) mastered the universal basic fundamentals of computer languages.

Anyway, the purpose of this blog is to keep the world on top of my journey from being a beginning programmer to hopefully creating the next big thing on the app store. In the future, these articles will be mostly related to the current topics I am covering in my iOS course and beyond. Thanks for your time, and I encourage my readers to check back weekly, as I plan on writing a new article each week! Until next time.

Featured post

Web Services, MapKit and CloudKit

The last week has yet again been filled with tons of new material. On Monday and Tuesday, we covered the concepts of web services and APIs. These are extremely useful for getting real time data and can even save developers from having to release updates on a regular basis. For the next couple of days after that, we covered the use of MapKit and CloudKit. MapKit is exactly what it sounds like- implementing Apple’s maps and map functionality into your own app. We did several different things with the maps and even used them to create an app that allows the user to report and view current local flooding on streets to alert other users of the app. The saved flood locations in this app utilized CloudKit to save and document the locations of the flooded areas. (More to come on this later)

Back to the first topic: web services and APIs. Web services are basically just sets of useful data, usually put into some kind of format (such as JSON) that a program or application can download and parse in order to do things with that data. Parsing is where the application can break apart the data into useful objects and assign values to variables or objects that use that data. For example, the image below contains JSON data that is downloaded and put into separate objects in a Thermostat application I created in the early weeks of this course.

Screen Shot 2016-07-31 at 9.47.22 PM

The data above is downloaded by the program and then split apart and saved into different variables I had previously defined in the program. For example, I would save the current temperature (found under the “temp” tag) into a temperature variable, which would then be set to (in this case) 301.69 Kelvin. I then converted that temperature to fahrenheit and displayed the result in the text of a UILabel. The advantage of using this data is that it is constantly updated on the web server, so anytime it changes on the server it will also change on the app. This can be extremely beneficial if the developer wants to add a category or additional information to his or her already-published application. If I had created a similar weather app that displayed data in a table by the city, all I would have to do if I wanted to add an additional city would be to add that city to my web service. Then, once the app is run again it will already automatically be added to the list (provided that the list is generated using web service data). This saves programmers valuable time and effort having to prep their entire application for another version release.

The next few days were all about MapKit and CloudKit. These two frameworks are crucial with the amount of map-usage by the average user today. With the MapKit framework, the developer has access to the maps interface and can add anything they want to it in order to make it function as desired. As an assignment for MapKit we were instructed to create an app that displays an icon that indicates that a particular area has high water on the road and to avoid it. In order to do this, we had to set up the map to start on the user’s current location. Whenever the user shakes their device, they add an icon to the map that indicates that that area is flooded. Of course, people sometimes inadvertently shake their device, or flooded areas may have subsided, so there is also an option to delete a pin. Once a user adds a pin to the map, it is saved onto the cloud using CloudKit and updates onto the map for others to see. This app is an awesome example of the simplicity of using CloudKit and the kind of impact it can have on a social apps with lots of users. An app that was this simple to design can literally save lives- that’s really cool! See the screenshot below to see it in action, and thanks for reading!

Simulator Screen Shot Jul 31, 2016, 4.14.42 PM

CoreData and SQL

During the past two weeks, we’ve been covering the concepts associated with storing and recalling data. Similar to the concepts covered about a month ago with NSUserDefaults, database management is all about finding the most efficient ways to 1) store the data, 2) set up the structure of the database, 3) establish relationships between data, and 4) recalling the data. The complexity of these tasks has increased with the introduction of CoreData and SQLite, but the use of these two concepts allows the user to store much more data than they otherwise would be able to using just the NSUserDefaults approach.

The first thing we learned pertaining to CoreData was basic SQL. Although we only learned four commands (SELECT, INSERT, UPDATE, DELETE, and CREATE), we were given enough understanding of these commands to build a foundation. Additionally, we were able to create functioning databases that could store, recall, and update actual data stored in the app’s datasource. Here is an explanation of the basic SQL commands we learned:

SELECT: allows the selection of a piece of data

INSERT: adds new data to the database

UPDATE: updates a particular row of data

DELETE: deletes a piece of data from the database

CREATE: creates a new piece of data in the database

That’s it! Pretty simple when you think about it. With no prior knowledge of SQL, or even how databases work in general, I can create you a new database and modify and update the data within it and even create new data. Although this is pretty simple, setting it up to work in an app is extremely complex- and is a task that is still a bit murky for me so bear with me here.

There are 5 basic components of setting up a SQL (or other type) of database on an iOS application. All but one of these, fortunately, is set up only once in the app’s “app delegate” file. This makes the whole process a little easier, but setting all of this stuff up takes a lot of tedious programming and attention to detail. The different components are as follows: The data model, the managed object model, the managed object context, the persistent store coordinator, and the persistent store itself (the data’s final location). All of these components work together to execute the same 5 commands I mentioned earlier. Of these 5, the only one that is carried throughout the app is the managed object context. This is responsible for talking to the persistent store coordinator to access the data. See the chart below.


Although it gets a bit more complicated than that, these are the basics that have to be implemented to create a functioning database that the app can access to remember the user’s information- and this information can be literally anything. The user can save grocery lists, personal information, passwords- anything! As the developer, I can also save the user’s preferences, preferred color scheme, frequently visited locations or whatever else I can think of that needs saving. Although I still don’t completely understand the proper implementation of databases, I do understand their importance and relevance in data access and storage.

A Swift Transition

It has been a couple of weeks since my last post, but do not be mistaken: I have learned what feels like a lifetime of new material in that time. There have been so many topics covered in the mean time- including frameworks, autolayouts, the introduction of Swift, core motion, and core camera. Let’s jump right in.

Shortly after we covered NSUserDefaults, we jumped into the topic of frameworks. Frameworks are packages of code that are compiled together for future use. In our frameworks project, we were assigned the task of creating our own custom framework of a previous StepperView project we had done a few weeks before. The goal of frameworks is to allow the developer to quickly and efficiently use another developer’s (or their own) code in an easier way than having to create the components of the framework all from scratch. In the context of our assignment, we imported a custom stepper control and implemented it within our new project using only the framework that we had imported. See the example below.


After getting comfortable with frameworks, we moved on to how to set up basic autolayout constraints and settings. These can be pretty confusing, but the basic idea of this topic is finding the most efficient way to make the different views in the storyboard space apart properly, keep their aspect ratio, or constrain to margins, or some kind of large combination of the three. It often takes a lot of trial and error to find the perfect constraints- and sometimes when you think you’ve found them, they crumble when you run the app on a different device. The best practice I can recommend for this topic is to simply have patience and to keep trying different approaches until you find success.

The next topic- nay, language we started was Swift. Swift was created very recently- about two years ago, and is much more dynamic and easier to use than Objective-C. According to my instructor, many people who begin learning to program apps in Objective-C give up quickly and quit because of the complexity of the language (something I’m glad I didn’t know before I started the course!). A cool thing about Swift is that it is very strict. This sounds like bad thing, but it is in fact a great feature. It will not allow you (the developer) to execute your application without first making sure that every variable and method is valid and used properly. This saves a lot of time when creating new objects and firing methods on those objects. Another cool feature of Swift is the ability to use a file called a playground. A Swift playground is basically a live console where you can fool around with different bits of Swift code to see what results you will get with a live preview- saving you from having to build and run the application over and over again. I enjoy learning Swift, but like any new language, it comes with some challenges and unfamiliar concepts that need to be hammered-in before you are able to move on to the next topic. Luckily, we’ll be working on Swift for the remainder of the course so I’ll have plenty of time to hammer these concepts in.

Core Motion and Core Camera were the last two topics we covered during this week. These are frameworks that give the developer access to the iPhone’s health and fitness data (using CMPedometer), the iPhone’s gyroscope data (including the device’s orientation, bearing, direction, and even its proximity to the earth’s magnetic field!), the camera, the camera roll, and more. These are extremely useful for location-based applications and augmented (and virtual) reality. As a test of our knowledge of these concepts, we created a text-based application that the user could scroll though simply by tilting their device forward or backward. This was done by using the iPhone’s gravity readings from CoreMotion and then making the text scroll up if the value exceeded a certain up-range, and scroll down if the value exceeded the down-range. In the future, I can see myself creating an app that a user can point at the sky and see where a planet is at the current time; therefore I would need to use CoreMotion to be able to accomplish this along with some implementation using the user’s location data. When we learned about CoreCamera, we designed an app that displayed a stock image that the user clicks to either select an image from their phone’s library or take a new photo. Once the photo was selected, it was displayed on the screen and also had the option to apply certain filters. Once the user was finished selecting their desired filter, they could then press the save button to save this image to their photo library. Although this was a pretty simple app, there were a few moving parts to figure out before being able to fine-tune it into a functioning, memory-efficient application.

Next time, I’ll cover some slightly confusing new concepts we’ve been learning pertaining to database management. We are currently learning basic SQLite and how to set up and store data into custom-made tables. This is pretty complicated stuff for me so far, but I’m starting to grasp it and see what’s actually going on behind the scenes. But for now, thanks for reading and see you next time!



In Another World

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.


Week 1 Summary

Last Friday (June 17th, 2016) marked the end of the first week of my iOS Mobile Engineering course. Not having had a background in this before, I was very worried coming in and didn’t know what to expect. After a day or two, I started to begin to feel comfortable with the material. Don’t get me wrong though- everything I was learning during this first week was foreign and scary to me. After a little bit of digestion, this material started making sense once I could see how it related to other languages. I was very grateful that I had previous experience in programming because these new, seemingly difficult concepts we were covering turned out to be completely relatable to the programming fundamentals I had picked up during my time with Python and Ruby.

For those of you who have no idea about iOS development: I am not that far ahead of you so I feel like these posts will be tailored to both people who don’t have a background in programming whatsoever and experienced developers alike. This reminds me of a story a friend told me one time. When he was about 2 years old (before he could talk) his older brother, who was 4 at the time, was able to communicate to their mother on my friend’s behalf- sort of like a translator from “baby-speak” (?) to actual English. He was able to tell their mother why my friend was crying, what he needed, and how to console him.  Who knows if this was real or not, but for the sake of the story consider me your “baby-speak” translator for now.

Let’s get to the actual iOS material now. So, on day one, we did not do what you typically would do at a first day of school. No syllabus, no getting out early, and unfortunately no recess. Nope, day one was all about learning new material. We started out by covering the basics of Github and Xcode. Then we moved on to the specifics of Xcode, and we’ve been branching off of that point every day since.

We started by creating a single-view application (an iPhone app with only one page- no links or tabs or anything), where we were using the ViewController and storyboard to visually place buttons and labels on the page. These tools are absolutely awesome! You can literally drag-and-drop any kind of UI element onto the screen and see exactly what you will see whenever you run the app. This part was pretty easy. Moving on to Outlets and Actions was a little tougher though. Outlets are what are used to connect UI elements to the View Controller, which allows them to interact with the user, send data to other parts of the application, and link UI elements to methods so that something will happen whenever you press a button or click a tab. I didn’t understand much about how it worked at first- and I just typed the same code my instructor was typing on the projector. This turned out to be a good thing though because when I went home and had a little bit of time to sort it out mentally, it all started to come together. I’ve noticed this pattern regularly once I started taking this iOS course. Everything is new and scary at first, but if I take the time to actually sit down and reiterate through the material, making sure I understand what it is accomplishing, I tend to be prepared and ready to tackle the next day’s work (given I can repeat this cycle over again).

The next couple of days were somewhat easy for me, as we covered those universal programming concepts I’ve been talking about this whole time. This material included data types, classes, methods, and some more Xcode basics like how the ViewController works, etc. Not necessarily easy material, but my background and willingness to learn helped me sail along smoothly. The coolest part of this week was getting to build a simple Calculator app that took in two numbers (inputted by the user), waited for the user to click a button indicating the operation to be done, and then displayed the result in the center of the screen. Later, we refactored this project to be done using classes, which for me was something new. After some study and documentation-consulting, I was able to figure it out- a huge milestone in my programming career. I knew what classes were and what they did previously, but I had never actually applied them (in this context) to anything I had created in the past. Once the calculator was complete, I felt a small sense of accomplishment since it was the first actual app I had ever created and it worked (see the screenshot below). Anyway, I’ve dragged on a bit, so thanks for reading and I will see you next time!



Create a free website or blog at

Up ↑