Slowly, I believe I am simply to dump to get this to work and hope
that somebody of you, can help me.
I am using the Android Design Support Library, AppCompat and support libarties:
compile "com.android.support:design:23.0.1"
compile 'com.android.support:support-v4:23.0.1'
compile 'com.android.support:appcompat-v7:23.0.1'
All I wanted was a simple Toolbar, Tablayout and a ViewPager getting to work.
Like you can see in every other app, too.
But I am getting an annoying FloatingMenu on every activity that uses the
app_theme.
How do I remove this FloatingMenu?
Cheers!
Douplicates:
Remove Floating menu button from HTC one [noanswer]
Lot of people are facing this problem and its just not related to your code but to what kind of updates vendors have pushed.Try to confirm it by running your app on other devices too with different lollypop version.
Create a mainmenu.xml file with just one item (R.id.action_settings)
and try to inflate it within your code and set the visibility to false afterwards.
That will might solve the issue otherwise go into phone settings and button and then try to find out if there is any option to help you. It should be related to navigation or something i suppose.
Edit
Setting your sdk version 14 or above seems to solve the issue. We went through many hit and trial and this one seems to work. I believe its a sort of bug in the design library.
It's seems like HTC issue try to override
#Override
public boolean onCreateOptionsMenu(Menu menu) {
MenuItem settingsItem = menu.findItem(R.id.action_settings);
settingsItem.setVisible(false);
return true;
}
Related
My old app has one simple menu on the main activity. It has only a few simple options, for instance "About" causing a popup with some info about the app.
It works perfectly on emulator Nexus One (API23), because there is an emulated physical menu button.
However, on most modern phones, there is no button, which means that my menus cannot be accessed.
I actually vaguely remember running it on a phone years ago which didn't have a menu button, yet somehow one could still access the menus. I may remember wrong.
(I started digging into this some days ago, and started modifying my code, the main activity inheriting from something more posh than Activity, which then caused some older API versions to be left out - and things quickly spun out of control. After hours of "maven gradle settings" and "Support Library" stuff and many pages of "AAPT2 errors" and messing up my whole system trying to fix that, I had to throw everything away and get a fresh clone from the repo. Fortunately I could also repair the other changes I had made to the system.)
How does one convert an old-style app menu to work on modern phones? It doesn't have to be fancy.
/** Setup menu */
#Override
public boolean onCreateOptionsMenu(Menu menu) {
MenuInflater inflater = getMenuInflater();
inflater.inflate(R.menu.main, menu);
return true;
}
/** Handle menu clicks */
#Override
public boolean onOptionsItemSelected(MenuItem item) {
// Handle item selection
switch (item.getItemId()) {
case R.id.action_about:
final SpannableString s =
new SpannableString(getApplicationContext().getText(R.string.about));
Linkify.addLinks(s, Linkify.ALL);
AlertDialog d = new AlertDialog.Builder(this)
.setIcon(android.R.drawable.ic_dialog_info)
.setTitle("About")
.setMessage(s)
//.setView(message)
.show();
((TextView)d.findViewById(android.R.id.message)).setMovementMethod(LinkMovementMethod.getInstance());
return true;
default:
new AlertDialog.Builder(this)
.setIcon(android.R.drawable.ic_dialog_info)
.setTitle("Currently not used.")
.show();
return super.onOptionsItemSelected(item);
}
}
I'll admit that I no longer understand all the details above from years ago.. it worked, so I never paid it much attention. It looks a bit wordy... probably there are simpler ways to do it.
This is menu/main.xml
<menu xmlns:android="http://schemas.android.com/apk/res/android" >
<item
android:id="#+id/action_settings"
android:orderInCategory="100"
android:title="#string/action_settings"/>
<item
android:id="#+id/action_about"
android:orderInCategory="3"
android:title="About"/>
<item
android:id="#+id/action_manual"
android:orderInCategory="4"
android:title="Manual"/>
</menu>
Maybe there is some "theme" to just add somewhere that makes the menu button show up somewhere on the screen, and that's that? (I know I am optimistic. :))
Everything looks fine.
I think your problem is because you are extending Activity.
change Activity to AppComatActivity.
and change your appThem to android:theme="#style/Theme.AppCompat.Light.DarkActionBar"
Note:
To use the AppCompatActivity, make sure you have the Google Support Library downloaded (you can check this in your Tools -> Android -> SDK manager). Then just include the gradle dependency in your app's gradle.build file:
compile 'com.android.support:appcompat-v7:27.0.2'
SOLUTION:
The only way to a solution that I could find was to create a completely new project with default settings in the latest Android Studio. This gives a "latest fashion" setup. Then I moved code in from the old project manually.
Everything now works perfectly!
ISSUES / REASONS:
As mentioned in the comment section above, every attempt I made to modernize the code resulted in a maze of problems. It was an old project, from way back when Android Studio was not even in Beta stage. Hence, it was based on Eclipse. The current Android version back then was Jelly Bean (Kitkat was just released).
In summary, we had an ancient project based on an older IDE. Perhaps it would be doable to convert a modern Eclipse project into Android Studio. Perhaps it would be doable to convert an older AS project into a modern one. However, performing both these major jumps at the same time was too great a challenge for me.
Another issue which has nothing to do with the old code, but which confused the matter greatly is that something called AAPT2 currently for whatever reason assumes american characters only in the search path to the .gradle directory. I use the word "assumes", because if the characters are anything else, you get pages of errors in the build log. None of the errors point very clearly to the reason.
AFAIK I don't even use AAPT2! After some sleepless nights, I solved it by changing the global setting in Android Studio to simply use another path.
While using Android Studio just now I was editing an XML file in the editor and I got this error in the Preview and Design windows:
Exception raised during rendering: Unable to find the layout for Action Bar.
I've tried restarting Android Studio, my Laptop and Googling for the answer but I can't find anything. Has anybody experienced anything similar?
I had this kind of error. On My Mac, there is API 22. If I choose it this error will appear. So clicking on API 21 or below would solve your problem
You probably need to update your tools
Those using Eclipse might try to choose Theme.DeviceDefault to eliminate the exception.
Update: as per comments this works for Android Studio also.
You can solve this problem by two ways
Change API from the tab, Try one of them from the available or Select PICK UP BEST or change your minimum sdk
Change the Theme if first solution not work
Click on Theme in Editor and change the theme:
MY issue is solved after this
I had this error on eclipse-3.8, adt-23.07, sdk-tools-23.1, appcompat_v7_r19.1.
After analyzing the error I found the problem is in
android-sdk-linux/platforms/android-23/data/layoutlib.jar:com/android/layoutlib/bridge/impl/Layout.class on method createActionBar at line if (this.mBuilder.isThemeAppCompat())
My solution:
(don't have the source, so) decompile Layout.class -> Layout.java
edit Layout.java, add method:
private boolean hasWindowDecorActionBar(SessionParams params) {
LayoutlibCallback callback = params.getLayoutlibCallback();
try {
callback.findClass("android.support.v7.app.WindowDecorActionBar");
} catch (ClassNotFoundException ei) {
try {
callback.findClass("android.support.v7.internal.app.WindowDecorActionBar");
} catch (ClassNotFoundException e) {
return false;
}
}
return true;
}
Locate the line if (this.mBuilder.isThemeAppCompat()) then change to :
if (this.mBuilder.isThemeAppCompat() && hasWindowDecorActionBar(params))
recompile Layout.java -> Layout.class and Layout$Builder.class
update layoutlib.jar with the new classes
restart eclipse
That's all. Now, I can render using API-23 all of my old app layouts that links against appcompat_v7_r19.1.
You suppose to do clean project.
i think it is a bug and there is no ultimate solution until this moment,
changing to API less than API-22 is a temp solution not more.
I´m experiencing a weird problem with SlidingMenu Library and ViewPager when they are running on devices with Android 3.2 (Honeycomb).
The problem appears when we "toggle" the SlidingMenu to show the Menu that is hidden on the left of the app. When we do this, both ContentView and BehingContentView stops responding to touch events.
Thinking that this was a problem related to my application, I downloaded the last version of ABS and SlidingMenu library and configured a new project using the built-in example that comes with the SlidingMenu and, for my surprise, the same behavior occurred with the ViewPager example.
These are the steps that I did:
Configure an Emulator using API Level 13 and 7" WSVGA (Tablet);
Download ABS and SlidingMenu from GIT;
Setup a new Project, using the compatibility library android-support-v41 (Also tested with android-support-v4);
Solved the problem 'getSupportActionBar() is undefined' as described here: https://github.com/jfeinstein10/SlidingMenu/issues/145;
Run the 'Example Application' and choose 'ViewPager' example;
Swipe pages to the right and to the left, without opening the menu;
Open the menu. See that the lists don´t scroll as expected;
Close the menu. See that the viewpager doesn´t responds to touch events anymore;
Notice that this behavior was reported only on Android 3.2 devices. We have the same application running on 2.x and on 4.x devices, without this problem.
Also, noticed that the Example Application that was downloaded from Google Play doesn´t have this problem.
Does anybody have any advice? Thanks a lot!
Edit 1
Tested on a real device, and confirmed the Behavior. Does anybody have an advice?
I had the same problem and fixed it by using the following work-around.
Replace these lines in SlidingMenu.java:
#TargetApi(Build.VERSION_CODES.HONEYCOMB)
public void manageLayers(float percentOpen) {
if (Build.VERSION.SDK_INT < 11) return;
with:
#TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
public void manageLayers(float percentOpen) {
if (Build.VERSION.SDK_INT < 14) return;
This is very, very strange. I've never seen anything like it. At the time I am took this screenshot, I'm not loading any overlays. First, I thought it was my internet connection where it couldn't download the tile information; but we have many users reporting the same issue who downloaded from the market. This just started happening like a week ago. Not sure why though. Anyone have a clue? Thanks!
Ok. After starting from a clean project I found these two lines of code that was the culprit.
mapView.setSatellite(true);
mapView.setStreetView(true);
They appeared back to back of each other and I looked back at the very beginning of development and they were there and it worked just fine. Apparently, this is a BUG in the MapView as I'm guessing it tries to show both SateliteView and StreetView at the same time. One would think that the latter would override the former; but I guess not.
So, the question I have is, why this all of the sudden surfaced just within the last week or so. My guess is that the Maps Application was last updated in the market on Sept 8th and maybe a day or so after updating from the market, this issue started to resurface.
As a test, can someone just add these two lines to their code and confirm you get the same behavior?
I had only setStreetView(true) and getting those annoying grey boxes. I played around with both lines with no luck. Solved it by removing both setStreeView and setSatellite from my code, goes to streetview by default.
I had the same problem with my app that uses google maps library... Because i have in my setting option where user can change view of the map to Satelite or Street, i dont use setStreetView(true) at all...just mapView.setSatelite(true or false)...
preferences = PreferenceManager.getDefaultSharedPreferences(this);
pogled = preferences.getString("list", "Street");
if(pogled.equalsIgnoreCase("Street")){
mapView.setSatellite(false);
//mapView.setStreetView(true);
}else if (pogled.equalsIgnoreCase("Satelite")) {
mapView.setSatellite(true);
}
As you can see i had mapView.setStreetView(true) but that gave me a headache... :D I hope this will help you...
I removed setStreetview(true) from my code and now its working fine i was saw this issue occured in last 2 weeks , nyway we finally solved the issue thats great
Street view is always considered as the default option.
The problem arises when we use both setStreetView(true) and setSatellite(true) at the same time. Problem will be solved like this
if(mapView.isSatellite()){
mapView.setSatellite(false);
}else{
mapView.setStreetView(false);
mapView.setSatellite(true);
}
I hope that will help
private void setUpMapTypeScreen() {
if (mapType.equalsIgnoreCase("Satellite")) {
mapView.setSatellite(true);
// mapView.setStreetView(false);
} else if (mapType.equalsIgnoreCase("StreetView")) {
mapView.setSatellite(false);
// mapView.setStreetView(true);
}
mapView.invalidate();
}
mapType is a user defined string variable. Not false the previous view type when switching to view types. that the error we made, only set the view type you required.
I had the same problem, I took out my mapController, and it fixed it. The only other thing I did different was put the mapview in a linearlayout with a textview (it used to just be a mapview only) and I played around with the mapcontroller, commenting it out.
Since those are the only two things I changed, I'm pretty sure your problem lies in there as well.
I was having the same problem and the common advice that I have got is to not use setStreeView(true) and setSatellite(true) together. Some have even suggested not to use setStreetView(true) altogether. But my code was working okay before. I had to reinstall my machine and therefore installed android SDK and other components afresh after which this started happening. So my guess is that this is an issue with some specific version But I have found out that this problem occurs specific revision of 2.2 - in my case Android SDK Platform 2.2, revision 3. I have tried running same code on 2.3 and it works correctly i.e no grey boxes.
Besides removing mapController.setStreetView(true), there is also another thing that should be added to the layout XML..
xmlns:android="http://schemas.android.com/apk/res/android"
<com.google.android.maps.MapView xmlns:android="http://schemas.android.com/apk/res/android"
android:id="#+id/mapa"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:apiKey="YOUR API KEY"
android:clickable="true"></com.google.android.maps.MapView>
Note the xml namespace after com.google.android.maps.MapView. After adding the namespace, the cross tiles disappeared. Don't know if it's a bug or the namespace is necessary in order for the api render the map correctly. Either way, it worked.
The following problem seems unique to 2.1, happens both on an emulator and on a nexus. The same example works fine on other platforms I've tested (1.5, 1.6 and 2.0 emulators).
I've added created gestureListener as described in this post.
The difference is that I've added the listener on a TextView which also has a contextMenu registered, i.e. sth like the following:
onCreate(...) {
...
// Layout contains a large TextView on which I want to add a context menu
tv = findViewById(R.id.text_view);
tv.registerForContextMenu(this);
// create the gestureListener according above mentioned post.
gestureListener = ...
// set the listener on the text-view
tv.setOnTouchListener(gestureListener);
...
}
When testing it, the correct gesture is recognized alright, but every other time it also causes the context menu to be opened.
As the same example is working on non 2.1 platforms, I've got a feeling it is not my code that is the problem...
Thankful for any suggestions.
Update:
Seems that the return value is flipped somewhere. If I let onFling() return the "wrong" value, i.e. true when the event is skipped and false when it was consumed, it works correctly in 2.1. But of course, that doesn't work on the other platforms. Seems like its time for an ugly workaround...
Thanks for the link steelbytes. I implemented the cancel-and-return-false solution in the last comment (Dec 27, 2010) but just for my onFling event and it appears to work on 1.6 as well as 2.x devices.