I completely agree with your last statement. My intention is not to force someone to use a pen-enhanced UI just because they have a pen *capable* tablet. I would simply like to restrict my asking the user if they have an active pen they would like to use with the UI to those users who even have the potential of *having* such a device (those tablets that have active pen input capability). There's no sense in asking a user who's device is not capable of active pen input whether or not they have an active pen they would like to use.
Based on the market research I've done, I've found that most people do not know the difference between an active an passive pen. Many people don't understand how using an active pen is any different from using one of the many many capacitive styli for iPads and Android tablets. I believe this will change as more and more active pen enabled devices are released into the market and people start seeing the differences first hand. Until then, I'm sure if prompted whether or not they have an active pen for their tablet when their tablet doesn't even support active pen input, there will be many users who would respond "yes" and then be presented with a UI that now *lacks* functionality due to their response. While this could still happen with devices that do support active pen input, by limiting the prompt to those devices this situation is further limited (and it is more likely that those users would actually know what an active pen is, even if they don't have one). All that said, I had not considered iterating through the current input devices using getDeviceIds(). This should help a lot, so thank you Diane for that suggestion. Andrew On Fri, Nov 11, 2011 at 5:14 PM, Dianne Hackborn <hack...@android.com>wrote: > 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 <ashug...@gmail.com> 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 <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 >> > > > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > 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 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 > -- 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
