Top Common Mistakes Done by Android Developer
Android. What’s not to like about this platform? It’s free, it’s customizable, it’s rapidly growing and it’s available not just on your phone or tablet, but on your smartwatch, TV and car too.
With the latest Oreo update, Android programming continues to improve. The platform has matured quite a bit since the initial AOSP release, and set the user expectations bar quite high.
There are thousands of different devices, with different screen sizes, chip architectures, hardware configurations, and software versions. Unfortunately, segmentation is the price to pay for openness, and there are thousands of ways your app can fail on different devices, even as an advanced Android programmer.
Regardless of such huge segmentation, the majority of bugs are actually introduced because of logic errors. These bugs are easily prevented, as long as we get the basics right!.
I am gone tell all those mistakes which you can avoid while development.
1) Developing for Your Android Device:
Unless you are building a kiosk/promo app for a single tablet, chances are your Android app won’t look good on every device. Here are a few Android programming tips to remember:
Density-independent pixels (dp) are different than normal pixels (px).
Resources are included multiple times to account for different densities and orientations.
9-patch drawables are stretched to fit the screen.
There are literally thousands of possible scenarios, but after a while you develop a sense for covering them all with a handful of cases.
You don’t own thousands of devices? Not a problem. The Android Emulator is super good in replicating physical devices. Even better, try out Genymotion, it’s lightning fast and comes with a lot of different popular preset devices.
Also, have you tried rotating your device? All hell can break loose…
2)Not Using Intents:
Intents are one of Android’s key components. It’s a way of passing data between different parts of the app or, even better, different apps on the system.
Let’s say you have a gallery app that can share a download link to some images via SMS. Which of the two options seems more logical?
Option 1:
Request the SEND_SMS permission.
<uses-permission android:name="android.permission.SEND_SMS" />
Write your own code for sending SMS using the SmsManager.
Explain to your users why your gallery app needs access to services that can cost money, and why they have to grant this permission to use your app.
Option 2:
Start an SMS Intent and let an app designed for SMS do the work
Intent sendIntent = new Intent(Intent.ACTION_VIEW);
sendIntent.setData(Uri.parse("sms:" + telephoneNumber));
sendIntent.putExtra("sms_body", x);
startActivity(sendIntent);
In case that you have any doubts, best solution is option 2!
This approach can be applied to almost anything. Sharing content, taking pictures, recording video, picking contacts, adding events, opening links with native apps, etc.
Unless there is a good reason to make a custom implementation (ex., a camera that applies filters), always use Intents for these scenarios. It will save you a lot of programming time, and strip the AndroidManifest.xml of unnecessary permissions.
3)Not Using Fragments:
A while ago in Honeycomb, Android introduced the concept of fragments. Think of them as separate building blocks with their own (rather complex) life cycles that exist inside an Activity. They help a lot with optimizing for various screens, they are easily managed by their parent activity, can be reused, combined and positioned at will.
Launching a separate activity for each app screen is terribly inefficient, since the system will try to keep them in memory as long as it can. Killing one won’t free the resources used by the others.
Unless you want to dig deep into the Android core and read this article, advocating against fragment usage, you should use fragments whenever possible. It basically says that fragments and cursor loaders have good intended purpose, but poor implementation.
4)Blocking the Main Thread:
The main thread has a single purpose: keeping the user interface responsive.
Although the science behind measuring the frame rate our eyes/brain can perceive is complex and influenced by a lot of factors, a general rule is that anything below 24 fps with delay greater than 100 ms won’t be perceived as smooth.
This means that the user’s actions will have a delayed feedback, and the Android app you have programmed will stop responding. Stripping the user of his control over the app leads to frustration.
Even worse, if the main thread is blocked for a while (5 seconds for Activities, 10 for Broadcast Receivers), ANR will happen.
This was so common in Android 2.x, that on newer versions the system won’t let you make network calls in the main thread.
To avoid blocking the main thread, always use worker/background threads for:
1. network calls
2. bitmap loading
3. image processing
4. database querying
5. SD reading / writing
5)Reinventing the Wheel:
“OK, I won’t use the main thread. I’ll write my own code that communicates with my server in a background thread.”
No! Please don’t do that! Network calls, image loading, database access, JSON\xml\SOAP parsing, and social login are the most common things you do in your app. Not just yours, every app out there. There is a better way. Remember how Android has matured and grown as a platform? Here’s a quick list of examples:
Use gradle as a build system.
Use Retrofit / Volley for network calls.
Use Picasso for image loading.
Use Gson / Jackson for JSON parsing.
Use common implementations for social login.
If you need something implemented, chances are it’s already written, tested and used widely. Do some basic research and read some Android programming tutorials before writing your own code!.
6)Not Understanding Bitmaps:
Users love content! Especially when the content is well formatted and looks nice. Images, for instance, are extremely nice content, mainly due to their property of conveying a thousand words per image. They also consume a lot of memory. A lot of memory!
Before an image is displayed on the screen, it has to be loaded into the memory. Since bitmaps are the most common way to do this, we’re going to provide an Android programming guide for the whole process:
Let’s say you want to display an image on your screen that you just took with your camera. The total memory needed for this is calculated with the following formula: memory_needed_in_bytes = 4 * image_width * image_height;
Why 4? Well, the most common / recommended bitmap configuration is ARGB_8888. That means that for each pixel we draw, we need to keep 8 bits (1 byte) for the alpha, the red, the greed and the blue channel in memory, in order to properly display it. There are alternatives, like the RGB_565 configuration that requires half the memory than ARGB_8888, but loses the transparency and the color precision (while maybe adding a green tint).
Let’s assume you have a brand new device with full HD screen and 12 MP camera. The picture you just took is 4000x3000 pixels large and the total memory needed to display it is: 4 bytes * 4000 * 3000 = 48 MB
48 megabytes of your RAM just for a single image!? That’s a lot!
Now let’s take the screen resolution into consideration. You are trying to show a 4000x3000 image on a screen that has 1920x1080 pixels, in worst case scenario (displaying the image full screen) you shouldn’t allocate more than 4 * 1920 * 1080 = 8.3 MB of memory.
Always follow the Android programming tips for displaying bitmaps efficiently:
Measure the view you’re showing your images in.
Scale / crop the large image accordingly.
Show only what can be displayed.
7)Using Deep View Hierarchy:
Layouts have an XML presentation in Android. In order to draw content, the XML needs to be parsed, the screen needs to be measured, and all the elements need to be placed accordingly. It’s a resource- and time-consuming process that needs to be optimized.
This is how the ListView (and more recently the RecyclerView) works.
If a layout has been inflated once, the system reuses it. But still, inflating the layout must happen at some point.
Let’s say you want to make a 3x3 grid with images. One way of doing this is a vertical LinearLayout containing 3 LinearLayouts with equal weight, each of them containing 3 ImageViews with equal weight.
What do we get with this approach? A warning that “nested weights are bad for performance”.
There is a saying in the Android programming world, that I just made up: “With little effort all hierarchy can be flattened”.
In this case RelativeLayout or GridLayout will efficiently replace the nested LinearLayouts.
8) Not Setting the minSdkVersion to 14:
Well, this is not a mistake, but it is bad practice.
Android 2.x was a huge milestone in developing this platform, but some things should be left behind. Supporting older devices adds more complexity for code maintenance and limits the development process.
The numbers are clear, the users have moved on, the developers shouldn’t stay behind.
I’m aware that this doesn’t apply for some big markets with old devices (ex. India), and setting the minSdkVersion to 14, on the Facebook App, means leaving couple of million users without their favorite social network. But, if you are starting fresh and trying to create a beautiful experience for your users, do consider eliminating the past. Users that don’t have the resources, or feel the need to upgrade their device/OS, won’t have the incentive to try out a superior version of your Android app and ultimately spend money on it.
9) Developing App in MVC Architecture:
i have seen thousands of time that client is shouting that write unit test cases for my business logic and let me know the coverrage of it.then if your app is in MVC then you can never say that you can write 100% unit test cases because of tight coupling between the business logic and controller and vice-versa.So instead of MVC use MVP because of its simplicity,abstractness,code maintainability,separate business logic presenter class etc.i can write 1000 of advantages over MVC which actually helps in long term project.
10) Not Giving Importance to User Experience:
Apps are made for users. so, user experience is the key factor that determines the success or failure of an app. There are several seminars, annual events and conferences help over this common topic. However, add developers often fail to place enough emphasis on this crucial factor and intuitive design.
Before finalizing an app, run usability or user acceptance testing (UAT) several times to check how it works on the mobile platform. Such testing can give you better understanding of user experience and persona, and even how people would like to interact with the app. To ensure this process works smooth and fine, wireframe the entire designing process.
11) Inefficient Resources Management in Android App Development:
Android application resources such as images, icons, layouts, text strings, etc. are vital for app performance. Due to responsive designing needs, these resources need more than one alternatives to fit in any device from tiny to large handhelds.
Therefore, an advanced architecture for resources management is essential, and we can do it by externalizing the application resources from the code. We can maintain such resources independently by creating directories and sub-directories in res/directory of your Android project.
Besides primary resources, you should place alternative resources for specific device configurations. You can group it all specifically named resources directories and sub-directories so that Android can use the appropriate resource in runtime based in its current configuration.
Android. What’s not to like about this platform? It’s free, it’s customizable, it’s rapidly growing and it’s available not just on your phone or tablet, but on your smartwatch, TV and car too.
With the latest Oreo update, Android programming continues to improve. The platform has matured quite a bit since the initial AOSP release, and set the user expectations bar quite high.
There are thousands of different devices, with different screen sizes, chip architectures, hardware configurations, and software versions. Unfortunately, segmentation is the price to pay for openness, and there are thousands of ways your app can fail on different devices, even as an advanced Android programmer.
Regardless of such huge segmentation, the majority of bugs are actually introduced because of logic errors. These bugs are easily prevented, as long as we get the basics right!.
I am gone tell all those mistakes which you can avoid while development.
1) Developing for Your Android Device:
Unless you are building a kiosk/promo app for a single tablet, chances are your Android app won’t look good on every device. Here are a few Android programming tips to remember:
Density-independent pixels (dp) are different than normal pixels (px).
Resources are included multiple times to account for different densities and orientations.
9-patch drawables are stretched to fit the screen.
There are literally thousands of possible scenarios, but after a while you develop a sense for covering them all with a handful of cases.
You don’t own thousands of devices? Not a problem. The Android Emulator is super good in replicating physical devices. Even better, try out Genymotion, it’s lightning fast and comes with a lot of different popular preset devices.
Also, have you tried rotating your device? All hell can break loose…
2)Not Using Intents:
Intents are one of Android’s key components. It’s a way of passing data between different parts of the app or, even better, different apps on the system.
Let’s say you have a gallery app that can share a download link to some images via SMS. Which of the two options seems more logical?
Option 1:
Request the SEND_SMS permission.
<uses-permission android:name="android.permission.SEND_SMS" />
Write your own code for sending SMS using the SmsManager.
Explain to your users why your gallery app needs access to services that can cost money, and why they have to grant this permission to use your app.
Option 2:
Start an SMS Intent and let an app designed for SMS do the work
Intent sendIntent = new Intent(Intent.ACTION_VIEW);
sendIntent.setData(Uri.parse("sms:" + telephoneNumber));
sendIntent.putExtra("sms_body", x);
startActivity(sendIntent);
In case that you have any doubts, best solution is option 2!
This approach can be applied to almost anything. Sharing content, taking pictures, recording video, picking contacts, adding events, opening links with native apps, etc.
Unless there is a good reason to make a custom implementation (ex., a camera that applies filters), always use Intents for these scenarios. It will save you a lot of programming time, and strip the AndroidManifest.xml of unnecessary permissions.
3)Not Using Fragments:
A while ago in Honeycomb, Android introduced the concept of fragments. Think of them as separate building blocks with their own (rather complex) life cycles that exist inside an Activity. They help a lot with optimizing for various screens, they are easily managed by their parent activity, can be reused, combined and positioned at will.
Launching a separate activity for each app screen is terribly inefficient, since the system will try to keep them in memory as long as it can. Killing one won’t free the resources used by the others.
Unless you want to dig deep into the Android core and read this article, advocating against fragment usage, you should use fragments whenever possible. It basically says that fragments and cursor loaders have good intended purpose, but poor implementation.
4)Blocking the Main Thread:
The main thread has a single purpose: keeping the user interface responsive.
Although the science behind measuring the frame rate our eyes/brain can perceive is complex and influenced by a lot of factors, a general rule is that anything below 24 fps with delay greater than 100 ms won’t be perceived as smooth.
This means that the user’s actions will have a delayed feedback, and the Android app you have programmed will stop responding. Stripping the user of his control over the app leads to frustration.
Even worse, if the main thread is blocked for a while (5 seconds for Activities, 10 for Broadcast Receivers), ANR will happen.
This was so common in Android 2.x, that on newer versions the system won’t let you make network calls in the main thread.
To avoid blocking the main thread, always use worker/background threads for:
1. network calls
2. bitmap loading
3. image processing
4. database querying
5. SD reading / writing
5)Reinventing the Wheel:
“OK, I won’t use the main thread. I’ll write my own code that communicates with my server in a background thread.”
No! Please don’t do that! Network calls, image loading, database access, JSON\xml\SOAP parsing, and social login are the most common things you do in your app. Not just yours, every app out there. There is a better way. Remember how Android has matured and grown as a platform? Here’s a quick list of examples:
Use gradle as a build system.
Use Retrofit / Volley for network calls.
Use Picasso for image loading.
Use Gson / Jackson for JSON parsing.
Use common implementations for social login.
If you need something implemented, chances are it’s already written, tested and used widely. Do some basic research and read some Android programming tutorials before writing your own code!.
6)Not Understanding Bitmaps:
Users love content! Especially when the content is well formatted and looks nice. Images, for instance, are extremely nice content, mainly due to their property of conveying a thousand words per image. They also consume a lot of memory. A lot of memory!
Before an image is displayed on the screen, it has to be loaded into the memory. Since bitmaps are the most common way to do this, we’re going to provide an Android programming guide for the whole process:
Let’s say you want to display an image on your screen that you just took with your camera. The total memory needed for this is calculated with the following formula: memory_needed_in_bytes = 4 * image_width * image_height;
Why 4? Well, the most common / recommended bitmap configuration is ARGB_8888. That means that for each pixel we draw, we need to keep 8 bits (1 byte) for the alpha, the red, the greed and the blue channel in memory, in order to properly display it. There are alternatives, like the RGB_565 configuration that requires half the memory than ARGB_8888, but loses the transparency and the color precision (while maybe adding a green tint).
Let’s assume you have a brand new device with full HD screen and 12 MP camera. The picture you just took is 4000x3000 pixels large and the total memory needed to display it is: 4 bytes * 4000 * 3000 = 48 MB
48 megabytes of your RAM just for a single image!? That’s a lot!
Now let’s take the screen resolution into consideration. You are trying to show a 4000x3000 image on a screen that has 1920x1080 pixels, in worst case scenario (displaying the image full screen) you shouldn’t allocate more than 4 * 1920 * 1080 = 8.3 MB of memory.
Always follow the Android programming tips for displaying bitmaps efficiently:
Measure the view you’re showing your images in.
Scale / crop the large image accordingly.
Show only what can be displayed.
7)Using Deep View Hierarchy:
Layouts have an XML presentation in Android. In order to draw content, the XML needs to be parsed, the screen needs to be measured, and all the elements need to be placed accordingly. It’s a resource- and time-consuming process that needs to be optimized.
This is how the ListView (and more recently the RecyclerView) works.
If a layout has been inflated once, the system reuses it. But still, inflating the layout must happen at some point.
Let’s say you want to make a 3x3 grid with images. One way of doing this is a vertical LinearLayout containing 3 LinearLayouts with equal weight, each of them containing 3 ImageViews with equal weight.
What do we get with this approach? A warning that “nested weights are bad for performance”.
There is a saying in the Android programming world, that I just made up: “With little effort all hierarchy can be flattened”.
In this case RelativeLayout or GridLayout will efficiently replace the nested LinearLayouts.
8) Not Setting the minSdkVersion to 14:
Well, this is not a mistake, but it is bad practice.
Android 2.x was a huge milestone in developing this platform, but some things should be left behind. Supporting older devices adds more complexity for code maintenance and limits the development process.
The numbers are clear, the users have moved on, the developers shouldn’t stay behind.
I’m aware that this doesn’t apply for some big markets with old devices (ex. India), and setting the minSdkVersion to 14, on the Facebook App, means leaving couple of million users without their favorite social network. But, if you are starting fresh and trying to create a beautiful experience for your users, do consider eliminating the past. Users that don’t have the resources, or feel the need to upgrade their device/OS, won’t have the incentive to try out a superior version of your Android app and ultimately spend money on it.
9) Developing App in MVC Architecture:
i have seen thousands of time that client is shouting that write unit test cases for my business logic and let me know the coverrage of it.then if your app is in MVC then you can never say that you can write 100% unit test cases because of tight coupling between the business logic and controller and vice-versa.So instead of MVC use MVP because of its simplicity,abstractness,code maintainability,separate business logic presenter class etc.i can write 1000 of advantages over MVC which actually helps in long term project.
10) Not Giving Importance to User Experience:
Apps are made for users. so, user experience is the key factor that determines the success or failure of an app. There are several seminars, annual events and conferences help over this common topic. However, add developers often fail to place enough emphasis on this crucial factor and intuitive design.
Before finalizing an app, run usability or user acceptance testing (UAT) several times to check how it works on the mobile platform. Such testing can give you better understanding of user experience and persona, and even how people would like to interact with the app. To ensure this process works smooth and fine, wireframe the entire designing process.
11) Inefficient Resources Management in Android App Development:
Android application resources such as images, icons, layouts, text strings, etc. are vital for app performance. Due to responsive designing needs, these resources need more than one alternatives to fit in any device from tiny to large handhelds.
Therefore, an advanced architecture for resources management is essential, and we can do it by externalizing the application resources from the code. We can maintain such resources independently by creating directories and sub-directories in res/directory of your Android project.
Besides primary resources, you should place alternative resources for specific device configurations. You can group it all specifically named resources directories and sub-directories so that Android can use the appropriate resource in runtime based in its current configuration.
No comments:
Post a Comment