Best to ignore such messages. Call Google's bluff. I do, my apps keep paying out.
Prisoners of Google Android development
131–140 of 318 posts
Re: Prisoners of Google Android development
#132Its actually much worse than what the author wrote about - he/she just messed up execution of roll-out.
If they decided, the app was really not worth it, they could have unpublished it. However, even unpublished apps can jeopardize your account's standing by running afoul of a policy, which Google may have concocted long after the app was written.
Unpublished apps in this state can get your account permanently banned.
You have to support your apps for the rest of your life (if you care about your account).
Re: Prisoners of Google Android development
#133I also got this email, but professionally and personally. Personally, I voluntarily built and run open source apps for 16 different cities for their transit system. This gave me two weeks to update 16 apps, for no benefit of anyone. My app is a PWA, and the Android version just uses cordova + a few plugins to add a few native options. Unfortunately, updating cordova to support the new target android api broke some of…
> Truthfully, I'd prefer to get rid of the app and just have users go to the website and install the PWA, but the average user still doesn't know how to do this. Let's be clear: that's not because users don't know how to do it. It's because Google and Apple haven't made it as easy as installing an app from their app store. That's a choice, and it's a deliberate one.
You mean - click on the share button and “copy to Home Screen”? It’s literally been an option since iOS 1.
Re: Prisoners of Google Android development
#134This is a no-win situation. MS expends an inordinate amount of effort on back compatibility, and much kudos to them. But it vastly increases their attack surface. Likewise many of the worst things about the unfairly maligned C++ come from a hardcore position on back compatibility: as much as possible, old code, and even old C code, should continue to compile and work as expected, even to the point of linking old bina…
I got the impression the author was mainly complaining about Google's role as arbiter of what software users may run. The problems from deprecating APIs are just what brought the author's attention to how vulnerable we've become to Google's whims.
Re: Prisoners of Google Android development
#135It was always obvious that Play Stores and their captive developer "communities" were a trap. Forced API upgrades are just one aspect of that. There are certainly tasks that are best done by a phone or mobile app; usually, these are things that involve moving around, such as navigation, or depend on phone sensors, such as working out which way is "up". But nearly everything else can be done by a website. I'd hate to…
But you don't want to be ideological about user sovereignty over their own devices, do you? Be smart and pragmatic instead, and walk the path of least resistance into a cage.
Re: Prisoners of Google Android development
#136While 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…
> and it would just not make sense to build such a robust QA
Well since it broke, it kinda of would have made sense.
> This particular app have been written long time ago by another company and there's not even simple unit tests
He didn’t do a simple smoke test.
Re: Prisoners of Google Android development
#137Earlier quoted context omitted.
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.
"A bullet-proof automated testing solution" isn't needed for the type of problem you describe. Anything that logs in (including a human on a real device) would catch it even if it does nothing else.
Exactly. It’s a poor excuse that the author didn’t even try to log in to the app with the newest version.
Re: Prisoners of Google Android development
#138This is a no-win situation. MS expends an inordinate amount of effort on back compatibility, and much kudos to them. But it vastly increases their attack surface. Likewise many of the worst things about the unfairly maligned C++ come from a hardcore position on back compatibility: as much as possible, old code, and even old C code, should continue to compile and work as expected, even to the point of linking old bina…
I just don't buy this as an excuse for google. The majority of applications deployed to android are targeting android's bytecode. They aren't natively compiled applications. The reason C++ presents insurmountable security problems is it's low level nature and the fact that once you have a native binary, you're done. But a bytecode for a language with memory safety? How would it be possible to not backport security fi…
> The JVM can still, today, execute and use classes targeting Java 1.0 (released in 1996
Only if you are lucky they don't depend on stuff that started being removed after Java 8, when deprecated for removal went into effect.
Re: Prisoners of Google Android development
#139I do not sympathise with people who build apps for these evil stores. Google and Apple can only deliver value in their app stores because of you tending their gardens. As developers and businesses we must stop tending their gardens. Build on open platforms.
Re: Prisoners of Google Android development
#140Earlier quoted context omitted.
I just don't buy this as an excuse for google. The majority of applications deployed to android are targeting android's bytecode. They aren't natively compiled applications. The reason C++ presents insurmountable security problems is it's low level nature and the fact that once you have a native binary, you're done. But a bytecode for a language with memory safety? How would it be possible to not backport security fi…
> The JVM can still, today, execute and use classes targeting Java 1.0 (released in 1996 Only if you are lucky they don't depend on stuff that started being removed after Java 8, when deprecated for removal went into effect.
That stuff, to be clear, is stuff in `sun.misc.Unsafe`.
Plenty of libraries from that era didn't require unsafe code to accomplish their tasks.
I'm more than happy if google decides to break people who used non-public android apis.