Leveraging Configuration Management Systems Android

There are many wonderful source control systems out there for developers, and most that work well for traditional development work fine for a mobile project. Versioning your application, on the other hand, is not necessarily as straightforward as you might think.

Choosing a Source Control System

Mobile development considerations impose no surprise requirements for source control systems. Some considerations for developers evaluating how they handle configuration management for a mobile project are

  • Ability to keep track of source code (Java) and binaries (Android packages, and so on)
  • Ability to keep track of application resources by device configuration (graphics, and so on)
  • Integration with the developer’s chosen development environment (Eclipse)

One point to consider is integration between the development environment (such as Eclipse) and your source control system. Common source control systems such as Perforce, Subversion, and CVS work well with Eclipse.

Implementing an Application Version System That Works

Developers should also make an early decision on a versioning scheme that takes into account the device particulars and the software build. It is often not sufficient to version the software by build alone (that is, Version 1.0.1).

Mobile developers often combine the traditional versioning scheme with the target device configuration or device class supported (Version 1.0.1.Important Characteristic/Device Class Name).This helps quality assurance, technical support personnel, and end users who might not know the model names or features of their devices or only know them by marketing names developers are often unaware of. For example, an application developed with camera support might be versioned 1.0.1.Cam, where Cam stands for “Camera Support,” whereas the same application for a device without camera support might have a version such as 1.0.1.NoCam, where NoCam stands for “No Camera Support” source branch. If you had two different maintenance engineers supporting the different source code trees, you would know just by the version name who to assign bugs to.

Just to make things a tad more confusing, you need to plan your upgrade versions as well. If an upgrade spawns a rebuild of your application, you might want to version it appropriately: Version 1.0.1.NoCam.Upg1, and such. Yes, this can get out of control, so don’t go overboard, but if you design your versioning system intelligently upfront, it can be useful later when you have different device builds floating around internally and with users. Finally, you also have to keep track of the versionCode attribute associated with your application.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Android Topics