10 Most Common Mistakes by Android Developers

Android, everything about is outstanding. Its free, it is adaptable, is enormously growing and is accessible on your phone, tablet, smart TV, smart watch and car too.

Android has been continually improving from “Alpha” to “Lollipop”. Since the initial release of the android AOSP the expectations of the users, really high.

There are enormous diverse gadgets with distinctive screen sizes, chip architectures, hardware configurations and software versions. Sadly, segmentation is the cost to pay for openness, and there are thousands ways your application can fall flat on diverse gadgets.

Although the segmentation is really big, still a large chunk of bugs are introduced because of logical errors. If the basics are right, the bugs can be fixed.

 Now, the 10 common mistakes made by the Android developers:

 1)      Developing for iOS:

Occasionally an android app we see is a clone of an iOS application. This mistake has been realized now clients have understood that the design standards set by Apple are a part of past now.

Clients have been using android for a while now and they’ve become usual to the stage. Pushing iOS design standards to them is an awful method. Unless, there is a super solid reason to break the guidelines, don’t break them.

Some common examples of this mistake are:

• there should be no colors in the system notification icons.
• the icons of the apps should not be placed in a box or a rounded rectangle, unless its an original logo e.g. Facebook.
• lists should not include carets (^).
• static tabs should not be in the bottom, rather you shouldn’t be making them.
• splash screens are no longer needed surpassing the initial setup or introduction. They should not be used in any other case.

2)      Developing for your device: 

There are possibilities that your app won’t look attractive on every device until you’re developing an app kiosk/ promo app for a single tablet.

• 9-patch drawables are stretched to fit the screen.
• Resources are included multiple times to account for different densities and orientations.
• Density-independent pixels (dp) are different than normal pixels (px)

There are several different plans but after a bit of practice you get an idea of how to cover them all with things which are difficult to handle.

You won’t be having all android devices and that is not a problem. Replicating becomes very easy for physical devices using the Android Emulator, a better option is Genymotion. Genymotion comes with a lot of different presets of popular devices and it’s super fast.

Have you tried rotating your device? A chaos can be born. 

3)      Not using intents:

Intent is one of the essential components of Android. Intent is an abstract description of an operation to be performed. Its a way of passing data between different parts of the app or different apps of the system.

For example you have a gallery application which can share a link of some images via SMS. Which of the two options seem 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);

Option 2 is a better solution, just telling you so that you don’t have any doubts.

This option can be applied to almost everything i.e. Sharing content, taking pictures, recording video, picking contacts, adding events, opening links with native apps, etc.

Use intents for these scenarios unless there is a good options to make custom changes, this will save a lot of time.

 4)      Not using fragments: 

In an earlier version of Android, Honeycomb, a system fragments was introduced in the Android. Now, what is fragment?

They are independent building blocks, with their complex life cycle that breathe inside an activity.  Fragments help in the optimization of many screens, are efficiently managed by their client activity and can be reused combined or positioned at will.

Launching a separate activity for each of the app screen is appallingly wasteful, since the memory would store them inside it, until it can.  Killing one of them won’t free the resources, as they will be used by the others.

Fragments should be used whenever they’re possible to use. Fragments have poor implementation but are good for intend purposes. 

5)      Blocking the main thread:

Keeping the user interface responsive is a single purpose of the main thread.  A common rule is that anything which is below 24 frames per second with a delay greater than of 100 ms isn’t considered to be smooth.

So deducing from this, the user will have a delayed feedback and the application will stop responding. This can turn a user into a frustrated one which may result in a negative feedback.

This issue was really common with the version 2.x of Android, which resulted that in the later versions system didn’t allowing making network calls in the main thread.

To avoid, hindering the main thread always use background or worker threads for the following:

• network calls
• bitmap loading
• image processing
• database querying
• SD reading/ writing

6)      Reinventing the wheel:

Refrain from writing your own threads that will communicate with the server in the background. There are some common things which you do in your app are Network calls, image loading, database access, JSON parsing, and social login. This is done with the every app out there.

Here is a checklist of how Android matured and grew as a platform:

• 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.

Do a bit of research before before what you’re going to write or test may already be written and tested.

7)      Not assuming success:

Well documented libraries can be used to better handle the long running tasks. But the clients have to wait because, its unavoidable. Packages are not sent, received or processed instantly. Numerous errors can occur i.e. round trip delay, there are network failures, packages get lost, and dreams get destroyed.

But everything is scaleable, successful calls are more likely than the unsuccessful ones. So why should we wait for the server response before handling the successful request? It’s boundlessly better to expect success and handle failure. So, when a user clicks the like button, the likes increase in number and when there is an unlikely event, the user is notified.

8)      Not understanding bitmaps:

Users are fond of contents, especially when the content is attractive. Images have a greater impact but they consume a lot memory.

An image is loaded in the memory before the it is displayed on the screen. Bitmaps are the common ways of doing this.  A deeper look of this process:

The following formula is used to calculate the total memory of the image to be loaded

memory_needed_in_bytes = 4 * image_width * image_height;

A question may arise that why ‘4’?  This is because the most common bitmap configuration is ARGB_8888. For each pixel we draw we need to keep 8 bits (1 byte) for alpha, the red, green and blue channel in the memory. There are some other alternatives to this which require half the memory but the image loses its charm and transparency.

For example, you have a brand new device with full HD screen and 12 MP camera. The picture you just took is 4000×3000 pixels large and the total memory needed to display it is: 4 bytes * 4000 * 3000 = 48 MB

This means 48 mb of ram for one image. This is too much!

Now let’s take the screen resolution into consideration. You are trying to show a 4000×3000 image on a screen that has 1920×1080 pixels, in worst case scenario (displaying the image full screen) you shouldn’t allocate more than 4 * 1920 * 1080 = 8.3 MB of memory.

Few recommendations for displaying bitmaps productively are:

• Measure the view you’re showing your images in.
• Scale / crop the large image accordingly.
• Show only what can be displayed.

9)      Using deep view hierarchy:

Layouts have an XML presentation in Android. The  screen needs to be measured and the elements need to be placed in the respective places, in order to draw the content. This process needs to be optimized as it’s a time and resource consuming one.

Let’s say you want to make a 3×3 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 is the result of this task?  A warning that “nested weights are bad for performance”.

In this case RelativeLayout or GridLayout will efficiently replace the nestedLinearLayouts.

10) Not setting the minSdk version to 14:

This is an unhealthy practice.

The Android 2.x was a turning point in the development of this platform, but this is past now. The development process becomes limited because when the older devices are supported and becomes more complex to maintain the code.

As the platform is growing, the developers should also move on, now.

But this doesn’t applies to big markets which still have old devices, and setting the minSdkVersion to 14, on the Facebook App, which means you’re snubbing a couple of million users away from their favorite social network.

If you’re objective is to a give an outstanding experience to your users and you’re starting fresh, abolish the past. The user’s who do not have the resources and have a need to upgrade the app won’t get the incentive to use your app and will ultimately have to spend chunks to enjoy it.

 Android is a powerful platform which is developing really fast. It isn’t sensible to anticipate that the clients will also keep up the pace, but its urgent for the developers to catch up the boosted process.

It is vital to realize that Android is not only on our phones and tablets. It is in our living rooms, on  our wrists, in our kitchens and in our vehicles. Getting the rudiments right, is the foremost task before we begin growing.

source : http://tkxel.com/