At first, because of the business comparison, we have not done a better top-level design, the code requirements are the minimum requirements-the completion of functional development on the line. This short-term design also causes our code to be almost zero in scale, adding a little bit of new functionality. When the backend system architecture is switched from TCP to HTTP, these drawbacks are magnified to the extreme ... So, we only have to refactor. The focus of my work over the last one months has been to plan and design the code structure of our project, and share it with our Android team and implement it. Because I studied a lot of architectures, including Android-related, and non-Android-related, I've flipped through a little bit of help with my design architecture. Even to understand, some of the micro-blog Project structure Information ~
However, in this process, I found that in fact, Android does not have a more stable framework like Java background development, can be directly applied, basically all have their own views and rules. The most discussed at present is the so-called MVC, MVP, MVVM-like MVX framework. In order to pave the way for our central idea, let's analyze how these so-called well-known decency is really as we think.
One, MVC, those things.
Let's look at MVC first, because MVC is often mentioned in Android development. Let's take a look at the structure of MVC, usually the answer you use when you're interviewing for questions about MVC.
The MVC method of communication is a ring-like pattern, as shown in the diagram on the left: The view transfer instruction to Controller;controller to different levels of organizational action, to control the application process. It handles the event and responds. The "event" includes the user's behavior and the changes in the data model, the model sends the new data to the View, the user gets feedback, and all the traffic is unidirectional.
Theoretically, it's quite reasonable, but in fact, it's easy to see how deep they are coupled. Usually a change, the basic three levels have to be changed, because their trigger is very strong coherence. More specifically, if you are actually writing code rather than stopping it theoretically, the MVC structure should be described in the right-hand image, which means that the external connection of V is bidirectional, because M needs to change V's requirements and the controller has one.
Well, we're going to go to Android now, assuming that we're dealing with the Android problem with MVC, it's clear that the heap of XML is view, and activity is the so-called Controller,model that we define as those data objects. But obviously Android inside the XML as a view layer is simply a little weak hand versus feeling, in addition to set the point properties, almost no logical operation. So, usually we will use Activity+xml as the view layer in order to enhance the function of the view. In practice, however, such a combination is far beyond the scope of the view, because the activity usually takes on a lot of logical operations, the so-called Controller's responsibility ... Now we is totally mixed up! Because you are not able to accurately stratification. Because MVC is primarily used in strong view development mode, such as desktop applications, because as long as the view is strong enough to play the power of MVC, it is clear that Android native does not have this ability, unless you write a view frame yourself, this is not what the injection of the tool class, Those just help you reduce the amount of code, and not fundamentally solve the problem, here the view framework is a set of enhanced Android native view framework.
So, it is obvious that native MVC is not suitable for direct use in the development process, where the addition of a native MVC is for "the answer", because if you derive, the amendment is another thing ~
Two, the MVP thing
MVP can be said to derive from MVC, because there are problems to solve. Since MVC is not good enough, let's fix it! So the MVP comes out (even though the first MVP is the application of desktop apps like MVC ...). )。 This is shown in the figure below:
MVP Communication method: the communication between the parts is bidirectional; Here the view is not associated with the Model, all through Presenter (you can also call controller~). This structure is ideal for Android's view layer, because the MVP structure has a very thin view, no business logic is deployed, basically a "passive view" (Passive view), which means that there is no initiative, and of course, presenter is very thick, All the logic is deployed there. In fact, when we use, we tend to be more on the right, because since presenter has a great responsibility, no matter how many points, but better unified management ... So we can also weaken the model's ability, that is, the model layer is completely passive to provide data, class database schema.
I personally think that the upgrade to the MVP is already very good, at least structurally more clear than the MVC, the only problem is that we presenter a bit overweight, or there are improvements, we will be in the post one by one.
iii. MVVM those broken things
Why do you use MVVM for those "broken things"? Because we found that at least for now, I didn't see a more normal analysis of MVVM on Android. Because now in Android, the mention of MVVM is dagger, like DAGGER=MVVM ... But in fact, is not so, dagger class tools, just to achieve the view and model of automatic two-way binding, that is supposed to call view.setxxx to the model value assigned to the view to show, now do not (this "no", It's just that programmers don't have to write this code explicitly ... , so the so-called View-model in MVVM can be said to be presenter, just because we have the data of the two-way binding tool, so that the link between the presenter and view into a dashed line, and model to maintain a two-way connection, The model is bound to the view. So, rather than an MVP optimization, MVVM is more of an optimization of MVC than that. MVP and MVVM are just two different ways to optimize MVC--MVP selection to continue layering, while MVVM chooses to reduce tiering. Perhaps, you may still have no special feeling for these so-called mvx after reading them. Starting with the split line, we begin to think more deeply about the problems we are experiencing ~
whether it's MVC,MVP or MVVM, they're more like a software development idea than a model. Because if you define him as a pattern, you will find that they are on the mobile side, the mobile side has sub-ios,android and WP, as well as web-side, PC-side implementation of the way there is always a certain difference. Just like MVC, some implementations are a clockwise scheme, others will isolate the MV, all on C. Just like the example I gave above, some people might think, right, not another picture? But when they continue to rely on search engines, they will be messy, because there are various logical architecture diagram and each has its own truth, the most deadly is no one will say which is wrong. In fact, you've gone astray since you started looking for their template.
only by thinking of these so-called architectures as a solution to the problem can we realize this idea on the basis of realistic and specific problems such as different platforms and different business requirements. Plainly, Marxist guiding ideology is very good, but it must conform to China's national conditions. Is it clear that we should go back and look at the problems we encountered before, based on these new ideas? Just like MVC, no matter how many variants it has, they are all designed to better implement the idea of MVC layered decoupling. everyone to search online Android MVVM, there is no feeling almost all involved databinding, and then introduce some databinding usage ... And then it's gone (just a little bit, you'll be a little bit better with Google for this question). And obviously, based on our newly established ideas, these posts can be completely one-sided and fraught. Becausefor DataBinding is just a tool for implementing the idea of MVVM, which is to help you bind the view and model, and without this tool, you have to implement the idea of MVVM, You will also write a binding util class to do it yourself. second, after the completion of the binding, it is necessary to operate closely related to the business ViewModel. If it is simple, then why do we need such a complex implementation? (We all know that some of our pages are actually very simple, simple to you are embarrassed to say that you did ~). If the business logic is complex, you still need other ideas to break down the behemoth. To say this is to be able to see these so-called patterns in a different perspective. At the same time, we also want to remind you not to rely too much on the online search, which includes both blogs and GitHub. Because real big God is really very few, the false big God everywhere is. We search as far as possible to refer to the main, copy supplemented. Instead of the reverse-here's an example, if a classmate has used itemtouchhelper, and also searched the Internet, you will find that an example of the entire universe (you know ... , and in fact, just look at the source code of Itemtouchhelper, and you'll find there's a totally friendlier way.~let's go back to the chase.all software architectures and development ideas are for four purposes: maintainable, testable, flexible, independent. That is, make the softwarebetter maintenance, testing, scaling, and relative independence on the basis of satisfying requirements.
Good maintenance means that the code structure is clear, easy to understand and modify;
A good test means that the module is relatively independent, the coupling is low, and the external dependence is to keep the reference;
a good extension means an interface specification that can extend the business at any time;
relative independence means that the external system can operate in a relatively independent state;others are well understood, but what is the independence of applause? let's say that iOS is also developed in Java, how do you get this set of code to move smoothly from Android to iOS? Do you have to define a good view interface and some other interfaces that involve the system API, and when migrating to iOS, you just have to implement these interfaces to make the code run properly on iOS systems. in fact, it is to put their own app as an independent system to develop, it is assumed that external dependencies are likely to change, not only refers to the background, even including the system itself. We all have to be able to cope. originally want to continue to write down, but I think, knot or put my ppt as a conclusion, let everyone slowly realize it. Because thought to practice will always be due to the actual environment, but the core of those themes will never change ~
About the Android architecture.