This is a bit sensationalistic of a headline as Google had already previously paved the path to transition from Google Fit to the Health Connect platform, the centralized hub for all health data. It's more secure and allows a wider more diverse suite of apps to integrate into it.
From the article:
>While we’ve deprecated the Google Fit Android API, we’re aiming to turn down the API no sooner than June 30, 2025. This is to give users enough time to switch to Health Connect and continue their service.
Specifically they indicate, as they have in the past, that developers should transition from the Google Fit API to the Health Connect API. The Google Fit app already uses the Health Connect API itself to upload health data to a centralized repository.
The article also mentions no "big updates" since 2022, while I can't gauge what they're qualifying as "big", there have been 20+ app updates since that time frame and there is a major beta release ( https://play.google.com/store/apps/details?id=com.google.and... ) that has been in public testing for some time now.
> It's more secure and allows a wider more diverse suite of apps to integrate into it.
It's more secure, yes. But since the data stays on the device now, web apps cannot read or write health data anymore. You need to develop a dedicated app to access the data on the device. And the user has to interact with the app, or the data will not be accessible.
E.g. my Withings scale writes my body weight to Google Health Connect. But I need to open the Withings app every time for that to work. The app-developers cannot do this in the background afaik.
(The data flow is: scale -> cloud -> app -> Google Health Connect.)
Another issue I see is: There is no incentive for app developers to write data to Google Health Connect.
Even if you subscribe to the idea of using it as your data-store, you will lose access to the data if a user uninstalls your app. It's only possible to read data up to 30 days in the past, or however long the user has installed your app – hopefully they don't decide to reinstall it.
I really appreciate the inter-connectivity Google Health Connect allows between apps, though.
>E.g. my Withings scale writes my body weight to Google Health Connect. But I need to open the Withings app every time for that to work. The app-developers cannot do this in the background afaik. (The data flow is: scale -> cloud -> app -> Google Health Connect.)
I have a Renpho scale, the way it works for me is that when I step on the scale it turns it on and connects to my device via bluetooth which wakes the app. The weight is captured and synced in the background to both the Renpho cloud service as well as the local Health Connect.
>There is no incentive for app developers to write data to Google Health Connect.
Again this is currently an app by app basis, they get a lot of write storage to health connect for free from the API:
> Even if you subscribe to the idea of using it as your data-store, you will lose access to the data if a user uninstalls your app. It's only possible to read data up to 3 month in the past, or however long the user has installed your app – hopefully they don't decide to reinstall it.
As I understand it the access is 30 days prior to the first permission given.
" Health Connect allows your app to read records with time or startTime for up to 30 days before your app's first successful permission request. If your app is uninstalled and then re-installed, the date is reset which marks as your new starting date as if you use the app for the first time. There are no restrictions on the data you share with Health Connect, however avoid writing large amounts of historical data at this time. Similarly, avoid writing data associated with future events such as a predicted"
> I have a Renpho scale, the way it works for me is that when I step on the scale it turns it on and connects to my device via bluetooth which wakes the app. The weight is captured and synced in the background to both the Renpho cloud service as well as the local Health Connect.
I bought a Wifi scale specifically so I don't have to have my phone with bluetooth on, nearby. Does the BT-connection open the app itself, or just initiate a sync in a background service?
I was under the impression that it is impossible to access Google Health Connect in the background – I get access-errors in my log when I start my own app from the IDE while the screen is off.
> [...] they get a lot of write storage to health connect for free from the API
Is this really an issue that is solved by using Google Health Connect?
> As I understand it the access is 30 days prior to the first permission given.
You are right, I edited my original post accordingly.
>I bought a Wifi scale specifically so I don't have to have my phone with bluetooth on, nearby.
Our has that option, but as multiple people in the house used the scale, having a phone on hand (which we do anyway) streamlines the process versus having to identify the user weighing.. user preference really.
>Does the BT-connection open the app itself, or just initiate a sync in a background service?
Background service as best as I can tell. I rarely, if ever, open the app in foreground and the weight is captured.
The general vibe I get is that while Google is positive about the change, they're not offering feature parity [0] and don't seem to have any specific reason to not make the old API a facade of the new one in the first place.
The bigger picture is probably that we all see the writing on the wall when Google starts to shuffle their services, like they did for messaging, as it means Google doesn't see it as a big enough deal to be more cautious about it.
If it's really the case, whatever Google says we might as well consider it dead in 2 years.
[0] > However, there is no replacement for the Goals API that lets Google Fit users set “how many steps and heart points they want to aim for each day.”
IMO the only free services and free software (free as in free beer) you can rely on is software that is open source or source available (in its entirety).
Lets disregard the "youre the product" (and the fact that the hardware wasnt free) for a second and focus on the fact that all these dead services have one thing in common: They shut down because theyre centralized, or because their development is centralized. If an open source project (where all parts are open source) is developed by a paid dev team, and they abandon the project and kill the dev team, the code remains and people can continue to use it if they wish to maintain it also.
I'm no stallman, and I dont generally care for idealistic arguments, but this may be one of those rare times when the "FOSS is better" crowd has a really good point.
Even if its source available, or a non-commercial license, thats still more pro-consumer than whatever google fit et al did.
Google has several completely free services. I won’t name them because I’m superstitious that they will get shut down after I write this comment.
Google doesn’t shut down services because they are free. It shuts down services because they are unpopular at trillion dollar corporation scale. Stadia was paid and it got shut down too. Unfortunately, this leads to the second-order effect of people not using new Google services because they are afraid it will get shut down.
It's easy for things to get forgotten about at big companies. But sooner or later someone looking for a promotion will discover it, shut it down and put the saved money part on their CV.
Google Fit is being replaced by Goolge Fitbit, but as usual with Google what is really happening is Google is one by one replacing the sections of the original Fitbit app with the Google Fit interface. The first thing that got replaced is the Fitbit Sleep tracking, and believe me when I say what Google did is an abomination in terms of UI/UX design. The previous Fitbit sleep tracking screen was near perfection of readability and clarity. The new one is Google's usual form-over-function design language where the most important metric (weekly-view sleep score) is hidden and requires many taps to access.
From the article:
>While we’ve deprecated the Google Fit Android API, we’re aiming to turn down the API no sooner than June 30, 2025. This is to give users enough time to switch to Health Connect and continue their service.
Specifically they indicate, as they have in the past, that developers should transition from the Google Fit API to the Health Connect API. The Google Fit app already uses the Health Connect API itself to upload health data to a centralized repository.
The article also mentions no "big updates" since 2022, while I can't gauge what they're qualifying as "big", there have been 20+ app updates since that time frame and there is a major beta release ( https://play.google.com/store/apps/details?id=com.google.and... ) that has been in public testing for some time now.