I want to make a slick GUI for my application. But how would i go about creating a cusom title bar with a back button? And are there any tools to make custom buttons for in android? Or to help make a GUI? Also are there any books that talk HEAVELY about android GUI's?
I want to make a slick GUI for my application.
That's nice.
But how would i go about creating a cusom title bar with a back button?
No sensible Android developer puts "a back button" on the screen, since the OS provides a BACK button for the user.
Be careful when doing too much with custom title bars right now. The Android title bar is morphing into the Honeycomb "action bar" for Android 3.x, and there is a decent chance that Ice Cream Sandwich will give phones the "action bar" as well. While you can style the action bar and do lots of slick things with it, it has a structure that should be adhered to, so Android applications can have a consistent look and feel. If you make your phone apps too dependent on a radically different sort of "custom title bar", you may get UX complaints from users.
That being said, personally I find the easiest way to do a "custom title bar" is to simply get rid of the existing title bar (e.g., android:theme="#android:style/Theme.NoTitleBar" on the <activity> in the manifest) and then do the "title bar" in the activity's own layout. Or, use FEATURE_CUSTOM_TITLE, as described in this blog post.
And are there any tools to make custom buttons for in android?
Photoshop. The GIMP. Microsoft Paint. Etc.
If you are referring to an image to go on the face of a button, you only need one image. If you are referring to a custom background, that gets more complicated, as they will probably need to be nine-patch PNG files, one for each different state of relevance (normal, pressed, selected, etc.).
Or to help make a GUI?
Eclipse has drag-and-drop GUI development nowadays.
Also are there any books that talk HEAVELY about android GUI's?
Assuming you really mean "heavily" (and were distracted by the SHIFT key while typing), then pretty much all of them do. It's not like they're covering Web servers or Beowulf clusters or something.
As to whether they meet your standards for "HEAVELY", read the tables of contents.
Related
What is the point of action bars in android if you can just use a custom linear layout and use that? You can add more robust functionality, you can do much more than with the regular app bar, it's less hassle to use. I can only see the advantage when you tie your action bar to the activity, but most of the apps now have different action bars or no action bars at all for different screens.
Why would one choose one over another, or what even is the use case of action bars
As written in the google documentation https://developer.android.com/training/appbar
"The app bar, also known as the action bar, is one of the most important design elements in your app's activities because it provides a visual structure and interactive elements that are familiar to users. [Pay attention to the point 'familiar to users'] Using the app bar makes your app consistent with other Android apps, allowing users to quickly understand how to operate your app and have a great experience. The key functions of the app bar are as follows:
A dedicated space for giving your app an identity and indicating the user's location in the app.
Access to important actions in a predictable way, such as search.
Support for navigation and view switching (with tabs or drop-down lists)."
To your question.
Yes, it is a valid point that custom action bars provide very robust and diverse functionality, but the point here lies in UI/UX part of the software development.
As you saw in the documentation
Familiarity to users
Consistency in design
Users are not comfortable with design changes as in general, because
Most of them do not even care about the design they just have to do what they have to do.
They have to again familiarize themselves to the new design so that they could remember it and navigate through the user interface faster.
So keeping software development aside for a while it becomes a bit difficult for the end-user.
Also, It might be that the default UI elements work better with the operating system [Cache, CPU, etc. ]
This is related to our design , I think when design is sync with Action bar then it is better to use it but if we have flexible design we have to use custom Toolbar.
Some of benefits of an Action bar that cause developers select it at first :
-Makes important actions accessible in a predictable way (such as Search).
-Supports consistent navigation and view switching within apps.(If you use navigation component is very simple to use Action bar)
-Reduces clutter by providing an action overflow for rarely used actions.
-Provides a dedicated space for giving your app an identity.
And finaly Should you replace ActionBar with ToolBar? YES and NO. YES if you want the flexible header that comes with the Toolbar, NO if you don not need those flexible header. by flexibility, you can do things like adding background image, animations,...
I'm coming from the iOS world and need to port an app with the typical tabbar/navigation pattern to Android. The UI design is the client's decision, so I can't change it (I'd still like to hear from you if you think it's appropriate or not for Android).
So the idea of the app is the following:
3 Tabs are always shown on the bottom of the screen. Inside each tab there can be a hierarchy of screens, with the title and up-button showing in the action bar on the top.
How do I implement this in Android? Am I correct in that the tabs need to be a fragment which need to be implemented in every single activity? How should the hardware back button behave? Say if I switch to a certain tab and then press the back button, should the tab change back or should it mirror the up-button's functionality?
As you can see I'm struggling with all these basic concepts and I'm very thankful for any tip that can help me to implement this navigation structure.
Edit:
Thanks to the competent answer of CommonsWare and looking deeper into it, I realise that I really should push the client to use an UI that's more suitable for the platform. (Also, I know I should use an Android device for some time to get used to the concepts, but I can't change that for now. So I'm sorry for these newbie questions).
The thing is, the app existed before as a web container app with an ugly jquery mobile UI with the above described UI elements. The idea is now to make the app navigation native with native animations, while keeping the content views in html/css/js inside webviews. So while it's possible to adapt each platform's UI principles, I cannot change the general structure of the app, which is: 3 different main entry points, and in each of them the content is navigated hierarchically. I've implemented that in iOS with a tabbar and navigation controllers which works great. The challenge is now to implement it in Android. To reassure that I'm on the right path and understood the points of CommonsWare correctly as well as to maybe receive more tips, I'm writing down what my thoughts on the steps involved:
As CommonsWare suggested, I could replace the tab idea with action buttons in the action bar, which will work well as there are only 3 of it. So it's appropriate to use action buttons for navigation? There will be an additional button for switching the language (Yes I know, usually I should pick the current language of the system, but in this particular app language switching is important and the user will switch it several times while using the app). To separate the navigation action buttons from the language switcher, which works on the current content and is a bit less important, I put the language switcher under the so-called "action overflow" (the 3 dots on the upper right corner).
Now there is an action bar button for each "tab", so far so good. But is there a way the user can tell on which "tab" he is? Or should I only show two action bar buttons at any given time, hiding the one he's currently "in"?
Each of these action bar buttons starts a new activity (with it's own action bar, right?). Inside such activity, the user can navigate hierarchically and back using the up button or back button. He can also use the hardware back button to go back to the last "tab"; would this be appropriate?
Every screen in the navigation hierarchy is a separate activity with a title and a webview.
In the end, to make the whole app compatible back with gingerbread, I would use the actionbarsherlock library, right?
3 Tabs are always shown on the bottom of the screen
That violates the Android design guidelines. On Android, tabs go at the top.
Inside each tab there can be a hierarchy of screens
Outside of a Web browser, I truly detest this navigation concept.
Am I correct in that the tabs need to be a fragment which need to be implemented in every single activity?
You do not appear to have more than one activity in your proposed design.
Say if I switch to a certain tab and then press the back button, should the tab change back or should it mirror the up-button's functionality?
And this is one of the reasons why I truly detest in-tab navigation. Tabs are for presentation of content, not as a navigable container in their own right.
should it mirror the up-button's functionality?
Since you do not appear to have more than one activity, it is unclear to me that you even have an up button.
How do I implement this in Android?
Ideally, you dump the tabs and use action bar items to switch between the different navigable areas, each of which would be its own activity. In that case, back (and to a lesser extent up) will flow more naturally.
If you had more than three tabs, you might go with the navigation drawer pattern, with the navigable areas each having an entry in the drawer. Three, though, would make the drawer look rather empty.
There is plenty more on app structure in the Android design guidelines that can help.
The UI design is the client's decision, so I can't change it
The objective of an app is to allow the users to accomplish their objective. Using design patterns native to a platform help in this regard, by allowing the users' existing experience to guide them in the use of the new app. This is not to say that true innovation beyond the guidelines is inappropriate, but it requires experience and deft hand.
Your client appears to be saying, "hey, this one firm came up with a design pattern for their platform, so therefore let's use it everywhere, as we want a consistent UI design". The problem is that nobody cares about consistency between platforms except them. Few people own mobile devices from multiple platforms, let alone use the same app on both, let alone expect the same UI design on both. Certainly, design touches (e.g., color scheme) could be similar, and the objectives of the app will be similar if not identical. But the delivery of that functionality should use design metaphors and patterns that are native to each platform, as the user is far more important than is your client.
(and if your client says "well, we are the users", because this is an internal-use-only enterprise app, kindly explain to them the concept of the passage of time, introduce them to the notion of employee turnover, and point out that they won't be the users all that long compared to the possible lifetime of the app)
Your client, if they ran a US-based car rental agency, would argue that their firm should rent left-hand-drive cars in the UK, for a consistent UI experience, despite all the accidents that will cause in a left-hand-traffic country.
Now, let's pretend for a moment that you need to write this app following their UI design anyway. Hostages are being held at gunpoint, somebody has a nuke on a hair trigger, the bad guy is demanding the app, the clock is ticking, you're Kiefer Sutherland, and so on.
(and if you really are Kiefer Sutherland, ummm... hi!)
You will wind up with a single activity for this core UI. Ancillary stuff (e.g., preferences, help) would be separate activities, but the three-tabs-to-rule-them-all UI would be in one activity.
The tabs themselves probably would use a FragmentTabHost, perhaps with modifications to better support tabs on the bottom. This is not a common choice, but it's the best fit. ViewPager and a tabbed indicator would be another possibility, if the client does not consider a horizontal swipe to change tabs to be "the devil's gesture" or something. Action bar tabs are at the top and are not always tabs, as they sometimes convert to drop-down navigation in certain screen size and orientation combinations.
Each tab would be a fragment and most likely would use nested fragments for the in-tab navigation between panes of content. Again, there are other possibilities (e.g., lots of hiding and showing of widgets within a single fragment to handle the navigation), but I think you'll go crazy trying to manage all of that.
With respect to the BACK button, without knowing the context of the tabs, my gut instinct would be to follow the tabbed browser metaphor of "BACK is local to a tab". I think that you'll need to manage this manually, unless it magically works because you are using nested fragments, and I don't think that's the case. When you are at the beginning (nested) fragment for a tab, and the user presses BACK, exit the activity.
I am about to start porting an iOS application to Android targeting ICS devices. The PM/designers had originally agreed that we will follow the Android design guidelines to provide users with a consistent experience. However, when I received the wireframes, I noticed that their "tab bar" is at the bottom and that several screens have "segmented controls" at the top.
When I explained that these patterns don't follow the guidelines, they came back with a response to the effect of "Instagram for Android does it and they've been featured and have millions of users."
So I took a look at the Instagram Android app. Here is what the offending screen looks like:
My question is, what would this type of screen look like if it followed the design guidelines. Obviously the tabs would be on top using the ActionBar APIs. However, at that point I think that the segmented controls would only confuse the user since they would appear as a secondary tab bar. I am not familiar with any Android design patterns that mimic the iOS segmented controls in situations like this. Would an ActionBar spinner containing the 2 items be appropriate here? If so, it would seem that we would not be able to keep the "NEWS" title.
Any help is appreciated.
PS. Taking a look at the offending screen with hierarchyviewer reveals that the Instagram tab implementation uses the deprecated TabHost/TabWidget and that the segmented controls are implemented via a (custom) ViewSwitcherButton class.
I am new to Android. So new that I am not even clear on the terminology. From the user perspective, one can swipe from one page (iOS term) to another on Android. I have been told that these are called "panels" - but googling that term, I find out about the notification panel - which seems to be what iOS would call the status bar. Or, perhaps, these are called "home screens"
I would like to find out if there is a way to change the background image as the user swipe from one page/panel(?) to another. For example, I might want my game apps to have a green background and my social media apps to have a blue background. If this can be done by setting a panel's background image, that would be good. If there's a hack with wallpapers, that would be okay, too.
Any pointers to Android UI guideline doc that names visual entities would be great. Likewise, any pointers to a glossary of Android UI terms would also be wonderful.
Thanks in advance.
UPDATE:
I have just come across "live wallpaper" and am wondering if this - with onOffsetsChanged() - is the way to go.
In regards to the widget questions the term has two meanings: the UI components provided by the API such as TextView, Button, and WebView and the other meaning is an icon on the launcher that does more than start an app. The latter is also referred to as App Widget and an example of this would be music player controls or weather report. Both kinds of widgets are documented at the Android Developer website.
Wallpapers are typically Live or static. Live Wallpapers are similar in idea to screensavers but do not have the same function as screensavers are for inactivity. They can also be interactive. Static wallpapers are generally bitmaps that are cropped for the situation or specially made for the dimensions. In addition a Launcher (which is the name of the "desktop application" and the Launcher Home being the "Desktop") can be replaced to provide additional features for wallpapers. For your specific question about having an image gallery style wallpaper, the vanilla Launcher does not support this.
Desktop apps have top level menus (File, Edit, Search, ..., Help).
Web apps have very similar thing, menu tabs (Logo, Questions, Tags, Users, Badges, ...).
However I cannot find equivalent of top level menu in Android framework. Assume that my app has 5 main activities. According to menu design guidelines options menu should contain actions related to current activity. So how an app should allow users to easily switch to one of five main activities.
It seems that different apps solve the problem in different ways. Some have a tab list at the top of the screen, some at the bottom. Even Google applications aren't consisted in that field. Google Listen has an options menu item called 'Listen Home', however Listen main activity has no that options menu item. Others have two icons in app luncher which start two different activities from one app.
I realize that due to small phone screens Android apps have to be designed in a slightly different way than web or desktop apps. But I have a feeling that the app top level menu topic was omitted in Android framework. And developers are on their own here. Or am I missing something?
Update: this is Google blueprint for a great app
Update2: this an example app of these patterns
Update3: GreenDroid library helps a lot implementing these patters in your apps. It seems that dashboard and action bar patterns are becoming quite popular.
You should take a look at this Google I/O session: http://www.google.com/events/io/2010/sessions/android-ui-design-patterns.html
They talk about the design patterns they used for the Twitter application and basically the type of concept you are asking about. Basically, your activity should have a top bar that gives the user specific tasks to do in the view or allows them to switch into another activity.
Google has not implemented anything like this into the actual SDK yet so you're sort of on your own in terms of implementing it but the main concept is given in the presentation. This is the direction that Google would like to see Android shift into though.
Hopefully this helps you out somewhat.
The file/edit menus of desktop apps have a very different purpose than the questions/tags etc. tabs at the top of this webpage.
The contents of the file/edit menu should be implemented as in the options menu that appears when you press the menu button. This is, as you noted, to save space on the smaller screens.
App navigation like the questions/tags etc could be implemented using a Tab Layout. You are right that apps vary in whether or not the tabs are on the top or bottom, but I don't think thats a huge deal. In my unscientific look through apps on my phone, the bottom seems to be more common. However, I think it might depend on your specific implementation which you decide.
A lot of apps don't require any sort of navigation like that, and can get away with just having a path forward or back via the back button. I think this is preferable for a lot of applications, but won't work in all cases.
I'm not sure what more you would want built into the framework.. It seems like you can accomplish any kind of navigation desired with the above options.
You can look at the source of the Google IO app
ioshed