In many cases Moki’s Android Agent is deployed on devices where the Google Cloud Messaging (GCM) service is not installed, the GCM inbound traffic is blocked at the firewall or the customer has requested that no inbound traffic be relied upon by the Moki systems. In these cases, the Moki Android Agent cannot be contacted proactively by Moki Control for management and monitoring activities.
The Moki Android Agent used in these scenarios runs in a ‘GCM-less’ model where all communication is done on a scheduled model. The Moki Android Agent is configured to call ‘home’ to Moki to check its work queue on a schedule. Once the Agent calls Moki Control for items in its work queue, it receives those items in the order they were given, executes each item in succession and reports back to Moki Control until all items in the work queue have been addressed.
This is an overview of the communication process for devices not using GCM:
- An action is initiated in Moki Control and is added to an action queue for the device
- The device heartbeats into Moki and Moki sends the first action in the queue for processing
- The device reports back to the server with the status of the first action
- Steps 2 and 3 repeats until all actions in the queue have been received and processed
NOTE: Some actions that take longer to process when they are received by the device will send a received status to the server. The device will then attempt to perform the action. Upon success or failure, a status update is sent to the server. The current status of any action can be viewed at any given time from Moki Control.
There is little to no difference between actions on devices with GCM, as opposed to those without. The chief difference is that when devices with GCM have a new action added to the queue, they will receive a push message telling the device to heartbeat and process the action. Devices without GCM must wait until the device heartbeats before they can access and process the action queue. When the device heartbeats it will get an action from the queue, as described above.
This is the expected behavior. Moki does not communicate instantaneously with devices unless they have Google Cloud Messaging (GCM). As a way to overcome this, Moki uses what we call an “action queue”. This means that admin users submit actions to a device and they are stored, in order, in the action queue. Enrolled devices have a heartbeat, which means on a regular schedule they check in with Moki to find out if there are tasks in their action queue. At each check-in, the device sends logs to Moki and picks up actions from its queue. It then responds to each action, one by one, in order until all actions are completed. By default, Moki Agent has a 15-minute interval heartbeat. This can be changed by setting up an Android Profile for “Check-in Interval”. The Check-in interval is set in terms of minutes. The shortest time you can set is a 1-minute interval, which means every 1-minute the device checks in with Moki to get actions. Typically, in production, we don’t recommend using a check-in interval of less than 15-minutes. In cases where you are working with a device (or a merchant customer with a device) and you want to troubleshoot issues or send actions quickly, we have introduced the function of “support mode” which checks in nearly constantly for new actions for a 2-minute period of time. Such frequent check-ins are ok for shorter, defined periods, but if all devices were always running in this mode it would be very costly in terms of both data consumption and hosting costs. It is rare that actions sent require immediate processing and usually, those actions can wait until the next heartbeat.
HISTORY AND RESETTING
This is how Moki is designed to work. The system assumes that if you factory reset a device or unenroll it that you are removing the device from the system. We do not hang on to action history or action queue. This prevents any confusion of past actions with a device that has been reset and possibly repurposed.
