This is the first part of a blog series that details how to develop a mobile application that is backed by MongoDB and a PaaS. MongoDB makes a great companion to this mobile application given its ability to shard and the nature of being able to store JSON documents with little data manipulation required. In this blog post, part one of the series, we will go over the background of the application and discuss the features we are going to build.
I started developing iOS based applications shortly after the arrival of the iPhone on the market. Having been a Java and PHP developer for my entire career, switching to objective-c was a tough challenge for me. I had to remember basic programming methodologies and patterns that I haven’t used since college. I had to remember that when using the C programming language, that garbage collection doesn’t happen automagically. You have to allocate your memory and then when you are done, free that memory up. I also had to learn a new IDE (XCode) to take advantage of the profiling tools and other features that is required when doing native iOS development. XCode has improved significantly over the years, but in my opinion, it’s still a far cry from what I expect from an IDE.
To write my first iOS application, it required nearly two months of work at the cadence of 30-40 hours per week. To my delight, after releasing the application, the market for the application was larger that I had anticipated. Users were writing great reviews and requesting more features.
Shortly after releasing my first iOS based application, Google decided to enter the smartphone market with their android based sdk and devices. This should have been great news for most software developers but for me, a part time mobile developer, it wasn’t. I now had users requesting my application for android devices as well as for the new iPad and other tablets that were hitting the market. I didn’t have the free time to port my application to the android sdk as it would have required another two months of software development as well as maintaining two separate code streams for patches and updates.
At OpenShift, we enjoy local craft beers and the social aspects of having a pint while discussing the latest trends in software development and deployment. One night, over a pint, we thought it would be cool if we could quickly read a description of the beer and brewery before ordering. We kept discussing the app and of course feature creep started setting in. Before we ended the night, we decided to develop a mobile-based application that would allow a user to search for beers, and then log when and where they drank it. Because the team was split between using iOS and Android based phones, we needed it to work on both devices and sync the information via a backend service. Of course, all of this had to be available via the web as well.
Want a quick preview of what we will be building? Check out the video showing the application.
BeerShift has a tabbed based UI that consists for 4 main screens. Drink, Drank, Kegstand, and Settings.
The settings tab presents the user with username and password input fields. If the username does not exist in the MongoDB database, the user will be prompted if they want to create a new user.
The drink tab is the heart of the application. This tab allows the uses to enter in a beer name and will return a result of all beers and breweries that match the search string. The results are retrieved via a REST API call to the openshift server and presented to the user in a table view. The user can select a a beer from the list and then select to “Drink It”.
Once the user has decided to log drinking a beer, the drinking event will be recorded on both the drank tab and the keg stand tab.
The keg stand tab will allow the user of the application to view the 50 most recent beers drank by any user of the application.
In the next blog post of this series, I will detail the installation of applications and tools needed to begin with development of the BeerShift application.