Its been a little more than a couple of months now since I last blogged. That post was about the release of the Yardistry design tool. This post is about the release of an iphone app + microblog site that I just finished work on. I regret not having taken the time to post regularly during this project because we discovered and realized so many interesting aspects of iPhone development during the development of this project.
While I cannot talk about the specifics of the iPhone application nor the problem it solves due to client NDAs, I thought that it would still be possible to talk about the interesting aspects of the app without giving away too much.
The project started off as a native iPhone app that would allow users to setup events in a particular domain and then allow the user to post updates on that event to their contacts/friends in existing social networks such as Twitter and Facebook. As analysis progressed, it soon became obvious that while posting to existing social networks is useful, we would not be adding real value unless we gave the audience that the updates were sent out to – the friends and family – a user experience that could not be achieved with Twitter and Facebook since we kept hitting walls in the API as well as the user experience on these sites. I posted my observations on this early on during the analysis and early development of this project in this post.
The application that we ended up with is so much more useful and complete. Along with the iPhone app, we built a polished microsite that the friends and family could visit and view the updates and comment on them. We also hooked in a flexible REST-full API under the hood using which the iPhone app client could sync the events, updates and comments with the server. Clients built on other mobile platforms in the future can easily hook into this API. The iPhone app itself now includes utilities that focus on the problem domain and makes uses of the iPhone capabilities such as camera and location awareness to bring real value to the user experience. It is a little frustrating not to be able to talk about the problem the app solves or the details of the application as the value does not come across without it. But this will have to do for now.
Our choice of the technology stack on the server side is interesting to note because it’s the first time we used Groovy & Grails with mySQL to build both the microsite and the REST API. It was a very rewarding experience to work with Groovy & Grails because it allowed us to build a sophisticated scalable site in record time and I can foresee how maintenance pains will be eased dramatically compared to other technologies we have used. The focus on convention over configuration opened up a huge number of shortcuts to achieve what would have been laborious manual coding otherwise that would have taken us twice as long to complete the microsite. Since Groovy & Grails lie on top of the Java platform, we did not have to make any sacrifices since we still coded any complicated business logic and algorithms in Java. It all plays together seamlessly.
Among the many interesting problems we hit and thought about, one that stood out was syncing data between the iPhone and the server especially when the device moved between being online and offline. What should we do when the device is not online and the user posts an update or a comment? What approach should we take here? Should we have offline storage that gets synced with the server once the device goes online? Should we sync all the data in timed syncs and on specific actions? We took a look at what a lot of the apps out there do and noticed that most apps tend to allow actions that require talking to the server *only* when the device is online. When not online, the app would not allow the action. Ultimately, that’s the model we went for.
However, we are still thinking about this problem. We can see us hitting this problem frequently in the future in apps where not allowing the action is not an option. It seems like a problem we should provide an elegant and sophisticated solution for. Payman and I are going to be working on this in the background and if we come across any solutions we think might be worth discussing, we’ll put it up here. I hope you will look at them and leave us your thoughts.
There are other such interesting questions that we came across and continue to come across as we start on new mobile platform projects. I hope to find time to post them here as frequently as I can manage.
