Introduction to the Square Open Source Library flow and mortar

• Original link: architecting an investigation into Flow and mortar
• Translator: Sundroid (chaossss co-translation)
• Proofread by: Chaossss, Mr.simple
• Status: Complete

"Using Fragment instead of Activity as much as possible during App development," Google's official recommendation is no doubt that millions of Android developers are starting to focus on and use Fragment. But with the increase in the number of people using Fragment, Fragment's problems are beginning to be exposed, and in various Android communities, it has begun to question whether using Fragment as a substitute for Activity is really as good as Google says in app development. The reasons for questioning Fragment are broadly as follows:

• When using Fragment, we can only choose to use the default construction method, not the freedom to construct the construction method we want.

• Nested use Fragment are prone to various weird bugs, or are subject to a variety of depressing restrictions.

• The life cycle of the Fragment itself is very complex.

What's more, the reason why this part of the developers stand firmly in the "anti-Fragment" team is that the use of Fragment in the development process does not allow this part of Android developers to feel the convenience and pleasure of using Fragment, instead, using The Fragment brought them endless difficulties and troubles. I don't know what Google is going to think about when it sees these critical Fragment posts ...

But in our Android Learning Community Big Nerd Ranch, our android Bootcamp course has been consistently used Fragment, and to introduce the benefits of Fragment to us (especially Android In addition, we have extensively used Fragment in our information projects.

However, while we are a loyal fan of Fragment, we have done quite a lot of research and exploration on the existing Android library in the spirit of continuous learning and exploring new knowledge, in order to find the best alternative to Fragment and help these hard-suffering Android Developers get out of their misery and move to the beautiful new world of Android development.

Enter flow and mortar

Embracing the tenets of destroying all Fragment in the world, Square introduced two new libraries a year ago: Flow and mortar. As an anti-Fragment, Square also created a number of good libraries:

• Dagger
• Retrofit
• Picasso
• Otto
• And so many more

I just want to say that I believe in them and I think any resources from square may be useful or at least interesting, so their projects are worth seeing.

Before we dive into these libraries, I would like to remind you that Square uses these libraries only in a small subset of projects within them, and that I write articles when they are in the pre-release stage. In other words, the two libraries have made positive progress in recent months, which bodes well for a respectable future, and while the library is like quicksand, it can change, crash or even stop publishing, but the core architectural principles on which the library relies are immutable.

System architecture

First, let's look at the architecture of Android applications before Android Honeycomb is used, and even before the advent of fragment, the standard mode for developing Android apps is to create a lot of Activity. The most common phenomenon at that time was that most developers did not follow the MVC pattern for development, but that was normal. Because the model relies on data, traditional databases are either WEB requests stored as JSON or a variety of Java object enumerations. Developers are happy to set the view for the Activity through the XML layout, and the view's controller is the actvitiy itself that each screen displays.

While this is a brief overview, you can see how the Android and MVC patterns fit naturally.

With the advent of Fragment in Honeycomb, the Android team has made it easier to deal with different forms of events. Today, the standard Android application architecture has been transformed into a small group of Activity and many Fragment that make our apps cross-platform on mobile phones, tablets, smart watches and even spaceships.

Under such a vision, everything about Fragment is good, Fragment becomes popular, and the decomposition of an Activity into several Fragment is advocated. In addition, even though the Activity is often simplified as a Fragment holder, or an interface between the Fragment and the system, the architecture of the Android application still follows the MVC pattern.

But is the activity not fulfilling our App's desire to use cross-platform, or are we not using the activity in the right way? Perhaps, if you combine activity with a custom view, you might be able to make your activity achieve cross-platform use without Fragment. The key purpose behind using the Flow and mortar libraries is to explore the problem and get a definitive answer. Flow and mortar work by using a custom view instead of Fragment and using a specific controller object injected into a custom view to control the view, allowing us to do the work in lieu of the Fragment with view.

We'll build the middle part of the diagram in our discussion and figure out how to piece together different view fragments into one activity without using Fragment. We'll see the standard MVC architecture evolve into something completely different, which will involve a lot of our flow and mortar.

So, what exactly is flow and mortar? How do they work?

Flow

Flow divides an application into a logical screen combination, which is not a special library object of any kind, but a plain Java object (POJO) created to represent our view of the application. Each screen is a self-contained segment of the app, and they have their own features and intentions. The usefulness of a screen is no different from the usefulness of traditional activity, and each screen in the application corresponds to a specific location, somewhat like a URL page in Android or a specific implicit intent. Therefore, the screen class can be viewed as a readable definition of a part of the application.

Each activity in our application becomes a flow object, and the flow object saves a record of screen in the return stack, similar to the return stack of the Activity or Fragmentmanager, which allows us to You can easily switch between them by simply instantiating them without having to include a lot of activity in your app. There is a small amount of Activity (preferably one) to hold these screens. The relationship between them is similar:

We want to switch to a new screen, we simply instantiate this screen and tell us that the Flow object helps us switch to this screen. In addition, as we have expected, Flow is instantiated to implement the GoBack () and Goup () methods. However, many developers think of the Goto statement in Java as a scourge, but in fact the Goto statement in Java does not sound as scary as it sounds.

In essence, Flow simply tells us which screen we're going to switch to in the APP. The advantage of this design is that Flow is designed so that we can easily switch between the various custom View definitions we define, and keep us from the hassles of Activity or Fragment, allowing us to focus on dealing with the view. Flow has created a simple, convenient, view-centric application architecture for us.

Mortar

Mortar is a repository of focus drag and dependency injection, mortar an application into composable modules with several different sections: blueprints, presenters and a boatload of custom views.

Every part of the mortar app (in this case, every screen, because we're using Flow) is defined by Blueprint and gives them a private Dagger module. It looks a little like this.

Flow and mortar work together well, we just need to adjust our screen class to implement the Blueprint interface provided by mortar, and it will give us a free-to-use Dagger scope.

Presenter is a view private object that has a simple life cycle and bundles that accompany its life cycle, and is primarily used as the controller for that view. Each view has a Presenter that exists in the corresponding screen (and Blueprint) associated with the view itself. Because Presenter can only be used on his screen, when we use Flow to enter a new Screen,presenter (a very important part of our architecture) it is likely to be automatically reclaimed by Java's garbage collection mechanism. In addition, the Dagger in the mortar scope will be combined with the automatic garbage collection mechanism, which allows our App to better manage and use its memory--of course, the controller objects that are not currently in use are being reclaimed by us. In the traditional activity development, the Fragment and activity of the switching process, the casual garbage collection is not very good to be noticed and beware.

Since custom View is used frequently in our architecture, we simply inject all the important model data through Dagger and then use the Presenter associated with the view to control the view itself. Even if the configuration is changed, presenters will not disappear, and we know very well the knowledge associated with the Activity life cycle, so that presenters can be recovered after the process has been killed. In fact, Presenter is linked to the bundle hooks of the activity onsavedinstancestate () method, allowing it to store and read the data generated by the configuration changes using the same mechanism as the activity. The life cycle of the Presenter is very simple, with only four callback methods:

• Onenterscope (Mortarscope scope)
• OnLoad (Bundle savedinstancestate)
• OnSave (Bundle outstate)
• Onexitscope ()

There is no such a complex life cycle as Fragment, this is not my blow!

There is a lot of moving parts and new terms and classes and all sorts of the class for confusion. So in sum, we have the following pieces of the puzzle:

• Screen:a particular location in the application ' s navigation hierarchy
• Blueprint:a section of a application with its own Dagger module
• Presenter:a View-controller Object
• Custom Views:views defined by Java and usually some XML

In this article, you will find that there are many changes in Flow and mortar, new terminology and classes, and new usage rules that will inevitably make people confused. So in order to facilitate everyone's understanding, in general, we need to pay attention to the following parts:

• Screen: A special presence in the application navigation hierarchy that is used to represent the object of our view
• Blueprint: Part of an application that has a private Dagger module
• Presenter: a View Controller object
• Custom views: defined by Java code View, of course, XML definition is also very common

Here's what we final mortar and Flow architecture looks like:

We mortar and Flow the whole architecture will look like this:

Instead of sticking with model view Controller, the architecture have morphed into more a Model view Presenter style. The big difference concerns the handling of the runtime configuration changes like rotation. In MVC, our Controller (activities and fragments) would be destroyed alongside we views, whereas in MVP, only our View wil L be destroyed and recreated. Nifty.

Abandoned the obsession with the MVC pattern, which became more like MVP mode after it was completed. Such a huge shift makes the new architecture need to focus on how to handle the problem of application configuration information changes at run time, such as: rotation. In the MVC pattern, our controllers (Activity and Fragment) are killed along with our View. However, in MVP mode, we only have View
Be killed and reproduce it when it is needed. It's funny, right?

Positive feedback

In order to get rid of Fragment,square to pay a lot of sweat to re-structure and design, and completed the mortar and flow library, they will certainly get the corresponding return, then I will give you the two libraries to bring us the benefits of it.

Using the mortar and Flow library forces us to create a modular APP structure that matches the MVP pattern design, which effectively helps us keep our code tidy.

Testing is made easier with dependency injection of our custom View and presenters

Animations can be processed in the View layer, rather than worrying about bugs as they used to be in Activity and Fragment

Mortar automatic garbage collection in the View and Presenter layers to handle its scope means that the application can use memory more efficiently

Space to optimize

While Flow and mortar have brought us many benefits, there are still some problems:

To be proficient with Flow and mortar, you need to face a steep learning curve. before you really understand the design ideas and principles of the two libraries, their usage patterns look very complex, and if you want to use them handy, there is no doubt that a lot of exploration and experimentation is needed, and these libraries are not for beginners, we recommend beginners to learn how to use them correctly and effectively. Activity and Fragment, I am not scaring you, so to tell you, even if the Android development God, in the face of these libraries still need to spend a lot of energy and time to learn about design patterns, to really understand this library.

If you're going to use the mortar and Flow libraries, you really need to get a full picture of their usage. because it is difficult to interact with the standard "less-use-Fragment" development model. If you want to modify an already written project, let it use mortar and Flow, although not impossible, but the process of accomplishing this goal will be very long and difficult.

There are also countless templates and configuration information that need to be processed. and this is my biggest worry, when using these new classes and interfaces, I often feel overwhelmed by the uninteresting code ocean, because the code is designed to hook up with the various classes and interfaces in it, and the design makes me feel that the two libraries are not as interesting as I expected.

What's next?

But now the mortar and Flow libraries are in the pre-release phase, and there are no officially released versions. This means that Square is still dealing with the problems, changes, and updates that exist in both libraries, but it also means that they need a lot of time to improve before they can really get into use.

Using the mortar and the flow library is an interesting experience and I am enjoying the alternative of using a variety of new libraries and looking for an official Fragment-oriented application structure, but I don't think mortar and flow are the alternatives to Android looking for Fragment, after all Fr Agment may be modified in the next few months or years. But I still hope that these projects will attract more attention, and continue to optimize, I will certainly continue to pay attention to their latest progress, I hope you continue to follow my blog Oh.

Introduction to the Square Open Source Library flow and mortar