Why Flutter Will Change Mobile Development for the Best?
If you’re an Android developer, you may have heard of Flutter. It’s a relatively new, supposedly simple framework designed for making cross-platform native apps. It’s not the first of its kind, but it’s being used by Google, giving its claims some credence. Despite my initial reservations upon hearing about it, I decided on a whim to give it a chance — and it dramatically changed my outlook on mobile development within a weekend. Here is what I learned.
Before we get started, let me add a short disclaimer. The app I wrote and will be referencing in this article is relatively basic and does not contain a lot of business logic. It’s nothing fancy, but I wanted to share my experience and learnings from porting an existing native Android App to Flutter, and this is the best example I can use to do so. Neither app makes any efforts in terms of architecture; it’s purely about development experience and using the frameworks as they are.
Exactly one year ago, I published my first Android App in the Play Store. The app (Github) is pretty basic in terms of architecture and coding conventions; it was my first big open source project, which shows, and I’ve since come a long way with Android. I work at an agency, and spend time on quite a few projects with different technologies and architectures, including Kotlin, Dagger, RxJava, MVP, MVVM, VIPER and others, which has really helped my Android development. That being said, over the past few months, I’ve been getting frustrated with the Android framework, especially regarding incompatibility and how counter intuitive it is to build apps in general. Don’t even get me started on build times… (I’d recommend this article, which digs into more details) and while things have gotten a lot better with Kotlin and tools like Databinding, the whole situation still just feels like putting a band-aid on a wound that’s too big to be healed. Enter Flutter.
I began using Flutter a few weeks ago when it entered beta. I looked at the official documentation (which is great, by the way) and started going through the code labs and how-to guides. Quickly, I began to understand the basic ideas behind Flutter, and decided to try it out myself and see if I could put it into use. I started thinking about what kind of project I should work on first, and I decided to recreate my first Android app. This seemed like an appropriate choice as it would allow me to compare both “first-efforts” with the two respective frameworks, while not paying too much attention to app architecture, etc. It was purely about getting to know the SDKs by building a defined set of features. I started by creating the network requests, parsing the JSON and getting used to Dart’s single-threaded concurrency model (which could be the topic of a whole other post on its own). I got up and running with some movie data in my app, and then started creating the layouts for the list and the list items. Creating layouts in Flutter is as easy as extending the Stateless or Stateful Widget classes and overriding a few methods. I’ll compare the differences in building those features between Flutter and Android. Let’s start with the steps required to build this list in Android:
Create list-item layout files in XML
Create an adapter to inflate the item-views and set the data
Create the layout for the list (probably in an Activity or Fragment)
Inflate that list layout in the Fragment/Activity
Create instances of the adapter, layout-manager etc. in the Fragment/Activity
Download the movie data from the network on a background thread
Back on the main-thread set the items in the adapter
Now we need to think about details like saving and restoring list-state…
… the list goes on and on and on
This is, of course, tedious. And if you think about the fact that building these features is a fairly common task — seriously, it’s not some particularly rare use case that you’re unlikely to ever run into — you might find yourself wondering: is there really no better way to do it? A less error-prone way, maybe one that involves less boilerplate code, and increases development velocity? This is where Flutter comes in.
You can think of Flutter as the result of years of lessons that have been learned on mobile app development, state management, app architecture, and so on, which is why it’s so similar to React.js. Doing things the Flutter way just makes sense once you get started. Let’s look at how we can implement the above example in Flutter:
Create a stateless widget (stateless, because we just have static properties) for the movie item, which takes as it’s constructor parameter a movie (as a Dart class for example) and describes the layout in a declarative way while binding the movie’s values (name, release date etc.) to the widgets
Create a widget for the list like so. (I kept this example simple for the sake of this article. Obviously, we would want to add error states etc and this is just one of the many things of doing this kind of work).
You can find the full article here: https://proandroiddev.com/why-flutter-will-change-mobile-development-for-the-best-c249f71fa63c