in android, ios, mobile |

Mobile Application Development Protocol

Mobile application development protocol is a set of rules and procedure that we need to follow before starting the mobile application project, during the project execution and after the project delivery. We are introducing this protocol for following reasons,

  1. To make our work efficient and fast by following standard programming practice.
  2. Easy to collaborate with multiple team member.
  3. Increase readability of code.
  4. Ensure security / privacy in mobile application
  5. Gathering crash report information to resolve bugs in the application before and after production.
  6. Collecting user behaviour within the app that will help for future enhancement planning.

Prerequisite / Information Required

Every developer need to be clear about the following topic before starting the project.

 

Topic Detail
Project Requirement Complete project requirement for client project or project idea for demo application
Design Mockup Look and feel of mobile application in PSD or Image format
Application Name
Package ID / Bundle ID
Supported Platform iOS Android Both
Programming Language Objective C <Version>

Swift <Version>

 Java<Version>
Deployment Target iOS<Version> Android<Version>
IDE Xcode<Version> Android Studio<Version>
Device Support Phone Tablet Both

Mobile Application Foundation

For every mobile application project we will allocate sufficient amount of time to setup application framework before we actually start actual project work.  During this project setup we need to address the objective of mobile application development protocol.  Below is the detail description of what we need to include  for mobile application foundation setup,

  1. Correctness
  2. Naming Convention
  3. Code Organisation
  4. Managing Constant
  5. Managing Environmental Variable
  6. Managing Development and Production Build
  7. File Structure
  8. Version Control
  9. Persistency 
  10. Logging
  11. Localisation
  12. Analytics
  13. Crash Reporting
  14. Rest Call Handling
  15. Form Validation
  16. Dependency Manager
  17. UI Interface Design
  18. Design Consistency
  19. Component Reusability
  20. Unit Test

 

Correctness

We need to ensure the code we write is error and warning free as far as possible. The compiler won’t let you compile when there is an error, but compiler ignores this in case of warning. So consider warnings to be errors.

Naming Convention

Use descriptive names with camel case for classes, methods, variables, etc. Type names (classes, structures, enumerations and protocols) should start with capital letter, while method names and variables should start with a lower case letter.

Function

For functions and init methods, prefer named parameters for all arguments unless the context is very clear. Include external parameter names if it makes function calls more readable.

 

Protocols

Following Apple’s API Design Guidelines, protocols names that describe what something is should be a noun. Examples:CollectionWidgetFactory Protocols names that describe an ability should end in -ing, -able, or -ible. Examples:EquatableResizing

Enumerations

Following Apple’s API Design Guidelines for Swift 3, use lowerCamelCase for enumeration values.

 

Code organisation

Comments

Use comments to make code self-documenting explaining what a particular piece of code does. Comments must be kept up-to-date or deleted.  Comments should not be used to disable code. Commented out code is dead code and pollutes your source. If you want to remove code but keep it around in case it’s useful in the future you should be relying on git and/or your bug tracker.

  1.  // : Use single line comment  to disable  one line code
  2. /* */ :  Use block comment to provide self-documenting information  about the block of code
  3. //MARK    //TODO   //FIXME:   Use this extension to properly organise the code in the logical block of functionality.

Managing Constant

Better use of constant make the code more readable and easy to update strings of text throughout the application.  Utilising struct and enum can make constant very handy, contextual and reuse of the same name.

 

Managing Development and Production Build

For starters, some of you may be wondering why you should use two builds while developing your app. The reason is because as you continue to build new features, you want to separate the development version from the existing public production app. Standard software development practice is to use different environments for the different versions of the software. The development version of an app typically uses a different database and server from the production environment. Developers commonly use dummy images or data during testing. In testing or development environments, it’s not uncommon for one to use test data such as “test comment”, “argharghargh” and “one more test comment”. Obviously, you don’t want your real users to see this kind of messages. In the case, if your app using an analytics system, you may even send thousands of events during the testing stage. Again, you don’t want to mix the test data with the production data in the same database. This is why it’s always recommended to separate the development and production builds. To read more https://tigerraj.wordpress.com/2016/01/19/manage-development-and-production-builds/

 

 

Managing Environmental Variable

Environmental variable (System variable) are very critical variable of any software product, which upon incorrectly configured can cause critical issue in system or in a  business. So we need to give special attention to these variables. These are the variable whose value changes based on the build configuration such as debug , development or production.  Let’s take an example that you are integrating stripe as payment gateway.  Stripe does have sandbox environment and production environment identified with  two different credential.  Now imagine what will happen if we by mistake use production credential in debug or development environment.

Version Control 

Every project need to use version control from the beginning of project execution.  There are basically 2 popular option for this git and svn.  This will make life lot easier when

  • You made a change to code and realised it was a mistake and wanted to revert back
  • Lost code or had a backup that was too old?
  • Had to maintain multiple versions of a product?
  • Wanted to see the difference between two (or more) versions of your code?
  • Wanted to prove that a particular change broke or fixed a piece of code?
  • Wanted to review the history of some code?
  • Wanted to submit a change to someone else’s code?
  • Wanted to share your code, or let other people work on your code?
  • Wanted to see how much work is being done, and where, when and by whom?
  • Wanted to experiment with a new feature without interfering with working code?

 

Persistency

 

Depending on the scale of the mobile application, every application needs some kind of data persistency layer within the application.  When we store user’s data, it is then our responsibility to address users privacy and security. Depending on the severity of the data we can store user information in three different form which we need to strictly follow

  • Keychain :  We need to use keychain for storing utterly critical user information such as username, password, access code, securityKey etc
  • User Default or Preference :  We need to use User Default in such cases where we need to store application specific data which  don’t need to use complex database. Such as  login status,  application specific key value pair data.  We also need to make sure we store very limited information in User Default. Both apple and google have limitation on this. Upon exceeding this limit your app may get rejected during submission.
  • Mobile Database :  When we need to store large information with complex query  handling mobile database is the option. There is no limit in storage capacity until you have sufficient space in your device.  SQLite  Realm and CoreData are popular option available.  Realm will be better option among all other because it is modern, fast, efficient and easy to use.

Once we start using one of the database type, it is not recommended to use other database in parallel with previous one.

 

Logging

During development of any software developer add print message  through out the code for debug purpose using log() or print(). When application get’s bigger such log message also increase.  Now when your application is sufficiently large  the printed log message very big that it does not even serve your need or help in debugging specially in case of multi threaded application. We often print username and password for debug purpose but forget to comment in production build which result in  security vulnerability. Also because of flooded message your application slow down unnecessarily.

There is a better option  for logging that won’t hurt the current sentiment and also address the problem specified earlier.  We can set LOG LEVEL  in the application and easily filter what to print and what not to print in console for development and production builds. LOG LEVEL can have following  value with its priority. First one have least priority.

  1. Verbose or Debug : print all message
  2. Info: print message that have log level info, warn and error
  3. Warn: print message that have log level warn and error
  4. Error: print message that have log level error

So it’s ok to set log level to debug during development but need to change to info or warn for production. To support this we need to use third party tool

iOS https://github.com/SwiftyBeaver/SwiftyBeaver
https://cocoapods.org/pods/SwiftLogger
  • Declare a logger
    SwiftLogger.logLevel = .Verbose
  • Invoke logging methods, e.g.,
    Log.error(“Something has gone horribly wrong.”)
    Log.warning(“Something might go wrong.”)
    Log.info(“This is some useful information.”)
    Log.debug(“This is a debug message.”)
    Log.verbose(“This is some very specific information”)
ndroid    slf4j for android       http://www.slf4j.org/android/
  • Declare a logger
    private static final Logger logger = LoggerFactory.getLogger(MyClass.class);
  • Invoke logging methods, e.g.,
    logger.debug("Some log message. Details: {}", someObject.toString());

 

 

Localisation

Internationalisation and Localization of apps is essential when you want the apps to seamlessly support different languages and region. Internationalisation refers to process of providing a framework to the app for supporting multiple languages. Both iOS and Android have standard way to achieve localization.  Localization need to done for 3 different part in app

  • Internationalisation of UI Control (such as button title, Label).
  • Internationalisation of text.
  • Internationalisation of images.

Easy to follow tutorial can be found at

http://rshankar.com/internationalization-and-localization-of-apps-in-xcode-6-and-swift/
https://www.appcoda.com/localization-tutorial-ios8/ https://developer.android.com/distribute/tools/localization-checklist.htmlhttps://developer.android.com/training/basics/supporting-devices/languages.html
https://developer.android.com/guide/topics/resources/localization.html

 

Analytics

After releasing mobile application we need a tool to gather information about  how user are interacting with your application so that you can prioritise investments in the next version.  There are lot of popular player available for mobile analytics among them

  • Google Analytics
  • Mixpanel ( recommended )
  • Heap

Below are some of advantages of integrating mobile analytics

1. Helps to build an efficient mobile marketing strategy.

Without analytics to verify which content and/or functionality customers respond to, marketers have no basis from which to strategize. Analytics will help define a measurable goal. Does my app have an adequate ROI for my overall campaign? Which tactics are reaping the highest returns? If you can’t answer these questions with hard data, then it’s virtually impossible to build a successful marketing campaign.

2. Discover which parts of your app people are using, and which parts they aren’t.

Analytic tracking has the ability to show the different screens and paths users take when navigating throughout your app. By following which screens users spend the most time on and come back to most often, you have a clear understanding of the content users are looking for. It’s worth finding a better way to get them there. You can use this information to produce more content or further develop the functionality that your users will likely engage in.

3. Learn which parts of your app drive valuable conversions.

Mobile analytics enable marketers to understand which parts of their app lead to conversions and how often. For example, if you have a nonprofit app that accepts donations, you can tell how many people are actually pledging a donation through your app, even if all contributions are processed the same.

4. See if people actually use the app.

People only use 25% of their apps on a continual basis. Since repeat use is very important in building a relationship with your users, tracking whether second time users spend time with the app can give valuable insights as to whether the app provides users with good enough reason to return.

 5. Detect the mobile device.

Which mobile devices download your app? It is important to the overall efficiency of your mobile marketing strategy to understand which mobile devices should be prioritized for QA and future development. For instance, if you notice that more Android users download your app, you can look into why this is, and gain a better understanding of your target demographic.

Analytics can help you realise the entire user experience of your mobile app – from detection to download to engagement.  Through data-driven decisions at each stage of the app life cycle, marketers and developers can create an app experience that is more useful and engaging for their users and overall marketing strategy.

Crash Reporting

Every application crash when user starts using it.  During development we can instantly track down the bug causing  the crash and resolve it.  But  once your app is made public, it is then impossible to track bug  with the approach you use in development environment.  To make life easier to get real time crash report from customer we need integrate third party service  which  additionally provide lot more information about the crash in application in production environment.

I recommend to use fabric for this.

Rest Call Handling

Most mobile application need some kind of communication  with server to function.  Also it is always good idea to print request and response header that will help during debugging.  While creating such  handler we need to address  following conditions

 

 

Write a Comment

Comment