Android 5.0 does not respect view's margins - android

I have an app that runs well in any version of android, but in Lollipop seems that all views don't respect any margin or padding.
Does anyone know why??
Thanks in advance.
I'm declaring the CardView like this:
<android.support.v7.widget.CardView xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:card_view="http://schemas.android.com/apk/res-auto"
android:id="#+id/card_view1"
android:background="#color/backgroundItem"
android:layout_width="match_parent"
android:layout_height="fill_parent"
android:layout_marginRight="2dp"
android:layout_marginLeft="2dp"
card_view:cardCornerRadius="0dp"
android:layout_weight="1">

Per the CardView documentation:
Note that, if you specify exact dimensions for the CardView, because of the shadows, its content area will be different between platforms before L and after L. By using api version specific resource values, you can avoid these changes. Alternatively, If you want CardView to add inner padding on platforms L and after as well, you can set setUseCompatPadding(boolean) to true.

Related

Android ConstraintLayout #dimens replaced with hardcoded values

Heyho mates,
currently I am learning the new layout editor of Android Studio with the new ConstraintLayout.
By the way, I hate it.
But I got the issue, that if I want to specify a layout_height with #dimen, it gets replaced with a dp value instead.
Someone else got this issue?
Android Studio version 2.2.2 & 2.2.3 same issue.
Newest gradle version.
Thanks in advance guys!
Edit :
Code example :
<?xml version="1.0" encoding="utf-8"?>
<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="wrap_content">
<android.support.constraint.ConstraintLayout
android:layout_width="match_parent"
android:layout_height="wrap_content">
<ImageView
android:layout_width="wrap_content"
android:layout_height="#dimen/imageViewHeight"
app:srcCompat="#drawable/accept"
android:id="#+id/imageView"
android:layout_marginStart="16dp"
app:layout_constraintLeft_toLeftOf="parent"
android:layout_marginLeft="16dp"
android:layout_marginTop="16dp"
app:layout_constraintTop_toTopOf="parent" />
</android.support.constraint.ConstraintLayout>
</ScrollView>
Also happens outside scrollview.
Turns out this is a bug and will be fixed in Android Studio 2.3.
I think the reason behind this is, that ConstraintLayout as a WYSIWYG layout is inevitably meant to be edited/manipulated in the visual editor only.
Therefore keeping references to dimens in your dimens.xml would mean that as soon as you change something, move some elements around, these would not be relevant anymore and are hence replaced with "actual current values".
Also as mentioned in the docs:
All margins offered by the tool are factors of 8dp to help your views align to Material Design's 8dp square grid recommendations.

Card view shadow is not showing

This is my card_view. I have mentioned card_view:cardElevation.
But still shadow is not showing.
I have searched many links. Everywhere they have mentioned to use card_view:cardElevation.
<android.support.v7.widget.CardView
android:id="#+id/card_view"
xmlns:card_view="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="wrap_content"
card_view:cardBackgroundColor="#color/white"
card_view:cardCornerRadius="4dp"
card_view:cardElevation="5dp"
card_view:cardUseCompatPadding="true"
app:cardPreventCornerOverlap="false">
</android.support.v7.widget.CardView>
Can you tell what I am missing here?
Read https://developer.android.com/training/material/lists-cards.html
To create a card with a shadow, use the card_view:cardElevation
attribute. CardView uses real elevation and dynamic shadows on Android
5.0 (API level 21) and above and falls back to a programmatic shadow implementation on earlier versions. For more information, see
Maintaining
Compatibility.
UPDATE
try adding margin to card if you want to see shadow
check https://developer.android.com/reference/android/support/v7/widget/CardView.html
Set the following attribute in your cardview
card_view:cardUseCompatPadding = "true"
card_view:cardElevation = "5dp"

Android ConstraintLayout generates absolute values

I have recently started learning the new ConstraintLayout in Android Studio 2.2 and noticed that when I add simplest of the views, the layout editor automatically generates some absolute coordinates. Here is a sample XML:
<android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:id="#+id/activity_portfolio"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context="com.abc.Activity"
tools:layout_editor_absoluteX="0dp"
tools:layout_editor_absoluteY="81dp">
<TextView
android:text="#string/creator_name"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
tools:layout_editor_absoluteX="246dp"
tools:layout_editor_absoluteY="479dp"
android:id="#+id/first_textview"
app:layout_constraintRight_toRightOf="#+id/activity"
android:layout_marginEnd="16dp"
tools:layout_constraintRight_creator="0"
app:layout_constraintBottom_toBottomOf="#+id/activity"
android:layout_marginBottom="16dp"
tools:layout_constraintBottom_creator="0" />
</android.support.constraint.ConstraintLayout>
Notice the absolutes like 81dp, 246dp, 479dp... I tried to manually delete these, but when I go back to the "Design" tab and come back to the "Text" tab, these regenerate. Now, I have three questions:
Is there a way to tell Android Studio to not generate these?
Should I manually place them in dimens.xml?
Would these absolutes cause some layout problems in other devices?
You'll note that all of the absolute values are in the tools namespace - this means they are not compiled into your app, nor used in anything but in the tools (and in this case, the visual editor). They are simply to ensure that switching from the Design to Text tab is always consistent, with the underlying files remaining stable.
Is there a way to tell Android Studio to not generate these?
No.
Should I manually place them in dimens.xml?
These are only useful for the tools and therefore should not be added to a separate dimens.xml file that would be included in your final APK.
Would these absolutes cause some layout problems in other devices?
No, they are only used by the tools.
I'm not sure your original question contains your entire layout, as it references a widget with an id of #+id/activity, so the issue might lie elsewhere in your layout.
Ensure that no widget that exists within a ConstraintLayout has a layout_width or layout_height of match_parent.
MATCH_PARENT is not supported for widgets contained in a ConstraintLayout, though similar behavior can be defined by using MATCH_CONSTRAINT with the corresponding left/right or top/bottom constraints being set to "parent".
Source
If you use match_parent, Android Studio will generate these absolute values, as well as replacing match_parent with an absolute dimension.
Based on the layout you posted, your TextView probably had a layout_width or layout_height of match_parent before Android Studio replaced it.
You should replace android:layout_width="match_parent" with
android:layout_width="0dp"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintEnd_toEndtOf="parent"
And android:layout_height="match_parent" with
android:layout_height="0dp"
app:layout_constraintTop_toTopOf="parent"
app:layout_constraintBottom_toBottomtOf="parent"
In your specific layout, you probably want something like this:
<android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:id="#+id/activity_portfolio"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context="com.abc.Activity">
<TextView
android:text="#string/creator_name"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:id="#+id/first_textview"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintBottom_toBottomOf="#+id/activity"
android:layout_marginEnd="16dp"
android:layout_marginBottom="16dp" />
</android.support.constraint.ConstraintLayout>
As a side notes to given answers, you can use the Magic Wand Icon in the toolbar menu above the design preview. Click on Infer Constraints button, this will automatically add some lines in the text field and the tools one will be converted to constrained.
Please see below picture :

Strange CardView behaviour

I'm trying to implement simple cardview with semi-transparent background.
<android.support.v7.widget.CardView
android:id="#+id/card_view"
app:cardBackgroundColor="#33FFFFFF"
app:cardCornerRadius="4dp"
android:foreground="#33FFFFFF"
android:padding="20dp"
android:layout_width="match_parent"
android:layout_height="100dp">
......
</android.support.v7.widget.CardView>
And this is the result in L and preL
android L: (Nexus 5)
Pre L:
Any idea how to fix the pre L to look like L ?
As you can see there are too many borders/strokes surrounding the card.
I'm can guess it relates to shadows and stuff...
Thanks.
Look like it's a known defect in google forums
Thanks to #benhylau for providing implementation for cardview with alpha here
There no possible to color cardview background with #__FFFFF as it ignores the transparency values. need to work with alpha attribute

Alternative to nested weights with LinearLayouts

I want to achieve the following:
It works with the following layout:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="horizontal">
<LinearLayout
android:layout_weight="3"
android:layout_width="0dp"
android:layout_height="fill_parent"
android:orientation="vertical" >
<fragment
android:name="com.bobjohn.DetailsMenuFragment"
android:id="#+id/detailsMenuFragment"
android:layout_width="fill_parent"
android:layout_height="0dp"
android:layout_weight="6"
/>
<fragment
android:name="com.bobjohn.SummaryFragment"
android:id="#+id/summaryFragment"
android:layout_width="fill_parent"
android:layout_height="0dp"
android:layout_margin="10dp"
android:layout_weight="4"/>
</LinearLayout>
<TextView
android:layout_width="0dp"
android:layout_weight="7"
android:layout_height="fill_parent"
android:text="Test Text"/>
</LinearLayout>
However, I get the warning about nested weights being bad for performance. I understand the error but I don't know how to express this layout in another way. What is the alternative?
There are NEW updates in SUPPORT Libs, Please check Accepted Answer too.
Updated Answer :-
Whenever you create any view, It calls it's measure events to know the height width of view on the screen, If you are not using WRAP_CONTENT or FILL_PARENT or FIXEDSIZE and using Weights then it's becoming more complex to render your layout on the screen.
Means,
First your main layout is rendered and calls it's measure..then based on weight all child views calls it's measure events recursively so it consumes more time to load.
So, One should avoid nesting of weights.
Alternative to Nested weights :-
You should consider using different layout and drawable folder specific to different sizes. Write your views in your XML with specific height-width OR make it wrap_content and use specific background images OR make it fill_parent.
I believe that as developer we may be wrong several time, but as creator Android (Lint) they may be wrong only in rare case, should listen to those warnings to make your code better.
BELOW ANSWER WAS WRITTEN WITH LACK OF KNOWLEDGE ABOUT ANDROID LAYOUT
AFAIK, I think you have done right, this is the best written XML for the same.
You have used the weight attribute perfectly as it should have been used. You just ignore the Warnings.
What is the alternative?
I have coded all my XML in the same way in my projects so This has been the best alternative to me,So I dont think there is any other alternative to CODE the XML to get Such layout until and unless you use RelativeLayout as parent layout with some fixed sizes height and width of the child views. Still I advice you keep it as it is.
I would have deleted this answer as I still don't completely know Android Layouts but keeping it to receive new comments and answer based on this
Yes we have the alternative for nested LinearLayout weight by android's percent support library
Code and concept HERE !
GitHub Project HERE !
Consider this simple layout where I have totally avoided weight property of LinearLayout
<android.support.percent.PercentRelativeLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="match_parent">
<TextView
android:id="#+id/fifty_huntv"
android:layout_width="0dp"
android:layout_height="0dp"
android:background="#ff7acfff"
android:text="20% - 50%"
android:textColor="#android:color/white"
app:layout_heightPercent="20%"
app:layout_widthPercent="50%" />
<TextView
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_toRightOf="#id/fifty_huntv"
android:background="#ffff5566"
android:text="80%-50%"
app:layout_heightPercent="80%"
app:layout_widthPercent="50%"
/>
</android.support.percent.PercentRelativeLayout>
Really awesome !!!
I think (and I will probably be flamed for this), but again I think my phone has a quad core processor to rival (if not utterly destroy) most peoples home PC's.
I also think this kind of hardware capability is the future of phones.
So I come to a conclusion, that as long as you are not getting carried away with nesting (in MHO a layout should never be more then 4 levels deep, and if it is you are probably doing it wrong), your phone could care less about having weights.
There are many things you can do that will have a much more far reaching effect on performance, then worrying about your processor doing some extra math.
(please note that I am being slightly humorous, and so not to take anything too seriously from this post, other then the idea that there are other things you should optimize first, and that worrying about a 2-3 level deep weight is not helping your health)

Categories

Resources