About a little more than a month ago I wrote about my experience with writing my Masters thesis from start to finish in small concentrated time frame of 150 hours. In this post I will be giving out more information about the guts of my thesis. I’ll give brief overview of what I did and what treasures and skeletons I met on the way. The title of my Master’s thesis was “Techniques of developing smart phone applications from a single code base”, I thought it was a bit lengthy, but seeing the other students titles with many more words and even multiple rows. I was quite pleased with my compact title.
So What Does It Mean
In the classical sense of developing mobile apps it pretty much means that, if you want to have an app running for example on iOS, Android and Windows Phone you have to have three separate development teams on staff. If we’re talking about the big players, then this kind of development model is not a problem and it even makes sense. If we think about smaller teams with less resources, then this kind of plan of action isn’t probably the way to go. In the course of my thesis I researched the possibilities of developing multi platform mobile applications from a single code base. I tried to describe the main principles of using different frameworks while doing so. During my work I studied two different frameworks: PhoneGap and Mono. I described the process of creating applications for three mobile operating systems: Android, iOS and Windows Phone 7.
Hey Tell Me About The Frameworks
I thought you’d never ask. Let me do a brief introduction to my two new friends.
Say Hello to Mono
Mono is an open source, cross-platform, implementation of C# and the CLR that is binary compatible with Microsoft.NET. What Mono allows us to do is develop .NET applications on operating systems other than Windows. Also it allows us to share code written in C# between applications. In case of my thesis I developed applications for Android using Mono for Android, application for iPhone using MonoTouch and application for Windows Phone 7 using Mono for Windows phone
How Did it All Go Down
So I wanted to know how easy or hard it was to develop some kind of trivial prototype app with these tools. For a prototype I chose to simplify the simple. I created stripped down Toggl app, that only communicates with Toggl public API. The main needed functionality was as follows:
- Authenticating user
- Showing listing of time entries.
- Start/stop Time Entry
- Stay functional when network connection is lost.
The PhoneGap way
With PhoneGap I started by creating a standalone web application using some cool things like CoffeeScript and Backbone. With some proxy tuning in place the web app was entirely usable by itself. Then after I had a functioning web app I looked at what could be done with PhoneGap. Firstly I decided to try out the PhoneGap Build service, that promises to do all the compiling work for you. This is exactly what it does. You can do some additional configuring like adding some settings or uploading the correct certificates and provisioning profiles for iOS to fine tune your application. Basically it does what it promises. If you are looking for some more custom solution with plugins and such, then PhoneGap Build is probably not the way to go. With my simple time tracking tool prototype the PhoneGap Build service worked great.
The other way I tried was the basic way of building apps for every platform with development tools. For Android I used Eclipse and Android SDK, for iPhone I used Xcode and for Windows Phone 7 I used Visual Studio for Windows phone. I created template PhoneGap project using the PhoneGap command line tools and then copied my web app inside the platform specific assets path inside the project. Android and iOS compiled with minor glitches and seemed to work as intended. The most difficult part of those three platforms was compiling Windows Phone 7. When compiling, it threw several strange errors, and gave me a real hard time. One of which was error message “Object doesn’t support this action”. After some investigation I found out that in the browser used by Windows Phone the variable name „item“ is a reserved word and using it somewhere in the code creates some nasty errors. To make it work as intended, I had to rewrite some parts of the application, that the Windows Phone didn’t get along at all.
With Mono framework it’s absolutely different side of the Moon. Not the darker side, but a different one indeed. When using Mono framework you can have part of your applications code shared between projects. So I started with creating a separate project for the shared code. What can be shared between projects is the part of the Business layer,the Data Access layer and the Data layer. Since I didn’t use any in-app database like SQLite I used only the first two. The Business layer meant that all the models and objects used in the app could be shared. The Data Access Layer consisted of simple HTTPWebRequest logic to post and get data from the Toggl public API.
After this was out of the way I started coding the mobile apps for all the platforms. With every platform I had to create it’s own user interface. To create applications for all the different platforms I had to get acquainted with every platforms specific User Interface designing techniques. On the other hand I felt that this is not what I was aiming at with the single code base to multiple platforms theme, but then again I figured that the separate User interfaces can be a plus since the users on different operating systems are used to different user interfaces.
So What’s The Verdict Chief
For the goals that were set at the beginning of the research, I would have to say that the Toggl way is still the better way. Using PhoneGap and web technologies is effective and at the same time powerful. The applications on different platforms are always in sync and making changes is fast and easy. When still choosing Mono, maybe you are very competent with C# or have some kind of infrastructure in place that is written in C#, you should keep in mind that all the user interfaces are created separately. This makes updating user interfaces not so simple because the changes have to be made for each and every one of the platforms.