Cross platform app development with flutter

Editor's Notes

• #2: I will skim a general aspect of Flutter and not going too deeper. Due to the nature of language/framework introduction, there are quite lot of texts inside this slide. Yes. it’ll be boring, I know. But please be patient only for 30 minutes. BTW, you wonder why I put “bright and dark sides” as subtitle? Because I thought Flutter could be a silver bullet of mobile app development, but it’ll be scarcely possible even if Flutter is not in a BETA stage. I’ll explain it later. So, let’s take a look.
• #3: I will talk these 5 subjects. I wish I could add another section that comparing Flutter development experience vs React Native, but this is a short talk, maybe next time.
• #4: Looks very similar to Java at first glance! Personally I really dislike typedef because I think it is powerful but easily to be spoiled. So I put the comment at top of it. Let’s have a look of another Dart snippet.
• #5: What is the difference between final and const? What in the earth of static const or static final? What is the context of keyword ‘static’ in dynamically typed language? Is this an abomination of Java or what? This was my first time expression. Coding in Dart looked definitely sucks to me. However, I said this is “at the first glance” thing so understanding the core concept of the language is necessary. At the final stage you can accept this ‘strange’ syntax. Yet in my case it tooks almost a month though.
• #6: Dart is neither a Java minor copy, nor an abomination. Literally it’s different. Although I said it’s a Java bastard, but it means the learning curve of the language is not steep, because Java is so popular and everybody knows it. Think about the name “Javascript”. Dart could be procedural. OOP style is not mandatory but preferred. Functional coding is also possible. Talking about Smalltalk/Strongtalk. Yes, every types in Dart are objects. However, built-in types are acting very similar to Java’s. Basically Dart is dynamically typed language. All type annotations are OPTIONAL. There’s no function overloading. You may think ‘meh.. No function overload’ but modern languages such as Go or Rust also does not supports it so I’ll give no comment. Mentioning about reflection. I’ll talk it later in Flutter section. Single threaded? Well there is Future class which looks like very similar to Java’s, but it’s actually Promise in Python or JS. You can expect some keywords like async, await, then.. and so on. Mix-in? What is mix-in? It’s quite complicated concept to talk, but in short it’s a different way to reuse code by inheritance. This is not a place to lecture difference between code reuse and type reuse, so no more further explanations. No visibility modifiers. In dart, everything only public or private. Actually there is privacy called “library-level privacy” which is similar to “internal” in Kotlin, but this is the big controversy in Dart community as well. Also there are plenty of blog posts about Dart language and why it’s modern and cool. I think my presentation is not a good material to demonstrate the good side of Dart. BUT!!! With title “My experience blah blah”, I’m still quite against to this language actually. It doesn’t mean that Dart is BAD, yet It’s just not a right tool for me. No offense however; because of my professional background, my personal preference is biased to statically typed programming languages. Therefore these are features list of Dart which I dismay, actually. I know that somebody who loves Dart a lot would say I’m talking a bullshit. Yes, because my Dart understanding is still in a novice level. Again, I will not say Dart sucks, but my experience with it was definitely uncomfortable.
• #7: This is the brief explanation of Flutter. Looks quite decent at the first moment. Personally, amongst all, IDE perfect integration is strong point compare to RN in my opinion. Flutter plugin for visual studio is also quite good. Also, Google’s Flutter team officially mentioned that Flutter is greatly inspired and tried to follow the nature of RN, so strong points of RN is also applied to Flutter too. What is “everything are reactive” means? Well, all of the UI components will not change until we apply any data changes on it. Even the native UI lifecycle cannot. This is quite promising to whom have an experience about lifecycle management of Android Fragments. This makes UI logic quite simple. I dislike the JSX feature of React Native because it does not looks like a code but embedded inside our logic. Sorry to say but it reminds me the nightmare of JSP model 1. In Flutter, we code UI in Dart, not in XML, JSON or something else. Of course both are conceptually same, but I prefer to split concepts which are not ‘fluently compatible’.
• #8: I said StatefulWidget and StatelessWidget and its inheritances *should be* immutable, but actually it *must be* to not break the ‘Widget’ architecture. Sounds confusing. I’ll talk this later. UI navigation method is simple push-pop model, but handy especially compare to native Android thing. In Android, every Activity(a unit of whole screen) could be an entry point and navigating between those with data is very clumsy. IPC like calls must be made on every screen transition in Android. However in Flutter, we can just code like “Show another screen, wait for its response, and do my own job” in a same call site(no onActivityResult callback), which could make our code nicer in simple navigation case. No reliance on platform widgets. Flutter team said it’s a strong point of Flutter. IMO, this could be controversial. Actually there WAS an graphic toolkit library which has same concepts in 18 years ago and still used but scarcely. Imagine what? It’s SWING. Dart’s UI is not sluggish compare to Swing’s because it’s run on OpenGL canvas, but occasionally you can notice that something is unnatural. Consistent 60FPS sounds nice but there’s a caveat: no complications inside redraw mechanism called setSate, I’ll explain it later. Another good thing for Android developers is, our Dart logic is directly compiled inside of SO file. It means decompiling is much harder and we can protect our code from script junkies at least.
• #9: Nobody really cares about Dart. This is actually a huge problem. Although Dart is modern and nice, but… I don’t think Dart is better than Kotlin or Swift. Even there’re no any rants about “Why Dart sucks” or something like.There’re plenty of “Why Kotlin sucks” or “Why Swift sucks” rants already over the web - think all of these languages are considered as “Modern”! Among the other things, no reflections allowed in Flutter really makes me doubt about whole framework’s future. Dart team officially explained why it’s impossible in Flutter but let’s think beside of those “under the hood” thing. Suppose you code a huge sized project with Flutter. Imagine there are about 30 JSON APIs to handle. Writing all serialisation/deserialisation logic manually must be tedious. But there’s no plan B. Still somebody may say it’s acceptable, but not for me. We can communicate native logic via “platform channels” but only data are exchangeable at the stage. This is why there’s no factory Flutter MapView widget yet - there’s reference implementation via Google maps static API though -. Hope the Flutter team solve this problem soon. Although iOS style in Android or Material design in iOS is accepted but it must be very unnatural to platform fanboys. The keyword “cross-platform development environment” sounds like it will free us from the problem. However, there’s no such silver bullet - there are two concrete implementations of MaterialApp or CupertinoApp. More worse, we must choose it by manually. We have to put logical decisions before drawing if we truly want to make a natural app with same codebase. Lack of factory built-in Cupertino widgets is also a huge minus. Therefore we still have to think about our own abstraction strategy about basic drawing rules of UI, navigation, etc. within cross platform dev environment. But don’t be disappointed. Yet Flutter has these dark sides, but it’s still in BETA stage and there’s hope that the situation gets better.
• #10: Thinking about the word ‘invalidate’, an experienced developer can imagine “when we could state the UI is clean, dirty, box range, visibility, etc.”. I think setState() approach is much nicer than invalidate(), because those jargons I spoke is actually low-level thing. Mostly, we don’t have much chances to think about it, even if we’re developing a complex app. Unless if our app consisted by 100% custom UIs.
• #11: The term “BuildContext” in this slide is, a context of building our UI. What is a context then? It holds various information - parent group of this UI, box size of it, screen density, orientation.. such things.
• #12: In this diagram, we can imagine that… If there’s a “Button text” attribute in State object, we can change it and change itself by calling setState() method. Any UI attributes we can think easily, like “text/background colour” and so on, could be done by same mechanism. This approach was nice because we have to think how to separate state manipulation and UI drawing, by lead of the framework.
• #14: React native is more mature than Flutter in Mar. 2018 current, and you don’t need app store requirements for your webapp. I said it might replace Android development, but wait. Isn’t this a cross platform supported tool? Because the major target of Flutter is “Fuchsia” currently Google is working on. Not even for Android. However, as we know the result of Java fight between Google and Oracle… Google might deprecate our good old Android but I think it won’t be happen in near future. Also… as I mentioned, there always could be a Platform abstraction problem which could never be solved, so Flutter can’t be our silver bullet.