> For long-running, expensive processes that do a lot of waiting, a downside is that if you kill the goroutine, you lose all your work.

This is true regardless of the language. I always do a reasonable amount of work (milliseconds to up to a few seconds) worth of work in a Go routine every time. Anything more and your web service is not as stateless as it should be.

Thanks. TIL.

This comment itself proves what should have be `context.isInFoteground()` function call has been made more complicated.

There isn't a single definition of what foreground means and typically usage of something like that would be a signal of poor design leading you to the point of wanting such a thing.

Toast can only be displayed when the app is the foreground.

If there is not single definition of what foreground is then how is someone supposed to know whether a toast will be displayed or not?

If someone wants to know the real definition they need to read the AOSP code. The code is the source of truth and it could potentially change in a future versions if a new security concern came in.

https://cs.android.com/android/platform/superproject/main/+/...

Whether a toast is successfully toasted is reported back to the app's process, but the android framework doesn't expose this result to the app which implies that one shouldn't need to rely on the toast being shown or not.

> which implies that one shouldn't need to rely on the toast being shown or not.

I wanted to display Toast if I can, and if not, a developer might prefer to display a Snackbar or a notification if a Toast cannot be displayed.

I am curious, would an app, say a music player written for iOS in 2015, be usable in 2025?

For Android, I can say that it would have to be re-written ~30% or so. The entire permission model has evolved

  - iOS style runtime permissions
  - permission to access local files
  - permission to display notification
  - special "Foreground service" to run the app in the background ... 

All of these emerged in the last 10 years.

> Just make a web app, works everywhere

I do that whenever possible, but you can't easily build a music player that plays local files.

> Agreed with the article. Some will say just do iOS/Cordova/React Native/Flutter. But these have all the same problems eventually.

I don't have enough experience with iOS. React Native, Cordova [and Flutter], however, as a different problem and that's that you need someone to deal with underlying platform changes, the libraries that you rely on adds another layer of leaky abstraction between your app and the Android platform. Now, you have to wait for someone to update the underlying libraries as well, for example, https://github.com/react-native-community/discussions-and-pr...

So, are the Flutter library maintainers so good that they are able to abstract out all the changes that are happening to Android system libraries, Google's helper libraries, and the restrictions on the underlying platform?

Mostly yes, Flutter is insulated from the underlying platform.

Rendering everything to a canvas has disadvantages but also advantages. Flutter doesn't need to care about most framework changes.

Rendering to canvas eliminates may be 25% of the issues that I listed.

How does rendering to canvas insulate you, for example, from the underlying permissions changes in the Android platform?

> Well, at least I've learned not to bet against the cheaper way of doing something. If the Play Store is too expensive to list in, F-droid will thrive.

F-droid has nowhere near the reach of the Play Store. You can't tell your non-geeky friends to install F-droid to install apps from F-droid.

> There's not 2 different versioning schemes, there's 3! Those clowns sometime use letters. Now you have to recite your alphabet just to know if one version is before or after.

Yeah, thankfully, the alphabet one is mostly used in marketing. The other two show up in documentation interchangeably.

> Why would you do that? This is a self-inflicted wound that exactly matches the title. This isn't like another example of some important system library you need that gets removed, forcing changes

As I mentioned elsewhere in the article, each library supports a certain version of Android; your old library will not support newer versions. E.g. API 33 onwards there is an edge-to-edge display, and older UI libraries won't be able to handle it.

Older UI libraries handle it just fine and there's no need to migrate Material at all.

Really, material doesn't have anything to do with edge2edge.

Not quite true.

Old Exoplayer V2 cannot handle new media style notification that are used on API 33 and later.

What does that have to do with anything I said?