Technical Challenges of Building an iOS App in a Short Period of Time
My team and I were given an existing project and a goal. That goal involved a lot of moving parts and a deadline that was not too far off. We quickly met as a group once we had the project in our hands and some time to talk.
The First Challenge
What does this code even do? We were given a strange starting point to say the least. At first glance, we weren’t see what the source code accomplished or where we were going to begin our refactoring. Then I reminded myself — professional development involves a lot of iteration. You aren’t always given a clean slate to build on. We were handed a non-functional mess. The folders weren’t organized, random files were in the main project directory, and so on. I told myself that this was just part of the process and got to work.
The Second Challenge
Map annotations. They’re incredibly important for any app that uses a map — especially if it’s the focus of the app. This seemed like a fairly trivial thing for us to implement, but we soon hit our first roadblock. We decided to use a tab bar controller to make navigation quick and simple. However, none of us necessarily had experience with dependency injection while using tab bar controllers. It wasn’t as simple as ctrl + dragging a segue in storyboard. To go from an annotation tap to a detail view required us to get creative and do some research. Here was our solution:
We built out the mapView(didSelect) function to segue information manually. This was perfect for us because the only time we wanted to actually segue data was when the user tapped an annotation.
The Third Challenge
We needed to display a city properly in our detail view controller. However, we didn’t have a model — or a detail view controller. I tackled this problem while I helped solve our information segue issue. Everything seemed simple until I realized that we didn’t have any data. Being a cross functional project meant that achieving some of our goals was dependent on other members of the team achieving their goals. I didn’t know what the data model would look like and neither did those responsible for making it. I went with something pretty basic:
This left us room to easily expand if we needed to. We know we had a city name and we know we had a walkability score. If we refer to the previous code block, you will see that I’m hard-coding our walkability score in the segue. This was a temporary solution until we received actual data from the data science team. Implementing the mock data was fairly simple as well; first, I wrote a function that changed the label color depending on the walk score value:
I then updated our city’s name (name and state) with the data passed in from the map annotation:
We eventually added support for crime rate, a livability index, and more, but we did not get our actual data from data science until two hours from our deadline. In hindsight, we should’ve anticipated something like this and just had more mock data.
Looking Back
Numerous problems arose during our time creating this app. However, we were always able to derive a solution and implement it. We even used third-party APIs to source mock data from while we waited for our own data. I’m even more confident now that there’s not a problem that can’t be solved when you have multiple people discussing it.
