Android 4.2 introduced the support for Right To Left action bar, is there a way to configure the Sherlock Action bar to be in RTL mode?
note that the current Sherlock Actionbar version is 4.2, but I couldn't find anything related to the RTL support.
As of this time, the RTL feature of the ActionBar has not been included in the support library. From what I can gather, it's not scheduled to be, either, since there were some changes to the underlying View structure.
If you're using ActionBarSherlock, it will work the same as if you're using a native ActionBar. From 4.2 up, it will support RTL, and not on lower platform levels. Assuming you have android:supportsRtl="true" in your manifest, that is.
If you want to have a good RTL experience for all users, while still using the native RTL support for those on >=4.2, you can check the build level in your app and plan accordingly.
The alternatives as I see it are:
Use a custom layout for all users and forgo the ease of the new API levels
Support RTL for no users
Your question was: "Is there any way to configure ABS for RTL?". The answer to that is yes, but only if users are on 4.2. For anything lower than that, there is simply no way to do it without custom layouts.
Related
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 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.
Is there a Switch widget that comes with Android 4.0 and above in the ActionBarSherlock packages. I see ABS has a 4.0 compatible Spinner View, but no Switch. Does Jake intend to include this in any near release?
No, the Switch component is not part of the action bar and hence will never be part of ActionBarSherlock. The Spinner that is included is a subset of the full version which only has the necessary features required to work inside the action bar.
If you need a components like this on all versions of Android I suggest you backport it yourself. Just grab the source, styles, and drawables and fix up any usage of new APIs to use old or compatible method calls.
If I'm trying to make my App work on older devices, I use the Support Libary and ActionBarSherlock.
Of Course, they also work on newer devices. But should i use them on new OS versions, or change the code and resource files so that 4.0 devices for example all use the stock classes and not the support ones.
For example (pseudocode):
if (running 4.0+){
ActionBar= getActionBar();
}else{
ActionBar= getSupportActionBar();
}
or just use this one on all versions:
ActionBar= getSupportActionBar();
What are best pratices, and does that affect stability and perfomance ?
You answered yourself already: "Of Course, they also work on newer devices". If it works then it works. Compatibility lib is just portion of Android framework separated from Honeycomb+ code and offered as .jar for use on older devices. If you target older devices, with pre 3.x Androids and HC+ devices at the same time, then if you still want to use fragments and stuff you got no other choice anyway. And you also need compatibility library for ActionBarSherlock, as it needs it as well.
As far as I know, ActionSherlockBar itself automatically switches everything based on the OS version. So you don't need to bother.
I have used it in my application and it works pretty much the same both on 2.3.7 and 4.0.
This is from its website:
The library will automatically use the native action bar when appropriate or will automatically wrap a custom implementation around your layouts. This allows you to easily develop an application with an action bar for every version of Android from 2.x and up.
These are my doubts while using ActionBar.
1) To make it prevalent across various tabs, I had to repeat the same code in all the tabs. Is there a better way to rewrite this part? I could have one ActionBar class which I can call everywhere, but that won't make it dynamic. (More options in certain tabs.)
2) I'm presently defining a menu and inflating it. Is it the best way to go about it? The problem I am facing here is I'm definitely not using the entire space and always running out of space to put in more actions. How to rectify it?
3) The third problem that I'm facing is a bug when I use Theme.Light. The app crashes. If I use Theme.Holo.Light, the app doesn't. Though, it still crashes in a 2.3 supporting phone. Anyway to rectify that? I mostly feel that I've missed out on backward compatibility or is Action bar not compatible with certain themes?
This answers your 3rd question, straight from docs here:
Beginning with Android 3.0 (API level 11), the action bar is included in all activities that use the Theme.Holo theme (or one of its descendants), which is the default theme when either the targetSdkVersion or minSdkVersion attribute is set to "11" or greater.
If you want to use ActionBar APIs, such as to add navigation modes and modify action bar styles, you should set the minSdkVersion to "11" or greater. If you want your app to support older versions of Android, there are ways to use a limited set of ActionBar APIs on devices that support API level 11 or higher, while still running on older versions. See the sidebox for information about remaining backward-compatible.
Sidebox info
If you want to provide an action bar in your application and remain compatible with versions of Android older than 3.0, you need to create the action bar in your activity's layout (because the ActionBar class is not available on older versions).
To help you, the Action Bar Compatibility sample app provides an API layer and action bar layout that allows your app to use some of the ActionBar APIs and also support older versions of Android by replacing the traditional title bar with a custom action bar layout.