Key android developer best practices to keep in mind.
Published: 2020-01-15 10:43:00

Hello Coders!

So, today I'll be talking about best practices to adopt as an android developer. Keep in mind that it's all about simplicity, readable code, and most important other developers might end up maintaining your code. I've summarized some of the key practices as follows, I thought it would be helpful.

## 1. Project structure.
When starting a new project, Android Studio automatically creates some of these files for you, as shown and populates them based on realistic defaults.
![Project structure img](https://thepracticaldev.s3.amazonaws.com/i/28hq8zwl8ys4w7wmln08.png)

## 2. Keep your colors.xml short and clean, just define the palette.
There should be nothing in your colors.xml other than a mapping color name to an RGBA value. This helps to avoid repetition of values thus making it easy to change or refactor colors, and also will make it explicit how many different colors are being used. Normally for a aesthetic UI, it is important to reduce the variety of colors being used.
### DON'T
```
<resources>
    <color name="button_foreground">#FFFFFF</color>
    <color name="button_background">#2A91BD</color>
</resources>    
```

### DO:
```
<resources>
    <!-- grayscale -->
    <color name="white">#FFFFFF</color>
   
    <!-- basic colors -->
    <color name="blue">#2A91BD</color>
</resources>
```


## 3. Also keep dimens.xml clean, define generic constants.
You should define a "palette" of typical spacing and font sizes, for basically the same purposes as for colors. A good example of a dimens file:
```
<resources>

    <!-- font sizes -->
    <dimen name="font_larger">22sp</dimen>
    <dimen name="font_large">18sp</dimen>

    <!-- typical spacing between two views -->
    <dimen name="spacing_huge">40dp</dimen>
    <dimen name="spacing_large">24dp</dimen>

    <!-- typical sizes of views -->
    <dimen name="button_height_tall">60dp</dimen>
    <dimen name="button_height_normal">40dp</dimen>

</resources>
```

You should use the spacing_**** dimensions for layouting, in margins and padding, instead of hard-coded values, much like strings are normally treated. This will give a consistent look-and-feel, while making it easier to organize and change styles and layouts.

## 4. Do not make a deep hierarchy of ViewGroups.
 * Sometimes you might be tempted to just add yet another LinearLayout, to be able to accomplish an arrangement of views. Take a look at this case:
 ```
 <LinearLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    >

    <RelativeLayout
        ...
        >

        <LinearLayout
            ...
            >

            <LinearLayout
                ...
                >

                <LinearLayout
                    ...
                    >
                </LinearLayout>

            </LinearLayout>

        </LinearLayout>

    </RelativeLayout>

</LinearLayout>
```

 * A couple of problems may occur. You might experience performance problems, because there is a complex UI tree that the processor needs to handle. Another more serious issue is a possibility of errors because of too many nested layouts.

Therefore, try to keep your views hierarchy as flat as possible: learn how to use ConstraintLayout, how to optimize your layouts and to use the ***<merge>*** [tag](https://developer.android.com/training/improving-layouts/reusing-layouts).

## 5. User Experience.
* It's the context of satisfaction of a user’s interaction with your app. Some notes to improving the experience of your apps:
    ### 1. Excellent UI.
    To have a a excellent feel and experience of an app starts with a good design that matches the Google material design principles.
    * Consistency in color combinations. For this case use [Material Design Color Tool](https://material.io/resources/color/)
    * Use of proper icons to portray functionality. Use [Material Design Tool](https://material.io/design/introduction/#)

    ### 2. Configuration Change Handling.
    This is the most annoying scenarios android developers face. When you rotate your device and the screen changes orientation, Android usually destroys your application’s existing Activities and Fragments and recreates them. This is done so that the application can reload resources based on the new configuration and this is basically like starting afresh. Improper handling of this scenario is an instance of bad user experience. Below are some solutions to this:
    * With the [ViewModel](https://developer.android.com/topic/libraries/architecture/viewmodel.html) as part of the [architecture components](https://developer.android.com/topic/libraries/architecture/index.html) released by Google.
    Below, is an image that shows the life-cycle of an Activity as compared to that of a ViewModel.
    ![viewmodel-lifecycle](https://thepracticaldev.s3.amazonaws.com/i/hhvv3qt40b323q7qik1h.png)

    * consider is persisting your data in the database after it has been fetched from a remote source so that when the phone is rotated, data can quickly be gotten from the database instead of having to fetch again.
    
## 6. Compatibility.
There are two types of compatibility: device compatibility and app compatibility.
* Device compatibility. Because Android is an open source project, any hardware manufacturer can build a device that runs the Android operating system.
* App compatibility. Because Android runs on a wide range of device configurations, some features are not available on all devices.
    
## 7. Understand build process.
The build process involves tools and processes that convert your project into an Android Application Package (APK) so it's important to understand.
![build-process](https://thepracticaldev.s3.amazonaws.com/i/mmp0fvz9rx68vu9pymyl.png)

* The compilers convert your source code into DEX (Dalvik Executable) files, which include the bytecode that runs on Android devices, and everything else into compiled resources.
* The APK Packager combines the DEX files and compiled resources into a single APK. Before your app can be installed and deployed onto an Android device, however, the APK must be signed.
* Before generating your final APK, the packager uses the zipalign tool to optimize your app to use less memory when running on a device.

## 8. Security & Privacy.
Security is one of the most neglected areas when building apps because it is large in scope and it's almost impossible to perfect. Google has released features that significantly reduce the frequency of security issues. Some of which include:
* Google play protect: this is built into every device with Google Play to automatically take action to keep data and device safe.
* Encryption from Android M to protect user data.
* SafetyNet attestation: evaluates if an Android device is a certified secure .
* reCAPTCHA for Android: This ensures that an app is not automated i.e handled by a robot.

However, notice that some security vulnerabilities are out of their control like:

### Communicate Securely with a Server.
* At some point our apps needs to communicate with an APIs and back-end services to fetch data or send data which should be done in a securely. On that note, [Network security configuration](https://developer.android.com/training/articles/security-config.html) was introduced to ensure adequate validation of the servers our apps intend to communicate with.
* If you are building a social app or anything related that requires authentication and user management, you could use the service provided to us by Auth0 to manage our identities while you focus on other functionalities which uses a secure protocol.

Below is a generic workflow of the protocol.
![oauth2-generic-flow](https://thepracticaldev.s3.amazonaws.com/i/pizuj3pkfsqc7fwppfim.png)

      
## 9. Keep the Long Running Tasks Away.
* Use a background thread for all long running tasks. Doing this counts for a better performance and better user experience in the long run.
* Android Studio provides us with the profiler to check the performance of our app while still in development. The profiler helps us gauge the device’s resource usage of our app during execution. It is usually located at the bottom of your screen and only shows up when the app is running.
![android-profiler](https://thepracticaldev.s3.amazonaws.com/i/neycx4pe07kgzept2jmz.png)