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.
Related
With the number of users moving to 7+ android version, is AppCompat still necessary or can I use the new libraries instead. This is specially related to styling. I want to switch to the Material design library for styling. What i'm asking is, is it recommend to use the new Material design library versus AppCompat?
The Material Design Components are built on top of AppCompat, so while you may use Material styles in place of AppCompat, you still need AppCompat under the hood to provide a consistent base across all API levels. This also means you need to continue to extend AppCompatActivity, etc.
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.
I just started my journey on Android Development and there's one thing that is confusing me.
When creating menu items why do we need to specify an alias for properties when android studio's autocomplete suggests the use of android:showAsAction="value"?
when using android:showAsAction the property is ignored. If i replace it for anything else it works. Why?
Related
https://stackoverflow.com/a/17914095/1084568
If you are using the native action bar, you use android:showAsAction. Any time you see android: as a prefix, you know that it is an attribute defined by the Android framework.
If you are using the appcompat-v7 backport of the action bar, that comes from a library (appcompat-v7). Libraries cannot invent new android: attributes. Instead, for library-defined attributes, you use a new namespace (e.g., app:) tied to a http://schemas.android.com/apk/res-auto URL.
it says that android: namespace is not able to provide access to the property if the we pretend to support older android versions such as 2.1
Correct. In this case, while android:showAsAction was added to the framework in Android 3.0, part of the goal of appcompat-v7 is to support back to Android 2.1. While Google has a time machine, they have not been using it to "retcon" Android and add in attributes that formerly did not exist.
(though, if they did, we wouldn't know about it, as our past would have been altered to have those attributes, unless we somehow have an existence outside the normal space-time continuum, which frequently seems to involve wearing a cape)
So, appcompat-v7 can use attributes like android:icon, which existed from Android 1.0, but cannot support an android:showAsAction prior to Android 3.0. Hence, they have their own attribute.
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 have an app that supports Android v14 and up. I'd like to use the Cast SDK, as well as some of the Material features that were added to v7-appcompat. I'm currently using v13-support, which wraps v4-support but let's you use real Fragments.
Is there any way to use the Cast SDK back to v14 without incurring the cost of using FragmentActivity et al? Needing to replace all my styles/themes and base classes, go find every reference to getFragmentManager and replace them all with getSupportFragmentManager so on, and so on...?
The features that I"m interested in from v7 support library have seemingly nothing to do with Faux Fragments or Faux Holo themes...the idea of refactoring the whole app to use the Faux Fragments in order to use Cast seems audacious.
Anybody know an alternative?
(the app i'm working on has backwards compatibility issues beyond the v7 support library, so using v7 wouldn't change the fact that the app needs to be 14+)