Google changed where Chrome stores data. Chrome handles data for HTML apps. Uh oh.
Read the whole story
Read the whole story
Chrome’s Data Disaster: Browser update wipes out Android app data
- Thread starter JournalBot
- Start date
This sucks big time for developers that is using WebView because the consumers will blame entirely on developers for it. Whereas it is Google for creating this mess. I felt bad for developers since they are getting barrage of complaints from their consumers. Yikes.....
Upvote
127
(131
/
-4)
Yeah, or maybe you could do your own fucking QA. Ha ha ha, this is Google we're talking about.
Upvote
291
(300
/
-9)
Google apologizes profusely for this oversight. In response, Google will be discontinuing Android Chrome in the coming months, replacement TBD.
Upvote
173
(181
/
-8)
Yeah, I mean, I thought developers target an API. It shouldn't be up to them to test Betas of the next release to catch Google's/Chrome's screwups.
What's probably going to end up happening now is that every developer, on an app-by-app basis is going to need to develop their own custom data retrieval code to pull the old data from the old location, and either move it (if this is the first time the user loaded the app since the update, so that there's no new data to merge yet), or merge data if they have both old and new data, or ask the user if they want to split their history - retrieve the old data and make it available as an 'archive' and then use new data going forward, or whatever.
From one app to the next, what makes sense might differ - some apps, historical data might not be necessary for future data to be added and used; in other cases, historical data is vitally important.
Honestly, though, aren't most apps these days, "cloud apps", and as such, most local data can be restored from the cloud if the app detects its "lost" on startup (which is how it would appear after this update)?
Upvote
88
(90
/
-2)
I know this is bad news for many legitimate apps and users of those apps.
However, I hope this encourages more people to use actual websites rather than an app which is a glorified browser for one site... often with unnecessary permissions.
I hope even more that this encourages sites not to pester you to install their crappy app, to view the very site you're already on.
However, I hope this encourages more people to use actual websites rather than an app which is a glorified browser for one site... often with unnecessary permissions.
I hope even more that this encourages sites not to pester you to install their crappy app, to view the very site you're already on.
Upvote
47
(77
/
-30)
Does Google actually have a QA team?
The lack of rigor in QA across a large number of teams/products speaks to a fundamental and pervasive flaw in their development processes. Whether it's Stadia, Pixel, Android - the same seemingly QA-able flaws keep cropping up. Apparently with increasing regularity.
I mean, changing the default path for anything - in any application - would be a focus point for even the most novice of QA teams. For an application that's a dependency for 10's or 100's of thousands of applications? They're pawning this off on 3rd party devs for not using the test branch? Seriously? Prior communication of a breaking change to developers is just that hard?
I'd love for a long-time Googler to elaborate on how Google's devolved over the past few years. Things like this make it readily apparent that the smart, efficient, effective Google of the 2000's which could do no wrong, do no evil, and valued R&D - seemingly no longer exists.
The lack of rigor in QA across a large number of teams/products speaks to a fundamental and pervasive flaw in their development processes. Whether it's Stadia, Pixel, Android - the same seemingly QA-able flaws keep cropping up. Apparently with increasing regularity.
I mean, changing the default path for anything - in any application - would be a focus point for even the most novice of QA teams. For an application that's a dependency for 10's or 100's of thousands of applications? They're pawning this off on 3rd party devs for not using the test branch? Seriously? Prior communication of a breaking change to developers is just that hard?
I'd love for a long-time Googler to elaborate on how Google's devolved over the past few years. Things like this make it readily apparent that the smart, efficient, effective Google of the 2000's which could do no wrong, do no evil, and valued R&D - seemingly no longer exists.
Upvote
187
(191
/
-4)
Agreed this is a pretty pathetic response from Google. What he's suggesting implies every developer releasing an app on their platform has to perpetually keep testing their own applications, regardless of whether they are rolling out new versions themselves or not, because every six weeks Google might just break things for you.
I can understand the developer is just frustrated with the situation, but blaming it on your platform users is just plain unprofessional.
Upvote
181
(184
/
-3)
Ironically this is hitting those who DID NOT want this information in the cloud. If it was in the cloud this wouldn't be an issue other than some issues with where offline data was stored until you have a cloud connection again.
Upvote
89
(89
/
0)
At least with Windows 10 Microsoft only break your shit every 6 months.
Upvote
51
(74
/
-23)
The worst thing is when they deliberately reduce functionality of the web site, or more commonly, just make the web site worse and deliberately irritating, in order to 'persuade' you to get the app and bug you literally everytime you load a page up to download the app, even though they know you've said no a 1000 times already (I have first party cookies enabled)...........I'm specifically looking at you Reddit!
Edit: typo
Upvote
134
(134
/
0)
Yeah, I get it. He's thinking "how did no one notice this in 6 weeks?" Fair enough, but those who change the code are supposed to anticipate problems, and QA exists to find things coders don't think of.
If it goes from beta to live in 6 weeks that could be the problem right there. No way was proper QA done.
Upvote
62
(65
/
-3)
I guess the lesson for developers is to avoid using local storage in WebView for their apps.
Upvote
-11
(8
/
-19)
I'm assuming this would be vastly worse on Chrome OS by covering all offline web store apps. And with increasing RAM pressure ditching Android on Chrome might be a necessity on lower end devices making the old web store system the only apps.
Upvote
18
(18
/
0)
I don't do development for mobile apps but it feels _very_ strange that a number of apps uses, essentially, WebView's temporary storage for some heavy lifting and large amount of data.
I'd expect them to use it for something like log-in caching (questionable as well, but at least predictable) and temporary store until there's a chance to sync up with server, but shoving a whole heap of financial data there versus storing it on their own server? For _years_? Ugh...
Even if user didn't want "cloud" and wanted a local store, wouldn't the logical approach be to use "normal" storage? So user can back it up, etc.
I'd expect them to use it for something like log-in caching (questionable as well, but at least predictable) and temporary store until there's a chance to sync up with server, but shoving a whole heap of financial data there versus storing it on their own server? For _years_? Ugh...
Even if user didn't want "cloud" and wanted a local store, wouldn't the logical approach be to use "normal" storage? So user can back it up, etc.
Upvote
29
(39
/
-10)
If I understand this issue correctly, this would only ever effect developers who mix WebView with local system functions that look for the storage locations manually. If you developed a full Progressive Web App, then moving the exact storage location wouldn't matter since your app *never* knows it.
That being said, I still feel like the real lesson is that Google needs to do proper QA...
Upvote
17
(21
/
-4)
captain numerica
Ars Scholae Palatinae
I edited your comment to make it more applicable to industry trends that aren't limited to just Google or Microsoft or Amazon et al.
Also, the answer is largely no. QA is still there in other forms but many of the formal roles are now gone.
edit: I'm still learning how to type.
Upvote
2
(16
/
-14)
Upvote
-6
(5
/
-11)
Paraphrased: "You got six entire weeks before a massive, breaking change rolled out from first introduction to end-user devices. What the hell do you people want from us?"
Time to actually test proposed changes, for one. Six weeks is a ridiculously short window.
Upvote
52
(60
/
-8)
biffbobfred
Ars Scholae Palatinae
One could say the same of apple. I remember at one time, Jobs pared the Macs down to 4, a matrix of desktop/laptop crossed with work/home. now we have more than that number of OSes based off Darwin (macOS, watchOS, homeOS, tvOS, iOS, iPadOS).
Things show at scale. Google/Microsoft/Apple are all at scales that seemed unbelievable a decade or so ago.
Upvote
1
(15
/
-14)
From someone who works at Google (not me though): the only team that has an actual, well-staffed and organized QA team is Ads. Everyone else skates by with ad-hoc processes, devs doing their own QA, customers filling in as QA, etc.
It's based on the idea that groups should run lean, that Google hires the smartest people, and that they'll just automate things until everything comes out perfect the first time.
Note to lawmakers: no need to break up Google. They're going to self-destruct not to far out in the future.
Upvote
105
(106
/
-1)
BloodyCactus
Ars Praefectus
as a dev, if your app is "stable" you probably would have zero idea using the system webview would have such impacts, so its easy to not be subscribed to googles nightly changes in opaque backend components. They changing chrome? ok I dont use it, i just use the android system webview...
Upvote
60
(62
/
-2)
I'm having a hard time believing no one on the Chrome team can think of any way to merge the two datastores. Sure, it's possible there's no practical way. But given that it's Google, I don't think it's unreasonable to assume they just DGAF.
Upvote
15
(32
/
-17)
Not to mention that I don't think that Google advertises just how far-reaching the changes in that new version was going to be.
The entire fucking point of using an API is that you don't need to know the details of where exactly things are stored, how they're processed, etc. You need to know when the API signature changes - not that the location of the storage is changing.
This is a fuck up that goes far beyond not doing QA.
Upvote
97
(98
/
-1)
biffbobfred
Ars Scholae Palatinae
This is probably the norm in most places. Getting good QA people, who can reason about what's a black box to them is hard. So the theory goes, have the developers do it, they know the code best! But they're not paid for QA, they're paid for new features that make money, so they kind work at it, kinda.. maybe, when their boss isn't yelling at them.
Upvote
53
(53
/
0)
I would guess that they haven't tested the effects. Not that it stopped them the first time.
Upvote
1
(5
/
-4)
Heck some API makers assume that not all the users know that the signature has changed and keep the old version in parallel for awhile. One that we use at work uses a different end-point when they change the API majorly. Granted they don’t have to but being a major manufacturer they also can’t afford to have a supplier suddenly not be able to send or receive data. They keep the old one around for awhile while their suppliers manage the change.
That being said another company that we deal with is not consistent with how their API sends out information and it was quite a surprise to find that out.
Nothing on the level of wiping our data though.
That being said another company that we deal with is not consistent with how their API sends out information and it was quite a surprise to find that out.
Nothing on the level of wiping our data though.
Upvote
26
(26
/
0)