cordova-plugin-ble-central icon indicating copy to clipboard operation
cordova-plugin-ble-central copied to clipboard

iOS ble.isEnabled fires error scenario even though it is enabled

Open tigohenryschultz opened this issue 3 years ago • 3 comments

I am using version 1.4.4-alpha.3 and was under the impression that the is enabled did not resolve the first time you called it on iOS.

The behavior I am seeing is it is called/invoking error on the first time even though it is enabled.

isBleEnabled: ({state, commit, dispatch}) => {
   log.debug('TigoBle2:isBleEnabled');

   return new Promise((resolve, reject) => {
     window.ble.isEnabled(
       () => {
         commit('setIsBleEnabled', true);
         resolve(true);
       },
       () => {
         commit('setIsBleEnabled', false);
         if(window.Capacitor.getPlatform() === 'android'){
           dispatch('enableBle')
             .then(resolve)
             .catch(reject);
         } else {
           reject(false);
         }
       }
     );

     if (window.Capacitor.getPlatform() === 'ios' && state.isBleEnabled === null) {
       //iOS takes  a while
       setTimeout(() => {
         dispatch('isBleEnabled')
           .then(resolve)
           .catch(reject);
       }, 300);
     }
   });
 },

As you can see the code checks for iOS and keeps calling itself until the isBleEnabled is true or false. The behavior I am seeing is it is being set to false from

commit('setIsBleEnabled', false);

calling it again right after it returns true this time.

Expected outcome, return the correct value the first time or do not return success/error until BLE device is initialized

tigohenryschultz avatar Mar 07 '22 20:03 tigohenryschultz

@tigohenryschultz apologies for the confusion, but what you are describing is exactly what I expect to see 🙂

It does result, but the first time it resolves with false because the adapter is still warming up. See this thread for more discussion: https://github.com/don/cordova-plugin-ble-central/issues/768#issuecomment-1049289467

The underlying cause is #828

peitschie avatar Mar 08 '22 09:03 peitschie

Hmm interesting. So we need to call it a few times the first time regardless of true/false?

tigohenryschultz avatar Mar 08 '22 17:03 tigohenryschultz

On the first call, I'd simply call a second time if it returns false. If the value comes back true, you're good to assume the Bluetooth is enabled!

peitschie avatar Mar 08 '22 22:03 peitschie