Open PMunch opened 2 years ago
I have the very same problem. The app looks great, but the most simple thing is not possible: Working with local files.
This would be very helpful! I'm not a kotlin/android developer by any means, but it looks like this is just a tweak to how the app stores tasks, as well as likely a configuration option to choose your location. Currently it's stored in SharedPrefs (which I think should mostly be used for small sets of data like app preferences anyway). It looks like the correct file storage API to use would be either getExternalFilesDir
or the MediaStoreAPI (depending on whether it is desirable to remove tasks on uninstall)
@bgregos first of all - thoughts? I'm game to attempt the update if you think it a worthy improvement. If so, can you help point me? I'm working to understand the codebase but there's also some Android development mechanisms I don't yet understand (it looks like I need a context
object but the point at which files are saved may not have access to that object?)
@shfattig I think this is a worthwhile feature for sure and I'd be happy to accept a PR that implements this. It may be a bit more work than expected though. The feature will need the following:
deleted.data
and completed.data
will probably require deeper changes since Foreground basically "forgets" tasks once they're completed/deleted and they've been sent to a task sever.TaskRepository.kt:runMigrationsIfRequired
Some additional thoughts:
getExternalFilesDir
or the Storage Access framework (which accesses shared storage). Using getExternalFilesDir
would be great but it means other apps can see your task data by default, which is bad. The Storage Access framework route would require the user to pick a storage directory at first app launch, also bad. My recommendation here is to initially save to context.filesDir
(private app-specific storage) and then have an option in settings to allow saving to external storage with a message about visibility to other apps.context
is your hook into the system and is exposed at the UI layer. We generally don't want to pass this around to other higher layers if we can avoid it since it makes unit testing very difficult. This app uses dependency injection to inject children of context
where needed. The individual children (or children of children) of context
are easier to mock in testing.taskFileStorage
branch.I realize this feature is pretty complex, maybe more so than expected, but I wish you good luck if you want to take this on! I'm available to answer any questions you have along the way.
@bgregos AWESOME, let's do it.
I was able to track down where SharedPrefs is coming from and mimic the implementation using getExternalFilesDir
(and successfully build, run, and write to a file!). This also helped me to find how context
is being used. I also discovered a little more about what Dagger is doing to generate code. I'll have to compare with your branch and see if I'm on the right track.
I see the steps you're pointing out, and I have a few thoughts:
completed.data
and deleted.data
files (at least as a first implementation). I know at least for my mobile taskwarrior usage I'm ok with that limitation.In regards to a storage location, I think handling this particular feature request requires visibility to other apps, so that Syncthing can track the file and read/write. I guess I assumed we would keep the default storage location to SharedPrefs unless otherwise specified, but your recommendation seems to indicate that this feature would actually change the default location as well. Is your recommendation also based on the fact that defaulting to external/shared/visible storage would be bad practice and dirty since it is insecure and requires the user to specify a location?
Do you want me to open a WIP PR to continue communication? Would be an easier place to discuss code changes!
I'm glad to hear you're going to be doing this!
completed.data
and deleted.data
as long as it doesn't cause an issue with Taskwarrior. I think you may need to implement them so the other Taskwarrior client knows that those tasks have been completed. I'm not sure what to do with undo.data
since Foreground doesn't support undo - we'd need some more investigation to see if we need to handle this.Opening a WIP PR sounds good to me!
I have taskwarrior set up with a shared folder through Syncthing to my various devices, including my phone. I'm looking for an easy way to add tasks to taskwarrior when I'm out and about and found this app. It has taskwarrior sync, but only to a taskwarrior server. I'd like to simply point it to my local taskwarrior files and have it work on those instead and let Syncthing handle all the synchronization for me.