Why Flutter is better than Android native

There are two inaccuracies in my title: firstly, Flutter is Android native, but we will be talking about developing Android native apps using Java versus Flutter app in Dart; and secondly, one isn’t really better than the other, but in my circumstances, one approach was definitely better than the other.

A brief introduction

The important information about my background which you should know:

• I published an app in 2013 and I think it has been moderately successful. Not a Candy Crush, but it hasn’t died yet and people are using it daily.
• I rebuilt this app and it has feature parity with the old one – it does exactly the same thing the old one did (I know, because I’ve had users point out to me where I have forgotten how the “old” app worked). From their point of view, it just seems like I updated the look and feel a bit.
• Development is a hobby rather than a job (although I work with development teams, but not as a developer). Java and Dart were both self-taught and never used in a professional environment for me. (I learned C++ at uni and have a long history with languages like BASIC, Pascal, C and Visual Basic).

So my qualification to make these statements come from building the same production app in both Java and Dart with limited experience. Let’s dive right into some comparisons:

Java vs Dart

Both languages are very similar and I feel fairly comfortable using both. I was a bit hesitant with learning Dart, but it felt completely natural after being quite used to Java (I’ve dabbled a bit with Python and PHP and I found it much easier to quickly adapt into Dart comparatively).

Doing asynchronous work in Java is a bit more of a hassle compared to Dart. Dart’s syntax makes it very easy (except that in Flutter, you build methods cannot use the asynchronous syntax).

I also got into Dart and Flutter when Dart 2.0 was out, so the language was cleaned up for Flutter, so no annoying “new”‘s everywhere.

And then, Dart either seems to handle nulls a bit better or I have burned myself enough in Java to be handling it better myself. But it feels like Flutter protects you a little bit as you don’t have a mini-explosion every time you forget to handle a null.

The only negative point for Dart, but this more a Flutter thing, is that you end up with lots of brackets everywhere – more than usual. And maybe quite a lot of commas too.

As a language, I prefer Dart as it is a bit more to the point and feels like it is made for what I want to do.

Material design

I spent a good number of weekends implementing material design at the start of 2015. It had only been announced in June the previous year, so it was still relatively new and there wasn’t too much help available in terms of libraries. I remember having to style everything by hand, measuring margins and constantly referencing the material design specs.

Flutter basically gives you material design out of the box. I actually hadn’t realised how “not material design” my app was until I rebuilt it using Flutter. (Of course, I don’t know if you now get some better help in Android native, but it felt really good that the design system I wanted to use was immediately available to me rather than having to sit and figure out margins, padding, shadows, rounding and so on, on my own.)

Getting a material design look in Flutter was effortless compared to doing the same thing in Java.

XML vs code

When you work with Java, a lot of layouts, strings and random values will reside in XML instead of code. This should make scaling with large teams easier as there is a separation of concerns and a designer can pick up the XML files and edit them without having to know code. As nice as this is, I don’t like it for a smaller project. And then, you end up having to reference the XML in code any way, and you always wonder why you can’t just do it all in code (maybe you can?). It felt like things got messy having to work in XML and then use LayoutInflater to build the things I just build in XML to start with.

On the flip-side, I miss one thing: Strings.xml. This allows for easy translation and just having everything nicely in one place. I have seen a way to do it in Flutter, but it didn’t immediately make sense to me. I never actually translated my app, so it’s probably over-engineered, but equally don’t feel too happy with the strings just sitting all over the place. (I should probably at least just create a static class to put all my strings in…but that’s for another day).

Because I definitely prefer being able to have complete control over my layouts, I prefer the Flutter approach where it is all in code. The XML approach would have been more useful for WYSIWYG editors, but they never worked too well for me and I didn’t feel completely in control. And the fact that it would try and display even the smallest layout in the editor. It was just odd.

Hot reload

The lack of WYSIWYG layout editor in Flutter is made up for by having hot reload. It can do some strange things at times (or in my app if I change things which are done right at start-up, hot reload doesn’t work), but it is great for making layout changes and being able to see it immediately. This is not available when using Java and slows down the process a bit.

Fragments vs widgets

I’m calling out fragments here, but it really should be, “Widgets vs the Android kitchen sink”. Everything in Flutter is a widget – this makes it very predictable on how it will work and easy to move around and plug in somewhere else. It took me minutes to take my existing layout for phones and adapt it for tablets where I wanted side-by-side views of two different screens.

Adapting my app for tablets in Java was a complete nightmare. Again, things might have changed, but I had to use fragments. I had two fragments and it just felt awkward trying to deal with it differently between tablets and mobiles. Because everything is a widget in Flutter – this sort of thing is quite straight-forward to achieve.

It’s worth pointing out, that even after all of that work with fragments, the app stopped working on tablets at some point and I just never had the courage to want to try and fix it again. Until Flutter came along…

Flavours

I have three different flavours in both my set ups. The Flutter one would not have been as straight-forward to set up since I had to go and muck around in the Android code – but since I have done it before, it was pretty much copy and paste. If I was new to this, I can imagine it would have been pretty difficult to figure out as you have to change files you don’t normally deal with.

One of my flavours has a different applicationId which I can use in Flutter code to distinguish, but two of them don’t and I cannot easily and without some workarounds detect in code which flavour is which.

I would prefer it if there was an easier way to deal with flavours in Flutter, but it barely handles it at the moment.

Dependencies

For both Java and Dart, dependency management is quite straight-forward. Dart feels a little bit more light-weight and straight-forward – I have many more dependencies in my Java app for Android support libraries which I didn’t need in Dart (due to Flutter).

Due to not having to worry about the support libraries I prefer Flutter for dependency management, but I’m sure this might be why the APK’s are so big.

APK sizes

This was almost a deal breaker for me, and even though the production APK’s are quite a bit smaller than the debug ones, this is Flutter’s worst point for me by far.

The Java APK is 4.07MB and the Flutter one is 10.03MB.

Due to the large initial size of the Flutter APK (I started somewhere around 18MB), I had to be aggressive in terms of making images as small as possible, reducing the size of my static data database and be very careful with dependencies. Both APK’s are Proguarded/Minified. My Flutter APK is only that small due to a dedicated effort to try and get it as small as possible. If I put the same effort into the Java one, I’m sure I would get it to be a bit smaller.

Android Studio vs VS Code

I moved from Eclipse to Android Studio and liked it in the beginning, but it was quite heavy on the processing side. I’ve killed a laptop battery due to it and I’m fairly sure the heat Android Studio has generated in the past might have fried a few laptop components too. I now use a desktop, but Android Studio is still quite heavy-weight and it just feels too clunky.

Even though I use Android Studio from time to time due to wanting to use the layout inspector as an example, I prefer spending my time in VS code.

Maturity

We have to touch on maturity here. Because Java Android has been around for years, you have access to tons of libraries and many resources. Getting stuck shouldn’t happen for long and you’ll be helped quite quickly. All the libraries have had years to stabilise and shouldn’t give you problems (well, you’d think so at least).

On the other hand, Flutter is still fairly new. I’ve had specific issues with libraries crashing my app because despite claiming to be version 1.1+, version 1 just meant it was their first publication. I’ve also had issues with libraries being incomplete. It’s worth pointing out that in both cases, I found suitable solid alternatives, so I haven’t been left with nothing.

This is probably set to get worse for now as many libraries are still experimental or beta. As these libraries are upgraded, I’m probably going to have to rewrite large chunks of code. (Although, my Java code is probably in that situation now as I haven’t upgraded libraries for about 6 months).

Wearables

Neither app had a wearable version, but it was an option for me when I was working in Java. Flutter doesn’t support this yet, so if I had any plans to also have a wearable version, it isn’t currently possible.

I’ll mention it here only because it is also in the category of I don’t have it, but had the option and lost it – widgets. I believe that Flutter doesn’t yet support home screen widgets on Android, but this I cannot confirm.

Flutter’s best feature for me

So I’ve saved the best for last – Flutter gives me something I’ve wanted since 2013, but due to many issues, like time constraints, willingness and ability to learn, having to work on a Mac, I just never could build an iOS app. Flutter gave me this for free. Of course I had to set up a Mac in order to test it, but it just worked – pretty much out of the box with no code changes whatsoever (working is of course different to being usable – I’ve done a post on Flutter on iOS for Android developers about my lessons I’ve learned).

I’ve broken into a whole new market due to Flutter, so this is for me, the main reason that Flutter is better than using Java Android.

Summary

This is all my opinion based on my own use case, but hopefully you can find some useful bits in here if you are deciding whether to use Java for Android for Dart for Flutter. The checkboxes simply point out which is better at supporting the feature than the other – in most cases features are supported in both.