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.
Related
I'm working with Xamarin.Android.
Appcompat is actually necessary for use material design because the nougat package (Android.support.design) requires it.
But why, for example, if I work only with API 27, I must add the AppCompat package? In my toolBox i've not the floatingActionButton, NavigationDrawer etc.. so I must add this packet to unlock them.
What is exactly this package? I've read on the web that this package works with backward compatibility but I only work with new APIs, so why I must install it?
Thanks.
AppCompat should add the 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:
https://developer.android.com/topic/libraries/support-library/features.html
The Xamarin.Android.AppCompat is just what it says. Its a library for App Compatibility for backward compatibility for previous versions of Android and more specifically this version (v7) brings support for Action Bar support. Read more here :
AppCompat
They are libraries used for accessing the latest features of an Android OS version. It is backward compatible by the way.
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 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 have used several applications which appear to use Android 4.0's 'Holo' theme, whilst still running on an older version of Android (2.3). Is there a supported way to do this or have these developers designed their own custom themes?
Thanks.
I am working on this:
https://github.com/ChristopheVersieux/HoloEverywhere
EDIT: Moved to: https://github.com/Prototik/HoloEverywhere
Might be really fit your needs.
Look here SDK/platforms/android-15/data/res/
There are all styles and related resource data used on latest Android 4.
You can also download it from here:
https://github.com/android/platform_frameworks_base/tree/master/core/res
And you can grab what you need from here to your app. Only remove android: prefix to use it in you project. This is only way how to defines the same theme as is used in the latest Android versions.
i've noticed that the default look of tabs has changed between Android versions (see screenshot). I like the first version better, but i need to set my android target to version 8 (android 2.2) so that app2sd works. but then i have the darker backgrounds. how can i switch to the old one? setting the background color manually produces ugly results
Since TabView is a standard widget, it likely relies on a system resource in android.R (or similar.) Because the theme was changed, you would have to manually extract the old images from older android source, copy them to your project, and hook them up to your TabView.
Remember that if your app were able to run on earlier versions of android, on certain custom ROMs, or phones that deviate from the standard android UI, it would look different on each unless you manually set it up to use a specific skin set.