10 mistakes I made, these 3 years of Android App Development (Part 1)

Being in the field of Android app development from past 3 years and being a self taught developer, I was writing messy, non-standard and terrible amount of code. Although I progressed alot, but I did a lot of native mistakes.

“An expert is someone who knows some of the worst mistakes, which can be made, in a very narrow field.” — Niels Bohr

I ain’t claiming that I am an expert Android Developer, although I am following the best practices and trying to share my experience in my words.

  1. Not structuring your Project

While creating project initially we always start creating classes in the main package, which is wrong. New project should follow the Android Gradle structure that is defined on Android Gradle plugin user guide. You can also find a boilerplate of the structure here.

All in all, ordered from the closest-to-backend to the closest-to-the-user:

├─ network
├─ models
├─ managers
├─ utils
├─ fragments
└─ views
├─ adapters
├─ actionbar
├─ widgets
└─ notifications

2. Wrong naming convention

To increase the readability of your code you must follow the standard naming convention and should adopt this standard throughout your project. File naming conventions must be followed correctly to increase the understandably of your code. Following are some guidelines for naming convention of files.

  1. Class names should be written in UpperCamelCase.
  2. For classes that extend an Android component, the name of the class should end with the name of the component; for example: SignInActivity, SignInFragment, ImageUploadService,ChangePasswordDialog.
  3. Resources file names are written in lowercase_underscore.
  4. Layout files should match the name of the Android components that they are intended for but moving the top level component name to the beginning. For example, if we are creating a layout for the SignInActivity, the name of the layout file should be activity_sign_in.xml.
  5. Naming convention for drawables should start with some prefix for example an Action bar drawable named with prefix ab_ as ab_stacked.9.png.
  6. Naming convention for icons should start with some prefix ic_ for example an ic_star.png.

You can find a well documented file naming convention guideline here. For XML naming convention you follow this guideline.

3. Targeting wrong SDK versions

According to the Official Reports of Android, by targeting API 16: Android 4.1 (Jelly Bean) your app will run on approximately 95% of the devices that are active on the Google Play Store. While starting project try to target the OS that are mostly in use of Android users.

4. Using Deprecated APIs

“I am getting back to work on an app, I worked on a while ago, when I had everything built around Android 2.2 Froyo. I have updated my SDK for the latest APIs and noticed that the ClipboardManager features I was using are deprecated. I updated the code to use the newer ClipData model and tried it out on my Froyo phone and, of course, I get a NoClassDefFoundError in the new code.I’m not entirely sure how I should handle this and other situations where the API differs, because I want users of all versions to be able to use my app.

You shouldn’t worry about using deprecated methods as all Android versions are backwards compatible, saying that you want to watch when things are for 3.0 Honeycomb as these are a little different. BUT putting a check with respect to the OS version can help you avoid using DEPRECATED APIs. Foe example if(Build.VERSION.SDK_INT>=Build.VERSION_CODES.LOLLIPOP)…

5. Writing every method in Activity or Fragment classes

One of the common mistake we all do in our early stage of learning Android development is we write each and every method in the Activity or Fragment class. I did it too, and the result were terrible code base. It decreases the readability of the code.

Better to create a separate package named utils and add utilities classes to it. For example adding StringUtilities,FieldValidationUtilitiesand so on. Not only this makes your code look cleaner, but also increases reusability of your elements and methods, which ultimately saves time in the future.

6. Not using VCS tool for your codebase

This is also on of the common mistake we all do at beginner level of the development. The uncertainty of technology may lead you to zero. Incase of power or memory failure you may loose all your source code. Taking local backups in folders and appending dates to the name of the folders may confuse you later while checking the code.

Start using Version Control System like Git or Mercurial to safely store your source code. I personally recommend Git as it’s mostly commonly use by the community. Platforms like Github and Bitbucket provides cloud base source management and collaboration features.

If you are not welling pay the monthly fee Github you can apply for the student package, while Bitbucket provides free service for upto team of 5 members.

7. Writing Permission Code

Beginning in Android 6.0 (API level 23), users grant permissions to apps while the app is running, not when they install the app. Initially I was avoiding the permission code and by setting the targetSdkVersion to less than 23, which is was like hiding a fault form yourself.

Later I discovered many ways to handle the situation. You can find a google code sample here. There are 3rd party libraries available for handling the permissions while the app is running. Libraries like Dexter, PermissionDispatcher and Grant can be helpful. On of the best way to handle the permission to avoid writing length code you use Permission Dispatcher Plugin.

8. Securing Code from thieves

Once I worked on an app, launched it on play store and very proudly I claimed that I wrote an algorithm that can perform XYZ analysis. Next week I found my app source code on a website. WTF I just said it and start worrying about my other apps which I thought were secure intern of source-code but they weren't.

Please start using Progaurd before someone steal your idea, code base and money. It not only secure your app but also optimizes and shrink the application.

9. Configuring Build Variants

You can create and configure build types in the module-level build.gradle file inside the android block. When you create a new module, Android Studio automatically creates the debug and release build types for you. Although the debug build type doesn't appear in the build configuration file, Android Studio configures it with debuggable true. This allows you to debug the app on secure Android devices and configures APK signing with a generic debug keystore.

I used to add release, beta, debug and qa variants of my app that can be easily managed and build instantly of demand.

A sample of Build Variants Block from Gradle

10. Jack of IDE or Master of IDE

Android Studio is the official tool for Android development these days. Being developed at the top of project IntelliJ IDEA, takes into advantage (almost in its entirety) features of edition, debugging, analysis, refactor among many other categories for developing in an effective way.

Mastering the IDE is an essential step for learning the development language and getting most of the IDE can help to develop the app faster. Efficient usage of IDE saves your time and efforts.

This training might help you to become proficient and productive in Android applications development.

P.S Recommend it to someone who is newbie or would like to start his career as Android Developer.