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)


IOS:

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

Android:

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…

What I learned from Kotlin Flow API

I used to check the docs and just read a lot about flows but didn't implement anything until yesterday. However, the API tasted really cool (even though some operations are still in Experimental state).Prerequisites: If you don't know RxJava it's fine. But a RxJava recognizer would read this faster.Cold vs Hot streamsWell, I really struggled with this concept because it is a little bit tricky. The main difference between cold and hot happened to be pretty simple: Hot streams produce when you don't care while in cold streams, if you don't collect() (or RxJava-s equivalent subscribe()) the stream won't be activated at all. So, Flows are what we call cold streams. Removing the subscriber will not produce data at all, making the Flows one of the most sophisticated asynchronous stream API ever (in the JVM world). I tried to make a illustration of hot and cold streams: Since I mentioned the word asynchronous this implies that they do support coroutines also. Flows vs…

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…