The 16-year full-stack developer’s Android development pit record

Author | Stephan Miller

Translator｜ Ma Kewei Planning｜ Tian Xiaoxu This is a story with a complete aftermath. As a full-stack web developer with almost sixteen years of development experience, the author knows all the technologies required to build web applications. In recent years of work projects, the author became an Android developer for the first time. After a period of running-in, the author realized that the developer’s thinking also needs to be transformed from web development to Android and mobile application development. Most of the wrong paths for the newbies of Android development can be solved by refactoring or modifying the build process in the later stage of the project, and continue to polish until the unit test perfectly covers all the situations required and can also handle some small errors. But the rest of the missing fish are not so easy to solve. These are enough to have a lasting impact in the life of the app and make people want to overthrow the entire project. Some of the mistakes even make the author ashamed to say that he has made mistakes. Pass them. The following will provide some tips to prevent the time paradox (laughs) when you want to go back to the past and redo the project. I hope it can help you prevent the bad troubles that are hard to get rid of. Add in-app update immediately. It wasn’t until a year after it was released that we plugged the update notification function into our app. If the built-in update reminder function is added at the beginning of the project, then the process is fairly simple, but if it is delayed until later, it will inevitably cause a lot of problems, including: the need to build a custom process manually, and the user to try it on his own Skip the update. Believe me, this feature will be a breakthrough change for your app. Existing users of the app may have become accustomed to the in-app update function through other apps, and even take it for granted that this should be one of the features of the mobile platform. But in fact, it wasn’t until I personally experienced Android development that I knew that this feature had to be manually added by the developer. When your app unfortunately stops running, users will not look for software update packages, they will only uninstall and then install them, or even worse, they will leave comments in the app store. Restrict API key Let the program run first, and then apply a patch if something goes wrong. Maybe you also have this habit, but please don’t continue to delay. Point out an article about API keys on Google Cloud Platform, but for other platforms, the same applies. For GCP (Google Cloud Platform), we only need to log in to the Google account and select the API key to be restricted, and the system will jump to the key attribute interface. Select the Android application in “App Restrictions” and click “+” to add the package name to the API key that needs to be restricted. As for adding certificate fingerprints, you can directly copy the commands on the page and follow the instructions on the right side of the page. It only takes a few minutes to complete. We only started restricting API keys two years after the app was shipped. However, after the restriction, a map function of the app went on strike. After rolling back the changes, it took us a lot of work to find the problem. Most of the official Google software packages used by the app can be perfectly adapted to the code behind the restricted API key. Only one of the maps needs to rewrite the other set of API call codes. If we can consider the limitation of the API key at the beginning of the project and write it into the source code, this will undoubtedly increase the development time, but in the later stage, we can no longer worry about the limitation. The story does not end here. In order to ensure the normal operation of the map and limit the API key, we have to perform a mandatory update. We have background statistics to monitor the user’s update process, and the data shows that 90% of users update only a few weeks after receiving the update notification, while the other 10% still choose when the map is almost completely out of order. Without updating, I don’t know how they endure this kind of bug. Internal API version control When I was still focusing on web development, I never understood why someone would want to do this. After updating the front-end code, why keep the old version of the API? No matter how you think it is useless waste. However, when the software version used by the user is different, a major update of the API may cause a large-scale software crash. The method of in-app update can help alleviate this problem, but the process will be extremely long. Dividing API versions is more like a quick and simple solution for this kind of software crashes, rather than over-engineering as I once thought. Want to go offline beforehand Our app has practical goals. When we received feedback from users that the app reacted stuck and the response timed out, I was just a novice in mobile app development, and I just came across a new term: Offline First. If the user fails to connect to the Internet, all unuploaded and unsaved things will be lost, and when the connection is restored, they will have to re-enter all the content. The priority offline structure will write the changes to the local database, and then synchronize when there is a network connection. In this way, the user can use the app offline, and the response will be faster when connected to the Internet. The user no longer has to wait for the server to send back a response before proceeding to the next step. The offline priority function may be more difficult to implement in the later stage of the project. The difficulty depends on the complexity of the app’s data. So please decide as soon as possible whether the app needs it. We are still studying how to better implement this feature in our “old age” app… Choose navigation items carefully If your Android app has a complex structure and many interfaces, it will be more troublesome to modify the navigation items in the later stages of the development process. Our app was directly changed to the form of bottom navigation in the later period. In some situations, the Activity in Android development can be regarded as the code of a certain screen in the app; Fragments, which are only available in Android 3.0, can be understood as the subview code or part of the code in the app. The layout of both is defined through XML. Our navigation points to the main functions in different areas of the app, and these small navigation cards each lead to different sub-functions, connecting more than 30 activities in total. These are just four fragments in this Activity-based app. Navigation drawer is another common navigation form, the main service object is the navigation needs of Activity docking with Activity form. Bottom navigation Because the bottom bar of the app is always visible, its design object is fragment navigation. After adding the bottom bar to the Activity, then we only need to type its related code into the Activity and add its view to the layout of the Activity. In this way, by clicking the button on the bottom sidebar, we can load the fragment into the Activity. So, in order to add the bottom navigation bar in the app, I tried to convert Activity to fragment. The result was very tragic. Excessive bugs directly caused the software to crash and wasted a month of my time. If we only have five or six activities, it may not be too difficult to solve, but in fact our app has more than 30 activities! This directly led me to give up other work this month and focus on adding navigation functions to each Activity. I also tried to create a helper function, but this did not save me much trouble. In the end, I still have to write code for the Activity one by one. At the same time, I also need to add the bottom sidebar to all layouts and make room for this little guy in the existing layouts. In addition, the Activity stack must be programmed to prevent race conditions. Although the process was cumbersome, it was successful in the end, and the effect was not bad. It’s just that if I can add the bottom navigation bar at the beginning of the project and start the design based on the fragment, it will be much easier. This is just an incomplete list… Of course, there are many other things to consider when starting your first Android application, such as adding unit tests, not changing the mode of an app after determining it, and so on. But if you have been exposed to other types of development models before, these should be familiar to you. Maybe you will not encounter exactly the same problem as mentioned in the article, but I am afraid it will not be too different. Hope these little tips can help you realize that Android development is very different from other types of development, and the influence of these development decisions may last for a long time. https://triplebyte.com/blog/everything-id-do-differently-if-i-could-go-back-and-rewrite-my-android-app-today