Brief explanation of Flutter(Android / iOS cross platform development framework made by Google), presented on May 2018 at developers meetup, by Hyperconnect Inc.
The Role of IoT and Sensor Technology in Cargo Cloud Solutions.pptx
Cross platform app development with flutter
1. My cross platform app
development experience with
Flutter
And its bright and dark sides
16 - May - 2018
Francesco Jo (nimbusob@gmail.com)
2. Table of Contents
- Dart language characteristics
- Bright and dark side of Flutter
- Live code demo
- Conclusion
3. Dart language at the first glance (1/2)
- JAVA minor copy / Degenerated Groovy
// Thanks god it would be hopeless if there’s macro in this language
typedef O transformer(I input);
typedef void VoidCallback();
abstract class StateTemplate<T extends StatefulWidget> extends State<T> {
bool _isBuilt = false; //// Library-level private
@override void setState(VoidCallback fn) {
if (_isBuilt) {
super.setState(fn);
} else {
fn.call();
}
}
}
4. Dart language at the first glance (2/2)
- JAVA styled Javascript… or something… an abomination?
var name = 'Voyager I';
var year = 1977;
var antennaDiameter = 3.7;
var flybyObjects = ['Jupiter', 'Saturn', 'Uranus', 'Neptune'];
var image = {
'tags': ['saturn'],
'url': '//path/to/saturn.jpg'
};
static const String label_ok = “Okay”;
final myObject = new MyObject(); // Reference(s) inside object can be modified
const personality = const Personality(); // Object is totally immutable
5. Dart language characteristics
- Similar syntax to the most widely used programming languages
- Could be procedural / object-oriented / functional
- Syntactically no primitive types. Smalltalk/Strongtalk in action?
- No function/method overloading
- Mirror(Reflection) support
- Single-threaded programming model (async/await, .then(...))
- Code reuse by mix-in
- No public, private, protected
6. Flutter explained - the bright side
- Still in BETA - many things would be better in the future
- Greatly inspired by React Native(RN)
- Small but very responsive developer community
- Internationalisation(i18n), localisation(l10n) support
- Material, Cupertino design support
- Perfect IDE integration with IntelliJ IDEA or Android Studio
- Hot reload support
- No freakin’ UI lifecycle, everything are reactive
- No JSX
- 100% Open source
7. - Literally everything in Flutter is “Widgets”
- Easily to code business logic inside UI logic, which seems not
desirable(Reactive architecture is forced to avoid this problem)
- UI can be formed with composition of StatefulWidget and
StatelessWidget, those should be immutable
- Simple(push-pop) but handy UI navigation
- No reliance on platform widgets
- Consistent 60 fps environment
- No bytecode/IL/JS source inside package. Damn hard to reverse-engineer
Flutter explained - Flutter original
8. Flutter explained - the dark side
- Dart as the first citizen programming language
- No Reflection support(although Dart allows it). No excuse, this is inevitably
BAD for large scaled applications
- Embedding native UI is IMPOSSIBLE in 2018
- We must choose MaterialApp or CupertinoApp by our own
- If you code your MaterialApp strongly dependent to Material Scaffold
and trying to code iOS side, you’re doomed
- Lack of iOS examples and factory default widgets
- I18n support is nearly useless in 2018. Produces non-compilable code
9. Flutter’s Reactive architecture
- According to the official document:
- Everything’s a Widget
- Every logic are separated as 2 categories: UI changer or not
- We can tell state-changer is “Stateful”, and standalone logic is “Stateless”
- There are StatefulWidget and StatelessWidget in Flutter
- Only StatefulWidget can hold its state
- No invalidate(), but setState() for our custom State<T> bound to
MyCustomWidget extends StatefulWidget
12. Live code demo
Demo with more practical case
- Fetches list of image metadata from network
- Parse the metadata
- Show a list of image thumbnails and its description
- And let’s see what happens if we change the UI of this list
- https://github.com/FrancescoJo/practice_flutter_imagelist
13. Conclusion
- Different experience vs. ‘native’ Android/iOS development
- Code in reactive way is forced which is a good decision
- Not a silver bullet for “code once, run everywhere” concept
- Dart as first citizen language - most mobile developers prefer Kotlin/Swift, I bet
- Platform abstraction problem will linger forever
- “unnatural” UI sometimes. Maybe fixed, but another problem will arise
- Strong competitor: React Native, Progressive webapp
- Close to “Major upgrade” of webapp (Mar. 2018 current) rather than native
substitute
- Very productive in quick and dirty coding development - good for prototyping
- ‘might’ replace our good old Android development in the far future
14. Good posts to read
- Flutter technical overview
- https://flutter.io/technical-overview/
- “Dart is not the language you think it is.”
- https://developers.slashdot.org/story/13/05/21/2123245/dart-is-not-the-language-you-think-it-is
- “Is Flutter likely to replace Android app development?”
- https://www.quora.com/Is-Flutter-likely-to-replace-Java-for-Android-app-development
- “Why Flutter will change mobile development for the best”
- https://android.jlelse.eu/why-flutter-will-change-mobile-development-for-the-best-c249f71fa63c
- “Using Flutter in a real-life application with 200k downloads”
- https://medium.com/google-developer-experts/using-flutter-in-a-real-life-application-with-100k-
downloads-ab64ecd8e03f
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.
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.
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.
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.
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.
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’.
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.
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.
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.
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.
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.
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.
