4 Things to Keep in Mind for Your Next Android Project

Building Android applications for commercial use has become much easier, if we compare the development process to the previous years. We have seen many frameworks developed, refined and widely used. There are a lot of ways we can improve our app development process, for example, by using project management and collaborative interface design tools. But no matter how advanced and efficient tools are used, the key part is still planning and understanding the issues we may encounter during development.

In this article we will look at some of the key points and issues development teams should consider when building an Android application.

Short deadlines and time constraints

As in every development project, we have to consider the amount of time or deadline we have for the current project. If there is a very short deadline, planning and sticking to it is the most crucial part to ensure the success of the project. It is important to not go overboard in terms of requirements of what can be done in a given amount of time, otherwise the application will not be scalable and will be hard to maintain. Namely, code is written at a fast pace without doing code reviews and overall sanity checks to validate if the implemented functionality is correct.

When faced with a short deadline, depending on the size of the app we want to build, it is essential to have concrete requirements in place in order to meet the deadline. Doing rapid design and requirement changes during development is the worst thing that can happen in any development lifecycle. The task for the developer becomes many times harder. This is firstly because these changes are not as well documented as initial requirements, so the developer can miss a feature or have to add additional cognitive load to work capacity, which again, can lead to a worse code base and slow down overall development. Secondly, doing code refactoring has to be done slower than initial development of a feature, because the developer has to go back to already done code. At this point, some key things about that particular part of the app might have been forgotten, which may bring some regressions. Keeping track of these refactorings becomes even more complicated, especially if they need to be passed to the testing team.

If there is little possibility to consult with developers on requirements, the following will guide you through the two most crucial points—differences between Android API levels and hardware.

Different API versions

API level is a value that represents the framework capabilities offered by the Android platform. Every level includes separate set of packages and classes, various kinds of XML elements for declaring attributes in manifest and resources, a set of intents and, last but not least, a set of permissions an application is required to have and a set of available internal APIs that an application can have (such as accessing WiFi state). Android devices will have different maximum API levels depending on the device’s manufacturer and age. To put it simply, application capabilities for different devices can vary quite a lot, which means that the app features and design must be made according to what is supported. To better understand on what scale applications can be limited with a new API level release, let’s take a look at an example of a permission update introduced in Android 11.

Tracking nearby devices through WiFi APIs and Bluetooth devices can show where the user is located. For that reason, it was decided that no Bluetooth or WiFi scan results can be accessed from Android 11 devices without location permission. This caused one major problem—Play Store users did not know about these API changes, so when they saw that the app asks for their location to scan for bluetooth devices, they added bad reviews and in some cases even deleted the app. As mentioned before, we could limit this behavior by addressing only the Android APIs which were affected by this change. Fortunately, for this particular API change, Google has introduced a permission group called Nearby devices in Android 12, which lessens the confusion on the user base.

Android API and permission changes are very frequent. They can sometimes limit an app's capabilities quite extensively, which means developers need to keep track of updates and communicate with management about potential problems caused by that update. It is important for the management and design team to work together with developers on the design phase to limit UI/UX revisions in later stages of the development lifecycle.

Tip: With lower API versions, developers have much more freedom with how they can implement various features that use bluetooth, WiFi, location and camera. To ensure the best user experience for as many users as possible, research on API capabilities can be done and according to that research different application flows and designs can be made for specific API versions.

Writing and running tests

Testing is one of the project lifecycle’s fundamentals. It has many benefits and helps developers a lot. There are a couple of ways we can do testing during the app’s development.

One is to write Unit/UI tests in the app itself. This is crucial because the code usually has a lot of connected elements in itself and by changing one part of the code we could have a regression. Unit/UI tests help assure developers that no other part of the app was broken during feature development. But there is an issue—it takes a significant amount of time to write Unit/UI tests. They are tricky and have to be written correctly. Incorrectly written Unit/UI tests will give false negatives or positives and will mislead developers. That is why it is important to take time and allocate resources to write them qualitatively. For very small or time limited projects, it might be more sufficient to not write them, as there is not much to track. But when the codebase starts to scale up, let’s say, nine screens plus additional utility code, networking and persistence, it becomes really tricky to know whether the developer has broken anything or not. It will take more resources to test and go back to the code to fix it, rather than writing a test for it.

Another way of testing is to give the application to manual testers and codebase to the automation team. When doing manual testing, it is important to have variety, like different Android APIs and screen sizes. As mentioned before, there are a lot of different Android devices, and they all should have a good user experience.

Tip: For the best variety, acquire devices that are large (tablets and larger phones), medium (standard phones), and small (smaller phones) to cover all screen sizes and verify that the layouts scale properly. For each size category, it would be beneficial to test with at least three APIs—the newest and lowest API set in the project, and one that is between the newest and lowest.

Test automation (done by QA) is a more refined process of writing more complicated UI tests and their primary purpose is to test user stories. Although developers cover some parts of user stories by writing Unit/UI tests, they are not written according to actual user stories. Knowing that the app flow is based on all user stories is crucial, as an incorrect user flow can lead to a bad user experience. These tests are usually written after a full app release. When planning, it is necessary to include time for fixing bugs and issues found in testing.

Requirement testing allows engineers to find issues in early stages of the development lifecycle and limit any refactorings afterwards. This kind of testing is very effective because it takes significantly less time to check requirements rather than refactoring them later.

Having testers work closely with system designers while the system is being designed can increase each party’s understanding of the design and how to test it. This increased understanding can reduce the risk of fundamental design defects and enable tests to be identified at an early stage. (ISTQB Foundation Level Syllabus)

Although the quote above is meant for testers, we can still apply the same principle to the developer-project manager relationship. Having developers review requirements together with the design and management team allows them to have more clear and tangible results, which leads to a better and faster development process.

Fun fact: According to recent statistics from Business of Apps, Android has over 2.8 billion active users with a global market share of 75 percent.

Dependency on other resources

Applications usually consist of some kind of backend or SDK implementation. Having a complete or at least completely planned backend helps developers to plan their implementation of that backend.

Same as UI/UX requirements, poorly designed backend can lead to lots of headaches on the app side. For example, app developers will need to write a wrapper function if the API response sends a JSON object containing a list of ints as one string where each element is separated by a comma instead of just returning a list of integers.

The previous sentence already sounds complicated (although there is very little difference in the image above) to non-developers. Now try to imagine explaining the issue to the manager. This is such a headache and simply drains all the patience from developers. Minor issues like these compounds and lower developing effectiveness.

Another obvious but important step is to make sure the developer has everything they need to code the app. For example, if the project consists of pairing a bluetooth device with a phone, and there are both iOS and Android developers as well as a tester, there should be three bluetooth devices provided to that team. Having only two devices in this case would slow down development significantly. If the app has an instant messaging feature, the developer will need multiple devices to test if the functionality is correct. If devices are not available, then emulators can also be used.

Lastly, it is almost impossible to work effectively on a low performance station when there are two and more emulators running at the same time and while Android Studio is running. Developers in this case will ask either for better work stations or physical devices.

The bottom line

When working on an Android development project, it is essential to focus on time, APIs, testing, and available resources.

Make sure you stick to deadlines and create an efficient plan for you and your team to follow. You also need to be aware of the different API versions and be up to date with any changes made to them. When it comes to testing Android applications, make sure a variety of tests are written and carried out properly. Finally, be mindful of possible issues that may appear during development and keep them under control.

Have you built or are in the process of building an Android application? We can help make sure your application meets all the requirements by providing a range of quality assurance services. Contact us with details about your project and find out how we can help.