10 Things I Hate About Android

I hate the way you define your views in XML and code Nobody enjoys having to write out these monstrosities.

activity_main.xml

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    android:id="@+id/activity_main"
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    >

    <TextView
        android:id="@+id/text_view"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="@string/text"
    />

</LinearLayout>

MainActivity.java

private TextView mTextView;

@Override
public void onCreate(Bundle bundle) {
    super.onCreate(bundle);
    setContentView(R.layout.activity_main);
    mTextView = (TextView)findViewById(R.id.text_view);
}

I hate the way you make me write everything so verbose

I hate the way the lifecycle is nigh on impossible to decode

I hate the way your AsyncTasks leave much to be desired Anyone who has had to support an app written in the last 4 years will have had the joy of working with a codebase that either a) handled all blocking(!!) calls on the main thread (network requests, I'm looking at you), or when Android finally introduced the NetworkOnMainThreadException because things were getting out of hand, the joy that was the blocking network calls migrated unapologetically to AsyncTasks - usually as a private class on the Activity. Yuck.

I hate the way your ancestors have a habit of hanging around Nothing says Android like having to support ~11 different API versions. Which also leads into

I hate the way there is no consistency between vendor implementations Before Android gained first party support for NFC or fingerprint readers you had to build against a different SDK for each of the vendors that supported it, some of which (That means you, Samsung) had very.. interesting views on how to interface with hardware.

I hate the way you seem to break on such arbitrary little things

UNEXPECTED TOP-LEVEL EXCEPTION: com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536
at com.android.dx.merge.DexMerger$6.updateIndex(DexMerger.java:502)
at com.android.dx.merge.DexMerger$IdMerger.mergeSorted(DexMerger.java:277)
at com.android.dx.merge.DexMerger.mergeMethodIds(DexMerger.java:491)
at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:168)
at com.android.dx.merge.DexMerger.merge(DexMerger.java:189) at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:454)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:302)
at com.android.dx.command.dexer.Main.run(Main.java:245)
at com.android.dx.command.dexer.Main.main(Main.java:214)
at com.android.dx.command.Main.main(Main.java:106)
...

Thats fine, I didn't want to use that library anyway.

I hate the way the design documents aren't consistent at all Don't get me wrong, Material Design is one of the best things that Google have produced in the last few years, however as Ian Clifton wrote introducing these inconsistencies makes it difficult for users and developers.

I hate the way the emulator lags on the simplest of things Integration tests failed? Chalk another one up to emulator lag.

But mostly I hate the way I don't hate you. Not even close, not even a little bit, not even at all.

Serious talk now, developing on Android isn't all bad, and some simple things make the whole experience much better. Use ButterKnifetocleanupViewinjection,oralternativelyAnko so you can define your layouts in code.

Speaking of Anko, using the Kotlin RuntimeinsteadofstraightJavacanmakeeverythingmuchmoresuscinct,andmuchmoreenjoyabletoreadandwrite.ChristinaLeehasagreattalkaboutusingKotlininproductionapps.

RXJavaandRetrofitcanremovemostofthepainofdealingwithasynchronousnetworkcalls,andtheSupportLibrary makes dealing with old API levels a breeze.

The Genymotionemulatorvastlyimprovestheexperienceofdevelopingnotdirectlyonaphysicaldevice,andFirebaseTestLaborAWSDeviceFarm make it easy to run integration test of your app across a variety of different, physical devices.

Android Studio and Gradle are miles better than the previous Eclipse + Ant workflow, so if you haven't yet made the switch to Android Studio, I highly recommend you give it a go, especially as the Eclipse Android plugin has been deprecated.