My Video Interview at Mobile World Congress 2011 @ Barcenola

Memory Management (m-Cube Level 1)

Memory is one of the main resources for mobile devices. Managing this resource in an optimum manner is one of the main challenges for mobile application developers… Even though there are numerous devices in the market today that have good memory capacity… it is still important that the memory management is not neglected.
While developing mobile applications, one should always use optimal solution for memory usage. For instance, if applications want to display an image on the screen, then using PNG format instead of BMP is advised..

If a single application is used for multiple screen resolution devices, then all the resources should be downloaded from the server at the first launch. This way… the application need not increase its size by packing all resources of different screen sizes together in the final distributable.

If the application want to display a tile pattern in the background of the screen.. it will make more sense to use a small image and render it multiple times on the screen to create the impression of a big image. This way, the applications can reduce the actual memory required to store that big image and it will help in scalability of the app to other screen resolutions.

Also … applications should consider memory fragmentation rules as to allocate memory in the power of 2.
let’s suppose it would require 15 bytes to store a string, applications should allocate 16 bytes (2^4) as it would be easier to add/delete those memory blocks.
Also, try to allocate large chunks rather than small ones. For example, instead of allocating a single object, allocate an array of objects at once and then start the processing the same.
Another factor is Lazy loading, also known as dynamic function loading. Here, applications do not load all the components by default into the memory when a program is started…
In lazy loading, all dependent components will be loaded as and when required by the application. It can be used to improve the performance of an application, if most of the dependent components are not used together on a single screen but are required at different points in the application flow.

All mobile applications should ensure that they do not use more memory than actually necessary.
Memory management should also adhere to the guidelines of the corresponding OS. For example, an iPhone app should follow the guidelines for using an AUTORELEASE POOL.
If the applications want to store a received object completely in an instance variable, then they must retain or copy it. They should generally not use weak references and decide where they would require a Deep Copy of objects and where a shallow copy will do.

Interrupt handling (m-cube: Level 1)

I think interrupt handling is one of the crucial parts of any mobile solution.

So many times it happens that while running a mobile app, there are interruptions such as an Incoming Calls, Text Messages, low memory or a low battery notification. A good mobile solution must be able to handle these notifications gracefully… and without any disruption. Few of the important aspects to be considered here are

• Application suspend and resume should be handled properly especially for incoming calls and Text Messages.

• The UI and media, such as images, sounds, context pointers should be released on SUSPEND event.

• Low memory notification should be given highest priority and unused memory should be release immediately.

• Suspend routine should be small and must not consume time.

• Object Serialization/De-serialization and state management should be considered.

• Context sensitive handlers should execute data processing in case of interrupt handling.

• Thread safe the execution of processes, so that the UI threads will be in a sleep state until interrupt is executed.

Every mobile platform has its own recommendation for interrupt handling. For example, in the iPhone Applications, the low memory notifications must be appropriately handled and necessary steps should be taken like cleaning up the stale resources.

However, if the iphone application is data centric, the “Application state management” should be present. This will be required to handle the premature exit of the application; for example, if the last session of application is closed abruptly, the application should be able to serialize its state before exit, and when the same application is accessed, it should initiate from the same point.

Similarly in BREW applications, “Suspend and resume behavior” is one of the very important recommendation of NSTL TBT certification. As per the NSTL guidelines, BREW application must suspend itself on notification of incoming call and must resume from same point after the call is finished.

In the case of a client-server based mobile application, the app must have ability to check network connectivity (GPRS or WI-FI). If the connectivity is not available, then the application should keep information (to be synced with server) in some local storage and sync it with the server when the network is available next time.

For mobile devices like iPhone, iPad, Windows mobile phones, that supports bolth..landscape and portrait modes, the application should be able to provide the required support with the help of appropriate delegates/ events.

Graphics & UI (m-cube: Level 1)

Graphics & UI have always played a very important role in mobile applications.

I believe that it is essential for the application’s UI design and flow to cover the business needs effectively… and deliver quality user experience in terms of interface and design.

The UI should be compatible to the native applications so that the user finds it easy to operate. For example on RIM Blackberry devices, you can see that the native email client uses Up & Down indicator instead of a scrollbar. Hence, on all carrier-grade Blackberry apps you will see similar design.

UI is the front interface of any application by which the user interacts with it. Application’s success depends largely on the UI’s ease of use and intuitiveness.

Right from the plain vanilla J2ME/BREW devices to the iPhone and Android devices, every platform has certain recommendations for UI. A typical mobile application must follow certain guidelines strictly.. let me discuss some them with you;

• iPhone OS provides guidelines name as Human Interface Guidelines.

• Android also recommends a set of best practices related with “App Widget Design”, “Menu Design” etc.

• Every certification (like NSTL TBT certification for BREW apps, Java Verified for J2ME apps, Windows Logo Certification for WinMo apps) recommends best practices for UI designing.

if a developer follows these UI guidelines from the development stage itself, he will find it very easy to get certification on the application.

I would also like to point out that though there are numerous touch-screen/non-touch handsets available under the same platform, the UI design should be independent for both these categories.

My advice to you as a developer will be to ensure that you are not using the UI of one platform for another… especially, if you are planning to cover multiple mobile platforms (like iOS, Android, J2ME, Symbian, WinMo, etc) for your applications. Every device comes with a specific usage style and the same must be considered while designing the UI.

I also recommend avoiding the use of heavy and large images. My preferable format is PNG.

I would also suggest that you ensure that you do not blend the images with code...as using separate resource files makes the white labeling of apps easier.

If you or any other developer were to follow these basic guidelines, you are sure to have an amazing user experience and end user response on your application product.

Certification (m-cube: Level 1)

Certification clearance is one of the basic requirements for all mobile applications…All mobile applications should adhere to the various certification guidelines and the same should be implemented from the design phase itself.

We have an assortment of testing authorities; NSTL for Brew, Symbian Signed for Symbian, Apple store for iPhone etc. These mobile platforms have their own guidelines and an application is required to follow the same. For Example- All BREW applications should have the functionality of the CLR key as a BACK key. Whereas, in case of your Symbian application, it is essential to incorporate an enable/disable feature if the application has auto-start functionality.

The iPhone OS defines the standard appearance of user interface elements and delivers consistent behavior that the users expect. iPhone makes it mandatory for the developers to follow their rules and ensures that the users get a uniform and satisfactory experience at all times.

Applications are increasingly being submitted to various app stores; we have OVI store for JAVA & Symbian technologies, BlackBerry App Store for BlackBerry, App store for iPhone, Windows Market Place for Windows Mobile, Android market for android... In such a scenario, the applications should also adhere to these store guidelines.

Cost is another very important motivation to follow best practices for certification. As we know, the certification authorities charge a specific amount based on the number of builds submitted for testing. The application developer should consider this factor before the application design and create single build for multiple devices. This would help in reducing the cost of the submission, and facilitate maintenance of the codes.

My video Interview at Nokia World 2010, London.

Distribution (m-cube : Level 1)

An effective distribution strategy plays a vital role in the success of any mobile solution. As the applications’ distribution directly affects the billing procedure, it is imperative that this strategy is worked out in the design phase itself.

Distribution largely depends on the type of application.

Typically, consumer mobility applications may be distributed via App stores, carrier deck or app aggregators like (get jar & cell mania). These app stores have now reduced the entry barriers and helps us reach out to the market in no time, like OVI store - you can register as a publisher just in 1$, get your applications signed for free and launch to the audience in more then 190 countries in almost in no time.

For enterprise mobility, corresponding Mobile Device Management systems should be planned and configured according to the expected load.

In case of a client/server application, like a mobile banking or a stock market app that needs frequent interaction with the server..you may feel the need of distributing it from your own Deck i.e. Over the Air from your own Website.

This makes sense when it is complicated to share the revenues of these apps with carriers, aggregators and/or store fronts while providing a quality service to the customers. In setting up an OTA distribution infrastructure for these cases, we need to make sure of the following two things:

a- Auto-detection of device platform and model, so that the right build is delivered to the requesting mobile device – this is achieved by searching the WURFL database using user-agent string fetched from the mobile request.

b- Auto-upgrade infrastructure is required on both the client & server side, so that on every login, the server can compare the client build version with one available on OTA server and give notification of optional/mandatory upgrade to the client app.

Another way to reach the market quickly is to embed the application on the device before the same is launched. You can do this by making an alliance with a renowned handset manufacturer like Nokia, Samsung, Motorola, etc for this.

If the application is going pre-loaded on the device; our best practices suggests that you should just get a stub of your app pre-loaded on the device which fetches the most updated version of your application matching to the device default locale, when the end-user launches it for the first time.

Stay tuned, I will be posting the details of other attributes and best practices very soon.