Top 10 Most Common Mistakes That Android Developers Make

Android. Could you ask for anything better about this stage? It’s free, it’s adaptable, it’s quickly becoming and it’s accessible on your telephone or tablet, however on your smartwatch, TV, and vehicle as well.

With the most recent Lollipop update, Android programming keeps on improving. The stage has developed a considerable amount since the underlying AOSP delivery and set the client desires bar very high. Look how great the new Material structure design looks!

There are a great many various gadgets, with various screen sizes, chip models, equipment designs, and programming adaptations. Sadly, segmentation is the cost to pay for transparency, and there are a great many ways your application can fall flat on various gadgets, even as a propelled Android software engineer.

Notwithstanding such immense segmentation, most of bugs are really presented due to rationale mistakes. These bugs are effectively forestalled, as long as we get the rudiments right!

Here’s an Android programming instructional exercise to address the 10 most regular errors Android designers make.

Common Mistake #1: Developing for iOS

To my incredible delight, this Android botch is far more uncommon these days (incompletely in light of the fact that customers are starting to understand that the days when Apple was setting all the structure principles are a distant memory). Yet at the same time, sometimes, we see an application that is an iOS clone.

Try not to misunderstand me, I’m not an Android programming evangelist! I regard each stage that moves the portable world a stage forward. Yet, it’s 2014 and clients have been utilizing Android for a long time now, and they’ve become used to the stage. Pushing iOS plan principles to them is an awful methodology!

Except if there is a too valid justification for breaking the rules, don’t do it. (Google does this constantly, however never by duplicate sticking.)

Here are probably the most well-known instances of this Android botch:

Try not to make static tabs, and they don’t have a place on the base (I’m pointing at you Instagram).

Framework notice symbols ought not have shading.

Application symbols ought not be put inside an adjusted square shape (except if that is your genuine logo ex. Facebook).

Sprinkle screens are excess past the underlying arrangement/presentation. Try not to utilize them in different situations.

Records ought not have carets.

These are only a couple of the numerous other little things that can destroy the client experience.

Basic Mistake #2: Developing for Your Android Device

Except if you are building a booth/promotion application for a solitary tablet, odds are your Android application won’t look great on each gadget. Here are a couple of Android programming tips to recollect:

Thickness autonomous pixels (dp) are not the same as expected pixels (px).

Assets are incorporated on numerous occasions to represent various densities and directions.

9-fix drawables are extended to fit the screen.

There are truly a large number of potential situations, yet sooner or later, you build up a feeling of covering them all with a bunch of cases.

You don’t possess a large number of gadgets? Not an issue. The Android Emulator is excessively acceptable in recreating physical gadgets. Shockingly better, evaluate Genymotion, it’s exceptionally quick and accompanies a variety of famous preset gadgets.

Likewise, have you taken a stab at turning your gadget? Crap can hit the fan…

Regular Mistake #3: Not Using Intents

Aims are one of Android’s key parts. It’s a method of passing information between various pieces of the application or, surprisingly better, unique applications on the framework.

Suppose you have an exhibition application that can share a download connection to certain pictures by means of SMS. Which of the two alternatives appears to be more consistent?

Choice 1:

Solicitation the SEND_SMS authorization.

<uses-authorization android:name=”android.permission.SEND_SMS”/>

Compose your own code for sending SMS utilizing the SmsManager.

Disclose to your clients why your exhibition application needs access to administrations that can cost cash, and why they need to give this authorization to utilize your application.

Choice 2:

Start a SMS Intent and let an application intended for SMS accomplish the work

Plan sendIntent = new Intent(Intent.ACTION_VIEW);sendIntent.setData(Uri.parse(“sms:” + telephoneNumber));sendIntent.putExtra(“sms_body”, x);startActivity(sendIntent);

In the event that you have any questions, the best arrangement is alternative 2!

This methodology can be applied to nearly anything. Sharing substance, taking pictures, recording recordings, picking contacts, including occasions, opening connections with local applications, and so forth.

Except if there is a valid justification to make a custom execution (ex., a camera that applies channels), consistently use Intents for these situations. It will spare you a great deal of programming time, and strip the AndroidManifest.xml of superfluous authorizations.

Basic Mistake #4: Not Using Fragments

Some time prior in Honeycomb, Android presented the idea of sections. Consider them separate structure obstructs with their own (somewhat intricate) life cycles that exist inside an Activity. They help a great deal with enhancing for different screens, they are handily overseen by their parent movement, can be reused, joined, and situated voluntarily.

Propelling a different movement for each application screen is horrendously wasteful since the framework will attempt to keep them in memory as long as possible. Murdering one won’t free the assets utilized by the others.

android programming instructional exercises

Except if you need to delve profound into the Android center and read this article, supporting against piece utilization, you should utilize parts at whatever point conceivable. It essentially says that sections and cursor loaders have a decent intended reason, yet helpless execution.

Basic Mistake #5: Blocking the Main Thread

The fundamental string has a solitary reason: keeping the UI responsive.

Despite the fact that the science behind estimating the casing rate our eyes/mind can see is intricate and affected by a ton of variables, an overall principle is that anything under 24 fps with postpone more prominent than 100 ms won’t be seen as smooth.

This implies the client’s activities will have a deferred input, and the Android application you have customized will quit reacting. Stripping the client of his authority over the application prompts dissatisfaction, disappointed clients will in general give extremely negative input.

Surprisingly more terrible, if the fundamental string is hindered for some time (5 seconds for Activities, 10 for Broadcast Receivers), ANR will occur.

This was so regular in Android 2.x, that on more up to date forms the framework won’t let you make arrange brings in the primary string.

To abstain from hindering the principle string, consistently use laborer/foundation strings for 1. organize calls 2. bitmap stacking 3. picture preparing 4. database questioning 5. SD perusing/composing

Normal Mistake #6: Reinventing the Wheel

“Alright, I won’t utilize the primary string. I’ll compose my own code that speaks with my worker in a foundation string.”

No! Kindly don’t do that! System calls, picture stacking, database get to, JSON parsing, and social login are the most widely recognized things you do in your application. Not simply yours, each application out there. There is a superior way. Recall how Android has developed and developed as a stage? Here’s a snappy rundown of models:

1. Use Gradle as a form framework.
2. Use Retrofit/Volley for organize calls.
3. Use Picasso for picture stacking.
4. Use Gson/Jackson for JSON parsing.
5. Utilize regular executions for social login.

In the event that you need something actualized, odds are it’s as of now composed, tried, and utilized generally. Do some fundamental examination and read some Android programming instructional exercises before composing your own code!

Basic Mistake #7: Not Assuming Success

Amazing. We have discovered that there is a superior route for taking care of long-running errands, and we are utilizing all around reported libraries for that reason. Be that as it may, the client will at present need to pause. It’s unavoidable. Bundles are not sent, prepared, and got in a split second. There is a full circle delay, there are organize disappointments, bundles get lost, and dreams get wrecked.

Be that as it may, this is quantifiable. Effective system calls are undeniably more probable than ineffective ones. So why sit tight for a worker reaction before taking care of the effective solicitation? It’s endlessly better to expect achievement and handle disappointment. Along these lines, when a client prefers a post the like check is quickly expanded, and in the far-fetched occasion that the call fizzled, the client is advised.

In this advanced world, quick criticism is normal. Individuals don’t care to pause. Children would prefer not to sit in a study hall acquiring information that has a dubious future result. Applications must oblige to the client’s brain research.

Normal Mistake #8: Not Understanding Bitmaps

Clients love content! Particularly when the substance is all around organized and looks pleasant. Pictures, for example, are very decent substance, mostly because of their property of passing on a thousand words for each picture. They likewise devour a great deal of memory. A great deal of memory!

Before a picture is shown on the screen, it must be stacked into the memory. Since bitmaps are the most widely recognized approach to do this, we will give an Android programming manual for the entire procedure:

Suppose you need to show a picture on your screen that you just took with your camera. The all out memory required for this is determined with the accompanying recipe: memory_needed_in_bytes = 4 * image_width * image_height;

Why 4? All things considered, the most widely recognized/suggested bitmap design is ARGB_8888. That implies that for every pixel we draw, we have to keep 8 pieces (1 byte) for the alpha, the red, the insatiability, and the blue divert in memory, so as to appropriately show it. There are options, similar to the RGB_565 setup that requires a large portion of the memory than ARGB_8888, however loses the straightforwardness and the shading exactness (while possibly including a green color).

How about we expect you have a fresh out of the box new gadget with a full HD screen and 12 MP camera. The image you just took is 4000×3000 pixels huge and the all out memory expected to show it is: 4 bytes * 4000 * 3000 = 48 MB

48 megabytes of your RAM only for a solitary picture!? That is a ton!

Presently we should think about the screen goal. You are attempting to show a 4000×3000 picture on a screen that has 1920×1080 pixels, in a most dire outcome imaginable (showing the picture full screen) you shouldn’t distribute more than 4 * 1920 * 1080 = 8.3 MB of memory.

Continuously follow the Android programming tips for showing bitmaps productively:

Measure the view you’re indicating your pictures in.

1. Scale/crop the huge picture as needs be.
2. Show just what can be shown.
3. Normal Mistake #9: Using Deep View Hierarchy

Formats have a XML introduction in Android. So as to draw content, the XML should be parsed, the screen should be estimated, and all the components should be put appropriately. It’s an asset and tedious procedure that should be upgraded.

This is the manner by which the ListView (and all the more as of late the RecyclerView) works.

In the event that a design has been swelled once, the framework reuses it. Yet at the same time, swelling the format must occur eventually.

Suppose you need to make a 3×3 framework with pictures. One method of doing this is a vertical LinearLayout containing 3 LinearLayouts with equivalent weight, every one of them containing 3 ImageViews with equivalent weight.