Currently attending “Comparing, Contrasting, and Differentiating Between Mobile Platforms” by Mark Spritzler, a fellow CodeRanch moderator. The presentation is in part an open discussion with the audience of what people have tried and works well in the Mobile environment.
1. What is out there?
- Android OS (Java)
- Apple iOS for iPhone/iPod/iPad
- Web applications with custom UI for mobile applications. CodeRanch currently offers a mobile web version of the website
- J2ME (not common)
- BlackBerry (custom Java)
- SymbianOS (C)
2. Android OS Review
Built by Google and uses Java and can run Flash. UI built with declarative UIs using XML primarily and supports visual tools such as Droid Draw and/or Interface Builder. MVC-like architecture with view as XML, and control/model as Java classes. The API is quite open so there’s a lot of ability to customize for developers.
There is currently a large variety of Android devices so splintering of the code base could be in the future. Some devices cannot upgrade the Android OS, leading to permanent branching of code base.
Also, Android requires a lot of manual work to integrate with a database, such as SQL Lite, whereas Apple iOS has this built in.
3. Apple iOS Review
Built by Apple and uses Objective-C, and cannot run Flash. Developers must manage memory manually. The API is completely proprietary and there are limit tools for developers. For example, the developer must have a Mac and use an xCode. Closed APIs but Apple promises stability (although it did change in iPad with split/view feature).
Dicussion on Apple’s strigent application approval process followed. One participant commented that they waited 1-2 months for Apple to approve it. Apple has also stopped approving ‘pointless’ apps. I asked Mark if he thinks the delays are worth the improvement in quality, to which he replied that it does lead to better applications. He also informed the audience that Apple wants you to use certain visual controls in particular manners to help build a consistent UI, and may reject applications based on improper usage. Apple sometimes comments on why applications are rejected but not always.
4. J2ME Failure Review
Idea was to develop using Java and runs on a variety of devices. One of the major problems is Sun certified J2ME mobile phones that didn’t properly or fully implement the spec. Also, lead to splintering of code base and very inconsistent results across devices.
5. Native vs Web applications
Web applications have greater reach since they can run on many devices, but have weaker performance and require the developer to self-promote them.
6. App Generating Frameworks
Build mobile applications from predefined templates using a CMS system often entered in a web browser, such as MobileRoadie, but it is a paid service. Builder frameworks (often open source) that generate mobile applications based on existing code including Appcelector, Rhomobile, PhoneGap.
Write once and run on many devices through generation. They may have limited functionality since they use a subset of features available in the language. Multi-touch is also very limited in Android over iOS. HTML5 does support location-aware so it can help in application generation.
Mark ended the presentation with an open discussion asking people to share their own mobile development experience. He pointed out that there a lot of pros and cons to using different mobile platforms and mobile devices, and you should consider the resources on hand when deciding how to proceed in development.
“Android requires a lot of manual work to integrate with a database, such as SQL Lite, whereas Apple iOS has this built in.” – Something’s amiss here. Android has SQLite built in, and an API to use it. No “integration” needs to be done, and certainly nothing manual.
What I meant by that statement is the API is cludgy and awkward to use.
True, the API is a bit hobbled by having to be general enough to accommodate non-DB data sources in ContentProvider (which is also a plus, on the other hand). But it is rather different than JDBC.
I don’t agree with the “not common” comment on JME, by the way. I’m pretty sure there are more JME phones being used than all of iOS/Android/WinMobile/WP 7 etc. combined. They’re not smartphones, though; maybe that got lost during transcription. And the BlackBerry *does* run on JME, but has additional BB-specific APIs.