May 7th, 2012

Guide to mobile development: intro and native apps

Categories

Guide to mobile development: intro and native apps

This 3 part series will talk about the mobile eco system and how native apps, runtime native apps, and mobile web apps tie it all in.

If you are a developer and trying to or thinking of getting into mobile development, this is a guide for you. In just a few years mobile development has changed dramatically. The so called “old days” when we had no tools and were limited by devices are behind us. These days mobile development is less about the phone and more about the OS. There are both high end and low end feature phones and smartphones. The distinction between the two is becoming less important now. For a while now the market has been shifting towards the smartphones. In the early adopter countries like the US and Canada, smartphones are no longer a status symbol but the norm. If you are designing for the global market and want your app to work on every possible device, you must accomodate different screen sizes, different OS’s, and different programing languages. You willl also need to structure your code so that it has a small footprint and does not “hog” bandwidth. Most feature phones have very limited memory; furthermore, the bandwidth is too expensive for a lot of people in most countries.

The new mobile eco-system is diverse, confusing, and can be a little intimidating. My experience is with Google Android OS and the Apple iOS so I’m going to limit the scope of this discussion to these. Hopefully, some of you can add some comments about mobile development for RIM BlackBerry OS, Microsoft Windows Mobile, and various Linux OS’s.

Here is how the eco-system breaks down. There are three different versions of apps (more if you combine the three different versions into hybrid apps); we have native apps, runtime native apps, and mobile web apps. Native apps are coded in the native language, have full access to the native API’s, and are written in IDE’s by the OS providers. The runtime native apps are executed through an embedded runtime that exposes the native API’s and uses some sort of easy templating to compile the apps for different devices. The most-used templating is HTML 5, CSS, and JavaScript. Mobile web apps are either just web pages formatted for the mobile device or full apps built using JavaScript Frameworks that use HTML 5, CSS and internal browser databases.

Native Apps
Android apps are coded in Java programing language. Google wants to be IDE agnostic, but right now the most features that support Android development are found in Eclipse. IntelliJ version 11 has a view pane that will help with graphic user interface development. The code runs in Google’s flavor of JVM. iOS apps are coded in Objective-C. The best tool for iOS development is Xcode, however if you like IntelliJ you can use AppCode from JetBrains for iOS development. When developing mobile apps, a developer needs to consider the environment. Although we never have infinite resources, the mobile platform has more finite resources than any personal computer or server. Furthermore, each app runs in a sandbox, meaning it is isolated from the other apps. The database and the file system of the other apps and the OS are not accessible to your app. Your app will have the same access to the mobile platform resource as the other apps. You can still affect the phone with your code, therefore you should be a good citizen and think about how your app will fit or work with other apps. With this in mind, the developer should profile and load test the app to see if the device can handle the app. Almost every Android device has different heap size. The average heap size is about 40Mb compared to average server heap size of 2Gb. Regular users will not be able to change the factory set heap size on an Android phone, so you have no choice but to make sure the app will run on different Android phones before releasing the app. The iOS system is a little more predictable, but still has finite resources.
Memory is not the only concern on mobile platforms; the bandwidth and the battery are the other major concerns. You can not assume there is limitless bandwidth, either through ignorance or design mistakes. Some popular email apps pull all the new emails when open or when running in the background. If you are on business trip in a different country and have to pay for the roaming charges and you forget to turn off the app or change some sort of setting, you might be surprised by the bill. In this case a simple change in design, such as an alert asking to pull the emails or a cap on the number of emails that can be pulled at once, would have saved the user a lot of money. The battery has always been a concern. Now the phone comes with more and more software and hardware features. With every app asking for push notification and location services. The phone’s battery is drained so fast by the apps, you don’t have enough power to make a phone call. Every social media app wants to know your current location. The GPS is one of the most power hungry features on the phone. If your app is running in the background checking the GPS location every few seconds, the battery will be drained very quickly. Depending on the precision required by your app you might want to get the location by less power-hungry means. Both Android and iOS devices have a few different ways of finding your location. You can use cellular tower triangulation – it’s not very accurate but it is low power. The other option is to use WiFi lookup – it’s more accurate than cellular tower lookup but it needs more power.

part 2 -> Runtime native apps: Appcelerator titanium
part 3 -> Mobile web apps: Sencha and JQuery

Links
Android – http://developer.android.com/index.html
iOS – http://developer.apple.com/devcenter/ios/index.action
Rhodes – http://rhomobile.com/products/rhodes/
Appcelerator – http://www.appcelerator.com/
Sencha Touch – http://www.sencha.com/products/touch/
jQuery Mobile – http://jquerymobile.com/
PhoneGap – http://phonegap.com/
AppCode – http://www.jetbrains.com/objc/