Essentially I'm confused over when and how the options menu is shown with devices with and without menu buttons on Android devices 3.0 and above.
Focusing specifically on options menu, I know from reading that the options menu is inflated in onCreateOptionsMenu (whether via menu button or action bar) and the Google developer site states that 'items in your options menu appear on the screen depends on the version for which you've developed', i.e. bottom menu or action bar.
I've tried a few apps (e.g. gmail) on a Nexus 4 and Samsung phone, both with Jelly Bean. The Nexus has no menu button and gmail displays the options menu in an action bar. On the Samsung there is a menu button and there is no action bar, you have to press menu.
Is the options menu handled automatically by Android or is there some code going on within the app to determine if a menu button is present?
Also, what further confused me (i.e. contradicted this thought) is the Android developer site says if you use Theme.Holo you get an action bar, which kind of tells me it's not implicit how the action bar is displayed.
Thanks for any guidance.
If you want to check if a device has softkeys use hasPermanentMenuKey using
boolean hasMenuKey = ViewConfiguration.get(context).hasPermanentMenuKey();
If that returns true it means you don't have the soft keys.
If guessing most android applications have some sort of built in functionality to do a similar check and determine whether a menu is needed or not.
Normally beginning with Android 4.0 the menu options embed into ActionBar and menu button is removed, but it's not necessary just optional and you have to handle it in your code to show to user
For the menu button on Samsung I guess it is only in the Samsung models, since if you can look at the new models of other device manufacturers, there is no menu button at all. Samsung takes the options button in the action bar to the menu button(harware button).
Related
I know I can "auto hide menu bar" in system preferences, however, what I like to do is hide items like this repository.
https://github.com/dwarvesf/hidden
This repository can hide items on right, but I wonder if I can hide left items (which are application menus).
Any idea is appreciated.
As for application menus on the left, those can't be hidden, I'm pretty sure.
Applications often have the option to enable or disable their menu bar helper app in the main preferences. If that doesn't help, e.g. if it's a full-fledged menu bar app, not just a helper, then to my knowledge the only solutions are Hidden Bar, which you mentioned, and Bartender.
I'm using the latter, and it does a very fine job. You have four options in Bartender's preferences:
Show (default macOS behavior)
Hide (menulet will be hidden in a special Bartender secondary menu bar, accessible via the triple-bullet icon ยทยทยท on the far right)
Always show (menulet will be visible in the main macOS menu bar as well as the secondary Bartender menu bar at the same screen position)
Always hide (menulet will be completely hidden)
Some older menulets seem to switch their position occasionally, e.g. after wake-from-sleep, and Bartender isn't yet able to fix the position of BitBar instances. But for the vast majority of menu bar apps and helpers it will work just fine.
I know how to implement the back button. My question is about the desired behaviour (as I experienced there is a hype around it that the good implementation of back button is required to sell the app in the store).
There is the official source:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402536(v=vs.105).aspx#BKMK_BackButton
But I have never used a WP8 for more than 5 minutes. I understood that the "Windows" button/key is the same as android home and ios home buttons. Is it true, that the WP8 back should be the same as the android back? (Briefly navigate back through pages (screens/activities), dismiss alerts or cancel confirm popups, or if it is the first/only/final page/activity, the app should exit.)
As I experienced, there is a long-press on the back button, which brings up the app switcher (~ios double home). Is it true that I should not take care about of this button? Is the default behavoiur the same for the remaining buttons (windows, power off, camera (half and full), search)? Should I override them? Can I override them (I think I can use camera, but can I use volume controls for other purposes)?
The certification requirements lay out what the back button should do pretty well. In short, it sounds like how you described the Android back button - here are the relevant requirements:
(5.2.4.1) Pressing the Back button must return the app to the previous page or return to any previous page within the back stack.
(5.2.4.2) Pressing the Back button from the first screen of an app must close the app.
(5.2.4.3) If the current page displays a context menu or a dialog, the pressing of the Back button must close the menu or dialog and return the user to the screen where the context menu or dialog box was opened.
You don't have to handle triggering the long-press, nor do you need to handle navigation specifically (assuming you're using the NavigationService for page navigation.)
You can definitely override the camera button, but search, power, and volume are off limits.
I've created an interface nib/xib file. The app is basically working, which is cool. The standard toolbar buttons look bad, they're glossy and raised, while most apps in Lion have the flat, inner bevel look. So I created some image toolbar buttons and put them in the toolbar and they look great, but they're all disabled by default.
Is there a way to give these the correct state in InterfaceBuilder or do I have to use code to give them the proper state.
Cocoa and Objective C are very unfamiliar so it would be helpful to me if I just knew what to search for. Most of my searching brings me results for creating custom buttons for iOS.
I figured this out, here's what you do:
In the nib/xib file, double click your menu bar to show the "allowed toolbar items" sheet. From here, choose your button that you've created. In my case I'll select a back button that I want to connect to a webview control. Ctrl click + drag from the button to what you want to connect it to and then make the appropriate connection. In my case I choose goBack from the WebView.
Once it has a connection it now becomes active.
Is it allowed by Windows Phone application certification rules, to only have users be able to return to a previous screen with the use of a hardware back button?
In my scenario, a user clicks on a setting button and lands at a settings page. He changes settings if he decides to, and all the changes get saved automatically, like in iOS.
But currently, the only way for the user to get out of the settings screen, is to press a hardware Back button on the phone.
Will such implementation of navigation functionality pass the Windows Phone certification?
Yes - leave the back button as the navigation method to get back to your main page after visiting the settings page. Not only is this allowed, but it is the desired method of back navigation, and it is what Windows Phone users expect. Here is a great article on the subject: http://blogs.msdn.com/b/ptorr/archive/2011/10/06/back-means-back-not-forwards-not-sideways-but-back.aspx
As far as I understand the terms of the navigation guideline is your usage the right way to go.
Back button
Pressing the back button from the first screen of an application must exit the application.
Pressing the back button must return the application to the previous page.
If the current page displays a context menu or a dialog, the pressing the Back button must close the menu or dialog and cancel the
backward navigation to the previous page.
You should only implement back button behaviors that navigate back or dismiss context menus or modal dialog boxes. All other
implementations are prohibited.
See this cheat sheet for more informations on the design guidelines.
XCode works in mysterious ways (at least to me).
I simply want to create a Preference pane in my app. When I run my app, the stock menu bar comes up (Apple, MyApp, File, Edit...) and the "Preferences" menu item is grayed out. It makes sense since I haven't started playing with it.
How on earth do I add/remove/activate/inactivate menu items? I'm not talking about adding anything new, simply using what should be there.
Thanks in advance.
NSMenu has "Auto Enable Items" enabled by default. That means if the menu item does not have it's action message hooked up, it will appear grayed out. So in your case, you would simply set the Preferences menu item's "Sent Action" to whatever action shows your preferences window. This can be hooked to some sort of showPreferencesWindow: method of your AppDelegate, or directly to the showWindow: method of a window controller.
To dynamically enable/disable menu items the best way is to implement the NSUserInterfaceItemValidation protocol which is excellently documented here
Edit: Your app's menu bar items live in the MainMenu.xib file. The menu bar appears as a "Main Menu" object on the left hand side (if you're using Xcode 4) Simply click on the items to modify them, and you can Ctrl+drag connections to and from them like any UI object.