Android development framework

From: goodcandle http://www.cnblogs.com/goodcandle/archive/2012/10/16/2672057.html

ProgramFramework

After more than 10 years of experience, I realized that the program framework really plays an important role in developing products. If there is a good program framework for a good product, it will get twice the result with half the effort. It may start to do a lot of work and it is difficult to see exciting results, but believe me, it is definitely worth it. At the beginning, I also paid more attention to program interface development and soon developed the interface. It was really exciting because something came out, but the things behind me were so crazy that I wanted to start all over again, it's too late. It's close to the schedule and time is not allowed. You only have to make patches on your head and deliver the first version, the second version, or the later version, sooner or later, it will come back. So when we lead the team to develop the program later, we should discuss the program framework before development, and set aside a lot of time for program framework development and continuous improvement in development.

I just got started with Android and didn't know what program framework to use. So I checked a lot of information. At first I saw a program framework and it felt very good. So I used the following program framework at the beginning.

This framework is quite easy to use. For a brief introduction, if the main UI thread wants to create a task for a long time, it will create a task and send it to the task queue, the backend service constantly retrieves tasks from the task queue and submits them to the thread for processing. After the thread completes processing, the tasks are sent to the handler through the message, then, the handlemessage function of handler calls back to the main UI thread.

The disadvantage of this framework is that it is troublesome.

1) First, there is an observer mode. Each activity must implement an interface and register it in the background service so that the background service can call back the processing result to the main thread.

2) each event must form a task and be sent to the task queue.

3) The background thread first needs to take the task, then process it, then switch to the main thread through the message, and then return to the corresponding activity. There is a three-time middle to determine what the current task is.

4) No, the task can only be one by one, although this generally does not cause a bottleneck.

Because it is relatively simple to shake 2 and select 1, I feel that I can process the message by using the thread and handler, and then check the data and find that there are already manyArticleAfter describing this method, I didn't propose it as a framework, but I felt that it was enough for the leeching 2 to choose 1. Below is the masterCode, Distributed in each activity:

 Private   Void  Taskthread () {thread taskthread = New  Thread () {@ override  Public   Void  Run (){  //  Perform time-consuming tasks Message msg = Message. Obtain (); MSG. What = 1 ; Uicallback. sendmessage (MSG) ;}; taskthread. Start ();}  Private Handler uicallback = New  Handler () {@ override  Public   Void  Handlemessage (Message MSG ){  If (Msg. What = 1 ){  //  Processing results in the main thread  }}};