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
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.
Setting Up Your Android Development Environment
Writing Your First Android Application
Understanding The Anatomy Of An Android Application
Defining Your Application Using The Android Manifest File
Managing Application Resources
Exploring User Interface Screen Elements
Designing User Interfaces With Layouts
Drawing And Working With Animation
Using Android Data And Storage Apis
Sharing Data Between Applications With Content Providers
Using Android Networking Apis
Using Android Web Apis
Using Location-based Services (lbs) Apis
Using Android Multimedia Apis
Using Android Telephony Apis
Using Android 3d Graphics With Opengl Es
Using The Android Ndk
Using Android’s Optional Hardware Apis
Working With Notifications
Working With Services
Extending Android Application Reach
Managing User Accounts And Synchronizing User Data
Handling Advanced User Input
Targeting Different Device Configurations And Languages
The Mobile Software Development Process
Designing And Developing Bulletproof Android Applications
Testing Android Applications
Selling Your Android Application
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.