I'm developing an app that needs to support multiple languages, including some for which fonts are not included in some older Android versions.
The same TextView can have content in multiple languages, so setting a single TypeFace does not help, I need to have a list of fall-back fonts to use when some characters are not available in preferred fonts.
Extending to this, I also need to use the same set of fonts for other elements also (not only TextViews) if possible.
I had a workaround for this. I extended the Application class for the app and set the fonts globally there.
For the fallback fonts, I read the Android API code for Typeface and going from there, I found some hidden APIs. Doing all sorts of hacking (reflections, getting private/hidden classes or methods, setting private fields etc.), I finally made it working for Android API versions 21 to 23. Not sure about the newer APIs and it doesn't work for the older ones.
You can check my code at https://gist.github.com/nisargjhaveri/47acc83e66dcb347e05685ccfd3038e8
It is working, but even I don't recommend using it!
The better solution for this may be to use TypefaceSpans, after detecting the best typeface for each character, everytime you show text to user. I did not try this.
Also, I just have been playing with android for past two months, so think twice before you take my advice! :P
Related
I'm generating HTML-mails and as such, need to fall back to inline styling.
As a result, it's not possible (or hard?) to use #font-face and I need to rely on font-style or font-family.
It's working alright, but using "Impact" (required), is a problem since I can't find an Android replacement. Is there one? Is there a list of the fonts that the gmail app can render?
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'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
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