This stuff has a complexity which goes beyond what makes software reliable. The final results is that foreground services get's killed for reasons that nobody can understand and take weeks to debug why !
The problem is deeply rooted in their choice of language such as "foreground" and "background" when all we need is persistent and nonpersistent threads
Stock Android devices are simply not a reliable device to carry out software tasks in a way like a pc because Android is always trying to appeal to noobs who have absolutely no idea about battery and memory, so they entirely focus on prechewing things that are an absolute nightmare
Well, long-running work was supported through foreground services, which are severely restricted on Android 12, and expedited work/job "is not a substitute for long-running work" (10:15). So long-running work is just impossible on Android 12, with or without WorkManager, right?
@@gmk57 it's mentioned that from background you cannot trigger foreground service, for this should use expedited work. It works based on importance of the service and quota available. When running on less quota it will suspend and resume.
Can app still have foreground service in Android 12 when using WorkerManger? 4:40 section says the work is tie with a foreground service to handle the notification cancellation. However, 9:00 section says app can't start foreground service when in background mode. Does this mean everything you said in 4:40 section doesn't work on Android 12? Can anybody chime?
10:32 says the Expedited work runs in the context of a foreground service. My understanding is that this replace the old API setForeGroundAsync in 8:57. On Android 12, instead of calling setForeGroundAsync, developer uses Expedited work instead. There is a catch though. Expedited work can't be long running. This sound like a capacity gap to me that app can't maintain the same behavior on Android 12 for long running background tasks.
Question: does the scenario described in 4:40 section still work on Android 12? If the answer is true, does it have to be Expedited work or a regular WorkManger work?
Google's approach to save battery and have apps which run better is very suffocating for devs lately, but also google is right, there is too much developers doing wrong things(sometimes myself included), poorly designed apps and so on. So google's approach is constraint to the minimum a developer can do. The very bad downside of this constrained environment is that you are narrowing the spectrum of possibilities of what a developer or small startup can do, with their app. There is nothing bad on Implement a Background Service on it's own process, There is nothing bad on Implement a Pending Service (Which I believe is under the hood of Workers) Yes, you may have to do other checks by yourself, like network and other stuff. I been doing android dev for over 10 years and I can see anyone can build an app (which is cool), it's easier with all the jetpack and stuff but also is WAY harder to do non conventional apps. Looks like there will be a lot of Filtering image apps.
"back to the foreground" you think that's funny but really it goes to show how ridiculous your terminology is here The right terminology is a persistent or non-peristent PROCESS (not work) Please stop making new terminology, it's not cool, it's not fun, it's not technical, it's just inaccurate and confusing
I'm starting to think that the Android APIs are so terrible and make absolutely no sense because these people don't respect the English language, simplicity and not reinventing the wheel High quality break strategy? What? Come again? High quality insertion of newlines in text? What? Put the pipe down...
Like what are you talking about man How is a notification not background work? Like how does a notification all of a sudden imply something is running on the main thread? Oh. It doesn't? What? Ok so what is a foreground as opposed to background? Oh. Persistence? THEN SAY PERSISTENT INSTEAD OF FOREGROUND
