This question already has an answer here:
Material Design, AppCompat, and Backwards Compatibility
(1 answer)
Closed 6 years ago.
I would like to use Material theme for my app and target from Jelly Bean to "M".
What's the correct recommendation ?
1. Use appcompat theme on api levels below 21 and use standard material them on 21 and above
2) Simply use appcompat on all the api levels.
Will I be missing anything if I simply use appcompat on all api levels ?
You would use only the AppCompat themes for all. For most stylings, they have their own implementations that mimic more modern approaches. For things that can't be mimicked, they just simply don't do it or move to the default (one that comes to mind is the Ripple effect. 21+ devices it will use Ripple, but on others it will default to the standard button selector). If they can use native approaches, then they will use those instead.
On some cases though, you may need to create styles that contain attributes which unique to a certain API level. In which case you need to create a layout-v## folder where ## is the API level to support. Then put in a Style with the same name as one in the lower layout folder. Android will choose the appropriate folder. The same can be done for any other resource folder.
Use AppCompat for everything, there is built in functionality to handle if you are using < 21 or >= 21.
Really the only time you should use the standard Material Theme is if your base API you support is 21+ but even then you will eventually use app compat for new things that get added
Related
So I'm creating an app that is Lollipop 5.0 API 21 and up with zero interest in supporting older devices. Do I still need the appcompat library when using Material Design like UI elements & layouting (sidebar aka nav bar, ink, etc) ? When stripping it down I often encounter crashes when trying to move away from the AppCompat stuff. Changing activity types from the AppCompat one to the Normal one, I end up with problems regarding dependencies on layout types like the coordinator layout that aren't there.
I'm still new to android and this is very confusing, as my theme is currently in limbo somewhere between the appcompat theme & material design when I tried to change it from one of the template.
I've read that this is an android studio issue because it always uses appcompat regardless of your set dependencies & minimum API levels. Forcing you to manually override every implicit hidden appcompat call.
When trying to dump AppCompat, what changes to I need to do to make that happen ? Manifest, Activities, Menus, Layout, Styles ? It seems to touch all these things. If going exclusive without Appcompat, do you still need the v21 folders or will it grab the default ones ?
Do I still need the appcompat library when using Material Design like UI elements & layouting (sidebar aka nav bar, ink, etc) ?
If you are using classes out of the Design Support library, such as NavigationView, you generally need to use appcompat-v7 and AppCompatActivity. As of early May 2016, Google has not shipped a Design Support library analogue that works with Theme.Material. You may be able to find third-party library replacements for some of those widgets, and seasoned Android developers can sometimes "cross-port" these components to eliminate the appcompat-v7 dependencies.
I've read that this is an android studio issue because it always uses appcompat regardless of your set dependencies & minimum API levels. Forcing you to manually override every implicit hidden appcompat call.
The only place that Android Studio really cares about appcompat-v7 is in the new-activity wizards, which you do not have to use.
When trying to dump AppCompat, what changes to I need to do to make that happen ? Manifest, Activities, Menus, Layout, Styles ?
That is difficult to answer in the abstract. You would need to:
Stop using Design Support library widgets and containers
Stop inheriting from AppCompatActivity
Change your app: attributes in your menu resources to their android: equivalents
Change your theme to not use Theme.AppCompat
If going exclusive without Appcompat, do you still need the v21 folders or will it grab the default ones ?
-v21 resource directories are not tied to appcompat-v7. They will still be used, on API Level 21+ devices.
I have been really confused on this. I want to be able to have a lot of people use my app, but as of this post, this seems difficult unless you set your minimum API down to 16-17 or so.
Even if I am setting my API to this level, is there any point to me using things like AppCompatActivity / the Support Library?
If I want to use a Material theme, do I either have to set minimum API to 21 or use AppCompat?
Are "ActionBars" still a thing, or are they deprecated? I'm trying to find something that will allow me to display the bar on all preference screens (including nested screens). I'm also trying to include icons in both the bar and the preference items.
So I am unsure what API I need to use / what libraries to use.
Your question is similar to this previously asked question
Should I use AppCompat v7 if minsdk is 14
AppCompat libraries allow you to provide features and capabilities that are in later releases of Android to earlier releases that dont have them in their SDK versions. Theme features and capabilities are part of this, but certainly not limited to that. Example that you already stated is the material design one. If you want widgets and views that are introduced in SDK 21+ supported in say API 15 (ICS) then you would use AppCompat 21+. However, features that are in AppCompat +7 (example AnimatedVectorDrawable) would not be needed since Api 15 would already support that.
So effectively it depends on the feature you want to support and the minimum SDK you are targeting.
Hope that helps!
Some material design are only supported starting from android 21 API , so for this purpose we need to provide alternative styles that will work on devices running earlier version . (like they say in documentation ) .
for example :
res/values/styles.xml
res/values-v21/styles.xml
They also have mentioned V7 support library that includes Material design styles .
From here I am little bit confused !
Suppose that my default theme extends from Theme.AppCompat .
Why Should I provide an alternative style for 21 api knowing that Theme.AppCompat is made for compatibility ?
You should do so to use functionalities from api 21 that does not previously exist.
For exemple, on api 21 and later you can make the statusbar translucent, and this is not done by default with the appcompat, because that's not the default behavior.
In a general sense, AppCompat back ports everything that you will generally need to worry about (with new features added all the time). AppCompat itself is doing that alternative style heavy lifting for you.
Start with AppCompat and only create an alternative style if you run in to a specific feature that you need (you probably won't).
If we want to support both Lollipop and pre-Lollipop devices for an app with Material design which among the following is the right method ?
Use Android Support Library alone: Use only support library for the whole app and don't use any of the API 21. I have tested this and it works in emulator. I could get the material features in a Lollipop device in emulator.
Use both API 21 and Android Support Library simultaneously in the App: Provide alternative styles, alternative layouts etc... one using API 21 and other one using Android Support Library as mentioned in Android's documentation.
My confusion is, if I am going with option 1, is it the right approach for Lollipop devices ? Will that be lesser memory efficient ?
Otherwise if I am going with option 2, will it be an overkill if that is not actually required ?
Also in 2nd option, for using Toolbar, we can have alternative layouts in two folders (layouts and layouts-v21) with layout in first folder using android.support.v7.widget.Toolbar and layout in second folder using Toolbar.
But to have it set as ActionBar it is sufficient for Lollipop to have the activity to inherit from Activity class. But pre-Lollipop will need to inherit from ActionBarActivity. So will we need to have two activity files too ?
Please point out if I have blurted out any blunders.
Some features are only available in v21 like riplle effect, so if you want to use ripple effect in your app than use both support library for back support and v21 for lollipop.
Use custom XML/Java for pre lollipop, for lollipop just add your animation/design in v21 folders
I am trying to support devices down to API level 9 by using the AppCompat library. I am trying to theme the ActionBar using the example theme from Google but it keeps telling me that any item named android:action* requires API level 11 (current min is 9). I am targeting 18. If I use the stuff directly from the example why is it breaking? And can anyone help me figure out how to theme the ActionBar using the AppCompat library from API level 9?
The android:action* items are only available with API 11 and above. In order to support different API levels, Android contains various values directories. If you look at your project's folder structure, you will most likely see directories for res/values and res/values-11 and perhaps a few other ones. As you might have guessed, the 11 stands for API 11, which means that themes that are only available in API 11 and above should be included here. The values directory is your base one.
Therefore, for your example, you need to split up the themes file into two different ones. The parts that contain android:action* should be in a themes file in the values-11 folder, and the other ones can stay in the base values folder. Android takes care of automatically choosing the proper theme.
You should really read this, especially the parts near the bottom about applying themes. It discusses how you can apply themes to different API levels.
The function you are trying to use is only available from API 11 up.
You won't be able to use in devices that have API level 9 like you wanted to.
requires API level 11 (current min is 9)
You can run the example in devices with Android 3.0 and up, but for that you will have to change your Manifest file minSdkVersion to at least 11.
<uses-sdk
android:minSdkVersion="11"
android:targetSdkVersion="18" />
Try to remove all the items with android:action* and leave only those with action* (without the android namespace).
This works for me but I got my style from this wonderful style generator for action bar: http://jgilfelt.github.io/android-actionbarstylegenerator/