As a simpler operating system than mobile systems, Android provides a better mechanism to enhance program security. Android has a strict type of security check function, it can almost find out all the Syntax problems in the program, which greatly helps developers. Let's talk about how to learn Android.
With the framework, we don't have to deal with naked OS APIs and do repetitive and complicated things. However, there is no free lunch in the world. In Android, the lower layer is the Linux kernel, but the upper layer's java framework makes all the encapsulated secrets hard.
Taking message processing as an example, in MFC, we can use PreTranslateMessage to process messages freely. In C #, the boss of Anders Hejlsberg said that he opened a "life-saving window" for us to the bottom layer, but unfortunately, in learning Android, the window was closed, at least I didn't find it now ...).
When learning Android, you want to process messages such as Keydown ...), you must find some overload functions provided by Activity for you, such as onKeyDown ...) or a variety of listener, such as OnKeyDownListner ...). The advantage of doing so is obvious. The more freedom there will be the more danger and the more obscure it will be. It's easy to use and save your mind, this is what a well-designed framework should offer.
For my current project, I don't have any BT requirements that I can't do under the current API. google's design ms is still very nice. However, the world is cruel. Sometimes we must have mechanisms to deliver and process messages.
Because some jobs cannot be processed synchronously by direct calls, and they cannot be done through embedded message distribution and interface settings in the Activity, such as scheduled touch of events, asynchronous processing of cyclic events and time-consuming work.
In Android, it provides some interesting ways to do this. Sorry, I don't know much about it. I have never seen similar methods, I have seen it before ). It has an android. OS. Handler class that accepts a logoff parameter. As the name suggests, it is a encapsulated class that represents a message loop.
By default, Handler accepts the message loop instances in the current thread. That is to say, a message loop can be distributed by multiple objects in the current thread for processing in the UI thread, the system already has an Activity to process. You can start several Handler to process it ...) after instantiating a handlerInstance, you can send messages through sendMessage and other message sending mechanisms, and send messages by reloading handleMessage and other functions.
But! The handlerInstance can receive messages. This statement is inaccurate only for messages constructed by handlerInstance. obtainMessage. You can also manually create a Message and configure it to be handled by the handlerInstance. I have not followed it to analyze its identification mechanism. If you are interested, please play with it. ^_^ ).
That is to say, A, B, C, and D can all process message distribution in the same thread, but each of them can only process its own message, this obliterates B's intention to secretly enter the territory of A. It is theoretically possible that the greater the number of agents will do some nonessential tasks.
B is still likely to disguise messages like A's family. I didn't try to challenge google's IQ. I want to study it myself if I have BT requirements. ^_^ ). In this way, both flexibility and security are taken into account, and it will be simple to use. I am the master of my website. It is a pleasure not to feel hurt or be innocent.
Obviously, message senders are not limited to their own threads. No one can only perform scheduled, delayed, and other things. During Handler instantiation, logoff can be any thread. As long as there is a Handler pointer, any thread can also sendMessage. This construction method is also very interesting.
You can construct Handler by passing the Logoff of line B in thread A, or in thread B, which brings A huge variable to the memory management method ...). However, a rule must not be broken, that is, a non-UI thread cannot touch the UI class.
There are many solutions on different platforms. If you have many solutions that you can't be more interested in, you can take a look at one I wrote a long time ago. No SB doesn't need money ). I specifically followed the AsyncQueryHandler class in android to learn about google's official solutions.