Tag Archives: Xamarin

Me Tech Talking at Xamarin Dev Days 2017, Singapore…

Here’s all about my tech talk at Xamarin Dev Days Singapore 2017, under the session, Cross Platform Native UI with Xamarin.Forms…

So on 4th of November Xamarin Dev Days Singapore 2017, concluded with a massive success, with a full house attendance, and as of me I happened be a presenter there.

a full house turn up at Xamarin Dev Days Singapore 2017…

Hosted by Microsoft with the support of Xamariners and SyncFusion, it was a full day community event.

As of myself, Udara Alwis, I was presenting my tech talk session on Cross Platform Native UI with Xamarin.Forms, where talked all about Xamarin.Forms and building cross platform apps with fully native look and feels, while being able to access platform specific features easily, and the latest updates and features of Xamarin.Forms.

udara alwis presenting tech talk xamarin dev days singapore 2017
oh! that’s me, presenting my tech talk…

Along side with an in detailed Live Demo of how Xamarin.Forms runs natively on Android, iOS and Windows with all the native look and feels.

Here are the event details if anyone’s keep on tito, Xamarin Dev Days event Link: on tito. Also if anyone’s looking for the Event photos, its all hosted in the Xamariners Facebook page and Meetup event page: on Meetup 

So I’m about to share some of the stuff I presented at my talk there, although I will not be diving into every single detail I talked about there, only be focusing on the key points.

Cross Platform Native UI with Xamarin.Forms…

So as we all aware, Xamarin.Forms is all about allowing developers to build native UIs for Android, iOS and Windows from single shared C# code base, while maintaining full native look and feels as well as native features.

In the beginning we had native Xamarin, which is the C# and dot net wrapper around the native platforms, where you had to manually develop the UI layer for each specific platform, but still allowing the shared business logic.

Then came Xamarin.Forms, the new abstraction layer that sits on top of the native platforms and abstracts up all the common properties and behaviors to a single abstraction layer, allowing you to develop the UI in one single code base and deploy directly into native platforms, along with the shared business logic. 😉

Windows vs Xamarin.Forms Development…

Here I did something pretty special that is to compare the UI Controls in Windows Dev Environment, and Xamarin.Forms Dev Environment. This helped most of developers who comes from Windows Development background to easily familiarize themselves for Xamarin.Forms development.

As of the MVVM Architect savvy fellas, do not worry Xamarin.Forms supports full binding out of the box, just like you had in Windows Development.

Eco System and Community…

It had been an incredible rise of the community around Xamarin since the Open-Source initiation by Microsoft, with some incredible statistics. 😮

Some of the Latest and Greatest in Xamarin.Forms…

In this section I dived into some of the latest updates of Xamarin.Forms.

Native View Declarations..

Now you can declare Platform Specific Elements inside your Xamarin.Forms pages, yes that’s correct even from XAML directly. 😀

Page Embedding…

Page Embedding has been one of my favorites, being able to embed Xamarin.Forms Elements in your Xamarin Native code. A great way to adopt Xamarin.Forms elements into your existing Xamarin Native applications. 😉

New Performance Updates…

Yes the Engineers in Xamarin has been busy with improving the performance of Xamarin.Forms lately, which is pretty impressive…

Layout Compression…

So whenever you create user interface in your mobile app, it forms some kind of a hierarchy of the Layouts and Control Elements. And you know for a fact the more higher the hierarchy the more performance is consumed by the Layout Renderer.
So its the same case here in Xamarin Forms, specially here it adds some extra layers in between the UI elements to do its Native Magic.

As you can see above the Xamarin.Forms Layout has 12 Elements in the UI, but in reality at run time it increases up to 19 Elements in the UI.

That’s why they’re introducing this new performance enhancement feature called Layout Compression. So what this new feature does it is remove the unnecessary nesting of the hierarchy and compress it as much as possible.

There you can see above as a result of the new feature how the Layout Hierarchy is flatted and compressed down to 16 Elements.

Fast Renderers…

Yes that literally means speeding up the Rendering process of a given Element at runtime. As we know in Xamarin.Forms, each UI Element has a Renderer attached to it, that handles all the native mapping with Xamarin.Forms layer. This Renderer layer also contributes to the unnecessary UI hierarchy for the Layout Renderer.

That is why with this new Fast Renderers feature they’re merging the Element and its Native Renderer into one single Element, causing the whole UI Layout Hierarchy to compress down itself even further.

As a result you can see above example, the 12 Elements hierarchy we had in Xamarin.Forms has compressed down to 10 Elements at run time, resulting in massive performance improvement.

New Backends…

So Xamarin.Forms is all about Cross Platform application development, that’s why they’re now expanding their horizons into some new platforms, allowing you to write you code in Xamarin.Forms in a single code base and deploy to the new platforms right away, without having to write any native code line at all… 😉

  • Tizen : yaay! Samsung devices…
  • WPF: Oh yeah! beautiful WPF, here we come…
  • GTK#: Ubuntu? or whatever your Linux flavor… 😉
  • MacOS: Woot! Woot! MacOS apps…
More…

And with a lot more awesomeness…

All of it on github…

That’s right, I’ve hosted all of the slideshow and the full demo code up in my github: https://github.com/UdaraAlwis/XamarinDevDays-2017-Singapore-Udara

Finally thanks everyone who attended Xamarin Dev Days Singapore 2017 and contributed to make it a success. 😀

Cheers!

Advertisements

It’s a Flippin’ Flipity Flippable View in Xamarin.Forms!

Something that Flips! Flipity Flippy Flippin’ Flip View right out of Xamarin.Forms yol! 😀

Sometime back while I was trying to push the limits of Xamarin.Forms Views, I came across this requirement of Flipping a View with a cool animation. So let me share the story of it right here as usual…

I wanted to create a control that would have a Front View and a Back View, whilst being able to switch between those two Views in with a cool Flip animation!

Behold ze me effortz… 😀

 

TADAAA! 😀 How cool it is eh! 😉

And its all pure Xamarin.Forms, without a single line of native code… Say whuut! 😀 lol

So yeah let’s see how I did it.

The Golden Recipe…

So the solution here is to simply use a View which can hold two layouts (where we will be placing out child elements in) on top of each other, and rotate the View with the easy use of  Xamarin.Forms Animations, whitest swapping the two layouts on top of each other accordingly.

Ok so let me elaborate step by step.

  • Prepare a MainLayout View to hold two child Layouts (FrontView and BackView) in it
  • Add the FrontView and BackView on top of each other inside the MainLayout  View
  • Rotate the MainLayout 90 degrees using Xamarin.Forms Animations API
  • Swap the FrontView and BackView 
  • Then Rotate the MainLayout another 90 degrees
  • And Repeat the same…

That’s it!

The Golden Control…

Alright let’s start of with creating a custom control, which we shall call the golden XFFlipView which would derive from a ContentView. Then myself be using a RelativeLayout as the Parent Layout View of this control,

I’m using bindable FrontViewProperty and BackViewProperty inside the XFFlipView control to hold the reference of the two child Layout Views that we are going to be using as FrontView and BackView of this Flippin’ Flippity Flippy thing! 😀

Additionally we are going to use a bindable boolean, IsFlippedProperty to handle the flipping of this flip view 😉

Well why all the “bindable properties” you might ask? Oh come on, why not silly! So we can monitor the changes of those properties at run time and react accordingly, such as the IsFlipped property, whereas whenever the value changes we shall be activating the Flip View animation functionality.

public class XFFlipView : ContentView
{
	private readonly RelativeLayout _contentHolder;
	
	public XFFlipView()
	{
		_contentHolder = new RelativeLayout();
		Content = _contentHolder;
	}

	public static readonly BindableProperty FrontViewProperty =
	BindableProperty.Create(...);

	public static readonly BindableProperty BackViewProperty =
	BindableProperty.Create(...);

	public static readonly BindableProperty IsFlippedProperty =
	BindableProperty.Create(...);

	private static void IsFlippedPropertyChanged(BindableObject bindable, object oldValue, object newValue)
	{
		if ((bool)newValue)
		{
			((XFFlipView)bindable).FlipFromFrontToBack();
		}
		else
		{
			((XFFlipView)bindable).FlipFromBackToFront();
		}
	}
	
	/// <summary>
	/// Performs the flip
	/// </summary>
	private async void FlipFromFrontToBack()
	{
		...
	}

	/// <summary>
	/// Performs the flip
	/// </summary>
	private async void FlipFromBackToFront()
	{
		...
	}
}

 

There you have it as we just discussed earlier. Ops I may have forgotten about those two methods at the bottom, so those are the methods we are going to use the actual Flip Animation logic, as you can see they’re are being called every time the IsFlipped property is changed.

Oh for them lazy fellas, here grab the full implementation above on my github: XFFlipView.cs

Ze Animationalization…

Alright time for the reveal of the animation thingy, which has been completely done through the easy to use Xamarin.Forms Animations API. Surprise!!?? 😛

...
private async void FlipFromFrontToBack()
{
	await FrontToBackRotate();

	// Change the visible content
	this.FrontView.IsVisible = false;
	this.BackView.IsVisible = true;

	await BackToFrontRotate();
}
...

So basically that’s the implementation of the above said mystery two methods, as you can clearly see, inside there I’m calling another method called FrontToBackRotate() which is the actual method that performs the animation. And right after that we are swapping the Visibility of the FrontView and BackView. Then continue with the rest of animation in BackToFrontRotate() call, just like how we discussed at the beginning.

Let’s see the actual animation implementation, shall we…

#region Animation Stuff

private async Task<bool> FrontToBackRotate()
{
	ViewExtensions.CancelAnimations(this);

	this.RotationY = 360;

	await this.RotateYTo(270, 500, Easing.Linear);

	return true;
}

private async Task<bool> BackToFrontRotate()
{
	ViewExtensions.CancelAnimations(this);

	this.RotationY = 90;

	await this.RotateYTo(0, 500, Easing.Linear);

	return true;
}

#endregion

 

Oh look at that simplicity eh! Thank you Xamarin.Forms animation! 😀 lol

So what happen over there is first we cancel any pending animation and the do initial Y axis rotate property of the parent View and then actually call on the RotateYTo() of Xamarin.Forms Animations, causing it the parent Layout to rotate around the Y Axis with the given value of degrees.

Then when the parent View is flipping from Back To Front View, the same process’s opposite will be executed. 😀 Simples!

Try it out eh! 😀

Since its full on Xamarin.Forms without a single line of native Xamarin code, you could straightaway use this in your XAML or C# code behind anywhere in your PCL.

<xfFlipViewControl:XFFlipView 
        x:Name="XFFlipViewControl1">

    <xfFlipViewControl:XFFlipView.FrontView>
        <Frame
            Margin="10"
            Padding="0"
            BackgroundColor="#0080ff"
            CornerRadius="10"
            HasShadow="True">
            <Grid>
                <Label
                 Grid.Row="0"
                 FontAttributes="Bold"
                 FontSize="Large"
                 HorizontalTextAlignment="Center"
                 Text="this is front view"
                 TextColor="White"
                 VerticalTextAlignment="Center" />
            </Grid>
        </Frame>
    </xfFlipViewControl:XFFlipView.FrontView>

    <xfFlipViewControl:XFFlipView.BackView>
        <Frame
            Margin="10"
            Padding="0"
            BackgroundColor="#ff0080"
            CornerRadius="10"
            HasShadow="True">
            <Grid>
                <Label
                 Grid.Row="0"
                 FontAttributes="Bold"
                 FontSize="Large"
                 HorizontalTextAlignment="Center"
                 Text="this is back view"
                 TextColor="White"
                 VerticalTextAlignment="Center" />
            </Grid>
        </Frame>
    </xfFlipViewControl:XFFlipView.BackView>

</xfFlipViewControl:XFFlipView>

 

Woot! Such simplicity! 😀 So you can see how I have directly used our awesome XFFlipView control right inside XAML and defined the Front and Back Views. Also I have used a Frame View to make it look cooler 😉 lol

So now to execute the awesome Flip Animation, simply change the value of the IsFlipped as follows.

XFFlipViewControl1.IsFlipped = !XFFlipViewControl1.IsFlipped;

 

As you can see in code behind, we’re changing the value of the control’s IsFlipped property, Simples eh! 😀 This is fully bindable as well, so you can directly bind this to a ViewModel property as well.

...
<xfFlipViewControl:XFFlipView 
     x:Name="XFFlipViewControl1" 
          IsFlipped="{Binding IsViewFlipped}">
...

</xfFlipViewControl:XFFlipView>

 

So you can directly use this in your beautifully crafted MVVM Xamarin.Forms app as well. 😀

Some Live Action…

Here we go baby! iOS and Android running side by side…

  

Oh hold on… there’s more coolness… 😀

 

Ohhh! Eye Candy! 😀

And the craziest thing about it is that, all of this awesomeness is right from Xamarin.Forms, without a single line of native Xamarin code. 😉

Woot!

This whole awesome project i hosted up in my Github repo : https://github.com/UdaraAlwis/XFFlipViewControl 

Oh BTW, you might ask me why on Android during the Animation, the view seem to be expanding out of the view? Yes its basically how the Android native flip animation executes, since Xamarin.Forms directly maps its Animation rendering calls down to native level. But we could easily tweak it up by implementing our own native renderer for the Animation, which we will be looking into in the next post. 🙂

Cheers! 😀 Keep on going my fellow devs!

Spread the love…

I’m building an Atom Simulation with SkiaSharp and Xamarin.Forms!

So lately I’ve been on quite a bunch of adventures with SkiaSharp in Xamarin.Forms! 😀 You know how it is for me, pushing the limits of the framework as usual for the fun 😉 And this right here is one of those adventures I’m going to share with you all…

Little Backstory…

I’ve always been fascinated by the Atom’s graphical structure being the science nerd back in school days. I’ve always loved the simulation of the Electrons circulating around the atom’s core filled with Neutrons and Protons. 😀 So while reminiscing those memories, I was thinking of ways to play around with SkiaSharp framework, and suddenly, AHA! A light bulb lit-up on my head! 😀

I’ve decided to build an Atom Simulation in SkiaSharp, with Xamarin.Forms! 😉

A sneak peek!

  

TADAAA! 😀

So where is it going?

Haven’t you ever thought those animated atom structure simulation they show on TV was very very cool? Well I’m thinking of building a similar simulation with SkiaSharp on top of Xamarin.Forms! 😀

And this is going to be a step by step process, where I shall begin with the basic 2D structure and slowly moving towards the complex animated simulation!

Well I’ve already started developing this some time back, and I’ve made quite a bit of progress.

I have hosted this on Github: github.com/UdaraAlwis/SkiaSharpAtomStructureSo that anyone can try it out or add improvements to it, and yes I’m open for pull requests! 😉

Code behind tech bits?

Well basically as you may have already figured out, it’s a Xamarin.Forms project, and I’m using the awesome SkiaSharp for rendering the graphics.

And to be specific with SkiaSharp I’m using the following to render the cool stuff:

  • 2D Shapes Drawing
  • Canvas Translations and Rotations
  • Continuous Animation Rendering
  • Gradient Shading
  • Touch handling

Pretty cool set of features right there, out of the box with SkiaSharp eh! 😉

Progress so far…

I’ve broken the progressive steps to several Pages in the project for clear distinction between the code behind.

I will be updating this post as the project moves forward with improvements and new progression steps.

And here they are…

1. Atom Silhouette

 

So the first step was to simply build a silhouette of the atom structure. There you have the core with Neutrons and Protons, and the Electrons around it in their own orbits.

Basically I’m using the SkCanvas.DrawCircle() to draw the center core and then SkCanvas.DrawOval() to draw the Oval Orbits around the core. 😉

Then I’m drawing the “Electron dot” for each orbit using the corner most point of the Oval Orbit, which is basically the width of the Oval. Tricky yeah!

You might think how about the angles of the oval? Oh yeah I’m using Canvas Rotation for each orbit draw cycle, SkCanvas.RotateDegrees(xx degrees)! 😀

And there’s a simple +/- increment mechanism for increasing and decreasing the number of electrons around the orbit!

You can take a look at the implementation: AtomSilhouettePage.xaml.cs

2. Atom Orbital Paths

 

Here’s a little improvement for the previous step, where as I’ve added some gradient effect for the drawing of the Oval path with the same SkCanvas.DrawOval() call.

The CreateSweepGradient() is one of the way to create a gradient color effect in SkiaSharp, whereas we’ve used white and dark gray as the color here.

Oh Gradients are always cool yeah! 😉

You can take a look at the implementation: AtomOrbitalPathsPage.xaml.cs

3. Atom Orbital Paths Uneven

 

Now we know in reality the Atom’s electron orbit is not a nice even orbit, so we’re going to reflect just that in this progress step! 😀

So basically I’m randomly generating the Oval’s supposed width for each orbit, thus giving the above output!

You can take a look at the implementation: AtomOrbitalPathsUnevenPage.xaml.cs

4. Atom Animated Silhouette

 

This is the step where I kick it up a notch, with the Animation rendering using SkiaSharp!

So as we all know there’s no direct animation rendering support with SkiaSharp, since its a on demand 2D vector graphics rendering system.

What I’m doing here to get the electron dot’s to movement on the oval orbit, is I’m rendering it’s each 360 degrees positions continuously on a timer loop. Might sound pretty complex, but its actually simple! 😉

You can take a look at the implementation: AtomAnimatedPage.xaml.cs

5. A cool touch feature!

I’ve added something cool for the number of displayed Electron’s incremental mechanism!

 

I’ve added a touch handling feature to the atom’s electron incremental mechanism, so now basically you can swipe up or down the screen to increase or decrease the number of electron orbits of the Atom! 😉 Now instead of clicking on the +/- buttons, rather you could swipe up or down to increase or decrease the electron orbits.

This was done simply using the SkiaSharp’s built in touch event handler, and calculating the touch movement direction, thus determining up or down direction! 😀

6. Atom Animated Uneven Orbits

 

So here’s the next progression step, with uneven orbits animation! I’m using a gradient oval drawing for each orbit, similar to what I’ve explained above in one of the previous steps. And I’m generating the Orbits Width upon a given random value.

You can take a look at the implementation: AtomAnimatedUnevnOrbitsPage.xaml.cs

7. ….T B C…..

This will be the next progression step. Since this post will be a continuously updated post along with every progression step I make in this fun project! 😀 So stay tuned!

 

 

That’s all for now!

So like I said at the beginning, this is a continuous fun protect, which I’ll keep on improving step by step. And once again, I will be accepting your pull requests for any improvements you suggest, or just drop a comment or message me of your suggestions. 😀

Don’t forget, feel free to try this project from my Github repo: github.com/UdaraAlwis/SkiaSharpAtomStructure 

I will be updating this post as the project progresses on hopefully! 😉

Let’s draw basic 2D Shapes with SkiaSharp…

So on my last post I shared a recap of my tech talk on SkiaSharp with Xamarin.Forms, check it out if you missed it: So I gave a Tech Talk on SkiaSharp with Xamarin.Forms…

There I talked about some of the most important parts of the whole 1 hour plus presentation-hands-on-labs session, in which I didn’t share all the details of the whole session. I did a pretty comprehensive demo session there, specially about the 2D drawing basics of SkiaSharp, which I didn’t highlight in that post.

Basic 2D Shapes with SkiaSharp…

So today I thought of sharing the demos I did there, about basic 2D shapes drawing with SkiaSharp more extensively… 🙂 Since there seem to be a lack of tutorials explaining this topic of, “draw basic Shapes with SkiaSharp”, which I think should be more important for beginners!

So buckle up fellas, let’s see how we could draw some of the most commonly used 2D shapes with SkiaSharp with ease… 😉

There’s many out of the box support for drawing basic 2D Shapes from SkiaSharp, such as DrawCircle(), DrawRectangle(), DrawLine(), DrawOval() and so on many more.  You could stright away use those methods or you could even go around it and use Paths and Lines drawing methods of SkiaSharp in order to draw them, which is completely up to you.

But SkiaSharp doesn’t have methods for drawing for every single kind of Geometrical shape there is out there. So if you want to draw some kind of complex shape, then you could basically use a combination of Paths and Lines drawing methods in SkiaSharp, which has many kinds of methods you could come up with. 😉 that’s the beauty of SkiaSharp! Anyways the choice of drawing methods are totally up to you!

Now if you want to get ahead of yourself, you may grab the live hands on demo code I did at the presentation which includes all of the below code, right from my github repo: https://github.com/UdaraAlwis/XFSkiaSharpDemo

Just on a note, here I will not be discussing basics of SkiaSharp or the setting up of SkiaSharp library or the Canvas properties and behaviours, I’ll directly get into the programming of the shapes drawing, but if you want to get a head start, head off to Xamarin SkiaSharp Documentation or my previous post, So I gave a Tech Talk on SkiaSharp with Xamarin.Forms…

1. Simple Stroke Line…

private void SkCanvasView_OnPaintSurface
		(object sender, SKPaintSurfaceEventArgs e)
{
	...
	
	// Drawing Stroke
	using (SKPaint skPaint = new SKPaint())
	{
		skPaint.Style = SKPaintStyle.Stroke;
		skPaint.IsAntialias = true;
		skPaint.Color = SKColors.Red;
		skPaint.StrokeWidth = 10;
		skPaint.StrokeCap = SKStrokeCap.Round;

		skCanvas.DrawLine(-50, -50, 50, 50, skPaint);
	}
}

 

We use the DrawLine() and pass in the Line’s starting point’s XY position and and ending point’s XY position, while passing in the paint configuration, SKPaint as we wish.

 

Since SkiaSharp support pure Xamarin.Forms you can straight away run all your native projects without any hassle of handling native code.

2. Drawing a Circle (Filled)

// Drawing a Circle
using (SKPaint skPaint = new SKPaint())
{
	skPaint.Style = SKPaintStyle.Fill;
	skPaint.IsAntialias = true;
	skPaint.Color = SKColors.Blue;
	skPaint.StrokeWidth = 10;

	skCanvas.DrawCircle(0, 0, 70, skPaint);
}

 

We shall be using the DrawCircle() whilst passing in the Circle’s center XY position and desired radius for it. To define whether its a Filled or Non-Filled circle we’ll be using Style property in our SKPaint configuration.

 

Next let’s draw a Circle with just the stroke (with filling the inner of the circle).

3. Drawing a Circle (Un-filled)

We do this by setting the Style property to Stroke! and everything else is the same 🙂

// Drawing a Circle Stroke
using (SKPaint skPaint = new SKPaint())
{
	skPaint.Style = SKPaintStyle.Stroke;
	skPaint.IsAntialias = true;
	skPaint.Color = SKColors.Red;
	skPaint.StrokeWidth = 10;

	skCanvas.DrawCircle(0, 0, 70, skPaint);
}

 

 

Look how simple eh 😉

4. A Square Rectangle!

How about a standard Rectangle? We shall use the SKRect object to configure our Rectangle as we wish and draw it up!

// Draw Rectangle
SKPaint skPaint = new SKPaint()
{
	Style = SKPaintStyle.Stroke,
	Color = SKColors.DeepPink,
	StrokeWidth = 10,
	IsAntialias = true,
};

SKRect skRectangle = new SKRect();
skRectangle.Size = new SKSize(100, 100);
skRectangle.Location = new SKPoint(-100f / 2, -100f / 2);

skCanvas.DrawRect(skRectangle, skPaint);

 

See it in action? 😉

 

The square root of 69 is 8 something, right? – Drake 😉 lol

5. Let’s draw an Ellipse…

There’s many ways to draw an Eclipse, but most common way is to use DrawOval(), as well as other kinds of complex drawings.

// Draw Ellipse
SKPaint skPaint = new SKPaint()
{
	Style = SKPaintStyle.Stroke,
	Color = SKColors.OrangeRed,
	StrokeWidth = 10,
	IsAntialias = true,
};

SKRect skRectangle = new SKRect();
skRectangle.Size = new SKSize(150, 100);
skRectangle.Location = new SKPoint(-100f / 2, -100f / 2);

skCanvas.DrawOval(skRectangle, skPaint);

 

 

So here we’re configuring a Rectangle with SKRect, which an Ellipse could be mathematically consist of.

6. How about an Arc shape?

Well it’s basically the same concept as of an Ellipse, but since we need an “Arc”, we’re going to use some basic mathematical angles to configure the starting angle, startAngle and sweep angle, sweepAngle of the Arc we’re going to draw with a Path object.

// Draw Arc
SKPaint skPaint = new SKPaint()
{
	Style = SKPaintStyle.Stroke,
	Color = SKColors.BlueViolet,
	StrokeWidth = 10,
	IsAntialias = true,
};

SKRect skRectangle = new SKRect();
skRectangle.Size = new SKSize(150, 150);
skRectangle.Location = new SKPoint(-150f / 2, -150f / 2);

float startAngle = -90;
float sweepAngle = 230; // (75 / 100) * 360

SKPath skPath = new SKPath();
skPath.AddArc(skRectangle, startAngle, sweepAngle);

skCanvas.DrawPath(skPath, skPaint);

 

So there we’re configuring our Path object to start off from -90 degrees and ends up at 230 degrees from the start point, drawing the Arc shape. Notice the comment I’ve added there, showcasing how you could also calculate the Arc’s drawing angle as a percentage value. 😀

 

Pretty cool eh! 😉

7. Did we forget Text?

Did you know you could even draw text on a SkiaSharp canvas right away by using DrawText() method.

// Drawing Text
using (SKPaint skPaint = new SKPaint())
{
	skPaint.Style = SKPaintStyle.Fill;
	skPaint.IsAntialias = true;
	skPaint.Color = SKColors.DarkSlateBlue;
	skPaint.TextAlign = SKTextAlign.Center;
	skPaint.TextSize = 20;

	skCanvas.DrawText("Hello World!", 0, 0, skPaint);
}

 

SkPaint object holds several properties for drawing Text on the canvas, such as TextAlright, TextSize and many more you could play around with..

 

Hello World, indeed! 😉

8. Let’ draw a simple Triangle?

Well SkiaSharp doesn’t have a out of the box method call for drawing a Triangle, this is where simple Drawing path and points comes into play.

So basically what we do is, we’ll draw three lines that’s interconnects at the ending points, using DrawPoints() method and pass in the list of Points that’ll draw the Lines…

// Draw Rectangle
SKPaint skPaint = new SKPaint()
{
	Style = SKPaintStyle.Stroke,
	Color = SKColors.DeepSkyBlue,
	StrokeWidth = 10,
	IsAntialias = true,
	StrokeCap = SKStrokeCap.Round
};

SKPoint[] skPointsList = new SKPoint[]
{
	// Path 1
	new SKPoint(+50,0),
	new SKPoint(0,-70),

	// path 2
	new SKPoint(0,-70),
	new SKPoint(-50,0),

	// path 3
	new SKPoint(-50,0),
	new SKPoint(+50,0),
};

skCanvas.DrawPoints(SKPointMode.Lines, skPointsList, skPaint);

 

See it first may be?

 

So now if you think about it, you could actually draw any kind of a Shape with interconnecting Points and Paths using the above method. 😀

9. Draw any Shape?

It’s true earlier step, in Triangle drawing I said you could use the DrawPoints() and a bunch of Points to draw any kind of shape in SkiaSharp. This is actually a painful, but there’s actually a better way… 😉 yaay!

So basically if you needed to draw any kind of shape, all you need is a Path and a bunch of Points that interconnects. A much easier way to do this is by using a SKPath configuration object, using this you could pass define the Starting Point of the drawing path, move around the drawing path with interconnecting Points by using MoveTo() and LineTo() calls. For this you use the mighty DrawPath() method, which you could use to draw anything on the canvas. 😀

// Draw any kind of Shape
SKPaint strokePaint = new SKPaint
{
	Style = SKPaintStyle.Stroke,
	Color = SKColors.Black,
	StrokeWidth = 10,
	IsAntialias = true,
};

// Create the path
SKPath path = new SKPath();

// Define the drawing path points
path.MoveTo(+50, 0); // start point
path.LineTo(+50, -50); // first move to this point
path.LineTo(-30, -80); // move to this point
path.LineTo(-70, 0); // then move to this point
path.LineTo(-10, +90); // then move to this point
path.LineTo(+50, 0); // end point

path.Close(); // make sure path is closed
// draw the path with paint object
skCanvas.DrawPath(path, strokePaint);

 

There you go…

 

So with the use of SKPath, you could draw any kind of 2D shape as you wish… 😀

10. Final shape?

Oh sorry! there ain’t none! 😛 just put up a 10th point for the fun of it! 😉

Well you could grab all of the above code up in my Github repo: https://github.com/UdaraAlwis/XFSkiaSharpDemo That right there is actually the live hands on demo code I did at my original presentation…

So now get out of here and start drawing 2D with SkiaSharp! 😀

or may be check out my talk on SkiaSharp…

Shape the love fellas! 😀

-Udara Alwis.

So I gave a Tech Talk on SkiaSharp with Xamarin.Forms…

A little back story…

Few months back our company was asked to do a graphics application, so we decided to take a look into graphics rendering libraries available for Xamarin.Forms, given the limited time, we thought of going for SkiaSharp over other alternatives, which we had very little knowledge of how to work with.

But to our surprise we managed to build an incredible app with beautiful interactive graphics and animations completely using SkiaSharp with Xamarin.Forms. So I thought of sharing my experience with the fellow dev community. 😀

Opportunity…

So few weeks back (18th June, 2017), I had the opportunity to give a tech talk-hands on demos, at Singapore Mobile .Net Developers  meetup, under the topic “2D Graphics Rendering in Xamarin.Forms with SkiaSharp”!

udara alwis presentation skiasharp xamarin microsoft

So I’m about to share some of the stuff I presented at this meetup, although I will not be diving into every single detail I talked about there, only be focusing on the key points (mostly on the hands on demo bits). If you’re interested in learning SkiaSharp for Xamarin.Forms, go ahead to the the incredible documentation provided by Xamarin: https://developer.xamarin.com/skiasharp/

Here’s the short recap of the presentation I did over there! 😉

2D Graphics Rendering in Xamarin.Forms with SkiaSharp!

So let’s get started off with the Slideshow Presentation…

And you may grab the live hands on demo code I did at the presentation from my github repo: https://github.com/UdaraAlwis/XFSkiaSharpDemo

Now let’s recap…

Behold the incredible 2D Rendering Engine for Xamarin and Xamarin.Forms, SkiaSharp!

An open source project originally developed by Google(Thank you <3), from C++ language, by the name Skia. It is used across a huge variety of Google’s products, including web graphics rendering and so on. This is a Immediate mode 2D vector graphics rendering system, this framework allows you to do 2D graphics, handling and manipulating image resources and text and a lot of cool stuff. 😀

So SkiaSharp is the C# and DotNet wrapper of Skia framework allowing us to use it right on top of Xamarin, a mono based open source project, where you could add your own contribution to it via: github.com/mono/SkiaSharp!

SkiaSharp for Xamarin.Forms comes with the SKCanvasView that inherits from Xamarin.Forms.View which allows you to use it as just another View in your PCL code, and you don’t have to handle any native implementation, everything is accomplished right in your PCL code. 😉

SkiaSharp basics Demo..

For setting up SkiaSharp, open your nuget manager and install “SkiaSharp.Views.Forms” across your Xamarin.Forms solution, including PCL and platform specific projects.

Add the SKCanvasView to your page as you wish.

<ContentPage
    x:Class="XFSkiaSharpDemo.MainPage"
    xmlns="http://xamarin.com/schemas/2014/forms"
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
    xmlns:forms="clr-namespace:SkiaSharp.Views.Forms;assembly=SkiaSharp.Views.Forms"
    xmlns:local="clr-namespace:XFSkiaSharpDemo">

    <forms:SKCanvasView x:Name="SkCanvasView" PaintSurface="SkCanvasView_OnPaintSurface" />

</ContentPage>

 

Notice the PaintSurface event, the most important execution point you need to handle in order to render your graphics on the SKCanvas. Every time you need to do any kind of a drawing or rendering of 2D graphics on your Canvas, you need to do it in this event, this method is first invoked when the Page appears on the screen, and then if the orientation changes or you could even manually invoke it by calling InvalidateSurface() of your SkCanvasView.

Let’s do that…

public partial class
	MainPage : ContentPage
{
	...

	private void SkCanvasView_OnPaintSurface
		(object sender, SKPaintSurfaceEventArgs e)
	{
		// Init skcanvas
		SKImageInfo skImageInfo = e.Info;
		SKSurface skSurface = e.Surface;
		SKCanvas skCanvas = skSurface.Canvas;

		// clear the canvas surface
		skCanvas.Clear(SKColors.SkyBlue);

		// retrieve the canvas info
		var skCanvasWidth = skImageInfo.Width;
		var skCanvasheight = skImageInfo.Height;
	}
}

 

This event provides you with all the required properties and values to execute your 2D rendering, such as the SKCanvas instance, which is the actual canvas you’re going to do the 2D drawing on, SKImageInfo instance which provides you with details such as actual Width and Height by pixels and so on.

The Clear() method call, clears up the canvas surface and prepare it for rendering new content, by passing it a SKColor object, you can paint it with that color.

2D Graphics with SkiaSharp..

The SKCanvasView is actually a placeholder for the SKCanvas which you can access in the PainSurface() event.

There’s many ways to draw or render stuff on our Canvas, but SkiaSharp also provides us predefined methods that allows us to draw simple types of shapes such as Circles, Lines and Texts, etc.

So usually when you are to do some complex drawings you would be using a combination of all those drawing methods at a given rendering cycle.

Transform Operations…

SkiaSharp allows you to do all kinds of Translations, Scaling, Rotating and even Skewing on the Canvas.

Usually on the Canvas, the X,Y coordinate system starts from the top left most corner and Y axis increments vertically and X axis increments horizontally.

So lets see how we could manipulate this in our favor and do some basic Translation and Scaling on the Canvas.

private void SkCanvasView_OnPaintSurface
	(object sender, SKPaintSurfaceEventArgs e)
{
	...
	
	// move canvas's X,Y to center of screen
	skCanvas.Translate((float)skCanvasWidth / 2,
				(float)skCanvasheight / 2);

	// set the pixel scale of the canvas
	skCanvas.Scale(skCanvasWidth / 200f);
}

 

There we are Translating the Canvas’s X,Y coordinate system to be started off of the center of the screen, and then Scaling the Canvas to the ratio of 200 pixels according to the actual canvas Width.

SKPaint object..

SKPaint object is one of the most important element in SkiaSharp, it holds the configuration for any given type of 2D rendering, so you’ll be storing your drawing configuration in that object, such as Color, Style, Stroke Width/Height, Anti Alias and so on.

SKPaint skPaint = new SKPaint()
{
	Style = SKPaintStyle.Fill,
	IsAntialias = true,
	Color = SKColors.Blue,
};

 

There’s how you instantiate a SKPaint object which you’ll using to render your 2D graphics, it’s got all kinds of drawing properties and configurations you can play around with. 🙂

Draw a simple Circle (Filled and Non-Filled)

Let’s get our hands dirty with some actual 2D drawing eh! 😉

// Drawing a Circle
using (SKPaint skPaint = new SKPaint())
{
	skPaint.Style = SKPaintStyle.Fill;
	skPaint.IsAntialias = true;
	skPaint.Color = SKColors.Blue;
	skPaint.StrokeWidth = 10;

	skCanvas.DrawCircle(0, 0, 50, skPaint);
}

...

// Drawing a Circle Stroke
using (SKPaint skPaint = new SKPaint())
{
	skPaint.Style = SKPaintStyle.Stroke;
	skPaint.IsAntialias = true;
	skPaint.Color = SKColors.Red;
	skPaint.StrokeWidth = 10;

	skCanvas.DrawCircle(0, 0, 70, skPaint);
}	

 

We shall be using the DrawCircle() whilst passing in the Circle’s center XY position and desired radius for it. To define whether its a Filled or Non-Filled circle we’ll be using Style property in our SKPaint configuration.

 

Look how simple and beautiful eh 😉

Since SkiaSharp support pure Xamarin.Forms you can straight away run all your native projects without any hassle of handling native code.

To learn more about drawing on the Canvas you can check out the official Documentation: https://developer.xamarin.com/guides/cross-platform/drawing/

Handling User Interactions…

When it comes to most Xamarin.Forms components, they do not have touch handlers, however the SKCanvasView comes default with a Touch event handler, Touch and a boolean property to enable or disable Touch Events, EnableTouchEvents.

You can straightaway use that even and property to handle touch events on the SKCanvas.

<forms:SKCanvasView x:Name="SkCanvasView" 
		EnableTouchEvents="True" 
		Touch="SkCanvasView_Touch"
		PaintSurface="SkCanvasView_OnPaintSurface" />

 

You can subscribe to it and look for the type of touch event and handle it.

private void SkCanvasView_Touch(
object sender, SKTouchEventArgs e)
{
	if (e.ActionType == 
		SkiaSharp.Views.Forms.SKTouchAction.Pressed)
	{
		_lastTouchPoint = e.Location;
		e.Handled = true;
	}

	_lastTouchPoint = e.Location;

	// update the Canvas as you wish
	SkCanvasView.InvalidateSurface();
}

 

As you can see it gives you the Touch point location. You can get a hold of the event and the touch point and you want to do some drawing on the SKCanvasView, then you could call the InvalidateSurface().

private SKPoint _lastTouchPoint = new SKPoint();
private void SkCanvasView_OnPaintSurface
(object sender, SKPaintSurfaceEventArgs e)
{
	...
	
	using (SKPaint paintTouchPoint = new SKPaint())
	{
		paintTouchPoint.Style = SKPaintStyle.Fill;
		paintTouchPoint.Color = SKColors.Red;
		skCanvas.DrawCircle(
			_lastTouchPoint.X,
			_lastTouchPoint.Y,
			50, paintTouchPoint); // 45
	}
}

 

Here it is in action… pretty simple eh! 😉

  

But this touch handler is very primitive, as in if you want to handle multiple concurrent touch points, or special gesture touches, pan, or zoom and so on, then you need to implement a more advanced low level touch handler, something described as here:

https://developer.xamarin.com/guides/xamarin-forms/application-fundamentals/effects/touch-tracking/

That way you could simply attach the above TouchEffect just as a normal effect and see the complex touch events in action.

<Grid>
	<skia:SKCanvasView x:Name="SkCanvasView"
		PaintSurface="SkCanvasView_OnPaintSurface" />
		
	<Grid.Effects>
		<tt:TouchEffect Capture="True"
			TouchAction="OnTouchEffectAction" />
	</Grid.Effects>
</Grid>

 

There you go! 😀

Bitmap Image Handling….

Images are pretty crucial when it comes to  2D Graphics, it gives more of added advantage over your design idea.

As of Xamarin.Forms, the conventional the conventional way of loading an image is, either as an Embedded Resource or Platform Specific Resource.

So in SkiaSharp for Xamarin.Forms, provides you SKBitmap or SKImage for handling your image resources. You have few options to load an image, from a data stream, file path and so on.

The most common way in the sense of Xamarin.Forms architecture, you have the option of loading your Images directly from PCL as Embedded Resources, and then convert it to a SKBitmap or SKImage.

string resourceID = "XFSkiaSharpDemo.Resources.xamarinmonkey.png";
Assembly assembly = GetType().GetTypeInfo().Assembly;

SKBitmap skBitmap;

using (Stream stream 
		= assembly.GetManifestResourceStream(resourceID))
using (SKManagedStream skStream
		= new SKManagedStream(stream))
{
	skBitmap = SKBitmap.Decode(skStream);
}

skCanvas.DrawBitmap(skBitmap, 
	SKRect.Create(-50, -50, 100, 100), null);

 

There you have it, we are using the DrawBitmap() method for drawing the image on canvas.

 

But if you have a Xamarin.Forms ImageSource at hand and you need to use in SKCanvas, then you have convert it a Stream object and convert it to SKBitmap, which you could use to manipulate or draw using SkiaSharp on the Canvas. 😉

Image Filters..

Thanks to SkiaSharp you don’t have to manually implement image filters at all, since it packs a pretty cool set of Image Filters out of the box. 😀

Here’s a small sample of a blur image filter implementation…

// built-it blur image Filter
var filter = SKImageFilter.CreateBlur(5, 5);
var skPaint = new SKPaint();
skPaint.ImageFilter = filter;

skCanvas.DrawBitmap(skBitmap, 
	SKRect.Create(-50, -50, 100, 100), null);

 

SKImageFilters is the class that provides the built in filters. 🙂 You attach that object to a SKPaint configuration and draw the Bitmap with it!

 

Keep in mind, there’s a lot more default Image Filters you could play around with! 😉

*drum beat*! 😀

Rendering Animations…

Although Xamarin.Forms packs some pretty decent set of Animations out of the box, we don’t much control over the animation for customization.

But using something like a 2D Rendering Engine, we could create whatever the animation or customization as we wish. SkiaSharp of course is a great option, but that being said, there’s no direct Animation handling available. Because it’s simply a 2D vector rendering engine.

So this means if you want to render some continuous animation with SkiaSharp, you need to handle every single frame of it manually from your code.

So by actual implementation there’s few ways to do this, but the actual underlying idea is to repeatedly render a given set of values on the Canvas, preferably triggered by a continuous timer of sorts.

Stopwatch stopwatch = new Stopwatch();
bool pageIsActive;
float t;
const double cycleTime = 1000; // in milliseconds

private void InitAnimation()
{
	pageIsActive = true;
	stopwatch.Start();

	Device.StartTimer(TimeSpan.FromMilliseconds(33), () =>
	{
		// calculate t for current 
		// tick with regards to cycletime
		t = (float)(stopwatch.Elapsed.TotalMilliseconds
					% cycleTime / cycleTime);
		// invoke redraw on canvas
		SkCanvasView.InvalidateSurface();

		if (!pageIsActive)
		{
			stopwatch.Stop();
		}
		return pageIsActive;
	});
}

 

The above shows you you could create a simple continuous pulse generator relative to milliseconds and execute a continuous animation. In simple terms the Timer is running each 33 milliseconds, calculates a value (t) based on the total elapsed milliseconds on the stopwatch, relative to the cycle time (controls the speed of animation) and repeats. Then calls the SKCanvas redraw. Make sure to call this method on PageAppearing() to start the timer and set the pageIsActive = false on PageDisappearing() to the timer stops.

private void SkCanvasView_OnPaintSurface
	(object sender, SKPaintSurfaceEventArgs e)
{
	... 
	
	// calculate circle radius for this cycle
	float radius = 70 * t;

	// Drawing a Circle Stroke
	using (SKPaint skPaint = new SKPaint())
	{
		skPaint.Style = SKPaintStyle.Stroke;
		skPaint.IsAntialias = true;
		skPaint.Color = SKColors.Red;
		skPaint.StrokeWidth = 10;

		skCanvas.DrawCircle(0, 0, radius, skPaint);
	}
}

 

There as you can see we are drawing the Circle at the given rendering cycle with relative to the generate “t” value at the Timer. So the Circle’s radius will keep on varying from 0 – 70, thus creating the animation effect.

 

Now keep in mind there’s nothing to worry about the rendering performance, since SkaiSharp is a rendering engine. 🙂 You can configure the animation even more faster as you wish, it wouldn’t make much effect on app’s performance! 😉

More Awesome Stuff…

If you want to learn more, check out Xamarin official documentation: https://developer.xamarin.com/guides/skiasharp/

If you need to check out sample code and demos : https://developer.xamarin.com/SkiaSharpFormsDemos/

This presentation’s demo on github…

That’s right, you can get the full demo code I’ve showcased in the presentation up in my github: https://github.com/UdaraAlwis/XFSkiaSharpDemo

I haven’t shared all the demo code I’ve presented in this blog post, but you call find all of the demo code from my git repo above! 🙂

Conclusion…

Yep that’s pretty much it, just get out of here and build something awesome with SkiaSharp! 😉

Share the love! 😀

Cheers!
– Udara Alwis

Xamarin Forms cross platform architectural implementation patterns…

Let’s talk about how to properly handle advanced cross platform architectural implementations in Xamarin Forms projects, specifically when you’re abstracting native services/implementations in your shared code base, while trying to maintain loosely-coupled and scalable architecture.

Yaay! Xamarin Forms!

Now we all know how Xamarin Forms allows us to build cross platform mobile apps while sharing almost up to 100% of our code base and skill having native performance and look and feels.
It does this by adding a common layer of abstraction which shares properties and behaviors which are common for the native platforms.

BUT…

Despite the incredible architecture of the Framework, one of the main drawbacks of it is that we do not get access to 100% of the native properties and behaviors, thus we only get the “common subset” of behaviors of each native platform that are shareable in a common manner among all the platforms through Xamarin Forms.

OPS…

So when we need to access some properties, behaviors or services that’s not available from Xamarin Forms layer, we need to drill down to the native platform specific level of that certain platform.
Now for UI Controls and their properties or behaviors we could use Custom Renderes or Effects.

But how about inbuilt native Services, such as Storage, Text-to-Speech, Location and so on?

ABSTRACTION FTW!

Turns out it’s all abstraction of an interface and mapping it to a platform specific concrete implementation, which could be described as the famous “Bridge Pattern”.

A BUMMER..

Yes it does seem pretty simple but when it comes to actual practicality of it, then it becomes a little bit complicated or rather messy, unless you follow a proper implementation pattern.
And it only gets more complicated when you keep on scaling your app project.
Therefore it’s very crucial that we maintain a certain set of principal patterns when we do platform specific implementation with abstraction mapping.

THE SOLUTION?

So we need to make sure that we maintain a proper set of principal patterns when deal with this situation as I explained earlier.
Here I’m going to talk about three key principles to deal with advanced cross platform implementations for handling native abstractions.

  • Factory Pattern
  • Service Locator Pattern
  • Dependency Injection Pattern

Now with the above principle patterns you could maintain a properly constructed and easily scalable Xamarin Forms project solution, when you’re dealing with advanced cross platform implementations with abstracting native services. Or rather any kind of an abstraction service implementation you could keep properly maintained by following the above patterns. The key advantage in all the above patterns are decoupled code, and scalability at any given time.

Now keep in mind there’s actually many kinds of patterns you could follow in this scenario or you could come up with your own architectural patterns, but the above are known to be most used among Xamarin Forms projects.

It is best to be aware of them, since you could either use them straight away or modify them according to your requirements. And keep in mind the above principle patterns could become slightly changed from their literal definition when it comes to actual implementation, it’s only the foundation concept that we need to keep in mind when we implement them, and make sure we are following the basics of it at least.

Which one should I use?

There is no such thing as “the best” or “the worse”pattern for cross platform mobile development, it all depends on how you interpret it based on your requirements. The selection of which pattern or architecture suits best for you is totally up to you and your requirements, that is something very crucial to keep in mind. Therefore here in this post I shall be demonstrating each of the above patterns and how to implement them properly in a Xamarin Forms project solution for the same app concept.

Let’s talk Demonstration!

In order to properly demonstrate the above said patterns I will be implementing a simple Xamarin Forms app which allows you to writing notes, save them, view them, read them out loud, edit them, and also delete them. So in that case we will be using native Storage Services and Text-To-Speech Services of those native platforms, while having a shared code base.

Alright now, I’m not going to get into spoon feeding details of how to do each native services implementation such as Storage and Text-To-Speech and implementing the XAML pages for the app and so on, but I will only be focusing on implementing the pattern for the given scenario, which is what matters for this post.

So we are going to create a Xamarin Forms solution in Visual Studio, and keep the interface for the above native services in the PCL or Shared Project (INoteReader and INoteLoader) and have the concrete implementations of them to be moved down to the native projects.

Then to demonstrate the differences of implementation of all the above three patterns I have created a complete solution (XFCPMobilePatterns) which has three sub folders, and included three Xamarin Forms projects in each of them which has the demo for Factory Pattern (XFMyNotesAppFP), Service Locator Pattern (XFMyNotesAppSL) and Dependency Injection w/ IoC (XFMyNotesAppDI).

Yep, that’s how it would look, if you’re interested in diving further into the implementation, You may find the complete solution up on my Github repo: https://github.com/UdaraAlwis/XFCPMobilePatterns

Let’s begin.

1. FACTORY PATTERN with Xamarin Forms

Oh yeah, back to basics yeah? the good old Factory Pattern, which allows you to create objects without exposing the creation logic to the client, or as in without having to aware of the concrete implementation.

So for our implementation we are going to keep a static generic Factory which will handle mapping and creation of the services. And we would request the service by passing the service type.

public static class ServiceLoaderFactory<T>
{
    public static Func<T> CreateService { get; set; }
}

 

Alright next we are going to map our Service Interfaces (INoteReader and INoteLoader) which we have placed in the PCL project, with their actual concrete implementations in the platform specific projects using the ServiceLoaderFactory. Make sure to do this mapping in the run time execution point of each project as shown below.

// Android implementation
protected override void OnCreate(Bundle bundle)
{
	TabLayoutResource = Resource.Layout.Tabbar;
	ToolbarResource = Resource.Layout.Toolbar;

	base.OnCreate(bundle);

	global::Xamarin.Forms.Forms.Init(this, bundle);

	ServiceLoaderFactory<INoteLoader>.CreateService = () => new NoteLoaderDroid();
	ServiceLoaderFactory<INoteReader>.CreateService = () => new NoteReaderDroid();

	LoadApplication(new App());
}

// iOS implementation
public override bool FinishedLaunching(UIApplication app, NSDictionary options)
{
	global::Xamarin.Forms.Forms.Init();
	LoadApplication(new App());

	ServiceLoaderFactory<INoteLoader>.CreateService = () => new NoteLoaderIos();
	ServiceLoaderFactory<INoteReader>.CreateService = () => new NoteReaderIos();

	return base.FinishedLaunching(app, options);
}

// UWP implementation
public App()
{
	ServiceLoaderFactory<INoteLoader>.CreateService = () => new NoteLoaderUwp();
	ServiceLoaderFactory<INoteReader>.CreateService = () => new NoteReaderUwp();

	this.InitializeComponent();
	this.Suspending += OnSuspending;
}

 

Next we need a NoteManager which is going to keep tract of all the service instances after they’re mapped to their concrete implementations at the run time, and also to maintain sort of a ‘facade-like’ access to the services. So for obvious reasons, we need to make it a singleton access point, as there’s no point of duplicating service objects. Also we are creating the NoteManager to handle basic functions such as loading and saving Notes at run time. 🙂

  public class NoteManager
  {
        // make a singleton access point
        private static readonly NoteManager _instance 
                                          = new NoteManager();
        public static NoteManager Instance 
                                  { get { return _instance; } }


        public IList<MyNote> MyNotes { get; private set; }


        public INoteLoader NoteLoader { get; private set; }
        
        public INoteReader NoteReader { get; private set; }

        private NoteManager()
        {
            NoteLoader = ServiceLoaderFactory<INoteLoader>.CreateService();
            NoteReader = ServiceLoaderFactory<INoteReader>.CreateService();

            MyNotes = new ObservableCollection<MyNote>(NoteLoader.Load());
        }

        public void Save()
        {
            NoteLoader.Save(MyNotes);
        }
  }

 

You can see there in the constructor, how we are loading the Service objects from our ServiceLoaderFactory and mapping them to the public interface instances, so that we could use them anywhere in our app.

Now the reason why I’m maintaining the NoteLoader and NoteReader instances here is because with the Factory Pattern, every time we request a service instance, it creates a new instance of the service and returns to the client, which obviously is not efficient, that’s why I’m retaining those instances in the NoteManager class. But with few tweaks you could easily implement a Factory Pattern which caches instances, and reuse them upon request, but I wouldn’t waste time on that, since we could use Service Locator or Dependency Injection for such scenarios, which I would explain later in the article.

Here’s how to access the above services in anywhere your PCL or Shared Project.

NoteManager.Instance.NoteReader.Speak("Hello, read this!");

 

There you have it, now that shows how to add platform dependent services and use them in your shared code following the Factory Pattern, as you go on scaling up the project solution! 😉

But keep in mind that this may not exactly according to literal definition of “Factory Pattern 101” but rather a customized version of it which I came up with for cross platform implementation, so you might have a different kind of implementation of the same concept, which is totally ‘ok’, as long as the foundation is the same. 🙂

2. SERVICE LOCATOR PATTERN with Xamarin Forms

As we already know, Service Locator Pattern, is all about locating a concrete implementation instance of an abstracted service interfaces at run time.
This is something similar to Factory Pattern, but a different type of a solution for our situation, whereas it maintains a dictionary of registered services which has been mapped with their concrete implementation, which we can look up at run time and retrieve the instance. Now it is considered that Service Locator pattern is a variation of Inversion of Control principle, just as Dependency Injection pattern, which we’ll discuss in the next topic.

This provides an on demand service look up at anywhere in the run time. The native service instances are stored in a dictionary-like data structure inside the Service Locator object, and returned at run time when they’re requested by the interface type. Obviously there will be a singleton static reference to the Service Locator object.

There’s many Service Locator ready-made libraries out there, and heck even Xamarin Forms already provides a solid Service Locator in the framework, which you may have already heard of, Xamarin Dependency Service. So you could use it right out of the box in Xamarin Forms, for your abstracted service implementations.

But that being said it’s not so hard to roll out our own Service Locator (just for the demonstration of it’s mechanics). 😉

So let’s implement our own simple Service Locator, this was actually something I grabbed off of github.

/// <summary>
///     Simple ServiceLocator implementation.
///     Extracted source credit : https://github.com/Azure-Samples/MyDriving/blob/master/src/MobileApps/MyDriving/MyDriving.Utils/ServiceLocator.cs
/// </summary>
public sealed class ServiceLocator
{
	static readonly Lazy<ServiceLocator> instance = new Lazy<ServiceLocator>(() => new ServiceLocator());
	readonly Dictionary<Type, Lazy<object>> registeredServices = new Dictionary<Type, Lazy<object>>();

	/// <summary>
	///     Singleton instance for default service locator
	/// </summary>
	public static ServiceLocator Instance => instance.Value;

	/// <summary>
	///     Add a new contract + service implementation
	/// </summary>
	/// <typeparam name="TContract">Contract type</typeparam>
	/// <typeparam name="TService">Service type</typeparam>
	public void Add<TContract, TService>() where TService : new()
	{
		registeredServices[typeof(TContract)] =
			new Lazy<object>(() => Activator.CreateInstance(typeof(TService)));
	}

	/// <summary>
	///     This resolves a service type and returns the implementation. Note that this
	///     assumes the key used to register the object is of the appropriate type or
	///     this method will throw an InvalidCastException!
	/// </summary>
	/// <typeparam name="T">Type to resolve</typeparam>
	/// <returns>Implementation</returns>
	public T Resolve<T>() where T : class
	{
		Lazy<object> service;
		if (registeredServices.TryGetValue(typeof(T), out service))
		{
			return (T)service.Value;
		}

		return null;
	}
}

 

As you can see how simple and straightforward it is. We maintain a singleton instance of the ServiceLocator, and there are the Add<TContract, TService>() which is used for registering the service interfaces with their concrete implementation and the Resolve<T>() which is used for retrieving the service instance at run time.

Notice how its maintaining a Dictionary of the service instances and retrieve it up on Resolve() call. 😉

Let’s add the above Service Locator to our project and construct it as below. And keep in mind the service implementation is going to be the same, having your service interfaces in the PCL shared project and the concrete implementations in the platform specific projects.

Now with our Service Locator this is how you would register your Service Interfaces (INoteReader and INoteLoader) with their concrete implementations.

// Android implementation
protected override void OnCreate(Bundle bundle)
{
	TabLayoutResource = Resource.Layout.Tabbar;
	ToolbarResource = Resource.Layout.Toolbar;

	base.OnCreate(bundle);

	global::Xamarin.Forms.Forms.Init(this, bundle);
	
	ServiceLocator.Instance.Add<INoteLoader, NoteLoaderDroid>();
	ServiceLocator.Instance.Add<INoteReader, NoteReaderDroid>();
	
	LoadApplication(new App());
}

// iOS implementation
public override bool FinishedLaunching(UIApplication app, NSDictionary options)
{
	global::Xamarin.Forms.Forms.Init();

	ServiceLocator.Instance.Add<INoteLoader, NoteLoaderIos>();
	ServiceLocator.Instance.Add<INoteReader, NoteReaderIos>();

	LoadApplication(new App());

	return base.FinishedLaunching(app, options);
}

// UWP implementation
public App()
{
	ServiceLocator.Instance.Add<INoteLoader, NoteLoaderUwp>();
	ServiceLocator.Instance.Add<INoteReader, NoteReaderUwp>();

	this.InitializeComponent();
	this.Suspending += OnSuspending;
}

 

Then just like what we had in Factory Pattern implementation we need a NoteManager which is going to handle basic Note managing functions such as loading and saving notes. 🙂

public class NoteManager
{
	// make a singleton access point
	private static readonly NoteManager _instance 
                                          = new NoteManager();
	public static NoteManager Instance 
                                  { get { return _instance; } }


	public IList<MyNote> MyNotes { get; private set; }
	
	private NoteManager()
	{
		var noteLoader = ServiceLocator.Instance.Resolve<INoteLoader>();
		MyNotes = new ObservableCollection<MyNote>(noteLoader.Load());
	}

	public void Save()
	{
		var noteLoader = ServiceLocator.Instance.Resolve<INoteLoader>();
		noteLoader.Save(MyNotes);
	}
}

 

As you can see, compared to the NoteManager we had in the Factory Pattern, this NoteManager is much more simplified and cleaner thanks to the ServiceLocator.

This is because ServiceLocator allows us to maintain a single instance of our services such as INoteLoader and INoteReader, thereby we do not have to worry about duplicating their instances, we could simply access them anywhere in our code.

You can see how its easily calling the ServiceLocator.Resolve<T> to retrieve the service instances. 🙂

Here’s how to access the above services in anywhere your PCL or Shared Project, and notice how we are directly accessing the service instance unlike in Factory Pattern thanks to the ServiceLocator.

ServiceLocator.Instance.Resolve<INoteReader>().Speak("Hello, read this!");

 

There you have it, now this clearly shows how easy it is to add more and more platform dependent services and use them in your shared code as you go on scaling up the project solution, all thanks to Service Locator Pattern! 😉 Altogether while simplifying the shared code compared to the Factory Pattern.

And keep in mind this is a well improved pattern over Factory Pattern, but it still depends on your requirement as to which one is best suited for your implement. 🙂

3. DEPENDENCY INJECTION with Xamarin Forms

Now this right here is like the holy grail or the most praised and most used pattern in our scenario. Dependency Injection is all about injecting dependencies to create a given object just as said by its name. This is all about automatically resolving the required dependencies at run time without having the client specifically looking it up and creating them and injecting them to the new object to be created. So we are delegating the whole dependency resolving to an automated mechanism, thus a very popular form of Inversion of Control principle, whereas a massive improvement over the Service Locator.

Service Locator is good enough, only for smaller scale projects, where as you register services manually and look them up on demand at run time. But when the project gets more bigger and complex, with a lot of inter-connecting service and dependencies, it is very hard to keep a track on all of them, and most likely you’ll up missing a whole bunch of required dependencies in your code. This is usually a common case when you move into patterns such as MVVM implement for your mobile project, where you deliberately loosely couple all the layers of your app project, and you could easily end up missing dependencies.

This is where Dependency Injection comes for the rescue, where as we inject the required dependencies in the constructor or as properties and delegate that whole process to an automated mechanism, which we call the “Container“. So whenever we implement a DI it always comes with a static singleton Container which manages all the dependencies and resolve them automatically at run time, and we just have to register the dependency mapping only with the container.

Now there’s so many kinds of Dependency Injection Containers out there for you to choose from, given the popularity of this pattern. Unity, Ninject, AutoFac, TinyIoC and so on are some examples. It’s also pretty straight forward to roll out our own, but for this demo I would use an existing DI Container, Unity, quite a popular counterpart in this space.

Alright then, first of all let’s add the Unity library to our solution.

Make sure to select your PCL project and all the platform specific projects when you’re adding Unity from nuget.

Let’s make use of the Dependency Injection with our IoC Container as below. Now there’s nothing to be changed in how you implement your abstract interfaces in your PCL shared project and concrete implementations in the platform specific projects. 🙂

Let’s create a static reference for our container instance.

public partial class App : Application
{
	// static DI Container instance
	public static UnityContainer Container { get; set; }

	public App()
	{
		InitializeComponent();
		MainPage = new NavigationPage(
                                new XFMyNotesAppDI.NoteListPage());
	}
	
	...
}

 

Next here’s our NoteManager which is going to handle basic Note managing functions such as loading and saving notes. 🙂 You might see something different than what we had in Service Locator.

public class NoteManager
{
	private readonly INoteReader _noteReader;
	private readonly INoteLoader _noteLoader;

	public IList<MyNote> MyNotes { get; private set; }
	
	public NoteManager(INoteLoader noteLoader, 
                                    INoteReader noteReader)
	{
		_noteReader = noteReader;
		_noteLoader = noteLoader;
		
		MyNotes = new 
                  ObservableCollection<MyNote>(_noteLoader.Load());
	}

	public void Save()
	{
		_noteLoader.Save(MyNotes);
	}
}

 

As you can see we are passing in the INoteLoader and INoteReader services to the constructor of the NoteManager, this means that NoteManger cannot exist without those parameters services. So what happens here is that, when we request an instance of the NoteManager, the IoC Container (Unity Container) will resolve those depending services instances and inject them into the NoteManager, whilst creating the NoteManager.

Look how simple and clear the NoteManager is compared to our Service Locator and Factory Pattern principles.

Also you can see that we are no longer maintaining a singleton static reference to the NoteManager like how we did in Service Locator, because we could do the same thing directly using our IoC Container as shown below. 🙂

public App()
{
	InitializeComponent();

	// resolve the NoteManager instance
	App.Container.RegisterType<NoteManager>(
                        new ContainerControlledLifetimeManager());
					 
	MainPage = 
             new NavigationPage(newXFMyNotesAppDI.NoteListPage());
}

 

That’s how we are registering our NoteManager instance with the container, and we are instructing the container to retain a single instance of it by passing in the ContainerControlledLifetimeManager() type object to it. Also its good to keep in mind there are several object life time management types in Unity Container which you could play around with.

One of the coolest things about IoC containers is that we could instruct it to how we need a certain object or a type should be managed in the run time of the app. 😉 Oh yeah, cool indeed!

Now with our Unity Container this is how you would register your Service Interfaces (INoteReader and INoteLoader) with their concrete implementations on the platform specific level.

Also something to keep in mind is that we need to instantiate our UnityContainer instance here in the platform specific level where the execution begins. 🙂

// Android implementation
protected override void OnCreate(Bundle bundle)
{
	TabLayoutResource = Resource.Layout.Tabbar;
	ToolbarResource = Resource.Layout.Toolbar;

	base.OnCreate(bundle);

	global::Xamarin.Forms.Forms.Init(this, bundle);
	
	App.Container = new UnityContainer();
	App.Container.RegisterType<INoteLoader, NoteLoaderDroid>();
	App.Container.RegisterType<INoteReader, NoteReaderDroid>();

	LoadApplication(new App());
}

// iOS implementation
public override bool FinishedLaunching(UIApplication app, NSDictionary options)
{
	global::Xamarin.Forms.Forms.Init();

	App.Container = new UnityContainer();
	App.Container.RegisterType<INoteLoader, NoteLoaderIos>();
	App.Container.RegisterType<INoteReader, NoteReaderIos>();

	LoadApplication(new App());

	return base.FinishedLaunching(app, options);
}

// UWP implementation
public App()
{
	XFMyNotesAppDI.App.Container = new UnityContainer();
	XFMyNotesAppDI.App.Container.RegisterType<INoteLoader, NoteLoaderUwp>();
	XFMyNotesAppDI.App.Container.RegisterType<INoteReader, NoteReaderUwp>();

	this.InitializeComponent();
	this.Suspending += OnSuspending;
}

 

Thanks to the IoC Container you could easily access the NoteManager anywhere in your code, which will give you access to the static retained instance.

NoteManager _noteManager = App.Container.Resolve<NoteManager>();

 

And of course the services as well.

App.Container.Resolve<INoteReader>().Speak("Hello, read this!");

 

There you have it, now this clearly shows how easy it is to add more and more platform dependent services and use them in your shared code as you go on scaling up the project solution, all thanks to Dependency Injection Pattern! 😉

Specially you noticed how it simplifies our shared code compared to the Service Locator pattern. Also its worth it to notice, how using an IoC Container brings many useful features to the table that you could use to improve your code.

So again, which one should I use?

Now that should have given you a very good comparison between the use of,

  • Factory Pattern
  • Service Locator Pattern
  • Dependency Injection Pattern

Each one of those patterns have their own advantages and disadvantages, yet you may have noted a general aspect improvement over each other such as Factory Pattern < Service Locator Pattern < Dependency Injection Pattern. Let’s break it down as below.

Considering some of the negative aspects of NoteManager implementation in each pattern,

in Factory Pattern we had,

  • Maintain static singleton access to NoteManager
  • Maintain static references to the INoteLoader and INoteReader service objects
  • Use NoteManager to access INoteLoader and INoteReader service objects
  • Resolve INoteLoader and INoteReader service objects manually

in Service Locator Pattern we had,

  • Maintain static singleton access to NoteManager
  • Resolve INoteLoader and INoteReader service objects manually

in Dependency Injection Pattern we had,

  • none of the above issues

So there you can clarify my claim of general improvements over each pattern, Factory Pattern < Service Locator Pattern < Dependency Injection Pattern.

Although that’s being said, the choice of Pattern to follow is totally up to you and your requirements. As an example something like Factory Pattern or Service Locator Pattern would be good enough for a small scale projects and Dependency Injection would be perfect for large scale projects with heavy MVVM based apps which uses a lot of service dependencies and so on.

Conclusion?

So I hope my demonstration of each of the patterns and how to implement them properly in a Xamarin Forms project solution for the same app concept, may have helped you in deciding which patterns to be used in any given scenario, which uses cross-platform dependencies.

Oh once again, You may find the complete solution up on my Github repo: https://github.com/UdaraAlwis/XFCPMobilePatterns

Go ahead and play around with the app and check out how each pattern is used in the MyNotes App scenario! 😉

Cheers everyone! 😀

Advanced decorating of Xamarin Forms Slider for Android…

Alright so today I’m gonna take you guys through a journey of decorating a Xamarin Forms Slider control in Android…

Well we all know how basic the default Slider control in Xamarin Forms, but worry not, there are plenty of ways to decorate it with awesome features,specifically for Xamarin Android! 😀

It all started a few weeks back when I was playing around with the Slider control to add  a whole bunch of complex visual features in one of my company apps.

Let’s get started…

Alright, first thing first, we need set up our Custom Slider control first and attach it’s Custom renderer in Android.

So here goes the Custom Slider control subclassing in Xamarin Forms project…

namespace WhateverYourNamespace
{
    public class CustomSlider : Slider
    {

    }
}

 

Next set up the Custom Slider Renderer in your Android project…

[assembly:ExportRenderer(typeof(CustomSlider), typeof(CustomSliderRenderer))]
namespace WhateverYourNamespace.Droid
{
    public class CustomSliderRenderer : SliderRenderer
    {
        protected override void
                 OnElementChanged(ElementChangedEventArgs<Slider> e)
        {
            base.OnElementChanged(e);

            if (e.NewElement != null)
            {
		// All the customization will go here
            }
        }
    }
}

 

How would I consume this in XAML you ask? Just as another ordinary view… 😉

<StackLayout>

	<local:CustomSlider 
	HeightRequest="7" 
	WidthRequest="350" 
	HorizontalOptions="Center"
	Minimum="0" Maximum="100" />

</StackLayout>

 

Now keep in mind all the customization that we are doing later will be done within this custom renderer.

Something to keep in mind is that,

the Xamarin Forms Slider control’s Android run time native counterpart is the SeekBar…

So the more you aware of the SeekBar’s properties, the more customization you could play around with! 😉

Alright let’s start decorating… 😀

Decoration 1 : Change color theme!

Want to change the color theme of your Slider? Here we go…

Let’s see the code.

if (e.NewElement != null)
{
	// progressbar and progressbar background color
	Control.ProgressDrawable.SetColorFilter(
		new PorterDuffColorFilter(
		Xamarin.Forms.Color.FromHex("#ff0066").ToAndroid(),
		PorterDuff.Mode.SrcIn));
}

 

Use the ProgressDrawable Property and set the ColorFilter to it as you wish… 😉 which will set the color theme to your Progress Bar , Progress Thumb, and the background bar…

Decoration 2 : Change only the Slider’s Thumb Color?

How about changing just the Progress Thumb’s color? Yes you may…

Look at that funky looking Progress Thumb! 😉

Code?

if (e.NewElement != null)
{
	// Set Progress bar Thumb color
	Control.Thumb.SetColorFilter(
		Xamarin.Forms.Color.FromHex("#8000ff").ToAndroid(), 
		PorterDuff.Mode.SrcIn);
}

 

Android SeekBar (which is the native handler of Xamarin Forms Slider on Android) has the Thumb property which allows you to customize the appearance of the little thumbnail head of the Slider control as we have used above.

Next! 😀

Decoration 3 : Change progress background Color?

How about changing only the Progress Bar’s background color? As you can see below..

Look at the boring default progress bar’s background color vs the purple background color! 😉 pretty cool!

Here’s how you do it,

if (e.NewElement != null)
{
	//Set Background Progress bar color
	Control.ProgressBackgroundTintList 
           = ColorStateList.ValueOf(
            Xamarin.Forms.Color.FromHex("#8000ff").ToAndroid());
	Control.ProgressBackgroundTintMode
           = PorterDuff.Mode.SrcIn;
}

 

Use the ProgressBackground property to set the TintList and the TintMode! 🙂

TADAA!

Decoration 4 : How about adding a secondary progress indicator?

Now we all have seen secondary progress indicators in progress bars, specially in online video stream players… 🙂 example take the Youtube player! 😉 So have you ever wanted to add such a cool feature to your Xamarin Forms Slider in Android? Let me show you how its done… 😉

Look how cool that is yeah! 😉

Alright let’s get into coding…

Now in Android we have this built in property called SecondayProgress which allows you to set a secondary progress value to your Slider or Seekbar as of native Android handler.

if (e.NewElement != null)
{
	// secondary progress value in Xamarin Forms units
	int secondaryProgressValue = 50;
	
	// secondary progress value in 
	// Android native Seekbar units
	int secondaryProgressValueInAndroidUnits =
	(int)((secondaryProgressValue - 
			((CustomSlider)Element).Minimum) /
	(((CustomSlider)Element).Maximum -  
			 ((CustomSlider)Element).Minimum) * 1000.0);

	// set the secondary progress value
	Control.SecondaryProgress = 
	secondaryProgressValueInAndroidUnits;
}

 

There you go, you can see that we are setting the SecondaryProgress value, but also take a closer look at the calculation that we are doing before setting it.

Now Xamarin Forms Slider and Xamarin Android Seekbar which is the handler for the Slider control, uses different value types or unit types for setting the Progress and the Secondary Progress values in native level. If we want to set the value from Xamarin Forms value units then we need to convert that value to Android Seekbar’s native values which is exactly what we are doing at the calculation. So basically we are setting the Xamarin Forms unit value according to the native units to Seekbar control.

Oh if you want to set the Secondary Progress from Xamarin Forms level then you can easily create a property in the CustomSlider class and use it down here in your Custom Renderer class 🙂 Imagination is the limit! 😉

Decoration 5 : May be change the Color of secondary progress indicator?

How about we spice it up by changing the color a little of the secondary progress? 😉

Look at that!

Time for coding…

Android Seekbar has this property called SecondaryProgressTintList and SecondaryProgressTintMode which allows you to achieve the above results and set the secondary progress color as you wish…

if (e.NewElement != null)
{
	//Set Seconday Progress bar color
	Control.SecondaryProgressTintList = 
	      ColorStateList.ValueOf(
		Xamarin.Forms.Color.FromHex("#8000ff").ToAndroid());
	Control.SecondaryProgressTintMode = 
	      PorterDuff.Mode.SrcIn;

	// secondary progress value in Xamarin Forms units
	int secondaryProgressValue = 50;
	
	// secondary progress value in 
	// Android native Seekbar units
	int secondaryProgressValueInAndroidUnits =
	(int)((secondaryProgressValue - 
	((CustomSlider)Element).Minimum) /
	(((CustomSlider)Element).Maximum - 
	 ((CustomSlider)Element).Minimum) * 1000.0);

	// set the secondary progress value
	Control.SecondaryProgress = 
		secondaryProgressValueInAndroidUnits;
}

 

And hey of course don’t forget to set the SecondaryProgress value while you’re at it!

Decoration 6 : I would call it Funky delight!

Alright, now all that being said, how about blending some of those different colors adding some funky delight-ness to the Slider? 😉

Well what I mean is, let’s try adding different color’s to Thumb, Progress Bar, Progress Bar background and Secondary Progress Bar!

Too much funky? I thought so!

How about these??? 😉

I know, I love playing with colors being a Visual oriented developer! 😀 lol

Your imagination is the limit fellas!

Here’s how you play around with the colors…

if (e.NewElement != null)
{
	// Different colors for ProgressBar components
	// Set Primary Progress bar color
	Control.ProgressTintList = 
		ColorStateList.ValueOf(
		Xamarin.Forms.Color.FromHex("#6200ea").ToAndroid());
	Control.ProgressTintMode 
		= PorterDuff.Mode.SrcIn;

	//Set Seconday Progress bar color
	Control.SecondaryProgressTintList = 
		ColorStateList.ValueOf(
		Xamarin.Forms.Color.FromHex("#b388ff").ToAndroid());
	Control.SecondaryProgressTintMode 
		= PorterDuff.Mode.SrcIn;

	//Set Progress bar Background color
	Control.ProgressBackgroundTintList = 
		ColorStateList.ValueOf(
		Xamarin.Forms.Color.FromHex("#b39ddb").ToAndroid());
	Control.ProgressBackgroundTintMode 
		= PorterDuff.Mode.SrcIn;

	// Set Progress bar Thumb color
	Control.Thumb.SetColorFilter(
		Xamarin.Forms.Color.FromHex("#311b92").ToAndroid(),
		PorterDuff.Mode.SrcIn);
}

 

Decide your flavor of colors and go crazy fellas! 😉

Decoration 7 : Remove Thumb Header may be?

Absolutely, check this out…

It’s pretty simply actually, simply set a Tranparent ColorDrawable to the Thumb property.

if (e.NewElement != null)
{
	// Hide thumb
	Control.SetThumb(
		new ColorDrawable(Color.Transparent));
}

 

Woot!

Decoration 8 : Let’s kick it up a notch!

Let’s add some more vibrant and complex customization to our Slider for Android! 🙂

How about throwing in some cool gradient effects…

So to achieve that, we shall be using Android native Styling with Drawables such as Shape, Gradients and so on.

We will create a native android xml Style file in your Resources/Drawable folder with the name “custom_progressbar_style.xml”

Here’s what you’ll be placing inside of it…

<layer-list xmlns:android="http://schemas.android.com/apk/res/android" >

  <item android:id="@android:id/background">
    <shape>
      <corners android:radius="15dip" />
      <gradient
       android:startColor="#d9d9d9"
       android:centerColor="#e6e6e6"
       android:endColor="#d9d9d9"
       android:centerY="0.50"
       android:angle="270" />
    </shape>
  </item>
  
  <item android:id="@android:id/secondaryProgress">
    <clip>
      <shape>
        <corners android:radius="15dip" />
        <gradient
             android:startColor="#e6b3e6"
             android:centerColor="#ffcce0"
             android:endColor="#e6b3e6"
             android:centerY="0.50"
             android:angle="270" />
      </shape>
    </clip>
  </item>
  
  <item android:id="@android:id/progress">
    <clip>
      <shape>
        <corners android:radius="15dip" />
        <gradient
         android:startColor="#ff0066"
         android:centerColor="#ff00ff"
         android:centerY="0.50"
         android:endColor="#cc0052"
         android:angle="270" />
      </shape>
    </clip>
  </item>
  
</layer-list>

 

So to explain the above a little bit, we have created a Style layer-list which assigns the given styling items to the specific id’s of the SeekBar native control, such as the background, secondaryprogress, progress as you have noticed. Those drawable objects will replace the default styles of those segments in the SeekBar with these defined drawable objects.

First we are using a Shape drawable to to the Background property, which creates a gradient layer with the given colors and angle for creating a gradient effect! Also we are setting a radius value to corner so that the corners will be curved nicely.

Next for the Progress and the SecondaryProgress properties we are creating a similar Shape gradient as before but we are clipping it according to the given values of each of them.

if (e.NewElement != null)
{
	// Set custom drawable resource
	Control.SetProgressDrawableTiled(
	Resources.GetDrawable(
	Resource.Drawable.custom_progressbar_style,
	(this.Context).Theme));

	// Hide thumb to make it look cool lol
	Control.SetThumb(new ColorDrawable(Color.Transparent));
}

 

There’s how you set it in the custom renderer level, simply call the SetProgressDrawableTiled() method by passing the custom style of what we created above.

Also I have disabled the Thumb, just to make it look cooler. Its up to you though.

If you want to do more extensible customization like above and may be preserve the Thumb view and style that as well? then refer to this stackoverflow article: http://stackoverflow.com/questions/16163215/android-styling-seek-bar

Additionally you could have bitmap images or nine patch images as drawables to styling and so may other stuff.

Now this is like the holy grail.. where as you can see with Android you get full flexibility for any kind of complex customization!

Its only limited by your imagination! 😉

WooT! 😀

Decoration 9 : Can I reduce the above overridden Height?

So you’re worried of the height after setting the custom styling drawables as above? simply reduce the HeightRequest value in your Xamarin Forms code for our custom Slider view.

Right after we set the Custom ProgressDrawable styles in the renderer level, it overrides the Height property of native SeekBar  that’s assigned from Xamarin Forms level for each of those sub-views (ProgressBar, SecondaryProgressBar and Background sub views), so they expands themselves to the fullest as possible with the new Drawable objects.

<local:CustomSlider HeightRequest="7" WidthRequest="350"  HorizontalOptions="Center"
        Minimum="0" Maximum="100" />

 

So the above should give you control over the Height issue!

Or else you could set the dip IntrinsicHeight values in your XML style drawables itself as well (something extra)! 😉

Decoration 9 : Can I  have the above cool-ness programmatically without resources?

So you don’t like to deal with Android Resources and creating the Style XMLs and stuff?

Oh sure, no worries! but you will have to do a little bit of work to get the above simple XML Styling into pure code generated objects!

Let me begin by giving credit to this example written in Java which I found while I was in the same situation: FlatUI/FlatSeekBar.cs

So let’s see how we could create Drawable Style objects in C# code!

Now keep in mind all the Drawable objects we used in our XML file “custom_progressbar_style.xml” has their own programmatical counterparts such as Shape, Gradient and Clip by the names as ShapeDrawable, GradientDrawable, and ClipDrawable and so on likewise.

So we can convert any given XML style to a C# generated style drawable. (any native Android developer should be well aware of this)

So let’s do something similar! 😉

So we are going to create our own Drawable objects and set them to the sub-views of our Slider control for Android, just like how we did with the XML styling, but this time programmatically. Here is how it will look like…

There you haveit, let’s see how we did this…

if (e.NewElement != null)
{
	// Setting drawable styling programatically

	// progress
	var progress = new PaintDrawable(Color.Red);
	progress.SetCornerRadius(
		(int)DpToPixels(this.Context, 10));
	progress.SetIntrinsicHeight(
		(int)DpToPixels(this.Context,10));
	var progressClip = 
		new ClipDrawable(progress, GravityFlags.Left,
		ClipDrawableOrientation.Horizontal);

	// secondary progress
	var secondary = new PaintDrawable(Color.Gray);
	secondary.SetCornerRadius(
		(int)DpToPixels(this.Context, 10));
	secondary.SetIntrinsicHeight(
		(int)DpToPixels(this.Context, 10));
	var secondaryProgressClip = 
		new ClipDrawable(secondary, GravityFlags.Left, 
		ClipDrawableOrientation.Horizontal);

	// background
	PaintDrawable background = new 
                 PaintDrawable(Color.LightGray);
	background.SetCornerRadius(
		(int)DpToPixels(this.Context, 10));
	background.SetIntrinsicHeight(
		(int)DpToPixels(this.Context, 10));

	// retrieve LayerDrawable reference of the SeekBar control
	LayerDrawable layeredDrawableReference 
		= (LayerDrawable)Control.ProgressDrawable;
		
	// apply our custom drawable objects to the 
	// given sub-views through their IDs
	layeredDrawableReference.
	    SetDrawableByLayerId(
		Android.Resource.Id.Background, background);
	layeredDrawableReference.
	    SetDrawableByLayerId(
		Android.Resource.Id.Progress, progressClip);
	layeredDrawableReference.
	    SetDrawableByLayerId(
		Android.Resource.Id.SecondaryProgress, 
                  secondaryProgressClip);
}

 

So basically we are creating our our Drawable objects programatically, in this case PainDrawable objects and giving them different styling values such as Radius, Clipping, IntrinsicHeight and so on.

And then at the end we are going to retrieve the references for the sub-views of our native SeekBar in Android which is the after-rendering counterpart of Xamarin Forms Slider as I mentioned at the beginning. This is going to be a LayerDrawable object, which is going to allow us to set our own custom Drawable objects to each drawable layer by their IDs.

As you can see we are calling the SetDrawableByLayerId() on our LayerDrawable object and passing in the each sub-view reference and custom drawable objects we want to set to them. 😀

Now keep this in mind, here you could have any kind of drawable objects to create your custom drawable styling just like you previously did with GradientDrawable in XML style, have the exact same beautiful visual result rendered programatically! 🙂

That’s it…

Well fellas that’s it for now, well at least that’s all I came across while I was playing around with my Custom Renderer for Xamarin Forms Slider on Android! 😀

Enjoy and share!

CHEERS!

Let’s resize a Bitmap and UIImage with Xamarin…

Since the beginning of computers, developers has been struggled with Images. So did I with Xamarin 😉

So here I am sharing my findings on resizing a Bitmap and UIImage respectively on Android and iOS, meanwhile preserving the aspect ratio. I’m sharing this for the ease of fellow Xamarin devs, if anyone is struggling to find a source to find solution for both Xamarin Android and iOS platforms.

Xamarin Android

Alright here goes resizing of a Bitmap on Xamarin Android, and please note that I merely convered this implementation from Java to C# when I was implementing it in my project, and here’s the reference for it : http://stackoverflow.com/a/8224161

You need to pass in the height and width you need to resize your Bitmap into. Also as you can see this resizing method scales up the Bitmap on the Y Axis, and scaling begins from the center of the Image. 🙂

private Bitmap ResizeBitmap(Bitmap originalImage, int widthToScae, int heightToScale)
{
	Bitmap resizedBitmap = Bitmap.CreateBitmap(widthToScae, heightToScale, Bitmap.Config.Argb8888);

	float originalWidth = originalImage.Width;
	float originalHeight = originalImage.Height;

	Canvas canvas = new Canvas(resizedBitmap);

	float scale = this.Width / originalWidth;

	float xTranslation = 0.0f;
	float yTranslation = (this.Height - originalHeight * scale) / 2.0f;

	Matrix transformation = new Matrix();
	transformation.PostTranslate(xTranslation, yTranslation);
	transformation.PreScale(scale, scale);

	Paint paint = new Paint();
	paint.FilterBitmap = true;

	canvas.DrawBitmap(originalImage, transformation, paint);

	return resizedBitmap;
}

 

Xamarin iOS

So below is what I used for UIImage on iOS, which I was lucky enough to find through the Xamarin Forum: https://forums.xamarin.com/discussion/comment/175585/#Comment_175585 So kudos to the original post! 🙂

public UIImage ResizeUIImage(UIImage sourceImage, float widthToScale, float heightToScale)
{
	var sourceSize = sourceImage.Size;
	var maxResizeFactor = Math.Max(widthToScale / sourceSize.Width, heightToScale / sourceSize.Height);
	if (maxResizeFactor > 1) return sourceImage;
	var width = maxResizeFactor * sourceSize.Width;
	var height = maxResizeFactor * sourceSize.Height;
	UIGraphics.BeginImageContext(new CGSize(width, height));
	sourceImage.Draw(new CGRect(0, 0, width, height));
	var resultImage = UIGraphics.GetImageFromCurrentImageContext();
	UIGraphics.EndImageContext();
	return resultImage;
}

 

Well there you have it.

Enjoy! 😀

An infamous(or not?) fact(something important?) about Xamarin Forms Navigation in Android…

Xamarin Forms uses a very neat and simplified Navigation Architecture which can be easily justified among Android, iOS and WinPhone mobile platforms under common grounds.

Xamarin Forms Navigation

Alright, now this is not an article about Xamarin Forms Navigation article, as it is very well explained in Xamarin official documentation. If you want to go check it out right now before you get into this article. https://developer.xamarin.com/guides/xamarin-forms/user-interface/navigation/hierarchical/

Now the way Xamarin Forms handles this navigation during the actual runtime, specifically in native levels are different for each mobile platforms. Of course they have to somehow map Xamarin Forms Navigation paradigm to the Native app navigation paradigm, which is extremely complex and Xamarin has done a great job so far. 😀

Why is Navigation so Important?

Navigation plays a huge part in your Mobile Application development, specially when it becomes more complex when you need to implement deeper customisations to your cross platform app.

So when we get down to complex customisations related to your Navigation, it is very important to be aware of the underlying mechanics of the platform.

Hence with Xamarin Forms, we are dealing with a cross-platform situation, where it is very crucial that we pay attention to three different mobile platforms, and how their navigation is actually handled in Xamarin Forms.

Xamarin has done a great job in handling a common cross-platform navigation pattern, and faded out the Native-compatibility mechanics to the background, to the point a developer doesn’t really have to pay any attention to it. So kudos Xamarin! 😉

Recently I…

So the reason I’m writing this article is because, recently I came across a situation where I had to pay detailed attention for Xamarin Forms Navigation and how it actually handles it in native execution. 🙂

And there’s something very interesting I spotted in how Xamarin Forms handles Navigation in Android runtime..

So I thought of sharing it with everyone, hence most developers doesn’t seem to be aware of this.

Specially amongst the fresh developers of the Xamarin Community, where a lot of developers assume Xamarin Forms follows everything exactly as the Native Framework patterns and properties, which is not actually accurate and they have taken some unique (or may be different) approaches for mapping Native stuff to the Xamarin Forms level, which are quite out of the box. So you need to pay a good attention to their details when you are dealing with complex implementations in Xamarin Forms.

So what’s the big deal I found with Xamarin Forms Navigation in Android ?

Xamarin Forms Navigation in Android?

Now when it comes to handling Xamarin Forms Navigation in Android run time, I noticed something very interesting, which I should blame myself for not paying any attention way earlier for this aspect. However…

If you’re familiar with Native Android development, the standard pattern of how we navigate in-between Activities and Fragments, how the activity lifecycle is handled so on and so forth yeah? (Nope, I’m not gonna get into the details of Android Navigation pattern in this article, if you aren’t aware, please stop reading this article and Google about it, then you may get back here… other wise you might get confused!)

Now have you ever thought how Xamarin Forms actually handles this complex Android Navigation Pattern? And actually map the Xamarin Forms Navigation paradigm to the Native Android Execution?

Now this is where it gets interesting…

Go on to this link which explains the NavigationPage (the page that manages the navigation) of Xamarin Forms, and read the REMARKS! READ IT!

https://developer.xamarin.com/api/type/Xamarin.Forms.NavigationPage/

Let me quote it,

“Note that on the Android platform, INavigation operations do not generate activity lifecycle notifications. For each Page that you push or pop, the Android implementation of NavigationPage simply adds or removes the content of the page to or from a single activity.”

Interesting right?

Now I did some more research about it, and came across more interesting facts.

At Xamarin Evolve 2014…

Watch this Youtube clip where an attendee asks Jason Smith about the Navigation pattern of Xamarin Forms in Android.

Attendee: I was curious why you designed the Xamarin Forms Android to be a Single Activity as opposed to Multiple Activity?

Jason: Couple of minor considerations I guess. At the time Fragments weren’t fully back ported when we started the project. So we couldn’t actually target Fragments, which was really annoying. And Google was advocating the Single Activity approach and on top of that Navigations Paradigms of Activity didn’t fully map to the Xamarin Forms Navigation Paradigm.

Furthermore from Jason Smith…

So I found a post in Xamarin Forms Community Forum  where Jason Smith has commented regarding the navigation further more a s follows…

https://forums.xamarin.com/discussion/17668/running-xamarin-forms-as-one-single-activity-vs-performance-design

TheRealJasonSmith [Jason Smith]

“Xamarin.Forms pre-dates the backporting of Fragments on Android, however it is written in a fashion similar to how fragments work. The Views we add/remove from the view hierarchy are fully cleaned up and disposed of when they go away. This works around the standard issue people had with single activity apps where all the views would stick around eating lots of memory.

Even if you as the user pre-allocate all of your Xamarin.Forms views, we do not realize them into actually android objects until they are needed on screen. We then will remove and dispose those same objects dynamically when they are no longer needed. This means that you should not be paying a significant memory overhead, even if you are not mindful of this yourself.”

So now what does this all tell us?

So after all these findings what is the conclusion we could come to?

In Native Android Development…

Untitled-3

When we develop Native Android application we usually use the standard Multiple Activities approach to propagate the pages and to navigate in between them, and sometimes we throw in some Fragments here and there as needed for memory saving and re-usability.

There is also an approach called “Single Activity Architecture” approach where you maintain only one activity and render all the pages on top of it in Native Android development.

Xamarin Forms Navigation in Android?

Untitled-2

Short and sweet Xamarin Forms does not follow the same standard multiple activity pattern in Android

Instead,

Xamarin Forms uses a unique Single Activity Architecture based pattern in Android which is similar to the use of Fragments, but with a better management of memory with its approach…

As with all our findings this is quite a unique approach that Xamarin Forms has implemented under the hood for Android. Which is very important to keep in mind when you get down to complex implementation of Xamarin Forms in Android.

Advantages and also Disadvantages ?

This gives many advantages and also disadvantages for us developers. Advantages such as good memory management, ease of navigation, instead of dealing with Activities and Fragments directly.

But this also brings many disadvantages which I had struggled in great deals with in Xamarin Forms complex implementations for Android, such as management of a custom ActionBar across your views, adding custom page transition animations for pages, unpleasant UX behavior when hiding ActionBar and so on.

But then again, there is always a way to solve problems in programming. 🙂

That’s it… 🙂

Well there you go, hope this clears any confusion anyone had just like I did sometime back… 🙂 And if you weren’t aware of this before, now you know how to handle stuff when it’s in need during your Xamarin Forms mobile development.

Cheers! 😀