ajax|web| Program Due to the unpredictability of network potential, this perceptible error comes and goes, and testing the responsiveness of the application can become more difficult. Therefore, the network potential is the most common reason for the poor interactivity of real-world applications.
Four, asynchronous client
In practice, we must try to make the UI response independent of network activity. Fortunately, a fixed time response is often sufficient, as long as it is timely. Let's look at the actual problem again. One of the main tasks of my morning routine is to wake my children to school. I can stand on them and poke them until they get up and put on their clothes, but it's a pretty time-consuming way of leaving me with almost nothing to do (Figure 8).
Figure 8 Asynchronous response user input sequence diagram |
In this sequence diagram, the transition of time is perpendicular. The height of the shaded section indicates the length of time that I was blocked for further input.
I need to wake my child, stare at the window, and ignore the cat. The children will inform me-they are awakened correctly for asking for breakfast. Like server-side processes, children wake up very slowly. If I use an asynchronous client model, I will wait a long time. As long as they can grunt, I can wake up and then I can continue to do other things easily and check them out when needed.
In computer terminology, what I'm doing here is firing an asynchronous process in a separate thread. Once they are started, my children will wake up in their own thread, and I-the parent thread, do not need to sync with them until they notify me (usually using a request). Although they were waking up, I couldn't communicate with their clients as if they had gotten up and dressed, but I was sure it would happen in time (Figure 9).
Figure 91 asynchronously responds to the user input sequence diagram. If I use an asynchronous input model, I can get the kids to tell me they're starting to wake up. Then, when I wake up, I can go on with my other activities and have a short time to stay in the block. |
Whether you use any UI, you create an asynchronous thread to handle any lengthy computations and let it run in the background, and the user continues to work on other things as a good solution. When the thread starts, the user is bound to be blocked, but this may occur within a very short period of acceptable time. Due to the potential of the network, a good implementation is to treat any RPC as a potentially lengthy process and process it asynchronously.
Both the problem and the solution are good. The potential of the web has long been in the old-fashioned client/server model-making poorly designed clients stranded at an intolerable level when trying to reach an overloaded server. In today's internet age, the potential of the web has made it a huge setback for your browser to switch back and forth between pages. We cannot eliminate this potential, but we know that it can be handled by processing the remote call asynchronously, right?
Unfortunately, this is not captured for most of our web developers.
HTTP is a request-response protocol, which is one-way. The client can contact the server, but the server cannot start a communication with the client. Indeed, the server cannot remember the client from one request to another.
Most Web developers who use modern languages such as Java, PHP, or. NET are familiar with the concept of user conversations. HTTP works well according to its original design, and it has been adapted to achieve more flexible functionality. However, the key to our asynchronous callback solution is that the client is notified again: the first time when the thread is created and the second time the thread completes. The direct HTTP and classic Web application model can't do this for us.
The classic Web application software model used by Amazon is still based on the conceptual design of the page. A document is displayed to the user-contains a list of links and/or table cells-they allow them to be submitted to further documents. It is entirely possible to interact with complex datasets in this way on a large scale and, as Amazon and other sites demonstrate, to build a commercial operation based on this experience.
- Ajax: A new way to build Web apps
- Discussion on the error handling mechanism of AJAX (2)
- Discussion on the error handling mechanism of AJAX (1)
- First experience. NET Ajax Brushless New technology
- A brief analysis of Ajax development Technology in Rails system (4)
