Does the android:clipChildren still works?
I have a AbsoluteLayout with a size and set the clipChildren to false. When I add childeren that are bigger then the AbsoluteLayout the childeren are still clipped.
Anyone got this working?
Working with Android 2.2 (API level 8)
Update 20-01-11:
I can make something similiar with a RelativeLayout, but does the android:clipChildren work on that?
btw, it's not needed that my application needs to work on any other platform then Android 2.2.
Absolute layout is deprecated. I suggest using something different.
This class is deprecated. Use
FrameLayout, RelativeLayout or a
custom layout instead.
http://developer.android.com/reference/android/widget/AbsoluteLayout.html
Edit: Answering to your comment:
Being deprecated means that for some reason, they stopped developing it. Maybe there's a better replacement, maybe they don't like the way it works. Anyway, they may drop this layout in future versions (which means your app won't be able to run in a future version of android).
Alternatives:
Frame Layout:
FrameLayout is designed to block out
an area on the screen to display a
single item. You can add multiple
children to a FrameLayout, but all
children are pegged to the top left of
the screen. Children are drawn in a
stack, with the most recently added
child on top. The size of the frame
layout is the size of its largest
child (plus padding), visible or not
(if the FrameLayout's parent permits).
Views that are GONE are used for
sizing only if
setConsiderGoneChildrenWhenMeasuring()
is set to true.
http://developer.android.com/reference/android/widget/FrameLayout.html
Relative Layout
You can also use a relative layout. Align every view by it's parent and set left and top margins as you wish. This may be your best option IMO. I've done this before and it worked reasonably well.
As Pedro said, this feature may have been an addition that came after AbsoluteLayout's deprecation, so if it's not implemented already, it will never work.
As far as the comment "which means your app won't be able to run in a future version of android", Google has promised that this will NEVER be the case.
Dianne Hackborn
On Mon, May 4, 2009 at 10:00 AM,
Sundog wrote:
I have a highly rated app that simply... could... not... be...
written... without AbsoluteLayout, no matter whose Java sensibilities
it steps on. I guess Android's doing so well with apps that it can
afford to shut down an entire category of games.
Did AbsoluteLayout disappear from 1.5?
No. Are you unable to write 1.5 apps
using it? No. Have we ever said we
have any plan to completely remove it
at any point in the future? No. You
need to find better reasons to be a
victim. If you can't find one, let
us know the name of your app and we
can make sure to break it in the next
release. Then you can -really-
complain!
-- Dianne HackbornAndroid framework engineerhack...#android.com
and later:
I'll say again: we are not going to
remove AbsoluteLayout from a future
release, but we strongly discourage
people from using it.
I'd say it's a safe bet to say it won't be removed, but it also won't get new features/fixes either.
Related
I have had feedback from Pixel 3/4 users that the bottom of the screen on this app is cut off, obscuring buttons and possibly other controls that the user requires.
This has only started happening on Android 10. The app contains both Xamarin.Android axml and Xamarin.Forms xaml layouts for the views (the particular page that you are viewing below is Xamarin.Forms).
I don't want to set margins, paddings, gravity or such like on the entire app as obviously that would impact non Android 10/Pixel users. I don't really want to check the operating system version and programatically change those properties as that seems quite hacky and will quickly become unmanageable.
I've looked for something similar to a UseSafeArea property for navigation bars rather than notches but there doesn't seem to be any. Is using WindowInsets the only way to this or has someone else had/solved this issue?
How it looks (controls at bottom are obscured):
How it should look (and does on every other device, the data is different here but it's the view that matters):
I had a similar issue which I solved by removing a few lines of code that were there to fix a bug that has since been fixed in Xamarin Forms.
It directly relates to this forum topic: https://forums.xamarin.com/discussion/87176/windowsoftinputmode-doesnt-work-in-xamarin-forms-android
If these lines exist in your MainActivity.cs, try removing them and see if that works:
Window.SetSoftInputMode(Android.Views.SoftInput.AdjustResize);
Window.SetSoftInputMode(SoftInput.StateHidden);
AndroidBug5497WorkaroundForXamarinAndroid.assistActivity(this);
I totally understand the advantage of having ConstraintLayout when flatenning nested UI's. But with the introduction of ConstraintLayout I see people adopting it instead of RelativeLayout even for simple layouts with a flat structure.
Does ConstraintLayout always performs better than RelativeLayout?
Specifically in the case when a view can be achieved with single flat
structure with no nested UI?
If yes, shouldn't Relative Layout be deprecated?
Any help would be much appreciated :)
I think that should be a matter of choice and customs. Some UI designers prefer RelativeLayout where others prefer ConstraintLayout. The ConstraintLayout can be used in many cases more than the RelativeLayout. And yes it performs better than the RelativeLayout but I think for just a single flat structure I can opt for RelativeLayout too though due to support tooling provided by the ConstraintLayout it makes it a better option if you need that feature.
That's my point of view.
Yes, it performs better, ConstraintLayout has designed with performance optimization in mind. Also, it's very straightforward to use by just drag and drop things.
I really like Constraint layout to develop complex layout faster than any other one, but in my opinion, it's harder to make changes on it when you need, but is just my point of view
Q1 - Does ConstraintLayout always performs better than RelativeLayout
A1 - I saw a lot of questions and answers on StackOverflow about that subject and here is what I can say base on those threads and my personal experience with ConstraintLayout :
In most cases, if you are using ConstraintLayout properly it will work faster but , there is no guaranty that this is what you will get all the time.
From my personal experience with ConstraintLayout, it is working really fast and in all of my layouts (both simple and complicated in terms of UI) it works faster than RelativeLayout.
Q2 - shouldn't Relative Layout be deprecated
A2 - Why I believe that Relative Layout should not be deprecated.
I honestly don't see any valid reason for RelativeLayout to be deprecated, altho I am using ConstaintLayout I first started with RelativeLayout and now I see it as another tool to build my UI.
If it's not broken don't fix it:
Don't forget that there are a lot of developers around the globe, some prefer
RelativeLayout and some prefer ConstraintLayout, let's keep it this way is what I believe - don't take the option to choose from the developers, give them the option to choose what to use.
ConstraintLayout is not a better solution for building UI as a fact, its just my opinion.
I really think that its something that depends on the developer and his decisions, therefore - no layout is better than the other and no layout should be deprecated (as long as it works)
I have two switches next to each other in a LinearLayout.
The problem is that with API level 20 the switches take a lot of space:
With API level 23 (I don't know at which API level it changed and it doesn't matter here) the switches became more minimalistic:
With which layout (and how) can I achieve that in the first picture the second switch goes below the first one (so to speak in the second line), but only if there is not enough space to display the label properly?
I don't want to use third party libraries if possible.
I think you can't achieve this with standard layouts. But you can use FlexboxLayout.
I also advise you to use android.support.v7.widget.SwitchCompat instead of android.widget.Switch, so switch will look like the same (material style) on different versions of android.
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!
Does it (and in what way) effect performance to have a complex Layout hierarchy?
In what way does it affect an application to have deeply nested layouts (e.g. RealitiveLayout which contains many LinearLayouts which each contain....)
It has an effect, the simpler the better is the rule.
Every view — or worse, every layout manager — that you add to your
application comes at a cost: initialization, layout and drawing become
slower. The layout pass can be especially expensive when you nest
several LinearLayout that use the weight parameter, which requires the
child to be measured twice.
From: http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html
You can use hierarchyviewer to gauge the performance of your layout hierarchy. For more details see http://developer.android.com/guide/developing/debugging/debugging-ui.html
Yes it does and more than 3 levels are supposedly not recommended. That is one reason why the new GridLayout was created. Also the lint and hierarchyviewer tools in the SDK will help you optimizing your layouts.
However depending on your needs you might have to nest deeper. Just use the SDK tools and some devices with hands on testing to see if your performance bottlenecks are with the rendering. Most likely they are somewhere else in your code..
One of the main performance slogs with regards to views is not the rendering but inflating them from xml files..