×
Namespaces

Variants
Actions
Revision as of 21:13, 27 June 2012 by inari (Talk | contribs)

Porting from BlackBerry to Series 40

From Nokia Developer Wiki
Jump to: navigation, search

This article explains what needs to be taken into account when porting BlackBerry apps to Series 40.

Enter article metadata as described below. Note that this template can be placed anywhere in the article. Do not remove parameters that you do not use

Article Metadata
Compatibility
Platform(s): Series 40
Series 40
Series 40 DP 2.0
Article
Created: (27 Jun 2012)
Last edited: inari (27 Jun 2012)

Contents

Porting considerations

BlackBerry devices (up to BlackBerry OS 7.1) and Series 40 devices share the same development platform - Java ME. This makes porting from BlackBerry to Series 40 quite straightforward and transparent, especially when compared to other mobile platforms. Generic Java ME MIDlets that use the standard set of LCDUI controls, Canvas, GameCanvas, and the basic set of optional JSRs, should be possible to deploy to both BlackBerry and Series 40 after platform-specific repackaging. Of course, the behavior of LCDUI Commands and the default UI look & feel varies significantly between platforms but from the development perspective optimising a standard Java ME MIDlet for a specific platform is a trivial task. The familiarity of the programming language, Java, also plays a significant role in simplifying the porting process. Many generic Java ME libraries can be reused on both platforms “as is”.

At the same time, most of the benefits that developers used to get from BlackBerry devices are specific platform integration APIs, which allow deeper utilisation of device services when compared to generic MIDlets. On top of that, the BlackBerry UI frameworks are different from the traditional Java ME architecture and much closer to the Java Swing ideology when compared to the classic LCDUI which is, with some Nokia extensions, the basis of Series 40. This means that the estimated difficulty of porting “BlackBerry Application” types (which is the term used in the BlackBerry Application Descriptor XML) is probably on the same level in as Android to Series 40 porting projects. Developers targeting both platforms might consider using the LWUIT library, which provides enough UI abstraction between platforms but also a rich set of UI components. This approach can definitely be an interesting choice especially for new projects because the Nokia release of LWUIT has been tailored for Series 40.

LWUIT for Series 40

And finally, developers should recognise the major differences between the platforms: BlackBerry devices are full smartphones with multitasking capabilities, and Series 40 devices are feature phones with much more limited resources and device capabilities. However, with the right approach and creativity, you should be able to achieve high standards of user experience for ported applications in several categories and benefit from the giant marketplace of Series 40 devices in consumer hands.

Devices especially interesting for porting projects

Developers with BlackBerry applications targeting traditional QWERTY keyboard devices should take a close look at these Nokia devices:

Bb qwerty asha.jpg

Nokia Asha 302 and Nokia Asha 303 are the fastest QWERTY Series 40 devices with 4 MB of Java Heap space available for 3rd party applications. The expected user base is very similar to BlackBerry Bold and Curve users, especially for the messaging and business types of apps. Nokia Asha 302 supports landscape orientation and integration with Mail for Exchange, which makes it one of the primary porting targets for traditional BlackBerry apps.

Full touch devices

With the announcement of Nokia Asha 305, Nokia Asha 306, and especially Nokia Asha 311, BlackBerry developers targeting the full touch experience should also consider porting to these devices.

Bb touch asha.jpg

Nokia Asha 311 is an especially interesting device, giving that the performance is significantly faster than the performance of the more budget-oriented Nokia Asha 305 and Nokia Asha 306.

Portability of different application types

2D games Excellent portability, source code-level compatibility. 2D game development on BlackBerry and Series 40 uses the same Java ME APIs from the javax.microedition.lcdui.game package. For devices with similar input types (touch, non-touch) porting would be possible by simply recompiling and repackaging. However, the main focus for porting will be the optimisation of graphical assets to smaller screen sizes, adaptation of different touch gestures, and adjusting to Series 40 memory requirements.
3D games Generally portable. BlackBerry 3D gaming uses Java interfaces for OpenGL ES. Series 40 doesn’t support OpenGL ES but it features an excellent implementation of Mobile 3D Graphics (JSR-184 or M3G). This JSR is significantly simpler and optimised for low memory footprint but it is far from being primitive and it is a real 3D rendering engine with a special immediate mode, which is ideologically very similar to OpenGL. Similarly as in 2D gaming, Series 40 memory requirements impose challenges for textures and graphical assets.
Social networking Applications with OAuth authentication are not portable as Java apps because the Series 40 platform doesn’t support embeddable web view and the custom Java ME implementation of OAuth appears to be challenging. The Series 40 platform doesn’t support multitasking and background execution, so implementing messaging notifications when the application is not running is not possible. However, if background functionality is not needed and if the social networking app is using custom authentication schemes or private APIs for well-known networks, then it is generally portable. Developers of such apps should consider exploring Nokia Web Apps, where at least the OAuth issue can be resolved.
SMS, MMS, and Bluetooth Messaging Generally portable. BlackBerry and Series 40 both feature the Wireless Messaging API (JSR-205) and Java APIs for Bluetooth (JSR-82). Some parts can be compatible on the source code level with the correct level of abstraction from the UI.
Telephony and platform messaging services Generally not portable. The Series 40 platform doesn’t support integration with telephony and other these types of services for 3rd party developers. Applications for VoIP, Caller ID, Tethering, platform email, and Social Networking apps’ integrations are not feasible on Series 40.
Video, audio, and image processing Generally not portable. The Series 40 platform doesn’t provide APIs for media parsing, recompressing, and image processing. It is also related to memory restrictions (2 or 4 MB Java Heap) imposed on 3rd party applications.
Photography and camera Generally portable with Advanced Multimedia Supplements APIs (JSR-234) which is also supported on BlackBerry with source code level compatibility. Image filtering and processing full resolution images is not possible due to memory restrictions.
News readers, book readers, business, finance, comics, magazines Generally portable. UI redesign and optimisation of graphical assets is required. The Series 40 platform doesn’t support embeddable web view and book / magazine reader apps should implement custom text rendering with LCDUI components or Canvas. Comics and magazine readers should take special precautions regarding memory limitations.
Media playback and streaming Generally portable with Mobile Media API (JSR-135). Simple audio / video playback and streaming is possible and might be compatible on source code level. Redesign is required for background audio streaming apps, which are not supported on Series 40.
Maps and location Generally portable with Nokia Maps API for Series 40, which provides also search, geocoding, reverse geocoding, and routing functionality. Series 40 devices are not equipped with GPS, so Cell ID-based location or an external GPS device with Bluetooth connection is needed.

User interface

Working on the user interface of the application takes most of the development and design time. It is important to correctly map the user experience from BlackBerry to Series 40 using the right APIs and components. A typical BlackBerry application with a standard UI architecture uses the fundamental basics from net.rim.device.api.ui, a set of pre-build components from the net.rim.device.api.ui.component package, and the net.rim.device.api.ui.container package for arranging elements. Combined, those packages provide quite a sophisticated user interface and event model, which is optimised for BlackBerry smartphones. Series 40 UI development should utilise the LCDUI model which is suitable for devices with a low memory footprint.

The following diagram (from the Java Developer’s Library) illustrates this model:

Lcdui diagram small.png

If the BlackBerry application was created with correct decoupling of models, views, and data; rewriting the UI using a set of LCDUI classes, especially in business applications, should not be a significant issue. The biggest UI-related task that developers will face is optimization for different screen sizes and the navigation model. The screens of a BlackBerry application (UiApplication) are managed according to the stack model - you can push your application screens into the stack and the screen on top of the stack is what is visible to the user. LCDUI on Series 40 behaves differently and you can switch between screens directly. In addition to LCDUI, Nokia provides Series 40-specific extensions known as the Nokia UI API. These APIs enhance MIDP with a functionality related to touch screen gestures, canvas drawing, text editing, and kinetic scrolling.

Memory considerations

Modern Series 40 devices impose specific memory limitations on 3rd party applications. The application JAR file size should not exceed 2 MB and Java Heap Size can be either 2 or 4 MB. For applications that use many graphical assets and custom backgrounds, especially games, it might be a challenge to pre-bundle the required resources. The smaller screen size of Series 40 may help reduce the sizes and resolutions of images; however, memory limitations should be considered carefully. A potential workaround for storing a big amount of binary resources can be the usage of RMS (Record Store) and file system. In this case the required application data can be loaded over the network and cached locally.

At the same time, Java Heap size can be a serious obstacle for certain imaging applications. For example, if the application requires displaying large images even from the device image gallery, the developer should take special care of checking the image file size to avoid potential OutOfMemory exceptions.

The Nokia Device Matrix is a very good tool for finding information about devices parameters relevant for porting projects:

Series 40 Devices with Java Heap size 4MB

Series 40 Devices with JAR file size 2 MB

312 page views in the last 30 days.

Was this page helpful?

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

 

Thank you!

We appreciate your feedback.

×