Porting is AvoidableExtreme OO and Enterprise ready best practices

for Android, BB, JavaME Apps

by Raja Nagendra KumarFounder & C.T.OTejaSoft Innovations Pvt. Ltd.nagendra.raja@tejasoft.com+91-9886723872

Prepared for TechGig Webexhttp://www.techgig.com/webinar.php?webinar_id=126

Agenda• Background• Porting Definition• Why Porting in Mobile Apps• Porting Challenges for

– Organizations– Developers

• Five OO (Object Oriented) Principles to Avoid Porting• Explanation of Five Principles through Tips

– Problem – Solution

Background• Successful, time-critical deployments of "killer" mobile

apps for B2C, B2E and B2B require significant investment.

• Frameworks, toolsets, libraries, and app platforms all offer the promise of "Write Once, Run Everywhere" functionality. But beyond the initial outlay, the "hidden" costs can add up to many times the original price tag. How should organizations balance and leverage mobile standards and development tools?

• Reference context is for Java Based Mobile Applications, it is applicable to Android, JavaME, BB too.. I shall use code from any of these.

Assumptions• It is assumed audience are hands on developers and

architects• Has experience of complete Mobile Applications

Lifecycle (at least 2 apps)• We hope all of you welcome Product Era

– Where Simplicity is to be rewarded as opposed to complexity

Definition - Porting• Porting is the process of adapting software so that an

executable program can be created for a computing environment that is different from the one for which it was originally designed– Diversity of Embedded Commodity Devices

• Same is currently applied for programs to – work across different standards

• Android, JavaME, BB– Work across buggy implementation of standards

• http://en.wikipedia.org/wiki/Porting

Why Porting• A dirty way to handle fragmentation i.e. Comply to diverse

market choices of – Devices

• 4000 plus mobile devices• More than 10 New Mobiles get released each week

– Many Forms• Mobiles• Tablets• TV’s (Set-Top Boxes)

– SDK’s• Software and Hardware Evolves with time, New Libraries gets added• Android so far has more than 20 versions

– Many Players & OEM’s• Everyone wants their OS/API to be used• Standards are way far.. due to time to market pressure is too high• No Single Winner.. Market Leadership Math's changing each quarter

Conventional ways to Avoid Porting

• Duplicate Code for each client and treat them as separate products eventually

• Use Cross Platform Tools (which are still immature and would never be mature too) such as Phone Gap, Titanium App Accelerator etc..

• Limit the Business– Release the Product only for few devices. Which are currently having big

market share– Market share change impacts business

• Dilute features, interactions and release the product on HTML 5– It is a Myth that HTML versions shall work on all the devices– Browsers on difference devices support various versions of HTML 4.x or 5.x..

• Use Pre-Processing code and make things more complex & buggy

Pitfalls of Conventional Approach

• Add more mess on the name of solving existing and known mess..

• Technology for Technology and Numbers for the sake of Numbers. (They are not meant to give any business value to client’s long term business)

– We all know issue is because of Evolution of Android SDK (In case SDK’s does not evolve then no issues at all..).. How can other 3rd Party Software Solve the issue.. They also evolve..

– Least common denominator approach is Never a solution for Industry grade products

– There would be lag in 3rd party, adopting to new versions of Android SDK

– There are many 3rd party vendors, in this space too… they are all trying to add their own api. Which one would win!!

– New Proprietary API learning & Bugs of 3rd Party shall affect and de-rail much more

Organizational Challenges

• Plan for Porting cost and efforts for each release of the application

• Supporting multiple devices even with best team would demand huge money, which would a very risky business proposition

• Least Denominator approach will not create desired brand impact..– Always end users are looking for richest possible experience

• Long term Business returns based on Mobile applications, so far is a hype for many organizations.

Developer’s Challenges

• With rapidly evolving SDK’s, one can’t even install multiple version in one machine and test..– Do we have android plug-in for eclipse, which can work with

any SDK.. say SDK 1.1 and SDK 4.0.3..?

• Check, if existing plug-in supports?– Code Reuse across the applications/projects?– Does plug-in supports sharing of resources between Android

Module and JavaME Module?– Can the plug-in, build using any SDK’s and for any number of

devices at a time..?

• Each change induces more bugs, due to many manual steps – of Adopting to multiple code bases

• Meeting market demands with sub standard toolset

Five OO Principles to Avoid Porting

1. Implement a Feature and Support for Feature Variance• Object & Class Level

• Field Value Change• Methods Implementation Change

2. Amplify Code Reuse• Single Source Across Modules• OO Reuse of Resources

1. Media (Images, Audio and Videos)2. Text

3. OO & Intelligent Build Script (Avoid plugin approach)• Installation directory structure• Define a Device through Configuration• Common commands for Android, JavaME, BB with single command

4. OO, Dynamic & Organized approach to• sourcepath (Demo of Source Dir Structure) • classpath (Demo of CBE)• Definition of Devices (Demo g8, g9 )• SDK installations (support multiple sdk installs in single machine)• Configurations (dev, pro, qa)

5. Keep Evolution in mind• More SDK’s can come in any time• Inheritance based on File Name and not on absolute file location• Build based supporting for Refactoring

TIPS to Avoid PortingCode Walkthrough

• Problem & Solution Approach• Meant to show how to avoid porting and

to increase productivity - for developer to take on porting efforts

• Easy to evolve with New SDK’s and devices– Self Maintainable framework approach

Tip -1 : Code Feature with Variance in Mind

• Variance Scope– Support for OO Customization

• Be away from the Bug World of IT.. – enter into Variance World• Making Feature work for one device is

Developer’s Job• Making Feature work on every device is the

need for Variance – It is aspiring Architect’s Job– Variance Code should be encapsulated in device

specific classes

Tip 1: Problem – if’s1. Messy & end less depth of if’s

public void playSound(){

if(isNokia()){

if(isS40()){//varience 1}else(isS60(){//varience 2}

}else if (ifMotorola()){

//varience 3}

}

– This if’s would exist in many methods of a class and in many classes in order to meet many features and bugs

Tip 1: Solutionpublic void playSound(){if(isNokia()){

if(isS40()){

}else(isS60(){}

}else if (ifMotorola()){}}

Tip 1: Solution (cont.)public void playSound(){if(isNokia()){

if(isS40()){

}else(isS60(){}

}else if (ifMotorola()){}}

public void playSound(){

DeviceMethod.playSound();}

Tip 1: Solution (cont.)public void playSound(){if(isNokia()){

if(isS40()){

}else(isS60(){}

}else if (ifMotorola()){}}

public void playSound(){

DeviceMethod.playSound();}

public class DeviceMethod extends GenericDeviceMethods{

}

Tip 1: Solution (cont.)

public void playSound(){if(isNokia()){

if(isS40()){

}else(isS60(){}

}else if (ifMotorola()){}}

public void playSound(){

DeviceMethod.playSound();}

public class DeviceMethod extends GenericDeviceMethods{

}

public class N60DeviceMethods extends xyz{

public void playSound(){//useNokiaAPI.. To play the sound}

}

Tip 1: Solution (cont.)

public void playSound(){if(isNokia()){

if(isS40()){

}else(isS60(){}

}else if (ifMotorola()){}}

public void playSound(){

DeviceMethod.playSound();}

public class DeviceMethod extends N60DeviceMethods {

}

public class N60DeviceMethods extends xyz{

public void playSound(){//useNokiaAPI.. To play the sound}

}

Tip 2: Problem – Design for Magic Numbers

• Media – Magic Numbersswitch(WIDTH){

case 128:{

draw(WIDTH+10 )break;

}case 245:

{

draw(WIDTH+5)break;

}

default:{}

}– In android, you have resources stored in hdpi, mdpi, ldpi..however is that enough.. Because each device is of

different sizes..– Also, this approach increase the Jar size multifold

Tip 2: Solutionswitch(WIDTH){

case 128:{

draw(WIDTH+10 )break;

}case 245:

{

draw(WIDTH+5)break;

}

default:{}

}

Tip 2: Solution (cont.)switch(WIDTH){

case 128:{

draw(WIDTH+10 )break;

}case 245:

{

draw(WIDTH+5)break;

}

default:{}

}

switch(WIDTH){draw(WIDTH + DeviceConst.WIDTH_ADJUSTMENT)}

Tip 2: Solution (cont.)switch(WIDTH){

case 128:{

draw(WIDTH+10 )break;

}case 245:

{

draw(WIDTH+5)break;

}

default:{}

}

switch(WIDTH){draw(WIDTH + DeviceConst.WIDTH_ADJUSTMENT)}

public interface DeviceConst extends GenericDeviceConst{

}

Tip 2: Solution (cont.)switch(WIDTH){

case 128:{

draw(WIDTH+10 )break;

}case 245:

{

draw(WIDTH+5)break;

}

default:{}

}

switch(WIDTH){draw(WIDTH + DeviceConst.WIDTH_ADJUSTMENT)}

public interface DeviceConst extends GenericDeviceConst{

}

public interface s40DeviceConst extends xyz{ public static int WIDTH_ADJUSTMENT = 10; public static String PROP_FEATURE_MAPS_KEY=“android.maps.enabled”;

}

Tip 2: Solutionswitch(WIDTH){

case 128:{

draw(WIDTH+10)break;

}case 245:

{

draw(WIDTH+5)break;

}

default:{}

}

switch(WIDTH){draw(WIDTH + DeviceConst.WIDTH_ADJUSTMENT)}

public interface DeviceConst extends S40DeviceConst {

}

public interface S40DeviceConst extends xyz{ public static int WIDTH_ADJUSTMENT = 10; public static String PROP_FEATURE_MAPS_KEY=“android.maps.enabled”;

}

Tip 3: Problem – Infinite Branches

• Reuse to be maximized and should be applied to– For Java Code

• Android• BlackBerry• JavaME

– Across SDK’s– Across Projects– One Main Branch for each Client– Across Many Device Forms

• Mobile• SetTopBox• Tablets

– Across Application Modules• JavaEE• JavaME

– For Text Resources– For Media (Images, Video, Audio)

Tip 3: Solution

• Across the Branches, there is so much code which is similar, Focus on Source Level Code Reuse

• Demo of Directory Structure– Focus on Common

Tip 4 : Problem - Resources Reuse Never Considered

• Images Reuse– How many images can be reused across the project and sdk’s

• e.g Logo & Themes

• Text – Translations– How many times word ‘exit’ gets translated..

• At least 20 times..

– What if the translated word ‘exit’ needs to be changed to some thing else..• How many manual steps are involved?

Tip 4 : Solution

• OO Directory Structure– For Images Reuse– For Text Translations Reuse

Tip 5: Problem - Every thing is decided by plugin

• Eclipse Plugin.. – Plugin decide every thing..– They are designed for one mobile

application and not for enterprises.. Which is a factory for multiple mobile applications

– Source for all IT Waste and IT Rework, IT Duplication

Tip 5: Solution• Evolve the Code from Device Specific to Most Reusable

common code• Use Build Scripts to fully automate• Use the Power of Source Path to pickup best match

first• Power to Refactor as and when needed

Summary• As promised, passion was to find simple solution, this complex

enterprise issue. Try these tips, they work 100%• Fragmentation is not a curse.. It is a boon and however it can

challenge ordinary OOAD programmers..– We have achieved code reuse of as much as 80% for few apps, more than 50%

code most of the times– 80% of porting efforts are eliminate in most cases

• Said approaches has additional benefit of reducing the foot print too.– In most cases it would be much less than one bulky code supporting

all..• Can save much more time and cost than going with 3rd Party Solutions

such as PhoneGap etc..• Follows Build Time Pre-Processing as opposed to Compile Time Pre-

Processing– IDE Friendly– Debugging Friendly– Can build for multiple devices and multiple configurations at a time say n*

Summary (cont.)• Due to clean and separated code specific to each device, no

induced bugs to other devices, due to porting• Code Reuse can’t be applied if the language is not Java, however

resource reuse can be applied for iPhone and other languages too..• What is communicated is tip of iceberg, similar thinking can be

applied to resolve most of the Fragmentation issues

• This Framework is evolved as a bi-product of TejaSoft’s experience in building many enterprise grade mobile applications and while ‘Code Re-Engineering’. – We call this as ‘TezzMDF’

• For Enterprises, this approach would Save as much as US $200K to $500k per release• It Complies to our value of ‘Factor 4 Benefits : Halve the Efforts, Double the Results’

– IT Services companies don’t blame us.. – 3rd Party Single Source Product Vendors.. Integrate our model into our products

Queries?

TezzMDF(Fastest native way to produce Mobile Applications)

http://www.slideshare.net/nagkumar/mobile-single-source-strategyfeedback.techgig@tejasoft.com

Thank You All