Thanks to all for this discussion :) And happy new year !
On 1 jan, 20:23, jotobjects <[email protected]> wrote: > 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 <[email protected]> wrote: > > > jotobjects wrote: > > > On Dec 30, 8:39 am, Mark Murphy <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
