Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

I am currently investigating different alternatives for building a mobile instan

ID: 658630 • Letter: I

Question

I am currently investigating different alternatives for building a mobile instant messaging application for iOS and Android, using an XMPP server (probably ejabberd) as the back-end. Main requirements are a nice UI and of course good performance on most devices.

I have identified three different alternatives, two of which include using the Marmalade SDK

Option A): Use Marmalade C++, creating the UI with Marmalade Libraries such as IwNUI/INUI. In this option, the UI is created in C++ code. My assumption is that this should be good in performance, however I am not sure how easy it is to achieve a nice, custom UI that has a good/modern feel to it, such as other high-quality apps. Another advantage: This would target iOS/Android with one code base.

Option B): Also Marmalade, using the C++ s3eWebView api to load local web pages packaged in the application package. UI would be designed in these web pages using HTML/CSS/JavaScript. For the application logic, JavaScript or C++ can be used, as there is a JavaScript Bridge (docs.madewithmarmalade.com/display/MD/The+Javascript+interface) to communicate between C++ and JavaScript code. Would also target iOS/Android in one go.

Option C): Non-Marmalade: Go with two code bases. Use Objective-C (i.e. "standard way") for iOS, and Google Android SDK for Android. Build the app twice.

I am currently leaning towards Option B, as this would allow for use of one code base, and leverage existing HTML5/CSS/JavaScript technologies (nice especially for UI), together with the ability to use C++. However, my concern is whether device/UI responsiveness will be acceptable with this. I have run some preliminary tests for simple things such as loading CSS3 dropdown menus into an s3eWebView via C++, and this seems fairly responsive (i.e. menu drops down quickly and smoothly).

Explanation / Answer

Regarding the code:

C++ is already commonly used cross platform for non UI code, there was a recent presentation on how dropbox accomplishes this:

oleb.net/blog/2014/05/how-dropbox-uses-cplusplus-cross-platform-development/

Since you intend on using C++, the non-UI code can be shared regardless of the UI decision. That might make it easier to just make a decision about the UI.

Regarding the UI:

You should determine whether this tradeoff is acceptable with additional research.

The last mile of making a hybrid app mimic a native app is rarely worth putting effort into, as you will two problems: 1) finishing the app features, 2) hacking in all kinds of native functionality.

If you try apps made with mobile uis (this site[1]), apps made with mobile frameworks (ionic[2], ratchet[3], others...) and decide the performance is fine, then make a hybrid app. If you feel you need to improve on it, even incrementally, just ship native controls instead.

Even if you end up intending on shipping native controls, you could prototype with HTML and later figure out the native UI, assuming that the non-UI code is decoupled.