Wendy began over 3 years ago. I created it to add offline support for an app that I was building at the time for an app I was building. Since then, the project has matured with improvements here and there as I add it to more and more production apps of mine.
Wendy has been very experimental for years. The more that I used it, the more that I learned about how to build offline apps.
The day has finally arrived. Wendy is ready to become stable. It's ready for it's next major upgrade.
Tasks planned for Wendy v1.0
[ ] Better solution for connecting the Wendy queue system to the UI. Wendy is a job queue. This is not a unique idea. Job queue solutions exist in software already. What makes Wendy unique is it's a job queue system on the client side. This adds the need to incorporate the UI with the job queue system. When a pending task is added to Wendy, the UI of your app should reflect this. It should dynamically change depending on the running state of the pending task. Today, this is done in Wendy through attaching listeners so your UI can change in real-time with the status of a pending task. This is great, but it's limited in it's functionality and requires a lot of work from the developer end. Make this trivial where the power is on Wendy for the most part.
This task also means No more taskId returned when you add a pending task to Wendy. To use Wendy, the developer should not need to be responsible for managing an ID returned from Wendy. Using Wendy's querying system, you should be able to find a pending task anytime in the future if you need it.
[ ] Change the persistent storage solution to be easier to migrate Along with this, consider using the file system for persistent storage. We are currently using a database and I am seeing some cons to that when we could be using the file system with an in-memory cache instead.
This also means we probably need to add a cache to make Wendy faster. This is optional, but an idea of mine. Having an in-memory cache will improve speed but it may be so minimal it's not worth it.
[ ] Improved testing while using Wendy. The pending task API today is not very testable. Dependency injection is not good. This can be improved. Maybe we even remove pending tasks altogether and come up with a different way. ViewModel <--> Repository models are great ways to write code today. Leverage Repositories to do the work for Wendy.
[ ] Deploy Wendy to Maven Central. About time! No more JitPack as the place to get the production build.
[ ] Separate the features of Wendy that are useful to Android UI and features that are purely business logic. This allows projects that are not UI projects (like libraries) can successfully use this project.
[ ] Not as many defaults, be more flexible There are some default behaviors that Wendy performs. The power should be in the developers hands. For example, when you add a pending task to the queue in Wendy today, the queue runs immediately. This should be changed because the developer knows when they want the queue to run. Let them decide.
[ ] Be modern with coroutines
I'm excited. I am not sure when this will be complete so stay tuned. I am also making big, stable changes to my other library to help build offline capable apps, [Teller]https://github.com/levibostian/Teller-Android/issues/74).
gatspy
commented
1 year ago
Wendy began over 3 years ago. I created it to add offline support for an app that I was building at the time for an app I was building. Since then, the project has matured with improvements here and there as I add it to more and more production apps of mine.
Wendy has been very experimental for years. The more that I used it, the more that I learned about how to build offline apps.
The day has finally arrived. Wendy is ready to become stable. It's ready for it's next major upgrade.
Tasks planned for Wendy v1.0
This task also means No more
taskIdreturned when you add a pending task to Wendy. To use Wendy, the developer should not need to be responsible for managing an ID returned from Wendy. Using Wendy's querying system, you should be able to find a pending task anytime in the future if you need it.This also means we probably need to add a cache to make Wendy faster. This is optional, but an idea of mine. Having an in-memory cache will improve speed but it may be so minimal it's not worth it.
[ ] Improved testing while using Wendy. The pending task API today is not very testable. Dependency injection is not good. This can be improved. Maybe we even remove pending tasks altogether and come up with a different way. ViewModel <--> Repository models are great ways to write code today. Leverage Repositories to do the work for Wendy.
[ ] Deploy Wendy to Maven Central. About time! No more JitPack as the place to get the production build.
[ ] Separate the features of Wendy that are useful to Android UI and features that are purely business logic. This allows projects that are not UI projects (like libraries) can successfully use this project.
[ ] Not as many defaults, be more flexible There are some default behaviors that Wendy performs. The power should be in the developers hands. For example, when you add a pending task to the queue in Wendy today, the queue runs immediately. This should be changed because the developer knows when they want the queue to run. Let them decide.
[ ] Be modern with coroutines
I'm excited. I am not sure when this will be complete so stay tuned. I am also making big, stable changes to my other library to help build offline capable apps, [Teller]https://github.com/levibostian/Teller-Android/issues/74).