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.

```xml: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>
```
```java: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
<img width="367" alt="If programming languages were essays.png" src="https://qiita-image-store.s3.amazonaws.com/0/151673/7272097b-5b1e-d9d2-30c8-c0f64885877d.png">
* * *
## I hate the way the lifecycle is nigh on impossible to decode
<img width="500" alt="Activity & Fragment Lifecycle" src="https://i.stack.imgur.com/fRxIQ.png">
* * *
## 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 `AsyncTask`s - usually as a private class on the `Activity`. Yuck.
* * *
## I hate the way your ancestors have a habit of hanging around
<img width="330" alt="Data collected during a 7-day period ending on December 5, 2016" src="https://qiita-image-store.s3.amazonaws.com/0/151673/16e6bb62-1ca3-db9b-cf20-f77f7140a875.png">
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
```java
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
<img width="600" alt="http://blog.iangclifton.com/2016/03/19/bottom-tabs-on-android/" src="http://blog.iangclifton.com/uploads/2016/03/grounding-example.png">
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](http://blog.iangclifton.com/2016/03/19/bottom-tabs-on-android/) introducing these inconsistencies makes it difficult for users and developers.
* * *
## I hate the way the emulator lags on the simplest of things
<img width="300" alt="gotta go fsat" src="https://4.bp.blogspot.com/-w0KlXxaj-Bg/VrT3cvcuNzI/AAAAAAAACjs/RCwQO4nbb_w/s1600/image07.gif">
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.
<img width="500" src="http://i.giphy.com/XQvI2AjApnqes.gif">
* * *
Serious talk now, developing on Android isn't all bad, and some simple things make the whole experience much better. Use [ButterKnife](https://github.com/JakeWharton/butterknife) to clean up View injection, or alternatively [Anko](https://github.com/Kotlin/anko/) so you can define your layouts in code.

Speaking of Anko, using [the Kotlin Runtime](https://kotlinlang.org/docs/tutorials/kotlin-android.html) instead of straight Java can make everything much more suscinct, and much more enjoyable to read and write. [Christina Lee has a great talk about using Kotlin in production apps](https://www.youtube.com/watch?v=mDpnc45WwlI).

[RXJava](https://github.com/ReactiveX/RxJava) and [Retrofit](https://github.com/square/retrofit) can remove most of the pain of dealing with asynchronous network calls, and [the Support Library](https://developer.android.com/topic/libraries/support-library/index.html) makes dealing with old API levels a breeze.

The [Genymotion](https://www.genymotion.com/) emulator vastly improves the experience of developing not directly on a physical device, and [Firebase Test Lab](https://firebase.google.com/docs/test-lab/) or [AWS Device Farm](https://aws.amazon.com/device-farm/) 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.](https://android-developers.blogspot.co.nz/2015/06/an-update-on-eclipse-android-developer.html)