Issues Related to Singleton PolarBleApi

[KennethEvans]

Platform your question concerns:

• Android
• iOS
• Other
• Platform is not relevant for this question

Device:

• Polar OH1
• Polar Verity Sense
• Polar H10
• Polar H9
• Other
• Device is not relevant for this question

Description:
Discussion about the singleton nature of the PolarBleApi was started in #197. The singleton issue and other problems are not really relevant to the HR=0 and other problems with PPI and PPG (which seem to be related to the device and not the SDK), so I am making a new issue. I will note that problems with the purple light staying on were also mentioned in that issue, and the result was a bug fix which is now available in SDK 3.2.2. It was also mentioned that I should change my KE.Net HR Compare app (which connects to two different devices) to only have one instance of PolarBleApi. These are related to this issue.

I have done that and also changed to 3.2.2. The good thing is there no longer seem to be problems with the purple light staying on after the device is connected.

Now that I have changed to only one instance of PolarBleApiDefaultImpl.defaultImplementation and verified that it is, in fact, a singleton (the hash code does not change when I get a new one), I could not see how it ever worked with two instances as it had previously. Going back to that commit, I see it was not a singleton in 3.2.1. That is, each instance had a hash code and it changed when a new one was set.

The app is working as before with only only one PolarBleApi mApi field, but there is another problem. The app has a MainActivity and an HRActivity. The MainActivity only sets the device IDs and starts the HRActivity. The only use of the PolarBleApi is in the HRActivity. The problem is that after returning to the MainActivity using the back button and then starting the HRActivity again, the HRActivity never connects nor, in fact, gets any callbacks. It is using the same singleton instance with the same hash code each time.

This could be my error but I am not finding it. It looks as though the singleton PolarBleApi is not cleaning up correctly.

mApi is set again each time in onCreate. This is what is in onDestroy:

    @Override
    public void onDestroy() {
        Log.v(TAG,
                this.getClass().getSimpleName() + " onDestroy: mAPi=" + mApi);
        super.onDestroy();
        if(mPpiDisposable1 != null && !mPpiDisposable1.isDisposed()) {
            mPpiDisposable1.dispose();
        }
        if(mPpiDisposable2 != null && !mPpiDisposable2.isDisposed()) {
            mPpiDisposable2.dispose();
        }
        if (mApi != null) {
            try {
                if (mDeviceId1 != null) mApi.disconnectFromDevice(mDeviceId1);
            } catch (Exception ex) {
                Log.e(TAG, "Error disconnecting from " + mDeviceId1);
            }
            try {
                if (mDeviceId2 != null) mApi.disconnectFromDevice(mDeviceId2);
            } catch (Exception ex) {
                Log.e(TAG, "Error disconnecting from " + mDeviceId2);
            }
            mApi.shutDown();
        }
    }

I am not seeing a way to fix it.

Note: As cleanup issue, I notice that in the androidBleSdkTestApp (I am still using the one in 3.2.1) in onPermissionsResult for requestCode = 1, it is saying "bt ready", whereas it asked for ACCESS_FINE_LOCATION with requestCode 1. Older versions caused the user to be asked to start Bluetooth using onActivityResult, which is now deprecated. (This is not related to the current issue.)

Second unrelated question. It would be nice to have the Javadoc available in Android Studio. Is there a way to attach what is in the docs directory to polar-ble-sdk.aar? I haven't found one.

[JOikarinen]

The problem is that after returning to the MainActivity using the back button and then starting the HRActivity again, the HRActivity never connects nor, in fact, gets any callbacks.

Your implementation looks good. I have high suspect that this issue in SDK. I will take a look.

[JOikarinen]

I think, the fix in your code is that you remove the mApi.shutDown(); from onDestroy() of HrActivity. As the documentation of shutDown() says is meant to be used at the moment of whole application is destroyed, not when the activity destroyed. That said, I need to study a bit deeper what was the original idea of shutDown();. I will come back on this topic.

[KennethEvans]

Handling application shutdown is difficult. My activity that uses PolarBleApi might not even get called, and the application may not be in that activity when it is shutdown. I am just calling shutDown in onDestroy because that's what the examples do. I have no idea what it does. (Logically I am through with PolarBleApi in onDestroy in the HRActivity.) I also have no idea where the singleton is stored or what services are being run by the SDK or their life cycles .

The app works ok the first time. That must mean the singleton instance is not in the same state after shutDown that it was initially. This has only become a problem now that it is a singleton, because before it was recreated from scratch each time.

It seems to me that shutDown should bring it to the initial state or there should be something new that does that. (I have not looked at the code.)

I don't particularly want to look at the code (especially if it is in Kotlin). However, I would like to see the Javadoc in Android Studio. It is too inconvenient to have to access it through the HTML in the downloaded docs directory, and so I seldom do it. There should be a way to attach the source or Javadoc to the AAR in Android Studio, but I have not figured it out. Nor are there Javadoc nor source JARS (that I have found). That is the usual way to do it. Not having the docs readily available contributes to bad code and misunderstanding on my part.

I am not sure anything I said here helps. These are just my opinions. I trust you will work it out. 😉

[JOikarinen]

The problem is that after returning to the MainActivity using the back button and then starting the HRActivity again, the HRActivity never connects nor, in fact, gets any callbacks

@KennethEvans this shall be now fixed by release 3.2.3

While fixing the issue you reported, I have found another issue on SDK which shall be handled as a separate bug. Android platform has the limitation that only 5 scan starts are allowed within 30s. The limitation is explained for example in here NordicSemiconductor/Android-Scanner-Compat-Library#18. Because of that limitation you may observe problems with sensor connection on your app. If stepping too fast (within 30s) between MainActivity->HrActivity->MainActivity->HrActivity you observe that connection to sensor is not always created.

There should be a way to attach the source or Javadoc to the AAR in Android Studio, but I have not figured it out.

Let's investigate the options for this too.

[KennethEvans]

Thanks for doing that. It seems to be working ok with SDK 3.2.3.

While fixing the issue you reported, I have found another issue on SDK which shall be handled as a separate bug. Android platform has the limitation that only 5 scan starts are allowed within 30s. The limitation is explained for example in here NordicSemiconductor/Android-Scanner-Compat-Library#18. Because of that limitation you may observe problems with sensor connection on your app. If stepping too fast (within 30s) between MainActivity->HrActivity->MainActivity->HrActivity you observe that connection to sensor is not always created.

That's interesting. It shouldn't be a problem for this app in normal use, though.