Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tigohenryschultz opened this issue Mar 7, 2022 · 3 comments
Open

Comments

@tigohenryschultz
Copy link

tigohenryschultz commented Mar 7, 2022

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

@peitschie
Copy link
Collaborator

@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: #768 (comment)

The underlying cause is #828

@tigohenryschultz
Copy link
Author

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

@peitschie
Copy link
Collaborator

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants