Support a remote Activity in another App as a question type

[philadams-zz]

It would in some cases be very useful to allow an experiment to launch a different application for the completion of a survey question. This allows developers to extend PACO's question types beyond the standard supported set by tying into existing/novel applications as well as the (already very cool) Javascript API.

Ohmage, a PACO-like system, supports this via a survey question type of 'remote_activity': https://github.com/ohmage/server/wiki/Campaign-Definition#promptTypes

[BobEvans]

Hey Phil,

Sorry about the delay I was out on vacation.

I think I understand this request. Similar to the way that Paco currently uses the Camera app and gets a result back in onActivityResult, this would be the specification of an external app that plays by that same rule? I am curious if there is a particular app you have in mind that we could test against.

Best,
Bob

[philadams-zz]

One option would be to use the lightweight app I'm using for a co-design project. An early version is on the app store - Ohmage launches it using the standard set of package name, activity name, and an Intent action (edu.cornell.idl.meter.ACTION_SELF_REPORT in this case).

[BobEvans]

OK. Presumably, the remote app would call back once it is done with the self report data and Paco should put that into the experiment dataset. Sound like what you are thinking?

Best,
Bob

On Oct 20, 2014, at 9:25 AM, Phil Adams notifications@github.com wrote:

One option would be to use the lightweight app I'm using for a co-design project. An early version is on the app store - Ohmage launches it using the standard set of package name, activity name, and an Intent action (edu.cornell.idl.meter.ACTION_SELF_REPORT in this case).

—
Reply to this email directly or view it on GitHub.

[philadams-zz]

Absolutely, through whatever mechanism makes the most sense for PACO. Ohmage does it by expecting back a particular key in the returned Bundle ('score'), but you can also pass additional key,value pairs either a serialized JSON string or as extra key,values in the Bundle. That data then just gets pushed into the datastore.

From Ohmage's documentation: "These activities must return a JSONObject with at least one key, 'score', whose value is a double. Other key-value pairs may be returned by the remote Activity. The result of this prompt should be a, possibly empty, JSONArray of these JSONObjects"

Yet another example of why Android's data sharing model is so cool.

[BobEvans]

OK. Cool. We will add it to the list of question types to implement. We have a new design for everything that we are starting to implement now and can add something like this.

[philadams-zz]

Awesome - thanks!
Greatly looking forward to seeing the new design.

[BobEvans]

I have created a use case for the new question type, with questions, on the wiki. Please add comments/answers from your particular case there if you would.
https://github.com/google/paco/wiki/Use-Case:-Remote-App-Question-Type

[philadams-zz]

Will do - is there a way within that webpage to comment/answer? Or do I do this in my own fork?

[BobEvans]

Ack. Right, those are not publicly editable. No need to go to all the trouble of a branch. Can you just do it here and I will update the page?

--inserted page with questions--
o enable calling out to another app to retrieve data as part of responding to an experiment. This is exactly like the current photo chooser behavior except generalized. Where the photo input type launches one specific intent, the Camera App, waiting for one specific data type, the url of a photo stored on disk, this question type will allow specification of an intent to launch (on Android, not sure about iOS, maybe the callback-uri mechanism?) and it will receive back a json string containing a key-value tuple that it will insert into the dataset for the experiment as it would for any other question response.

Questions: Right now, there is no way for an input to provide multiple key-value pairs. Is this necessary for this feature.

Size limit, in order not to cause unintended breakage, there should be an upper limit on the data accepted in callback to Paco. Right now, other than photos, which are stored outside the datastore, there is usually a 500 char limit on inputs. Is this sufficient?

Should we have an option to specify a key to look for in the returned json data? Some apps may return multiple responses but perhaps only one is relevant to the experiment.

Should there be a protocol for an error response? For example, the app does not exist on the phone, in which case the intent call will fail. Should we disable the question or fill in a response of "app not installed"?

Another example of error protocol, if the called app cannot complete the data entry, do we expect an empty response from the app, or, a error string to present to the user?

[philadams-zz]

Multiple k/v pairs: I don't believe this is necessary, at least at first. The remote Activity can be thought of as another question type, one that cannot (easily) be implemented in PACO's Javascript layer. And while it's a bit janky, a researcher/developer can always pass a JSON object of their own as the returned value, and parse it themselves when accessing the data.

Size limit: makes complete sense. I can't imagine folk needing more than 500 chars.

Specifying a key: I don't see either way being a problem. Perhaps a non-developer researcher who is using an app that returns this sort of data, who can't edit their remote Activity, would value this option. Certainly Ohmage just requires the remote Activity to use an Ohmage-specified key.

Non-installed apps: I think from the user perspective, filling out 'app not installed' and letting them know a question was skipped for this reason makes sense. Perhaps PACO can surface a link to the Market for installation in a notification? But, this puts a lot of responsibility on PACO - it seems to me that it is the researcher's responsibility to encourage and ensure that their participants have secondary apps installed.

I think if the remote Activity fails, or crashes, then reporting that in the data as well as presenting it to the user is important.

[philadams-zz]

One other thought is, does PACO have a responsibility to inform users about a second app opening, that may (for any actions taken in that app alone) may perform side-effect actions?

[BobEvans]

Interesting question, especially given the nature of Android apps. Since it is designed to operate as an ecosystem of Intents it does put it back on the user to understand what responsibilities they have granted an app.

On the safer side, given the nature of data being collected, it seems imperative to inform the user somehow.

On Dec 16, 2014, at 9:48 AM, Phil Adams notifications@github.com wrote:

One other thought is, does PACO have a responsibility to inform users about a second app opening, that may (for any actions taken in that app alone) may perform side-effect actions?

—
Reply to this email directly or view it on GitHub.