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();
Related
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.
I'd like to add a sliding drawer to my app which is using the min sdk version of 16 and a target sdk of 21 and should allow it to use the most recent features of the platform.
I looked around on how to implement a sliding drawer, and all the articles I found talk about using some support APIs to do just that.
My app is not yet using these support APIs.
I wonder if implementing the sliding drawer is possible without any support APIs, and if so, if there is any resources showing just that.
DrawerLayout, the basis for Creating a Navigation Drawer is only found in the Android Support Library (along with many other Support Library only APIs). There is nothing in the Android framework that provides this same functionality.
To provide the most consistent experience to users, you should just use the Support Library.
You should consider using support APIs, but if you really dont want to, you can use user-created library.
Here's one I used for one of my projects:
https://github.com/mikepenz/MaterialDrawer
Yes, it is always possible. However, the DrawerLayout class is available only in support libraries.
When I first realized that, it made no sense to me. But now I see support libraries as an extension of the core libraries (android.*).
Anyway, I recommend using the support libraries or you will have to create the logic to do exactly the same from scratch.
You can use android design support library, it's working on all devices in android and it's open source so you can edit it as you like with custom element.
Here's a reference how to implement Navigation drawer using new android support library
I see the official documentation uses the support API in its documentation: http://developer.android.com/guide/topics/ui/actionbar.html
As a newbie in Android I have some questions.
Is is okay to aim for the API level higher than 11 devices only ?
In that case, can I still skip using the support API mentioned there ?
Is is okay to aim for the API level higher than 11 devices only ?
Yes.
I still skip using the support API mentioned there ?
I assume you are referring to appcompat-v7 for the action bar backport. You do not have to use this.
Some other libraries (e.g., Android Design Support library) presently require you to use appcompat-v7 for certain things. appcompat-v7 also gives you aspects of the Material Design aesthetic on older devices, in terms of the action bar and the tinting of some widgets for your brand's colors. If those features are of interest to you, you can certainly use appcompat-v7 if you wish.
Min version depends upon your target audience. From a development standpoint the newer API's have more features. You can see version statistics here.
At this points devices using API 11 are going to be pretty old and may not be your target audicance.
The newest design standards by Google is to use Material Design found in the appcompat-v7 support library
There are several other support libraries for backports of components
design For Floating Action Button & Snackbars
cardview for cardviews
recyclerview for efficient lists of items
Also of note the latest version of AppComapt 22.2.0 now uses Toolbar instead of ActionBar (you can set a toolbar to be used as an 1Actionbar`)
Update
If you want to use Material Design (recommended) but still support older version of Android here are some updates from the action bar guide you linked.
// Extend AppComaptActivity instead of Activity
public class MyActivity extends AppCompatActivity implements ConnectivityService.ConnectivityListener {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.my_activity);
// Set the toolbar defined in your layout as the ActionBar
setSupportActionBar((Toolbar) findViewById(R.id.toolbar));
}
One final difference is that your app theme should be (or extend) some variant that does not include an action bar (e.g Theme.AppCompat.Light.NoActionBar)
There are plenty of other guides on using AppCompat and Material Design, the linked ActionBar guide is correct if you are building a pre API 21 app without using AppComapt.
I understand that for Android below 3.0 i need to use ActionBar from v7 support lib
My question is how v7 ActionBar behaves on phones above Android 3.0. Does is use native ActionBar or v7 ActionBar?
I am asking if v7 ActionBar on phones with Android 3.0 and above will be of less quality
(may be less features) than regular ActionBar
Thanks
If you decide to use ActionBarCompat - all your devices will get action bar from compat library. Of course you can have some really tricky API version checks and choose one over another in runtime, but efforts and code complexity just don't worth it. I wouldn't say it is going to be "less quality" since Google guys are really trying hard to make it look the same. Also Im pretty sure list of interfaces is exactly the same as native implementation.
From another hand, there is obviously a risk to hit some nasty bug which is not present (or already fixed) in native implementation, so it is all up to you to take this risk to the benefit of supporting older platforms.
Considering Android Design Guidelines announcement what is the best way to make apps which are compliant with them on Android 2.x phones? E.g. what is the best way to implement the ActionBar pattern?
ActionbarSherlock is a starting point. It includes the compatibility libraries from Google and comes provided as a project rather than JAR offering greater flexibility, should you need to alter anything. Version 4 is on the way which will also include ICS stuff.
As far as I am aware I believe ABS is backward compatible to 1.6, and makes use of the minSdkVersion and targetSdkVersion. It uses an extended version of the holo theme to create a light and dark version that includes the extra ActionBar goodness, which in turn you can extend to style your app.
I recorded a tutorial on YouTube to get people started.
I think it's better to use the compatibilty libraries directly, instead of another library based on those. Additionally, refer to the Google I/O App as stated at the bottom of the first link I gave. You can find the best practices about implementing a UI for several devices with compatibility libraries.
I found ActionBarSherlock to be pretty good. It will emulate ActionBar on older devices and use the native one on modern ones. It's an extension to Android compatibility library - so you will also get fragments and other ICS stuff.