Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prisoners of Google Android development

solutional.ee

Post reply on HN
Print view View original

171–180 of 318 posts

Re: Prisoners of Google Android development

#171

Post by hn_throwaway_99 »

8note wrote: post #126
hn_throwaway_99 wrote: post #88

Earlier quoted context omitted.

I disagree, at least on the Android side of things (Apple has long been hostile to PWAs). Installing a PWA from a website is trivially easy on Android, it's just that most users really have separated in their minds (not surprising due to history) that apps come from app stores, and the browser is used for websites. Also, Google has made in much easier in recent years to submit plain PWAs to the Play Store: https://yo…

I just have no desire to have an app. The attempt to download one when I visit a website is unwelcome.

That's what's pretty great about PWAs:

1. For people like you that don't want to install them, they're just a normal website.

2. For people that do want to install them for the added functionality (things like notifications), then it is easy to install, and furthermore cheaper for developers to build and maintain (one codebase instead of multiple).

You say "you have no desire to have an app", but I think for most people that's really dependent on the site/application. Yeah, for any site I just have a short term or infrequent transaction, I don't want an app either. But many/most people use apps for businesses they have long term relationships with (namely financial institutions).

Re: Prisoners of Google Android development

#172

Post by callalex »

sofixa wrote: post #158
l72 wrote: post #72

Earlier quoted context omitted.

The problem is that many of my users are temporary. For example, I have an app for the public transit system for a resort town in Colorado. The town has a decent, albeit small bus system. They technically have an app from their vendor, although it is not very good and is difficult to find. If you search for "$town_name transit app", it won't show up anywhere, where as my app does. And I think my app is much more user…

> If you search for "$town_name transit app" Do people really search for entirely temporary/short-term/single-use use apps, like for a resort town's transit or a restaurant? For me it's a last resort thing, if there's no website or it's unusable.

Or just use the built-in Maps app…

Re: Prisoners of Google Android development

#173

Post by jarm0 »

Ozzie_osman wrote: post #162

I don't get the comments tearing into OP. Sure, he could have been more careful. He could have tested the login on the latest version of Android. But what if it wasn't a login crash? What if it worked on the latest version but not others? At what point do you draw the line? At some point, you just have to say "OK this is a platform used by literally millions of apps and millions of developers, and mistakes will be ma…

I'm the OP and thank you for thinking along with me here. As stated in numerous replies already then I totally agree that I could have done better in terms of testing things out - of course, there's always room for improvement in that regard. There was a deadline set by Google (again, first time I heard about it was at 18th of August, not before), change seemed trivial at time and since app worked on an old Android version as it was before then I didn't expect it to fail so miserably. Again, I'm not a seasoned Android dev, but have 15+ years of experience in software development in general so I have some expectations how things will work or not and what to expect and be afraid of. I really didn't know that "best practice" is to do a staged roll-out of "99.99999999%" to have a way of partial "yank" possibility of the latest release. To find out that there's no way to cancel/delete a latest release to fall back to previous working version was just something I did not expect in my wildest dreams (I guess this is something you only learn during situations like these). Yes, everyone can blame me for not testing every functionality with every Android version and I do the same, but please open your eyes and understand that the way releases are currently handled by Play Store is not a sane person would do outside of Play Store. Everyone will have a problem like this at one point and I do hope that this article will and thread in here will lower the number of developers experiencing situation similar to this.

Re: Prisoners of Google Android development

#174

Post by danpalmer »

lubesGordi wrote: post #110
binkHN wrote: post #34

While 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…

What you're saying is totally true and the only pragmatic way to update/release. But it is a shame that if the api update compiles you can't expect things will just work the same way.

This is why you set a version number for the API you want. No type system in wide production use is able to encode the semantics of APIs sufficiently. Many of the best APIs out there have version numbers that allow you to pin the API structure and semantics – GitHub and Stripe come to mind with this.

Re: Prisoners of Google Android development

#175

Post by jarm0 »

imchillyb wrote: post #78
jarm0 wrote: post #28

Earlier quoted context omitted.

Yes, that's definitely one side of the problem and I'm not chasing too much backwards-compatibility. My biggest concern in this particular situation is that there is no way (with Android, at least) to pull-back/cancel/rollback release and everything is blocked behind Google's review process. Why isn't it just possible to "yank" problematic release and continue showing previous release as the latest version. That woul…

Rollbacks allow malicious actors to /simply-easily/ circumvent device security and user preference. To allow rollbacks is to /significantly/ increase the attack surface of a device.

What do you mean by that? Are you effectively trying to say that allowing upgrades does not have any risk of attack surface? I'm pretty sure that updating things have also a pretty high risk on introducing new previously non-existing security issues into your code-base/product.

Re: Prisoners of Google Android development

#176

Post by danpalmer »

gmiller123456 wrote: post #84
nvm0n2 wrote: post #61

In theory this kind of "controlled" backwards compatibility break is good, it lets old apps work whilst encouraging developers to keep up with platform changes. In practice it has the nasty side effect of preventing the scaling of the software industry, and with it, industrial society. Therefore Google should drop this policy and allow old programs to be distributed forever. With near perfect backwards compatibility,…

This is not about backwards compatability. Google is preventing users from installing apps that are 100% compatible with their phone.

Google is preventing new users from installing the app for the first time, on a device that is substantially newer than the app they are installing.

Anyone who has already "purchased" (may be free) the app will still be able to access it, and anyone on an older device can still access it.

I the simplification of this that you specified is ok as a summary, but the devil is in the details, and the details here do make this policy much less impactful than your summary suggests.

Policy: https://support.google.com/googleplay/android-developer/answ....

Re: Prisoners of Google Android development

#177

Post by withinboredom »

izacus wrote: post #152
withinboredom wrote: post #75

Earlier quoted context omitted.

This email was the first I'd ever heard of it.

Play has raised it's tarter API requirements several years now and repeatedly warns a full year ahead of next change. If you never heard of it you've been deliberately playing dumb.

In my case, I was hired to work on an update to a legacy app ~8 months ago. So this is my first round of bs. Been writing software for 20 years and I’ve never seen this before… I wouldn’t consider it playing dumb, I’ve just never had cause to care or receive an email like this.

Re: Prisoners of Google Android development

#178

Post by kergonath »

BaseballPhysics wrote: post #76
l72 wrote: post #51

I 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.

I find it much easier to install a web app from the website than having to find anything on the App Store. There’s nothing easier, it’s only 2 taps when browsing the website, at least on Safari. The process is exactly the same as in iPhoneOS 1.0, when this was the only official way to get applications.

The problem is not that it’s difficult, it’s that the share sheet got bloated and should be completely rethought.

Re: Prisoners of Google Android development

#179

Post by themerone »

zaat wrote: post #154
l72 wrote: post #73

Earlier quoted context omitted.

I agree with you in many cases. At my professional company, we've made the decision to write native apps for Android, iOS, Windows, and the web, because we have pretty deep integration into each platform and want the best native experience for our users. But, for my personal apps (which is what I am talking about in this thread), I can't support that. Writing it once and maintaining it takes up enough of my free time…

The app my accountant provide me - a white-label finance app with the firm logo on it - used to be native. The developers had issues with updating the app to support a change in the camera API and I couldn't scan papers. They sent me get web app instead. Now whenever I use phone's native back button/gesture the app quits instead of going back within the app, there's a functional in-app back button, but my instincts w…

In a properly coded single page application, the back button works as expected.

Re: Prisoners of Google Android development

#180

Post by kergonath »

sofixa wrote: post #158
l72 wrote: post #72

Earlier quoted context omitted.

The problem is that many of my users are temporary. For example, I have an app for the public transit system for a resort town in Colorado. The town has a decent, albeit small bus system. They technically have an app from their vendor, although it is not very good and is difficult to find. If you search for "$town_name transit app", it won't show up anywhere, where as my app does. And I think my app is much more user…

> If you search for "$town_name transit app" Do people really search for entirely temporary/short-term/single-use use apps, like for a resort town's transit or a restaurant? For me it's a last resort thing, if there's no website or it's unusable.

I got Citymapper, and that was the end of me looking for transit apps when going abroad. But true, these days the built-in map apps in all platforms are also decent at dealing with public transport options.
Post reply on HN