Good morning Erik,
Can you please let us know which devices you are using / targeting?
Are you stating the below approach is not reliable?
I have the MC18 with the three-slot cradle.
While monitoring charging state will theoretically let me know if the device is placed in the cradle or not, it doesn't let me know when it gets locked. Also, if I would move the terminal while it's placed in the cradle, the charging state can change even if it is locked (basically a glitch occurs between the connectors which will trigger a "false" state).
So I got two problems. I can't detect when the device gets locked or unlocked (Although, I can interpret the result of an unlock operation, but that is not sufficient since the software event can be delayed a few seconds after the actual physical unlock) AND I cannot reliably trust a charing state change since there are false events occurring.
Currently, I listen for battery level and charing state broadcasts and wait until I have received X number of "is charging" events before I interpret it as being placed and locked in the cradle.
If I somehow could receive a callback when the device gets locked in the cradle I could probably work around the other issues myself.
As far as I know, no event is triggered as the unit is docked / un-docked / locked / unlocked.
My understanding goes as follows:
- when sled into a cradle slot, the MC18 unit is automatically locked.
- to programmatically unlock it, the unlock method needs to be called and passed a unlockDuration argument expressed in seconds, which must range from 10 (minimum) to 30 (maximum) seconds.
& If have successfully and reliably used a BroadcastReceiver to
- get notified as
ACTION_POWER_CONNECTEDand ACTION_POWER_DISCONNECTED events are raised and
- determine whether or not the unit sits in a cradle (E.g. by calling the getCradleInfo method, shortly after receiving a ACTION_POWER_CONNECTED event)
Yes, I know all of this. The problem is that the connectors between the terminal and the cradle aren't perfect. That means if I wiggle the terminal when it is in the cradle it will trigger multiple ACTION_POWER_CONNECTED and ACTION_POWER_DISCONNECTED, although it still is placed in the cradle. That is, it is not possible to trust those events alone for reliably detecting when the terminal is locked.
Calling getCradleInfo() too early will result in an exception (again, there is no reliable way of determining what the state is currently). This means that if the customer will place the terminal in the cradle and then try push it around, I will end up the wrong state detected.
I can tell from the system logs that there are events triggered internally when the terminal is placed in the cradle (long time before ACTION_POWER_CONNECTED is broadcasted) and when the lock is engaged (again, long time before and broadcasts are sent). I feel that there is some kind of delay in your processing that is the cause of this.