|Written by Ian Elliot|
|Monday, 21 August 2017|
Page 1 of 3
Now Available as a Book:
You can buy it from: Amazon
So what exactly is this "asynchronous" behavior all about?
The Workings Of Async - The Dispatch Queue
A thread in this case means thread of execution. A typical machine will have many threads of execution all managed by the operating system. This is how a machine can seem to be doing more than one thing at a time.
The reason it is generally called the UI thread is that its sole purpose in life is to look after the User Interface. The UI thread simply responds to events generated by the UI.
What happens is that the dispatcher maintains a queue of requests generated by UI events. The UI thread takes a request from the front of the queue and runs the code associated with the event. When the event code completes the UI thread returns to the queue and deals with another request. This continues until the queue is empty and all of the events have been dealt with. The UI thread then just waits for an event to occur.
DIAGRAM IN BOOK
if you have understood this simple dispatcher mechanism you should be able to understand a great deal of otherwise strange behavior.
For example if you write an event handler that takes a long time to complete then the user interface will appear to freeze because the UI thread cannot process any more events.
In fact the for a responsive UI what you really need is for the UI thread to be idle most of the time just waiting for an event to occur. When ever you are actually making use of the UI thread within an event handler then the user interface is frozen.
In the future it makes sense to use an architecture that puts all of the real work on a worker thread and leave the UI thread to just interact with the user. This is covered in a later chapter but you should not underestimate the subtle difficulties in writing reliable multithreaded programs. Indeed this is the reason that most UIs are single threaded. There have been attempts in the past to create a UI framework that allows multiple threads to work with it but it has always proved harder than you might imagine.
The key idea is that the natural state of the UI thread is doing nothing.
It really should only burst into life to do something in response to an event and get back to waiting for the next event as soon as possible.
This raises the question of what exactly an event is?
For example, when the user clicks on a button say the button click event is added to the dispatcher's queue. The details of the event are also stored in the queue as an event object. The event object has a range of properties which can be used by the event handler to find out which UI element generated the event and other details. What is stored in the event object depends on the event that occurred and to an extent on the particular browser being used.
When the dispatcher is free it takes the event at the head of the queue and calls the event handler passing it the event object. The event handler responds to the event by doing something appropriate and perhaps using the information about the event stored in the event object.
Notice that when an event handler is running nothing else can happen. The event handler will run until it yields the UI thread by performing a return. Events that happen while an event handler is running are added to the dispatcher's queue but they have to wait their turn for the UI thread to run them.
How do you register a function to an event?
This used to be a problem because different browsers implemented event handling in different ways but today there is just one standard way of doing the job.
If you need to support older browsers then use jQuery which provides a browser independent way of working with events.
In HTML you can set an event handler on an element using the well known "on" properties - e.g.
You can also add and event handler by setting the property in code:
Not all events have on properties and therefore cannot be set in this way. Also you can only set a single event hanlder. Assigning another function to the "on" property simply overwrites the previous value.
In code the modern way of doing the same job is to use the addEventListener method to register the event handler to the target. The target keeps a list of event listeners and so isn't restricted to juse one.
will result in myEventHandler being called when the user clicks the button. Notice that while the HTML needs a string which provides the event handlers name the addEventListener uses the reference to the function object. The first parameter specifies the event as a string.
A good source of information on what event names you can use can be found in MDN - https://developer.mozilla.org/en-US/docs/Web/Events.
One small point that is often overlooked is that an event source can have more than one event handler registered with it using addEventListener. It is customary to call event handlers added using addEventListener "event listeners", but the term "event handler" can be used for anything that responds to an event.
When the button is clicked you will see two alerts, one per event handler. Notice that there is no guarantee as to the order in which event handlers are called.
Why would you register multiple event handlers?
You can also remove an event handler using:
notice that the type and function have to match exactly the event handler added.
Removing event handlers is something of a problem. There is currently no way to get a list of events that are registered to an object. This is fixed in DOM 3 but at the moment this isn't implemented in any of the modern browsers. If you want to remove event handlers you have to keep track of them yourself and this means not using anonymous functions which are currently difficult if not impossible to remove.
|Last Updated ( Monday, 21 August 2017 )|