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).
Related
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 started working on making a simple launcher app. I have already gone through many posts and source code of various launchers but I am really stuck at the home screen thing. I just want to create a simple view pager and on long click of it I want it to behave like android stock launcher where user can drag and drop screens to rearrange it and may delete it by swiping down to the cross button.
I am really confused as there is no proper documentation of how things happening in android stock launcher
Please tell me how to achieve this properly. If anyone has extracted that code and give it to me it will be a great help. Links are appreciated.
Thanks!
The standard home screen is implemented as a single large view, with each screen being a child view. Each of those individual screens then lays out icons and app widgets according the grid appropriate for the device.
The way the swiping behavior works is by overriding onInterceptTouchEvent and onTouchEvent. It's tricky because there are so many things that a touch could be doing: the user could be tapping on an icon, swiping to the next screen, or starting a long-press. When you implement one of these behaviors, you have to make sure you don't get in the way of another one.
Once the user is doing a long-press, your launcher app enters a different mode, and the event processing behaves differently in this mode. That is, it implements the standard drag-and-drop behavior. This is tricky too.
I spent two years of my life working on the home screen app for a major device manufacturer. It's complicated, and I'd recommend that you have a good reason for diving into the project.
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.
In the past I've kept my game's options behind the physical menu button for these reasons:
I don't have to have on-screen buttons in-game.
The menu action is consistent with the android user experience; it's not something unique to my app.
In some situations Android provides a soft menu button in the bottom system bar. Looking forward, though (e.g. with recent devices and targetSdkVersions), it seems there's no guaranteed way to have a menu button without implementing the new ActionBar.
If my understanding is correct, I see these options:
Use the ActionBar. Say goodbye to a big chunk of screen real-estate, especially in landscape orientation.
Implement my own on-screen menu button. I've seen this in other games, and it strikes me as inconsistent and terrible.
Target an old sdk version. I don't like this.
Is my understanding correct? Anyone have additional suggestions for my list?
relevant links:
http://developer.android.com/design/patterns/compatibility.html
Android Menu Button on 4.0 Devices
Android 3.0 statusbar & targetSdkVersion in manifest, menu button
android honeycomb menu button target
You could implement a tiny , transparent menu button of your own. Many games do that. That way you are not dependent on anyone and you don't loose any screen space.
Edit : Your menu button could then have follow your game's design.
Is my understanding correct?
Yes.
Anyone have additional suggestions for my list?
Your definition of "terrible" differs from mine. IMHO, any game that has its own stylized graphics and look (i.e., just about anything using the Canvas or OpenGL) should have implemented its own "menu" from the outset, and therefore largely would be oblivious to these changes.
I frequently get designs for android apps featuring iphone-like functionality. In this case it has to do with a back button integrated in the layout as part of the header (on the left side).
Android already comes with a back button - although I have seen some technophobes completely ignore the back button and complain about the flow of an app. ("why is their no cancel button, 1 star, uninstall" push back)
First of all, recreating iOS elements is tedious and counterproductive, but in this case do android users expect a back button in the header at this point? Would a "back" button subtract from a UX at all?
For instance, Android users expect to long-click items in a listview to see what happens - often for options or to delete. Or at least the assumption can be made.
But for a back button in the layout, do Android users get enough apps with iOS-style back buttons to simply expect it?
Insight appreciated
Implementing a back button taking up screen real estate really has no point or benefit for an Android user. The only thing it does is cramp the UI for no real reason since the back button already exists.
Android users don't expect a software back button, since it's simply not the Android way of going back and not many apps have it.. hardly any apps have it actually.
Not only is a software back button completely unnecessary but it could even irritate the user since it could be seen as trying to "iPhone-ify" the app. Not popular at all for some Android users ;)