Skip to main content

Getting hands dirty with Flutter

An Android Developer point of view.

 I have never been a fan of cross-platforms until Flutter came by. Actually, it was my first experience with cross-platforms. Never have I ever tried React Native, Ionic or whatever. But what was intriguing about Flutter? Well, since I am a Google fan and a Native Android Developer, i thought I should give it a try.

Jumping into Flutter was pretty easy. They have simple documentation comparing to the Android Developers documentation, and I think it has a lot more details and better best-practices. Also, Android Studio supports flutter development by just installing Dart and Flutter plugins. So the only real configuration I made was telling Android Studio where my Flutter SDK location was.

In order not to transfer this article to a tutorial, I'm just going to point out, what I think Flutter development is comparing to Android.

Honestly, Flutter is simpler.
Even though I was an inexperienced programmer when I started Android, I remember a lot of struggles when having to face a bug or implement something new in Android. I expected to face more trouble with the State, since should have been a new concept but I got into it pretty quick.

Dart > XML for design
The easiest thing I'm going to point out here, is a BottomNavigationView, or a BottomNavigationBar (flutterly speaking). While in native code you have to care a lot about what happens when you press one element of the Navigation, in Flutter it's pretty simple:

However, I still think as a Flutter beginner that the syntax is pretty strange comparing to the heavy Java and Kotlin structure (and Java's verbosity of course).

There are a lot of Widgets
 Looks like I had to google a lot about implementing the right widget. I admit that I should have read the docs more, but still, widgets in Flutter are too many comparing to the Android Development views.
I loved lists.
A pain in the Android world is RecyclerViews and Adapters. They are not hard, but every time I have to create a list and display some data, I have this immediate reactions: "Oh great. Another adapter". In Flutter ListViews or GridViews were just too good.

Futures were great.
 While Android has made a lot of improvements in Futures (or Deferred responses to be exact), still, I loved the way dart manages asynchronous methods:

Adding some FutureBuilder support, Flutter Futures are just sweet.

Note, one thing I learned in Flutter, is that if I'm overthinking how to solve the case, perhaps I'm doing it all wrong or know nothing about the problem.

Kotlin > Dart
Yea, Kotlin is a better language to program comparing to dart. They do look the same in some cases but my experience with Kotlin has always been very easy.

Flutter lags a little
Perhaps I didn't google enough, and my loading images had a high quality, but I did experienced lags and shakes especially on the web (even though we know web build it's still not ready for production yet).  

I still don't know why can't I build a debug version for the web
The localhost:WHATEVER doesn't load a thing (The page was always blank. I didn't find much in Google, if you can help please share.), while building a release was pretty easyOne thing to keep in mind is that you must prepare the project to support web. Overall it's just 4 commands on the terminal.

TypeScript > KotlinJS > Dart.js on the web-perspective.
Well, even though I'm not experienced in the web development at all, I have tried Angular and I still think that no language is able to compile to JavaScript better then TypeScript.

Project overview: Just retreive some data from some API and make some List Rendering, usual things

The web version: (recently changed to new design)


Since I own an Android device, I'm using XCode's Emulator


Since I own an Android device, this is just a screenshot from it.

The performance is nearly the same.

Best of luck.

Popular posts from this blog

Modularizing your Android app, breaking the monolith (Part 1)

Inspired by a Martin Fowlers post about Micro Frontends, I decided to break my monolithic app into a modular app. I tried to read a little more about breaking monolithic apps in Android, and as far as I got, I felt confident to share my experience with you. This will be some series of blog posts where we actually try to break a simple app into a modularized Android app.

Note: You should know that I am no expert in this, so if there are false statements or mistakes please feel free to criticize, for the sake of a better development. 

What do you benefit from this approach:
Well, people are moving pretty fast nowadays and delivery is required faster and faster. So, in order to achieve this, modularising Android apps is really necessary.You can share features across different apps. Independent teams and less problems per each.Conditional features update.Quicker debugging and fixing.A feature delay doesn't delay the whole app. As per writing tests, there is not too much difference about…

From Gson to Moshi, what I learned

There is no doubt that people are getting away from GSON and I agree with those reasons too. The only advantage GSON has over other parsing libraries is that it takes a really short amount of time to set up. Furthermore, the most important thing is that Moshi is embracing Kotlin support.

First let's implement the dependency:
implementation("com.squareup.moshi:moshi:1.8.0") It's not a struggle to migrate to Moshi. It's really Gson look-a-like. The only thing to do is annotate the object with @field:Json instead of @SerializedName (which is Gsons way for JS representation):

data class User( //GSON way @SerializedName("name") val name: String, @SerializedName("user_name") val userName: String, @SerializedName("last_name") val lastName: String, @SerializedName("email") val email: String ) data class User( //Moshi way @field:Json(name = "name") val name: String, @field:Json(name = "user_name…

Modularizing your Android app, breaking the monolith (Part 2)

This is part 2 of a series of articles about modularizing Android app. If you haven't yet read the first article, you may find it here.

On our first article we just moved some classes outside the application and applied as an independent module. But what if we have dependencies pulled from the application level? This could be a small challenge. First of all, we want to clarify on how are we going to modularize the app. And depending on the previous article, I chose the by feature version of modularization. First of all, let's show some dependencies that are going to be needed in the whole app.

Note: I'm using Dagger for handling dependencies but manual DI or any dependency tool should be fine to understand this part.

So, this is my dependency schema:

Well, it's not that bad, but this isn't what we want to transform to when trying to modularize the app. If you think about it, modules that don't need a dependency, can get it quite easily. For example: A FeatureXVi…