I am learning Android development but I am really getting confused by all the AppCompat stuff. I may be wrong, but AppCompat allows the use of modern elements like Material Design on older Android version (lower than API 21). That's cool, but for the purpose of my learning, I wanted to create a pure API 21+ application, without caring about retro compatibility.
So I could use the "native" android:Theme.Material instead of Theme.AppCompat.xxx. But when it come to Toolbar it seem that I can't use it without a AppCompatActivity...
It's really confusing for me, Google seems to release new components that are only compatible on API 21+ but you can't use them without using retro-compatible activities ??
If someone could clear things out a bit, I would greatly appreciate that.
But when it come to Toolbar it seem that I can't use it without a AppCompatActivity
Bear in mind that there are two Toolbar classes:
android.widget.Toolbar, which is available on Android 5.0+ (API Level 21+)
android.support.v7.widget.Toolbar, which requires appcompat-v7 and AppCompatActivity and all of that, but will work going back to API Level 14 (and, with older versions of appcompat-v7, back to API Level 7)
So, you choose the Toolbar implementation that matches your chosen environment.
Related
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!
I am creating a new application and will have to deal with ActionBar. I know that I have to extend the AppCompatActivity because the ActionBarActivity is deprecated, however I still do not understand why I have to use the support.v7.widget Toolbar rather than the android.widget Toolbar even though I am using the latest API ?
Thank you
EDIT1:
I understand now that the support.v7.widgets are there to enable devices with old APIs to comprehend what are the new functionalities added in the newer versions and mimic them in their own way. Is that correct ?
If that is correct and I do not want to have any sort of backwards compatibility does this mean I can move forward and use the android.widget Toolbar ?
Also using the android.widget Fragment unfortunately I can not add it to a ViewPager. Why is that ? Why does it force me to use an older version which has been extended to mimic the behaviour of the new implementation of the component ?
I think I just getting lost in all of those "support" libraries. Can someone briefly ( or not ) explain all that - why are there things in the support libraries that are not included or updated in the newer versions of the API ?
Thank you
First of all you are asking Good Question, Android will add advanced features continuously in different API levels but those features are available from which level of API they are added
For Example: Consider android fragment functionality was added in API level 11 that means it will work for API level 11 and above but your application need for API level 10 devices also at that time it wont be work. For this reason android develop support library for cover a wide range of Android devices (support for low level API) to work those functionality.
Android always recommend developers to use support library for development for more information check here
Support.V7.widgets and widgets.android both are different libraries.
support.v7.widgets uses design library.
toolbar actually not an actionbar we are manually implementing a
ActionBar with support library.
And there are lot more new inbuilt properties are included like observableScrollActivity and More material designs...,
Why we aren't using default actionbar?
Because ActionBarActivity is depricated. Comparing old actionbar with our latest sdk actionbar it gives good look.
.setSupportActionBar(toolbar);
After Setting support to the toolbar gives actionbar properties to the toolbar like we can hide it by getSupportActionBar().hide();
I understand that it is considered good practice to program for Android using the AppCompat support libraries for backwards compatibility. However, for this specific project, the minimum API level I am to support is Android 5.0 (level 22).
However all information I can find for new Lollipop features always points towards the AppCompat support libraries. Must I do this, or are there vanilla equivalents that do not require AppCompat themes, classes or attention to backwards compatibility (ie. a plain CoordinatorLayout in layout XML instead of android.support.design.widget.CoordinatorLayout)?
First, Andorid 5.0 is API 21. If you set the min SDK to 21, most features like material design theme comes by default, you don't need any libraries. But I think the CoordinatorLayout is only in the com.android.support:design library, you have to include the library to use it.
You will need to use various support libs for certain functionality.
The CoordinatorLayout exists in the design library, and not in the OS framework.
This can actually be quite useful. Use of the design library means you can use these components independently from the OS version of the user's device. Meaning you can get updated functionality without the user updating their OS.
And won't experience breaking API differences depending on what OS the user runs.
When I created a new app, I got this
class NewApplicationActivity extends ActionBarActivity{... }
So I have read that, if you want to use a new feature from a newer API level, you better make it such that there is an alternative option for the App to combat any situation for the minSDKVersion that you plan to support.
Assuming this is true, lets say I decide to build my App against targetSDKVersion = 21(which I did in the above example), I would get the base Activity class as ActionBarActivity. Now this is from support library and works for older version(down to Android 2.1 I guess..).
The thing is, I am stuck with these alternative set of support libraries rather than platform libraries. Am I gonna miss something significant if this happens? Will I get a chance to incorporate the platform specific code from API 21 into my App ever? The majority of Apps are made with compatibility in mind. How do you people handle this?
Support Libraries such as AppCompat (which is what ActionBarActivity and its replacement AppCompatActivity are part of) are designed to reflect the latest platform changes and backport as much as possible. Thereby by using AppCompat, you are already using a large number of API 21 features (such as material theme).
Of course, there is nothing stopping you including any API from any level in your application: just make sure that they are guarded by the appropriate API level checks: this is exactly what many of the Compat classes in Support v4 such as NotificationCompat and ViewCompat do for you.
I'm a new Android developer who is trying to find the best balance for API level support. I think my indecision stems from a lack of understanding of the benefits and disadvantages of using the AppCompat Library over newer Android features such as Holo themes and the action bar.
Of course, I know that Holo is unavailable before API Level 14 and the Action Bar is unavailable before API Level 11. If I want to make my apps available to the broader Android userbase, I will need to lower my minSdkVersion and use the AppCompat Library.
My question is, are there any significant recent features of the Android OS that just aren't supported or are unable to be implemented through the AppCompat Library? Adding on to that, if you set your minSdkVersion to say API Level 7 and build your app with support for AppCompat (say, with your app themes being Theme.AppCompat.Light), will devices running an API greater than 11 or 14 for example use default Holo or action bar features or be restricted to AppCompat? I'd like to know if supporting older APIs will disadvantage users with newer and more capable devices.
Anyway, regardless of the outcome, I'll probably still go for supporting say API 7-8. This is more of a curiosity question on my part. I hope it makes sense!
Thanks, Klep
AppCompat should add functionality of the latest API to older APIs when needed. For instance, lollipop added the CardView class, which can be used in older Android APIs when AppCompat is used, with some minor differences (some of the Android L animations may not apply on older versions of Android for example). It is recommended to use AppCompat in most cases, since more users will be able to run your app when you do (depending on your MinSdkVersion). If you want to know what classes you can access in AppCompat, you can take a look at the features here.
Regarding the Styles: through Platform.AppCompat style the Theme.Appcompat inherits, and then overrides some properties, from Holo (11+) or Material (21+) if these are native on the running device.