I did a materalistic designed "Add" button on my Android-primary react-native app. While I used elevation style property as a primary source for shadows in the rest of the elements, I've discovered that it stops working when applied to an absolute positioned element. (Which I partially understand probably because absolutely positioned element ignores the general layout rules, but still, a shadow should work).
As far as I know, Android gets elevation and iOS gets their respective shadow properties.
I'd like to have this:
but I 'm getting no shadow once I set the element's style as absolute (in the bottom right corner).
Am I missing something or is it not working yet?
Simply, there is no current shadow support for Android in React Native yet and I think you are on the right track to use elevation way to achieve this. But it should only work for Android 5.0 or above.
Alternatively, you can try this module (https://github.com/879479119/react-native-shadow). It works for me.
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've developed a super simple custom View in Android, to be used as a generic placeholder, that just shows a diagonal line between the upper-left vertex to the lower-right one.
The problem is that when I try to lay out it in a ConstraintLayout, the editor does not show the anchor point I would expect. An image is worth a thousand words:
If you're experienced with Android Studio you know that if I were using a standard View, like a Button, instead of mine custom View, the green arrow should normally hook to the grey "BUTTON", representing a vertical constraint.
Any idea why Android Studio does not behave as expected ?
It is an Android Studio bug or maybe my custom view misses something else like some callback method ?
It is worth to mention than if I manually edit the layout XML writing the proper contraints and then I reopen the view, it is shown correctly, with all the arrows representing contraints in place! Even the one that I was not able to draw in the first place.
Ok, the answer was quite easy. In order to properly work, it is mandatory to assign an android:id to all components. If some components involved in a ConstraintLayout do not have it, it is impossible for Android Studio to set such constraint. This is because a constraint has this kind of form:
app:layout_constraintTop_toBottomOf="<ID OF THE COMPONENT ATTACHED TO>"
So... in my case it was enough to ensure all components, be them custom or default ones, have an ID.
I have an app that uses Expo's GestureHandler.DrawerLayout with the "back" drawer style, such that the view rests atop a stationary drawer and slides off to reveal it. To emphasize this arrangement, I wanted to add a drop shadow to the content View, cast on the drawer content. So far, I have this working on iOS but not on Android.
To explore this in isolation from the rest of my app, I've forked the react-native-gesture-handler project and modified the horizontalDrawer example app. I've added style props for the shadow here:
https://github.com/kmagiera/react-native-gesture-handler/compare/2542bd39503412ef00883e0e799caf7d1f68ef3a...brettdh:shadows-broken-on-android
As you can see in this screenshot, the shadow appears on iOS, but not on Android. However, if I remove absolute positioning by commenting out this line, I see that the shadow is actually being clipped on the left, as you can see in this screenshot.
I've dug into the component tree a bit and tried:
moving the shadow props to a wrapper View
clearing overflow: hidden
(though now my understanding is that overflow: visible only works on iOS)
I've found discussions describing this as having something to do with absolute positioning, but even if that's the case, I don't think I can avoid that, as it's part of the DrawerLayout itself. Any thoughts as to how I can accomplish the same shadow effect on both iOS and Android?
Some further investigation indicates that DrawerLayout puts a View around my component that's (probably) clipping the shadow. If I put my elevation prop on that View instead (along with a backgroundColor), the shadow is no longer clipped.
This probably means that I need to make a PR to enable custom styles on this wrapper View.
I couldn't quite figure out how to achieve the shadow separator as with Lollipop os settings in my app's settings screen. Please see the screenshot below.
I know I can use a simple custom preference with a shadow drawable to get this look. But I wish to know if there is any built-in native way of doing this in android L and later.
Please help...
I was looking for the same and, as it turns out that this is just a matter of setting "elevation" of the Viewgroups above and below.
I set elevation as 5dp for both the top and bottom ViewGroups and provided a margin of 10dp between them to get similar results.
Ofcourse its available only from L onwards. But I see that its L settings screenshot that you have provided.
#Androbean Studio is right. Checkout the Settings source. It create ui by DashboardSummary#rebuildUI.There is a view named categoryView with its xml layout. You will find the elevation attr in the LinearLayout.
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!