What does requestWindowFeature() do? I used it to create a custom titlebar, but I don't really understand what its purpose is.
The explanation provided in the SDK documentation here does not make sense.
Each activity has an associated window (on which the whole UI draws). This window has default way of being drawn (whether toolbar, actionbar, icons are drawn or not).
However, you can use requestWindowFeature to ask the system to include or exclude some of windows features (toolbar, actionbar and so on).
Here you can find the full list of supported features: http://developer.android.com/reference/android/view/Window.html
As example, you can use FEATURE_NO_TITLE to make a window full screen or FEATURE_RIGHT_ICON to let system know that icon should be drawn on the right side.
Related
I've run into a very peculiar problem with Toolbars. The way my team currently uses the Toolbar is via a wrapper class, let's call it WrapToolbar.
So WrapToolbar will internally setup a Toolbar, and exposes some common Toolbar functions. Things like setTitle, getTitle, etc are available.
This WrapToolbar also sets up a default icon. This way all usages of the WrapToolbar will have this icon available for the screens that need it.
The problem with this approach is that for screens that require additional icons, have to add them via a Menu XML and the onCreateOptionsMenu function.
When we do that, the default icon setup with WrapToolbar gets pushed to the left, and the new icons from the Menu XML get added at the end.
This has worked fine for us until recently when requirements changed, and now are asking for the default icon to be at the end all the time.
I'm currently wrestling with the idea of doing a custom wrapper around Toolbar that exposes the ability to add icons, get the title, set the title, etc. This way we can put the icons in any order, and have ultimate flexibility in how our Toolbar looks.
I'm looking for some guidance on what that might look like. I also want to get some feedback on whether my initial idea to solve for this is flawed in some way I haven't foreseen.
Menus have a built in ordering based on the android:menuCategory attribute - you can use android:menuCategory="secondary" to push a menu item (like your default icon) to the end of the list - all MenuItems without a menuCategory will appear to the left of it.
I'm trying to do minor tweaks to the layout of items inside an ActionBar, and hitting a lot of problems. It would help if I knew (or even better: could override!) the layout which Android is using for the ActionBar itself.
(Android's layout system doesn't allow you to fully control layout of "items" direct from the item itself - all the options are enabled/disabled based on what type the parent/container layout has)
So, for instance...
try to make a custom ActionView that takes "all remaining space" (because you have no title / don't need a title)
...everything breaks. There are lots of workarounds, all of which have their own bugs (I've tried 3 from SO already, and they all break on different versions of Android / different handsets)
this would be TRIVIAL if I could set the ActionBar's layout to "RelativeLayout" and use "layout_toLeftOf" etc
...but the docs don't seem to answer this, nor do they provide a way of setting it. Any ideas? I don't want to have lots of hardcoded, broken code to workaround the API (because it'll make maintaining this app a nightmare :( )
Have you looked at ActionBarSherlock? It's a support library extension that implements action bar on all versions of Android using single API. Also, when it comes to layouts, I often find it very useful to look at the source code. You can find action bar layouts on the very top of the list here.
Load the view hierarchy and then you will be able to see the views that compose any layout.
http://developer.android.com/tools/debugging/debugging-ui.html
my app is using using Sherlock action bar.
my designer gave me a new design.
the app logo need to be in the middle
2 action items to the left and 2 actionitems to the right of the logo
the app logo height is 1.5 the size of the actionbar (it suppose to be a little overflow)
is it possible to create a custom layout for the actionbar to implement this desing ?
or should i remove my actionbar and implement the design my own ?
if item #3 will be optional , does it changes your answers ?
Thanks
I'm sorry, but kick your designer in the...
He doesn't get Android at all and shouldn't design for Android. Either it's an ActionBar and then you should treat is as such and you (or your designer) should follow the common pattern on Android, or it is not.
If it is no ActionBar, please do not use an ActionBar (no matter which library) and create a custom design that deviates enough from an ActionBar so as not to confuse users!
Please forward your designer, and your manager to Android design patterns site at http://developer.android.com/design/patterns/actionbar.html . Also tell them that if they want Google to ever feature them, they pretty much have to adhere to these. With all failed use full screen layout and create a custom control on the top
I agree with other answers: that's not an action bar as defined by Android guidelines.
I'll just add that in case you can't go against the design decisions made (yeah, real-world projects sometimes suck and as a programmer you'll have to do what the client asks).
Go with your own implementation. I suggest simply creating a fragment with the appropriate listener interface (a common Android pattern, let the activity implement the interface, set the fragment's listener in onAttach).
If you want to implement this (and I pretty much agree with the other posters, that this is non-standard, and probably shouldn't be done).
You won't be able to create this style ActionBar with the standard APIs (or ActionBarSherlock for that matter) - since your UI is non-standard
You could create a RelativeLayout, with your icon in the center (centerInParent="true"). Then in the same layout, you could create a background, with width set to "fill_parent", and the height to 2/3 the size of your center icon (calculating this value in DP).
Then you can create ImageButtons for your 2 ActionItems to the left and to the right, then just put them in your layout relative to the center icon.
Bottom line, you probably should re-think your UI, to make this more standard to the design patterns specified by Android. If you still want to do it the way your designer asks, you will need to do a custom layout (using a RelativeLayout as I suggested is one way to accomplish the UI you are looking for).
You could create a RelativeLayout, with your icon in the center
centerInParent="true"
Then in the same layout, you could create a background, with width set to fill_parent, and the height to 2/3 the size of your center icon (calculating this value in DP).
Recently I became the proud owner of an Android 4.0 tablet and have been snooping around trying to create some apps. Now that I have the basics covered, I'm diving more into the "what's good/what's wrong" parts.
As far as I understand, the old "menu/settings"-button is deprecated (in the sense that you shouldn't use it anymore) and now the ActionBar is the way to go. Upon reading further, I came across this: http://developer.android.com/resources/samples/ActionBarCompat/index.html
It shows how to use the ActionBar on pre-API 11 systems. On the left you can see the typical menu where all options are shown a developer decided weren't important enough to be in the actual UI (the "wrong" way, but programmed using the newer ActionBar API). On the right, that same menu is now on the ActionBar.
My question is: Since it's been said such an "overflow"-menu is bad design on older mobile devices, is it also bad design when it's on the ActionBar as a button like shown on the right screenshot? Or is it only considered bad design because on a lot of devices it required you to press a physical off-screen button which makes it a non-issue when it's a virtual button on the ActionBar?
In short: Should I avoid it or not? Frankly, I like the idea of having a menu on the far right with all options that either don't fit or aren't important enough to be their own entity on the ActionBar.
Please also point out if any of the information I gathered and explained here is wrong.
The options menu hasn't been removed, it's just moved. It used to be hidden "behind" the Menu button on the device, but it's now moved to the ActionBar. Items on the menu either show as icons on the ActionBar, or on the overflow menu. You use exactly the same code to add items, whether to the old style menu, or the new style ActionBar.
A big part of the improvement that's been made is there is now a visible button on the top-right of the screen to open the "menu" (ActionBar overflow), which is right next to the other options. this is much better than before where the menu button had no visual connection to the app.
I suggest you look at ActionBarSherlock, http://www.actionbarsherlock.com, as it makes it pretty easy to add the full ActionBar to pre Android v3.0 devices.
http://developer.android.com/design/patterns/actionbar.html
Finally, I'd suggest that you follow the UI guidelines from Google. If they say the ActionBar is the right approach for navigation, then use it. It's best to use the provided UI patterns, and focus on the domain-specific stuff in your app.
Could anyone give me a tip on how to build a layout like in the following picture?
The application i'm working on has absolutely nothing to do with VoIP but I'm trying to build something like this. One fixed toolbar at the bottom, an interchangeable middle pane with listviews, scrollviews or other, and another toolbar at the top which would change depending on the button selected on the bottom bar.
Also, would it be possible and good practice to keep all of this within a single activity?
You should NOT build an interface like this. Don't use bottom bars! Don't use labelled back buttons on action views!
You should read the Android design guidelines and then work with tab views... and other stuff referenced there and build an Android app.
Also, would it be possible and good practice to keep all of this within a single activity?
-Yes for sure, and yes with a slight catch, depending on what you mean.
One approach would be to create your top and bottom bars inside their own XML. Then in your activity onCreate() inflate and add at the top and bottom of your Layout.
If the bottom bar will not change ever, then you could actually add that into the layouts you already have. If you do it that way, to handle the listeners you could create an Activity that contains just the bottom bar click listeners and then extend that with all of your other activities.
Since the top bar can change though you'll probably have to inflate and add the views to that at run time, that way you can react to what is going on to add / remove / present the appropriate views in the top bar.
Also just because it is somewhat of a pet peeve of mine:
When designing your bottom bar please seriously consider the fact that some devices have soft buttons directly underneath the touch screen. And they are rather close to the screen on some devices. Applications with a bottom bar that is not tall enough create an opportunity for the user to hit one of the system buttons instead of one of the bottom bar buttons as they are intending (or vice versa). Which from a users perspective I must say is VERY aggravating.
Do not use bottom bars. To give a more familiar UI, put all of those functions into the top bar. Start by looking at the source code for the ActionBarCompat project in your android sdk sample folder.
The Android developer site is a good place to start. See
UI Guide
I also agree with the poster who recommended against this specific layout. It seems to have been developed for an iPhone and shouldn't be used "as is".