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.
Related
I am developing an Android Project from scratch that has min 23 API level and uses AndroidX. When I complete the XML layouts (for ex. simple activity_layout) there is options to pick like between TextView & androidx.appcompat.widget.AppCompatTextView.
Is TextView targeting AndroidX?
If yes, can I ignore using androidx.appcompat.widget.AppCompatTextView or other AppCompat component if I target min 23 API level?
Is TextView targeting AndroidX?
The question in not clear but the class androidx.appcompat.widget.AppCompatTextView extends android.widget.TextView.
You can check the official doc.
A TextView which supports compatible features on older versions of the platform.
Also:
This will automatically be used when you use TextView 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.
Then.
If yes, can I ignore using androidx.appcompat.widget.AppCompatTextView or other AppCompat component if I target min 23 API level?
You can ignore this view if you are using the androidx.appcompat:appcompat:x.y.z library.
from the standard android documentation for AppCompatTextView:
This will automatically be used when you use TextView 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.
taken from here : https://developer.android.com/reference/android/support/v7/widget/AppCompatTextView , so yes, you can just use TextView as long as your activity extends AppCompatActivity
As pointed out by #Gabriele Mariotti (thank you to him) you should check out the documentation here https://developer.android.com/reference/kotlin/androidx/appcompat/widget/AppCompatTextView for more information regarding androidx AppCompatTextView documentation specifically.
The androidX documentation states the following regarding an AppCompatTextView:
This will automatically be used when you use TextView 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
an exact duplicate of the standard android documentation.
My initial answer only made use of this : https://developer.android.com/jetpack/androidx/releases/appcompat to check for any known limitations or history regarding androidx AppCompatTextView
I assumed that:
Like the Support Library, AndroidX ships separately from the Android
OS and provides backwards-compatibility across Android releases.
AndroidX fully replaces the Support Library by providing feature
parity and new libraries.
taken from https://developer.android.com/jetpack/androidx would be sufficient to make that assumption, +1 to him for the help :)
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?
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
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.
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.