MoSync

MoSync

There are a few too many platforms when it comes to mobiles, and targeting them all is getting increasingly hard. There is no coordination between different platforms to have some kind of common application format, API or even programming language.

Most app developers thus end up targeting only the major platforms while neglecting the others. This is precisely where cross-platform SDKs such as MoSync come in. MoSync features one API, and one programming language that lets you target nearly every platform out there! Not only does MoSync support the major Android, and iOS platforms, it also supports BlackBerry, both Windows Mobile (the older OS) and Windows Phone (the newer Metro-style OS), it even supports Symbian and Moblin. Finally it supports the JavaME platform, which enables MoSync applications to reach most feature phones.

To enable web developers to reach all of these platforms as well, MoSync offer support for using web standards to develop mobile applications. This is in the vein of PhoneGap / Apache Cordova; where you create a web application, which is then run in a web browser embedded inside a native application. The web applications has access to a number of native APIs allowing it to behave for all intents and purposes as an application directly running on the platform. In fact MoSync is compatible with the PhoneGap / Apache Cordova APIs.

MoSync goes a few steps ahead of Apache Cordova however, as it supports not only pure web-based applications, but also hybrid applications that bridge C++ / C with web code.

Multiple Paths

As we mentioned before, MoSync offers multiple paths to developing applications. Depending on where you are coming from, you have different options. These aren’t strict paths though, you have quite a bit of flexibility.

On one side you have native path, using C / C++. If you are porting from desktop to mobile, chances are some of the code in is C / C++, and MoSync will let you reuse that on mobile.

On the other hand, if you already have a web application, and want to bring that to mobile, the HTML path is open to you. MoSync will not only allow packaging and running web apps as native mobile apps, it will also let you use the kind of API that normally a web app would not have access to. For example, your web application can access the camera of the device, the compass, the calendar, the contacts and much more.

A third option is to go for a hybrid application which uses both web and native code. This is very useful if you wish to have a rich UI developed using web standards, while the power-hungry aspects of the application, such as image / audio processing can be handled in native code. Of course you can start by porting your web app to MoSync and incrementally replacing performance-intensive code with C / C++ code. Likewise one could port in the functionality of an existing desktop application as C / C++ code and add an HTML interface on top.

Even among these paths you have multiple options. For example, your C / C++ application could either be pure C / C++ code, or it could use the NativeUI features that MoSync provides — more on NativeUI later — or it could use OpenGL. Likewise, an HTML application could also use either a web UI or a Native UI.

NativeUI

One of the features that are quickly lost when you consider a cross-platform toolkit is the ability to have a native-looking, native-feeling UI. While cross-platform does mean that you can have the same look and feel for your application on all platforms, this isn’t necessarily a benefit.

While keeping the same UI across platforms might make it easier for people to switch from one device to another; it could come at the cost of making it difficult for people to switch from one app to another. While a person is using an app on a phone, they expect it to look and behave in a manner that is consistent with the platform. The minor advantage of offering a consistent UI across platforms is trumped by the major advantage of a consistent UI within the platform.

Many cross-platform toolkits offer a solution for this, and in the case of MoSync, we have NativeUI. NativeUI allows one to use a single API to create applications for Android, iOS and Windows Phone 7.

The NativeUI API features a number of widgets that can be used to create a cross-platform UI. Depending on which platform the application is targeting, the same UI code can look vastly different. MoSync allows you to code based on uniform API, but the end-result is rendered on each platform using their native UI representations.

Let us take a look at a snippet of code from one of the example applications that ships with MoSync, NativeUIDemo:
[do action=”code”]mColorScreen = new ScreenColorList ( );[/do]
[do action=”code”]mWebScreen = new ScreenWebView ( );[/do]
[do action=”code”]mImageScreen = new ScreenImageSwiper ( ); [/do]
[do action=”code”]this -> addTab(mColorScreen);[/do]
[do action=”code”]this -> addTab(mWebScreen);[/do]
[do action=”code”]this->addTab(mImageScreen);[/do]
Here the ScreenColorList, ScreenWebView, and ScreenImageSwiper classes are the three “tabs” or screens in this application that are defined separately. They are then added as tabs to a tab view which automatically translates the appearance of the tabs depending on the platform. This tabbed view itself will be added to the main view of the application.

This code will work on both Android and iOS — a slightly modified version is used for Windows Phone 7 — but will follow the native platform’s conventions. Here is how it looks on all three platforms:

IMAGE 1, 2, 3

As you can see, the same functionality is represented on each platform using the platform’s native interface elements. While we showed C++ code for using these native widgets, it is also possible to use these widgets if you use the web programming route. There are two ways to go about this. You can either create widgets using a JavaScript API, or declaratively create the UI using HTML. The following is an example of creating a UI with JavaScript:

var myButton = mosync. nativeui. create( "Button", "myButton", {
	"text" : "Click Me!",
	"width" : "100%"
});

The same widget, defined declaratively in HTML:

<div data-widgetType="Button" id="myButton" data-width="100%" data-text="Click Me!"></div>

In both cases, this will be translated to native code and will look different depending on platform.

The disadvantage when it comes to using the NativeUI is that it is only supported on the three main platforms, iOS, Android and Windows Phone 7. For other platforms, there is the option to use MoSync’s alternative widget framework called MAUI, which includes non-native widgets that look the same on all platforms. An application can use Native widgets for the platform that support it, and non-native ones for the platforms that don’t.

MAUI and MoRe

For platforms such as Symbian, Moblin, JavaME and Windows Mobile, you do not have the option to use the NativeUI widget framework. There instead you can use MAUI, a platform-independent UI framework included in MoSync.

A small example of how one might create a button using MAUI:

MAUI:: WidgetSkin* buttonSkin = new MAUI :: WidgetSkin ( SELECTED_ IMAGE, UNSELECTED_ IMAGE, X1, X2, Y1, Y2, SELECTED_ TRANSPARENT, UNSELECTED _TRANSPARENT );
myButton = new MAUI :: Label ( LEFT, TOP, WIDTH, HEIGHT, parentWidget, "Click Me!", COLOUR, FONT ); 
myButton -> setSkin ( buttonSkin );

Here we are first describing a skin for the button, which includes the images for the button when selected and unselected, information about how the image fits on the button, and whether the images are transparent. Then we are defining the button itself, and finally we are applying the button skin to it. This widget will look the same on all platforms.

MoSync supports emulating applications the emulators that ship with their respective SDKs, the Android emulator, the Windows Phone 7 emulator and the iOS simulator for example. However it also ships with an application called MoRE, which is a simulator for MoSync applications. Unlike device emulators, which have multiple layers, first emulating the device hardware, and then running the OS on top of that, MoRE simply runs the applications directly, so it starts quickly and performs better. However MoRE cannot be use with applications that use the NativeUI and some other features.

Web UI and Wormhole

MAUI isn’t the only way to have a mobile application look consistently and work across all platforms. The other option is using web technologies as the frontend of your application.

Using standard web technologies such as HTML, CSS, and JavaScript one can create powerful UIs. As mentioned before, MoSync exposes native platforms features such as the camera, compass etc. to web applications so they are not feature-restricted.

We also talked about how it goes a step ahead by allowing one to mix and match native and web code. MoSync includes a technology called Wormhole that allows you to bridge between native C / C++ code and JavaScript web code. The C++ Wormhole library allows one to write C++ code that can be invoked from JavaScript. For example, one could write an image filter or an audio processing algorithm in C++ which could be used by the JavaScript code.

Conclusion

While we have covered different approaches to creating the UI, Native UI, MAUI and web-based UI, you needn’t use just one. You can mix and match as desired.

As you can see MoSync is a powerful SDK and should be in the radar of anyone looking to create applications that need to run on multiple platforms. It is very flexible, with a broad feature set that is supported on an even broader set of devices.

Not all features are available on all platforms, that is true; however, it still promotes a large amount of code-reuse.

All of this of this is possible in MoSync via a single SDK. MoSync even offers an Eclipse-based IDE for working with their cross-platform SDK, supports testing using emulators for iOS, Android and Windows Phone, and includes a simulator for quickly testing apps. Oh, and did we mention that all this — the SDK and the IDE — is free and open source under the GPL.

Leave a Comment

Your email address will not be published. Required fields are marked *