Beliebte Suchanfragen

Cloud Native

DevOps

IT-Security

Agile Methoden

Java

|
//

6 reasons for native Android development

4.1.2017 | 3 minutes of reading time

2016 was yet again a successful year for the mobile device market. The operating systems Android and iOS together reach a market coverage of 99.3%.

It sounds promising to develop cross-platform apps and share certain components between them to reduce code duplication. Based on the experience with the Xamarin.Android platform this post shows a few reasons why this may not be such a good idea after all.

About Xamarin.Android

The concept of the Xamarin.Android platform is promising at first sight. Combining an awesome language like C# with a cross-platform managed runtime (Mono) should enable the developers to focus more on producing new features instead of
maintaining code for Android and iOS separately.

The fact that C# provides features on language level for some Java- and Android specialties (i.e. manifest generation using annotations, implicit casts via generic methods, background threads via the async keyword) and sharing code using the Mono runtime seems to make mobile development more efficient for developers.

I think this approach has some disadvantages which drove me to abandon Xamarin.Android and proceed with pure Android development. Although the title says “native development” this post is not a rant against hybrid development, but a plea for vanilla Android, which got so much easier than a few years ago.

Reason #1: The vast ecosystem of native libraries

Since the beginning of Android the amount of libraries, which are developed for or enhanced to support Android, has grown. Only a small part of that is being ported to C# and available as NuGet-Packages for the Xamarin platform.

Reason #2: The direct vendor support by Google

The community and the vendor support around Android is far more extensive than for Xamarin.Android. Bugs can be created and discussed using the Android bug tracker (https://source.android.com/source/life-of-a-bug.html).
Newest Android SDK versions are available as soon as Google releases them, there is no need in waiting for someone to port them, as it is the case with Xamarin.Android.

The well known discussion about who is responsible for the bug is between the Android project and the developer, there is no third party like Xamarin involved.

Reason #3: Stackoverflow AKA developer love

Stackoverflow is *the* source for problem solutions in IT. Currently (as of 27.12.2016) there a 931,615 questions tagged with Android and only 18,590 tagged with Xamarin.

Reason #4: Android Studio

Since Google dropped Eclipse, switched to the IntelliJ platform and is offering Android Studio, the IDE has become much better. Although I am using IntelliJ IDEA and there is the Android plugin available, I am still using Android Studio separately because its such a good adaption of the Android developer usecase.

My favorite features are:

  • the incredibly awesome layout designer
  • the extensive amount of lint rules for code and layout optimization
  • Instant Run

Reason #5: Tools

The tools coming with the Android SDK are very well integrated in Android Studio. Additionally, Android uses the uniform, transparently described, extendable build system Gradle, which can also use the extensive Maven repositories as a source for third party libraries. The productivity as a developer is very good, because everything fits in nice and works well together.

Additionally, Android Studio is available for Windows and macOS. Until now, for Xamarin.Android you have to use Xamarin Studio for macOS and Visual Studio for Windows. But this may change in the near future: https://www.visualstudio.com/vs/visual-studio-mac/

Reason #6: Startup time and size of the apps

Apps developed with Xamarin.Android use the Mono runtime to execute the code written in C#. This runtime has to be booted everytime the app starts in contrast to the JVM in Android, which is always running. This results in increased deployment times while developing in comparison to Android Studios Instant Run.

The Mono runtime and parts of Mono.Android have to be integrated in the app, which leads to a bigger application size.

Conclusion

A few of these reasons are of course personal taste, but I think native app development is more cost effective than is commonly believed. Which experience do you have with Xamarin and Android? Share your thoughts and leave a comment!

|

share post

Likes

0

//

More articles in this subject area

Discover exciting further topics and let the codecentric world inspire you.

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.