Everything I'm reading so far about backwards compatibility with material design indicates that I have to maintain two separate sets of layout files if I want to use any material design features and maintain backward compatibility, one for 21+, and one for pre-21. Needless to say, this really sucks. Every time I want to change something in the UI, I have to change it twice. Am I correct in this, or is there a cool workaround I have not found?
It seems that an alternative is to set all the material design attributes in Java instead of XML, wrapped in a check against the current SDK version. I would consider this pretty ugly, but it might be better than duplicating layouts. Maybe a clever way to hide it away would make it more tolerable.
I can't think of anything other than these two bad solutions - has anyone found something better?
ianhanniballake is right, you can just leave the new tags in the file. I was basing my ire on this from the documentation:
If the layouts that you design according to the material design
guidelines do not use any of the new XML attributes introduced in
Android 5.0 (API level 21), they will work on previous versions of
Android. Otherwise, you can provide alternative layouts. You can also
provide alternative layouts to customize how your app looks on earlier
versions of Android.
Create your layout files for Android 5.0 (API level 21) inside
res/layout-v21/ and your alternative layout files for earlier versions
of Android inside res/layout/. For example, res/layout/my_activity.xml
is an alternative layout for res/layout-v21/my_activity.xml.
Which I think clearly says to use new attributes you have to duplicate your files. It seems that is not the case after all. Thanks.
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 given my application target as 21. So I can use the Material Design API's. But when I run the same on older devices whether I have to define different layout or theme or how it could me.
And also I have read the official document Maintaining Compatibility.
But still I was not clear to use the material theme on android devices less than 5 os.
And also where can I find the Android 5 related XML tags. And how the same tags applied when running on devices less than 5.
Please help me on this. Thanks in advance.
There are few library's to achieve the Material Design applicable to an earlier platforms less than API-21.
An example of such library is this one:
https://android-arsenal.com/details/1/1156. You can look on Android Arsenal for more library's like this.
Also this blog-post from Chris Banes is about Material Design on older platforms, I recommend that you read it: https://chris.banes.me/2014/10/17/appcompat-v21/. I hope it will be helpful for reduce design complexity.
As I can see, more and more functions from Android 4.x like fragments or action bar are now supported on lower android versions by using support library. Anyone knows, if it works also for scrolling inside widget, which was introduced in Android 3.x? thx
Probably not going to happen, and probably not really possible. This needs support for the corresponding RemoteView's, etc. which is a little deeper in the platform than fragments, etc. You are, of course, welcome to give it a try.
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.
I've been trying to figure this out for a little while and I'm sure I've seen something on this before either on the Android dev blog or SO but it's fleeing me currently. I was wondering the best way to target different API levels with a single APK, if possible.
For example, I would like to be able to take advantage of the new Ice Cream Sandwich features and UI patterns but also want to support Gingerbread and below. Would the best solution be to make different projects with a similar code base but rewriting specific features to use the specific features and posting multiple APKs in the Market or could I use a form of reflection to scale back?
Any help would be greatly appreciated, thanks! Mainly, I would like to know if multiple APKs are necessarily bad or if I'd be better off with a single APK.
This is the canonical blog post for backwards compatibility: http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html
ICS -> Gingerbread can get complicated if you're using custom themes or want to use fragments.
I'm in the process of writing an article for developer.android.com that goes into more detail about this, but the short version is:
Create a res/values-v11 and a res/values folder. The v11 folder should hold themes which inherit from android.theme.Holo and the non-v11 folder should hold themes which inherit from android.theme. If you don't use custom themes, you can skip this step -- setting targetSdkLevel >= 11 will do all the magic for you.
Use the support package to provide Fragment/Loader support on pre-Honeycomb devices: http://developer.android.com/sdk/compatibility-library.html