Skip to content

android sucks

Jump to bottom
Jörg Hohwiller edited this page May 1, 2022 · 22 revisions

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. To make it even worse they now deprecated this and invented yet another format called aab. 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 used to another IDE such as Eclipse you are simply lost and forced to switch to Anrdoid Studio, 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 promise of gradle to make builds incredibly fast compared to Maven?

  • Android development consists of crappy XML resource files together with Java or Kotlin code. To bridge between these worlds the Android build process does magic code generation. However, this is unstable and breaks. When you want to refactor something things simply break and fall into pieces. If you look at the source-code of large Android apps you will often see all activities in one package with crazy names. This mess is a result of Androids crappy generation and flawed refactoring capabilities.

  • Naming conventions suck. MainActivity.java corresponds to activitiy_main.xml, etc.

  • 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 android did not have much Java experience and were designing the APIs from a native C developer point of view (comparable to the SWT "API" that 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 android never works intuitive.

    • Instead of creating dedicated widgets for particular purposes like a password input, android comes with ultra generic widgets like EditText that is a "text-input", "password-input" and "text-area" in one class 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.

Conclusion

In general it could be so much fun to build (mobile) apps but android makes the exeprience for developers so bad that it is almost 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.

Clone this wiki locally