One use case for Ballast in server side applications, or in front end apps without Androids WorkManager, is in scheduling jobs to be run repeatedly in the background. Ballast could support this fairly easily by creating a new module that adds an Interceptor into a View model which dispatches inputs at the appropriate time.
A first POC could be a basic timer-based scheduler. The next addition would be supporting cron syntax for running jobs at a specific time interval.
A final step would be to somehow run the ViewModel in a WorkManager and tie into the filtering behaviors there. It would also be nice to support the same kind of filtering by network state or other properties in iOS or JS.
Open questions:
does it need a distributed lock, for running the same task in a server-side environment? Or simply delegate that to the end-user to figure out?
How to handle failures in the scheduled tasks? Automatic retires (possibly as a separate module)? How to coordinate those retries with what's sent by the scheduler?
should it collect statistics about failures/successes? For notifying or pausing the schedule like a circuit breaker?
One use case for Ballast in server side applications, or in front end apps without Androids WorkManager, is in scheduling jobs to be run repeatedly in the background. Ballast could support this fairly easily by creating a new module that adds an Interceptor into a View model which dispatches inputs at the appropriate time.
A first POC could be a basic timer-based scheduler. The next addition would be supporting cron syntax for running jobs at a specific time interval.
A final step would be to somehow run the ViewModel in a WorkManager and tie into the filtering behaviors there. It would also be nice to support the same kind of filtering by network state or other properties in iOS or JS.
Open questions: