It is recommended that you copy images into your project. But what about everything else?
I designed an app on 2.1... but it looks different on 2.3.3. There are minor things like the background of alert dialogs, context menus, options menus. And for some reason I can't get this ic_dialog_generic to show up in 2.3.3 even though I have it in my project.
What's the best way to handle these things?
This only partially answers your question, but you can sometimes reuse drawables from android.R.drawables. In practice, I've seen my interface stay readable and fashionable enough through android 2.1 to 3.0 using the public drawables in context menus and the like.
See this useful resource based on stock android 2.2
Related
Is there a easy way to have our application look like ICS or JB?
Mainly the slider and the radio button. They look old when displayed in green.
Any hint about this?
There's a nice package available on github called HoloEverywhere.
One thing though, do not try pass it off as a ICS/JB Application, just because it "looks" like the user interface one would expect to see in a native ICS/JB Android set up.
Best that can be done with the project, is to target the latest SDK to guarantee your wide-market of Android usage, including GB.
Aim high, not low ;)
The best way is to use the Android Library 'Actionbar Sherlock'. This Library uses all native ICS Themes, etc for older devices.
ActionBarSherlock is an extension of the compatibility library designed to facilitate the use of the action bar design pattern across all versions of Android with a single API.
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.
I'm looking to create a cross-version compatible android tabbed layout.
The problem I'm running into is when implementing Google's example of TabActivity, I get a depreciation notice. The app I'm writing needs to be compatible down to 2.1, and I'm not finding a clear cut way to make it compatible.
I am aware of the versioning by folder (/layout-v4, /layout-v14, etc) but if possible I want to avoid this.
Are fragments the answer here and if so, does the Android Compatibility Layer V4 become the key to solving this problem?
I'd suggest the best approach might be to use the excellent (and free) ActionBarSherlock, so you can add Android 3+ action bar (including tabs) to apps going all the way back to v2.x versions.
I've used it on a few apps and it's pretty easy. I think it's the right approach to use the proper Action Bar interface across platform versions, and they include tabs and replace the whole TabActivity thing, which was pretty horrible anyway.
http://actionbarsherlock.com/
I have a published app for Android 1.x and 2.x, and now I want to make it support 3.x.
But Android 3.0 has massive API change, especially on UI, thus if I want to make one app compatible to 2.x and 3.x, the code will be ugly and package file will be huge.
On the other hand, if I make another app for 3.x, then I need to maintain two copies of their common codes. That's really annoying.
What should I choose, or does anyone have a more smart solution? Thanks!
If you package them together you could still maintain everything separately - For example: put a prefix in front of every layout and class for 3.x, such as honeyMain.class, and honeymain.xml
Or you could do it a way that makes more sense for you.
Or keep them partially together.
It WILL make your app larger, but then when 15 people with 3.x download it and 60 people with 2.x download it, you get 75 downloads, instead of 15 for one app and 60 for the other. The 75 cumulative will look better on the apps over all ranking on the market.
On the other hand, if the 3.x is really ugly or FCs, then negative ratings will impact both 2.x and 3.x, but that is easily controlled for by testing, testing, testing.
Also, I personally hate managing code for two different apps. It's overly repetitive.
So, my recommendation is to package them together.
Make use of resource qualifiers, e.g. -xlarge, -v11, etc.
Use reflection where necessary or other techniques to avoid pulling in stuff not supported by API level.
Use the compatability library, that way you can fragmentize your code regardless, avoiding duplication, and with little effort handle different screen sizes.
See providing resources
See multple screens
See compat lib
Right click on your project and select "properties",select "android" from window,and which type of version you want check it and apply
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