Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-7249] Android: Intent - getData(), getAction(), and getType() do not work

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2012-05-02T10:42:22.000+0000
Affected Version/sRelease 1.8.0.1
Fix Version/sRelease 2.1.0, Sprint 2012-09 Core
ComponentsAndroid
Labelsandroid, core, dr-list, parity
ReporterTony Lukasavage
AssigneeBill Dawson
Created2012-01-17T06:53:32.000+0000
Updated2017-03-24T21:04:18.000+0000

Description

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>

Attachments

FileDateSize
Jan18.txt2013-01-18T15:17:05.000+00002914

Comments

  1. Tony Lukasavage 2012-01-17

    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.
  2. Allen Yeung 2012-04-26

    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.
  3. Tony Lukasavage 2012-04-27

    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.
  4. Josh Roesslein 2012-04-27

    Looks like this is the same issue as TIMOB-8751. Looks like an easy fix, will have a PR ready soon.
  5. Bill Dawson 2012-05-01

    Testing Notes

    Use the test case in the description of this JIRA item, except change the line...
       Ti.API.info(intent.getData());
       
    ... to ...
       Ti.API.info(intent.getStringExtra(Ti.Android.EXTRA_STREAM));
       
    ... because Gallery puts the Uri to the selected image in that instead of the data property. I expanded the utility of getStringExtra such that if it doesn't find a string extra with the given name, it will also try getParcelableExtra with the given name and, if it finds a result, return the toString() value of it. This is useful because it would be hard for us to support getParcelableExtra 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 of getStringExtra at least helps with things like Uris, since their string representations are reasonable equivalents of their actual value.
  6. Bill Dawson 2012-05-01

    Pull request https://github.com/appcelerator/titanium_mobile/pull/2114
  7. Olga Romero 2013-01-18

    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)
  8. Lee Morris 2017-03-24

    Closing ticket as fixed with reference to previous comments.

JSON Source