Synchronizing Time With App Inventor
This is a guest blog by MIT Master Trainer Rich Interdonato
Synchronizing time across mobile devices is a very challenging problem for app makers. The moment you try to use App Inventor to make something happen on more than one device at exactly the same time, you will discover that every device reports the current time to be (slightly) different from all others - even when the devices are each set to synchronize their time with the network, as shown below.
You can very easily demonstrate this for yourself by setting the same alarm (for some time in the future) on more than one device and then waiting for it to go off. When the alarms are triggered, you will find that they actually fire at different times, even though they are set to go off simultaneously. This is true even if the devices are set to synchronize their internal clocks with the network time.
It turns out that the clocks used in mobile devices are not perfectly accurate. What is more, the inaccuracy in timekeeping accumulates from the moment the clock is set, such that individual seconds are more accurate than individual minutes, which are more accurate than individual hours and so on. For example, if the true duration of each second of time kept by a clock is off by .1 ms (.0001 seconds), then each minute will be off by 6 ms (.006 seconds), each hour will be off by 360 ms (.36 seconds), and each day will off by 8640 ms (8.64 seconds). This explains why the alarms set for the same time on different phones go off at noticeably different times, even when the devices are all "synchronized" to the same network time.
In most cases, this is not a problem for App Inventors. However, if you are making a clock, a timer, or any other app that requires something to happen at a precise time (or at exactly the same moment on more than one device), then it is a very big problem indeed. For example, a student of mine wanted to create a simple app that caused the device's screen background color to be BLUE during every ODD second and to be RED during every EVEN second, in order to create a "light show" using many devices. They were frustrated to discover that when the time was not the same on each device running their app, the colors didn't blink in unison, and so their app didn't really "work". Likewise, in more sophisticated multiplayer games where players (and their projectiles) move about the game worlds shared across multiple devices, if objects don't "meet" at the same time, these games don't really "work" either. So what can we do?
Fortunately there are a number of ways to synchronize time across multiple devices, but at present this feature is not built into App Inventor. App Inventor extensions allow you to get very accurate time if you want to write the Java code needed to communicate with a network time server, and this might be what you have to do if you require very precise timekeeping in your app. If you only need to approximately synchronize the time across devices, then you can choose any time source on the Internet as the "official" clock for your app. Then you can get the "official" time when your app starts, and calculate the difference between it and the device's internal time. This time difference, called the "offset", can then be used to adjust the device's time (forward or backward) to match to time reported by the "official" time source, more or less.
Until Internet communication is instantaneous for everyone, having a single source of time is not a perfect solution to the synchronization problem. This is because all the devices being synchronized have to send out requests for the "official" time and then wait for a response back from the time server. Even if the time server could send out "official" time responses at the very instant it received the requests, the response messages still take time to travel back to the requestor and are incorrect by exactly that amount of time. As long as transit time through the Internet is unpredictable, time synchronization will be inexact.
Since the "official" time that is received by the app requesting it was only accurate at the moment the message was sent by the server, the receiver needs to adjust it in order to account for the time that elapsed during the message's transit. Although the app receiving the "official" time does not know exactly when the time server sent the response, it does know when it originally made the request (according to its own clock), and therefore it can determine the "round trip" duration of the total request-response process. If we assume that the time required to transmit the request is the same as the time required to receive a response, then half the "round trip" is the time taken by the message coming back from the server. This additional amount of time should be added to the difference between the device's internal time and the "official" time, in order to improve the accuracy of the calculated offset.
