Problem
When deciding how an app should handle an incoming Android Intent, knowing the type, action, and data values that were sent with the Intent are critical. If your app only handles one very specific Intent, this is OK, but if you have an app that handles images, URIs, video,, etc... you need to know these values.
Right now when an Intent is received via Intent Filter in Titanium, the following lists the values/errors you will get for the data, type, and action functions and properties of an Intent:
*
getData()
always equals
null
*
getType()
and
getAction()
always throw this exception, despite the fact that logic and documentation dictates that these functions do not require arguments:
Uncaught Error: Requires property name as first argument
* The
data
property always returns
null
* The
action
and
type
properties always return
undefined
Proposed Solution
The above listed functions and properties need to return the appropriate values for
data
,
type
, and
action
so that developers will know what to do with the Android Intent that they are receiving. Like I said, if you are handling only one type of data as dictated by your Intent Filter, you are OK. But if you plan to handle images, video, etc... and you need to read them from Ti.Android.EXTRA_STREAM, you have no way of knowing which type of Intent you are receiving.
Also, I believe the implementation of
getAction()
and
getType()
need to change so that they do not require a parameter.
Test Case
var win = Ti.UI.createWindow({
backgroundColor: '#fff',
fullscreen: false,
exitOnClose: true
});
win.addEventListener('open', function(e) {
var intent = Ti.Android.currentActivity.getIntent();
var iname = Ti.Android.EXTRA_STREAM;
if (intent && intent.hasExtra(iname)) {
Ti.API.info(intent.getAction());
Ti.API.info(intent.getData());
Ti.API.info(intent.getType());
} else {
Ti.API.info('No extra named "' + iname + '" found in Intent');
}
});
win.open();
It will also be necessary to add an intent filter to a custom AndroidManifest.xml to get this test case to receive intents. The only below needs to go in the main activity and will receive all image share intents. You can easily trigger an image share intent by long clicking on an image in the android gallery then select 'share' from the intent list. Then just select your test case app from the list.
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="image/*" />
</intent-filter>
If you need a test case, let me know, but this should be present in all handling of Android Intents. It's also worth noting that my testing was done using the
Ti.Android.EXTRA_STREAM
extra. No handling of the actual Intent stream data is necessary to create the above issues, though.Hey Tony, would it possible to provide a test case? I checked the methods on the android side and getType() and getAction() don't require any arguments, so I'm not sure what the issue is there. If you could provide a test case that reproduces the failure, that would be great.
Test case added. Every run will result in the errors I've listed above. I am aware that getType() and getAction() _should not_ require arguments, but they throw an exception if they are not supplied with one.
Looks like this is the same issue as TIMOB-8751. Looks like an easy fix, will have a PR ready soon.
Testing Notes
Use the test case in the description of this JIRA item, except change the line...... to ...
... because Gallery puts the Uri to the selected image in that instead of the
data
property. I expanded the utility ofgetStringExtra
such that if it doesn't find a string extra with the given name, it will also trygetParcelableExtra
with the given name and, if it finds a result, return thetoString()
value of it. This is useful because it would be hard for us to supportgetParcelableExtra
given the myriad of possible return types it has. Unfortunately, one of the most common intent properties,Intent.EXTRA_STREAM
, is retrievable only as a parcelable extra, so it would suck to not have access to that. Thus the expanded capability ofgetStringExtra
at least helps with things like Uris, since their string representations are reasonable equivalents of their actual value.Pull request https://github.com/appcelerator/titanium_mobile/pull/2114
Need additional review. Tested with: Titanium Studio, build: 3.0.1.201212181159 Titanium SDK, build: 3.0.2.v20130117161659 Devices: Droid3 4.0.3 Nexus4 4.2 Actual result: See log for details (Jan18.txt)
Closing ticket as fixed with reference to previous comments.