Android & Kotlin

How to achieve better performance while mobile application development

Pinterest LinkedIn Tumblr

Every developer always try to give his best to achieve better performance and good results while development of mobile app. But there are many parameters which can improve the performance of mobile app and provide better user interface and user experience to end users. Even these parameters can be considered as checkpoints of mobile App while doing testing of its performance.

Let’s first discuss myths which are always creates issues while development of any mobile app.

Myth #1: All devices are the same and testing on emulators is enough

It is always suggested that before launching the final release of any mobile app, the app should be tested every supportive screen with every supportive OS versions. Because sometimes, app UI can generate different layout on different screens with their sizes. Even test the functionalities on real mobile devices because the end users will use them on real devices only. It is also suggested that make proper documentation of UI issues with different screens, try to solve all of them before giving final release.

Myth#2: If there some bugs in application, users will understand

If application doesn’t work properly or has bugs or has crashing issues , users will easily uninstall the app Quality and performance issues are the primary reason for bad review in Google Play Store/Apple Store/Windows Store. Even It also affects to company’s reputation and company would lose customer’s trust for future products too. Therefore its essential to have a proper mobile testing strategy in place before placing the app on Google play store or Apple Store or Windows Store etc.

When the developer develops apps for the use of mobile phones or Tablets, proper testing needs to be an essential part of every development process. The following practices will improve the performance as well as the quality of application. These points can also be considered as useful information, techniques, and ideas on how to test a mobile application.

Mobile Application Development tips for faster and better performance

1. Test on various data networks: Users might have any type of connectivity 

WiFi or cellular(4G,3G or 2G) – and the device might be switching between the two. The app must respond to this.A mobile application that needs an Internet connection in order to get responses from server or to request to server or to fulfill a task may encounter different data networks while the internet network is on the move as well

In the Case of Blocked Connectivity or no connectivity, the user should be notified with an appropriate ideally the application should indicate that the device.

Let’s first discuss myths which issues while development of any mobile app. is in no internet mode stating about the connection error.

2. Managing Base Url, Access Token or Secret Key

Ensure the application has been connected with proper session setup so that it can send/receive data via an HTTP/HTTPs network. An application should properly handle the Base Url for debug mode/release mode/staging mode etc using Gradle file or any other file.

Access Token or Secret key or confidential information should be passed using some encrypted format with those HTTP request where it is really needed .this practice is also needed due to security concern of application.

How to manage base url and access token using gradle file
    buildTypes {
        debug {
            debuggable true
            buildConfigField("String", "BASE_URL", "\"https://staging.androidwave.com/\"")
            buildConfigField("String", "API_KEY", "\"ABCXYZ123YYYY\"")
            buildConfigField("String", "SECRET_KEY", "\"v320d789fv7894vf1a0b045d97d4b9b7e1854c3ff8dd6681sgbsertcPPPPPPPPP\"")
            buildConfigField("String", "PLACE_API_KEY", "\"AIzaSyAH-koDBFJTKBaTXqQAUbSXYYYYYYYYY\"")
            buildConfigField("String", "API_SOURCE", "\"app\"")
        }
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.config
            debuggable true
            buildConfigField("String", "BASE_URL", "\"https://androidwave.com/\"")
            buildConfigField("String", "API_KEY", "\"ABCXYZ123XXXX\"")
            buildConfigField("String", "SECRET_KEY", "\"v320d789fv7894vf1a0b045d97d4b9b7e1854c3ff8ddXXXXXX\"")
            buildConfigField("String", "PLACE_API_KEY", "\"AIzaSyAH-koKDDJTKBaTXqQXXXXXXXXXXX\"")
            buildConfigField("String", "API_SOURCE", "\"app\"")
        }
    }
3. Use of Progress Dialog or Progress Bar

It is always suggested to display progress dialog or progress bar with meaningful progress messages. So that can know what’s happening with the application while using it.

4. Handling telephone call when application is in use

The user must be able to accept an incoming phone call or do any other task (Reading the message or WhatsApp etc)while the application is running. It should be suggested that application should be resumed from the same point in the application at the end of the call, or any other logical re-starting point.

The application should not block other tasks of (like accepting/rejecting the phone calls, reading/writing messages etc.)

5. Permission Model

Test your app with new permission model of different mobile devices or their OS versions (like Android 6M and above versions) Like contacts permission, storage permission, phone permission etc. so that user won’t face any problems related to required permission while using it.

6. Don’t hijack the native experience

It is always suggested not to hide the status bar or notification bar until and unless it is not required to hide.

The back button should always navigate through previous screens. (Prefer to store the previous screen into ) . Prefer to use native icons or components consistently over the different screens of .

7. Error messages,Spelling errors, Technical text errors:

Any error messages which is displayed on of application should be clearly understandable and meaningful.

Error messages should clearly define to a user the type of the problem, and should also suggest what kind of action needs to be taken (if applicable).

The application and all its screen should be free of spelling errors or language errors or grammatical errors unless they are part of a deliberate design concept.

The text which is displayed over the screens should be clear and readable. Screens should be free of technical text display issues. Such as -> Text cut off / Text overlapping, and all text in each target language(Locale) should be displayed without any display problems.

8. Multiple display format handling

It is always suggested to ensure that application is designed for which display format(portrait/landscape/both). Wireframes and UI should be appropriate according to required display format.

Components of the screen should be correctly placed in all required display environments(corresponding to different size of screens), with the application displaying correctly without obvious errors in all formats.

If the application is supposed to be run ONLY in portrait mode, then the application should be forced. so that it can’t be rotated to landscape mode even after rotating the device too. Even vice versa should be also true.

9. Read time and readability

There should be a enough amount of time for content reading which is available on the screen.

Everything which is present in the application should be in readable font size and type to provide good comforts to the user while using it.

10. Test updates and install/uninstall procedures

Before submitting a mobile app to an app store for release, tester or developer needs to test the app’s update and installation processes.  In this scenario, a previously signed-in user must not be signed out after the update, or the user’s database changes will have no impact on the existing data of the application.

Other remembering points are as follows :

  • Always show eye icon or show button with password editText
  • Always use and confirm password while registering user or with form
  • Disable the operation with editText and confirm edit text.
  • Avoid editText vertical scrolling (if it is not required)
  • Verify the behavior of app, corresponding to app feature which is not supported into lower devices
  • Check the native resource name corresponding to app feature, because many styles of property or methods don’t give any support in lower version devices.
  • Check the layout and its views visibility for lower version devices even with small screen phones.
  • Integrate Fabric for crashlytics (At least before delivering release build version)



Write A Comment