Some recent changes and impressions of the project code

Recently made some changes to the project code, the main change is the whole interface framework changes, because the previous writing code, in order to complete the function, not from God's perspective to think of the software interface design, it is completely necessary to do this function, how can it be done? Well, that's it, in order to complete the function of the interface constantly tinkering, this brings the main disadvantages are many:

First, the subsequent functions added, the need to consider the place will be more and more, because the previous code coupling is very high, such as OnStart callback, some things can be in the activity of the callback to do, but also in the fragment callback inside to do, You can do it here or there, add a new feature, and you have to consider checking it all at once, but it may not be possible to fully consider all the circumstances, and the final omission results in a bug change when the test is made.

Second, the maintenance of the existing code is also very difficult, such as testing or product suddenly come out of a new idea, to the original effect to a different effect, it seems not very difficult, but the realization of the time to find really very troublesome. For example, before the fragmented fragment, even I do not know whether this title belongs to fragment or acticity, the entire interface of the animation cut out also difficult to do, because they are not a whole.

Third, the code is ugly to write. For example onbackpressed, you need to judge (xxxfragnemt! = null, xxxfragent.isvisiable (), Xxxpopwindow! = null) and the like. It's really ugly.

Now the main change is to consider the above points, the main changes are,

1. Interface and data separation, such as interface a update, it does not need to consider, I do not have to update B, these are drawn to the previous layer of data structure to deal with. For example, if the activity contains a lot of fragment, then the activity is taken out separately, responsible for the preservation of the data, in the Android design, the activity and the fragment between the message communication has a very complete solution, This also frees the activity from the interleaved complex interface, which is only responsible for saving and synchronizing the data, notifying the interface to update the state, while fragment is only responsible for the interface, displaying the data. Originally belong to the public part of the interface, such as Title,bottom now separate into the various fragment inside go, so also need a synchronization mechanism, this demand to the activity to control, such as the Observer mode, which is completely can be done, Now I just briefly maintained a fragment of the list, the data update when the time to notify each sub-page.

2. Find ways to extract some of the common characteristics, put them into the base class to do, because the interface between the coupling is reduced, so many of the requirements of the interaction can be abstracted out into an interface, so that each interface to respond to the corresponding call can be, such as the previous onbackpressed callback, Now the activity simply does not have to control so many conditions, directly call the interface of the interface can be, instead of checking the management should call which interface, how to respond. Of course, because of the particularity of this interaction, there can only be one interface to respond, so temporarily changed to this appearance:

　　

 for (fragment x:fragmentlist) {  if(x.mybackpressed ()) {      break  ;   }}

After this change feel logical processing is indeed a lot simpler, the concrete effect has yet to be confirmed. Think about it, this set seems to be very similar to MFC's set ... This change also made me feel that Android and windows are really a lot similar places, such as Message Queuing, such as the relationship between Activty and fragment, and Windows within the window of the relationship is similar, but Android to abstract it out. The days seem to go back to when I first started looking at the PC client code, David told me, "you need to figure out how the message flows." Now think about the design of a framework, and indeed the most important thing is how the message flows and how it responds. Does it have a clear structure? Does it need to be consumed or should it be notified to all the places? How does the message between interfaces need to be communicated to each other? Between the interface and the framework, how do I need to be notified? Interface status updates directly and synchronously, how do I need to be notified? These are issues that need serious consideration.

Some recent changes and impressions of the project code