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 <mmur...@commonsware.com> wrote: > On Tue, Oct 25, 2011 at 6:23 PM, Andrew Hughes <ashug...@gmail.com> 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 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
