Collect: Figure out a way to enable SMS or remove all SMS code by September 2019

Created on 4 Mar 2019  路  3Comments  路  Source: getodk/collect

The decision has not been made yet, but I'm filing this issue so we don't forget.

Either we find some way to re-enable SMS in a compliant way, or we remove the SMS code. I'd like to make this decision by Sep 2019 (6 months after the policy was in place) because if we can't figure it out by then, we probably won't do it.

Related: https://github.com/opendatakit/collect/issues/2738

low priority

Most helpful comment

After discussion with @yanokwa and the Medic Mobile team we are exploring the creation of a side loaded app that handles sending SMS via an Intent. This is similar to option 2 above, but instead of relying on the default messaging app, we'd explicitly call a (side-loaded) app whose sole purpose is to relay the SMS.

Note that apps that use this side-loaded SMS app could optionally fall back to sending via the default messaging app if the relaying app is not present. In this case the message content would ideally be converted so that is it not human-readable and contains a checksum to know if it was altered.

We are working to contribute this SMS relay app to the Community Health Toolkit so that community health apps built with medic-android can use it -- and think that it will be a useful way for Collect to maintain its SMS functionality as well. If anyone else has started something similar, or is interested in contributing please respond here, or join the conversation in https://github.com/medic/medic-android/issues/71.

All 3 comments

There are a couple of options available even without having the permission in the Play store:

1) Product flavor or build parameter to include the SEND_SMS permission and the related code. You can have different permissions in a separate product flavor. By doing it that way the Collect app in the Play store would not have the SMS features, but builds with and without the SMS features could be made available in the GitHub Releases.

2) Android Intent to send the SMS with the default SMS app when the SEND_SMS permission is not given. There are some negative UX implications such as requiring the user to click Send from their SMS app, as well as having the content user editable and readable. That said, it could be better than not having SMS at all!

The options are not completely mutually exclusive, and could be implemented together.

An advantage for those who maintain their own branches of Collect would be that they could stay more up to date with the rest of Collect changes while also choosing to include the SMS features - they may even not need their own branch!

What do you think of these options? Would either (or both) seem feasible?

After discussion with @yanokwa and the Medic Mobile team we are exploring the creation of a side loaded app that handles sending SMS via an Intent. This is similar to option 2 above, but instead of relying on the default messaging app, we'd explicitly call a (side-loaded) app whose sole purpose is to relay the SMS.

Note that apps that use this side-loaded SMS app could optionally fall back to sending via the default messaging app if the relaying app is not present. In this case the message content would ideally be converted so that is it not human-readable and contains a checksum to know if it was altered.

We are working to contribute this SMS relay app to the Community Health Toolkit so that community health apps built with medic-android can use it -- and think that it will be a useful way for Collect to maintain its SMS functionality as well. If anyone else has started something similar, or is interested in contributing please respond here, or join the conversation in https://github.com/medic/medic-android/issues/71.

The strategy described above seems like a good one. Has progress been made in that direction?

It would likely require fairly significant changes to the Collect SMS functionality. We keep running into code or resources for SMS that are no longer in use and causing confusion. Let鈥檚 remove them for now and it can All easily be retrieved from source control and adapted for a new approach in the future.

Was this page helpful?
0 / 5 - 0 ratings