Recently, in the summary of the past work, I have thought about some of the structures I have used. Here I share some of my insights, which are also of reference value to other fields.

Choice of architecture

When you need to implement a complete project, you have to think about how to organize the code structure, how to plan the module layers, how to interact between modules, and so on. In the beginning, I tried to apply a variety of architectures, but when I looked back recently, I realized that was a mistake. There are thousands of things in the world, but not many for you.

The starting point of thinking is best triggered from the Angle of change and invariance. It makes sense to start by understanding what has changed and focusing on what has changed.

Let me give you an example. A product with strong operation type often carries out various activities with different activity styles and complicated logic. What has changed is the flexibility of activities. Burying various card styles on the client side not only complicates the client code, but also fails to meet the dynamic capabilities of the activity. Every time a new activity comes online, the client version needs to be updated. Instead, it’s much better to put the change on the server side, where the client is just a showcase and no longer needs to know the business details. The client provides basic display capabilities, such as login, download and other basic operations, and the server can flexibly display cards by issuing corresponding instructions through a good agreement between the two parties.

Android Clean architecture

Usually with the apps we develop, what changes the most are the business requirements. On such a product, new features are likely to be added and old features fixed with each iteration.

Clean Architecture

For such applications with frequent service changes, basic work needs to be done locally on the client and the architecture should be universal enough to support the addition of new services. Meet such architecture has a lot of, is recommended here [Clean architecture] (https://github.com/android10/Android-CleanArchitecture).

There are many articles on the Clean architecture that I won’t go into here, but if you are interested, you can see the links below.

  1. A cleaner Android architecture
  2. Architecting Android… The clean way?

Again, what is changing are new business requirements and adjustments to older businesses, and therefore a very scalable and robust architecture needs to be provided here.

Event-driven architecture

Not all cases can be implemented using the above framework. Again, let me show you by example, let’s make a player. The logic of the player is very complex, and there are many things to consider, such as play state, user actions, network conditions, etc. If we are thinking forward, the code will be difficult to write.

What’s changing is the state of the playback, the user’s actions, etc., and what we need to do is to respond to those changes, not to manipulate them positively. The architecture here is best done with an event-driven model, maintaining a state machine in the implementation, and all we need to do is switch states and change them accordingly, so it will be much more organized to write.

State Machine

For example, the state of play can be Idle, Preparing, Playing, Paused, Stopped, etc. The UI responds to the corresponding state and makes changes. For example, the play button changes from play to pause after receiving Paused -> Playing state change.

One Model

This pattern is generally suitable for very flexible situations, such as the first example I mentioned earlier, where the client serves as a presentation platform and does not participate in the business logic. There are many ways to implement this architecture, including webView as a simple way and Various Web Native frameworks as advanced ones.

But here’s another way, the pure Native way. The client itself, as a rendering platform, specifies the components it can support (Cards, Button, TextView etc.) and the corresponding supported functions (Download, Jump to Web, Open File etc.). The client defines the protocol with the server. When the server issues instructions according to the protocol, the client needs to parse them, display the corresponding components and bind the corresponding operations. In this way, the client becomes a browser to some extent.

Document information

  • Copyright Notice: Freely reproduced – Non-commercial – Non-derivative – Remain signed (Creative Commons 3.0 License)
  • Date of publication: October 30, 2016
  • Social media: weibo.com/woaitqs
  • Feed subscribe: www.woaitqs.cc/feed.xml