Porting considerations

Platform comparison

Android and Nokia Asha platforms are similar in many aspects but there's also differences. Porting most of the Android apps is possible, but there can be certain types of Android apps which are not suitable for Nokia Asha.

There is a large number of devices available on both Nokia Asha / Series 40 and Android, but the following groups of devices will be the target devices for features comparison and porting:

  • Low to mid-end Android phones (price point of ~50-150€).
  • Phones based on Nokia Asha software platform.
  • Series 40 touch phones: touch and type, full touch. Series 40 non-touch phones are also a valid target for some applications.
The following table presents a rough overview of typical device features in the approximate price range where there are both Android and Series 40 touch handsets available.
Table 1. Rough comparison of Android, Nokia Asha and Series 40 touch phones
Feature Android Phone Nokia Asha Phone Series 40 Touch Phone
Display tech Capacitive Capacitive Resistive or Capacitive
Touch interaction Multi-point touch Two-point touch Single-touch and Multi-point touch *
Display resolution 240x320 upwards 240x320 240x320, 240x400
Sensors Proximity, Acceleration Proximity, Acceleration Acceleration *
Positioning GPS, network-based Network-based Network-based
Connectivity GPRS, Edge, 3G, Wlan, Bluetooth, USB GPRS, Edge, Wlan, Bluetooth, USB GPRS, Edge, (3G), Wlan, Bluetooth, USB
Multitasking Yes No No
Background processing Yes No, except push notifications via Nokia Notifications API No
Low-level API access Yes Limited Limited
UI Definition Declarative or programmatical Programmatical Programmatical
Ready-to-use UI components Android UI Standard LCDUI, Nokia UI, LWUIT Standard LCDUI, Nokia UI, LWUIT
Battery life Fair Excellent Excellent
Development platforms Windows, Mac, Linux Windows Windows
IDEs Eclipse Nokia IDE 2.0 for Java ME (Eclipse), Netbeans Nokia IDE 1.0 for Java ME (Eclipse), Eclipse, Netbeans
Application size limitations 50MB + 4GB 5MB ** + Persistent Storage 2MB + Persistent Storage

* Multi-touch and sensor are supported by newer Series 40 full touch devices

** Recommended maximum JAR file size

Due to differences in the two platforms, it is important to understand the technologies involved, different possibilities, any limitations and design considerations in order to gain maximum benefit of the target platform.

In Nokia Asha software platform there are a number of design decisions which impose certain constraints on the applications. For example, replacing default applications and background processing are not supported except for push notifications. The application installation package size is limited to 5 megabytes which can be expanded by storing data in the Persistent Storage.

Android has a large number of combinations of display size and resolution, and Android developers consequently need to support a number of different display densities. In Nokia Asha devices, the resolution offering is much more homogeneous and easy to support from the porting viewpoint.

Portability of different application types

In general the Nokia Asha and Series 40 devices handle resources effectively, and often offer better performance characteristics when compared to devices with similar hardware configurations running on other platforms. Considering the lower price-point, the amount of memory available to applications is often smaller on the Java ME platform when compared to Android. Resource-intensive applications and games might be challenging to port as it is not possible to embed native code in a Nokia Asha software platform application, and there are no GPUs to enable hardware-accelerated 3D.

Social applications commonly require authentication to third party web services, for example by OAuth. Nokia Asha software platform doesn't currently support embeddable web views, which might make integrating social applications challenging.

While Nokia Asha devices are equipped with a capacitive display panel, some Series 40 models continue to make use of resistive technology. On these devices applications that require delicate and rapid touch interactions (such as fast-paced action games) may need thorough testing and possibly creating an optimised version.

The types of applications that are particularly favorable for porting include:
  • Content-intensive applications, showing lots of textual content and making use of vertical scrolling.
  • Single-purpose tools utilising network connectivity: Content aggregators, RSS/News readers; Location-aware applications featuring maps.
  • Various business applications.
  • Casual games (puzzle, 2D arcade), children's apps (drawing, coloring, touch interaction, soundboards).
On the other hand, the type of apps which would be difficult to port are:
  • Applications making heavy use of platform-native code.
  • Personalisation applications: widgets, live wallpapers, replacements for native functionality, input devices.
  • Custom applications using data stored in native applications, for example call logs or text messages are not available for custom application on Nokia Asha software platform (exceptions include, for example, gallery available via the File API).
  • Telephony apps; Nokia Asha software platform is not ideal for, for example, SIP clients.
  • Low-level functionality: battery saver, virus scanner, camera flash torch.
  • Background processing, for example background music players.
  • CPU/graphics intensive applications, for example 3D racing games (might be possible depending on the implementation).
  • Hybrid web/native applications, social media clients requiring OAuth authentication.
  • Multiple Language support (translator, dictionary apps): Android devices come with support for multiple languages, while Nokia Asha devices come in variants, each with a specific set of supported languages for input depending on the area/country where the device was purchased.
  • Accessing/opening large photos in the device's file system (see memory limitations).
The table below presents an overview of how common application categories in the Android marketplace at Google Play would port to Nokia Asha software platform.
Application category Portability and considerations
Games: Arcade, Action, Racing, Sports Generally portable. Certain touch interactions might need to be redesigned. Use of images for graphics might need to be optimised. Many of these games can also be ported for non-touch devices: also lower-resolution ones, by downscaling the graphics.
Games: Brain, Puzzle, Cards, Casual Generally portable. As these games are not usually graphically intensive, porting would be mostly converting the game logic and adjusting graphics for new resolutions. Depending on the type of the game, a wide range of Nokia Asha and Series 40 devices can be targeted, including non-touch ones.
Books, Comics, Education, News/Magazines Generally portable. Biggest challenge is likely scaling the graphical content. Limited display resolution may be an issue.
Business, Finance, Productivity Generally portable, except for productivity tools related to platform personalisation. These applications can be made to work on a wide variety of screen sizes and input types. Porting is mostly adjusting views and converting the application logic. Also adjusting to non-touch devices is usually possible.
Communication, Social Generally not portable: VoIP, tethering, ringtone and caller ID applications not feasible in Nokia Asha. Messenger applications can be implemented using push notifications.
Entertainment, Health, Lifestyle, Medical, Shopping, Sports Generally portable. Applications can be made to work on a number of screen sizes and non-touch devices. Most porting work is done with adjusting the UI and converting application logic. Background processing is not available, for example, to record GPS location on the background.
Media & Video Generally not portable. Simple video playback is possible, but support varies across devices. See Video Formats in the Developer Wiki.
Music & Audio Generally portable. Audio file playback is possible, including progressive download. Audio streaming is not possible.
Photography Portable, with reservations: camera accessible via JSR-234, no access to native code might make filters difficult to implement. This category is best viewed on the larger screen sizes, i.e. Series 40 touch and type and full touch devices and Nokia Asha.
Tools, Widgets, Live Wallpapers, Personalisation, Libraries Generally not portable: replacements for platform functionalities, virus scanners etc. not relevant in Nokia Asha.

Application components and lifecycle

Android applications are constructed from a collection of Activities, Services, Content providers, and Broadcast receivers. Each of these components has their own lifecycle and method of usage.

Figure 1. Android Activity lifecycle

The MIDlet lifecycle model is similar to Android Activity lifecycle model, but has fewer states and state transition events. There are no direct counterparts for these pieces, but instead MIDlet applications generally consist of a main application class and a number of views, with everything else being handled in standard program code: what happens once the MIDlet is entered is left up to the implementation of the startApp method to decide. This means it is usually convenient to have a central view controller component for the central logic of switching between views.

Figure 2. MIDlet lifecycle

Nokia Asha applications generally offer no specialised support for multitasking or background processing, and application sessions are frequently destroyed and restarted. For storing application state in Nokia Asha devices between application restarts, required session data can be saved in the Persistent Storage. Applications with dedicated backend server can provide push notifications via Nokia Notifications API even if the application is not running.

Language and code reuse

Android code runs on the Dalvik virtual machine, which in practice is able to handle most of the standard Java SE code. In contrast, Nokia Asha applications are based on the commonly used Java ME and MIDP 2.0 specifications. The most commonly encountered difference between the two is the version of the Java language used: Android supports Java 1.6+, but Nokia Asha runs on Java 1.3. The Java ME class library is relatively thin compared to the "desktop" flavour of Java, which means in some cases additional code must be included, for example for String or image manipulation operations.

How large parts of the code can be reused when porting from Android to Nokia Asha ultimately depends on the type of the application and its implementation details. As running native code is not possible on the Java ME platform, some specialised game code may need to be rewritten when porting to Nokia Asha software platform. On the other hand, as the Frozen Bubble porting example proves, game code written in Java can be also very straightforward and convenient to port.

It is likely that some Java libraries which can be used on the Android platform are not usable on Nokia Asha platform because of the language level differences alone. However, there is an extensive amount of support documentation and example applications with source code available at the Nokia Developer site. For example, the RLinks porting example uses the Java ME version of the JSON library, and includes useful utility code shared with some other Nokia Asha example applications. There are also high-quality libraries, such as Tantalum, that provide proven solution models for common challenges like concurrency, networking and JSON parsing.

For UI creation, the most common toolkit used in Nokia Asha is LCDUI that provides a selection of high-level components for utility apps and canvas for custom UI development. Alternatively, you can use open source Lightweight UI Toolkit (LWUIT). LWUIT for Nokia is an optimised version of the original LWUIT toolkit, incorporating Nokia Asha and Series 40 themed UI components and a set of platform features such as Nokia TextEditor, Gesture Framework, and Category bar. There is no official LWUIT support in Android, but there is a community port that developers can use.

As a rule of thumb, when targeting both platforms, any UI or interaction related classes should be separated from the application's engine. This is because many of the classes found in the java.lang.package of Android are supported on Nokia Asha and therefore mathematical calculations and initialisation or interruptions for Threads could be ported with minimal changes. However, advanced dynamic data structures like Queues, Stacks or Lists are not supported on Nokia Asha and they need to be converted to Vectors or HashTables. Similarly, suspending or resuming Android Threads or widely used URL Encoding or Decoding functions are not supported on Asha.

Another common ground between Android and Nokia Asha is the SAXParser that enables parsing data coming from InputStreams using the DefaultHandler. Applications that read files either from a local drive or remotely by contacting a Web Service could share large code parts. The parsing engine should again be separated from the read operation as Nokia Asha uses the Java ME specific javax.microedition.io.Connector in order to retrieve the InputStream, while Android uses the standard java.io.packages for the same operation. For more information about the common classes between Android and Nokia Asha see here.

In the case of developing a new application, it might be worth considering to first develop the application for Nokia Asha and then port it to Android for a number of reasons:

  • Upscaling is easier and requires less effort than downscaling.
  • It is easier to further expand to other Java ME supported platforms, such as BlackBerry and Symbian.
  • Early monetisation opportunities, as opposed to Android where free apps are generally expected.
  • Targeting specific large markets where the Nokia Asha and Series 40 platforms are popular.

Last updated 5 July 2013

Back to top

Was this page helpful?

Your feedback about this content is important. Let us know what you think.


Thank you!

We appreciate your feedback.