Jump to content

  • Log In with Google      Sign In   
  • Create Account

If you're developing games on an old smartphone with Android 4.0 installed, what should I do with the menu button?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 tom_mai78101   Members   -  Reputation: 572

Like
0Likes
Like

Posted 31 July 2012 - 05:19 AM

According to this article here, Google announced that Android no longer requires a dedicated Menu button.

Since I have an HTC Evo 3D phone, with Android 4.0 installed, I have a menu button. What should I do with it?

And how do I use the new "Action Bar" on Android 4.0?

Thanks in advance.

Sponsor:

#2 frob   Moderators   -  Reputation: 21479

Like
0Likes
Like

Posted 31 July 2012 - 07:32 AM

The menu button has been gone since 3.x; you won't find it on most tablets. They also don't have a search button.

If you want to take advantage of specific buttons then do so, just realize that you cannot count on any button actually being present and usable by your app.
Check out my personal indie blog at bryanwagstaff.com.

#3 TechnoGoth   Crossbones+   -  Reputation: 2769

Like
1Likes
Like

Posted 31 July 2012 - 09:53 AM

It's slightly trickier then that. The action bar provides a lot of great features the android dev site has an extensive article on how to use it (http://developer.android.com/guide/topics/ui/actionbar.html). But you also have to bear in mind the common android dev issue of compatibility. Unfortunately 81% of the android devices are current are using 2.2 or 2.3 (http://developer.android.com/about/dashboards/index.html) which is what most developers build against. So, you will need to decided what your support strategy will be for 4.0+ users and 2.2 and 2.3 user who make up the bulk of the user base. The action bar is just one of the many features that you'll be unable to fully use on older devices. Others include direct wifi connective

It maybe that you release a 2.2 and 4.0 version of your app and maintain two codes bases. Or you use the compatiability back to provide limited support on legacy devices, or various other tricks.

#4 tom_mai78101   Members   -  Reputation: 572

Like
0Likes
Like

Posted 01 August 2012 - 07:37 AM

For compatibility issues, isn't there a way to detect if the Android OS my app is being run on is a version older than 3.X?

I used to know that in C++, when you're programming for certain OS, you can use something like this (And yes, I do know my macros are incorrect, but the point is given):

#if __WINDOWS__
#elseif __APPLE__
#elseif __LINUX__
#endif

Would it be possible to code something like this for Android?

#5 SimonForsman   Crossbones+   -  Reputation: 6122

Like
0Likes
Like

Posted 01 August 2012 - 07:43 AM

For compatibility issues, isn't there a way to detect if the Android OS my app is being run on is a version older than 3.X?

I used to know that in C++, when you're programming for certain OS, you can use something like this (And yes, I do know my macros are incorrect, but the point is given):

#if __WINDOWS__
#elseif __APPLE__
#elseif __LINUX__
#endif

Would it be possible to code something like this for Android?


Those are compile time macros so you'd rather want something similar to getVersionEx on Windows.

http://developer.and...ld.VERSION.html should do the trick.

only annoying part is that the SDK_INT field is only available in newer versions (API versions 4+ (Android 1.6 and up) , and the RELEASE field is a string that may contain non numbers (it can be 4.1b3 for example). (There is also a deprecated SDK field but i wouldn't recommend using that).

If you don't care about 1.5 and down you can just use the value in SDK_INT to see what features you'll have available.

Edited by SimonForsman, 01 August 2012 - 07:52 AM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#6 tom_mai78101   Members   -  Reputation: 572

Like
0Likes
Like

Posted 02 August 2012 - 08:39 AM

If I continue to rely on dynamic version checking (by programming a conditional flag that makes the app detect the right Android OS version, and using that conditional flag to run codes targeted for specific versions of Android), would it make the Android app development more or less manageable?

The reason I ask this, is that in Android SDK, if I were to develop an app for Ice Cream Sandwich, I would see some deprecated values, and sometimes I might get confused with which deprecated functions should I intentionally use.

And there may be a possible scenario that two or more developers were working on the same project targeting at different Android versions. Some lead developer of the team wanted to merge the project together, so that developer A continues the work for Gingerbread, while developer B continues for Ice Cream Sandwich. More like the term branching, the project is then branched into seperate minor projects that ultimately decides the fate of the app itself.

Would that also have an outcome, all because that the menu button and the search button is useless in Android 4.0 on older Android smartphones?

Edited by tom_mai78101, 02 August 2012 - 08:45 AM.


#7 TechnoGoth   Crossbones+   -  Reputation: 2769

Like
1Likes
Like

Posted 03 August 2012 - 06:12 AM

There are a couple of approaches you could take.

Google Play allow you to have multiple apk files for the same app targeting different devices or api versions. So you can build your app against 2.2 and then have a second version of it that is built on 4.0 that references the 2.2. version but has 4.0 specific versions of your UI. This requires good design practices around separating your ui code from your functional code generally know as an api layer.

Another option along a similar line which I came across the other day and I'm currently trying out on my current app is to use an api layer and a factory pattern along with custom widgets. The idea is that rather then use the action bar directly you refer to a custom action bar that provides all the same functionality but under the covers does
version checks and providers either the action bar or a customer built equivalent depending on what the device supports. There is a added complexity around this of course and does mean you may see ui differences between versions. You will also have to build against a newer version then you are supporting which means you have to have
extensive tests against older api versions.

Or you could also take a hard line design decision not support any features that aren't in 2.2 and 4.0

But not matter what you choose you should never ever have developers working on there own bits it what ever version they prefer. Everyone should be working against common set standards and guidelines otherwise things will become unmanageable. That includes api versions, coding standards, naming conventions, etc..

#8 tom_mai78101   Members   -  Reputation: 572

Like
0Likes
Like

Posted 06 August 2012 - 08:01 AM

Ah, this explains everything nicely.

Thanks!

#9 jmrmbz   Members   -  Reputation: 106

Like
0Likes
Like

Posted 03 October 2012 - 01:45 AM

You can also make use of ActionBarSherlock (http://actionbarsherlock.com/). I recently integrated it into an app I'm making

#10 Strategy   Members   -  Reputation: 187

Like
0Likes
Like

Posted 06 October 2012 - 05:12 PM

This is covered pretty well here: http://stackoverflow.com/questions/8774317/handling-the-missing-menu-button-in-new-versions-of-android-3-x-and-up
Michael A.Designer/Developer
A Brief History of Rome
Pirates and traders




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS