WorkManager brainstorming and future of this library
gotev opened this issue · comments
From Android 8 onwards, Google started to push back on Android Services. With the release of Android 12, services are no longer considerable "first class citizens", as clearly Google is pushing stuff to be made with WorkManager now and it does make sense. You currently cannot start uploads while the app is the background on Android 12.
Current internal architecture revolves around the now "old school" android way of doing stuff:
- Create an intent
- Start a service with that intent
- Do stuff in the service
- Send broadcast intents from the service
- Listen to broadcast intents coming from the service to display the notification or to update some app UI
With WorkManager it will be completely different. Also the library name as it is now won't be representative anymore.
This issue is meant to be a brainstorming room about the future of this library going forward. It's clear that the Service architecture is coming to an end.
I'm also wondering if it does make sense to still maintain the lib, as moving to WorkManager will mean a total rewrite from the ground up, to be "just" a bunch of job implementations to be used with WorkManager APIs, changing the face of this library and its usage completely.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
One note on an issue raised on #657 regarding ForegroundServiceStartNotAllowedException occurring.
One should apply the workaround for this issue noted in https://stackoverflow.com/questions/70711950/android-12-foregroundservicestartnotallowedexception-while-in-foreground if this has not already been done.
See https://issuetracker.google.com/issues/229000935#comment34
I believe there is a point to this library continuing (or perhaps a renamed version thereof) to take the work out of using WorkManager for upload tasks and (hopefully) improving on the current state of affairs by reloading app code only when conditions are met for the upload (e.g. network availability).
One note on an issue raised on #657 regarding
ForegroundServiceStartNotAllowedExceptionoccurring.One should apply the workaround for this issue noted in https://stackoverflow.com/questions/70711950/android-12-foregroundservicestartnotallowedexception-while-in-foreground if this has not already been done.
See https://issuetracker.google.com/issues/229000935#comment34
See
I believe there is a point to this library continuing (or perhaps a renamed version thereof) to take the work out of using WorkManager for upload tasks and (hopefully) improving on the current state of affairs by reloading app code only when conditions are met for the upload (e.g. network availability).
So your point of view is maintaining the library public API and use WorkManager internally instead of the upload service, right?
I believe there is a point to this library continuing (or perhaps a renamed version thereof) to take the work out of using WorkManager for upload tasks and (hopefully) improving on the current state of affairs by reloading app code only when conditions are met for the upload (e.g. network availability).
So your point of view is maintaining the library public API and use WorkManager internally instead of the upload service, right?
Yes. Maintain an easy-to-use but flexible external API but internally use WorkManager to get Google to stop pestering and hopefully improve behavior from a user perspective by letting the OS kill the app/service process when resources are tight and only start it up again when conditions are right for the upload work. That seems like the underlying user benefit of the WorkManager that Google is pushing -- only loading/keeping app code in memory only when actually helpful.
That sounds good on paper. To actually make it, it's necessary to first and foremost be proficient at using WorkManager and know its lifecycle and concepts, then those have to be put in the context of the actual internal architecture of the library and its internal lifecycle, mapping all the needed changes and checking if that's going to cause changes for actual users, eliminating classes and code which will not be needed anymore. After the plan is made, actual implementation could start.
For the foreseeable future I won't have the needed time to do this work, but I'll leave this thread open for everyone who wants to help or try an implementation.