4 Replies Latest reply on Oct 6, 2017 11:02 AM by Erik Hellman

    Listening for Cradle lock/unlock events

    Erik Hellman

      Hi,

       

      Is there any way to listen for the true state of the lock of the cradle or even query the cradle about it's current locked/unlocked state? I haven't been able to do either so far.

       

      Also, how would I go about to detect being placed in the cradle but not yet picked up?

       

      We basically have three states in our app. Parked and locked, Parked but not locked (reserved for user) and not parked (picked up by user).

       

      Listening for battery state changes have proved unreliable and I'm not able to detect the state of the lock.

       

      Please advice.

       

      Cheers,

      Erik

        • Re: Listening for Cradle lock/unlock events
          Jacques Gourmelen

          Good morning Erik,

           

          Can you please let us know which devices you are using / targeting?

           

          Are you stating the below approach is not reliable?

          Monitoring the Battery Level and Charging State | Android Developers

           

          Kind regards,

          Jacques

            • Re: Listening for Cradle lock/unlock events
              Erik Hellman

              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.

            • Re: Listening for Cradle lock/unlock events
              Jacques Gourmelen

              Erik,

               

              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 the device is already unlocked, the unlock method returns ALREADY_UNLOCKED

               

              --

               

              & If have successfully and reliably used a BroadcastReceiver to

               

              Kind regards,

              Jacques

                • Re: Listening for Cradle lock/unlock events
                  Erik Hellman

                  Hi,

                   

                  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.

                   

                  // Erik