Thanks very much. This "best practice" outline is worthy of an
official Android blog.
Otherwise developers are going to come up with their own
misunderstandings (like assuming the com.android.camera component will
always be there - not a terribly unreasonable assumption although it
violated the rule against depending on classes outside android.jar).
Two followup questions about intent resolution - It is unclear to me
why the browser was chosen (we don't know what URI was actually
supplied). The API doc for android.content.Intent says "where no
explicit type is included in the Intent, instead the scheme of the
intent data ... is considered". In this case the type WAS included.
So is it correct to say the scheme would NOT be considered in the
resolution? Second question: If there is more than on matching intent
filter doesn't the platform put up a chooser automatically (seems like
I saw that somewhere)?
Happy New Year.
On Dec 31 2009, 6:45 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> jotobjects wrote:
> > On Dec 30, 8:39 am, Mark Murphy <mmur...@commonsware.com> wrote:
> >> Mark Murphy wrote:
> >>> The intent filter you are trying to match is:
> >>> <intent-filter>
> >>> <action android:name="android.intent.action.VIEW" />
> >>> <category android:name="android.intent.category.DEFAULT" />
> >>> <data android:mimeType="video/*" />
> >>> </intent-filter>
> >> Actually, to clarify: that's an intent filter for the built-in video
> >> player (out of the Camera app). One hopes that most devices have some
> >> app that supports a similar filter.
>
> > What is the best way to find out how the intent should be configured?
>
> Magic 8-Ball.
>
> ("Do I need an extra on this Intent?" "Signs point to no")
>
> :-)
>
> > Is going to the source code for the camera app and looking at the
> > manifest the best or only way?
>
> It's one starting point, to be certain.
>
> In this case, it's using a standard action (ACTION_VIEW) and a
> reasonable-looking MIME type. One would hope that there will be 1+
> applications on the device that support viewing that MIME type. As it
> turns out, there are 2+ in Android proper, as the OP reported that the
> Browser handled the request, probably based on scheme.
>
> You'll note that ACTION_VIEW of video/mpeg is not documented in the SDK
> anywhere, at least that I can find. This means that it is possible that
> a given device may have 0 apps that can support it, if some future
> Android edition modifies or drops the intent filter, or if some OEM
> messes around too much. That's the reason for my "tell the client there
> is no default video player" answer from earlier today, because,
> technically, there *isn't* a default video player, at least not one
> that's part of the SDK contract.
>
> > Would you still have to test every
> > device to see if it works with the video viewer app on that device.
>
> That depends a bit on what you want to do and how you want to do it.
>
> Given an Intent, you can use methods on PackageManager to figure out if
> there is anything that would satisfy that Intent. So, if the feature is
> optional, you could use that to disable a menu choice or button or
> something, so the user couldn't attempt to use something that would fail.
>
> Similarly, you can use createChooser() to deal with the case of 2+ apps
> thinking they can handle the Intent (e.g., email or GMail or SMS or
> Twidroid for an ACTION_SEND of text/plain).
>
> If, however, the feature is mandatory (i.e., your app can't run without
> it), you're better served trying to handle it yourself, at least as a
> fallback option. For example, the OP could implement a simple video
> player using VideoView and only resort to using it on devices that fail
> to offer anything that can ACTION_VIEW a video/mpeg.
>
> Where things get icky is if there is some device or app that does
> "support" ACTION_VIEW of a video/mpeg URL, but its support is broken
> somehow. This is not significantly different than a desktop OS video
> player not necessarily having the right codecs to play back such-and-so
> video content, and there's no great answer for that case, either.
>
> Intents and MIME types are not significantly different concepts from
> their equivalents in desktop OSes. We think that Android should know how
> to play video because we see our desktops able to play video from a URL.
> However, at the same time, those of us who don't use Windows much are
> used to the notion that certain things can't readily be viewed (e.g.,
> link to a Microsoft Access database), MIME type or not. Just as savvy
> developers try to make their desktop or Web applications deal with
> varying end user support for different MIME types, so should Android
> developers.
>
> Now, it would be really cool if Google stepped up and declared a more
> extensive list of Intent actions and Uri/MIME types that all Android
> devices should support. That would go a long way towards clearing up the
> sorts of issues the OP encountered. Right now, there's only a half-dozen
> in the list, and none are based on MIME type:
>
> http://developer.android.com/guide/appendix/g-app-intents.html
>
> --
> Mark Murphy (a Commons
> Guy)http://commonsware.com|http://twitter.com/commonsguy
>
> _The Busy Coder's Guide to Android Development_ Version 2.8
> Available!
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
