Things to take care of while developing mobile applications

image source: instabug.com

So you are about to build a mobile app. What are some of the important things you must take care of?

Well.. as an application developer who has built various mobile applications over the last 5 years, I feel that one must take care of the followings aspects:

Security:

If you’re not secure, how come your users be?

This is a very wide topic in itself, but there are some basic, important, security aspects that must be considered while building mobile apps.

• What kind of data do we have in our application? Is it some sort of GDPR Data that needs to be kept confidential to avoid legal ramifications? If Yes, then the data needs to be held in a user device or server of a particular region with the consent of the user. Also, there should be a strong purging mechanism to periodically flush out stale or unused data.
• Is there some sort of key to access our APIs? Then we should use KeyStore which resides inside our mobile hardware and helps us protect our data from JailBreak or rooting of our device. This kind of security will be of great use in all finance applications.
• Have we implemented enough level of obfuscation in our code? This is needed so that it becomes hard for intruders to reverse engineer and steal our code. To make such obfuscation, we need to implement Proguard or Dexguard or any such variant for our framework.
• We must implement the SafetyNet Attestation API, which is Google’s API that allows developers to verify the integrity of clients.

Patterns, clean code, and architecture:

Think of every part of your application as a plug & play component

We must always strive to write flexible, scalable, and maintainable code that can help our app evolve as per the client’s evolving business needs.

To achieve this, we can implement clean code and clean architecture principles while building our apps. Architectural patterns like MVC, MVVM, MVI, MVP, BLOC, Provider, etc. help a lot in this regard.

Alternatively, we can implement the vanilla flavor of Uncle Bob’s clean architecture principles in our daily code.

Choosing our libraries wisely:

Copy wisely

As soon as we start coding our application, we come across hundreds of libraries/dependencies/packages to solve our problems. But before we choose any of them, we must answer the following question:

Is this approved by framework developers?

If we’re gonna use some 3rd party code which is approved by our application framework provider like Google for Android or Fluter.Dev for Flutter, then we can use it safely as it has been tested and verified beforehand. Otherwise, if the library is not approved, we must check things like -

• how many issues are open in the library
• open issues list vs issues solved
• frequency of questions answered by the community.

Screen resolutions:

Not all fingers are the same size

So many devices, so many screen sizes… it’s very difficult to know whether our app’s UI will be perfectly compatible with every individual end-user’s device 🙂

Even though we build the app for the most popular/common screen sizes, we might find it difficult to fit our UI into all.

However, to achieve this cross-screen compatibility, the following things can be done:

• Most frameworks have a predefined structure to put our UI elements. For e.g Android has layouts like hdpi xhdpi xxhdpi etc. We should use them and design our UI to be compatible with at least all popular screen sizes.
• We should restrict user device orientation for our application, wherever it makes sense. This reduces our load of creating separate screens for vertical & horizontal orientations.
• We can use APIs like getScreenResolution and create our own screen versions until we pass our UI and get the best fit version for the user device. However, this also comes with a performance impact as it happens at run time and consumes enough CPU. So we must optimize it well.

Storage mechanisms:

Where and how will our app store data? There are a few options.

• Shared Preferences: Almost all frameworks provide Shared Preferences mechanism to store some key information (like key-value pair) without any clutter. However, shared preferences must not be used to store whole user information. This is because our user object is not of primitive type and also, storing whole user data in shared preferences is not that secure.
• Local Storage: There are many popular libraries and APIs provided by framework developers where we can store custom objects and do relational / non-relational queries. This must be used for data that is not getting stale, i.e, data that doesn’t get affected by changes on the server (…e.g. list of your company branches…)
• File Storage: There are instances where we would prefer to store data directly in file and put that file in application memory. These can be anything from cached network images to media files. We must make sure that we keep them only if we need them. Otherwise, we should delete them because they increase our application size on user devices… and users might end up deleting our app.
• Key Store: When we have to store public or private keys, we must make sure it is not compromisable and resides at the deepest vault. Key Store is the best place provided for this by the hardware memory of our device. However, we must make sure that we use it judiciously because it comes with CPU power cost.

Memory vs Bandwidth vs UX:

There is no right recipe

Many times we might want to save our device memory by fetching information from the network, rather than storing it in the device.

However, making multiple network calls has its own demerits. Firstly, cellular data is consumed (bandwidth issues). Secondly, the user might have to make multiple clicks in order to get information in chunks (bad UX).

So what should be the right recipe? What should be the trade-offs?

Well.. it varies from application to application, but a few points below may help us:

• Memory vs bandwidth: As we discussed above in the file storage point, memory is one of the key factors for users to decide our application’s fate. On the other hand, if you rely more on local data, then our data might become stale and provide misleading information. So, memory should be the last thing that we must compromise with. For e.g. I will store information like “a list of branches of my company” in my local device as it is less likely to become stale frequently. However, I will not save information like “user account balance” in my local device as it can get updated very frequently.
• Bandwidth vs UX: As we know, almost all device manufacturers and popular frameworks show users how much bandwidth a particular app is consuming. Hence, it is a primary factor in deciding an application’s success/failure. To save bandwidth, we should take information from the server only as and when needed. For example, let’s take a movie app that shows a list of movies. Now, instead of fetching all details of a movie at once, we will try to fetch and show in chunks only a few details, like the overview, star cast, and user reviews. This will ensure that the customer is not spending unnecessary bandwidth on information that he may not require. At the same time, to ensure good UX, we must ensure that the user does not have to do too many clicks (ideally, not more than 3) to get the info he needs. So, for e.g, in case a user needs to add new reviews for a movie, I will not ask him to jump to a new screen. Rather I will show a popup input dialog to add a new rating.

Of course, there are various other metrics to consider as well, but these are a few points that I feel are key to building a good mobile application.