• Why every Android Developer should try out Flutter
  • By Aaron Oertel
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: ALVINYEH
  • Proofreader: DateBro

A few months ago, I wrote about why Flutter can Best Change mobile development. Although it has been a while, my love for Flutter is still very strong; In fact, as I continued to use it, I realized that I had overlooked the importance of Flutter’s unique aspects. Don’t get me wrong — I still think that one of Flutter’s greatest strengths is how it solves many of the problems of cross-platform development. But lately I’ve been looking at more areas of mobile development, particularly the concept of declarative user interfaces.

Chris Charles from Unsplash.

I’m sure you’ve heard a number of arguments for why Android developers should pay attention to Flutter (if you haven’t, let me humbly suggest you look at this one), but I’d like to point out one big problem THAT I haven’t really addressed yet, That Flutter can give you a completely different perspective on App development. First, your application itself will be built differently — but more importantly, the actual UI development is pushed to the fore by incorporating it into your Dart code rather than XML, thus making it a “first-class citizen.” Once your UI code pops up in a non-markup language, you realize that you suddenly have the possibility to build applications. To be honest, I started to hate writing UI code on Android after using Flutter; Because the steps are more cumbersome on Android, you can still build responsive applications using tools like data binding, but it actually takes more time than Flutter.

The argument for using Flutter becomes even stronger when you consider integrating animation and other dynamic data in Android. Integrating animations can be inconvenient, and sometimes you may have to say no to a designer because it’s too hard to do what they want. Thankfully, Flutter changed all that. If you’ve been following Flutter, you’ve probably heard of the Flutter challenge from Fluttery. These challenges demonstrate how fast and intuitive it can be to build complex UIs with lots of custom components and beautifully designed (including animations). Implementing something like this on Android would be very difficult — especially because, unlike Flutter, Android views are based on inheritance rather than composition, which makes building views more complex.

Now, let’s cut to the chase: Building declarative UI with Flutter changes everything about UI development. Now you might be wondering, isn’t Android layout built declaratively too? The answer is yes, but it’s not. Using XML to define the layout gives us a feel for defining the layout declaratively, but this is true if your view is completely static and all the data is set up in XML format. Unfortunately, this almost never happens; Once you add dynamic data and things like lists, you naturally have to use some Java/Kotlin code to bind the data to the view. And then we end up with some kind of ViewModel that sets the data as a view. Imagine this is like calling textView.text = “Hello Medium!” on Android. The same. With Flutter, this is completely different: you create a window component class that contains a certain state, and then define your layout declaratively based on that state. Whenever the state changes, we call setState () to re-render the part of the component tree that we changed. Let’s look at how to use the API in Flutter and render a List with the result:

@override
Widget build(BuildContext context) {
  return new FutureBuilder<Repositories>(
    future: apiClient.getUserRepositoriesFuture(username),
    builder: (BuildContext context, 
        AsyncSnapshot<Repositories> snapshot) {
      if (snapshot.hasError)
        return new Center(child: new Text("Network error"));
      if(! snapshot.hasData)return new Center(
          child: new CircularProgressIndicator(),
        );
      returnnew ListView.builder( itemCount: snapshot.data.nodes.length, itemBuilder: (BuildContext context, int index) => new RepoPreviewTile( repository: snapshot.data.nodes[index], ), ); }); }Copy the code

Here, we use FutureBuilder to wait for the network call (Future) to complete. Once the network call completes and results or errors occur, the FutureBuilder component internally calls setState to invoke the provided Builder method to re-render. As you can see in this example, everything is declarative. Doing the same thing on Android usually requires a passive XML layout and then some other classes to manually set the state, such as Adapter and viewmodel. The problem with this approach is that the state may be different from the rendered state on screen. This is why we want to have a declarative layout like the one that Flutter provides us. We ended up writing much less code, while binding the state to what was displayed on the screen.

With these declarative layouts, we also started to think differently about architecture. Suddenly the word reactive comes up, and we’re talking more about state management than architecture. With Flutter, architectures like MVP and MVVM don’t make much sense anymore; We don’t use them anymore, we think about how state flows through our application. States are suddenly becoming a big part of the discussion, and we’re going to be thinking more and more about new ways to build applications. It’s a new journey for all of us, and there are many things that can be solved, but most importantly, it’s a chance for us to broaden our horizons.

Frankly, there is more to Flutter than sunshine and rainbows. I am currently working on a larger project with Flutter to understand its weaknesses, and the biggest flaw I have encountered so far is the lack of infrastructure. This problem was obvious when I tried graphQL-API; While there are libraries that do this, they don’t come close to Android’s relationship with Apollo. The good news, however, is that it is only a matter of time before Flutter catches up, and in the meantime it will not be difficult to extend existing libraries or even build their own. Note that you may need to invest some time in your app’s infrastructure, which is usually not the case for Android and iOS — there’s no such thing as a free lunch, after all.

Finally, one of the biggest lessons I’ve learned recently from using Flutter is that it’s useful to experience this declarative way of building UI and its impact on state management. I think Flutter is great; However, I caution you not to use it as a silver bullet to solve all your problems, but rather as an innovative tool to build beautiful custom UIs faster than you can on Android. More importantly, it shows powerful declarative layout capabilities and lets you treat your application as a rendered state rather than as a discontinuous Activity, view, and viewmodel — for that matter, I strongly recommend that you try Flutter.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.