211–220 of 318 posts
Earlier quoted context omitted.
> And if it's just a web site, why do you need to "install" it? A link is surely sufficient? Really? You don't understand the value in having the PWA appear as a native app icon alongside everything else on the device?
You can do that with a link. Just click the three dots then "Add to home screen".
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…
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…
Earlier quoted context omitted.
I would say only the weather and bank apps would be really equal as a PWA. Maps require complex gestures and advanced graphics and UIs that would never work well as a PWA. Try maps.google.com. Its nothing like the Google Maps app. Plus Android Auto integration. Tile probably needs pretty deep Bluetooth integration and background processing that the web doesn't provide. YouTube can do things like PiP that you can't do…
PiP, the one feature of youtube that I did not want (in the majority of cases) but got anyway. edit: Sorry for the snark. I think that maps are probably doable with pointer events ( https://caniuse.com/?search=pointer ) and Android is doing pretty well in terms of Web Bluetooth https://github.com/WebBluetoothCG/web-bluetooth/blob/main/im...
https://developer.mozilla.org/en-US/docs/Web/API/Picture-in-...
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…
> What if it worked on the latest version but not others? At what point do you draw the line? This is a poor excuse. Even if it were a web app, you would still need to test on multiple browsers. Doing a smoke test on a new release is just basic professionalism. And having a phase roll out with a rollback is also not a new concept.
there are a million “shoulds”. just because you know most of them or can afford to account for them on every release doesn’t excuse google for the maintenance nightmare that the android ecosystem is.
Earlier quoted context omitted.
I guess that's why no one uses The Internet or Web Browsers. Pack it in, fellas, the web is a passing fad.
That's not what I said, I live half my life within browsers. But big chunk of the population that you are probably not thinking about is not like that. My mother in law is using browser to read on her computer, and will never do that on her phone - the screen is too small and the whole experience not something that fits someone at her age. On the other hand, my children use apps since they are two years old, and at t…
Most of the people writing on HN were first exposed to the internet through web browsers. On the other hand, children these days who grow up with smartphones first interact with the internet through phone apps. Do they have any difficulty adapting to the unfiltered web when they grow older?
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…
> 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. Which is fine, if that's what you have to do, but at the end of the day I really do wonder what their 30% cut of your revenue is for, then.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> What if it worked on the latest version but not others? At what point do you draw the line? This is a poor excuse. Even if it were a web app, you would still need to test on multiple browsers. Doing a smoke test on a new release is just basic professionalism. And having a phase roll out with a rollback is also not a new concept.
but bugs slip testing all the time, that why even “the pros” have to use staged deployment trick, which takes us to the root problem: releasing on android is like running through a minefield. there are a million “shoulds”. just because you know most of them or can afford to account for them on every release doesn’t excuse google for the maintenance nightmare that the android ecosystem is.