Develop Reference

why the upper part of recyclerview item is erased?

the upper part of recyclerview item is erased in some phones and is normal in other phones as the images below.
the first image is normal which from samsung phone (android 12 )
the second image has the problem which from huawi phone (android 8)
this is the code
<androidx.cardview.widget.CardView
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="70dp"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:foreground="?android:attr/selectableItemBackground"
android:clickable="true"
android:layout_margin="5dp">
<androidx.constraintlayout.widget.ConstraintLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_gravity="center"
android:layout_margin="5dp">
<com.makeramen.roundedimageview.RoundedImageView
android:id="#+id/itemImage"
android:layout_width="40dp"
android:layout_height="40dp"
android:scaleType="centerCrop"
android:src="#drawable/ic_launcher_background"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent"
app:riv_oval="true"
/>
<View
android:layout_width="1dp"
android:layout_height="1dp"
android:id="#+id/viewSupporter2"
app:layout_constraintBottom_toBottomOf="#id/itemImage"
app:layout_constraintEnd_toEndOf="#id/itemImage"
app:layout_constraintStart_toStartOf="#id/itemImage"
app:layout_constraintTop_toTopOf="#id/itemImage"
/>
<TextView
android:id="#+id/diseasename"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_marginStart="10dp"
android:text="disease name"
android:textAppearance="?android:attr/textAppearanceMedium"
android:textColor="#color/black"
app:layout_constraintBottom_toTopOf="#id/viewSupporter2"
app:layout_constraintStart_toEndOf="#id/itemImage"
/>
<TextView
android:id="#+id/diseasenickname"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_marginStart="10dp"
android:text= "disease nickname"
android:textColor="#color/teal_700"
app:layout_constraintTop_toBottomOf="#id/viewSupporter2"
app:layout_constraintStart_toEndOf="#id/itemImage"
tools:ignore="NotSibling" />
</androidx.constraintlayout.widget.ConstraintLayout>
</androidx.cardview.widget.CardView>

You're doing a basic mistake of having your cards at fixed height of 70dp. Change them to be wrap_content and tweak margins/paddings of your layout instead to achieve the size you need.
While it looks ok on device you designed it for you can see it cannot fit TextViews on the other one so they ends up being clipped (on top). Actually you can even break it on your Samsung if you go into device settings and increase font size.
You have to let your card view "grow" in those cases so unrestraining height it is the way to go. Although you might consider adding maxlines to your textviews so they don't get too out of hand with maximum font size.

The problem here is your second device is set to a larger system font size than the first one. The dp system is designed so that things look consistent on different devices, and you can see that the ImageView takes up pretty much the same amount of space on both - the space around it is the same, the layout looks the same.
But you have to account for the user changing their overall text size, which is what's happening on your second image. See how the text is just bigger? Not just in your list items - the diseases text is taller than the hamburger icon on this one, the tab headers are much closer together because the words are wider...
You have three options in this case
use dp instead of sp for the text sizes (so they're consistent and don't scale to the user's preference)
make sure your fixed layout has enough space for those larger text sizes
make sure it can expand as necessary to fit them
The first option is ok sometimes, when you have text that's already large enough for everyone, and you want to maintain some kind of visual consistency (like a fixed design where things are a certain size etc). Don't do this as a way to get around the limitations of having to provide accessible content, that scales so the user can read it.
The flexible layout approach is what Pawel's suggesting - basically design your layout so it can grow if necessary. You can use the minWidth and minHeight layout attributes for this (and layout_constraintHeight_min in ConstraintLayout) to design how you want it to look, but use things like wrap_content and constraints to allow it to grow beyond that if necessary. That way you get it looking how you like, but if the user needs bigger text, it compromises.
And don't worry if you don't like how it looks with large text - that's not important! What's important is that the user can read it, and everything's visible and accessible. Nothing cut off, nothing overlapping anything, everything clickable etc. The user is the one making the compromise between style and practicality, and they probably don't have a choice, so just making it usable in that situation is the main thing.
The middle option is the fixed layout that has enough space for the larger text settings. This is actually what's recommended in the Material Design spec - I can't link directly to the Two line version, but go here and scroll down - there are some similar to what you're doing:
Those measurements are all in dp - notice that the top line's position is defined by where its baseline is, the line the text "rests" on, relative to the top of the layout. You can do that with:
android:layout_height="wrap_content"
app:firstBaselineToTopHeight="32dp"
app:layout_constraintTop_toTopOf="parent"
And then the text below has its baseline relative to the bottom of the first
app:layout_constraintBaseline_toBaselineOf="#id/firstTextView"
app:layout_marginBaseline="20dp"
or you could constrain it to the top of the layout like the first one, with a value of 32 + 20dp.
Notice that this design leaves space for the text to grow vertically (up from the baseline, which is in a fixed position). If you use the Material Design type scale (which is a bunch of standard text styles and font sizes with names like Subtitle and Body1) then those list item specs should have enough room to hold the text even at the larger font settings. Both lines in that image can pretty much double in height and still fit
The nice thing about these specs is someone's done the work coming up with a design for you! And they're working with fixed sizes, so you get a nice consistent look to your lists

Android Layout Difference Between Different API Levels

My question revolves around the general problem represented by a specific example.
When I create a button with the following markup:
<Button
android:id="#+id/btnLookup"
style="?android:attr/buttonStyleSmall"
android:layout_height="match_parent"
android:layout_width="40dp"
android:layout_weight="1"
android:enabled="false"
android:text="#string/go_button"
android:textColor="#color/black" />
And deploy the app to an API Level 10 device, the height of the button is considerably less than the height of the same button when deployed to an API Level 17 device - that is, the smaller button does not fill the height of the other items in it's horizontally aligned liner layout whereas the larger version does.
This may have to do with fill_parent vs match_parent, I'm not sure.
The problem I'm having with this is how to define a layout that makes fundamental properties like this the same across devices.
If the answer is, you don't - you use multiple layout files then my next question is what resources do people use to iron this stuff out? For example, is there a list somewhere of the differences between api levels so that someone could consult it, our do others just suss these things out through trial and error?

The difference in rendering of a layout from one device to another should not be related to the version of Android running on the device. The difference, however, can be(and mostly is) due to different screen densities and dimensions.
This problem is (to some extent) nullified by using dp(density pixel) instead of px(pixel) while dimensioning views. You can further reduce the oddities by using different dimens.xml for different screen densities. This way, you will have a dimens.xml inside values-mdpi, another one inside values-hdpi, and yet another in values-xhdpi.
I prefer another approach. I like to handle positioning of items using the screen dimensions. I get the screen width and height at runtime, and programmatically add margins and padding to layout items.
// Get screen dimensions
// Add a ViewTreeObserver.OnGlobalLayoutListener() to the view
// Update height and width for items
// Position items using screenWidth and screenHeight
This, kind of, fool-proofs the rendering. Not sure if this approach fails in some case.
Edit:
You can read through 'Providing Resources' to know about the criteria that android uses to decide on the best possible resource for a given device/situation.

Android sp vs dp texts - what would adjust the 'scale' and what is the philosophy of support

So we know from many other posts that we should use sp rather than dp for text in Android, and we know the reason for this is to respect a 'user's preferences'.
But precisely what are these preferences?
How might a user change this setting?
I cannot find any reference through the settings on my phone (I would have expected something in 'Accessibility' or 'Display'). So what is a user setting? Is it only done through the likes of an app such as 'Big Font'?
Assuming that it is (set by something like big font) - I have played with Google Docs and some other Google apps with the font set to 130%. While most layout stays fine, some gets a bit cut off and can't be read (and that is on a big screened SGS2). So, what is the approach to developing apps with text sizes using 'sp'? Do we make sure it works on 100% scaling and then ignore other settings - call it a special case that the user can worry about, or do we go out of our way to make sure things expand or are scrollable, in case the text overflows?
One argument is that we should use 'dp' to guarantee a user has a chance of seeing the text (even if they have to use a magnifying glass)
Thoughts/comments?

It is exposed in the settings menu on some Android devices (manufacturer dependent). It may also be altered by some accessibility options (device-dependent).
In general, you should always used scale-independent pixels, especially for a large body of text.
However if your text has to fit into a bounding-box of known size then you should use density independent pixels in order to ensure that the text always fits properly and that all characters are visible regardless of the users' setting.
In a nutshell: would increasing the text-size by around 5sp result in the text being unreadable or mangle your UI? If so use density-independent pixels. If not, use scale-independent pixels. However you should generally aim to use scale-independent pixels wherever possible, which means designing a UI that can accommodate different text sizes.

Using the sp unit is recommended for text because in ICS and above (could be Honeycomb too, correct me if I'm wrong), there is a preference for a user's font size. So, if you're using Gingerbread or lower, you won't be able to find this setting.
The preference is under Settings, Display, Font Size. There's also an option under Settings, Accessibility, Large text, too.
To address your question about how to go about using sp, note that by default, without changing any of the font size preferences, 1sp is equivalent to 1dp (also, they are equivalent before the preference was introduced). Like you've noted, designing for the case where a user has huge text would probably require you to assume things are going to need to scroll where you might otherwise not expect them to.

The answer lies in looking at this particular issue holistically.
The motivation for using "sp" for font sizes lies in giving the developer power to control their layout in the face of user changing the font size on their device.
Example:
Lets look at 2 extreme cases:
1) User selects font size "small"
This is what my layout looks like:
http://postimg.org/image/kiyqeo2bh/
Here is the layout xml:
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:paddingBottom="16dp"
android:paddingLeft="16dp"
android:paddingRight="16dp"
android:paddingTop="16dp"
tools:context=".MainActivity"
android:orientation="vertical">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_row="0"
android:layout_column="0"
android:text="Material-Design ist die Scheiße"
android:textSize="18sp"
android:background="#ffff0000" />
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_row="0"
android:layout_column="0"
android:text="Material-Design ist die Scheiße"
android:textSize="25sp"
android:background="#ffff0000" />
2) If the user selects font size "huge":
This i what my layout looks like:
http://postimg.org/image/d7rax9wob/
My layout xml is same as above in case 1).
So, as you can see what happened here is the top TextView has sort of perfect font-size in sp because it does not wrap for the entirety of the range of font sizes (small to huge). But the bottom TextView completely messes up your layout/design in case 2).
So you as a developer can iterate and decide what size in sp works for your design and android will draw it for you.

Android: custom views with proportional widths and same heights

I try to implement a good reusable color picker for my Sketcher application. Instructions and screenshots are here: http://bit.ly/sketcherapp
The problem is I'm stuck with a good "resizable" UI which enable me to support wide range of devices with different screen sizes.
The top two widgets should be the same height and have proportional widths: 80 to 20. Also it would be nice to specify paddings in XML.
Current implementation is not good. I hardcoded some values into code and also it looks bad on Xoom devices because of inaccurate layout measurements.
Is there any way to implement this behavior? Ideally, I need some way to do it like with HTML tables (pseudocode):
table.width=100%, td1.width=80%, td2.padding=5px, ...
or something like that.
Current implementation:
code:
https://github.com/wargoth/Sketcher/tree/master/src/org/sketcher/colorpicker
layout:
https://github.com/wargoth/Sketcher/blob/master/res/layout/color_picker.xml
Thank you.

The top two widgets should be the same height and have proportional widths: 80 to 20.
Use a horizontal LinearLayout, android:layout_width="0dip" for both widgets, and android:layout_weight="80" and android:layout_weight="20", respectively.
Also it would be nice to specify paddings in XML.
Use android:paddingLeft and kin.

OK. I stopped boring with it and created dedicated layouts for each screen size.

Managing Android layouts, there must be a better way

I'm trying to sort the layout for one of my Android apps, but I'm finding layouts a nightmare.
Principally I have to have a portrait and landscape layout for normal, small and large screens. So thats 6 layouts to maintain to start with, let alone having to launch the app on three emulators each time because my UI widets don't load in the built in previewer.
I might be showing my ignorance as a fairly new developer, but there must be a better way!
Are there any tools out there to help with Android layouts?
Thanks

You dont need to have that many layouts. Design only as many as you need, and never use absolute values, aditionally try to make everything look nice using fill_parent and wrap_content for you layout_width & layout_height tags. Android does most of the work it self.
This article contains a lot of usefull info:
Supportng multiple screens

You may find this applicaiton helpful for designing your layouts:
http://www.droiddraw.org/
Also, if you don't specify a layout for each rotation, android will use one - infact it can use one for everything. If you use fixed values it makes it much harder. Try using fill_parent and wrap_content, you android will take care of scaling the view for each screen type and rotation too.
As a tip, don't forget to include:
<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="wrap_content">
above your relative or linear layout, and:
</ScrollView>
at the end - that way if the view doesn't fit on the screen (ie too much content) it will allow the user to scroll.

Eclipse's built in layout "editor" shows a reasonably good example of what a layout looks like. I would assume you're writing your application in Eclipse. If not, I highly recommend it. While not perfect, it's the best environment I've found.

you just need to master the proper use of RelativeLayout's and LinearLayout's. Almost all of my Layouts will start with a Relative and have Linear nested inside.
I generally don't use LinearLayouts without having either height or width set to 0 and using the weight attribute to make everything the same size.