One of the reasons why I appreciated windows. Even old software would run on newer versions.
Prisoners of Google Android development
41–50 of 318 posts
Re: Prisoners of Google Android development
#42While I concur with the author on the challenges of Android development, the author made two major mistakes. One, he didn't test his app on the latest version of Android. This a very major mistake and the reason why we keep 11 virtual machines around with all the versions of Android that our app is supported on. Two, when you release an app on Google Play, you never, never, never deploy the app to 100% of your user b…
I agree that things could have been done better in many ways. However, as explained, it is a legacy application, which does not see any active development nowadays and it would just not make sense to build such a robust QA. This particular app have been written long time ago by another company and there's not even simple unit tests. That's the hard truth. But still, even as complex setup as you have, there's still go…
Unfortunately, as you noted, the game is rigged and you have to play within the sandbox provided. With that, and as you also noted, your testing simply needs to be better, especially since this is a customer-facing app and not an app that's solely used internally. As for dealing with the rollout when a serious bug is now in production, if you didn't roll out your app to 100% of the user base you could halt the roll out so it wouldn't affect any more customers. Then, while far from ideal, you could ask affected customers to uninstall the app and then reinstall it, and the newly installed version would reflect the previous version of your app.
Re: Prisoners of Google Android development
#43While I concur with the author on the challenges of Android development, the author made two major mistakes. One, he didn't test his app on the latest version of Android. This a very major mistake and the reason why we keep 11 virtual machines around with all the versions of Android that our app is supported on. Two, when you release an app on Google Play, you never, never, never deploy the app to 100% of your user b…
I agree that things could have been done better in many ways. However, as explained, it is a legacy application, which does not see any active development nowadays and it would just not make sense to build such a robust QA. This particular app have been written long time ago by another company and there's not even simple unit tests. That's the hard truth. But still, even as complex setup as you have, there's still go…
Android as an OS does not support rollbacks. It can only upgrade apps in monotonically increasing `versionCode`s. The simple reason is that client side data may have been upgraded by a newer release to a format that is now incompatible with the old version. Sqlite databases follow the same policy.
This is well-known to anyone who has been doing Android development for a while.
Re: Prisoners of Google Android development
#44While I concur with the author on the challenges of Android development, the author made two major mistakes. One, he didn't test his app on the latest version of Android. This a very major mistake and the reason why we keep 11 virtual machines around with all the versions of Android that our app is supported on. Two, when you release an app on Google Play, you never, never, never deploy the app to 100% of your user b…
I agree that things could have been done better in many ways. However, as explained, it is a legacy application, which does not see any active development nowadays and it would just not make sense to build such a robust QA. This particular app have been written long time ago by another company and there's not even simple unit tests. That's the hard truth. But still, even as complex setup as you have, there's still go…
> it would just not make sense to build such a robust QA.
Well that's a lesson you won't need to learn twice, isn't it?
Re: Prisoners of Google Android development
#45Earlier quoted context omitted.
I agree that things could have been done better in many ways. However, as explained, it is a legacy application, which does not see any active development nowadays and it would just not make sense to build such a robust QA. This particular app have been written long time ago by another company and there's not even simple unit tests. That's the hard truth. But still, even as complex setup as you have, there's still go…
Unfortunately, as you noted, the game is rigged and you have to play within the sandbox provided. With that, and as you also noted, your testing simply needs to be better, especially since this is a customer-facing app and not an app that's solely used internally. As for dealing with the rollout when a serious bug is now in production, if you didn't roll out your app to 100% of the user base you could halt the roll o…
A-ha - good tip about roll-out, uninstall & install. Was not aware of that possibility. But yeah, it's still a hack and there should be a better way - just let me delete/cancel latest release even if roll-out is 100% for whatever reasons.
About better testing - there's always room to improve testing, but no way it's going to happen with a legacy application where no active team is assigned. Only these irregular updates mainly forced by Google are done. Unfortunately.
Re: Prisoners of Google Android development
#46Earlier quoted context omitted.
I agree that things could have been done better in many ways. However, as explained, it is a legacy application, which does not see any active development nowadays and it would just not make sense to build such a robust QA. This particular app have been written long time ago by another company and there's not even simple unit tests. That's the hard truth. But still, even as complex setup as you have, there's still go…
Android as an OS does not support rollbacks. It can only upgrade apps in monotonically increasing `versionCode`s. The simple reason is that client side data may have been upgraded by a newer release to a format that is now incompatible with the old version. Sqlite databases follow the same policy. This is well-known to anyone who has been doing Android development for a while.
Totally understand that a roll-back is more complex, but it doesn't explain why pulling back/pausing/deleting/yanking a release is not possible either - customers who got the newest faulty release can uninstall & install to get the previous version back (no need to worry about incompatibilities here) and the ones who did not get the updated version yet can stay using the old one until a new fixed version will be released.
Re: Prisoners of Google Android development
#47> It's time to move back to open (web) standards and take control back into our own hands! Wait till you discover that the web is also half controlled by the company that is causing your problem now (Google). And Apple who owns Safari, the only browser on iOS in the real sense, isn't really your friend either.
And that hosting it might incur more maintenance work than just billing it.
I certainly prefer a website to a random app that just exist to better track you. But I read the article more as they half hassed the maintenance ...
Re: Prisoners of Google Android development
#48Earlier quoted context omitted.
I agree that things could have been done better in many ways. However, as explained, it is a legacy application, which does not see any active development nowadays and it would just not make sense to build such a robust QA. This particular app have been written long time ago by another company and there's not even simple unit tests. That's the hard truth. But still, even as complex setup as you have, there's still go…
> it would just not make sense to build such a robust QA. Well that's a lesson you won't need to learn twice, isn't it?
It's true that in the future I would do some more thorough testing, but never-ever for this legacy application can I build a bullet-proof automated testing solution - there will not be a budget for that for sure. However, even with a fancy solution mistakes will happen and you still can't stop release propagating. It's just a matter of time when it happens.
Re: Prisoners of Google Android development
#49We need appstore-less, fully device-private system. I'd be really happy to pay premium for that.
well, there's always the librem and pinephone, although they're not at the point of maturity just yet
the current system is already like this if you want to do sideloading/jailbreak/root of your devices. But that was the idea behind these stores: 'don't be like Microsoft and get viruses, we will make sure nooo malware ever enters our stores", which ofc is such a BS.
As for the developer in the story, he could've just make this a .pkg to be sideloaded by their clients, circumventing Google altogether.
Re: Prisoners of Google Android development
#50> It's time to move back to open (web) standards and take control back into our own hands! Wait till you discover that the web is also half controlled by the company that is causing your problem now (Google). And Apple who owns Safari, the only browser on iOS in the real sense, isn't really your friend either.
And that hosting it might incur more maintenance work than just billing it. I certainly prefer a website to a random app that just exist to better track you. But I read the article more as they half hassed the maintenance ...
Typical "legacy application situation where no team is assigned to" here. At least I've never seen in my 15+ year career a legacy application, which has a very good maintenance/testing model in place. It will just not work because maintenance/testing needs also resources and updates, but if priorities are in different places then it's not possible. Of course as stated already multiple times - things could have handled in better ways, but this doesn't mean that Google should not allow to stop release at least. Anyway, lessons learned.