Most of the time it will help us to remember the best practices we came up with. And maybe from time to time we will be able to help others with our solutions.
And of course since this is our start as mobile web app developers, we’re hoping to get proper feedback to improve our code. So we’re aware of the fact that our solutions may not be perfect (or sometimes are just crap) and we hope that by documenting our learnings we’ll get new ones along the way.
From colors to F.A.T.Z
colors (for android) is just an ugly tryout of a hybrid app made with Cordova (Phonegap). So only the android version was (as a proof of concept) made with Phonegap while the iOS version was written as a native app.
We didn´t have any experience in writing well structured code for a mobile web app and so, blame on me, I puzzled together a crappy HTML/JS/CSS version for Android.
But even with this crappy codebase it somehow worked on Android. So when we were thinking about F.A.T.Z, using the same codebase and deploying it on iOS and Android seemed like the right thing to do.
Pros and cons of hybrid mobile apps
Because this paragraph could be an article on its own, here’s a short summary of the pros and cons of creating hybrid mobile apps (with Phonegap/Cordova).
pros
- one codebase
- browser testing (most of the time)
- free choice of developer enviroment
cons
- managing different device capabilities in one codebase
- performance on old devices because the webview makes it even worse
- layout has to be done with CSS (at least for us it's a con)
- debugging on android
Lessons learned
Hopefully we will be able to write articles concerning all of our learnings. Listed below you can find an overview of all the things we could think of right now.
Besides finding a proper setup for working on the same codebase (with still two deployments for iOS/Android), we had to decide how to organize our code to guarantee an easy development and maintainance workflow.
Backbone
After a little research (ToDoMVC is a good point to start) we jumped right into using Backbone. Easy to use, big community and a well written documentation are a big plus when starting with Backbone.
Since Backbone isn’t a real MVC-Framework (more like a Model-View-Something) we had to find a way to separate the code in a good manner. Backbone gives you a lot of freedom on this side so we tried a few different ways.
We ended up using Backbone as a kind of MVVC-Framework where on the one hand views could just be ordinary views without any more power than rendering or on the other hand views could be used as controllers handling all the inputs and model updates itself.
We will talk about this in detail in a separate article, even knowing that right now we’re not having a final solution and a lot of improvements could be made.
Cordova (Phonegap)
When using Cordova (Phonegap) to wrap your webview in a native application and get access to a lot of hardware features, you have the chance to work together on the same code and live the dream of write once and deploy everywhere.
A dream that sometimes can turn into a nightmare. Especially when you try to support a wide range of devices. So supporting older Android 2.3+ devices with code that works perfectly on your newer Androids or iPhones could sometimes be very time consuming. And writing CSS that works perfectly on all devices was hard to archive.
Also Phonegap has its own little flaws like not normalizing callbacks for the same function on different devices. As for instance if you try to get the language of a device, iOS would give you “EN” where Android gives you “en-en” or sometimes just “English”.
And in the end if you want to use Phonegap you need a proper setup to share on the one hand the same code for your iOS and Android builds and on the other hand take care of code (like cordova.js) which is just different for each device.
Parse
Parse.com is a very easy to use backend solution. Since their Javascript SDK is based on Backbone we didn´t have any trouble integrating it in our project. We use Parse to store the highscores of our users. With its service CloudCode we even have a real chance to secure and validate new scores.
Since you have one million API calls for free per month, it was the perfect solution to start with, without having the task to write an own backend solution.
grunt.js
When we reached the point of providing a release version of our app we had a few tasks to solve:
- concatenate all the javascript code separated in different files
- minimize the code
- separate the minimized version from our working copy
To not do that every time by hand we use grunt.js.
Overview
Since we just gave a general overview in this article we try to go into detail in further articles.
- General
- proper setup for one codebase
- grunt.js
- Backbone + Underscore
- Backbone.Routers
- Backbone.View
- Underscore.template
- Parse
- Parse + Backbone.localStorage
- Phonegap
- Language detection
- OS detection
- Sounds
- alerts/prompts