Collect messaging push notifications

[Jason_Rogena]

@LN

For Ona users who use ODK Collect to fill out forms, how do you currently tell them to update when there's a major change to a form with the same ID? Do you tell them to delete the form and then redownload it?

Ona Data supports updating a form's schema without changing the form id. The users don't have to delete the previous version of the form. Both the old and new form will appear on the list of available blank forms. We, however, recommend the user deletes the previous version only if all form submissions have been finalised (to avoid confusion when filling in a blank form since both the old and the new form versions will likely have the same name).

@LN

am I correct in saying that these things need to be figured out regardless of the way that Collect learns about form updates? In other words, even if you end up building an external app, you'll need to tell Collect to update the form and so Collect has to know what that means?

Yes you are.

@LN

By the way, I tried to verify how all this currently works in my Ona demo account. I was able to replace my form in Settings > Edit Form Settings > Replace form without any errors. However, the new form doesn't show up in either Enketo or Collect.

@LN sorry to hear that. Did the new form have the same form name. If so, it probably showed up on the list of downloadable forms, but with the same name as the old form. It's hard to distinguish if a form has been updated if you don't change the form name.

@LN

It makes sense for Ona, Kobo, etc to run message brokers but I don't really know how that would work for organizations that self-host. With self-hosting, polling may be more appropriate rather than pushing. Additionally/alternately, although I appreciate your point about vendor lock-in, relying on a hosted solution like Firebase Cloud Messaging might be more realistic in a self-host context.

Yeah, I think so too. One potential way of handling this is allowing Collect to handle both (similar to how form submissions can be done to Aggregate, or Google Drive).

@LN

An additional question which I think is relevant to your implementation as well is when registration and de-registration for messages happens.

Whenever a form is downloaded, Collect will subscribe to the MQTT topic corresponding to the form, and listen out for form update and free form messages on that topic.

If the ODK user is updated, Collect will unsubscribe from all the form topics that were previously subscribed to, but that the new user doesn't have access to.

MQTT allows for the broker to preserve messages if Collect ever goes offline, and send the messages (in the order the broker received them) whenever Collect comes back. This should take care of scenarios where Collect is used in setups with intermittent data connections.

Glad to answer more questions.