The goal of this new library is to brige the gap between the theory of the Material Design specification and having actual available code to implement it.

The new library sits on top of the existing support-v7-appcompat package (which provides the base Material theming ability) and offers a bunch of new UI components and interactions from the specification.

Today I want to focus on two of those new elements that we will be using together: the infamous FAB (Floating Action Button) and CoordinatorLayout.

The FAB strikes back

If I had to pick one of the most iconic aspect of material design it would be the floating action button (henceforth known as FAB). It’s actually deemed important enough that the specification was expanded recently to have a dedicated section for it.

FAB are circular buttons containing a single icon (usually white or black) with a bright background (the color accent of your app for instance) and generally elevated above content (thus casting a shadow).

These FABs showcase the main actions that your app has to offer. As such, they are ones of the most important part of your UI and you should always pay special attention to get their interactions right.

Because FABs are so proeminent visually, they also offer a good opportunity to add pleasant touches to your app. In the word of the specification: “Take advantage of [FAB’s] visibility to create delightful transitions for a primary UI element.”

The support design library offers a default implementation of that UI widget that’s backward compatible with older versions of Android that don’t have elevation/shadow support or round clipping in the form of the FloatingActionButton widget which is a subclass of the classic ImageView.

Here I want to focus on one of the documented FAB transition: morphing. This transition is used to alternate between two main actions for a single FAB depending on the context:

To implement this, you can create a simple subclass of the default FAB that let you also specify a secondary set of icon and background and then create a custom animation to alternate between the two:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

public class SwitchableFab : FloatingActionButton
{
	AnimatorSet switchAnimation;
	bool state;
	Drawable srcFirst, srcSecond;
	ColorStateList backgroundTintFirst, backgroundTintSecond;

	// ctors.

	void Initialize (Context context, IAttributeSet attrs)
	{
		srcFirst = this.Drawable;
		backgroundTintFirst = this.BackgroundTintList;

		if (attrs == null)
			return;
		var array = context.ObtainStyledAttributes (attrs, Resource.Styleable.SwitchableFab);
		srcSecond = array.GetDrawable (Resource.Styleable.SwitchableFab_srcSecond);
		backgroundTintSecond = array.GetColorStateList (Resource.Styleable.SwitchableFab_backgroundTintSecond);
		array.Recycle ();
	}

	public void Switch ()
	{
		if (state)
			Switch (srcFirst, backgroundTintFirst);
		else
			Switch (srcSecond, backgroundTintSecond);
		state = !state;
	}

	void Switch (Drawable src, ColorStateList tint)
	{
		const int ScaleDuration = 200;
		const int AlphaDuration = 150;
		const int AlphaInDelay = 50;
		const int InitialDelay = 100;

		if (switchAnimation != null) {
			switchAnimation.Cancel ();
			switchAnimation = null;
		}

		var currentSrc = this.Drawable;

		// Scaling down animation
		var circleAnimOutX = ObjectAnimator.OfFloat (this, "scaleX", 1, 0.1f);
		var circleAnimOutY = ObjectAnimator.OfFloat (this, "scaleY", 1, 0.1f);
		circleAnimOutX.SetDuration (ScaleDuration);
		circleAnimOutY.SetDuration (ScaleDuration);

		// Alpha out of the icon
		var iconAnimOut = ObjectAnimator.OfInt (currentSrc, "alpha", 255, 0);
		iconAnimOut.SetDuration (AlphaDuration);

		var outSet = new AnimatorSet ();
		outSet.PlayTogether (circleAnimOutX, circleAnimOutY, iconAnimOut);
		outSet.SetInterpolator (AnimationUtils.LoadInterpolator (Context,
		                                                         Android.Resource.Animation.AccelerateInterpolator));
		outSet.StartDelay = InitialDelay;
		outSet.AnimationEnd += (sender, e) => {
			BackgroundTintList = tint;
			SetImageDrawable (src);
			JumpDrawablesToCurrentState ();
			((Animator)sender).RemoveAllListeners ();
		};

		// Scaling up animation
		var circleAnimInX = ObjectAnimator.OfFloat (this, "scaleX", 0.1f, 1);
		var circleAnimInY = ObjectAnimator.OfFloat (this, "scaleY", 0.1f, 1);
		circleAnimInX.SetDuration (ScaleDuration);
		circleAnimInY.SetDuration (ScaleDuration);

		// Alpha in of the icon
		src.Alpha = 0;
		var iconAnimIn = ObjectAnimator.OfInt (src, "alpha", 0, 255);
		iconAnimIn.SetDuration (AlphaDuration);
		iconAnimIn.StartDelay = AlphaInDelay;

		var inSet = new AnimatorSet ();
		inSet.PlayTogether (circleAnimInX, circleAnimInY, iconAnimIn);
		inSet.SetInterpolator (AnimationUtils.LoadInterpolator (Context,
		                                                        Android.Resource.Animation.DecelerateInterpolator));

		switchAnimation = new AnimatorSet ();
		switchAnimation.PlaySequentially (outSet, inSet);
		switchAnimation.Start ();
	}
}

You can then instantiate this new class directly in your XML layout:

1
2
3
4
5
6
7
8
9
10

<myApp.SwitchableFab
    android:id="@+id/fabButton"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_gravity="end|bottom"
    android:layout_marginRight="16dp"
    android:layout_marginBottom="16dp"
    android:src="@drawable/ic_action_mylocation"
    app:srcSecond="@drawable/ic_favorite_selector"
    app:backgroundTintSecond="@color/favorite_background" />

For that interaction, the icon itself is normally not supposed to scale but since the widget is based on ImageView it’s impractical right now to separate the two layers to animate a counter-scale for the icon.

I imagine that a default implementation of the documented FAB interactions will likely find its way into the library at some stage but in the meantime it’s very easy to cook them up yourself like above.

You may also have noticed in the video that the second state of my FAB uses an animated selector. This is done by augmenting the SwitchableFab class to track the checkable state (as I have already demonstrated).

In any case, you can find the full implementation of that selector and checkable changes in Moyeu repository.

CoordinatorLayout, the missing orchestra conductor

Another interesting type that support-design brings is CoordinatorLayout.

On the surface it doesn’t seem to do much, it’s intended as a wrapper around your existing UI that behaves like a FrameLayout from a layout perspective. The true value of CoordinatorLayout is found on its child views.

Just like its name imply, CoordinatorLayout serves as a central conductor for more complex transitions that your app UI may be doing especially when involving several floating views like the aformentioned FAB or snackbars.

The core working of the class relies on so-called Behaviors that can be set on any child views of the CoordinatorLayout. In a behavior implementation, views can define if they want to be dependent on some other views and get a callback when that other view state (position, size, etc…) changes.

Behaviors can be attached to views in a multitude of ways but here is how you can declare it directly in your layout XML:

1
2
3

<!-- Based on the same FAB definition than above -->
<moyeu.SwitchableFab
    app:layout_behavior="md55d31ab91effba0f9ed7ec79c59c38391.InfoPaneFabBehavior" />

Here I made a custom behavior that allows me to automatically track the state of my application bottom pane as it appears/disappears and is dragged by the user so that the FAB automatically stick to it and change its state when the pane is initially expanded (using the transition animation we saw earlier):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

public class InfoPaneFabBehavior : CoordinatorLayout.Behavior
{
	int minMarginBottom;
	bool wasOpened = false;

	public InfoPaneFabBehavior (Context context, IAttributeSet attrs) : base (context, attrs)
	{
		minMarginBottom = (int)TypedValue.ApplyDimension (ComplexUnitType.Dip, 16, context.Resources.DisplayMetrics);
	}

	public override bool LayoutDependsOn (CoordinatorLayout parent, Java.Lang.Object child, View dependency)
	{
		return dependency is InfoPane;
	}

	public override bool OnDependentViewChanged (CoordinatorLayout parent, Java.Lang.Object child, View dependency)
	{
		// Move the fab vertically to place correctly wrt the info pane
		var fab = child.JavaCast<SwitchableFab> ();
		var currentInfoPaneY = ViewCompat.GetTranslationY (dependency);
		var newTransY = (int)Math.Max (0, dependency.Height - currentInfoPaneY - minMarginBottom - fab.Height / 2);
		ViewCompat.SetTranslationY (fab, -newTransY);

		// If alternating between open/closed state, change the FAB face
		if (wasOpened ^ ((InfoPane)dependency).Opened) {
			fab.Switch ();
			wasOpened = !wasOpened;
		}

		return true;
	}
}

Dead simple right?

CoordinatorLayout can also be used to implement other user interactions like swipe-to-dismiss or other scrolling techniques (like collapsing toolbars). Checkout the provided SwipeDismissBehavior and AppBarLayout.Behavior for more information on those scenarios.

In this post, I’m gonna show you how we can achieve the following transition animation by solely using vector drawables and Android’s built-in widget state tracking mechanism:

Staging

To build an animation like this, you have to prepare the adequate stage. Afterwards, it’s just a matter of moving each individual pieces of that stage when needed.

In the above video, we can split the final visual in a couple of different parts.

Some like the center dot and the upper-half donut are static pieces, they never move. The two white thin rectangles, symbolizing the hands on a watch, are individual moving parts. The sun, moon and exclamation mark symbols are the varying state of the visual depending on the input.

Now, that’s only the visible part of the puzzle. If you look closely at the animation you can notice that everytime there is a state transition the right hand seems to be erasing the visible time symbol before the new one fade in.

This is where things get interesting because to be able to achieve this effect you have to get creative with the Z-ordering of your stage.

To understand this better, below is a rendering of all the layers of the visual:

The rectangle you see covering the half-bottom part of the picture is not an artifact. It’s painted with the same color than the overall window background thus acting as a cheap but effective hiding mask.

If I conceal this rectangle, here is what’s lurking behind: the other half of the visible top donut

To create the aformentioned effect, we will be moving that half-bottom donut to cover the top one, synchronizing it with the right clock hand. When not in use, it will be safely tucked behind our hiding rectangle.

Because vector drawables have a simple bottom to top drawing hierarchy, for this to work correctly we have declare pieces in a specific order:

• top half donut
• the 3 time symbols
• bottom half donut
• hiding rectangle
• the 2 hands white rectangle

Based on our animation needs, we then split this further into actual vector drawable <group /> elements to arrive at the following shape (path data removed for brevity, you can download all the XML pack at the end of the article):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

<?xml version="1.0" encoding="UTF-8" ?>
<vector xmlns:android="http://schemas.android.com/apk/res/android"
	android:height="385dp"
	android:width="416dp"
	android:viewportHeight="385"
	android:viewportWidth="416">
	<group android:name="background">
		<path
			android:name="topPie"
			android:fillColor="#454D58"
			android:pathData="..." />
	</group>
	<group android:name="timeItems">
		<path
			android:name="moon"
			android:fillColor="#DAE2ED"
			android:fillAlpha="0"
			android:pathData="..." />
		<path
			android:name="sun"
			android:fillColor="#E39300"
			android:fillAlpha="0"
			android:pathData="..." />
		<path
			android:name="now"
			android:fillColor="#C52E26"
			android:fillAlpha="1"
			android:pathData="..." />
	</group>
	<group
		android:name="hidingPie"
		android:pivotX="208"
		android:pivotY="192.5">
		<path
			android:name="hidingPiePath"
			android:fillColor="#454D58"
			android:pathData="..." />
	</group>
	<group android:name="coverBackground">
		<path
			android:name="blueCover"
			android:fillColor="#343A42"
			android:pathData="..." />
		<path
			android:name="middleRing"
			android:fillColor="#D8D8D8"
			android:pathData="..." />
	</group>
	<group
		android:name="leftHand"
		android:pivotX="208"
		android:pivotY="192.5">
		<path
			android:fillColor="#D8D8D8"
			android:pathData="..." />
	</group>
	<group
		android:name="rightHand"
		android:pivotX="208"
		android:pivotY="192.5">
		<path
			android:fillColor="#D8D8D8"
			android:pathData="..." />
	</group>
</vector>

State tracking widget

Before we dwelve into some more animation tricks, we first need to investigate how to make widget to represent our triple state because there is nothing in the default framework that allow this.

The good news is that, as I showed in a previous blog, it’s very easy to create a custom, state-aware widget which is what we are going to do with this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

public class TriStateView : View
{
	int selectedIndex;

	public int SelectedIndex {
		get {
			return selectedIndex;
		}
		set {
			if (value < 0 || value > 2)
				throw new ArgumentOutOfRangeException ("value");
			JumpDrawablesToCurrentState ();
			selectedIndex = value;
			RefreshDrawableState ();
			Invalidate ();
		}
	}

	protected override int[] OnCreateDrawableState (int extraSpace)
	{
		switch (selectedIndex) {
		case 0:
			return new int[0];
		case 1:
			return new int[] { Android.Resource.Attribute.StateFirst };
		case 2:
			return new int[] { Android.Resource.Attribute.StateLast };
		default:
			return base.OnCreateDrawableState (extraSpace);
		}
	}
}

By setting our state transition drawable as the background of this view, it will automatically react to state changes and animate accordingly. Using the normal state tracking mechanism also means that interruption mid-animations are gracefully handled for us.

One more trick

At this stage, I won’t go over every details of the individual animation definitions, they all tweak standard things like alpha and rotation on each piece of our stage. Nonetheless, you can read my animated vector drawable entry for more details on how they work.

I will only show a little trick that is useful when setting up more complex stages like this: zero-duration animators.

Take the following example that animates the bottom-half donut (to create the progressive hiding effect):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?xml version="1.0" encoding="UTF-8" ?>
<set xmlns:android="http://schemas.android.com/apk/res/android"
	android:ordering="sequentially">
	<objectAnimator
		android:duration="850"
		android:propertyName="rotation"
		android:valueFrom="0"
		android:valueTo="180"
		android:valueType="floatType"
		android:interpolator="@android:interpolator/decelerate_quad" />
	<objectAnimator
		android:duration="0"
		android:propertyName="rotation"
		android:valueFrom="-180"
		android:valueTo="0"
		android:valueType="floatType" />
</set>

The idea is that right after we have covered the entire upper-half, we want to immediately tuck it back under our hiding rectangle. This is because we then fade-in the new time symbol which would be hidden too otherwise.

Using zero-duration animators allow you to do just that by applying direct values to animated properties. The fact that there is a from attribute doesn’t matter much but since those properties are write only it will prevent object animator from complaining about missing accessors.

I use this in a couple of places to reset the stage state (since vector drawable instances are reused across transitions), quickly move away elements or hide them from view when they are not useful anymore.

Source

You can download the XML definitions and widget source here.

Bug alert: there is currently a parsing bug where the animated vector drawable inflater will greedily read the entire document given to it. This causes an issue if you declare them inline in your animated state transition XML file because it will corrupt your entire state by reading everything instead of stopping at its corresponding end tag. The workaround is to always declare them in their own XML files like I did.

It’s something everybody does at least once, if not everywhere, in his app which is loading and transitioning images.

Now to make this more glamour we generally all went with the classical, battle-tested approach of shifting the opacity of our image container to announce the change (that was even one of my first Android tip).

But the new approach taken by Material and detailed in the “Loading Images” section goes a lot further than this by also throwing some image levels manipulation in the mix.

The process is summarized in the following graph:

It outlines a 3-steps process where a combination of opacity, contrast/luminosity and saturation is used in concert to help salvage our poor users eyesight.

Android has always supported image manipulation through the ColorFilter class that can be set on any drawable and on some view classes (ImageView for instance).

When used with its 4x5 ColorMatrix-based implementation ColorMatrixColorFilter, you can virtually implement any kind of image transformation provided you grok the way vector/matrix multiplication work (head to the ColorMatrix documentation for the resulting equations).

The only thing that was a limiting factor is that a filter is initialized once and for all. If you want to change the effect you need to create a new instance of the filter (which initialize a native counterpart) and replace the old version with the new one.

Obviously this is a complete downer when you do animations because you don’t want to stress out the GC and GPU during those phases by creating a new instance of the filter at every refresh step.

But thanks to Lollipop and the fact that @hide can’t stop us, there is actually a new public method allowing us to update a filter after the fact.

Armed with this knowledge, we can now set out to create a custom ITypeEvaluator to tweak our filter:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

// Refer to http://developer.android.com/reference/android/graphics/ColorMatrix.html
// for a list of the matrix indexes
class AlphaSatColorMatrixEvaluator : Java.Lang.Object, ITypeEvaluator
{
	ColorMatrix colorMatrix = new ColorMatrix ();
	float[] elements = new float[20];

	public ColorMatrix ColorMatrix {
		get { return colorMatrix; }
	}

	public Java.Lang.Object Evaluate (float fraction, Java.Lang.Object startValue, Java.Lang.Object endValue)
	{
		// There are 3 phases so we multiply fraction by that amount
		var phase = fraction * 3;

		// Compute the alpha change over period [0, 2]
		var alpha = Math.Min (phase, 2f) / 2f;
		elements [19] = (float)Math.Round (alpha * 255);

		// We substract to make the picture look darker, it will automatically clamp
		// This is spread over period [0, 2.5]
		const int MaxBlacker = 100;
		var blackening = (float)Math.Round ((1 - Math.Min (phase, 2.5f) / 2.5f) * MaxBlacker);
		elements [4] = elements [9] = elements [14] = -blackening;

		// Finally we desaturate over [0, 3], taken from ColorMatrix.SetSaturation
		float invSat = 1 - Math.Max (0.2f, fraction);
		float R = 0.213f * invSat;
		float G = 0.715f * invSat;
		float B = 0.072f * invSat;

		elements[0] = R + fraction; elements[1] = G;            elements[2] = B;
		elements[5] = R;            elements[6] = G + fraction; elements[7] = B;
		elements[10] = R;           elements[11] = G;           elements[12] = B + fraction;

		colorMatrix.Set (elements);
		return colorMatrix;
	}
}

Here is how you can set it up:

1
2
3
4
5
6
7
8
9
10
11
12

var imageView = FindViewById<ImageView> (Resource.Id.image);
var drawable = (BitmapDrawable)Resources.GetDrawable (Resource.Drawable.monkey);
var evaluator = new AlphaSatColorMatrixEvaluator ();
var filter = new ColorMatrixColorFilter (evaluator.ColorMatrix);
drawable.SetColorFilter (filter);

var animator = ObjectAnimator.OfObject (filter, "colorMatrix", evaluator,
                                        evaluator.ColorMatrix,
                                        evaluator.ColorMatrix);
animator.Update += (sender, e) => drawable.SetColorFilter (filter);
animator.SetDuration (2500);
animator.Start ();

And here is the result:

It’s probably safe to assume Google will come out with an official way for this pattern e.g. in a subsequent support library update. In the meantime, you can get cracking with this version.

One such aspect that I was highly skeptical of until very recently was the concept of animated transition.

We actually talked about this during our Material Design Evolve session with James and at the time of that talk, the only facility we had been given to do it was by keyframe animations which is incredibly clunky to maintain.

Meet our new private implementation friend, PathDataEvaluator.

This evaluator is able to understand the path definition used by vector drawable and create intermediary versions of it.

This means that given two specific path of a vector drawable, we can use an object animator to, not only animate transformation or style like we have seen before, but also the actual pathData of the vector itself.

Now before you get too excited, it’s not a miracle evaluator. There are two very strong requirements for it to work properly:

• The path command list needs to be of the same size
• Each command in that list needs to be of the same type

Basically, the evaluator treats the path data as an array of float extracted from each command parameters and use that to interpolate inbetweeners.

This essentially mean that when crafting your paths, you may need to get a bit creative in the amount of nodes you use in order to make those requirements fit.

As an example, this is what we are going to make:

Intuitively, based on our previously mentioned requirements, we can see there is already fundamental problem when we think of alternating between a standard play icon and a standard pause icon: they don’t have the same amounts of subparts (2 rectangles for pause, 1 triangle for play).

In addition, the pause icon rectangles necessitate 4 control points for each subpart whereas the triangle of the play icon only requires 3.

That’s where the tweaking part comes in, following are how I created those shapes in my editor to solve both issues (nodes handles are highlighted):

The work was actually focused on the play icon by first separating the triangle shape in two right sub-triangles and then adding a (normally unnecessary) extra node onto its hypotenuse.

Each node is also numbered as the order in which the path is drawn has an impact on the look and feel of the animation. With those numbers, you can visualize in your head how the nodes are going to move across the canvas to alternate between the two shapes.

Without further ado, here are the vector drawables we are using:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<!-- In your strings.xml file -->
<resources>
	<string name="pause_vector_path">M12,10L20,10L20,38L12,38ZM28,10L36,10L36,38L28,38Z</string>
	<string name="play_vector_path">M16,24L38,24L27.3,30.8L16,38ZM16,10L27.3,17.2L38,24L16,24Z</string>
</resources>

<!-- Resources\drawable\ic_play.xml -->
<vector xmlns:android="http://schemas.android.com/apk/res/android"
	android:height="48dp"
	android:width="48dp"
	android:viewportHeight="48"
	android:viewportWidth="48">
	<group>
		<path android:name="d"
			android:fillColor="@color/white_primary"
			android:pathData="@string/play_vector_path" />
	</group>
</vector>

<!-- Resources\drawable\ic_play.xml is identical except
     replace pathData with the second string resource -->

The path data themselves are stored as a string resources. This makes it easier to use them in different places without having to copy and paste the entire thing.

Notice also how my commands are ordered (M stands for moveto and L for lineto) to reflect what the editor diagram showed and also how each command type maps to the same command type between the two definitions.

Since we want to create a transition we need a container for this that handle state using the Android standard state tracking mechanism. This type of container is called a state-list and, as we already covered in the Evolve video above, we now also have an equivalent version that supports animated transition between state: AnimatedStateListDrawable.

Here is my definition for the play/pause button state (based on the state_checked presence):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<animated-selector xmlns:android="http://schemas.android.com/apk/res/android"
    android:constantSize="true">
    <item
        android:drawable="@drawable/ic_pause"
        android:state_checked="true"
        android:id="@+id/pause_state" />
    <item
        android:drawable="@drawable/ic_play"
        android:id="@+id/play_state" />
	<transition android:fromId="@id/play_state" android:toId="@id/pause_state" android:reversible="true">
		<animated-vector android:drawable="@drawable/ic_play">
			<target android:name="d" android:animation="@anim/play_pause" />
		</animated-vector>
	</transition>
</animated-selector>

You can watch the Evolve video again for a longer explaination of how this works but essentially we are now naming our various <item /> elements with an id so that we can reference them for animation in <transition /> blocks.

Inside the transition, you’ll find our known companion AnimatedVectorDrawable referencing this object animator definition:

1
2
3
4
5
6
7

<!-- Resource\anim\play_pause.xml -->
<objectAnimator xmlns:android="http://schemas.android.com/apk/res/android"
	android:duration="250"
	android:propertyName="pathData"
	android:valueFrom="@string/play_vector_path"
	android:valueTo="@string/pause_vector_path"
	android:valueType="pathType" />

Key aspect is the valueType attribute that is set to pathType (the only actual way to can reference the non-public PathDataEvaluator class) and the property name set to pathData to change the corresponding member in the vector drawable. For the rest, you can tweak this like any other animator.

Last piece is to show this transition in something. The default Android framework offers a CheckedTextView for those cases but no CheckedImageButton (because using Checkbox can in some occasions result int a bit of pain with positioning). It’s easy to implement though:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

public class CheckedImageButton : ImageButton, ICheckable
{
	static readonly int[] CheckedStateSet = {
		Android.Resource.Attribute.StateChecked
	};
	bool chked;

	// Add standard constructors

	public override bool PerformClick ()
	{
		Toggle ();
		return base.PerformClick ();
	}

	public void Toggle ()
	{
		Checked = !Checked;
	}

	public bool Checked {
		get {
			return chked;
		}
		set {
			chked = value;
			RefreshDrawableState ();
			Invalidate ();
		}
	}

	public override int[] OnCreateDrawableState (int extraSpace)
	{
		var drawableState = base.OnCreateDrawableState (extraSpace + 1);
		if (Checked)
			MergeDrawableStates (drawableState, CheckedStateSet);
		return drawableState;
	}
}

You can use this class and simply set the android:src attribute to the animated state-list drawable.

Also don’t forget to set the android:background of the button to use the theme value ?android:selectableItemBackgroundBorderless to get the nice ripple effect on touch.

To conclude, you can still use the keyframe approach when doing animated state-list transition if you actually want to invest the time crafting each intermediary state maybe because it does a complex movement that can’t be naively interpolated.

But if you don’t need to, we now have an easy, fast and cumberless way to create beautiful state transitions using vector drawables.

In and by itself this is already a very powerful new addition. But to see what else we can do with this, let’s reuse the vector drawable example from the previous post:

1
2
3
4
5
6
7
8
9
10
11

<vector xmlns:android="http://schemas.android.com/apk/res/android"
	android:height="96dp"
	android:width="96dp"
	android:viewportHeight="48"
	android:viewportWidth="48" >
	<group>
		<path
			android:fillColor="@color/black_primary"
			android:pathData="M12 36l17-12-17-12v24zm20-24v24h4V12h-4z" />
	</group>
</vector>

I didn’t touch on it at the time but you may have noticed that our path element is actually contained inside another element called a group.

For the sake of displaying vector drawable, this is not a very interesting element. Now if I paste below the list of other attributes you can set on <group/>, you should see something emerging:

Extra group attributes

rotation, scaleX, scaleY, translateX, translateY.

You will have surely recognized those are the same attributes we use to manipulate our View instances when animating them.

Enter, Animated Vector Drawable.

Animated Vector Drawables are actually more of a meta-type bridging several other pieces together much like a State List Drawable (and like the later, they also are drawables themselves).

Here is an example of an animated vector drawable that we will use later on (also stored in your drawable resource folder):

1
2
3
4
5
6
7
8
9

<animated-vector xmlns:android="http://schemas.android.com/apk/res/android"
	android:drawable="@drawable/bluetooth_loading_vector" >
	<target
		android:name="circleGroup"
		android:animation="@anim/circle_expand" />
	<target
		android:name="circlePath"
		android:animation="@anim/circle_path" />
</animated-vector>

Animated Vector Drawables are declared using the <animated-vector/> element. The first thing you need to tie in is which vector drawable the animated version is going to use as a base, this is set in the android:drawable attribute at the top level.

The rest of the file contains a bunch of different <target/> elements, those are where we are going to set up which animations are ran and on what part of the vector drawable they will be ran.

But first, here is the definition of the bluetooth_loading_vector referenced in the animated vector:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

<?xml version="1.0" encoding="utf-8" ?>
<vector xmlns:android="http://schemas.android.com/apk/res/android"
	android:height="64dp"
	android:width="64dp"
	android:viewportHeight="192"
	android:viewportWidth="192" >
	<group>
		<path
			android:fillColor="@color/vector_foreground_color"
			android:pathData="M87.3996,113.161L85.3665,112.191L85.3665,23.517L87.3996,22.5479L143.293,67.8542L87.3996,113.161ZM99.9498,84.2151L120.134,67.8542L99.9498,51.4934L99.9498,84.2151Z" />
		<path
			android:fillColor="@color/vector_foreground_color"
			android:pathData="M87.4147,169.459L85.3665,168.484L85.3665,79.6589L87.4147,78.684L143.277,124.071L87.4147,169.459ZM99.9498,140.484L120.15,124.071L99.9498,107.659L99.9498,140.484Z" />
		<path
			android:fillColor="@color/vector_foreground_color"
			android:pathData="M43.8495,129.345L103.262,81.2217L112.186,92.2392L52.7734,140.362L43.8495,129.345Z" />
		<path
			android:fillColor="@color/vector_foreground_color"
			android:pathData="M43.8495,62.2562L103.262,110.379L112.186,99.3616L52.7734,51.2387L43.8495,62.2562Z" />
	</group>
	<group
		android:name="circleGroup"
		android:pivotX="96.0"
		android:pivotY="96.0"
		android:rotation="0">
		<path
			android:name="circlePath"
			android:strokeColor="@color/vector_foreground_color"
			android:strokeWidth="16"
			android:strokeAlpha="1"
			android:trimPathEnd="0.7"
			android:pathData="M96,5.56405C145.946,5.56405 186.436,46.0536 186.436,96C186.436,145.946 145.946,186.436 96,186.436C46.0536,186.436 5.56405,145.946 5.56405,96C5.56405,46.0536 46.0536,5.56405 96,5.56405Z" />
	</group>
</vector>

And what it looks like when rasterized:

This vector drawble is a bit longer than the previous one, but there are two main things to notice:

• The drawable is arranged in two distinct groups
• One group and one path have a name attached, mapping back to the animated vector’s target elements

The way we have layed-out and named our vector drawable means we can now directly reference the relevant parts we want to manipulate.

For instance in our case, we are only interested in the ring around the Bluetooth logo which is why only this piece is actually named in our vector drawable.

To close the loop (so to speak), here are the two animation definition files referenced by the animated vector drawable (placed each in your anim resource folder):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

<!-- Resources\anim\circle_expand.xml -->
<set xmlns:android="http://schemas.android.com/apk/res/android">
	<objectAnimator
		android:duration="@integer/loading_anim_time"
		android:propertyName="scaleX"
		android:valueFrom="1.0"
		android:valueTo="2.5"
		android:valueType="floatType"
		android:repeatCount="-1" />
	<objectAnimator
		android:duration="@integer/loading_anim_time"
		android:propertyName="scaleY"
		android:valueFrom="1.0"
		android:valueTo="2.5"
		android:valueType="floatType"
		android:repeatCount="-1" />
	<objectAnimator
		android:duration="@integer/loading_anim_time"
		android:propertyName="rotation"
		android:valueFrom="0"
		android:valueTo="360"
		android:valueType="floatType"
		android:repeatCount="-1" />
</set>

<!-- Resources\anim\circle_path.xml -->
<set xmlns:android="http://schemas.android.com/apk/res/android">
	<objectAnimator
		android:duration="@integer/loading_anim_time"
		android:propertyName="trimPathEnd"
		android:valueFrom="0"
		android:valueTo="1"
		android:valueType="floatType"
		android:repeatCount="-1" />
	<objectAnimator
		android:duration="@integer/loading_anim_time"
		android:propertyName="strokeAlpha"
		android:valueFrom="1"
		android:valueTo="0"
		android:valueType="floatType"
		android:repeatCount="-1" />
</set>

Since this is meant as a continous animation, we must ensure that the repeat count of each animator is -1 (a synonym for ‘infinite’) so that the process runs forever.

In the remaning bits, we are simply animating a bunch of property on both the group (for transformations) and on the path (for the stroke style) like we would on a normal view.

The last thing to do is load the animated vector drawable into a continuously animating View, typically a ProgressBar:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<FrameLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="?android:attr/colorPrimary"
    android:padding="48dp"
    android:clipChildren="false"
    android:clipToPadding="false">
    <ProgressBar
        android:indeterminate="true"
        android:indeterminateDrawable="@drawable/animated_bluetooth_loading"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center" />
</FrameLayout>

And we arrive at this result:

Next up, we will see how we can apply some of this to make terrific transitions.

In the first, I produce sequences of meaningul characters for a virtual machine in your favorite IDE, Xamarin Studio. In the second, I use my best friend Inkscape (and lately also Affinity) to help me think, iterate and produce the front face of my app.

The main challenge of this form of development is to find the best way to ease the content transition between both worlds.

In Android, what’s essentially the apocalypse of screen form-factor makes it particularily painful to work with that visual assets part of your app.

Where the world was happily spread between ldpi, mdpi and hdpi a few years back, today we just don’t know how many ‘x’ we are going to be able to fit in front of ‘hdpi’ (at the time of this writing we reached xxxhdpi).

I have actually already talked about this subject and, at the time, released my own library to try to tackle this issue.

But today we can finally rejoice as Google gave developers a blessed way to create unlimited scalable graphics with the recent release of Lollipop (or Android 5.0).

This new types of drawable is unoriginaly called Vector Drawables and, as with any other drawable, they are natively understood by the Android toolchain which make their use as seamless as feasible (i.e. you can reference them in layouts, styles, acquire them through Resources.GetDrawable, …).

This is an example of a vector drawable (store them in your Resources/drawable folder):

1
2
3
4
5
6
7
8
9
10
11
12

<?xml version="1.0" encoding="utf-8" ?>
<vector xmlns:android="http://schemas.android.com/apk/res/android"
	android:height="96dp"
	android:width="96dp"
	android:viewportHeight="48"
	android:viewportWidth="48" >
	<group>
		<path
			android:fillColor="@color/black_primary"
			android:pathData="M12 36l17-12-17-12v24zm20-24v24h4V12h-4z" />
	</group>
</vector>

Which draws this well known media player action icon:

The beef of a vector drawable is in its various <path/> elements and more precisely its pathData attribute. As arcane as it may look, it actually defines the full blown shape of the icon in the very concise SVG Path data format.

Don’t worry too much though, you won’t have to write that down by yourself (you may need to tweak it though for more funky things but more on that in a later post).

Since it’s based on the same specification than used in SVG itself, as long as you can grab a SVG version of your graphic you will directly be able to copy and paste it into a vector drawable XML.

As a matter of fact, the icon example that I pasted above came from Google’s official material design icon pack which also contains SVG for every icon:

1
2
3

<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48" viewBox="0 0 48 48">
    <path d="M12 36l17-12-17-12v24zm20-24v24h4V12h-4z"/>
</svg>

Notice also how the viewportHeight and viewportWidth values in the vector drawable reflect what’s in the width/height/viewBox parameter of the SVG. As long as those values are correctly defined, you can play with the android:width and android:height part of your drawable the way you want.

Together with the new general tinting facility in Lollipop, you can now iterate over your assets even faster without leaving your IDE and without having to re-generate 6 variants of your graphics.

Her name is Andrea Magnorsky.

Andrea is an Irish .NET programmer. She’s currently following one of her passion – game development – and is closing production with her studio Digital Furnace (ex-BatCat) on their next title Onikira.

To say that Andrea is a community person is an understatement. In the span of a few years she has not only created popular event/group like Global Gamecraft (game jam contest) or Dublin ALT.NET but she is also continously looking for new ways to teach people through numerous talks and meetups like Functional Kats.

She is curious of everything and always avid to learn. These days you can see her sailing along with F# and functional programming for instance.

It’s no surprise that she was recognized several times in Ireland as a top person in her field. Microsoft also recently awarded her an MVP award.

It’s thanks to people like Andrea that I’m happy to be part of the community that is software development.

Muncho would have loved to conclude this but he had another emergency

Being a mobile conference, we of course made our own app so that attendees could track out the sessions and the geography of the event.

We also launched something a bit different in the form of a treasure hunt app. Thanks to Estimote, we used a combination of iBeacon and QR codes spread throughout the conference intertwined with challenges along the way until you reach the end of the quest and a special prize.

The main interface of that quest app is a serie of connected dots:

As you progress through the game, the content scrolls naturally to reveal more odd-shaped arrangement of those dots.

Originally, this screen was just a big tall image containing everything. This is suboptimal on Android for a couple of reason like some graphic chip not supporting big “texture” or simply the need to rescale at runtime on most screen.

Ultimately it’s also not fun because there is really nothing you can do with a big image.

Hint: this is NOT what we shipped (on Android at least).

Rather, what attendees could see on their Android phone at the conference was this:

A much more satisfying, softly animated, connected system of dots. The current game position is also highlighted with a discrete pulse.

We will open-source the entire Quest application at some point but I wanted to share how we did that specific bit that is entirely exclusive to Android.

▸ View Source Code

Since this is a really custom animation, it’s a bit different than the other type of animation samples I have already shown.

For this type of thing, I usually rely on a very simple animator that gives me a floating value between 0 and 1 so that I can do my own tweening in code. I also manage to pass this value by hijacking one of the standard view animatable property so that I don’t need to expose more information to the Java bridge:

1
2
3
4
5
6
7
8
9
10
11
12
13

// Interpolator instantiation
shiverAnimator = ObjectAnimator.OfFloat (this, "scaleX", 0, 1);
shiverAnimator.RepeatCount = ValueAnimator.Infinite;
shiverAnimator.AnimationRepeat += (sender, e) => shiverIndex++;

// Property hijack
public override float ScaleX {
	get { return currentShiverInterpolation; }
	set {
		currentShiverInterpolation = value;
		Invalidate ();
	}
}

In our case, I then use this value to compute for each drawing pass an offset that is added to the base position of every dots:

1
2
3
4
5
6
7
8
9
10
11

// Expressed in dp units
int[] shiverOffsets = new[] { 9, 3, -8, 4, -7, 6 };

// Extra applied offset code
int ApplyShivering (int dotIndex, int value)
{
	var off = shiverOffsets [(dotIndex + shiverIndex) % shiverOffsets.Length]
		* currentShiverInterpolation;
	value += (int)Math.Round (off);
	return value;
}

The wave that you see on the highlighted pin comes from a GradientDrawable that I create from a shape drawable XML definition as follow:

1
2
3
4
5
6
7

<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android"
	android:shape="ring"
	android:useLevel="false"
	android:innerRadiusRatio="2">
	<solid android:color="#99ffffff" />
</shape>

The reason for using a drawable like this is to avoid redoing common drawing code and also taking advantage of the ring shape type automatic radius scaling (notice the innerRadiusRatio attribute) to create a nice spreading effect as the ring grows larger.

The ring size and color is dynamically computed from a slightly interpolated (quadratic or accelerated) value coming from our shared shiver interpolator:

1
2
3
4
5
6
7
8
9
10
11

var dur = shiverAnimator.Duration / 4;
var fraction = (float)(shiverAnimator.CurrentPlayTime % dur) / dur;
// Cheap interpolation
fraction *= fraction;

var rippleRad = (int)(radius * (5 * fraction + 1)) - 8;
ripple.SetBounds (x - rippleRad, y - rippleRad, x + rippleRad, y + rippleRad);

var color = Color.Argb ((int)Math.Round (0x99 * (1 - fraction)),
                        0xFF, 0xFF, 0xFF);
((GradientDrawable)ripple).SetColor (color.ToArgb ());

If you have been to my Mastering Time and Space session, you’ll likely also have detected the presence of a custom interpolator in there that is set on the shared shivering animator. The code is following:

1
2
3
4
5
6
7
8

class TriangleWave : Java.Lang.Object, ITimeInterpolator
{
	public float GetInterpolation (float input)
	{
		var t = input * 2;
		return (float)(2 * Math.Abs (t - Math.Floor (t + 0.5)) * (1 - 2 * Math.Floor (t)));
	}
}

This interpolator generates a triangle pattern that is repeatable (i.e. it both starts and ends at the same position for the dot) so that the animation can run continuously:

I just officially added Android Wear support in the shipped version of Moyeu, my Hubway (Boston’s bike sharing system) app for Android.

As usual, the code is available in my GitHub repository and you can grab it from Google Play.

It’s an example of what’s possible to achieve today with our Xamarin.Android Wear support and Google’s Wearable UI library. Feel free to reuse as you see fit.

This eerie light comes from our designer pole, an experiment I did to provide cheap feedback over our build status in our continuous integration system:

The setup is based around 3 main components: a Raspberry Pi, a 5V relay module board and a basic 12V RGB LED strip. You can buy all those parts directly from Amazon for about $112 total (of which $77 was for a premium Raspberry Pi package but it’s up to you).

No matter the RGB LED strip “brand” you end up buying (it all seems to be from the same generic supplier), the wiring is pretty simple and consist of a common ground and a wire for each color channel (red, green, blue) so 4 wires in total.

Thus in the simplest form we can very easily turn on and off those channels using a bunch of relays. Each build status (success, test failure and build failure) will be mapped to a specific color (green, blue, red respectively).

A relay is the basic building block to control a power circuit (the 12V DC from the LED strip power adapter) from a control circuit (the 3.3V DC of the Raspberry Pi). There are a bunch of different designs available (magnetic, solid state, …) depending on the amount of power you are controlling. For this type of setup pretty much anything should work (it’s just LEDs after all).

Those relays are then mounted on a board like the one in the picture to conveniently expose a control interface that you can plug to your Raspberry Pi GPIO ports. That’s the final product you can buy (unless you want to do your own PCB).

Below is a close-up of the wiring between all the different pieces, the GPIO ports are exported to the breadboard and then connected onto the relay module control circuit.

I also made a more schematic version so that you can see which GPIO ports are used:

The common of the LED strip (the white cable) is connected directly to the power source (we don’t care about controlling it). All the other color wires go in and out of their own relay.

If you are short on connectors, you may have noticed a little trick I use which is to go scavenge your old computers for IDE connectors (what you used to plug your old harddrive, floppy disk readers and the likes). They fit perfectly well and have the same type of wire that standard Dupont cables.

Below is the part of the code that controls the relay module to turn on and off the LEDs:

using System;
using System.Threading;
using RaspberryPiDotNet;

namespace WrenchBerry
{
	public static class Ledder
	{
		public enum Color {
			Green,
			Orange,
			Red
		}

		static GPIOPins[] pinMapping = new GPIOPins[] {
			GPIOPins.V2_GPIO_17,
			GPIOPins.V2_GPIO_27,
			GPIOPins.V2_GPIO_22,
		};

		public static void FlashLed (Color color, int times = 3)
		{
			var pin = pinMapping [(int)color];
			for (int i = 0; i < times; i++) {
				GPIO.Write (pin, true);
				Thread.Sleep (500);
				GPIO.Write (pin, false);
				Thread.Sleep (500);
			}
		}

		public static void TurnOn (Color color)
		{
			var pin = pinMapping [(int)color];
			GPIO.Write (pin, false);
		}

		public static void TurnAllColorOff ()
		{
			foreach (var pin in pinMapping)
				GPIO.Write (pin, true);
		}
	}
}

The code use the RaspberryPi.Net library to directly access the chip memory controlling the GPIO pins.

The main program is then a super-simplistic infinite loop over the CI results:

using System;
using System.IO;
using System.Linq;

namespace WrenchBerry
{
	class MainClass
	{
		const Ledder.Color NoColor = (Ledder.Color)(-1);
		static Ledder.Color currentColor = NoColor;

		public static void Main (string[] args)
		{
			var lane = args [0];

			while (true) {
				try {
					var builds = CISystem.GetStateListFromLane (lane);
					if (builds == null || builds.Length == 0 || !builds.Any (IsFinishedState)) {
					    Console.WriteLine ("Lane or fetching is fucked up");
					    return;
					}
					var firstBuilt = builds.First (IsFinishedState);
					Console.WriteLine (DateTime.Now.ToString ("u") + " - " + firstBuilt);

					Ledder.Color color = GetColorForState (firstBuilt);

					if (color != NoColor && currentColor != color) {
					    Ledder.TurnAllColorOff ();
					    Ledder.FlashLed (color);
					    Ledder.TurnOn (color);
					}
					currentColor = color;
				} catch (Exception e) {
					Console.WriteLine (e);
				}

				System.Threading.Thread.Sleep ((int)TimeSpan.FromMinutes (2).TotalMilliseconds);
			}
		}

		static Ledder.Color GetColorForState (DBState state)
		{
			Ledder.Color color = NoColor;
			switch (state) {
			case DBState.Failed:
				color = Ledder.Color.Red;
				break;
			case DBState.Issues:
				color = Ledder.Color.Orange;
				break;
			case DBState.Success:
				color = Ledder.Color.Green;
				break;
			}
			return color;
		}

		static bool IsFinishedState (DBState state)
		{
			return state == DBState.Failed || state == DBState.Issues || state == DBState.Success;
		}
	}
}

All that’s left to do is to make yourself a nice little storage area and, why not, spice up the system a little bit. For instance in our setup (pictured below) I also hooked up a small speaker.

As an example our current playlist consist of: the Imperial March (build failure), Mass Effect Reaper sound (test failure) and, last but not least, our friend He-Man (build success).

Happy (hardware) hacking!

It also has the nice property that, knowing the scroll extents, it’s very easy to infer a floating ratio (i.e. a value between 0 and 1) from a given intermediary scroll state.

This last property makes scrolling very similar to animations, replacing the need for a time-based interpolator by this scroll-state inferred value.

In addition, since scroll events are generally triggered in response to a continuous user action, those intermediates values can be used to implement nifty navigation effects.

I have already talked about one of such effect earlier, the infamous parallax, that a lot of people are already using but there is much more opportunities around.

In the last release of my pet app Bikr for instance, I added a new statistics screen:

As is common in Android land, the navigation is implemented using ActionBar’s tabs at the top of the screen. This is coupled with a ViewPager instance as the root fragment layout so that screens can be accessed both by swiping and by tabs selection.

The statistics panel itself consists of a subclass of ScrollView that snaps to each of its subsection scroll offset to display multiple sub-pages.

Since both of those elements can generate scroll states, the rest of the UI take advantage of it by dynamically refreshing itself based on those value changes.

For the ViewPager for example, the tab icons are progressively made more transparent or opaque. The overall gradient background is also subtly inverted to influence the reading direction of the user upwards instead of downwards:

View Code

The scroll information of the statistics ScrollView is linked to a custom scrollbar knob that is aligned to the subsection title. I use the intermediary scroll values in that case to both infer the knob vertical position and dynamically adjust its size:

View Code: Event - Drawing

Right from the start the development motto was that the app should be as simple and straightforward as the problem it solves: keeping track of users rides without needing their input.

This lead to a very clean UI with no apparent settings and interaction requirements kept to a bare minimum while still making it a delightful experience.

In the rest of this post I’m going to show you some UI tidbits that got implemented in Bikr as a result.

On-boarding

▸ View Source Code

As I mentioned in the introduction, the need for user involvement was voluntarily maintained low as the whole experience is supposed to be automatic.

As a matter of fact, the only actionable element of the entire main UI is the switch at the top-right of the screen that enable or disable globally the service.

This gave me the inspiration for this on-boarding:

The idea is to overlay on top of our main UI that same switch with a short explanation text and let the user initializes himself the service before being able to proceed further.

The effect is implemented by using Android view caching mechanism, retrieving the composited top-most bitmap and using Renderscript to blur the image as a background much like I described in this article.

Tank Filling Animation

▸ View Source Code

When the app starts, each circle fills out to show you how far you are in reaching the same level than the previous day, week or month (accordingly).

When thinking about it I almost right away draw a parallel between this and filling a container with water.

This animation thus reproduce the familiar bubbling at the surface of a liquid when poured rapidly:

I use a sine function to distribute the bubbles uniformly across the vertical top band of the liquid and then animate them to grow out and “burst” at the surface as they get closer to the top.

Wave Simulation

▸ View Source Code

Although the circles are not actual actionable items, when showing the app to friends they would unconsciously reach and try to interact with them.

In the spirit of rewarding the user for experimentation and not unsettling them, the water analogy is continued here by implementing a simple wave simulation that generates ripples where the user is tapping.

I also use a nice springy touch feedback that will influence the force of the final ripple to give even more touch satisfaction:

The simulation algorithm itself is based on the work of Matthias Müller.

It’s a no fuss, down to fundamental app that records how many miles you cycle and gives you a roundup per day, week and month. It will also show how you compare with the previous corresponding metrics (i.e. yesterday, previous week, previous month).

Best of all is that you don’t have to do anything. Thanks to Google Activity Recognition APIs, the app will take care of itself meaning you can just bike and forget about it.

The app is built using Xamarin as you would expect and you can find the entire source code at garuma/bikr on GitHub. As usual, code is under the Apache 2.0 license which basically mean you can reuse whatever you want.

It’s also available for download on the Play Store.

This is a joint release with James Montemagno’s MyStepCounter Android app, check it out too!

The idea is basically that the closer an object is to you, the faster it seems to move to your eyes. The extreme being the background (like distant mountains) which doesn’t seem to move at all.

This effect, called Parallax, is used proficiently on iOS and Android launchers when scrolling through your apps to make it look like your wallpaper is further away from your icons as they move.

We can re-create parallax pretty easily on Android using the ViewPager class of the support package as a foundation for handling the touch events and displaying our content.

Our goal here is to create an awesome on-boarding screen to present your app. Each “slides” will have its own background and a couple of visual elements (text, device frame, other widgets) that will be arranged in different virtual layer (i.e. some will move faster than others).

Check out an example below of such a screen and the slightly different position offsets applied to each elements:

The core idea is to setup a ViewPager taking up all the screen space (you can even use the new KitKat translucent window chrome like in the screencast with the Holo.*.NoActionBar.Translucent style) and then create a generic FrameLayout-based layout (remember how FrameLayout is your friend?) for the page. You don’t need to add an ImageView for the background since we will directly use the background property of the FrameLayout.

It’s also not necessary to have pre-scaled those background images since setting them as the background drawable of the main FrameLayout will automatically make them fit but it’s better if their dimensions are close to the form factor of the device (16/9 portrait usually) so that they don’t appear squashed (if you want to get fancy you might want to dynamically blur those too).

Afterwards, just sprinkle the layout with TextView, ImageView or whatever other view you may want to showcase your app using the layout_gravity and layout_margin attributes to align them on the screen. Here is the example, very dumb, layout I’m using for the demo:

<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:id="@+id/backgroundFrame"
    android:background="@drawable/onboarding_bg_1">
    <TextView
        android:text="A Big Title About Something"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:id="@+id/bigTitle"
        android:layout_gravity="center_horizontal|top"
        android:layout_marginTop="64dp"
        android:textColor="#ffffffff"
        android:textSize="24sp"
        android:shadowColor="#ff000000"
        android:shadowDx="0"
        android:shadowDy="1"
        android:shadowRadius="0.5" />
    <TextView
        android:text="A Subtitle About the Thing"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:id="@+id/bigSubtitle"
        android:layout_gravity="center_horizontal|bottom"
        android:layout_marginBottom="64dp"
        android:textColor="#ffffffff"
        android:textSize="20sp"
        android:shadowColor="#ff000000"
        android:shadowDx="0"
        android:shadowDy="1"
        android:shadowRadius="0.5" />
    <ImageView
        android:src="@android:drawable/ic_menu_gallery"
        android:layout_width="200dp"
        android:layout_height="300dp"
        android:id="@+id/centerImage"
        android:layout_gravity="center" />
</FrameLayout>

Once you have wired your ViewPager with an Adapter feeding the right content, we are going to create a PageTransformer which is where the parallax magic is gonna be created. Implementing this interface requires only one method which is called for every scroll offset of a given page View together with a value indicating its position relative to the center of the screen.

That relative position is very handy because it’s clamped between -1 (left of the screen) and +1 (right of the screen) with the zero value in the middle. That means we can derive a very simple parallax equation based on its value:

public class OnBoardingPageTransformer : Java.Lang.Object, ViewPager.IPageTransformer
{
	float parallaxCoefficient;
	float distanceCoefficient;
	IEnumerable<int>[] viewLayers;

	public OnBoardingPageTransformer (float parallaxCoefficient,
	                                  float distanceCoefficient,
	                                  params IEnumerable<int>[] viewLayers)
	{
		this.parallaxCoefficient = parallaxCoefficient;
		this.distanceCoefficient = distanceCoefficient;
		this.viewLayers = viewLayers;
	}

	public void TransformPage (View page, float position)
	{
		float coefficient = page.Width * parallaxCoefficient;
		foreach (var layer in viewLayers) {
			foreach (var viewID in layer) {
				var v = page.FindViewById (viewID);
				if (v != null)
					v.TranslationX = coefficient * position;
			}
			coefficient *= distanceCoefficient;
		}
	}
}

The trick is then to have a way to define layers and then let the user supply a couple of arguments to parametrize the effect. In the above class, we achieve this by letting the user gives a list of view IDs for each layer they want to create. You can then set the instance on your ViewPager by calling the SetPageTransformer method.

As a final piece of information, know that this technique only work on Android 3.0+ because ViewPager assumes you are using animatable properties.

By default pages are laid out to span the entire surface of the pager. In our case what we want to do is something akin to how the search results in the Apple’s AppStore iPhone app are displayed, a card-like style with adjacent items slightly taking over the surface edges:

Getting this to work with the default ViewPager class is a bit tricky. We have basically to change 3 things:

• The global padding of the pager
• The spacing between each page
• The width of a single page

The first one might seem straightforward, you would just go and add both a android:paddingLeft and android:paddingRight onto the pager XML declaration. The problem is that by doing so, the clip rectangle is also moved by that same padding so it looks like the pages are cut in the middle of nowhere.

Fortunately, every ViewGroup subclass accept the android:clipToPadding attribute (doc) which allows to alter exactly that. By setting this one to false, the clip rect will remain equal to the container bounds but padding will still be taken into account during the layout phase.

The spacing between pages is a property settable on the pager itself, PageMargin (doc). This value should be about half the size of the left padding value.

Finally, to change the width of the pages, you override the GetPageWidth method of your PagerAdapter subclass (doc). The right value you use depends on the sizing you put beforehand so slightly tune it until you find the desired effect.

Applying those 3 techniques we arrive at the following result:

For reference sake, here are the XML and code used for that output:

<android.support.v4.view.ViewPager
  	android:id="@+id/pager"
  	android:gravity="center"
  	android:layout_width="match_parent"
  	android:layout_height="0px"
  	android:paddingLeft="24dp"
  	android:paddingRight="12dp"
  	android:layout_weight="1" />

var pager = view.FindViewById<ViewPager> (Resource.Id.pager);
pager.SetClipToPadding (false);
pager.PageMargin = 12.ToPixels ();
pager.Adapter = new MyPageAdapter (ChildFragmentManager);

class MyPageAdapter : FragmentStatePagerAdapter
{
	public override float GetPageWidth (int position)
	{
		return 0.93f;
	}
	
	// ...
}

The secret of FrameLayout is how it layouts its children. Although normally designed to contain one item, it will happily stack up other element on top of each other. Thus FrameLayout is essentially a way to manipulate the Z-order of views on the screen.

This is super useful for a couple of UI tricks from HUD-like elements to sliding panels to more complex animated transitions. In this post we will see an example for each of those.

Overlay Elements

As I mentioned, FrameLayout will automatically stacks its children on top of each other. This makes it really easy to implement overlay or HUD element in your interface.

The idea is to wrap the part of the UI into an outer FrameLayout instance. Generally this will be the root element of your layout. You can then add below the main layout definition the other elements you want to overlay.

These elements will generally have a fixed size or be set as wrap_content. You can then place them at the right position on screen using the layout_gravity and layout_margin XML attributes.

In the following screenshot, my main content is a Google Map view. I have then added two overlays above it, one that replicate a toast message (center-bottom corner) and a TextView displaying the last time the data was loaded (upper-right corner).

This is simply achieved with the following layout:

<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <!-- The main content -->
    <com.google.android.gms.maps.MapView
        android:id="@+id/map"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />
    <!-- "Loaded" flash bar layout -->
    <FrameLayout
        android:id="@+id/FlashBarLayout"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_horizontal|bottom"
        android:layout_marginBottom="72dp">
        <!-- flash bar content -->
    </FrameLayout>
    <!-- Last loaded time layout -->
    <TextView
        android:id="@+id/UpdateTimeText"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="top|right"
        android:layout_marginTop="4dp"
        android:layout_marginRight="4dp" />
</FrameLayout>

Being just normal views, you can manipulate the overlays as usual. For instance you will probably want to implement some sort of animations for transition between visibility states if the overlay is transient.

Sliding Panels

Sliding panels (aka drawers, aka fly-out menus) are the rage these days. They mainly consist of a panel that is placed, depending on the desired spatial effect, above or below another piece of content. Again this falls back to placing elements using a FrameLayout object.

The trick then is to use the translationX and translationY properties of the panel View to move the element back and forth.

Alternatively, View also exposes the OffsetTopAndBottom and OffsetLeftAndRight methods (working on display list directly) but those are not as easy to animate. Indeed, with the translation properties you can directly use ObjectAnimator or ViewPropertyAnimator.

The panel is initially “hidden” by setting its translationY property to its height (i.e. top side forced to the bottom of the screen). We create the initial appearing effect with the following code piece inside the panel class:

// As its name imply, this interpolator will let the view go slightly overboard
// and then spring it back to its place
var intp = new Android.Views.Animations.OvershootInterpolator ();
var d = Context.Resources.GetInteger (Android.Resource.Integer.ConfigMediumAnimTime);
// Only the header part of the view should be visible, we thus just make
// the bottom of the view translated off-screen
var tY = Height - FindViewById (Resource.Id.PaneHeaderView).Height;

this.Animate ().TranslationY (tY).SetDuration (d).SetInterpolator (intp).Start ();

A common idiom of those panel is also to draw a shadow on the edge where they meet the content. This can be implemented very efficiently by overriding the DispatchDraw method of the sliding panel View and drawing a black linear GradientDrawable at the right place (use the Translate method on Canvas for the right positioning).

protected override void DispatchDraw (Android.Graphics.Canvas canvas)
{
    base.DispatchDraw (canvas);
    if (shadowDrawable == null)
        shadowDrawable = new GradientDrawable (GradientDrawable.Orientation.BottomTop,
                                               new[] { Color.Argb (0x60, 0, 0, 0), Color.Argb (0, 0, 0, 0) });
    // The reserved area for the shadow is set with top padding on the view.
    shadowDrawable.SetBounds (0, 0, Width, PaddingTop);
    shadowDrawable.Draw (canvas);
}

Transitions

With the move to a Fragment world, everything becomes just another View to manage and thereby removing the need for Activity.

When you think about the different “screen” of you application as individual fragments it becomes very easy to manipulate them in fun ways. Notably, being just managed View objects, you can apply any of the animations techniques you are already familiar with to implement very nifty transition effects.

At the core of such system, you will find again the same idea of a central, expanded FrameLayout surface where your Fragment are added.

The idea is to pile the Fragment views on top of each other like a deck of card. The current screen is thus the first card of the pile and application transitions are then simply how you want the middle cards to be put on top.

I’m using this analogy of the card deck because the method we are going to use here is View.BringToFront. This method will move the view at the last position inside its parent array. The end result of that operation of course depends on the type of container but in the case of FrameLayout it will make the View be drawn on top.

Note that this method doesn’t force a relayout which is fine for FrameLayout since children individual bounds aren’t dependent on each other but in the case of e.g. LinearLayout you will have to call RequestLayout for the modification to happen.

We will assume the layout of our main Activity is a single full-size FrameLayout container. Our application is composed of two screens represented as two fragments.

Initially, we create and attach directly those fragments to our content frame, hiding the second one to get into an initial state:

FirstFragment fragment1;
SecondFragment fragment2;

Fragment currentFragment;

protected override void OnCreate (Bundle bundle)
{
	SetContentView (/* ... */);
	
	fragment1 = new FirstFragment (this);
	fragment2 = new SecondFragment (this);
	
	SupportFragmentManager.BeginTransation ()
		.Add (Resource.Id.content_frame, fragment2, SecondFragment.Name)
		.Hide (fragment2)
		.Add (Resource.Id.content_frame, fragment1, FirstFragment.Name)
		.Commit ();
	currentFragment = fragment1;
}

When we want to change the Fragment that is shown, we will make sure that both views are on top of the drawing pile with the current one being on top of the other using BringToFront. We then swap the two fragments in a FragmentTransaction:

void SwitchTo (Fragment fragment, string name)
{
	if (fragment.IsVisible)
		return;
	var t = SupportFragmentManager.BeginTransaction ();
	t.SetCustomAnimations (Resource.Animator.frag_slide_in,
	                       Resource.Animator.frag_slide_out);

	// Make sure the next view is below the current one
	fragment.View.BringToFront ();
	// And bring the current one to the very top
	currentFragment.View.BringToFront ();

	// Hide the current fragment
	t.Hide (currentFragment);
	t.Show (existingFragment);
	currentFragment = existingFragment;

	// You probably want to add the transaction to the backstack
	// so that user can use the back button
	t.AddToBackStack (null);
	t.Commit ();
}

To add a bit of woosh, we are using customs animations to mark the transition between the two fragments to get this result:

These animations need to be defined in an XML resource using either property animator (aka from Android.Animations) if you are using framework Fragment or using view animations (aka from Android.View.Animations) if you are using Fragment from the support package.

To register custom animations, we call the SetCustomAnimations method on FragmentTransaction like so:

t.SetCustomAnimations (Resource.Animator.frag_slide_in,
                       Resource.Animator.frag_slide_out);

The first animation will be run on any fragment added/attached/shown while the second animation will be played on fragments hidden/detached/removed. Both are ran at the same time but you can use the animation startOffset attribute to delay one or the other.

For instance in my example, my frag_slide_out animation is defined like so:

<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android"
     android:interpolator="@android:interpolator/accelerate_cubic">
   <translate
      android:fromXDelta="0"
      android:toXDelta="100%"
      android:duration="300" />
   <alpha
        android:fromAlpha="1.0"
        android:toAlpha="0.3"
        android:duration="300" />
</set>

Conclusion

Everything I have presented here is part of a big refresh to Moyeu. You can view the full source code on the GitHub repository at garuma/Moyeu.

This library is called XamSvg and in a nutshell it’s a managed (partial) implementation of an SVG parser/renderer for, currently only, Xamarin.Android.

The idea stems from the fact that Android has by default no serious way to do scalable graphics in a world with an exploding amount of device densities.

SVG appeared as a good fit because it’s easy to parse (XML), text-based (compress well) and fit well with the Android graphics API. It’s also incidentally the format used by the lovely Inkscape which makes my work even easier.

Before anyone gets their hopes high and starts throwing fancy SVG tigers at the library, know that this is by no mean meant to be a complete implementation of the standard.

As described in the README, the goal is to provide a minimum viable product™ to support traditional shape-based icons.

Still, I haven’t had any problem parsing all the SVG that I have created as almost all the icons in Moyeu are entirely SVG based. In general, if you follow the exporting guide in the README you should be fine.

The other good thing about the library is that it’s very simple to use. You will generally use only one class, SvgFactory and its two methods GetBitmap / GetDrawable:

var bmp = SvgFactory.GetBitmap (Activity.Resources, Resource.Raw.ic_svg, 48, 48);
var drawable = SvgFactory.GetDrawable (Activity.Resources, Resource.Raw.ic_svg);

I recommend the second form as the returned drawable will automatically scale depending on the bounds requested. This means that if you have an ImageView set up using dp units like this:

<ImageView
    android:layout_width="14dp"
    android:layout_height="9dp"
    android:scaleType="fitXY" />

The displayed image will look the same crispy crispness on every devices no matter how many pixel per inches they have.

Another cool thing about the library is that it lets you dynamically adapt colors at runtime. To do so, you need to provide an implementation of the ISvgColorMapper interface which sports the single method Color MapColor (Color c) (instance that can also be retrieved from a Func<Color, Color>).

I use this tricks for the pins that are displayed by Moyeu on the map. Concretely, the pins are all the same base SVG:

On which I can apply tinting with my color mapper:

Color ColorReplacer (Color inColor, float ratio)
{
	Color tone = InterpolateColor (baseLightRedColor, baseLightGreenColor, ratio);
	Color result = inColor;

	if (inColor == fillColor)
		result = tone;
	else if (inColor == borderColor)
		result = Lighten (tone, 0x20);
	else if (inColor == bottomFillColor)
		result = InterpolateColor (baseDarkRedColor, baseDarkGreenColor, ratio);

	return result;
}

In order to have a multi-colored view of the world:

You can find more usage sample of the library in Moyeu source code.

This new version sports a good number of new features and general UI refresh.

For starter, the navigation is now exposed as a drawer that also lets you visualize stations that are near you.

Instead of the old info window style, information about a station are presented with a sliding info view in the same fashion than the new Google Maps application. That info view when expanded also shows you a Google Street View shot of the station surroundings for easier pinpointing.

The pins displayed on the map are also now showing the number of bikes available at each station. They also have a better tinting system to provide a direct feedback on each station bike availability.

Just for fun, I also made a little featurette page for the app. Check it out at moyeuapp.net.

For installation, head to the usual corner of the web:

What?

An experiment in bridging Rdio and Lastfm together.

The idea is to gather your most listened to artists on Rdio and generously gather similar talents from Lastfm comprehensive database.

All of this straight from your Android phone.

What does it look like?

It has pretty animations. It has blurring. It has large images.

What should I do with it

Use it as an example for bduncavage/RdioSdkBindings or scavenge any other part of it. All under Apache 2.0 license.

GitHub repository: garuma/Similardio

As a reminder, RenderScript is essentially Google’s version of OpenCL in that it allows you to write small general-purpose piece of code (called kernel) that executes on the GPU.

As such, it’s very efficient when doing parallelizable work on large data-set. The main hindrance as with any GPGPU scenario is that to interoperate with the CPU, data needs to be copied back and forth between RAM and GPU memory.

One of the main area where RenderScript is useful is with images and pixel-oriented algorithms. Since with recent Android version View instances are hardware-accelerated by default, showing up these GPU-processed images on screen is efficient as they don’t even need to be piggy backed to main memory.

Out of the box, Android ships with a couple of pre-made kernels, mainly picture-related. In that sense it can be considered equivalent to iOS CoreGraphics albeit much less rich in available filters.

One of those default script, ScriptIntrinsicBlur, allows you to blur the content of an image very easily:

Bitmap BlurImage (Bitmap input)
{
	var rsScript = RenderScript.Create (Context);
	var alloc = Allocation.CreateFromBitmap (rsScript, input);

	var blur = ScriptIntrinsicBlur.Create (rsScript, alloc.Element);
	blur.SetRadius (12);
	blur.SetInput (alloc);

	var result = Bitmap.CreateBitmap (input.Width, input.Height, input.GetConfig ());
	var outAlloc = Allocation.CreateFromBitmap (rsScript, result);
	blur.ForEach (outAlloc);
	outAlloc.CopyTo (result);

	rsScript.Destroy ();
	return result;
}

The code will certainly look familiar to those of you who have already used OpenCL. You basically create a context (RenderScript), setup typed buffers (Allocation), create the kernel (ScriptIntrinsicBlur), define its entry point (SetInput) and execute it (ForEach).

Below is the result in a small app to select different blur radius:

You can read up Android basic guide on RenderScript for a more in-depth explanation of each step.

Blur effects are becoming more and more trendy these days, being one of the design focus of iOS 7 and also used extensively by apps such as Rdio. With RenderScript you can now cheaply use that trick in your Android app too.