Profile cover photo
Profile photo
Christophe Beyls
Android developer/hacker from Brussels, BE.
Android developer/hacker from Brussels, BE.


While doing some notifications tests with the Android Wear 2.0 emulator (Android 7.1.1), I noticed there is no way to launch the main notification Intent (from setContentIntent) in Wear 2, while it's still working fine in Wear 1.

Is it a bug or am I missing something? I tried using WearableExtender.setHintContentIntentLaunchesActivity(true) but it has no effect.

I don't own any Wear 2 physical device so I have no idea how the main notification action is supposed to be launched on those.

More info:

Post has attachment
Reduce your Parcelable boilerplate code using Kotlin

Post has attachment
If you are interested in Kotlin and performance, I just published part 1 of "Exploring Kotlin's hidden costs"

+Adam Powell (and other Loaders gurus)
Hello, I have a question about Loaders in Fragments.

Are Loaders supposed to be able to start when a Fragment is in the detached state ? So far I always expected my Loaders to be started only between Fragment.onStart() and Fragment.onStop(), thus expecting that the fragment would already have a view hierarchy by the time the loader is started. Thus I did not check the existence of a view hierarchy in my LoaderCallbacks.

However, following a recent change you made in the framework and the support libraries, I noticed that now, Loaders in detached fragments are started then immediately retained during configuration change, and because my Loaders immediately deliver a cached result in Loader.onStart(), this causes my LoaderCallbacks.onLoadFinished() to be called when that fragment has no view hierarchy.

Is it a normal behaviour or can it be considered as a bug? If it's a bug and I file a bug report, can you fix it for the next release? Thank you.

Support library source: FragmentHostCallback.retainLoaderNonConfig()

I noticed that the selected item of the dynamically-populated Spinners in my apps is not restored properly anymore since Android N. This works fine in previous versions of Android.

After spending 1 hour to figure out what's going on, it seems to be a regression caused by this commit:

I only started using Android N recently and I'm surprised nobody reported or noticed this bug so far (it's there since 7.0).

Post has attachment

Post has shared content
A must read if you want to learn more about animated vector drawables.
An Introduction to Icon Animation Techniques

Week #1: wrote 27 icon animations for Android
Week #2: learned how to animate SVGs using SMIL and CSS
Week #3: learned the basics of Adobe After Effects to create cooler and more advanced icon animation effects
Week #4,5,6: learned JavaScript and ported 19 icon animations from Android to SVG to use as inline blog post demos
Week #7: rewrote and polished a bunch of animations, planned out structure of blog post
Week #8: writing, editting, rewriting, deleting, rewriting again, editting, repeat...

Don't think I have ever worked this much on a single blog post before... but I wouldn't have it any other way. Let me know what you think, and don't forget to share! :D


Post has attachment
Yesterday I was looking on how to enable scrollbars programmatically on a RecyclerView and the consensus seemed to be that it's not currently possible and you have to inflate a layout.

However I found a way and wanted to share it with you. You can just simply create a style and pass it to the constructor. I find this more efficient than inflation.

TextView drawing performance question

Is there a drawing performance hit when animating a drawable set as compound drawable on a TextView, compared to animating the same drawable in an ImageView ?

I know that the Canvas will clip bounds to the compound drawable area during its redraw, but since all text operations are also quite CPU-intensive I was wondering if this has a performance impact during animations at 60 fps.

Memory leaks in Fragments's LoaderManager

Hello developers. Recently I've been doing memory leaks tests in my apps using Leak Canary and the memory analysis tool in Android Studio.
I use Loaders and Fragments extensively in my apps for a long time and I noticed that the LoaderManager is always leaking my activity in every version of the support library since 24.0.0. It seems to happen as soon as you're using the LoaderManager in a Fragment and you detach it (the fragments are not retained). With previous versions of support-v4, the leak only happens if the fragment using Loaders is retained.

To summarize: as soon as I'm using a Loader in a Fragment and I detach the Fragment, I have two instances of my Activity in memory after rotating the screen.

Did you notice the same thing? It's a very serious issue for me so I decided to stick with AppCompat 23.4.0 for now.

Edit: I've been able to create a minimal sample project to reproduce the issue. The leak happens when a Fragment using a Loader is detached.

Edit 2: A leak also happens for all fragments with setRetainInstance(true) using a Loader, even if they are not detached. This bug was already present in previous versions of the support library.
Wait while more posts are being loaded