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.
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 want to create from my App a bunch of folders on the Home screen with Apps and Shortcuts inside. I also need to change these folders once in a while, adding and removing items in there.
Android 1.x and 2.x used to have Live Folders that have been deprecated.
Honeycomb has App Widgets Collections.
I believe Android 4.x has a new type of folders.
Which Api should I use to compatible with all version of Android?
I notice how many other Apps use widgets that looks like folders, but adding them to the Home screen is a pain and they are not standard.
I'm planning on writing an app and building against 2.2 Froyo (API Level 8). However, I want app users of 4.0 ICS to experience the app with the ICS user interface.
Currently my approach is to have the default activity of my app sense the version of the Android device.
If it is less than 4.0, use XML views written for Gingerbread and Froyo and, if it's 4.0 or higher to use ICS XML views. This however seems a bit haphazard and I'm not sure I can manage the separation of version views effectively.
What approaches, tools, and ideas can I use to help me make my app? Is it even something I need to consider? Is my idea of the view separation above correct? Do I have alternatives I could use instead?
Cheers!
If you just want to apply different resources for different OS version, you can let system do it for you by putting your resources into different resource folders with the "v" qualifer. Such as "layout-v8" folder for layouts used for Froyo and "layout-v14" for layouts used for ICS. I did not try this but from the document, that's what it supposes to do.
The Crunchyroll app (an anime viewer) has separate activities and layouts for Froyo vs. Honeycomb/Google TV, defaults to one or the other on initial startup, and thereafter allows the user to declare a preference for one or the other. I'm not affiliated with CR, but I use and have studied the app. One problem the app has, which may be encouraged by the level of separation it has between the two targets, is that the pre-Honeycomb interface has many features, and continues to receive updates, that the tablet/TV interface is only promised.
As for tools, you can use later features while targeting an earlier OS with the SDK's support package, which backports features (e.g., fragments) appropriately.
In the guidelines found in http://developer.android.com/guide/practices/ui_guidelines/index.html for menu and status icons, we have distinctive design approach for Android 2.2 and earlier and Android 2.3 and later.
My app is going to support Android 2.2 and later. I was thinking that i should follow the 2.3 and later guidelines.
Do you agree?
You can follow multiple styles by creating subfolders with the correct android version specifiers inside your res/ folder (e.g. drawable-v11 for API 11 - check the official documentation here). So I suggest supporting multiple styles.
This is obviously a bit more work. To make this easy for standard icons like notifications, check out the Android Asset Studio. This is a small webapp that creates these icons to your specifications and builds a zip with the multiple styles, already sorted into the different res/ subfolders.
On thing you could do is include assets for both builds, and at run time, figure out if you're on 2.2 or 2.3, and show the appropriate assets. This can be done with build.version or this method for earlier releases.
Of course, if you want multiple icons, I don't believe this method would work, as that needs to be build into the android manifest.
I would like to use some of the default menu icons provided by the Android OS.
The XML would be something like this:
<item android:id="#+id/menu_refresh"
android:icon="#android:drawable/ic_menu_refresh"
android:title="#string/menu_refresh" />
But the documentation says this is unadvised.
Warning: Because these resources can
change between platform versions, you
should not reference these icons using
the Android platform resource IDs
(i.e. menu icons under
android.R.drawable).
I thought the whole point of using the default icons is because the design does change from OS to OS. By using the default icons, your app will look and feel appropriate for the OS it's running on. So what is so bad about using the default icons? It seems like not using the default icons would hurt the appearance of the app.
The problem is that you are adding in a dependency that google does not guarantee will be static.
The names of these icons could change, the size could change and become incompatible with your app.
If you want icons to be the same as the current google ones, you can use the ones available here
It is very possible that some configuration of android will NOT have these resources read: HTC Sense, Samsung TouchWiz.
What you can do is find the drawables you want in your sdkFolder/platforms/platform-#/data/res/ and drop them into your project. Then reference them as you would any normal resources (#drawable/icon).
IMO, in practice you can use menu icons provided by Android OS, as long you use only the icons provided by OS for all your menu items. If you need another icon (say, refresh), you will need to copy images for other icons as well. Otherwise, if you mix your own and OS icons, visual styles may differ significantly on some devices.
I really can't think of a reason not to other than what if your operation does something more than slightly different from the associated action the OS does. For an exagerated instance, if you had your trash can button be the place where you created new widgets. But I figure if you are keeping the operations similar to those of the OS, then you are fine. In fact I agree with you, it may even look better for the app.
The problem is with the "customizations" each carrier or factory makes to the OS, so you cannot assume they are present or match the use. Anyhow,if you like them, you might just copy them to your drawables, as they will look standard no matter the customizations.
Also it can vary from android version to another android version.. So it would be best to include your own set of icons