|how to check if device has hardware search key||Latimerius||9/29/11 9:43 AM|
I thought querying the SPECIAL_FUNCTION KeyCharacterMap instance for KEYCODE_SEARCH would do the trick, however there's no SPECIAL_FUNCTION until API Level 11, whereas I need to support 7.
|Re: how to check if device has hardware search key||Studio LFP||9/29/11 1:49 PM|
I'm not sure if there is a way to check if it has a hardware search key. I would have thought it would be in the PackageManager.getSystemAvailableFeatures(), but I checked it and it doesn't have any listing for it.
Since the new ICS (Ice Cream Sandwich) version is based on Honeycomb and the hardware for that has no physical or touch keys for Back, Home, Menu and Search, you may just have to ask the user or allow the user to map whatever function you want to a specific key code. The search key may be on the screen or on the hardware, but it should still fire the same key code event in an onKeyEvent.
|Re: how to check if device has hardware search key||lbendlin||9/29/11 3:50 PM|
I seem to recall that Dianne already answered that question stating the same (no way to tell)
|Re: [android-developers] Re: how to check if device has hardware search key||Latimerius||9/30/11 3:25 AM|
Thanks for the replies!
Having no way to check seems unfortunate to me. I mean, a lot of people bemoan Android "fragmentation" and the need to check before you use a feature (and to provide a fall-back if you can't). I don't mind any of that, but not even being able to check really takes the problem to the next level ...
Sure, I let the user configure their controls - but if I can't tell what buttons their device has I can't even give them a reasonable default.
|Re: [android-developers] Re: how to check if device has hardware search key||Mark Murphy||9/30/11 4:07 AM|
On Fri, Sep 30, 2011 at 6:25 AM, Latimerius <l4t1m...@googlemail.com> wrote:
You should not be relying up on the existence of SEARCH, CAMERA, or
SEARCH is supposed to invoke a search. When using SEARCH for search,
_The Busy Coder's Guide to *Advanced* Android Development_ Version 2.0
|Re: [android-developers] Re: how to check if device has hardware search key||Latimerius||9/30/11 4:51 AM|
On Fri, Sep 30, 2011 at 1:07 PM, Mark Murphy <mmu...@commonsware.com> wrote:
Sure, I'm not relying upon it. I do have other means. I'm just saying being able to check for hardware would enable me to spare some users having to go to settings and map their buttons if they have any.
Plus, to be honest I don't see much of a reason not to include a way to check for a button.
I'm not using the Search button to search in this case. This is just part of a dev UI until on-screen controls are finished.
Having said that however, it will also say that using hardware buttons is likely to give a more pleasant user experience so it would be worth considering even for the end user interface.
Anyway, things are the way they are so I guess this is mainly just idle talk ... ;-)
|Re: how to check if device has hardware search key||Studio LFP||9/30/11 7:34 AM|
Keep in mind that with the new generations of phones and Android 4 coming, hardware buttons may be a thing of the past.
I'm sure it will be up to the hardware providers, but removing pieces of hardware just makes the phone cheaper and have less failure points. Hopefully less money in buttons, and the likes, means more money put to CPU, RAM, display, etc.
|Re: how to check if device has hardware search key||Zsolt Vasvari||9/30/11 11:12 PM|
> Having said that however, it will also say that using hardware buttons isWhat's your definition of "hardware" buttons? Do you consider the
buttons on the Nexus One to be hardware? I don't -- they are
dedicated buttons, but there is nothing mechanical about them. It
really is no different than using the button bar on Honeycomb.
|Re: [android-developers] Re: how to check if device has hardware search key||Dianne Hackborn||9/30/11 11:42 PM|
What do you mean by go to settings and map their buttons? There is a well-defined keycode for search; you shouldn't need to ask the user to map that to anything.
Anyway, our recommendation is to assume the search button isn't there and always have another way to start a search. In practice many users won't be aware they can search if you are only relying on the hardware button. (Good argument for that button going away...)
Android framework engineer
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.
|Re: [android-developers] Re: how to check if device has hardware search key||Latimerius||10/3/11 2:44 AM|
Sorry, "hardware" was not the right term to use. I have no hands-on experience with Android past 2.2 so I didn't realise there are on-screen system/button/status/whatever bars on Honeycomb. I'm still not sure how exactly those work anyway, especially how they interact with full-screen apps.
I guess what I meant was "how to check if the device has a control element that's always there, that the user can operate at any time and that sends KEYCODE_SEARCH". Ordinary hardware pushbutton is OK, "virtual" key (like on Galaxy S or Galaxy Tab or I presume Nexus One) is OK, an on-screen overlay that's never hidden even if the app is full-screen GLES would be OK, too.
Sorry for the confusion, hope this makes it clearer.
|Re: [android-developers] Re: how to check if device has hardware search key||Latimerius||10/3/11 3:02 AM|
On Sat, Oct 1, 2011 at 8:42 AM, Dianne Hackborn <hac...@android.com> wrote:What do you mean by go to settings and map their buttons? There is a well-defined keycode for search; you shouldn't need to ask the user to map that to anything.
Sure, but as I mentioned in a previous message I'm explicitly and intentionally *not* using the button to search. I'm working on a game (well, entertainment software would be a more precise description but anyway ...) and to make it short, I'm just looking for a convenient way to control the program during development.
Note this is *not* meant for release controls, at least at the moment. The problem is developers need to access more internal functionality directly (e.g. for testing) than will be exposed to the end user so I'm just looking for something reasonable to bind this to.
In this case, it's much more convenient to operate the program using off-screen controls so I'm looking to leverage whatever the devices has.
I already have a section in Preferences that lets people pick a control scheme based on what their device has so that's not a problem. I just thought if I could detect it myself I could automatically select a good default for the user.
If I can't check I have to set the default to the least convenient scheme that works everywhere and ask everybody with devices that support more to set their controls manually.
What would be the problem with letting programmers check if there's something on the device that sends KEYCODE_SEARCH?
|Re: [android-developers] Re: how to check if device has hardware search key||Dianne Hackborn||10/3/11 12:49 PM|
Okay yeah for a game, I think it often makes sense to allow the user to map whatever keycodes their device can generate to your control inputs. This has nothing to do with a search key though... in fact, trying to think about it as a search key is just going to make your problem worse because, since you aren't actually using it as a search key, this is semantically meaningless, and the thing that does matter (where it is positioned in relation to other keys and such) is going to vary widely between devices.
So just let your user press keys to set the control inputs for your game, so they can use it with a dpad if their phone has that, or all other kinds of inputs.
|Re: [android-developers] Re: how to check if device has hardware search key||Latimerius||10/3/11 1:06 PM|
Yeah, you're right. I only thought about it a as a search key because I figured, I can't use Home, I use Menu for menu and I have a different use for Back already - which leaves me with Search out of the four (semi)standard Android buttons. But it doesn't seem to be much good for me to try and be too smart about this.