in Android Security, Android Studio, Best Practices

Do’s and Don’ts for Building Better Android Apps

Buildings apps are challenging. Building apps are rewarding. It’s fun. It’s creative. But something else too is very true: building better Android apps or iOS apps is hard. Like, incredibly hard. The reasons are simple: apps are not simple series of pages (like HTML) where the user will keep following links have a happy ending. A typical app today has access to critical system resources and needs to manage communication and what not while doing its primary job. And then there are so many screen sizes and real-world cases to cover. In a nutshell, it has all the challenges of traditional software development, and then some (or many!).

If you’re an Android app developer, it’s time you started following a stringent set of guidelines for building better Android apps. We even suggest taking a printout and pasting it at your workstation to make sure you never miss a single critical quality check.

What to do for building better Android apps

#1 Use Android Studio

Do you have a favorite editor other than Android Studio that you’ve been using to build Android apps? Do yourself a favor: drop it. Yes, we understand that your favorite IDE is your first and last love and that you are might productive on it (after all, you know all the keyboard shortcuts!). But there’s a stronger reason in support of Android Studio: it was built to make app creation easier. For instance, one of the conveniences Android Studio adds is the Gradle build system. Out of the box, Gradle does everything Maven can (and Ant can’t), and includes awesomeness like ‘demo’ and ‘paid’ app flavors, APK splits by screen density, etc.

The list is too long to get into here, but Android app development will be ten times easier if you quit struggling and just adopt Android Studio. And that applies even if you’re an IntelliJ IDEA user!

#2 Create re-usable UI elements

Several of the UI elements in an app get reused over the lifetime of the app. That is, they should be reused in the proper sense of software engineering. Instead, what we have are developers copying UI XML data from other parts of the app and pasting where they see fit. And thus begins a vicious cycle of updating code at multiple places and chasing bugs that end in a battle you just cannot win.

The solution? Define reusable components in their separate XML files and use the magical <include/> tag to pull them right in when they’re needed! Granted, thinking through which elements are going to be reused and need to be saved separately can be punishing work, but consider how fast and easy it will make the rest of the redevelopment, especially when the inevitable happens and the clients asks you to make sweeping changes to the UI.

#3 Use shapes and selectors over images

Images are nice, without a doubt, but most of the simple shapes and ideas they represent can be easily programmed using the <shape/> tag in Android. The advantages are exactly that of bitmap vs. vector drawing: if you have a <shape/> in your Android app, it will render with perfect accuracy irrespective of the screen size and density.

If you’ve done any Android development yourself, you know what a nightmare it becomes to detect the current pixel density and make sure you have images for all possible scenarios.

#4 Integrate security plugins

Security is the most important and most neglected aspect of app development. After all, your mind is abuzz with the awesomeness of the amazing app you’re about to finish and the accolades that will roll in once it is published. In all this race to stardom, who has the time for something as stupid-sounding and jaded as security, right?

But you know if your heart that security is important. You only wish that it weren’t so damn difficult to get right. Guess what! Now there are plugins that integrate straight in your IDE and can perform code analysis for possible security holes. One such plugin is Devknox. The great thing about Devknox is that it not only tells you what problems exist in your code but also provides suggestions on how to improve things!

With such productive plugins around, the mention of security shouldn’t elicit sighs and groans anymore.

#5 Read the documents

Getting as familiar with documents as possible is not a waste of time. On the contrary, the deeper you dive into the official documents, the more you’ll come to understand the appreciate the Android platform. This will help you innovate in ways you never thought possible and will improve your skill as well as your career prospects. The best part is, Android has stellar documentation. Very few projects come close to Android in providing documents that are this fresh, beginner-friendly and comprehensive.

For instance, Android itself provides a first-class list of best practices that can take much grief out for your users. From native C++ development to UI best practices, the docs have everything!

So far it was about a few things that you must do. However, the road to building better Android apps doesn’t end with what to do. Equally important are things you must not do, else the app can fall apart very easily.

What not to do for building better Android apps

#1 Perform file operations in the UI thread

File operations are important in any app; the problem is when they’re performed in the UI thread. Because a file can be arbitrarily large and access can be choppy due to various reasons, reading/writing in the UI thread can cause the UI to hang or simply crash.

Such intensive tasks are better performed in workers with the help of AsyncTask/Loader. Once the worker has finished its job, it will send an asynchronous reply, resulting in smoother user experience.

#2 Add entire Google Play library to your app project

It can be tempting to add the Google Play library to your project. After all, it’s jam-packed with useful services that can make your life easier. But there’s also a downside: the Google Play Services is a massive library containing several smaller components. Some of these you are probably not going to use in your app, such as Google Awareness, Google Cast, Google Fit, Google Panorama Viewer, etc. But if you add the entire library, your app size will swell for no reason.

Better to figure out which components you want in your app, and add only those. It is better to add components individually, as it gives you more clarity and flexibility on the app.

#3 Overload your app with ads

There’s no better way to alienate users and plummet your credibility than to make an app that showcases those super-irritating full-view ads. How many ads you decide to put in your app will affect your reputation in the eyes of the users, and will have a direct impact on the percentage of users you are able to successfully monetize (through in-app purchases and premium versions, for example).

Another very strong reason not to go all-guns-blazing is the earning potential. If you look through some answers on Quora, you will see that on average, developers make $10-$20 a day through ads. In our opinion, it’s better not to kill the hen that lays the golden egg, and instead provide high-quality apps to build a following first.

#4 Get “creative” with standard UX principles

A good user experience doesn’t result from dazzling flashes of insight the product designer gets in the middle of the night; instead, good UX flows from strictly following the known principles of the design flow. For instance, you might feel like a genius for inventing a new gesture for your app – for example, swiping counter-clockwise to go back – but imagine what a cognitive overload it will be for the end user. Right means right, and attaching right-swipe to “next” and left-swipe to “back” is not only sensible but highly recommended.

Similarly, do not over-experiment with visual elements. Keep things simple, follow the Material Design Guidelines, and let your creativity be unleashed in how effortlessly the app delivers the solution it’s supposed to deliver.

#5 Use libraries with too many methods

You might feel a tinge of satisfaction as you add another library to your list of dependencies, but there’s a danger lurking underneath: the famous 65k function reference limit in the Dalvik Executable inside the APK files. Google has a nice, long writeup on it, but the long and short of it is that your app absolutely can’t have more than 65,000 methods at a time. The docs list ways to bypass the method limit but think twice before doing that.

If there are so many methods in your tiny app, something is wrong. Looks for which parts of the code are bloated and can be removed. A popular example on forums is the caution against using the Guava library, which alone has over 13,000 methods!

If your head is spinning by now, you have our sympathies. Yes, nobody said it would be so hard, but now you know. Remember how we began this blog by asserting that Android app development is hard? By now you have a glimpse into the abyss that is app development. But, hey! We would be remiss if you walked away from this as a discouraged developer. The point is that app development is getting more and more complex and should be seen as it is – a thing of responsibility – rather than through the colored lenses of foolish enthusiasm that makes us want to believe that the app can be delivered “over the weekend”.

Don’t let the complex landscape of app development bring you down. 

#CodeResponsibily #CodeEffortlessly #CodeSecure

Try Devknox