I hate the way you define your views in XML and code
Nobody enjoys having to write out these monstrosities.
<?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>
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 `AsyncTask`s - 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
```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
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
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 [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 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.
RXJava and Retrofit can remove most of the pain of dealing with asynchronous network calls, and the Support Library makes dealing with old API levels a breeze.
The Genymotion emulator vastly improves the experience of developing not directly on a physical device, and Firebase Test Lab or AWS 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.