Android elevation without shadow

Elevation & shadows

In the physical world, objects can be stacked or affixed to one another, but cannot pass through each other. Objects also cast shadows and reflect light.

Material Design reflects these qualities to form a spatial model that is familiar to users and can be applied consistently across apps.

Elevation

Measured from the front of one surface to the front of another, an element’s elevation indicates the distance between surfaces and the depth of its shadow.

Resting elevation

All material elements have resting elevations. While components have consistent resting elevations across apps, they may have different resting elevations across platforms and devices.

Dynamic elevation offsets

Dynamic elevation offsets are the goal elevation that a component moves towards, relative to its resting state.

Elevation (Android) Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Elevation is the relative depth, or distance, between two surfaces along the z-axis.

Specifications:

• Elevation is measured in the same units as the x and y axes, typically in density-independent pixels (dp). Because material elements have depth (all material is 1dp thick), elevation is measured in distance from the top of one surface to the top of another.
• A child object’s elevation is relative to the parent object’s elevation.

The images and values shown are for Android apps.

Multiple elevation measurements for two objects

Resting elevation

All material objects, regardless of size, have a resting elevation, or default elevation that does not change. If an object changes elevation, it should return to its resting elevation as soon as possible.

Desktop resting elevation is 2dp below the listed values to accommodate mouse and non-touch environments.

Component elevations:

• Components maintain consistent resting elevations across apps. For example, the floating action button’s elevation does not vary from one app to another.
• Components may have different resting elevations across platforms and devices, depending on the depth of the environment. For instance, TV has a greater depth than desktop as it has a larger screen and is viewed from further away. Similarly, both TV and desktop have a greater depth than mobile.

Responsive elevation and dynamic elevation offsets

Some component types have responsive elevation, meaning they change elevation in response to user input (e.g., normal, focused, and pressed) or system events. These elevation changes are consistently implemented using dynamic elevation offsets.

Dynamic elevation offsets are the goal elevation that a component moves towards, relative to the component’s resting state. They ensure that elevation changes are consistent across actions and component types. For example, all components that lift on press have the same elevation change relative to their resting elevation.

Once the input event is completed or cancelled, the component will return to its resting elevation.

Avoiding elevation interference

Components with responsive elevations may encounter other components as they move between their resting elevations and dynamic elevation offsets. Because material cannot pass through other material, components avoid interfering with one another any number of ways, whether on a per-component basis or using the entire app layout.

On a component level, components can move or be removed before they cause interference. For example, a floating action button (FAB) can disappear or move off-screen before a user picks up a card, or it can move if a snackbar appears.

On the layout level, design your app layout to minimize opportunities for interference. For example, position the FAB to one side of a stream of cards so the FAB won’t interfere when a user tries to pick up one of cards.

Источник

Elevation & shadows

In the physical world, objects can be stacked or affixed to one another, but cannot pass through each other. Objects also cast shadows and reflect light.

Material Design reflects these qualities to form a spatial model that is familiar to users and can be applied consistently across apps.

Elevation

Measured from the front of one surface to the front of another, an element’s elevation indicates the distance between surfaces and the depth of its shadow.

Resting elevation

All material elements have resting elevations. While components have consistent resting elevations across apps, they may have different resting elevations across platforms and devices.

Dynamic elevation offsets

Dynamic elevation offsets are the goal elevation that a component moves towards, relative to its resting state.

Elevation (Android) Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Elevation is the relative depth, or distance, between two surfaces along the z-axis.

Specifications:

• Elevation is measured in the same units as the x and y axes, typically in density-independent pixels (dp). Because material elements have depth (all material is 1dp thick), elevation is measured in distance from the top of one surface to the top of another.
• A child object’s elevation is relative to the parent object’s elevation.

The images and values shown are for Android apps.

Multiple elevation measurements for two objects

Resting elevation

All material objects, regardless of size, have a resting elevation, or default elevation that does not change. If an object changes elevation, it should return to its resting elevation as soon as possible.

Desktop resting elevation is 2dp below the listed values to accommodate mouse and non-touch environments.

Component elevations:

• Components maintain consistent resting elevations across apps. For example, the floating action button’s elevation does not vary from one app to another.
• Components may have different resting elevations across platforms and devices, depending on the depth of the environment. For instance, TV has a greater depth than desktop as it has a larger screen and is viewed from further away. Similarly, both TV and desktop have a greater depth than mobile.

Responsive elevation and dynamic elevation offsets

Some component types have responsive elevation, meaning they change elevation in response to user input (e.g., normal, focused, and pressed) or system events. These elevation changes are consistently implemented using dynamic elevation offsets.

Dynamic elevation offsets are the goal elevation that a component moves towards, relative to the component’s resting state. They ensure that elevation changes are consistent across actions and component types. For example, all components that lift on press have the same elevation change relative to their resting elevation.

Once the input event is completed or cancelled, the component will return to its resting elevation.

Avoiding elevation interference

Components with responsive elevations may encounter other components as they move between their resting elevations and dynamic elevation offsets. Because material cannot pass through other material, components avoid interfering with one another any number of ways, whether on a per-component basis or using the entire app layout.

On a component level, components can move or be removed before they cause interference. For example, a floating action button (FAB) can disappear or move off-screen before a user picks up a card, or it can move if a snackbar appears.

On the layout level, design your app layout to minimize opportunities for interference. For example, position the FAB to one side of a stream of cards so the FAB won’t interfere when a user tries to pick up one of cards.

Источник

Android — elevation style property does not work without backgroundColor. #10411

Comments

niagr commented Oct 16, 2016

Issue Description

The elevation style property on Android does not work unless backgroundColor has been specified for the element.

With backgroundColor applied to instructions element:

Without backgroundColor applied:

Steps to Reproduce / Code Snippets

• Create a View
• Add elevation style property — notice it has no effect
• Add backgroundColor stype property — notice elevation is now applied

Expected Results

Unless I’m missing something elevation should get applied regardless of whether a view has a background color or not.

Additional Information

• React Native version: 0.33
• Platform(s) (iOS, Android, or both?): Android
• Operating System (macOS, Linux, or Windows?): Linux

The text was updated successfully, but these errors were encountered:

leeight commented Oct 20, 2016

leeight commented Oct 20, 2016 •

How about add a new style property such as outlineProvider (https://developer.android.com/reference/android/view/ViewOutlineProvider.html), just like what we did in Libraries/Components/View/ViewStylePropTypes.js

leeight commented Oct 21, 2016

Kishanjvaghela commented Apr 28, 2017

@niagr I have implemented CardView for react-native with elevation, that support android(All version) and iOS. Let me know is it help you or not. https://github.com/Kishanjvaghela/react-native-cardview

hramos commented Jul 20, 2017 •

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we’re automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

• Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
• If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
• Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

Источник

Как показать тень вокруг linearlayout в android?

Как я могу показать тень для моего линейного макета. Я хочу белый цвет округлый фон с тенью вокруг linearlayout. Я делал это до сих пор. Пожалуйста, помогите мне. Спасибо заранее.

и rounded_rect_shape.xml в каталоге xml

13 ответов

в Android нет такого атрибута, чтобы показать тень. Но возможные способы сделать это:

добавьте простой LinearLayout с серым цветом, над которым добавьте свой фактический макет, с полем внизу и справа, равным 1 или 2 dp

есть 9-патч изображение с тенью и установить его в качестве фона для вашего линейного макета

существует также другое решение проблемы путем реализации списка слоев, который будет выступать в качестве фона для LinearLayoout.

добавить background_with_shadow.xml-файл в res/drawable . Содержащий:

затем добавьте список слоев в качестве фона в LinearLayout.

Ну, это легко достичь .

просто построить GradientDrawable это происходит от Черного и переходит к прозрачному цвету, чем использовать родительские отношения, чтобы поместить вашу форму близко к представлению, которое вы хотите иметь тень, тогда вам просто нужно дать любые значения высоте или ширине .

вот пример, этот файл должен быть создан внутри res/drawable , Я называю это как shadow.xml :

поместите следующий код выше из LinearLayout , например, установите android:layout_width и android:layout_height to fill_parent и 2.3dp , вы будете иметь хороший эффект тени на LinearLayout .

Примечание 1: если вы увеличиваете android:layout_height будет показано больше тени .

примечание 2: использовать android:layout_above=»@+id/id_from_your_LinearLayout» атрибут если вы размещаете этот код внутри RelativeLayout, в противном случае игнорируйте его.

надеюсь, это поможет кто-то.

для леденца и выше вы можете использовать высота.

для более старых версий:

(toast_frame не работает на KitKat, тень была удалена из тостов)

Источник