Difference between Android Framework widgets and their AppCompat version - android

I have lately noticed that there are AppCompat versions of most View types in Android, for example ListView / ListViewCompat, Button / AppCompatButton etc.
For these more simple Views (not counting for example SwitchCompat), what are the difference between them and the Android Framework version? I have not found any documentation on this matter...
I'm interested in knowing the consequences of choosing either version and if there are any advantages in chosing one over the other.
Specifically:
Difference between ListView and ListViewCompat
Difference between Button / AppCompatButton
Difference between ImageView / AppCompatImageView
Difference between EditText / AppCompatEditText
Difference between TextView / AppCompatTextView
I changed from normal to AppCompat versions with the expectation that colors would be used from the theme and look the same on Lollipop and pre-lollipop, but it rather had the opposite effect on some views (such as ListView)

AppCompat provides consistent UI support for older versions of APIs back to API v7.
from Documentation
The full list of tint aware widgets available in appcompat
AppCompatAutoCompleteTextView
AppCompatButton
AppCompatCheckBox
AppCompatCheckedTextView
AppCompatEditText
AppCompatMultiAutoCompleteTextView
AppCompatRadioButton
AppCompatRatingBar
AppCompatSpinner
AppCompatTextView
ListViewCompat is subclass of ListView same others
edited:
why both class available in framework or How Android Support Library work?

If you use AppCompatActivity, then AppCompatImageView will automatically be used when you use ImageView in your layouts.
From the AppCompatImageView AppCompatEditText AppCompatButton
Button vs AppCompatButton
This will automatically be used when you use Button in your layouts
and the top-level activity / dialog is provided by appcompat. You
should only need to manually use this class when writing custom views.
ImageView vs AppCompatImageView
This will automatically be used when you use ImageView in your layouts
and the top-level activity / dialog is provided by appcompat. You
should only need to manually use this class when writing custom views.
EditText vs AppCompatEditText
This will automatically be used when you use EditText in your layouts
and the top-level activity / dialog is provided by appcompat. You
should only need to manually use this class when writing custom views.
and the same rule is also valid for other appcompat views

Related

Warning : Use SwitchCompat from AppCompat or SwitchMaterial from Material library

What is the difference between these 2 objects (SwitchCompat and SwitchMaterial)? I have tried them and visually they are identical.
By the way, why did they remove the Switch class? Do you know which UI element is supposed to replace it in the future?
The SwitchMaterial:
is provided by the Material Components Library
extends the SwitchCompat
uses Widget.MaterialComponents.CompoundButton.Switch as default style, using the colors defined in the Theme.MaterialComponents (like colorSecondary, colorSurface and colorOnSurface) and applying the Elevation Overlays in dark mode.
The SwitchCompat:
is provided by the androidx appcompat library
uses Widget.AppCompat.CompoundButton.Switch as default style
By the way, why did they remove the Switch class?
The Switch class is not removed. It is provided by the android framework like other widgets as Button,TextView.. and the appcompat and material components libraries provide an updated version of them (like AppCompatButton, MaterialButton...).
There is a different with these widgets.
Using an AppCompat theme there is the AppCompatViewInflater that automatically replaces all usages of core Android widgets inflated from layout files by the AppCompat extensions of those widgets (for example a Button is replaced by AppCompatButton).
Using the Theme.MaterialComponents there is the MaterialComponentsViewInflater that replaces some framework widgets with Material Components ones at inflation time, provided a Material Components theme is in use (for example a Button is replaced by MaterialButton).
It is NOT true for the SwitchMaterial and the SwitchCompat.The reason for that is due to the AppCompat SwitchCompat not actually extending from the framework Switch class.
https://developer.android.com/reference/androidx/appcompat/widget/SwitchCompat
Switch have a different look for older versions of Android. we use SwitchCompat to have consistent look for all Android versions.
SwitchCompat is a complete backport of the core Switch widget that
brings the visuals and the functionality of that widget to older
versions of the platform. Unlike other widgets in this package,
SwitchCompat is not automatically used in layouts that use the
element. Instead, you need to explicitly use
<androidx.appcompat.widget.SwitchCompat> and the matching attributes
in your layouts.
SwitchMaterial is inherited from SwitchCompat. it is a class that creates a Material Themed Switch.
The switch view operates differently depending on which version of Android you are using. This might cause an issue if your app is being run in older versions or newer versions. To solve this, instead we can use SwitchCompat which operates the same on all versions currently.
To adjust this, go to xml code, instead of switch
// change from "Switch"
<androidx.appcompat.widget.SwitchCompat
android:id="#+id/main_activity_sw_simulate"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_marginStart="10dp"
android:layout_marginTop="9dp"
android:fontFamily="#font/coda"
android:text="#string/switch_text"
android:textColor="#color/onyx"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent"
tools:ignore="TouchTargetSizeCheck" />
SwitchCompat
SwitchCompat is an extended version of CompoundButton. SwitchCompat is a version of the old Switch widget which on devices back to API v7. It does not make any attempt to use the platform provided widget on those devices which it is available normally.
SwitchMaterial
It's an extended version of SwitchCompat. It creates a Material Themed Switch. This class uses attributes from the Material Theme to style a Switch.Because SwitchCompat does not extend Switch, you must explicitly declare SwitchMaterial in your layout XML.

Why extends ImageView marked as error?

Android Studio marks as error this line:
public class ParallaxView extends ImageView
Here the error:
This custom view should extend android.support.v7.widget.AppCompatImageView instead less... (Ctrl+F1)
In order to support features such as tinting, the appcompat library will automatically load special appcompat replacements for the builtin widgets.
However, this does not work for your own custom views. Instead of extending the android.widget classes directly, you should instead extend one of the delegate classes in android.support.v7.widget.AppCompat.
It recommends me to extend AppCompatImageView but then my JUnit test don't pass because AppCompatImageView needs a mock Context with resources and Imageview doesn't need this.
Here the question to solve the other problem:
NullPointerException creating an AppCompatImageView with mock Context
Can I ignore this error and use ImageView? Any other solution?
Using AppCompat widgets allows you to have some material design (and other new) features on devices with pre-Lollipop versions of Android.
At this point AppCompatImageView only provides the support for background tint and vector drawables. If you don't use them, then extending the regular ImageView will be fine.
It's not really an error. The app builds successfully right? It's only Android Studio which marks it as error.
You can change this to warning by editing the 'Appcompat Custom Widgets' inspection settings.

As a library, should I move my extends to AppCompatTextView/ImageView instead Normal TextView/ImageView

I'm making library that extends from TextView and ImageView. Someone requested me to extend from AppCompatTextView and AppCompatImageView instead so that it would be backward compatible (to I don't know what version... can't find the info).
My library already being used by others. If I change my library to extends from AppCompatTextView and AppCompatImageView instead of from TextView and ImageView, will there be impact to my existing user in term or usage (e.g. they have to modify their code, xml attribute)... or performance (e.g. slower, memory)? Or it is pure gain, i.e. AppCompat version is the superset of the normal version, and AppCompat is more backward compatible?

Difference between an AppCompat view and a normal Android view

What is the difference between an AppCompat view component and a standard/default view component?
For example, the difference between an AppCompatEditText, and an EditText, or between an AppCompatButton and a Button.
Looking at the developer docs for android.support.v7.widget, the AppCompat view components are described as "tint aware", but is this the only difference, and what exactly does this do?
When you are using a Button or an EditText you are actually using AppCompatButton and AppCompatEditText. From the official documentation of the AppCompatEditText.
A tint aware EditText. This will automatically be used when you use EditText in your layouts. You should only need to manually use this class when writing custom views
What is the difference between an AppCompat view component and a
standard/default view component?
AppCompat View Component supports compatible features on older version of the platform.
the AppCompat view components are described as "tint aware", but is
this the only difference, and what exactly does this do?
Although most of the AppCompatView only difference is it allows dynamic tint and background tint. Tint aware is not the only difference, each AppCompatView has its own differences, for example.
AppCompatEditText vs EditText
Allows textAllCaps style attribute up to Gingerbread.
AppCompatSpinner vs Spinner
Setting the popup theme using popupTheme.
You can dig down each view difference in Android docs.
However, as Sid / Docs says, you don't have to specify this on your layouts since it will automatically converted to AppCompat views. But, if you want to create custom view, you should use AppCompat Views, or else this bug will happens.
well one of differences that i have noticed , in order to change the background of a normal Button , you have to modify the XML ( to NoActionBar..
android:theme="#style/Theme.AppCompat.Light.NoActionBar" to
android:theme="#style/Theme.MaterialComponents.DayNight.NoActionBar"
whatever all i want to say is it difficult to work with buttons than the AppCompat version ).
so the use of androidx.appcompat.widget.AppCompatButton is somehow considered good because you will avoid a lot of little problems using the androidx library.

Material design for subclass of EditText

In API 21, we can use colorAccent to change the color of widgets like EditText, RadioButton etc. But it doesn't apply to the subclasses of those widgets. I've tried this but it's just like colorAccent, it applies only to original widgets.
Is there any solution to this? other than having to create a custom drawable then implements it as a style..
For applying colorAccent just extend your custom EditText class from
android.support.v7.widget.AppCompatEditText
Actually as of Android support 22.1 you should subclass AppCompatEditText.
Since, you did not post any source code I'm guessing you're not inflating your view from an XML layout but rater calling new MyCustomEditText.
As the developers site stated: The material theme design can only be applied when loading views using a layout inflater.
This is because the new material design backport hooks into the layout inflation process.
Another reason could be do to the fact that the appcompat v7 library only loads the material design when it finds an EditText in the XML layout. And it does not recognize custom view components.
Google plans to release the Material backport widgets in to the public, they stated that these are currently still in development. You may want to override these special backport widgets it could possibly solve your problem. But since they are not public yet... you can't.

Categories

Resources