The events you get have enough information for you to know what type of device it came from. We will not be having some kind of global information about such devices, for the reasons I already discussed.
If you did this with a uses-feature, you'd shoot yourself in the foot. Seriously. So some device reports that it can support a styles by setting the feature, your app looks at that and goes off into its own world of some kind of stylus-specific UI, and then the user who has not even bought a stylus is confronted by this? Not nice. And that's just the most trivial obvious example of the kind of bad problems this creates. You can iterate through the currently available input devices with this: http://developer.android.com/reference/android/view/InputDevice.html#getDeviceIds() There is an input device source for a stylus: http://developer.android.com/reference/android/view/InputDevice.html#SOURCE_STYLUS Trying to make this broader would do more harm than good. And please note, if you are thinking that you are going to significantly change your app UI because you *discover* that the device has a stylus attached to it, I can guarantee you will regret it for all the same reasons. The devices that are shipping with stylus support could well have that input device available because that is part of the hardware, but that says nothing about whether that is how the user is actually interacting with it. On Fri, Nov 11, 2011 at 4:44 PM, ashughes <[email protected]> wrote: > First off, I would really like to reiterate how important it is that > there be a way to determine if the current device supports an active > pen digitizer. As I said before, using an active pen can streamline a > user interface by allowing certain functionality to be moved to the > pen. This allows a finger touch to perform operation A while a pen > touch performs operation B. This can obviously be done already using > ICS on a device that supports an active pen, however what can't be > determined (either programmatically, through resource qualifiers, or > filtering using the manifest) is whether or not the device you're > currently running on *has* active pen capability (despite whether or > not the user has an active pen with them). The problem this creates is > if you just assume pen capability, and there is no pen, then > everything that you pulled out of your UI and added to the pen, the > user has no way of doing. If you just assume no pen capability, then > you have to duplicate all the functionality you provide in your pen > *also* in your UI. > > Here's a simple example: > Say I'm developing a drawing application that has an infinitely > pannable canvas. I want to be able to do two things: pan around the > canvas and draw on the canvas. On a device that does not support an > active pen, I would obviously have to switch between these two modes: > pan and draw (assuming we are not using multitouch gestures of > course). On a device that *does* support an active pen, drawing could > be always performed by the pen, while panning could always be > performed with a single finger touch. No need to have a UI button that > switches between these two modes. If I wanted to run on both active > pen and non active pen devices, I would need to be able to check if > the devices supports an active pen (and then possibly ask the user if > they actually have one) in order to determine which UI to show. > > I hope that helps clarify the situation and the definite need for > *some* way to check if a device supports an active pen digitizer. > > In reference to Mark's reply: > I'm also not holding my breath for cooperation between device > manufacturers in implementing a common uses-feature without Google's > direction. I don't see, however, why Google would *not* take the lead > an put in these final touches to better support active pen based input > in Android. There are already 4 active pen enabled devices on the > market by 3 of the major manufacturers: HTC Flyer, HTC Jetstream, > Lenovo ThinkPad Tablet, and Samsung Galaxy Note. And I know there's > more to come (the Adobe CTO showed off a Samsung tablet prototype with > a Wacom digitizer in it, and I believe Motorola announced a stylus > with the Xoom 2 but I don't know for sure if it's an active pen). My > point is, most of the major device manufacturers are already > developing or have released active pen enabled devices, and Google > actually now supports active pen input in ICS...so why not make it > more useful? > > Andrew > > On Oct 25, 9:47 pm, Mark Murphy <[email protected]> wrote: > > On Tue, Oct 25, 2011 at 6:23 PM, Andrew Hughes <[email protected]> > wrote: > > > It would also be helpful if active pen support could be listed as a > > > "uses-feature" in the Manifest to use Market filters to keep > applications > > > that require active pen support from being installed on devices that > don't > > > support it. (I believe HTC has a uses-feature descriptor called > > > "android.hardware.touchscreen.pen" that they recommend to be used with > their > > > OpenSenseSDK, but it is not listed as an official uses-feature, > despite its > > > android namespace). > > > > IMHO, this makes sense. However, this sort of thing may not be added > > to the platform for some time, after a few major device manufacturers > > start offering active pens and there's a clear industry direction > > towards having active pens. For example, front-facing cameras were not > > supported by Android until a few device manufacturers started rolling > > out FFC devices (with their own approaches for developer access to > > such cameras) and it was pretty clear most devices would eventually > > support FFC. > > > > Device manufacturers could independently endorse a convention, akin to > > android.hardware.touchscreen.pen, which might well speed platform > > adoption. I'm not exactly holding my breath waiting for such > > cooperation. > > > > -- > > Mark Murphy (a Commons Guy)http://commonsware.com| > http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > > Android 3.1 Programming Books:http://commonsware.com/books > > -- > 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 > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
