feature request: allow arbitrarily named string as IntentCallout responses
Closed this issue · 9 comments
The IntentCallout activity assumes that called services have knowledge of ODK's incredibly specific expectations. Namely that the result be bundled and named odk_intent_data. This makes the callout feature unusable when trying to receive a result from most applications.
Would it be possible to see if odk_intent_data is actually returned, and if not try to getString() for the available keys that match the requested keys? Even if you can only handle strings, it would go a long way to making generally IntentCallout useful.
Hey Shawn, That's a valid point and we do realize that it's constraining when you want to integrate with a general Android application you don't have control over. I think the purpose that having a specific callout key like odk_intent_data serve is to make sure that you are only integrating with Android apps that are meant to integrate with a ODK based Android app. Till now we have rarely encountered use cases where someone wants to receive data into CommCare from a third party Android app thats not meant to feed data into ODK/CommCare. Can you talk about your use case a bit more so that we can evaluate whether it's actually useful to relax this constraint. Thanks.
Sure, we have a requirement to scan some 2d barcodes that aren't handled well by ZXing/ the integrated CC barcode reader as they're very small. We've found another off the shelf Android app that does well with them and has an intent level API which would allow it to be a drop in replacment.
I think the purpose that having a specific callout key like odk_intent_data serve is to make sure that you are only integrating with Android apps that are meant to integrate with a ODK based Android app.
Shouldn't this be a decision for the form designer? Why would you want to limit the apps that Commcare can integrate with? One can still call whatever app they like, they just can't get any useful data returned. I understand expecting a certain format because being able to arbitrarily deserialize anything from an intent is a lot to ask, but being so opinionated in convention that it breaks the intended behavior of intents doesn't feel like a feature.
@shawnsarwar Thanks for the explanation. That makes a lot of sense and I do agree that CommCare should support Android Intents better. We will try to prioritize this work for CommCare 2.51 though we only plan to release it on Playstore by Dec 2020/Jan 2021.
@shubham1g5 Would a PR make this go faster? I might be able to find someone to handle the ticket.
@shawnsarwar we would definitely welcome a PR though we are at the start of our release cycle with CommCare 2.50 rolling out currently. So it would be another ~3 months before it makes sense for us to make another release. We can though make a custom apk available to you that you can distribute to your users.
That makes perfect sense. Thanks! That would be super. I'll see if I can find someone to pick it up.
@shubham1g5 I see that this PR has now been merged. Please when is the release update going to be available on playstore. Looking forward to your reply
@Sameme Our current release is undergoing QA at the moment and we hope to start the rollout of the release in couple weeks and fully complete the rollout by month's end. Here is the pre-release announcement in case you want to test this feature out before the release become available on playstore.
@shubham1g5 Thank you for the prompt response.