Here is the layout image.
The code that's causing the issue is as follows
View parent = calculateButton.getRootView();
Parent.setBackgroundColor(appSettings.getInt("app_background",r.color.White);
It works fine once the qpp key is there. However, the default key, no matter what it is, causes the layout bug.
I'm testing on a Nexus 6
EDIT: I believe i have solved it by replacing the default value for my getInt with an actual integer value rather than R.color.COLOR
Not sure what the root cause is, but it seems that whenever I used a color picker to set the color of the layout, it caused this weird rendering issue. I removed the feature, because I couldn't get it to render properly when the color was changed while the app was running.
Related
I'm using android.support.constraint.ConstraintLayout to layout a simple card's content views.
I'm getting random changes in my XML, every time, when:
I switch to Android Studio's layout editor's Design tab
Or when I have a Preview pane turned on (in this case changes happens even more often during my changes).
Those random changes include:
Removal of my manually defined layout margins (eg. layout_marginEnd)
Changing values of my manually entered margin value
Adding tools:layout_editor_absoluteX values
Questions:
Anyone else experience this Android Studio's feature?
How to switch this "feature" off, so my layouts would not be destroyed?
Where to report this bug to Google or JetBrains?
Please take a look to this file diff, which was made automatically when switched to Design tab:
PS.: My Android Studio version is 2.2.3; I'm running it on macOS Sierra.
Update #1
As suggested, after making layout_height="match_parent", I get modifications less often, but still my XML gets messed-up, when I edit layout in Layout Design'er:
This time I wanted to set layout_marginTop through Design UI (selected line is what I wanted to add), but I also got those other unwanted changes:
layout_marginStart removed;
app:layout_constraintBottom_toBottomOf referenced IDs got a prefix of "+" sign, which means, those IDs are newly declared, so when I'll use Goto declaration functionality, I'll have to choose it from the list - not a desired behaviour.
tools:layout_editor_absoluteX gets added. I could ignore it, but still - not what I'd want to happen.
In my case removing the layout constraint and adding it again fixed the disappearing margins.
I'm on Android Studio 4.1.1.
I have been noticing the same issue with Android Studio 2.3, the code changed automatically every time I went from text view to design view on a recent project with ConstraintLayout. - I'm pretty sure it happens with RelativeLayout or whatever other layout you want to use as well.
I guess it is some type of auto code generation bug linked to the design view, I have not been able to find a way to turn it off yet.
I'm not sure this helps because I'm confident you've already realized it, but if you work almost completely in text view, the issue never happens.
I occasionally use design view to begin my layout but once I have something working, staying in text view personally seems to be faster for the development process.
As #JoeyJubb mentioned, using layout_height="match_parent" solves this problem. At least XML is not modified. Although, sometimes preview is generated incorrectly.
In my case upgrade to newest gradle dependecy helped:
com.android.support.constraint:constraint-layout:1.0.2
Also I started using 0dp instead of match_parent for layout_width
I have an app that has a minSdk of 15 and I'm working out all the bugs that came with the lollipop upgrade. Our software is very complex and it dynamically creates views using custom ViewGroups and then an array of elements that are explicitly sized and placed inside the group. I'm running into an issue where for example I'll have a ViewGroup and the first child object is a Button...this button is sized to fill the view (not clickable). The second child is a FrameLayout containing a single view. This single view is a video object. In all prior versions of Android this works just fine. The FrameLayout is layered over the button (that is acting as a background) and the video is inside the framelayout. You can interact with the video without any issues.
Something changed in lollipop - suddenly, even though the button is showing up as the 0 index element, it is laying OVER the rest of the children...so I cannot get to the video underneath. If I remove that button element, the video renders and plays just fine...I have no issues interacting with it.
I ran the app in UI Automator Viewer just to make sure I was really setting up the UI as I expected (keep in mind the entire view is dynamically rendered at runtime using image/video assets and xml config files).
I'm not able to share code since this is proprietary software, but I am working on a little test project to see if I can manually recreate the issue with static objects. Once I get that up and running I'll be sure to update this ticket. For now, here is a screenshot of the hierarchy:
https://goo.gl/photos/a8on9CJDnN66XYnV6
Notice the highlighted object, this is the custom ViewGroup, the children below it are what I am describing above.
Does anyone know of a change in Lollipop that would effect the ordering of things? I found earlier that if you have a disabled object but don't have a disabled state drawable assigned to that object it would become invisible, previous versions just used one of the other state drawables..okay that makes sense and it was very easy to fix, but this object is not invisible...so it must be something different.
Any direction would be greatly appreciated.
~A
UPDATE -- FIXED
With the help of #alanv and #BladeCoder I figured out this functionality was due to the new elevation feature of Material design. I was able to fix my particular issue by first checking what version of android the device was using, and if lollipop, I just add this new property to the button:
android:stateListAnimator="#null"
This prevents my explicit child hierarchy from being overridden by the OS.
Lollipop introduced elevation as a way to position the elements on the Z axis and cast shadows between them depending on their difference of elevation.
Enabled buttons have a default elevation of 2dp (and it increases when you press them). So, your button has a higher elevation than the FrameLayout (0dp by default) so it will be drawn on top of it.
Disabled buttons have an elevation of 0dp. That's why disabling the button solved your issue.
Using buttons as backgrounds looks like a bad idea (why not setting a custom Drawable background on your FrameLayout instead?) but if you really need that, you can disable the button like you did and, just to be sure, enforce its elevation to 0dp. Another workaround is to increase the elevation of the FrameLayout but then it may cast a big shadow under Lollipop if it has a background, and maybe that's not what you want.
Okay, UPDATE! I figured out how to fix the issue, although I'm still not sure (even after pouring over the diffs between several classes in grepcode) what changed in lollipop that is causing a change in how this works.
If the button is enabled...and you are placing it using something equivalent to AbsoluteLayout (We have our own ViewGroup we created called Explicit layout, but it does pretty much the same thing as AbsoluteLayout), it will always be on top of anything else in the stack that isn't also a button of some sort (at least that's what I'm finding...I didn't test through every possible widget).
Setting the button that is acting purely as a background image to enabled=false solves this issue. I know, it doesn't make sense that we use Buttons as background images, but our code uses it for dynamic element creation so there are many possible states and uses for each element.
Anyway, not sure if anyone else would even run into this issue, but just in case you do...here it is.
Thanks!
I'm developing a PhoneGap-based application and I googled much about how to make my webview adjust its height when virtual keyboard appears, or at least get height of the virtual keyboard. I found a lot of posts (including stackoverflow) which says that
android:windowSoftInputMode="adjustResize"
must be set in the manifest and I did that. I also found that for PhoneGap config.xml there's
<preference name="android-windowSoftInputMode" value="adjustResize"/>
setting and I pasted that too. I also tried combined value 'stateVisible|adjustResize' (not just 'adjustResize') for both parameters, but it seems to me that they both have NO EFFECT. I don't know, maybe I'm doing something wrong, but you can check the screenshots from the emulator (Android 4.0.3, but I also tried 4.1.2 and 4.2.2):
http://screencast.com/t/Mm0mw8c693 - keyboard visible
http://screencast.com/t/lZ2DomqeRR - keyboard hidden
On the screenshot I intentionally captured my manifest and config.xml settings, so you may see they're actually there.
I even recorded short video - http://screencast.com/t/xI9PMcMJxxx
As you may see, no any viewport resizing occur when keyboard shown / hidden.
I also checked window.innerHeight using console.log() and it stays same for both visible and hidden keyboard.
Please, give me some advice.
windowSoftInputMode="adjustResize" does not work if your app is in fullscreen mode (setting fullscreen to true in config.xml). It is Android's issue not Cordova. the issue CB-4404 was filed in Cordova bug tracker for months but recently it turns out that it is working as intended on Android bug tracker.
I solved the problem by setting fullscreen to false since it wasn't a problem for my app not to go fullscreen.
I found I needed to to 3 things to resolve this issue, and prevent the actionBar from hiding itself, from scrolling out of view when the soft keyboard was brought up.
1) In AndroidManifest.xml, in the activity in question, I needed the line:
android:windowSoftInputMode="adjustResize"
The original problem is that adjustPan was present in the line above. At first, just the change above fixed the problem.
The project I am on uses fragments. In the onCreateView method, a different fragment had the line:
getActivity().getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_ADJUST_PAN);
That line, unfortunately, overrode the adjustResize parameter in the Application manifest, and after that other fragment was displayed, the fragment that I fixed broke again. So, to fix the new break, I did 2 additional things.
2) I deleted the SOFT_INPUT_ADJUST_PAN line from the onCreateView method of that other fragment, because it did not need that line anyway.
3) In the onCreateView method of the fragment with which I am primarily concerned, I added the line:
getActivity().getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_ADJUST_RESIZE);
Actually, doing either of items 2 or 3 would solve the problem. I did both to be thorough.
either you can set this property in android.manifest explicitly to "adjustNothing" then you do not need to set "fullscreen" mode to false.
but you have to update it every time you update/add android platform.
When I flip through the pages of a ViewPager, the background of a LinearLayout keeps changing from the grey color set in the Theme to white, and it do that only when flipping through pages, only in portrait mode and only in ICS.
It's perfectly working in all previous versions of Android.
EDIT: It looks like it's caused by the tag android:ellipsize="marquee" in the layout xml file.
How can I avoid this issue?
I find this thread
Android Viewpager saving data and views
By using view_pager.setOffscreenPageLimit(4);, this problem is solved (however, you can still see the white background for the first run, but it will work after that). Adjust the integer parameter according to your use ;)
I recently updated my app, changing it's design a bit. Amongst other things, I styled buttons with custom drawables (well - not exactly custom, just taken from ICS release). Everything works well, except for one of the users.
Instead of:
He sees:
This is a Button, but I have also other controls styled with the same background drawable and the problems appears there (so, it's not limited to buttons).
There are two changed style properties that these controls have in common. One is, of course, a background drawable. The other is textAppearance:
<item name="android:textAppearance">?android:attr/textAppearanceMediumInverse</item>
I came to a conclusion, that this user is using some strange theme, which alters the default value of textAppearance* styles. But I have no idea what attribute may control this "text background color" (android:background does not work, checked this just in case). Or maybe I'm looking in the wrong place and this problem is not related to textAppearance?
EDIT:
The background image is a semi-transparent PNG file.
Android version 2.3.7, Motorola Milestone. That's all I got.
EDIT 2, Fixed:
OK, the problem was at the users side, it turned out he was using CyanogenMod7 with forced 16bit trasparency. After switching that option off, everything works.
OK, the problem was at the users side, it turned out he was using CyanogenMod7 with forced 16bit trasparency. After switching that option off, everything works.