Set up observer queries in didFinishLaunchingWithOptions to align with Apples recommendations

[robertherber]

To comply with Apple recommendations and to prevent any race conditions that might arise from initialising it later, as is the case now.

There are two parts to this:

• Document, based on Apple docs, how to add this to didFinishLaunchingWithOptions for Bare React Native apps.
• Add a config plugin for this so it works with Expo Managed Workflow.

[mafen]

How does one use enableBackgroundDelivery today?, because i am seeing that in apples docs, they have something called completion handler, is that needed to do it ?

[robertherber]

@mafen It's available in this library already (and seems to work allright) - but according to the Apple docs it's recommended to call it earlier in the lifecycle (in didFinishLaunchingWithOptions, i.e. before any JS code is initialized.

[mafen]

Any examples on the part that is in already? Like i want to use enableBackgroundDelivery in it's current from, and i have tried

HealthKit.enableBackgroundDelivery(HKQuantityTypeIdentifier.activeEnergyBurned, HKUpdateFrequency.immediate)
But where do I get the result of this, what calls my method?

I would love an example of how to use this function

[robertherber]

@mafen The completion handler is solely indicating success or failure in enabling background delivery - not for getting the data itself (and in react-native-healthkit it's returned as a promise instead of a callback - to improve the developer experience).

I think the methods you use to fetch/subscribe to data are the same as without background delivery.

[mafen]

I have gotten it working with subscribe to data but only when press the simulate background fetch in XCode and it is very flaky on a real ios device, could only get it work well in the simulator but not after terminating the app.

[robertherber]

@mafen In the Apple Docs about Background Delivery it states that most types of data can only be subscribed on to an hourly basis at most, I guess that might be what you’re experiencing?

[mafen]

I am subscribeing to active energy burned and that is supposed to be on an immediate frequently

[robertherber]

@mafen Here it's not listed as one of the immediates.

[mafen]

@mafen Here it's not listed as one of the immediates.

I am maybe wrong, but I thought that was only for watch OS

[robertherber]

@ha3 I started looking at implementing a config plugin for this. However when reading the docs again I realised it's not actually recommending to call the enableBackgroundDelivery in didFinishLaunchingWithOptions, but rather to set up all observer queries there:

As soon as your app launches, HealthKit calls the update handler for any observer queries that match the newly saved data. If you plan on supporting background delivery, set up all your observer queries in your app delegate’s application(_:didFinishLaunchingWithOptions:) method. By setting up the queries in application(_:didFinishLaunchingWithOptions:), you ensure that you’ve instantiated your queries, and they’re ready to use before HealthKit delivers the updates.

I guess this makes more sense, and is also more difficult to achieve. What is your experience with this - do you miss out on background updates? Are you using observer queries or maybe some other method to fetch the data?

[ha3]

@robertherber I understand that this means changing useSubscribeToChanges implementation in general, and adding an additional native step for the installation. I agree that it can be more difficult to implement; but I'm not sure about the possible consequences of not following official advice on this.

We haven't ship HealthKit observers to production yet; since there is no way to retrieve changed data between observer calls for now (#50). So, we can't be sure if there is any miss or not.

Basically this is how we use the observers:

let isBackgroundObserversSetup = false;

const setupBackgroundObservers = () => {
  if (isBackgroundObserversSetup) {
    return;
  }

  isBackgroundObserversSetup = true;

  ([
    HKQuantityTypeIdentifier.activeEnergyBurned,
    ...
  ] as const).forEach(permission => {
    HealthKit.enableBackgroundDelivery(permission, HKUpdateFrequency.immediate);
  });
};

const HealthKitProvider = ({ children }: { children: React.ReactNode }) => {
  setupBackgroundObservers();

  HealthKit.useSubscribeToChanges(
    HKQuantityTypeIdentifier.activeEnergyBurned,
    async () => {
      const data = await HealthKit.getMostRecentQuantitySample(HKQuantityTypeIdentifier.activeEnergyBurned);

      if (!data) {
        return;
      }

      // do sth with data
    }
  );

  return <>{children}</>;
};

const App = () => {
  return (
    <HealthKitProvider>
      ...
    </HealthKitProvider>
  );
}

[matteo-hertel]

@ha3 thank you for the example you posted, helped a lot to understand how to set it up
The one thing that is still not clear to me is the background delivery when the app is in the background or closed, will the useSubscribeToChanges still fire?

For example, I'm trying to subscribe to the latest workout, I would like to send the user a notification once they completed a workout, I've created a provider like your example above but it only fires when the app is in the foreground, if the app is in a closed state I don't receive the data and therefore can't show the notification, any idea how to achieve that?