There's a funny little timing problem I ran into recently I'd like to share regarding window size and split action bars.
In an app I've got a loading screen that displays as we're making network requests. It's a cute SurfaceView with some animation to keep users amused. I'd written most of the initialization of assets inside of onSurfaceChanged() because I wanted to pre-scale everything to the exact size of the surface.
But a problem arose - for some reason onSurfaceChanged() was being called twice (and only when in portrait, not in landscape). This was troublesome because it's somewhat a substantial method due to all the initialization. What was happening?
It turns out that the split action bar was the culprit. Here's how things went down:
1. In onCreate(), add the SurfaceView to the view hierarchy.
2. SurfaceView.onSurfaceChanged() would be called.
3. onCreateOptionsMenu() would then be called. Since I had splitActionBarWhenNarrow set for the Activity, this would create the split action bar.
4. Due to the split action bar, the window size would change. SurfaceView.onSurfaceChanged() would be called a second time.
The solution was to move the addition of the Fragment with the SurfaceView somewhere after onCreateOptionsMenu(). I put it in onPostResume() (but make sure to call it only once on initialization).
There is one alternative solution, which is to call invalidateOptionsMenu() (or supportInvalidateOptionsMenu(), if you're using the support library) during onCreate(). This will force onCreateOptionsMenu() to be called early. I dislike this answer because it screws up the normal lifecycle for menu creation and can therefore readily cause confusing issues down the line.
Monday, September 10, 2012
Wednesday, August 29, 2012
Manually Adding the Legacy Overflow Button when targetSdkVersion >= 14
My company is in the process of converting our apps to use action bars, but we're not quite there yet. In the meantime, we've depended on the legacy overflow button on devices without a dedicated menu button:
A problem has arisen because we've bumped our targetSdkVersion up to 16 (Jelly Bean). It turns out there is a specific set of rules for when the legacy overflow button appears. Our app was depending on the fact that our minSdkVersion was less than 10 and that our targetSdkVersion was between 11 and 13. By bumping our targetSdkVersion up to 16, we no longer got the legacy overflow button.
This situation wouldn't be a problem if we showed an action bar, since the overflow menu would just appear there. However, we're using a theme that disables the title, so our menu items disappeared completely.
I want to emphasize that the correct solution is to use an action bar with an overflow button. But we're not done with the conversion to action bars yet and during development we'll want that menu to be accessible (all of our debug options go in there). So I came up with a small hack that lets us enable the legacy overflow button manually.
It turns out there is a hidden Window flag - WindowManager.LayoutParams.FLAG_NEEDS_MENU_KEY - that determines whether the legacy overflow button is shown or not. By using reflection, we can retrieve this field and add it to the Window's flags:
I added the RuntimeException above because you need to call this after the decor View is set (or else it does nothing).
A problem has arisen because we've bumped our targetSdkVersion up to 16 (Jelly Bean). It turns out there is a specific set of rules for when the legacy overflow button appears. Our app was depending on the fact that our minSdkVersion was less than 10 and that our targetSdkVersion was between 11 and 13. By bumping our targetSdkVersion up to 16, we no longer got the legacy overflow button.
This situation wouldn't be a problem if we showed an action bar, since the overflow menu would just appear there. However, we're using a theme that disables the title, so our menu items disappeared completely.
I want to emphasize that the correct solution is to use an action bar with an overflow button. But we're not done with the conversion to action bars yet and during development we'll want that menu to be accessible (all of our debug options go in there). So I came up with a small hack that lets us enable the legacy overflow button manually.
It turns out there is a hidden Window flag - WindowManager.LayoutParams.FLAG_NEEDS_MENU_KEY - that determines whether the legacy overflow button is shown or not. By using reflection, we can retrieve this field and add it to the Window's flags:
public static void addLegacyOverflowButton(Window window) {
if (window.peekDecorView() == null) {
throw new RuntimeException("Must call addLegacyOverflowButton() after setContentView()");
}
try {
window.addFlags(WindowManager.LayoutParams.class.getField("FLAG_NEEDS_MENU_KEY").getInt(null));
}
catch (NoSuchFieldException e) {
// Ignore since this field won't exist in most versions of Android
}
catch (IllegalAccessException e) {
Log.w(TAG, "Could not access FLAG_NEEDS_MENU_KEY in addLegacyOverflowButton()", e);
}
}
I added the RuntimeException above because you need to call this after the decor View is set (or else it does nothing).
Friday, July 20, 2012
Android Emulator Keyboard Support in ADT 20+
If you've upgraded to ADT 20, you may have noticed that your keyboard no longer works on inputs on your emulator. That is, when you have an EditText on the screen, typing characters into your physical keyboard doesn't register anything in the emulator; you need to open the soft keyboard to do anything.
The problem is that the emulator no longer assumes you have keyboard support by default. You'll need to add it yourself to the emulator and your keyboard will work again:
The problem is that the emulator no longer assumes you have keyboard support by default. You'll need to add it yourself to the emulator and your keyboard will work again:
Tuesday, June 12, 2012
Fragment Transactions Reference
I recently found myself looking at Fragment transactions and wondering precisely what each Fragment state meant. I vaguely had an idea of what added, attached, shown, hidden, detached and removed meant, but not the specific behaviors of each. I spent a morning looking through Android's code to better understand what happens to Fragments.
Here's a reference manual for what I learned. I looked into two aspects of Fragments: fragment states, and animations in transactions. This research was done primarily on the compatibility library. It's possible that some of the details below will differ for the 3.x+ implementation of Fragments.
Fragment States
All of the below support animations. Terminology note: when I say "configuration change", I mean when the device changes configuration (for example, from portrait to landscape) and the Activity must be destroyed/recreated.
FragmentTransaction.add()/remove() - These add and remove a Fragment from the FragmentManager. By default, it will begin showing the Fragment as well. During the transaction the returns of Fragment.isAdded() and Fragment.isRemoved() will be modified. These states are preserved on configuration change, so a Fragment that's added will remain added and can be retrieved again from the FragmentManager. Since a removed Fragment is no longer part of the FragmentManager, it will not be retrievable after a configuration change either.
FragmentTransaction.attach()/detach() - These attach/detach a Fragment from the Activity (e.g., make it an active Fragment that can be seen). During the transaction the returns of Fragment.isAdded() and Fragment.isDetached() will be changed. These states are preserved on configuration change, which means that (unlike removing a Fragment) it is possible to detach a Fragment but then retrieve it later after configuration change (even if it's not actively being displayed). Even in a detached state, the Fragment runs through all lifecycle methods (except the ones that are related to being attached to an Activity) - for example, onSaveInstanceState() will still be called even if the Fragment is detached (which is quite useful for maintaining state).
FragmentTransaction.show()/hide() - These show or hide a Fragment (in particular, it calls View.setVisibility() on the Fragment's root View). During the transaction the returns of Fragment.isHidden() will be modified. Showing/hiding Fragments states are NOT maintained on configuration change, meaning that if you hide a Fragment it will reappear on config change (for example, if the user rotates the screen).
FragmentTransaction.replace() - Theoretically it is the exact same as removing all Fragments associated with a particular View, then adding a new Fragment in its place. I did not research this much (since I'm more interested in manual control of which Fragments are shown).
Fragment Animations
There are three different ways to animate Fragment transactions. These are ordered by precedence (in other words, the first method, if available, will be used; then the second, then the last).
One thing to note between the compatibility library and the standard Fragment library is that the standard library uses property animators, whereas the compatibility library uses tween Animations.
1. Override your Fragment's onCreateAnimator() method and return an animation. This is the only way to dynamically generate an animation in code (the other two methods rely on pre-configured animations from your resources directory). In the compatibility library, the method is onCreateAnimation() (since the compatibility library uses animations instead of animators).
2. Call FragmentTransaction.setCustomAnimations(), referencing either animators or animations (depending on whether you're using the compatibility library or not). What is interesting is that setCustomAnimations() affects all fragment transitions added to the transaction after it is called. So you need to call setCustomAnimations() before you want it used, and you can actually setup multiple different custom animations for each part of a transaction (with a call to setCustomAnimations() before each add()/remove()/attach()/detach()/show()/hide()/replace()).
3. Setup a style that defines window animations (from this style), then call FragmentTransaction.setTransition() and FragmentTransaction.setTransitionStyle() to specify that style and target the correct animation.
#3 works different in the compatibility library. FragmentTransaction.setTransitionStyle() is completely ignored. Instead, it uses the specified transition to select a stock animation. So if you want custom animations in the compatibility library, you must use #1 or #2.
Here's a reference manual for what I learned. I looked into two aspects of Fragments: fragment states, and animations in transactions. This research was done primarily on the compatibility library. It's possible that some of the details below will differ for the 3.x+ implementation of Fragments.
Fragment States
All of the below support animations. Terminology note: when I say "configuration change", I mean when the device changes configuration (for example, from portrait to landscape) and the Activity must be destroyed/recreated.
FragmentTransaction.add()/remove() - These add and remove a Fragment from the FragmentManager. By default, it will begin showing the Fragment as well. During the transaction the returns of Fragment.isAdded() and Fragment.isRemoved() will be modified. These states are preserved on configuration change, so a Fragment that's added will remain added and can be retrieved again from the FragmentManager. Since a removed Fragment is no longer part of the FragmentManager, it will not be retrievable after a configuration change either.
FragmentTransaction.attach()/detach() - These attach/detach a Fragment from the Activity (e.g., make it an active Fragment that can be seen). During the transaction the returns of Fragment.isAdded() and Fragment.isDetached() will be changed. These states are preserved on configuration change, which means that (unlike removing a Fragment) it is possible to detach a Fragment but then retrieve it later after configuration change (even if it's not actively being displayed). Even in a detached state, the Fragment runs through all lifecycle methods (except the ones that are related to being attached to an Activity) - for example, onSaveInstanceState() will still be called even if the Fragment is detached (which is quite useful for maintaining state).
FragmentTransaction.show()/hide() - These show or hide a Fragment (in particular, it calls View.setVisibility() on the Fragment's root View). During the transaction the returns of Fragment.isHidden() will be modified. Showing/hiding Fragments states are NOT maintained on configuration change, meaning that if you hide a Fragment it will reappear on config change (for example, if the user rotates the screen).
FragmentTransaction.replace() - Theoretically it is the exact same as removing all Fragments associated with a particular View, then adding a new Fragment in its place. I did not research this much (since I'm more interested in manual control of which Fragments are shown).
Fragment Animations
There are three different ways to animate Fragment transactions. These are ordered by precedence (in other words, the first method, if available, will be used; then the second, then the last).
One thing to note between the compatibility library and the standard Fragment library is that the standard library uses property animators, whereas the compatibility library uses tween Animations.
1. Override your Fragment's onCreateAnimator() method and return an animation. This is the only way to dynamically generate an animation in code (the other two methods rely on pre-configured animations from your resources directory). In the compatibility library, the method is onCreateAnimation() (since the compatibility library uses animations instead of animators).
2. Call FragmentTransaction.setCustomAnimations(), referencing either animators or animations (depending on whether you're using the compatibility library or not). What is interesting is that setCustomAnimations() affects all fragment transitions added to the transaction after it is called. So you need to call setCustomAnimations() before you want it used, and you can actually setup multiple different custom animations for each part of a transaction (with a call to setCustomAnimations() before each add()/remove()/attach()/detach()/show()/hide()/replace()).
3. Setup a style that defines window animations (from this style), then call FragmentTransaction.setTransition() and FragmentTransaction.setTransitionStyle() to specify that style and target the correct animation.
#3 works different in the compatibility library. FragmentTransaction.setTransitionStyle() is completely ignored. Instead, it uses the specified transition to select a stock animation. So if you want custom animations in the compatibility library, you must use #1 or #2.
Tuesday, June 5, 2012
Obscure SimpleDateFormat Android Issue
This bug should win an award for the most obscure bug I've ever run into this year.
You might expect the two formats to be different (one for May 11, the other for May 12). You would be wrong on Android 2.2 and lower. It turns out in this one specific case, the SimpleDateFormat will spit out the same formatted date for the two Calendars.
The conditions seem to be thus:
In this one situation, SimpleDateFormat gets into a state where it formats both Calendars to the same date (May 11). Change any of the above assumptions and the problem will not occur; if the Calendars are more than one day apart, or you use multiple SimpleDateFormats, or you don't set the TimeZone, or you don't immediately reuse the same SimpleDateFormat...
This problem does not occur on Android 2.3+. For Android 2.2 and lower, the solution is simple - create a new SimpleDateFormat when formatting two Calendars one after another.
Check out this code below:
Calendar cal1 = new GregorianCalendar(2012, 5, 11);
cal1.setTimeZone(TimeZone.getTimeZone("UTC"));
Calendar cal2 = new GregorianCalendar(2012, 5, 12);
cal2.setTimeZone(TimeZone.getTimeZone("UTC"));
DateFormat df = new SimpleDateFormat("yyyy-MM-dd");
df.setTimeZone(TimeZone.getTimeZone("UTC"));
Log.i("test", "cal1.format=" + df.format(cal1.getTime()));
Log.i("test", "cal2.format=" + df.format(cal2.getTime()));
You might expect the two formats to be different (one for May 11, the other for May 12). You would be wrong on Android 2.2 and lower. It turns out in this one specific case, the SimpleDateFormat will spit out the same formatted date for the two Calendars.
The conditions seem to be thus:
- Two Calendar objects that are one day apart.
- One SimpleDateFormat that you want to use.
- Both the Calendars and the DateFormat are set to the same TimeZone.
- You format both Calendars using the DateFormat, one after another.
In this one situation, SimpleDateFormat gets into a state where it formats both Calendars to the same date (May 11). Change any of the above assumptions and the problem will not occur; if the Calendars are more than one day apart, or you use multiple SimpleDateFormats, or you don't set the TimeZone, or you don't immediately reuse the same SimpleDateFormat...
This problem does not occur on Android 2.3+. For Android 2.2 and lower, the solution is simple - create a new SimpleDateFormat when formatting two Calendars one after another.
Tuesday, April 17, 2012
Custom Fragment animations are different between the support library and vanilla
I've been converting a lot of my apps to the support library recently and ran into one issue worth mentioning. To be clear: I'm converting apps that use android.app.Fragment to now use support versions of Fragments.
If you do this and you're using FragmentTransaction.setCustomAnimations() you may be in for a shock. Your app will crash in the most glorious fashion:
The reason is that setCustomAnimations() in vanilla use object animators, whereas setCustomAnimations() in the support package use tween animations. It won't give you a compiler error because they're both referenced by resource id.
There's only one solution: convert your object animators to tween animations. The conversion wasn't difficult at all for me. In fact, it makes things a bit easier - object animators don't do percentages while tweens do, a problem I had struggled with before ("how do I get a Fragment to slide in from left to center?").
If you do this and you're using FragmentTransaction.setCustomAnimations() you may be in for a shock. Your app will crash in the most glorious fashion:
FATAL EXCEPTION: main java.lang.RuntimeException: Unknown animation name: objectAnimator at android.view.animation.AnimationUtils.createAnimationFromXml(AnimationUtils.java:124) at android.view.animation.AnimationUtils.createAnimationFromXml(AnimationUtils.java:91) at android.view.animation.AnimationUtils.loadAnimation(AnimationUtils.java:72) at android.support.v4.app.FragmentManagerImpl.loadAnimation(FragmentManager.java:710) at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:876) at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1080) at android.support.v4.app.BackStackRecord.run(BackStackRecord.java:622) at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1416) at android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:420) at android.os.Handler.handleCallback(Handler.java:587) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:132) at android.app.ActivityThread.main(ActivityThread.java:4123) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:491) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599) at dalvik.system.NativeStart.main(Native Method)
The reason is that setCustomAnimations() in vanilla use object animators, whereas setCustomAnimations() in the support package use tween animations. It won't give you a compiler error because they're both referenced by resource id.
There's only one solution: convert your object animators to tween animations. The conversion wasn't difficult at all for me. In fact, it makes things a bit easier - object animators don't do percentages while tweens do, a problem I had struggled with before ("how do I get a Fragment to slide in from left to center?").
Tuesday, April 10, 2012
Unicode Normalization and Android
I ran into a Unicode rendering issue recently that I wanted to go over. Check out this screenshot from an application we've recently localized into Vietnamese:
Notice how a lot of the text looks cut off (especially those blue labels). What's going on?
It turns out that the TextViews are rendering diacritics improperly. Sometimes the diacritic ends up on the wrong character. Other times, it ends up on its own space. The layout system seems to figure out the width correctly but the renderer screws it up, causing the text to be cut off when layout_width is set to wrap_content. The root of the problem is that Android is messing up combining characters (or combining diacritical marks) in unicode.
The solution that we found was unicode normalization. A character with diacritics can always be represented by a combination of multiple code points, but sometimes there is also a single code point that represents the character. We found that by using unicode's normalization form C (NFC), we could normalize most of the combining diacritical characters out of text (and thus sidestep this problem altogether).
There's two steps we're taking to normalize our text:
1. For all strings that are in our APK, we normalized them inside strings.xml. There are plenty of tools out there (like charlint) that can do the job.
2. We run all strings delivered from servers through Normalizer while parsing. It did not seem to degrade performance to do so.
Step 2 may not be necessary if your app is self-contained and never gets any strings from the net. Also, you could just use Normalizer as your tool for step 1 (it's up to you).
We found this problem to only happen on ICS - it appears to work fine on honeycomb and below. Also, if you want to know more about unicode normalization, I highly recommend reading this article.
Subscribe to:
Posts (Atom)