Porting mobile apps – few guidelines and insights – Continuous Testing and DevOps Blog

When we talk about mobile world complexities, it is important to understand the meaning of Porting.

We know that the mobile platform is dynamic, often changes and being influenced by many aspects (Calls, SMS’s and other interrupts, but also from diversity of mobile OS’s, new devices entering the market and more)

Porting of mobile apps, means – To take an existing working mobile application (Game, utility, web service or other) which was proved to work fine on few “lead”/”gold” devices which were (hopefully) well-defined by the project manager, and make a port of the application to many other handsets, tablets and so on.

You can imagine, that any generic core bug in one of the “lead” devices will obviously drill down to the ported handsets, so at first it is important to pick the right “lead” device which is new enough in the market, solid, and represent a “family” of existing devices (e.g. Samsung Galaxy SII for the Android OS).

Second thing to keep in mind, is that the time to develop and release a product (Mobile related) is ~3-6 months so the device needs to still be “relevant” in the market and be considered a “lead” in the market at the time of release.

Once we are certain that we picked the right lead devices and we have a Beta version with all features implemented and functioning, we than enter the porting phase in which we start to introduce new devices (hopefully from the same families of the lead devices which we ported) and install the application on them to perform sanity.

If the application was developed and designed “for portability” – we should be able to produce various version per new handsets which are built from the same core base with the distinguish of icons, resources and minor differences – in that case fixing bugs should also be easy.

If the design was not right than we can enter a “nightmare” of fixing bugs backwards in the core source, and maintaining many old and new devices for a long time.

The right model is to have a solid and generic core source base from which the release manager generates using build targets the right handsets by using property files which matches the right device “family” and profile.

Porting bugs can vary between handsets and can be caused by many reasons which are not always related to our application (e.g – an application which uses GPS or Camera and these functions are buggy on the device may impact the application stability – this is something which porting should handle, issues related to screen resolution, rotating from landscape to portrait and more).

In our days when we have the Android OS, iOS and Windows Phone and we wish to develop similar application to these 3 or more platforms, porting becomes even more complex – For that we can consider the above insights, and also integrate tools such as Code Name One, PhoneGap or other tools which allows to use one code base and deploy it to various mobile platforms and languages.

In future blogs i will try and refer to the method of developing a master test plan for the lead devices and a subset/sanity test plan for the ported devices which are derived from the lead ones.

For questions and more details, you may contact me as usual: eran.kinsbrunner@gmail.com