android sucks

Why android development sucks

Appologies in advance: Here comes my personal shit-storm. In practice I have various android devices and am quite a fan of it from a user-perspective. However, from a developers point of view I hate android.

When a giant IT company like google creates a development platform like for Anrdoid one would expect them to design it well and make it a pleasure for developers to build great apps. However, google has completely messed it:

• In Java artifacts for dependencies are typically available in maven-central. This makes it easy to include the required libraries into your code. However, google was ignorant enough to build their own google maven repository.

• In Java libraries are provided as JAR files. This is an absolute defacto-standard supported by all build tools out of the box. Even libraries with native code included use this standard. Again google was ignorant enough to create their own aar-format for packaging. This is preventing the use of android libraries in most common java toolchains like Maven or Eclipse and causing severe issues and pitfalls. IMHO the most terrible design decision ever.

• Google does not support major IDEs like Eclipse and was ignorant enough to create their own IDE called android studio. It is a kind of fork of IntelliJ. It is really not bad but it takes you away the freedom to choose your IDE. If you are are used to another IDE such as Eclipse you are simply lost and forced to switch to Anrdoid Stuio, give up your experience (plugins, shortcuts, etc.) and learn from scratch.

• Googles adoption of gradle for android is a desaster, especially when it comes to Multidex. Build time performance is very poor and sucks. Wasn’t the big promis of gradle to make builds incredibly fast compared to Maven?

• All libraries provided by google for android are provided without any JavaDoc and with fully uglified code:

  public class View
    implements android.graphics.drawable.Drawable.Callback, android.view.KeyEvent.Callback, android.view.accessibility.AccessibilityEventSource
  {
  public static interface OnLayoutChangeListener
  {
  public abstract  void onLayoutChange(android.view.View v, int left, int top, int right, int bottom, int oldLeft, int oldTop, int oldRight, int oldBottom);
  }
  public static class DragShadowBuilder
  {
  public  DragShadowBuilder(android.view.View view) { throw new RuntimeException("Stub!"); }
  public  DragShadowBuilder() { throw new RuntimeException("Stub!"); }
  @java.lang.SuppressWarnings(value={"JavadocReference"})
  public final  android.view.View getView() { throw new RuntimeException("Stub!"); }
  public  void onProvideShadowMetrics(android.graphics.Point shadowSize, android.graphics.Point shadowTouchPoint) { throw new RuntimeException("Stub!"); }
  public  void onDrawShadow(android.graphics.Canvas canvas) { throw new RuntimeException("Stub!"); }
  }
  public static class MeasureSpec
  ...

• The programming APIs are poorly designed, historically grown and simply ugly. Technically it is not even an API but a stub implementation not well designed for testability either. As an experienced Java developer you immediately see that the makers of the APIs for anroid did not have much Java experience and were designing the APIs from a native C developer point of view (similar to SWT whos API is a similar crime). The makers of Android APIs have been driven by pointless exposure of performance optimizations using integer masked attribute combinations instead of using Enums, flags and structured meaningful typings.

  • Android wigets have tons of methods taking int as argument such as setOrientation(int), setText(int), setInputType(int), etc. You need to know where to find the proper constants for providing valid arguments and sometimes even need to mask them with logical or such as InputType.TYPE_CLASS_TEXT | InputType.TYPE_TEXT_VARIATION_PASSWORD.

  • There is no systematics and no consistency in the API. Different widgets offer the same logical thing as methods with totally different names such as GridView.setNumColumns(int) vs. GridLayout.setColumnCount(int).

  • To "improve" the API methods like Display.getWidth() and Display.getHeight() have been deprecated. Instead you need to do:

    Point size = new Point();
    display.getSize(size);
    int width = size.x;
    int height = size.y;

  • Many general aspects such as ActionBar are really messed up and full of quirks. Getting something right with anroid never works intuitive.

  • Instead of creating dedicated widgets for particular purposes like a password input, android comes with ultra generic widgets like EditText fully overblown with methods.

  • Observing the inheritance of the android widgets is revealing that there was no real API design at all but all was driven by the implementation.

  • I am not a big fan of CSS but the styling of Android apps is much worse and CSS at least gives you a good flexibility.

• Entire libraries and functions of anrdoid get deprecated like anrdoid support library. So you end up in documentations like TabLayout without any hint where to find the proper replacement. Anroid does it’s best to let you feel lost in space as developer.

Conclusion

In general it could be so much fun to build (mobile) apps but anroid makes the exeprience for developers so bad that it is alost as shitty as building web applications with HTML5 and JavaScript. Sorry, for being so harsh but I wanted to make my point very clear after all frustration.