1 HSC PROPRIETARY

1.0 EXECUTIVE SUMMARY 1

2.0 CHALLENGING FACTORS IN A MOBILEENVIRONMENT 2

2.1 BATTERY LIFE 22.2 SCREEN SIZE 22.3 CONNECTIVITY 22.4 BANDWIDTH 22.5 MEMORY 22.6 OPERATOR & OEM POLICIES 2

3.0 ARCHITECTURAL BEST PRACTICES 33.1 OPTIMIZING BATTERY LIFE 33.2 OPTIMIZING FOR SCREEN AND USER

EXPERIENCE (UX) 53.3 CONNECTIVITY AND BANDWIDTH 83.4 MEMORY 93.5 ABSTRACT USING LAYERS: CODE FOR

DIVERSITY / FRAGMENTATION 103.6 PERFORMANCE OPTIMIZATION 103.7 KNOW HOW TO TEST 13

4.0 A USEFUL DESIGN PATTERN: MODELVIEW CONTROLLER 14

5.0 HSC EXPERTISE IN MOBILE APPLICATIONSError!

Bookmark not defined.

Developing for Mobile Platforms: General discussion and bestpractices

1.0 EXECUTIVE SUMMARY

Starting 2007 (launch of the venerableiPhone), Smartphones have changed the waywe look at mobile communication. Theerstwhile ‘mostly voice phone’ devicesuddenly transformed into a computing deviceand opened a new world of possibilities formobile users.

Amazing User Experience (UX), small formfactors, coupled with powerful developmentplatforms & mobile broadbandavailabilityhave opened up a Pandora’s box interms of how these tiny devices can be usedto improve our daily lives with almost as muchproductivity as a standard laptop PC. Withmore than 100,000+ (as of Nov 2009)applications on the iPhone and thousands onother competing platforms like Android,Blackberry, J2ME and Windows Mobile, it isapparent that we are living through arevolution; a paradigm shift, where the worldis converging to mobiles and relatedtechnologies for erstwhile desktop centricapplications. As this paradigm shift isoccurringa lot of desktop programmers arebeing thrown into a new world mobileprogramming. While there are many tools like Rhomobile (www.rhomobile.com), PhoneGap(www.phonegap.com), LiquidGear (www.liquidgear.com) and iWebkit (www.webkit.com)which try and bridge the gap between desktop and mobile programming, the seasoned mobileprogrammer will know these tools only scratch the tip of the iceberg and are only applicable forweb based non real-time applications. Programming for limited power/resource devices is amuch bigger challenge than the desktop environment. This whitepaper is a general guidelinefor developers who are taking a leap of faith into the mobile development world, to help

2

them get a head start in terms of selecting the right approach to develop a mobileapplication. The paper is independent of any specific platformbringing out differentiation in applicable

2.0 CHALLENGING FACTORS IN A MOBILE ENVIRONM

Smartphones have fewer resourcesthe notable ones are the battery, the screen size, connectivity, bandwidthsection of the paper we will introduce several key challenges. The next chapter will addresswhat we, as developers, can do to mitigate these challeng

2.1 Battery Life

Unlike desktops, mobile phonesadd to that, batteries have not been able to keep up to speedadvancementswhen compared to those of the chipsets whichwords while the phone processors and applications got more powerful, the battery that powersboth remained quite the same. Any compute operation performprecious resource to deplete. A compute intensavailable battery resource and eventually contribute to a degraded user experience and apotential rejection by users. The battery is not only a problem for application developers; oftenit is one the reason that leads to phone manufacturers having to make compromises onfeatures for a device. For example, one of the primary reasons that Apple does not allowmultitasking for 3rd party applications is that doing so will deplete battery resourcApple’s case, the phone features many software enhancements in terms of UI andwhichare already taxing to the battery. Aapplications would allow developers to create resource hungrythe battery to unacceptable levels, quickly.

2.2 Screen Size

Irrespective of processor advancements,developers are left with a much smallerseveral visual challenges. Just because a phone has a great web browser does not mean that itwill be as convenient to navigatescreen size has a direct relationship to UI Experience.

2.3 Connectivity

Unlike an always-on Ethernet connection via a DSL or Cable router, a mobile application mustcater for sporadic connectivity. Even though mobile operators may advertiseconnectivity, in reality however,

HSC PROPRIETARY

ad start in terms of selecting the right approach to develop a mobile. The paper is independent of any specific platform and simply

applicable programming methodology.

IN A MOBILE ENVIRONMENT

fewer resources when compared to their desktop counterpartsthe notable ones are the battery, the screen size, connectivity, bandwidth and

introduce several key challenges. The next chapter will addresswhat we, as developers, can do to mitigate these challenges.

Unlike desktops, mobile phones are usually disconnected from a continuous power, batteries have not been able to keep up to speed in terms of

when compared to those of the chipsets which reside in the phone. In otwords while the phone processors and applications got more powerful, the battery that powers

. Any compute operation performed by an application causes thisresource to deplete. A compute intensive application would quickly eat up the

available battery resource and eventually contribute to a degraded user experience and aThe battery is not only a problem for application developers; oftenads to phone manufacturers having to make compromises on

. For example, one of the primary reasons that Apple does not allowparty applications is that doing so will deplete battery resourc

features many software enhancements in terms of UI andthe battery. Adding multitasking capabilities for

applications would allow developers to create resource hungry applications that are likelybattery to unacceptable levels, quickly.

Irrespective of processor advancements, the form factor of these devices is smalldevelopers are left with a much smaller real estate to deliver their content on.several visual challenges. Just because a phone has a great web browser does not mean that it

navigate the same content on a phone as it is on a desktop. Therefore,rect relationship to UI Experience.

Ethernet connection via a DSL or Cable router, a mobile application mustcater for sporadic connectivity. Even though mobile operators may advertise

however, that is rarely true. High-speed train journeys, a visit to the

ad start in terms of selecting the right approach to develop a mobileconcentrates on

counterparts. Some ofand memory. In this

introduce several key challenges. The next chapter will address

power source. Toin terms oftechnology

e in the phone. In otherwords while the phone processors and applications got more powerful, the battery that powers

application causes thisive application would quickly eat up the

available battery resource and eventually contribute to a degraded user experience and aThe battery is not only a problem for application developers; oftenads to phone manufacturers having to make compromises on

. For example, one of the primary reasons that Apple does not allowparty applications is that doing so will deplete battery resourc es more. In

features many software enhancements in terms of UI and functionality,capabilities for 3rd party

pplications that are likely drain

form factor of these devices is small and theto deliver their content on. This brings up

several visual challenges. Just because a phone has a great web browser does not mean that itthe same content on a phone as it is on a desktop. Therefore,

Ethernet connection via a DSL or Cable router, a mobile application mustcater for sporadic connectivity. Even though mobile operators may advertise ‘Always On’ IP

train journeys, a visit to the

2

basement or an elevator are all prime examples or when a phone may drop its connection.Connectivity therefore, is a scarce resource that applications need to cater to.

2.4 Bandwidth

Different wireless access technologies coupled with subscriber service profile determines thebandwidth that would be eventuaunderstand that the available bandwidth, isparticular geographical area. Further, despecially so, while roaming. Although with the introduction ofan issue, however still, there are many subscrbasis. Therefore, from an application perspective, not only should the application brace forchanges in available bandwidth (example, coverage drops from 3G to GPRS), but by design, theapplication should be architected in a way that data consumption is as less as practicallypossible without affecting the quality of the service that is being provided by theapplication.Another key aspect to keep in mind while developing applications is that typicallythe downlink bandwidth is higher than the uplink bandwidth.

2.5 Memory

The reason why we have covered memory last is the fact that newer memory architecturesbeing introduced in mobile phone platforms are making it lesser of an issue for the newergeneration of devices. However stillmuch less memory and as an application for masses we want to develop an application whichcan run seamlessly on different classes of devices available in the market today.

2.6 Operator & OEM Policies

OEMs and Operators usually build diffephone platform or publishing guidelines for applications.developed for a specific service provider and a mobile device, developers should be aware ofdifferent vendor policies and applicationbe adhered to, for the application to be deployed in a particular networkdevice. Please refer to section 3.5

HSC PROPRIETARY

basement or an elevator are all prime examples or when a phone may drop its connection.Connectivity therefore, is a scarce resource that applications need to cater to.

Different wireless access technologies coupled with subscriber service profile determines thebandwidth that would be eventually made available to the user. As developers we mustunderstand that the available bandwidth, is typically a function of the network load in a

Further, data consumption associated tariffs are heftylthough with the introduction of one-tariff plans this is lesser of

, there are many subscr ibers who use data services on pay as you useTherefore, from an application perspective, not only should the application brace for

changes in available bandwidth (example, coverage drops from 3G to GPRS), but by design, thechitected in a way that data consumption is as less as practically

possible without affecting the quality of the service that is being provided by theAnother key aspect to keep in mind while developing applications is that typically

er than the uplink bandwidth.

The reason why we have covered memory last is the fact that newer memory architecturesbeing introduced in mobile phone platforms are making it lesser of an issue for the newer

However still there are still millions of phones in use today which featuremuch less memory and as an application for masses we want to develop an application whichcan run seamlessly on different classes of devices available in the market today.

OEMs and Operators usually build differentiation in their offerings by either customizing thephone platform or publishing guidelines for applications. Unless the application is beingdeveloped for a specific service provider and a mobile device, developers should be aware of

policies and application development and deployment guidelines which mustfor the application to be deployed in a particular network or on

3.5 for more details on this.

basement or an elevator are all prime examples or when a phone may drop its connection.

Different wireless access technologies coupled with subscriber service profile determines thedevelopers we must

the network load in aon associated tariffs are hefty and

ans this is lesser ofvices on pay as you use

Therefore, from an application perspective, not only should the application brace forchanges in available bandwidth (example, coverage drops from 3G to GPRS), but by design, the

chitected in a way that data consumption is as less as practicallypossible without affecting the quality of the service that is being provided by the

Another key aspect to keep in mind while developing applications is that typically

The reason why we have covered memory last is the fact that newer memory architecturesbeing introduced in mobile phone platforms are making it lesser of an issue for the newer

today which featuremuch less memory and as an application for masses we want to develop an application whichcan run seamlessly on different classes of devices available in the market today.

rentiation in their offerings by either customizing theUnless the application is being

developed for a specific service provider and a mobile device, developers should be aware ofguidelines which must

or on a particular

3

3.0 ARCHITECTURAL BEST PRACTICES

With these constraints in our mind, there are some key architectural methodologies, which canbe adopted to write optimum code for

3.1 Optimizing battery life

3.1.1 Be aware of the power management features of the OS

In order to prolong the battery life most of the mobile phone operating systemsenter a dormant state incase there is no activity either by the user or from thunderlying hardware platform. When the OS is about to enter a dormant state,applications are usually informed and asked for consent to action. The modernday mobile phone operating system features very complex power profiles andinclude multiple optioncomponents.

A good architecture should exploit these APIs, notifications and services and gelthem well into the user experience in a way that it contributes to an elongatedbattery life. For example, fobackground music stored locally on the phone, the video and the networkcomponents can be put to a dormant state, however, when the same applicationis playing back video, it prevents the OS from turning off tthe video component device.

Some other power management tips: Turning off or reducing display brightness for screens that are compute

intensive and don’t require continuous screen update Many power

battery charge level. Checking one in 10intelligent processing decisions in the application.

If the platform supports, check the power state of the phone before youexecute a UI heavy operation (for example, if a phone is in Screen Off state,there is little point in doing a foreground animation unless your applicationwants to turn the screen on). In general, understand the power states of thephone well before you writeyour code.

Writing an application that utilizes memory management effectively is alsoimportant. Please refer to

HSC PROPRIETARY

BEST PRACTICES

With these constraints in our mind, there are some key architectural methodologies, which canbe adopted to write optimum code for mobile platforms.

Be aware of the power management features of the OS

In order to prolong the battery life most of the mobile phone operating systemsenter a dormant state incase there is no activity either by the user or from thunderlying hardware platform. When the OS is about to enter a dormant state,applications are usually informed and asked for consent to action. The modernday mobile phone operating system features very complex power profiles andinclude multiple options for power management of audio, network and video

A good architecture should exploit these APIs, notifications and services and gelthem well into the user experience in a way that it contributes to an elongatedbattery life. For example, for an audio player application which is playingbackground music stored locally on the phone, the video and the networkcomponents can be put to a dormant state, however, when the same applicationis playing back video, it prevents the OS from turning off the backlit display forthe video component device.

Some other power management tips:Turning off or reducing display brightness for screens that are computeintensive and don’t require continuous screen update

manager APIs provide the developer an API to check currentbattery charge level. Checking one in 10-15 minutes can help makeintelligent processing decisions in the application.If the platform supports, check the power state of the phone before you

te a UI heavy operation (for example, if a phone is in Screen Off state,there is little point in doing a foreground animation unless your applicationwants to turn the screen on). In general, understand the power states of thephone well before you write an application and make use of the states in

Writing an application that utilizes memory management effectively is alsoimportant. Please refer to 2.5

With these constraints in our mind, there are some key architectural methodologies, which can

In order to prolong the battery life most of the mobile phone operating systemsenter a dormant state incase there is no activity either by the user or from th eunderlying hardware platform. When the OS is about to enter a dormant state,applications are usually informed and asked for consent to action. The modernday mobile phone operating system features very complex power profiles and

s for power management of audio, network and video

A good architecture should exploit these APIs, notifications and services and gelthem well into the user experience in a way that it contributes to an elongated

r an audio player application which is playingbackground music stored locally on the phone, the video and the networkcomponents can be put to a dormant state, however, when the same application

he backlit display for

Turning off or reducing display brightness for screens that are compute

manager APIs provide the developer an API to check current15 minutes can help make

If the platform supports, check the power state of the phone before youte a UI heavy operation (for example, if a phone is in Screen Off state,

there is little point in doing a foreground animation unless your applicationwants to turn the screen on). In general, understand the power states of the

an application and make use of the states in

Writing an application that utilizes memory management effectively is also

4

3.1.2 Tradeoff between burning local CPU vs. using the network for compute heavy jobs

Carefully partition the business logic of the application to leveragebased infrastructure for compusure that we do not end up over architecting the solution, as nmight not be ubiquitouslyamount of batteryis a client/server application andconnectivity a correct

3.1.3 Select the right algorithm; go with as much approximation as allowable

Unless an application is processing something criticalfinancial applicationnumbers especially in gamesat a higher computation andwhen developing complex user interfaces and gamesplayback application, which can fallback to a lowsuitable for the form factor of the device’s scree

3.1.4 Avoid floating point computations

Almost all of the mobile phone platforms do not feature a floating point coprocessor and hence all floating point computations are executed using fixedpoint libraries which is quite a drag on the CPU and hence the badvised that either architects develop equivalent fixedthe strategy laid out in

3.1.5 Avoid loops

Resort to an event driven architectureputting the application and hence the device in the low power stateapproach saves a lot of battery and alsoOS architecturesas well, since most of the Ostate till an event to be serviced occurs on the phone.

3.1.6 Multi-tasking3.1.6.1 Cooperative Multi-tasking

Cooperative multiwillingly give up CPU whenever they don’t need itsystem a fair share of CPUprogramming methodology not only leads to optimal battery performance but

HSC PROPRIETARY

Tradeoff between burning local CPU vs. using the network for compute heavy jobs

partition the business logic of the application to leverageinfrastructure for compute bound jobs.When adopting this strategy

sure that we do not end up over architecting the solution, as nubiquitously available and 2) might consume

amount of battery if used excessively. However, if the application being designedis a client/server application and the user is expected to

correct architecture can stretch the battery a long way.

Select the right algorithm; go with as much approximation as allowable

application is processing something critical, as would be a case for afinancial application, users are often ok with approximations in display and

especially in games and UI components. Higher precision often comesat a higher computation and hence battery costs. This concept is very usefulwhen developing complex user interfaces and games . A good example is a videoplayback application, which can fallback to a lower resolution-rendering enginesuitable for the form factor of the device’s screen.

Avoid floating point computations

Almost all of the mobile phone platforms do not feature a floating point coprocessor and hence all floating point computations are executed using fixedpoint libraries which is quite a drag on the CPU and hence the badvised that either architects develop equivalent fixed-point algorithms or usethe strategy laid out in 3.1.2 if such computations cannot be avoide

Resort to an event driven architecture as application loops prevent the OS fromputting the application and hence the device in the low power stateapproach saves a lot of battery and also gels well with the modern

as well, since most of the OSs are designed to enter a dormantevent to be serviced occurs on the phone.

tasking

Cooperative multi-tasking is an application design pattern where applicationsgive up CPU whenever they don’t need it , to give other tasks in the

system a fair share of CPU. Cooperative multi -tasking mixed with event drivenprogramming methodology not only leads to optimal battery performance but

Tradeoff between burning local CPU vs. using the network for compute heavy jobs

partition the business logic of the application to leverage network-hen adopting this strategy, make

sure that we do not end up over architecting the solution, as network access 1)relatively higher

e application being designedthe user is expected to have network

architecture can stretch the battery a long way.

Select the right algorithm; go with as much approximation as allowable

, as would be a case for a, users are often ok with approximations in display and

. Higher precision often comeshence battery costs. This concept is very useful

A good example is a videorendering engine

Almost all of the mobile phone platforms do not feature a floating point co -processor and hence all floating point computations are executed using fixedpoint libraries which is quite a drag on the CPU and hence the b attery. It is

point algorithms or useif such computations cannot be avoided.

application loops prevent the OS fromputting the application and hence the device in the low power state . This

modern mobile phoneo enter a dormant

tasking is an application design pattern where applicationsto give other tasks in the

tasking mixed with event drivenprogramming methodology not only leads to optimal battery performance but

5

also helps the OS to keepoperations that the user might want to perform on the phone.OSs follow an application development methodology centeredmulti-tasking as athe platform.

3.1.6.2 Muti-threadingDifferent OSs take different approach towards Multiin J2ME and Blackberry it the way to implement multipreferred approach on OSs like Symbian as itin the runtime system.

3.1.6.3 General RuleA good architecture should ideally abstract mutithe core application code and adapt the abstraction to the platform dependingupon the platform.

3.1.7 Use Compiler Optimizations

Applications can often be improved in terms of efficiency for performance andbattery by optimizing the application using available compiler options.these options well.

3.2 Optimizing for Screen and U

While developing applications developers should ensure that nothing that they do affects theprimary user experience in a negative way.behavior. As developers, we must also ensure thatapplication user experience integrates well with the native user experience of the phoneplatform. This will not only ensure that the users adapt well to the application butusers get comfortable with themost of the UI components, which are natoptimized for the platform in addition to beingcomponents will not only reduce the amount of code but alsoapplication. Some of the common guidelines for designing User Interfaces

1. Avoid too small or fixed sized fonts and if possible allow the users to change thesizes, if possible, from the options menu.

2. Use internationalization libraries while displaying content. This ensures that futurelocalization of the application is simpler (remember that different languages havedifferent character representation schemes,you).

HSC PROPRIETARY

also helps the OS to keep the platform responsive and interactive for otheroperations that the user might want to perform on the phone.OSs follow an application development methodology centered

tasking as a defacto standard, implementation and realization depends on

ifferent OSs take different approach towards Multi -threading in general. Whilein J2ME and Blackberry it the way to implement multi -tasking, it is not apreferred approach on OSs like Symbian as it introduces un-necessary overheadin the runtime system.

A good architecture should ideally abstract muti-tasking libraries of the OS fromthe core application code and adapt the abstraction to the platform dependingupon the platform.

Compiler Optimizations

Applications can often be improved in terms of efficiency for performance andbattery by optimizing the application using available compiler options.these options well.

User eXperience (UX)

While developing applications developers should ensure that nothing that they do affects theprimary user experience in a negative way. Most of the operating systems today ensure such a

must also ensure that we follow the guidelines suchapplication user experience integrates well with the native user experience of the phoneplatform. This will not only ensure that the users adapt well to the application but

get comfortable with the application with little or no coaching. On the technical side,components, which are natively supported by the platform, have already been

in addition to being tested for correctness/bugsnot only reduce the amount of code but also add to stability of your own

Some of the common guidelines for designing User Interfaces are as follows:

Avoid too small or fixed sized fonts and if possible allow the users to change thefrom the options menu.

Use internationalization libraries while displaying content. This ensures that futurelocalization of the application is simpler (remember that different languages havedifferent character representation schemes, let the resource libraries handle this for

the platform responsive and interactive for otherWhile almost all

OSs follow an application development methodology centered on cooperativeization depends on

threading in general. Whiletasking, it is not anecessary overhead

tasking libraries of the OS fromthe core application code and adapt the abstraction to the platform depending

Applications can often be improved in terms of efficiency for performance andbattery by optimizing the application using available compiler options. Study

While developing applications developers should ensure that nothing that they do affects theost of the operating systems today ensure such a

follow the guidelines such that theapplication user experience integrates well with the native user experience of the phoneplatform. This will not only ensure that the users adapt well to the application but will alsohelp

application with little or no coaching. On the technical side,have already been

bugs.Reusing theseadd to stability of your own

as follows:

Avoid too small or fixed sized fonts and if possible allow the users to change the font

Use internationalization libraries while displaying content. This ensures that futurelocalization of the application is simpler (remember that different languages have

let the resource libraries handle this for

6

3. Use relative positioning as much as possible and avoid absolute positioning. Use phoneAPIs to determine current font, window and screen size and ensure your applicationuses them instead of assuming valuedifferent user settings.

4. Since many of the mobile phone operating systems feature a touch modephysical keyboards, applications should be designed to supportthe system exports touch events, it is a good idea to trap and process them too)might require that the buttons and the UI components, which are placed on the views,are slightly larger than usual.

5. The color combination should be soothing and shall ensure rpractice is to follow the color combination configured in the current theme installed onthe device.

6. Make the user interface as consistent and predictable as possible. Users are more likelyto adapt well to an applicationdynamic workflows. What this means is don’t reknown applications that remap the back [not cursor left] key to move an onobject to the left!).

If the application is targeted forimportant that the application appears and behaves properly both in landscape andportrait mode and supports screen rotachoose to omit this guideline from their UI design, make sure the user of the applicationis appropriately informed of this decision.supports it, restrict the application from switching to horizontal mode if the phone isturned (again, we recommend you test for horizontalwidely adopted approach some architects follow the square based client area approach.This approach is most suitable forthe entire UI is designed assuming the client area is a square with its dimension equal tothe breadth or the shorter side of the mobile screen. This way, even when the screen isrotated, it is ensured that the user continues to see whatever was being displayed tohim earlier in the other mode.

7. Be aware of UI guidelines for certification: If your platform has a certification process,read it before you code! Sometimes, you may execute a UIcontradiction of a certification guideline. Incertification. If you implement an exception make sure you are confident of yourchances of an exception approval.

8. Remember those nag screens: On many platforms (J2ME being an example here), if yourapplication is not signed, the poor user will be presented with many ‘nag’ screens for

HSC PROPRIETARY

Use relative positioning as much as possible and avoid absolute positioning. Use phoneAPIs to determine current font, window and screen size and ensure your applicationuses them instead of assuming values. This ensures the application will play well with

of the mobile phone operating systems feature a touch modekeyboards, applications should be designed to support both interfacesm exports touch events, it is a good idea to trap and process them too)

might require that the buttons and the UI components, which are placed on the views,are slightly larger than usual.

The color combination should be soothing and shall ensure readability. One goodpractice is to follow the color combination configured in the current theme installed on

Make the user interface as consistent and predictable as possible. Users are more likelyapplication, which has consistent workflows than an app

dynamic workflows. What this means is don’t re-invent well known functions (we’veknown applications that remap the back [not cursor left] key to move an on

rgeted for devices, which support multiple screen orientation, it isimportant that the application appears and behaves properly both in landscape andportrait mode and supports screen rotation whenever required. In case

guideline from their UI design, make sure the user of the applicationis appropriately informed of this decision. Also, if this is the case, if your platformsupports it, restrict the application from switching to horizontal mode if the phone is

ain, we recommend you test for horizontal mode instead).widely adopted approach some architects follow the square based client area approach.This approach is most suitable for UIs, which have data entry screens. In this approach

e UI is designed assuming the client area is a square with its dimension equal tothe breadth or the shorter side of the mobile screen. This way, even when the screen isrotated, it is ensured that the user continues to see whatever was being displayed tohim earlier in the other mode.

Be aware of UI guidelines for certification: If your platform has a certification process,read it before you code! Sometimes, you may execute a UI operation, whichcontradiction of a certification guideline. In this case, your application will failcertification. If you implement an exception make sure you are confident of yourchances of an exception approval.

Remember those nag screens: On many platforms (J2ME being an example here), if yoursigned, the poor user will be presented with many ‘nag’ screens for

Use relative positioning as much as possible and avoid absolute positioning. Use phoneAPIs to determine current font, window and screen size and ensure your application

s. This ensures the application will play well with

of the mobile phone operating systems feature a touch mode as well asboth interfaces (i.e. if

m exports touch events, it is a good idea to trap and process them too) . Thismight require that the buttons and the UI components, which are placed on the views,

eadability. One goodpractice is to follow the color combination configured in the current theme installed on

Make the user interface as consistent and predictable as possible. Users are more likelyonsistent workflows than an application with

invent well known functions (we’veknown applications that remap the back [not cursor left] key to move an on -screen

screen orientation, it isimportant that the application appears and behaves properly both in landscape and

tion whenever required. In case the developersguideline from their UI design, make sure the user of the application

Also, if this is the case, if your platformsupports it, restrict the application from switching to horizontal mode if the phone is

. Although, not awidely adopted approach some architects follow the square based client area approach.

have data entry screens. In this approache UI is designed assuming the client area is a square with its dimension equal to

the breadth or the shorter side of the mobile screen. This way, even when the screen isrotated, it is ensured that the user continues to see whatever was being displayed to

Be aware of UI guidelines for certification: If your platform has a certification process,operation, which is a direct

this case, your application will failcertification. If you implement an exception make sure you are confident of your

Remember those nag screens: On many platforms (J2ME being an example here), if yoursigned, the poor user will be presented with many ‘nag’ screens for

7

many operations such as network access, SMS access, data storage etc. There is nothingthat destroys a UX experience as much as this one fact. Make sure you know thepotential nag screens, how to avoid them and how to alert the user to change phonesettings appropriately as part of the overall UX workflow design.

9. Use alerts and system notifications and use them wisely. The information beingdisplayed on an alert or a notification should be crisp and to the point, otherwise it willdiminish the visibility of the relevant information.

On platforms which support sysmedium to inform the user that the applicationhasfor user to review.

10. Some platforms like Windows mobile, Symbian and Android allow applications to placewidgets in the phone’scontinuously run in background

1) Critical info updates without actually invoking the application2) A shortcut access to the application for trivial tasks.

A good example is the Google Searchdirectly enter the keywords, which need to be searched, and the application then showsthe search results as the

As an extension to the aboveadd/change animation to the widget icon). This is also a great mechanism to update theuser with brief data without popping up a new screen/dialog. The iPhone process ofinstalling/upgrading a new apinprogress bar and a calendar widget that shows the date and day as part of the icon aregreat examples.

11. Display only relevant information and keep it ordered and grouped. Some examples forthe same could be:

a. Place commands for critical features in a prominent area such as a menuwindows mobile), or a navigation bar or tab buttons (on iPhone) andSymbian, J2ME etc.

b. Likewise, place lesc. Avoid placing commands redundantlyd. Errors should be notified to the user in a meaningful and concise way

12. Instructions for using an application

HSC PROPRIETARY

many operations such as network access, SMS access, data storage etc. There is nothingthat destroys a UX experience as much as this one fact. Make sure you know the

, how to avoid them and how to alert the user to change phonesettings appropriately as part of the overall UX workflow design.

Use alerts and system notifications and use them wisely. The information beingdisplayed on an alert or a notification should be crisp and to the point, otherwise it willdiminish the visibility of the relevant information.

On platforms which support system notifications, such notifications are usually a goodmedium to inform the user that the applicationhas an updated content

ome platforms like Windows mobile, Symbian and Android allow applications to placehome screen. This is a good feature for applications which

background, as it provides users with:

without actually invoking the applicationshortcut access to the application for trivial tasks.

A good example is the Google Search Application for Symbian, wheredirectly enter the keywords, which need to be searched, and the application then shows

the user selects the search button.

As an extension to the above, many platforms allow for dynamic widgets (i.e. you canadd/change animation to the widget icon). This is also a great mechanism to update theuser with brief data without popping up a new screen/dialog. The iPhone process of

new application where the widget icon shows an embeddedinprogress bar and a calendar widget that shows the date and day as part of the icon are

only relevant information and keep it ordered and grouped. Some examples for

Place commands for critical features in a prominent area such as a menuwindows mobile), or a navigation bar or tab buttons (on iPhone) and

mbian, J2ME etc.lace less-frequently used commands in a submenu or settings dialog.

Avoid placing commands redundantlyErrors should be notified to the user in a meaningful and concise way

an application should be easily locatable and accessible

many operations such as network access, SMS access, data storage etc. There is nothingthat destroys a UX experience as much as this one fact. Make sure you know the

, how to avoid them and how to alert the user to change phone

Use alerts and system notifications and use them wisely. The information beingdisplayed on an alert or a notification should be crisp and to the point, otherwise it will

tem notifications, such notifications are usually a goodupdated content or information

ome platforms like Windows mobile, Symbian and Android allow applications to placehome screen. This is a good feature for applications which

Application for Symbian, where the users candirectly enter the keywords, which need to be searched, and the application then shows

, many platforms allow for dynamic widgets (i.e. you canadd/change animation to the widget icon). This is also a great mechanism to update theuser with brief data without popping up a new screen/dialog. The iPhone process of

where the widget icon shows an embeddedinprogress bar and a calendar widget that shows the date and day as part of the icon are

only relevant information and keep it ordered and grouped. Some examples for

Place commands for critical features in a prominent area such as a menu (onwindows mobile), or a navigation bar or tab buttons (on iPhone) and Soft keys on

a submenu or settings dialog.

Errors should be notified to the user in a meaningful and concise way .

accessible.

8

13.The application should be responsive and shall give feedback to the user in reasonabletime. Please refer to section

14. If your application happens to be sending any user data to the network, it ispractice to have a Terms Of Service that states this explicitly and have the user accepbefore using the application.

15.Whenever the application needs to perform some time consumingwork in response touser input, it is always recommended to show that progress is being made using somesort of progress indicatorprogress-bar, slider, wheel etc. for any task that can take more thanscreen refresh.

16. If the application being developed has a time consuming initial setup phase, a splashscreen should be displayed as sooshow progress is being made, or else the userswill perceive that the application isfrozen.

3.3 Connectivity and Bandwidth

Applications accessing the enterprise, social networking sites,(MMO)gaming engines are alreadymay be good its availability and the size of the broadbandsubscriber, is largely variable. Hence, if an applicationgood idea to plan for an online and offline mode

In the offline mode the application typically caches data iavailable to the user even there is littlewith the backend servers as better connectivity or bandwidth is available.

Are online applications better than offline applicationsand shall be chosen by the architects baattempting to solve. While the online mode isup-to-date data their main limitation is that such applications are typically slow andwhen there is little or no coverage. Theoffline issue but designing such applications is typically complex and nongaming engines this approach might not be applicable at all. This approach isas well, since, the data which is cached locally, can fall into wrong hands as the device is stolenor misplaced.

Architect applications so that it can work with the minimal level of data available (i.e. don’t waittill you get the best datasets to work onthat is viable for your app for now, since quick

HSC PROPRIETARY

The application should be responsive and shall give feedback to the user in reasonabletime. Please refer to section Error! Reference source not found. for more details.

If your application happens to be sending any user data to the network, it isa Terms Of Service that states this explicitly and have the user accep

before using the application.

Whenever the application needs to perform some time consumingwork in response touser input, it is always recommended to show that progress is being made using somesort of progress indicator. It is a best practice in the mobile world to show such a

slider, wheel etc. for any task that can take more than 1 s

If the application being developed has a time consuming initial setup phase, a splashscreen should be displayed as soon as possible and with some sort of indicators thatshow progress is being made, or else the userswill perceive that the application is

Connectivity and Bandwidth

Applications accessing the enterprise, social networking sites, Massively Multiplayer Onlinealready taxing the wireless networks. Although data

its availability and the size of the broadband pipe which is available to theis largely variable. Hence, if an application needs online connectivity

good idea to plan for an online and offline mode during design.

lication typically caches data in the local database and makes itavailable to the user even there is little or no connectivity, and then the data is synchronizedwith the backend servers as better connectivity or bandwidth is available.

Are online applications better than offline applications?No one strategy is better than theand shall be chosen by the architects based on its applicability to the probl

. While the online mode is more secure and allows its users to access mostdate data their main limitation is that such applications are typically slow and

tle or no coverage. The hybridapproach on the other hand takes care of thedesigning such applications is typically complex and non-trivial and for online

gaming engines this approach might not be applicable at all. This approach is slightly less secureas well, since, the data which is cached locally, can fall into wrong hands as the device is stolen

so that it can work with the minimal level of data available (i.e. don’t waitsets to work on, and till then process/render the best approximation

your app for now, since quick display is veryimportant. A good example would

The application should be responsive and shall give feedback to the user in reasonablefor more details.

If your application happens to be sending any user data to the network, it is a gooda Terms Of Service that states this explicitly and have the user accep t it

Whenever the application needs to perform some time consumingwork in response touser input, it is always recommended to show that progress is being made using some

e world to show such asecond without a

If the application being developed has a time consuming initial setup phase, a splashn as possible and with some sort of indicators that

show progress is being made, or else the userswill perceive that the application is

Multiplayer Onlinedata connectivity

which is available to theneeds online connectivity , it would be a

n the local database and makes itivity, and then the data is synchronized

strategy is better than the othersed on its applicability to the problem they are

secure and allows its users to access mostdate data their main limitation is that such applications are typically slow and unusable

approach on the other hand takes care of thetrivial and for online

slightly less secureas well, since, the data which is cached locally, can fall into wrong hands as the device is stolen

so that it can work with the minimal level of data available (i.e. don’t waitrender the best approximation

A good example would

9

be the various mapping applications, whichbetter map or derive a more precise location.

3.4 Memory

Memory footprint of applicationsconsider while designing a mobile application. Most of the engineers often endengineering the solution by creating frameworks on top of which the user application is built.While this is a wise approach, often creating genewhich could have been otherwise avoided,significantly. Care should be taken so as strike the right balance between what should bedeveloped generic and specific for the

1. Memory allocation is never cheap. Not allocating memory is always cheaper thanallocating memory, especially at runtime.

2. Allocate memory buffers at the start of the application and then reuse those buffthroughout the application lifespan. One should have a fairly accurate idea for memoryallocations once the data structures and algorithms have been identified for theapplication being developed.

3. Do not allocate memory when executing screen update roun-welcomed glitches/interruptions

4. Optimize the use of memory buffers by using the same buffer for manipulationwherever possible instead of allocating a new buffer every time. Generalizing theconcept, avoid creating shortapproach could be to process the incoming data packet immediately instead of storingin the buffer queue for further processing which is an approach more suitable for serverside multi-threaded high throughput environments.

5. For platforms which support exception handling, it is not a wise choice to throw anexception while the destructor is getting executed.terminate, and second it can caudo not trap the object deletion and hence it may lead to memory leaks.

6. Do not declare destructors as virtual, if the class would not be derived in the future. Thiswill save some critical space, as

7. Check the return value of all memory allocation calls so you know when you have hit alimit.

8. If the platform allows, use data sharing between related processes as much as possible(such as memory mapped files)

HSC PROPRIETARY

applications, which resort to approximations till theydownloaa more precise location.

applications is another important aspect, which the developers need toconsider while designing a mobile application. Most of the engineers often endengineering the solution by creating frameworks on top of which the user application is built.While this is a wise approach, often creating generalized frameworks introduceswhich could have been otherwise avoided, and hence contributes to memory footprint

are should be taken so as strike the right balance between what should bedeveloped generic and specific for the platform and the application. Here are some tips:

Memory allocation is never cheap. Not allocating memory is always cheaper thanallocating memory, especially at runtime.

Allocate memory buffers at the start of the application and then reuse those buffthroughout the application lifespan. One should have a fairly accurate idea for memoryallocations once the data structures and algorithms have been identified for theapplication being developed.

Do not allocate memory when executing screen update routines. This could introduce/interruptions in the user experience.

Optimize the use of memory buffers by using the same buffer for manipulationwherever possible instead of allocating a new buffer every time. Generalizing the

avoid creating short-term temporary objects, if possible. An example for thisapproach could be to process the incoming data packet immediately instead of storingin the buffer queue for further processing which is an approach more suitable for server

threaded high throughput environments.

For platforms which support exception handling, it is not a wise choice to throw anexception while the destructor is getting executed. First, it can cause the application toterminate, and second it can cause memory leaks since most of the library users usuallydo not trap the object deletion and hence it may lead to memory leaks.

Do not declare destructors as virtual, if the class would not be derived in the future. Thiswill save some critical space, as the compiler will not create vtable entries.

Check the return value of all memory allocation calls so you know when you have hit a

If the platform allows, use data sharing between related processes as much as possible(such as memory mapped files)

downloadeither a

the developers need toconsider while designing a mobile application. Most of the engineers often end -up over-engineering the solution by creating frameworks on top of which the user application is built.

ralized frameworks introduces a lot of code,and hence contributes to memory footprint

are should be taken so as strike the right balance between what should beHere are some tips:

Memory allocation is never cheap. Not allocating memory is always cheaper than

Allocate memory buffers at the start of the application and then reuse those buff ersthroughout the application lifespan. One should have a fairly accurate idea for memoryallocations once the data structures and algorithms have been identified for the

utines. This could introduce

Optimize the use of memory buffers by using the same buffer for manipulationwherever possible instead of allocating a new buffer every time. Generalizing the

term temporary objects, if possible. An example for thisapproach could be to process the incoming data packet immediately instead of storingin the buffer queue for further processing which is an approach more suitable for server

For platforms which support exception handling, it is not a wise choice to throw anit can cause the application to

the library users usually

Do not declare destructors as virtual, if the class would not be derived in the future. Thisable entries.

Check the return value of all memory allocation calls so you know when you have hit a

If the platform allows, use data sharing between related processes as much as possible

10

3.5 Abstract using layers: Code for Diversity / Fragmentation

Unlike in the desktop world, where there are a handfulmobile world is fraught with fragmentation. Depending on country, operator, device and otherfactors the same mobile platform is often changed enough to cause nightmares for thedeveloper. There are several causes for fragmentation, including:

1. Hardware: Examples includeprocessing power, input mode, presence of additional hardware, and connectivityoptions.

2. Software & Platform diversity:Series 60/40, RIM OS, iPhone OSMobile etc.).

3. User-preference diversityrequirements

4. Environmental diversitybranding by carrier, compatibility requirements of the carrier backendapplication developmentaccess to outside the network etc.)

Application users, developers, content providers and distrdevice manufacturers are all affected by fragmentation. While designing applicationsdevelopers must ensure that the solution architecture is generic enough so that it can be easilyadapted to multiple targets. A good approacspecific to the platform. Once such demarcation has been identified, a large portion of code canbe reused across platforms with development effort restricted only to platform specificmodules.

3.6 Performance Optimization

1. As mentioned before, try and use native APIs provided by the SDK as much as possiblesince such libraries are usually optimized for both speed and space.

2. If you don't need to access an object's fieldfields. It can be called faster, because it doesn't require a virtual method tableindirection.

3. For Java based platforms virtual references are better tthe interface references could be about 2x time slower as compared to

HSC PROPRIETARY

Code for Diversity / Fragmentation

Unlike in the desktop world, where there are a handful of well knows Operating Systemsmobile world is fraught with fragmentation. Depending on country, operator, device and otherfactors the same mobile platform is often changed enough to cause nightmares for thedeveloper. There are several causes for fragmentation, including:

s include differences in screen parameters, memory size,processing power, input mode, presence of additional hardware, and connectivity

& Platform diversity:For example differences in platform/OS (Symbian,OS, iPhone OS, Palm OS, Mobile Linux, Android, BREW,

preference diversity: Aspects such as in language, style, etc., or accessibility

Environmental diversity: Such as diversity in the deployment infrastructure (e.g.,branding by carrier, compatibility requirements of the carrier backendapplication development APIs, gateway characteristics, opened ports, restrictions on

s to outside the network etc.)

Application users, developers, content providers and distr ibutors, network operators ande all affected by fragmentation. While designing applications

developers must ensure that the solution architecture is generic enough so that it can be easilyadapted to multiple targets. A good approach would be to identify layers, which should bespecific to the platform. Once such demarcation has been identified, a large portion of code canbe reused across platforms with development effort restricted only to platform specific

ry and use native APIs provided by the SDK as much as possiblesince such libraries are usually optimized for both speed and space.

eed to access an object's field specific to an instance, make themclasslds. It can be called faster, because it doesn't require a virtual method table

For Java based platforms virtual references are better than interface references sincethe interface references could be about 2x time slower as compared to its

of well knows Operating Systems themobile world is fraught with fragmentation. Depending on country, operator, device and otherfactors the same mobile platform is often changed enough to cause nightmares for the

differences in screen parameters, memory size,processing power, input mode, presence of additional hardware, and connectivity

n platform/OS (Symbian,, Mobile Linux, Android, BREW, Windows

spects such as in language, style, etc., or accessibility

as diversity in the deployment infrastructure (e.g.,branding by carrier, compatibility requirements of the carrier backend and

APIs, gateway characteristics, opened ports, restrictions on

ibutors, network operators ande all affected by fragmentation. While designing applications

developers must ensure that the solution architecture is generic enough so that it can be easilyh would be to identify layers, which should be

specific to the platform. Once such demarcation has been identified, a large portion of code canbe reused across platforms with development effort restricted only to platform specific

ry and use native APIs provided by the SDK as much as possible

specific to an instance, make themclasslds. It can be called faster, because it doesn't require a virtual method table

han interface references sinceits counter parts.

11

4. On certain interpreted platforms especially the ones based on J2ME and .NET CLR,enums have large storage and performance overheads associated with them, andhence a wiser approach would be use constants instead of enums.

5. Embedded processors typically do not have hardware floating pointoperations on floats and doubleoperations can take on the order of milliseconds to complete.Even for integers, somechips lack the support for divide operation and hence the integer divisions areperformed in software, which degrades the overall performance of the software. A goodapproach would be to developpoints representations and division with subtraction and shift approximations.

6. Most of the mobile platforms support some form of intent based IPC mechanism so asto allow maximum reuse of functionalityprovided by the OS or applications installed onthe device. As an application architect, onesthis functionality. This will not only help keep the memory footprint of the applicationlow, but also allow developers to offload some of the capabilities to applications whichhave been designed ground up to offer such services.implementation of this approach could be platform dependent.

7. Images are one of the most important elements in any user interface. A mobileapplication can use many types of images. Almost allguideline for common image types. Developers should refer to guidelines before theycreate images. This not only provides consistency to the platform but also allows theplatform to optimize image caches for optimum performance.mobile platforms do a bad job of scaling images, so it is best to use dimensions that suita particular view)

8. Keep error handling as simple as possible.not throw error exceptions. Thiintroduces unnecessary error checking making the memory footprint of the applicationbloat.

9. Avoid excessive try catch or exception harnesses; they use excessive space whencompiled since, most of theis natively missing from the platform.

10. Make sure you disable all debugging and testing related code from the release build.Another important observation would be to make sure that all librariescode is linking to, is also built in the release mode.

11. Avoid global static data in your applications. Doing this has advantages:

a. It allows the code to be ported easily across platforms

HSC PROPRIETARY

On certain interpreted platforms especially the ones based on J2ME and .NET CLR,storage and performance overheads associated with them, and

hence a wiser approach would be use constants instead of enums.

processors typically do not have hardware floating pointoperations on floats and doubles are performed in software. Some basic floatingoperations can take on the order of milliseconds to complete.Even for integers, some

he support for divide operation and hence the integer divisions areperformed in software, which degrades the overall performance of the software. A goodapproach would be to develop a revised algorithm, which replaces floats with fixed

ons and division with subtraction and shift approximations.

Most of the mobile platforms support some form of intent based IPC mechanism so asto allow maximum reuse of functionalityprovided by the OS or applications installed on

tion architect, ones should definitely look at reusing some ofthis functionality. This will not only help keep the memory footprint of the applicationlow, but also allow developers to offload some of the capabilities to applications which

ned ground up to offer such services. The exact terminology andimplementation of this approach could be platform dependent.

Images are one of the most important elements in any user interface. A mobileapplication can use many types of images. Almost all mobile platforms publish aguideline for common image types. Developers should refer to guidelines before theycreate images. This not only provides consistency to the platform but also allows theplatform to optimize image caches for optimum performance. (Also historically, manymobile platforms do a bad job of scaling images, so it is best to use dimensions that suit

Keep error handling as simple as possible. A function that returns an error code shouldnot throw error exceptions. This not only complicates application source code but alsointroduces unnecessary error checking making the memory footprint of the application

Avoid excessive try catch or exception harnesses; they use excessive space whencompiled since, most of the compilers use simulated exception harnesses as the supportis natively missing from the platform.

Make sure you disable all debugging and testing related code from the release build.Another important observation would be to make sure that all libraries to which thecode is linking to, is also built in the release mode.

Avoid global static data in your applications. Doing this has advantages:

It allows the code to be ported easily across platforms

On certain interpreted platforms especially the ones based on J2ME and .NET CLR,storage and performance overheads associated with them, and

processors typically do not have hardware floating point support; so alls are performed in software. Some basic floating-point

operations can take on the order of milliseconds to complete.Even for integers, somehe support for divide operation and hence the integer divisions are

performed in software, which degrades the overall performance of the software. A goodrevised algorithm, which replaces floats with fixed

ons and division with subtraction and shift approximations.

Most of the mobile platforms support some form of intent based IPC mechanism so asto allow maximum reuse of functionalityprovided by the OS or applications installed on

hould definitely look at reusing some ofthis functionality. This will not only help keep the memory footprint of the applicationlow, but also allow developers to offload some of the capabilities to applications which

The exact terminology and

Images are one of the most important elements in any user interface. A mobilemobile platforms publish a

guideline for common image types. Developers should refer to guidelines before theycreate images. This not only provides consistency to the platform but also allows the

(Also historically, manymobile platforms do a bad job of scaling images, so it is best to use dimensions that suit

an error code shoulds not only complicates application source code but also

introduces unnecessary error checking making the memory footprint of the application

Avoid excessive try catch or exception harnesses; they use excessive space whencompilers use simulated exception harnesses as the support

Make sure you disable all debugging and testing related code from the release build.to which the

12

b. The code can easily be ported for multic. Better at adapting to an MVC architecture described earlier.

12. Do not ignore compiler warnings.changed to improve the overall performance of the application. While this is alsoapplicable for desktop environments, it is

13. Most of the object-oriented platforms provide some sort ofalways advisable to use that class as the base of all classes we define. More often thannot these classes implement some housekeeping functionality, which leads to bettermemory management, and hence less bugs in the applica

14. Make sure you disable all debugging and testing related code from the release build.Another important observation would be to make sure that all libraries to which thecode is linking to, is also built in the release mode.

15. Functions should be defined local whenever possible. This reduces the amount ofhousekeeping code that is produced corresponding to each object by the compilerthereby reducing the memory footprint and

16. Avoid multiple functions, which perform simisuch functionality and abstract it within a single function with specific parameters. Thisapproach helps reducing the memory footprint of the application.

17. Choose a good set of default values for you applicationThis often helps optimize the application at runtime.

18. Mobile OSs can often suspend or terminate applications running in background so as torecover some runtime memory and launch them back when resources are available. Asthe application is terminated/suspended the user can loose some critical data or stateinformation. To overcome this issue, almost all OSs provide application lifecycle eventsto the applications. Applications which are required to maintain a consistent stacross invocations should register for these events with the underlying OS, and performstate management operations as the application transitions from one state to another.

19. If extracting maximum performance is key for you, don’t useget/set APIsclass fields directly, especially for interpreted platforms like AndroiBlackberry (yes, we know this exposes us to potential data structure changes, but whenit comes to performance optimization, you select the tradeoff)

20. Implement the UI and the Application Engine (or the business code) in two differenttasks. Off loading computations to a different task often helps keeping the applicationresponsive even when the application is performing a very compute intensive job andimproves the overall user experience for users of that application. This strategy is also

HSC PROPRIETARY

The code can easily be ported for multi-threaded and re-entrant architecturesBetter at adapting to an MVC architecture described earlier.

Do not ignore compiler warnings. Oftenthere are clues in them as to what can bechanged to improve the overall performance of the application. While this is alsoapplicable for desktop environments, it is much more important for mobile platforms

oriented platforms provide some sort of base class for objects. It isto use that class as the base of all classes we define. More often than

not these classes implement some housekeeping functionality, which leads to bettermemory management, and hence less bugs in the application.

Make sure you disable all debugging and testing related code from the release build.Another important observation would be to make sure that all libraries to which thecode is linking to, is also built in the release mode.

ined local whenever possible. This reduces the amount ofhousekeeping code that is produced corresponding to each object by the compilerthereby reducing the memory footprint and results in neater applications.

Avoid multiple functions, which perform similar tasks. A good strategy would be isolatesuch functionality and abstract it within a single function with specific parameters. Thisapproach helps reducing the memory footprint of the application.

Choose a good set of default values for you application and the algorithms it executes.This often helps optimize the application at runtime.

Mobile OSs can often suspend or terminate applications running in background so as torecover some runtime memory and launch them back when resources are available. Asthe application is terminated/suspended the user can loose some critical data or stateinformation. To overcome this issue, almost all OSs provide application lifecycle eventsto the applications. Applications which are required to maintain a consistent stacross invocations should register for these events with the underlying OS, and performstate management operations as the application transitions from one state to another.

If extracting maximum performance is key for you, don’t useget/set APIsclass fields directly, especially for interpreted platforms like Androi d, J2ME and

(yes, we know this exposes us to potential data structure changes, but whenit comes to performance optimization, you select the tradeoff)

ent the UI and the Application Engine (or the business code) in two differenttasks. Off loading computations to a different task often helps keeping the applicationresponsive even when the application is performing a very compute intensive job and

es the overall user experience for users of that application. This strategy is also

entrant architectures

ues in them as to what can bechanged to improve the overall performance of the application. While this is also

more important for mobile platforms.

base class for objects. It isto use that class as the base of all classes we define. More often than

not these classes implement some housekeeping functionality, which leads to better

Make sure you disable all debugging and testing related code from the release build.Another important observation would be to make sure that all libraries to which the

ined local whenever possible. This reduces the amount ofhousekeeping code that is produced corresponding to each object by the compiler

neater applications.

lar tasks. A good strategy would be isolatesuch functionality and abstract it within a single function with specific parameters. This

and the algorithms it executes.

Mobile OSs can often suspend or terminate applications running in background so as torecover some runtime memory and launch them back when resources are available. Asthe application is terminated/suspended the user can loose some critical data or stateinformation. To overcome this issue, almost all OSs provide application lifecycle eventsto the applications. Applications which are required to maintain a consistent st ateacross invocations should register for these events with the underlying OS, and performstate management operations as the application transitions from one state to another.

If extracting maximum performance is key for you, don’t useget/set APIs and access thed, J2ME and

(yes, we know this exposes us to potential data structure changes, but when

ent the UI and the Application Engine (or the business code) in two differenttasks. Off loading computations to a different task often helps keeping the applicationresponsive even when the application is performing a very compute intensive job and

es the overall user experience for users of that application. This strategy is also

13

important because, in most of the mobile phone operating systems the OS monitors themain task, which normally hosts the UI, by sending it constant signals, which areautomatically responded to by the UI. Hence, if the UI and the Engine components arecollocated and the application is involved in some intensive compute job the OS on notreceiving the response for heartbeat may terminate the application assuming it is nolonger responsive

3.7 Know how to Test

Developers often end up testing applications on device emulators and not target hardware orreal devices. This could lead to problems when the solution is actually deployed across differentplatforms since, there could be notable differences in the emulator and the platform related tothe application execution environment, the memory model and the performance parameters.

Several questions plague this community when it comes to testing:1. How do I do automated testing on a mo2. How does one test an application across hundreds of devices without the cost of buying

them and/or paying for remote testing (via remote labs offered by some companies) forall those phones?

The answer to the above deserves a detailed whitepaptackled exactly these problems and have designed the right workflows and methodologies tomeet such challenges for you.

HSC PROPRIETARY

important because, in most of the mobile phone operating systems the OS monitors themain task, which normally hosts the UI, by sending it constant signals, which are

atically responded to by the UI. Hence, if the UI and the Engine components arecollocated and the application is involved in some intensive compute job the OS on notreceiving the response for heartbeat may terminate the application assuming it is no

Developers often end up testing applications on device emulators and not target hardware orreal devices. This could lead to problems when the solution is actually deployed across different

notable differences in the emulator and the platform related tothe application execution environment, the memory model and the performance parameters.

Several questions plague this community when it comes to testing:How do I do automated testing on a mobile phone?How does one test an application across hundreds of devices without the cost of buyingthem and/or paying for remote testing (via remote labs offered by some companies) for

The answer to the above deserves a detailed whitepaper each. Suffice to say, at HSC we havetackled exactly these problems and have designed the right workflows and methodologies to

important because, in most of the mobile phone operating systems the OS monitors themain task, which normally hosts the UI, by sending it constant signals, which are

atically responded to by the UI. Hence, if the UI and the Engine components arecollocated and the application is involved in some intensive compute job the OS on notreceiving the response for heartbeat may terminate the application assuming it is no

Developers often end up testing applications on device emulators and not target hardware orreal devices. This could lead to problems when the solution is actually deployed across different

notable differences in the emulator and the platform related tothe application execution environment, the memory model and the performance parameters.

How does one test an application across hundreds of devices without the cost of buyingthem and/or paying for remote testing (via remote labs offered by some companies) for

er each. Suffice to say, at HSC we havetackled exactly these problems and have designed the right workflows and methodologies to

14

4.0 A USEFUL DESIGN PATTERN

Model View Controller (MVC) is one of the most used and popular application design patterntoday and yet so very few application developersparadigm for their own applicationsdecouples the rendering (view) from the logic (controller) and data (model) and isolating eachof these layers from each other through a wellused extensively by modern phone platforms likedepends only on the model to render everything on the screen. The controller receives input,can gain additional information by calling the view, and at the end manipulates the model. Theadvantages of this architecture are

a. A modularized architecture, which is largely independent of how the view renders theinformation and how data is stored internally.

b. Reusability of model and view across usage scenarios.c. Because the model is self

much less painful to change your data layer or business rules.

Figure 4-1: Model View Controller Solution Design Pattern

In this paper we propose a slightly modified MVC pattern be used in mobileapplications. In this proposal, theapplications are single threaded and coa consistent view of the model for both the controller as well as the view. The additionalexchange between the model and the viewaread-only mode allows for an optimization where un

HSC PROPRIETARY

DESIGN PATTERN: MODEL VIEW CONTROLLER

is one of the most used and popular application design patternapplication developers use it in the mobile phone

for their own applications. The design methodology calls for an architecture, whichthe rendering (view) from the logic (controller) and data (model) and isolating each

through a well-defined interface. Infact, the MVC architecture isused extensively by modern phone platforms like Android, iPhone etc. In this approachdepends only on the model to render everything on the screen. The controller receives input,can gain additional information by calling the view, and at the end manipulates the model. Theadvantages of this architecture are:

ized architecture, which is largely independent of how the view renders theinformation and how data is stored internally.

of model and view across usage scenarios.Because the model is self-contained and separate from the controller and the vimuch less painful to change your data layer or business rules.

Model View Controller Solution Design Pattern

In this paper we propose a slightly modified MVC pattern be used in mobileproposal, the architecture leverages the fact that most of the mobile

applications are single threaded and co-operatively multi-tasked and hence there will bea consistent view of the model for both the controller as well as the view. The additional

model and the view where the view consumes the model inmode allows for an optimization where un-necessary parameter marshalling

is one of the most used and popular application design pattern sin the mobile phone development

. The design methodology calls for an architecture, whichthe rendering (view) from the logic (controller) and data (model) and isolating each

, the MVC architecture ishis approach the view

depends only on the model to render everything on the screen. The controller receives input,can gain additional information by calling the view, and at the end manipulates the model. The

ized architecture, which is largely independent of how the view renders the

contained and separate from the controller and the vi ew, it's

In this paper we propose a slightly modified MVC pattern be used in mobilearchitecture leverages the fact that most of the mobile

tasked and hence there will bea consistent view of the model for both the controller as well as the view. The additional

where the view consumes the model innecessary parameter marshalling

15

can be avoided and the view can retrieve only that data which it needs from the model.The same architecture can also be extendthat case, care needs to be taken that the consistency of data is maintained across theview and the controller, because the view might retrieve data from the model through adifferent thread.

Figure 4-2: Customized Application View Controller Design Pattern

*

HSC PROPRIETARY

be avoided and the view can retrieve only that data which it needs from the model.The same architecture can also be extended for multi-threaded scenarios. Hthat case, care needs to be taken that the consistency of data is maintained across theiew and the controller, because the view might retrieve data from the model through a

Customized Application View Controller Design Pattern

be avoided and the view can retrieve only that data which it needs from the model.threaded scenarios. However in

that case, care needs to be taken that the consistency of data is maintained across theiew and the controller, because the view might retrieve data from the model through a

Customized Application View Controller Design Pattern

16

5.0 HSC EXPERTISE IN MOBILE

HSC is a world leader in mobile applications andservices across mobileplatformsapplication development.

Figure

As part of the mobile solution ecosystem, HSC also offers a Mobile Porting Library (MPL)reusable component to its customers. The MPL is an advanced platform abstraction layer thathides platform specific details from the application developer for all important phone platformssuch as Symbian, iPhone, Android, Windows Mobile etc. Written from ground up for mobileenvironments and tested in several live deployments by our customers, the MPLenhances product development quality and reduces time to market for you.

HSC PROPRIETARY

ILE APPLICATIONS

is a world leader in mobile applications and offers turnkey consulting, development, testingplatforms. Our mobile solution ecosystem spans the entire lifecycle of

Figure 5-1HSC Mobile Porting Library

As part of the mobile solution ecosystem, HSC also offers a Mobile Porting Library (MPL)reusable component to its customers. The MPL is an advanced platform abstraction layer that

platform specific details from the application developer for all important phone platformssuch as Symbian, iPhone, Android, Windows Mobile etc. Written from ground up for mobileenvironments and tested in several live deployments by our customers, the MPLenhances product development quality and reduces time to market for you.

offers turnkey consulting, development, testing. Our mobile solution ecosystem spans the entire lifecycle of

As part of the mobile solution ecosystem, HSC also offers a Mobile Porting Library (MPL)reusable component to its customers. The MPL is an advanced platform abstraction layer that

platform specific details from the application developer for all important phone platformssuch as Symbian, iPhone, Android, Windows Mobile etc. Written from ground up for mobileenvironments and tested in several live deployments by our customers, the MPL greatly

17

PROPRIETARY NOTICE

All rights reserved. This publication and its contents are proprietary to Hughes Systique Corporation. Nopart of this publication may be reproducedHughes Systique Corporation, 15245 Shady Grove Road, Suite 330, Rockville, MD 20850.

Copyright © 2009 Hughes Systique Corporation

HSC PROPRIETARY

All rights reserved. This publication and its contents are proprietary to Hughes Systique Corporation. Nopart of this publication may be reproduced in any form or by any means without the written permission ofHughes Systique Corporation, 15245 Shady Grove Road, Suite 330, Rockville, MD 20850.

Hughes Systique Corporation

CONTACTPhone: +1.301.527.1629fax: +1.301.527.1690email: whitepaper@hsc.comWeb: www.hsc.com

All rights reserved. This publication and its contents are proprietary to Hughes Systique Corporation. Noin any form or by any means without the written permission of

Hughes Systique Corporation, 15245 Shady Grove Road, Suite 330, Rockville, MD 20850.

CONTACT INFORMATION:+1.301.527.1629

+1.301.527.1690whitepaper@hsc.com

Web: www.hsc.com

18

APPENDIX A ABOUT HUGHES SYSTIQU

HUGHES Systique Corporation (HSC), part of the HUGHES group of companies, is a leading Consulting andSoftware company focused on Communications and Automotive TelematMaryland USA with its development centre in Gurgaon, India.

SERVICES OFFERED:

Technology Consulting& Architecture:define product requirements, validate technology plans, and provide network level consulting services anddeployment of several successful products from conceptualization to market delivery.

Development & Maintenance Services:in the communication industry. We have a wellSDLC from requirement analysis to the deployment and

Testing :We have extensive experience in testing methodologies and processes and offerPerformance testing (withbench marking metrHSC), Protocol testing, Conformance testing, Stress testing, WhiteRegression testing and Interoperability testingto our clients

System Integration : As system integrators of choice HSC works with global names to architect, integrate, deployand manage their suite of OSS, BSS, VAS and IN in wireless (VoIP & IMS), wireline and hybrid networks.Service Management & Provisioning .

DOMAIN EXPERTISE:

Terminals Terminal Platforms :iPhone, Android, Symbian, Windows CE/Mobile, BREW, PalmOS Middleware Experience&Applications : J2ME ,

Access Wired Access : PON & DSL, IP- Wireless Access : WLAN/WiMAX / LTE, UMTS, 2.5G, 2G ,Satellite Communication

Core Network IMS/3GPP , IPTV , SBC, Interworking ,

Applications Technologies : C, Java/J2ME, C++, Flash/lite,SIP, Presence, Location, AJ Middleware: GlassFish, BEA, JBOSS, WebSphere, Tomcat, Apache etc.

Management & Back Office: Billing &OSS , Knowledge of COTS products , Mediation, CRM Network Management : NM Protocols, Java technologies,, Knowledge of COTS NM products, FCAPS,

Security & AuthenticationPlatforms

Embedded: Design, Development and Portingdevices, Infrastructure components. Usage and Understa

FPGA & DSP: Design, System Prototyping.Automotive TelematHSC

In Car unit (ECU) software design with CAN B & CAN C TelematHSC Network Design (CDMA, GSM, GPRS/UMTS)

BENEFITS:

HSC PROPRIETARY

ABOUT HUGHES SYSTIQUE CORPORATION

ystique Corporation (HSC), part of the HUGHES group of companies, is a leading Consulting andfocused on Communications and Automotive Telemat HSC. HSC is headquartered in Rockville,

Maryland USA with its development centre in Gurgaon, India.

Technology Consulting& Architecture: Leverage extensive knowledge and experience of our domain experts todefine product requirements, validate technology plans, and provide network level consulting services anddeployment of several successful products from conceptualization to market delivery.

rvices: We can help you design, develop and maintain software for diverse areasin the communication industry. We have a well-defined software development process, comprising of completeSDLC from requirement analysis to the deployment and postproduction support.

We have extensive experience in testing methodologies and processes and offerPerformance testing (with), Protocol testing, Conformance testing, Stress testing, White -box and black

Interoperability testingto our clients

As system integrators of choice HSC works with global names to architect, integrate, deployand manage their suite of OSS, BSS, VAS and IN in wireless (VoIP & IMS), wireline and hybrid networks.

Terminal Platforms :iPhone, Android, Symbian, Windows CE/Mobile, BREW, PalmOSMiddleware Experience&Applications : J2ME , IMS Client & OMA PoC,

-DSLAM,Wireless Access : WLAN/WiMAX / LTE, UMTS, 2.5G, 2G ,Satellite Communication

Interworking , Switching solutions, VoIP

Technologies : C, Java/J2ME, C++, Flash/lite,SIP, Presence, Location, AJAX/MashMiddleware: GlassFish, BEA, JBOSS, WebSphere, Tomcat, Apache etc.

Billing &OSS , Knowledge of COTS products , Mediation, CRMNM Protocols, Java technologies,, Knowledge of COTS NM products, FCAPS,

Embedded: Design, Development and Porting - RTOS, Device Drivers, Communications / Switchingdevices, Infrastructure components. Usage and Understa nding of Debugging tools.FPGA & DSP: Design, System Prototyping. Re-engineering, System Verification, Testing

In Car unit (ECU) software design with CAN B & CAN CNetwork Design (CDMA, GSM, GPRS/UMTS)

ystique Corporation (HSC), part of the HUGHES group of companies, is a leading Consulting and. HSC is headquartered in Rockville,

experience of our domain experts todefine product requirements, validate technology plans, and provide network level consulting services and

We can help you design, develop and maintain software for diverse areasdefined software development process, comprising of complete

We have extensive experience in testing methodologies and processes and offerPerformance testing (withbox and black-box testing,

As system integrators of choice HSC works with global names to architect, integrate, deployand manage their suite of OSS, BSS, VAS and IN in wireless (VoIP & IMS), wireline and hybrid networks. : NMS,

NM Protocols, Java technologies,, Knowledge of COTS NM products, FCAPS,

RTOS, Device Drivers, Communications / Switching

engineering, System Verification, Testing

19

Reduced Time to market : Complement your existing skills, Experience in developmentcomplex communication systems, with key resources available at all times

Stretch your R&D dollars :Best Shore” strategy to outsourcingresource fluctuations

HSC PROPRIETARY

: Complement your existing skills, Experience in developmentcomplex communication systems, with key resources available at all times

Best Shore” strategy to outsourcing, World class proces

CONTACTPhone: +1.301.527.1629fax: +1.301.527.1690email: whitepaper@hsc.comWeb: www.hsc.com

: Complement your existing skills, Experience in development-to-deployment in

World class processes, Insulate from

CONTACT INFORMATION:+1.301.527.1629

+1.301.527.1690whitepaper@hsc.com

Web: www.hsc.com