Multipart SMS
https://developer.android.com/reference/android/telephony/SmsManager.html and it looks like we can split, send the message, and wait for the message sent intent to fire. I propose we wait for 5 minutes for the sending (inspired by Android’s messaging app https://android.googlesource.com/platform/packages/apps/Messaging/+/master/src/com/android/messaging/util/BugleGservicesKeys.java#69) and say the sending has failed.
Seems like a sensible approach!
Confirmation SMS
I think checking for a response SMS from the server is a bit too much to add at this stage. To use that data, the end point, which we don't control, has to send something back that Collect can parse. Let’s do without at first and it’s something that can be added if there’s demand for it.
Agreed. This can be added later as needed.
Multiple Transports
[...] an enumerator can switch between sending over SMS and data by changing the server type in the settings (if that isn’t locked down by an administrator).
I understand why offering a single transport method is a simpler implementation, but surprised that we'd be the only ones routing the submissions to the same place. I would have thought that others using this would eventually route the messages to the same place, even if it has to go via another pathway (eg Zapier, IFTTT, custom gateway, or manual import). In these cases it would seem beneficial to offer a fallback transport if the primary (eg mobile data) is not available.
@yanokwa what do you think of offering in the settings an "Alternate Server", which could be a different type. If an alternate server is set then the enumerator could chose to send with the primary or secondary pathway, or if you want to get fancy only offer the option to send via secondary transport if the primary fails.
Would this be useful for others interested in this feature too?