collect icon indicating copy to clipboard operation
collect copied to clipboard

Allow manually-triggered submission to happen in background

Open lognaturel opened this issue 3 years ago • 3 comments

There are two parts to this: refactoring for maintainability and reconsidering the submission user experience.

Currently automatic sending and manual sending use almost entirely disjoint code paths. This duplication is not good and should be addressed as much as possible. Implementation note: look at using a ForegroundService via WorkManager.

Currently manually-triggered submissions are done synchronously and block the UI.

In some cases this is good and desirable. For example, data collectors may be asked to submit high-priority submissions first and verify that they are all received before moving on to others (and maybe risk running out of credits).

In other cases, even if sending is manually triggered, it could be better for data collectors to be able to do other work in parallel. One hypothetical scenario is one where some submissions will have big attachments and others won't. Maybe we want data collectors to submit small submissions while in the field and wait for big ones to be sent from the office wifi. In the case of the small submissions, they'd like to select them once a day, queue them for sending once there's connectivity, and go about the rest of their data collection. They can't use auto-send because they don't want the big submissions to be queued. This sounds plausible but I'm not sure how likely it is. If it's a real case, maybe we should consider alternative solutions like auto sending submissions below a certain size or actually exposing submission size in the UI.

Backlog

  • [ ] #4881
  • [x] #4884
  • [ ] #4885
  • [ ] #4907
  • [ ] #4908
  • [ ] Remove experimental background submissions setting and dead code

lognaturel avatar Apr 30 '21 19:04 lognaturel

Quick thoughts on this:

  • This would be a great way to drive out getting rid of the InstanceUploaderTask hierarchy and to push us to refactor/clean up/test the upload paths.
  • An initial pass might be to generalize our auto send path and use WorkManager for uploading in both manual and auto cases - we could still have the UI block for manual uploads
  • We could introduce an experimental setting that switches uploads to using a foreground service and not blocking the user - this would let us iterate on the feature and allow people to test in beta without any imperfections blocking a release

seadowg avatar Oct 18 '21 08:10 seadowg

Get real examples of scenarios where data collectors should not use auto-send but have other Collect-based work to do while submissions happen.

@lognaturel A quick thought on this task: I think the mentality to approach this with is that in the future we'd potentially want auto-send to be the default (or only) behaviour, but we'll (likely) always need a "Send Finalized Form" or some kind of "Outbox" to handle failed submissions. That being the case I think we can just move forward with moving submissions to the background as it's advantageous for us (only one code path for submission) and for the user (able to do other things while submitting). I don't think we need to do research into those cases until we're thinking about making auto-send the default (or only) option. I'll get started on breaking this into issues, designs etc but let me know if you disagree.

seadowg avatar Oct 28 '21 11:10 seadowg

Agreed.

lognaturel avatar Oct 28 '21 15:10 lognaturel