Show snackbar notification when a form is saved or sent

[grzesiek2010]

Closes #5424

What has been done to verify that this works as intended?

I've tested the changes manually and added new automated tests.

Why is this the best possible solution? Were any other approaches considered?

The most important thing here is how I handled passing an URI of a saved form to the main menu in order to display a snackbar with appropriate data. Initially I did it using shared prefs 4e515a5 but then decided to take advantage of the fact that when a form is saved the URI is passed using activity result. This required some changes 0bfc7ac in the way we start the list of forms and the list of drafts to handle the result but I think this solution is more elegant and consistent.

Another thing of note is that I removed marking forms as failed before sending them see 227adcd
This was implemented to avoid editing forms that should be sent but now we do not allow editing finalized forms at all so it is redundant.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Please review the acceptance criteria in the issue and test saving forms according to them. When a snackbar is being created we assume that a form is saved as draft or finalized (and should be sent or not) but it's not sent yet. It would be good to check if it is possible for example using fast devices and small forms that the form is sent (or failed to send) before the process of creating a snackbar is finished because in such a case it won't be displayed at all.

Do we need any specific form for testing your changes? If so, please attach one.

No.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

Before submitting this PR, please make sure you have:

• run ./gradlew checkAll and confirmed all checks still pass OR confirm CircleCI build passes and run ./gradlew connectedDebugAndroidTest locally.
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[seadowg]

Now we've got this to play with, I think there are a couple of behavioural things we should change before diving into a code review:

• The snackbar should be hidden after an action (like "View") is clicked. Right now it's on-screen for a while (which is good), but if you click "View" and then press back to return the menu, the snack bar is still there and is confusing.
• The "It looks like you're offline..." doesn't really make sense as-is. We only show it if the device is connected to the network required for auto send, but somehow also offline which will happen very rarely (even if at all) in reality. I think we should show also show this message in the cases that auto send won't happen (auto send is wifi only, but we only have a cellular connection for instance). We might need to tweak the text a little as "offline" won't be strictly true any longer. It'd be good to get some thoughts from @alyblenkin on this one.

[alyblenkin]

Now we've got this to play with, I think there are a couple of behavioural things we should change before diving into a code review:

• The snackbar should be hidden after an action (like "View") is clicked. Right now it's on-screen for a while (which is good), but if you click "View" and then press back to return the menu, the snack bar is still there and is confusing.

Ah yes, it should go away if you press back to return to the main menu. You wouldn't want to see the snackbar after you've take an action, it should disappear.

• The "It looks like you're offline..." doesn't really make sense as-is. We only show it if the device is connected to the network required for auto send, but somehow also offline which will happen very rarely (even if at all) in reality. I think we should show also show this message in the cases that auto send won't happen (auto send is wifi only, but we only have a cellular connection for instance). We might need to tweak the text a little as "offline" won't be strictly true any longer. It'd be good to get some thoughts from @alyblenkin on this one.

I didn't think about this - good point!

If the device is connected to the network required for auto-send, we show "It looks like you're offline..."

If they have a cellular connection, but no wifi, perhaps we could show "It looks like you don't have Wi-Fi. Your form will send when you are online" or "connected"? I guess they technically have a cellular connection. "It looks like you don't have Wi-Fi. Your form will be sent when you connect"

What do you think?

[grzesiek2010]

If they have a cellular connection, but no wifi, perhaps we could show "It looks like you don't have Wi-Fi. Your form will send when you are online" or "connected"? I guess they technically have a cellular connection. "It looks like you don't have Wi-Fi. Your form will be sent when you connect"

Now I wonder if it make sense to check internet connection and display it in the snackbar at all...

1. Theoritecally it is possible that there is no connection when the snackbar is being created but 1s later when the process of sending forms starts the devices is connected or the other way around so the message might not be accurate.
2. We would need to check more cases and probably display different messages:
   • wifi only is selected in settings but you have no connection or only cellular
   • cellular only is selected in settings but you have only wifi
   • wifi or cellular is selected in settings but there is no connection at all
3. When auto-send fails we display a notification and I think that notification should contain a proper message that explain what happened.

Taking into account all of that maybe the snackbar should always display Sending form… if autosend is enabled and that notification should be responsible for providing more info.

[seadowg]

EDIT: I wrote this before I saw @grzesiek2010's reply (was offline), so some of the comments are redundant. Sorry!

If the device is connected to the network required for auto-send, we show "It looks like you're offline..."

Do you mean if they're connected, but their connection isn't working (like bad signal for instance)? We won't be able to detect that scenario dependably. The only times the phone really knows it's "offline" it can't find a cellular or Wi-Fi network at all. We could try and determine whether we have a "good" connection or not (pinging a known dependable server for instance), but I think that's further than we want to go here (and it's not trivial to do if we're needing to determine the quality of a specific connection type).

If they have a cellular connection, but no wifi, perhaps we could show "It looks like you don't have Wi-Fi. Your form will send when you are online" or "connected"? I guess they technically have a cellular connection. "It looks like you don't have Wi-Fi. Your form will be sent when you connect"

I think this approach makes sense. I guess the different scenarios when auto send is enabled we need to cover could look like this:

1. wifi and cellular enabled, but neither available
2. wifi only, but not available (cellular may or may not be enabled but doesn't change anything)
3. cellular only, but not available (wifi may or may not be enabled but doesn't change anything)

As I'm writing this I'm realizing there's further complexity here: in situation 2 or 3, I don't think we'll ever auto send the form if the connection type we need is disconnected, but the other is working. This is because (as far as I can tell) we currently wait for any connection to try and auto send, but will then determine whether we have the correct connection type or not and (again, as far as I can see), won't reschedule trying to send again if we don't. This would mean in a case where we have a cellular connection, but no wifi and auto send is "wifi only", we'd actually never auto send the form, so we can't say "Your form will be sent when you connect".

@grzesiek2010 could you investigate this to see if I'm correct about those scenarios or not? I think we might want to either rethink what we say on this snackbar, or try and improve the auto send behaviour before adding it (which I'd prefer).

[grzesiek2010]

This would mean in a case where we have a cellular connection, but no wifi and auto send is "wifi only", we'd actually never auto send the form, so we can't say "Your form will be sent when you connect".

In such cases, the Send button in the end screen is not displayed instead we see the Finalize one so it wouldn't be a problem. The message in snackabr would also be Your form was saved and not Sending form....

But again the more I think about it the more I'm convinced that if the button is Send we should always display just Sending form... because as I said above at the time when the scankbar is being created the connection might not be available but after 1s it changes and the form is sent or the other way around. This solution would be simpler and more accurate and potential errors should be displayed in a notification.

[seadowg]

But again the more I think about it the more I'm convinced that if the button is Send we should always display just Sending form... because as I said above at the time when the scankbar is being created the connection might not be available but after 1s it changes and the form is sent or the other way around

Yeah I agree with this. I think we should go with this for the moment (not have a different message for "offline"), and then look at revising auto send to be less brittle in the future. I think there's a lot we could improve around retrying to send when we have the correct connection that would allow us to more accurately say to the user "Your form will be sent later". Does that sound ok @alyblenkin?

If so, let's remove that offline message and hide the snackbar when an action is clicked as discussed here.

[lognaturel]

Agreed just giving feedback that a send attempt is ongoing and giving a way to immediately view the form that was just completed is already very helpful. Seems reasonable to focus on that for this release.

Have we also considered showing a snackbar when an autosend attempt completes? Currently we show a notification but my experience is that those are really easy to miss and they feel less tied to current actions. I think we may have discussed switching to or adding snackbars at some point.

For example:

• autosend runs, a single form is successfully sent: "Form sent.     View"
• autosend runs, multiple forms are successfully sent: "N forms sent."
• autosend runs, there are failures: "Autosend failure    Go to Ready to send" (not sure what that action link should be)

[alyblenkin]

Agreed just giving feedback that a send attempt is ongoing and giving a way to immediately view the form that was just completed is already very helpful. Seems reasonable to focus on that for this release.

Have we also considered showing a snackbar when an autosend attempt completes? Currently we show a notification but my experience is that those are really easy to miss and they feel less tied to current actions. I think we may have discussed switching to or adding snackbars at some point.

For example:

• autosend runs, a single form is successfully sent: "Form sent.     View"
• autosend runs, multiple forms are successfully sent: "N forms sent."

I spoke to @seadowg about the successfully sent message a while back, and we were worried that they could appear out of context or mid-flow when they are filling out another form. I documented some of that conversation here - @seadowg suggested we could maybe leverage system notifications down the road.

• autosend runs, there are failures: "Autosend failure    Go to Ready to send" (not sure what that action link should be)

What about - "Unable to send. Your form is "Ready to Send" later. View"

[grzesiek2010]

If so, let's remove that offline message and hide the snackbar when an action is clicked as discussed

Done.

[seadowg]

Looking good! Just a few things inline, but nothing major.

Before merging, it would be good to rebase this on top of master so that it gets the latest fixes for our instrumentation tests as this is red on Test Lab right now.

[seadowg]

I'm going to mark this "needs testing", as we're only discussing tests now.

[dbemke]

I'm not sure what should be an expected result in some scenarios:

1. Steps:

• Go to Drafts
• Open a form, go to a question
• Tap the device back button and discard changes

In this case the user is moved to the main menu and sees "Your form was saved as a draft"

2. If there are few forms in Ready to send that are being sent at the moment and I'm on the main menu should I see the snackbar "Sending form..." for each form when it's being sent?

[dbemke]

3. Steps:

• In Form Entry settings disable moving backwards.
• Go to Start new form and open a form.
• Fill the form and save it as a draft
• When the snackbar appears click "Edit”

The user is moved to the view of a form with only an "Exit" option which seems ok but on the other hand moving backwards is supposed to prevent edits(?) so the word Edit in snackbar might be confusing?

[dbemke]

Similar scenario to the previous one
4. Steps:

• In Access control, Main Menu Settings disable Drafts
• Go to Start new form and open a form.
• Fill the form and save it as a draft
• When the snackbar appears click "Edit”

The user is moved to the view of a form with only an "Exit" option

[grzesiek2010]

Go to Drafts
Open a form, go to a question
Tap the device back button and discard changes
In this case the user is moved to the main menu and sees "Your form was saved as a draft"

Not perfect but also not something terrible to me. It happens because the snackbar is created whenever after quitting a form its URI is returned. It turns out that when we close a form discarding changes it is returned. I'm not sure if it's the expected behavior but we probably shouldn't touch it so fi we want to improve the current behavior we need to add something to the returned intent when the form is closed to distinguish those cases.

If there are few forms in Ready to send that are being sent at the moment and I'm on the main menu should I see the snackbar "Sending form..." for each form when it's being sent?

No, the snackbar should be displayed only after closing a form for that particular form.

In Form Entry settings disable moving backwards.
Go to Start new form and open a form.
Fill the form and save it as a draft
When the snackbar appears click "Edit”

Here the action name should be View instead of Edit

In Access control, Main Menu Settings disable Drafts
Go to Start new form and open a form.
Fill the form and save it as a draft
When the snackbar appears click "Edit”

As above the action name should be View instead of Edit

I also wonder if it makes sense to have that Save as draft options visible if editing drafts is disabled like in those two last cases but it's something for a separate discussion I guess.

@seadowg what do you think about all those cases? Do you agree with what I said?

[dbemke]

One more question about expected
5. Steps:

• In settings, access control, main menu settings disable Ready to send and Sent
• Go to a form and send it

The users sees a snackbar with "View" option. I don't know if hiding Ready to send and Sent option from the main menu means that the user is not supposed to view forms that are being sent/ were sent?

[grzesiek2010]

In settings, access control, main menu settings disable Ready to send and Sent
Go to a form and send it
The users sees a snackbar with "View" option. I don't know if hiding Ready to send and Sent option from the main menu means that the user is not supposed to view forms that are being sent/ were sent?

Hmm If viewing sent forms was only in the list of sent forms (not in the list of forms to send too) I would say that the View option in the snackbar should not be available but now I don't know... I would file a separate issue for this and discuss it later.

[seadowg]

For 1, I think we should fix this now by not showing a snackbar when exiting a form via "Discard changes/form". In terms of implementation, I think it should be fairly feasible to just not set a result (or set a RESULT_CANCELLED result) in FormFillingActivity when changes are discarded so that the activity result callbacks never end up firing. If it ends up being much more complex than that, then I agree it's something we should look at as a separate PR.

Totally agree that for cases 3 and 4 we should just change the action text from "Edit" to "View". It might be that there's a helper we can pull out (probably from the logic in FormUriActivity) so that we don't end up duplicating things.

I also agree that 5 is something we should discuss as part of another issue - we might not make any changes there.

[grzesiek2010]

In terms of implementation, I think it should be fairly feasible to just not set a result (or set a RESULT_CANCELLED result) in FormFillingActivity when changes are discarded so that the activity result callbacks never end up firing.

You mean removing returning URI in that case like in 76ec768
Generally, I was thinking about that, and to me, that didn't even make sense (retuning that uri) but still, I'm not sure if it's not going to break anything...

[seadowg]

@grzesiek2010 Yes that makes sense to me. It's a change in behaviour that will affect external apps (calling into Collect), so we'll need to announce the change explicitly, but that's ok.

[srujner]

@dbemke already tested this PR

Tested With Success!

Verified on Device with Android: 10, 12, 13

Verified Cases:

• Acceptance Criteria from Show snackbar notification when a form is saved or sent #5424 has been met;
• Issues mentioned by Dominika has been fixed;
• Number 5 will be created as separate Issue to discuss;
• Snackbars with all auto send options;
• Snackbars while auto sent is set to true or false and auto delete is set to true or false in a form;
• Switching to airplane mode while on the end page and trying to send a form in Start new form and Drafts with saving as draft enabled and disabled in Form End;
• Checking audit logs after editing and viewing the form via snackbar in Track changes and Track changes reason, Identify user forms;
• Snackbars while moving backwards is disabled, Drafts disabled in the main menu;
• Using Save as Draft option when Exiting the Form;
• Viewing a sent form via snackbars while in settings Delete after send is enabled and disabled;
• Sending a form while in server setting there is a wrong URL;
• Different font sizes;
• Don’t keep activities enabled/disabled;
• In device settings - no background processes;
• Saving, sending a form added from the form map view;
• Light and Dark Mode;
• Rotate the screen, minimize the app.