Since API 14, right mouse clicks should have been easy to detect via getButtonState().
However, when I right-click, then it acts as the Back button. The middle button acts like the Home button. (Android 4.4, Galaxy Note 3, mouse via USB adapter)
My question:
Does the (smartphone/tablet) device manufactor decide what to do with right button?
Or do different Android versions act differently?
What Android versions / devices support right/middle mouse button?
The default behavior for the middle and right button are as you described for most devices, as is defined by the OS.
Starting at API level 14, there is a way to handle the second and third button from the MotionEvent of a GenericMotionListener.
I suggest you have a look at the answers to this similar question for more details.
The answer is yes, the manufacturer controls how the secondary/tertiary buttons react, because it is compiled with the kernel. Generically the right click acts as a back button, however, on a couple of my non-mainstream tablets it uses one of the mouse's side buttons to go back. Usually the wheel button goes home, all tested on my collection of devices. If you want to know how to override the default behavior, whether it be for an app or as a mod, check out my answer here: Change Mouse Right-click behavior
Hope this clears up everything
Related
My android watch has a single hardware (physical) button on the side. Is it possible to program a listener for this button, so that it can be used as an additional control in my program?
I don't believe this is possible. The usual way to detect a standard button press (like Back) in Android is with an onKeyDown listener, and this doesn't fire in an Activity on Wear when the stem button is pressed (tested on both Wear 1.5 and the 2.0 dev preview).
It's always iffy to assert something is categorically not possible, because there's always the chance that someone will find a clever hack to make it happen. And I wouldn't mind being proved wrong. But until such a hack comes along, I'm going to say no, it's not.
Quick question, Android related..
How do I display a working "THREE VERTICAL-DOTS" floating action button, to trigger same functionality as Android menu button that worked on Kitkat (Android-4), and all previous Android versions?
Details:
I have an Android app that uses Java Native Interface. It worked fine in Kitkat (Android 4.x series), but in Android 5.x, the menu-options button (three vertical dots) no longer responds. Originally, in Kitkat (Android 4.x), the standard Android menu button brought up the applications configuration menus. Now, in Android-5, the Menu button has been replaced with a "Recent Apps" button (this was a very poor design change - probably the worst basic re-design of a working interface I have seen in 30 years... ). Is there an easy way to use a "floating action button" or something like that, to restore functionality of the standard Android "Menu" button?
On Samsung tablets, one can tweak: "Settings / Accessibility / Dexterity and interaction / Assistant menu " to "On", and then a floating-action-button appears, which then has the three vertical-dots as one of it's optional push-buttons, if invoked. Pressing that three vertical-dots button (on the Samsung FAB (floating-action-button)), triggers the old Kitkat/Android4 menu, and at least Samsung users can alter set my app config parameters.
In my app's AndroidManifest.xml file, I have minSdkVersion="8" and the targetSDKVersion="8". I have tried setting the targetSDKVersion to higher levels, which results in a non-functional floating action button, showing three vertical dots, appearing on the screen.
There must be an obvious way to fix this damage that the Android "Material Girl Design" people did to Android Kitkat(and previous Android vers.) Android Menu Button. I've detailed a work-around for my user-base at this point, and released an new app version which offers details on the work-around - at least for Samsung phone and tablet users, but an in-app button really should just appear to allow the main app configuration menu to be triggered.
I have looked at this:
http://developer.android.com/training/appbar/setting-up.html#utility
Don't want an "Action Bar". My app is a DOS-emulator, and needs all the screen space.
I have also reviewed:
Android Options Menu in Fragment
This gets closer, but rather than trial-and-error, I would like to just jump to the solution, if possible. There must be some code or a feature selection that just fixes the little action button that appears (but does not work), when I set the targetSDKVersion="12" (or higher values), in the AndroidManifest.xml file.
My app uses SDL (Simple DirectMedia Layer) vers. 1.2 and 1.3 to control and draw the screen.
I will post the answer here when I find it. I know it is possible, because Samsung is already doing this, within its "Accessibility/ Dexterity.. /Assistant Menu" feature.
I have a custom home app a launcher
so i have control on home key back key and menu key i do what i need but on my tablet a 10.1" IPS Dual Core of Artview i have 4 button
-the back, one with a arrow
-the home, one with a little house
-the recent apps, who look like 2 superposed box (and who on press show recent app)
-the menu, 3 little point
My probleme is i wan't to do a custom think on the 3rd button but android systeme don't let me...
Anyway to do that? And if i have 4 button maybe i don't use the right keycode for the second one
I have finally found a way to do this
No doc about this do it on the onCreate of your activity
getWindow().getDecorView().setSystemUiVisibility(8);
But the 8 is a hidden flag to completly disable system UI with this your app is permanly in full screen(Be carefull if you use this bind power buton to exit app :P)
And don't forget
android.permission.EXPAND_STATUS_BAR
in your manifest
Don't k now if work in every version of android try on 4.0 4.1 and it's work for 3.x don't know.
This question already has answers here:
Are the 4 Android buttons standard? Ex. back button, menu button
(4 answers)
Closed 5 years ago.
Do all Android devices have "option" and "back" buttons? Or should my design have "back" and "option" buttons for making it more versatile?
The Android 4.1 CDD section 7.2.3 contains information on this:
The Home, Menu and Back functions are essential to the Android
navigation paradigm. Device implementations MUST make these functions
available to the user at all times when running applications. These
functions MAY be implemented via dedicated physical buttons (such as
mechanical or capacitive touch buttons), or MAY be implemented using
dedicated software keys, gestures, touch panel, etc. Android 4.1
supports both implementations.
The back button is going to bring back the previous screen on the stack regardless, much like the home button will pretty much always take you to the home screen. As for the option button, it's generally good practice to implement something for it if there are some settings to be changed or something like that, but that really depends on your application. Many apps don't utilize it and do just fine.
No, not every device comes with a back button. Amazon Fire phone do not have a back key.
On Android platform it is always better to be cautious as device manufacturer always do customization.
I am porting an iPhone app to Android, and I can't find the Android equivalent of the UINavigationItem. These are buttons with a triangular side indicating movement between different screens. For an example of what I'm trying to accomplish, this is from the BeyondPod app:
http://mobiputing.wpengine.netdna-cdn.com/wp-content/uploads/2011/05/beyondpod.jpg
The buttons labeled "Categories" and Podcasts" are what I'd like to duplicate.
Android has a hardware back button. Forward is typically accomplished by some widget, such as a button or link, somewhere in the Activity.
I looked at the screenshot you posted again and noticed that your left and right buttons are to switch between categories and not to go to an earlier screen.(Im not sure if im right)
If that's the case using the left and right buttons are okay as they are to switch between categories and not the previous screen. But keeping a left button just to go to the previous screen isn't really necessary. Here we need to think in terms of an android user. They are hardwired to press the hardware back button to go to a previous screen. There are many examples of apps that have a bit of changes in their android and iPhone version. Eg Evernote.
It uses tabs on the iPhone but in android they sort of created a dashboard in combination with an action bar.
So main thing to consider when porting an iphone app is to make enough changes so that an android user will feel like it has a navigation they are used to. Most apps that look exactly the same as iphone apps are created with these cross mobile development tools(titanium, sencha touch).