Category Archives: Xamarin Hacks

XFHACKS-004 Editor with a Placeholder!

Ever wanted to have a Placeholder property for your Xamarin.Forms.Editor control? Welcome to another lightening short post of me hacking around Xamarin.Forms elements to build cool stuff and get sh*t done! 😉

By Default Xamarin.Forms.Editor is a pretty boring control with not much room for customization, but is a very useful control. So I had always wondered why it didn’t have a Placeholder property like we have to the Entry control.

So I thought of build an Editor with a Placeholder by myself, without any custom renderers or native code or third party libraries. 😉

Sneak Peak!

That’s what we gonna be build yol!

XFHACKS Recipe!

So this recipe is going to be a bit advanced one, although the basic here is also going to be what we’ve been using last few XFHACK articles, the stacking of Elements on top of each other! my favorite! 😀 lol

Let me begin with the concept of Placeholder, which is a text display that is visible in any Text Editable element until the user starts typing their input, and if the user clears his input the Placeholder comes back to visibility.

In simple terms we are going to stack a Label underneath our Editor control which will act as the “Placeholder” element and then we’re going to do some external handling to make that given Label to be set visible or invisible based on users text input typing event. The first part is pretty straightforward but the second part needs more explaining I assume. To do that we’re going to make use of the awesome Triggers in Xamarin.Forms, we’re going to implement a simple TriggerAction which will react to the event of Text field change of our Editor control. So inside the trigger execution we will set the Placeholder Label to be visible or invisible.

The Golden Triggers: So we’re going to use DataTriggers of Xamarin.Forms that allows us to listen to changes in a Data Field and react up on it, in this case the changes of the Text property of our Editor control. We’ll attach the DataTriggers to the Label and bind them to the Editor.Text property, then reacting on that our TriggerAction will hide or visible the Placeholder Label.

How easy is that eh!

Code!

Let’s start off by implementing our awesomely simple TriggerAction which will be handling the event of Editor’s text field change.

/// <summary>
/// A simple trigger to change a
/// View's visibility dynamically
/// </summary>
public class VisibilityTriggerAction
			: TriggerAction<View>
{
	public bool IsViewVisible { get; set; }

	protected override void Invoke(View sender)
	{
		sender.IsVisible = IsViewVisible;
	}
}

 

So we have a TriggerAction which can be reused anywhere to set a given View’s Visibility on demand, the reason I made it as a “View” type is exactly for the reason of reusability. So inside our Trigger we will be changing the value of IsViewVisible property to change the visibility of the Placeholder Label.

Behold the golden XAML code!

<!--  Editor with a Placeholder  -->
<Grid
      BackgroundColor="#b3ddff"
      HeightRequest="100"
      HorizontalOptions="Center"
      WidthRequest="250">

      <Label
            InputTransparent="True"
            Text="Type anything here..."
            TextColor="Gray">
            <Label.FontSize>
                  <OnPlatform x:TypeArguments="x:Double">
                        <On Platform="Android" Value="17" />
                        <On Platform="iOS" Value="17" />
                        <On Platform="UWP" Value="15" />
                  </OnPlatform>
            </Label.FontSize>
            <Label.Margin>
                  <OnPlatform x:TypeArguments="Thickness">
                        <On Platform="Android" Value="5,11,0,0" />
                        <On Platform="iOS" Value="4,9,0,0" />
                        <On Platform="UWP" Value="11,5,0,0" />
                  </OnPlatform>
            </Label.Margin>
            <Label.Triggers>
                  <!-- the DataTriggers 
                           reacts to Editor.Text changes -->
            </Label.Triggers>
      </Label>
      <Editor
            x:Name="editor"
            BackgroundColor="Transparent"
            TextColor="Black" />

</Grid>

 

There you have the Editor and the Label stacked on top of each other acting like a Placeholder for the Editor. Something important to note here is that, you can see the Margin property being set up in a bunch precise values, this was to align the Label’s text field with the text field of the Editor, so that they superpose each other nicely, which in returns gives the exact look and feel of a Placeholder property. 😉 In addition to that I have very carefully adjusted the default FontSize of the Label to match to the Editor’s! Smart eh!

So with that note, if you want to customize the Editor’s FontSize or Font itself, you need to make sure to do the similar changes accordingly to the underlying Label’s property to match the same appearance.

Now here’s the important bit, the golden Trigger. So we’re going to attach two DataTriggers, one for listening to the Editor.Text property’s null value instance (this is to be safe of null values in certain different platforms) and the other is for Editor.Text.Length property value changes. Based on those two instances we’re activating our Triggers accordingly with passing in the IsViewVisible value to it.

So here are the XAML of the DataTriggers we just spoke about, which you should plug into the above code!

<!--  the DataTriggers reacts to Editor.Text changes  -->
<DataTrigger
      Binding="{Binding Source={x:Reference editor}, Path=Text.Length}"
      TargetType="Label"
      Value="0">
      <DataTrigger.EnterActions>
          <triggers:VisibilityTriggerAction IsViewVisible="True" />
      </DataTrigger.EnterActions>
      <DataTrigger.ExitActions>
          <triggers:VisibilityTriggerAction IsViewVisible="False" />
      </DataTrigger.ExitActions>
</DataTrigger>
<DataTrigger
      Binding="{Binding Source={x:Reference editor}, Path=Text}"
      TargetType="Label"
      Value="{x:Null}">
      <DataTrigger.EnterActions>
          <triggers:VisibilityTriggerAction IsViewVisible="True" />
      </DataTrigger.EnterActions>
      <DataTrigger.ExitActions>
          <triggers:VisibilityTriggerAction IsViewVisible="False" />
      </DataTrigger.ExitActions>
</DataTrigger>

 

There you have it, we’re binding our DataTriggers to the Editor’s Text property according to the two instances we discussed of, and setting the VisibilityTriggerAction‘s value to hide or visible our Placeholder Label.

Now as usualy could also move that whole piece of XAML to a separate XAML file, so that you could set it up as a reusable Control in your project! 😉

Pretty straight forward eh!

Fire it up!

 

There you have it running on Android, iOS and UWP like a charm! 😀

Grab it on Github!

https://github.com/UdaraAlwis/XFHacks

Well then, that’s it for now. More awesome stuff on the way!

Cheers! 😀 share the love!

Advertisements

XFHACKS-003 Editor with a Border!

Ever wanted to have a Border around your Xamarin.Forms.Editor control? Welcome to another lightening short post of me hacking around Xamarin.Forms elements!

Sneak Peak!

That’s what we gonna be build yol!

XFHACKS Recipe!

The default Xamarin.Forms.Editor control is a very dull and simple control which doesn’t have much of customization properties of its own. In this case the Editor doesn’t even have a proper border around it that explicitly shows the edge of the element. So here we’re going to look into how to add a nice Border around Editor in Xamarin.Forms without any custom renderers or 3rd party libraries!

We all know the Frame control, which has a nice Border property, and also CornerRadius property allowing us to control the curves of the corner edges of it. This is the simple magic we’re going to use here. We’re going to wrap our Editor inside this Frame control. 😀

How simple and easy is that eh!

Code!

Behold the golden XAML code!

<!--  Editor with a Border Control  -->
<Frame
	Padding="5"
	CornerRadius="8"
	HasShadow="True"
	OutlineColor="#2196F3">
	<Editor BackgroundColor="Transparent" TextColor="Black" />
</Frame>

 

So there we go as we discussed the Frame is wrapping around the Editor control. So the Frame has been configured with CornerRadius property so we can have some nice round corners. Then the Padding has been reduced to 5 so we have less space between the border and the Editor view, this you may change as you wish. 😉

HasShadow property is something you could change as you wish, which you should keep in mind, behaves differently on iOS and Android.

Now just to add something extra, imagine if you wanted to have the whole background with a certain color for the given Editor, this is how simple it is!

<!--  Editor with a Border Control  -->
<Frame
	Grid.Row="4"
	Padding="5"
	BackgroundColor="#7fc5ff"
	CornerRadius="8"
	HasShadow="False">
	<Editor BackgroundColor="Transparent" TextColor="Black" />
</Frame>

 

We simply add the BackgroundColor property of the Frame and then you set the HasShadow to false so it doesn’t show up Border Color just for the kicks of it. 😀 So just like that you could easily customize this as you wish!

 Important: You could also move that whole piece of XAML to a separate XAML file, so that you could set it up as a reusable Control in your project! 😉

Fire it up!

There you have it running on Android and iOS like a charm!

Let me type something inside our “cool” Editor…

 

Grab it on Github!

https://github.com/UdaraAlwis/XFHacks

Well then, that’s it for now. More awesome stuff on the way!

Cheers! 😀 share the love!

XFHACKS-002 Button with an Icon!

Ever wanted to have an Icon element attached to a Xamarin.Forms.Button control? Welcome to another lightening short post of me hacking around Xamarin.Forms elements!

No custom renderers, no platform specific code and no third party libraries! Just by using pure out of the box Xamarin.Forms! 😉

Sneak Peak!

That’s what we gonna be build yol!

Now for something like that you’re going to assume we need some custom renderers or platform specific code or third party library use, but no no no! not on my watch! 😀

XFHACKS Recipe!

In this recipe we’re going to use the same concept that we used in the XFHACKS-001 article, stacking Elements on top of each other using Xamarin.Forms Grid Layout. So here we’re placing an Image on top of a Button.

Now you might wonder wouldn’t that void the touch event of the Button, since the Image will be covering a part of the Button touch area? Now that’s where the magic property called InputTransparent comes into play. Using this property we can disable the touch input interaction for any given View and pass it down to the next child underneath. 😀

Code!

Behold the golden XAML code!

<!--  Button with an Icon Control  -->
<Grid
	Grid.Row="1"
	HorizontalOptions="FillAndExpand"
	WidthRequest="200">

	<!--  Button Control  -->
	<Button
		Grid.Column="0"
		Grid.ColumnSpan="2"
		BackgroundColor="#2196F3"
		HorizontalOptions="FillAndExpand"
		Text="Click me!"
		TextColor="White" />

	<!--  Icon Image  -->
	<Image
		Grid.Column="1"
		Margin="0,0,10,0"
		HeightRequest="25"
		HorizontalOptions="End"
		InputTransparent="True"
		Source="{local:ImageResource
			XFHacks.Resources.dropdownicon.png}"
		VerticalOptions="Center"
		WidthRequest="25" />

        <Grid.RowDefinitions>
          <RowDefinition>
               <RowDefinition.Height>
                    <OnPlatform x:TypeArguments="GridLength">
                         <On Platform="Android" Value="50" />
                         <On Platform="iOS" Value="40" />
                         <On Platform="UWP" Value="40" />
                    </OnPlatform>
               </RowDefinition.Height>
          </RowDefinition>
        </Grid.RowDefinitions>
	<Grid.ColumnDefinitions>
		<ColumnDefinition Width="*" />
		<ColumnDefinition Width="35" />
	</Grid.ColumnDefinitions>
</Grid>

There you have it just like we discussed, inside the Grid we have a Button, and on top of that we have an Image, with our magical property InputTransparent set to true, which disables the touch events of the Image redirecting them on to the Button itself. So by this the whole Image and Button works as a single Button control.

I have given a little padding to the Image, so that the icon doesn’t corner itself in the Button. The Image has a fixed width and height of 25 units, and its set to the second column of the Grid, whereas the Button spreads across two columns filling up the entire space of the Grid. Thereby you can set any fixed size to the Grid itself or let it Fill up whatever the parent container its holding.

 Important: You could also move that whole piece of XAML to a separate XAML file, so that you could set it up as a reusable Control in your project! 😉

Pretty straight forward eh!

Fire it up!

  

There you have it running on Android, iOS and UWP like a charm!

Grab it on Github!

https://github.com/UdaraAlwis/XFHacks

Well then, that’s it for now. More awesome stuff on the way!

Cheers! 😀 share the love!

XFHACKS-001 Picker with an Icon!

Ever wanted to have an Icon element attached to a Xamarin.Forms.Picker control? Then you’re at the right place. Welcome to another lightening short post of me hacking around Xamarin.Forms elements!

Sneak Peak!

That’s what we gonna be build yol!

XFHACKS Recipe!

Usually you would think you need to implement a Custom Renderer to get this done or use a third party control! I say NO! NO! NO!

You can easily do this right from Xamarin.Forms without any native coding or 3rd party library, let me explain.

In a Xamarin.Forms Grid layout we could place Elements on top of each other, using this simple advantage, we’re going to place an Image as an icon under a Picker control, and of course we’ll be setting the Background color of the Picker to Transparent! 😉 Simple right?!

Code!

Behold the golden XAML code!

<!--  Picker with an Icon Control  -->
<Grid
     Grid.Row="1"
     HorizontalOptions="Center"
     WidthRequest="200">

     <!--  Icon Image  -->
     <Image
          Grid.Column="1"
          HeightRequest="25"
          HorizontalOptions="End"
          Source="{local:ImageResource XFHacks.Resources.dropdownicon.png}"
          VerticalOptions="Center"
          WidthRequest="25" />

     <!--  Picker Control  -->
     <Picker
          Title="Select a Monkey"
          Grid.Column="0"
          Grid.ColumnSpan="2"
          BackgroundColor="Transparent">
          <Picker.ItemsSource>
               <x:Array Type="{x:Type x:String}">
                    <x:String>Baboon</x:String>
                    <x:String>Capuchin Monkey</x:String>
                    <x:String>Blue Monkey</x:String>
                    <x:String>Squirrel Monkey</x:String>
                    <x:String>Golden Lion Tamarin</x:String>
                    <x:String>Howler Monkey</x:String>
                    <x:String>Japanese Macaque</x:String>
               </x:Array>
          </Picker.ItemsSource>
     </Picker>

     <Grid.RowDefinitions>
          <RowDefinition>
               <RowDefinition.Height>
                    <OnPlatform x:TypeArguments="GridLength">
                         <On Platform="Android" Value="50" />
                         <On Platform="iOS" Value="35" />
                    </OnPlatform>
               </RowDefinition.Height>
          </RowDefinition>
     </Grid.RowDefinitions>
     <Grid.ColumnDefinitions>
          <ColumnDefinition Width="*" />
          <ColumnDefinition Width="25" />
     </Grid.ColumnDefinitions>
</Grid>

 

There you have it just like we discussed in the recipe, we have placed our Picker control on top of the Image control, and we’re using a Grid to bring all of this together. If you look closely, we are using two columns, the Picker is spread across both columns, and the Icon Image is only added to the last column, with a fixed width of 25 units, thereby aligning the Icon to the right most corner of the Picker from underneath it. 😀

You can set the WidthRequest to whatever the value you prefer. And as of Platform specific values we’re setting the Grid Height accordingly to the best appearance of Android and iOS separately, you’re in full liberty to change them as you wish. 

Important: You could also move that whole piece of XAML to a separate XAML file, so that you could set it up as a reusable Control in your project! 😉

Pretty straight forward eh!

Fire it up!

 

There you have it running on Android and iOS!

Grab it on Github!

https://github.com/UdaraAlwis/XFHacks

Well then, that’s it for now. More awesome stuff on the way!

Cheers! 😀 share the love!

Welcome to XFHACKS Series!

Hello humans, welcome to my XFHACKS series, where I share my experience on hacking around the Xamarin.Forms environment and pushing the limits of it to get sh*t done, in all kinds of unexpected and creative ways! 😀

Specially I’m going to share my experience on implementing beautiful UI elements right from Xamarin.Forms, without any native implementations. The majority misconception is that in order to implement complex or highly customized UI elements with Xamarin.Forms, you often need to use a third party library or create custom renderers and do native customization, every single time!

I’m here to prove them wrong! There’s so many ways to implement complex and beautiful UI elements right from Xamarin.Forms out of the box without the need of any native renderers or third party libraries! 😀

Stay tuned fellas! Awesome stuff on the way!

Although I’m thinking of renaming the series name to HACKXAMFORMS though instead of XFHACKS!

Meh! I’ll think about it later! 😛

Cool Animating Dots Control from Xamarin.Forms Animations!

Three dots, blinking and pulsating sequentially made with pure Xamarin.Forms Animations! (no third party elements, heck not even any images used)

A little fun experimental-implementation I did a while back, actually based on something I did long time ago for an office project, but then figured out I could make it much better in a later time, so thought of working on it and putting it out there.

So basically we needed to have a Loading screen or Activity indicator screen with cool three dots animating sequentially, instead of using a GIF, I wanted to do this purely from Xamarin.Forms without any use of a 3rd party component, not even any image or icon.

Yes, I ended up hacking my way to get this done!

Here’s that interesting journey unfolding…

Xamarin.Forms.Animations is awesome!

This is something I need to get out of my chest. No one would actual believe this, but there’s so many awesome stuff you could do with the built in Animations of Xamarin.Forms right out of the box.

Surprisingly it’s super simple as well!

Sneak Peak!

So here’s what I’ve built and what you’re gonna get! 😉

TADAAA! pretty cool eh!

Let’s get started…

So before I get started, the requirement here is to build a reusable “Control” that we can embed into a ContentPage that we would be using as a “Loading Screen” or an Activity Indicator screen as some might call it. So this is going to be a separate reusable View which you can embed anywhere you want to and use it right away, which will be independent of it own, yes even the whole Animation sequence is self sustained by itself. 😉 Oh yeah! Cool stuff ahead! 😀

Building the UI..

First of all let’s go on create a ContentView control, let’s name it, AnimatingDotsControl!

What we need here is just simple “three dots”, but like I said in the beginning I don’t want to use any third party components or even external Image to emulate “a dot” element.

So what am I going to use for “a dot”? Xamarin.Forms.Frame! MIND BLOWN!

Let the Hack-be-unfolded!

Right on fellas, just another Xamarin.Forms hack of my own, Frame View has this awesome property called CornerRadius, which we are going to use for our advantage here, when its sufficiently set properly to the proportion of the width and height of it, voila! you render a circle or a dot in this case.

So let’s go on add three Frame elements horizontally inside a Grid view. And also to emulate the blinking, “on” and “off” state of a dot, we need to maintain two Frame elements to represent one dot each. We’re going stack them on top of each other, so when the first one goes to off state the second one in the background will come to visibility and emulate the off state. So for the ease of use let’s call our tiny little Frame elements, Dot1, Dot2 and Dot3 and lay them out nicely as we discussed.

<?xml version="1.0" encoding="UTF-8" ?>
<ContentView
    x:Class="XFAnimatingDotsControl.AnimatingDotsControl"
    xmlns="http://xamarin.com/schemas/2014/forms"
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml">
    <ContentView.Resources>
        <ResourceDictionary>
            <Style x:Key="AnimatingDotsStyle" TargetType="Frame">
                <Setter Property="Padding" Value="5" />
                <Setter Property="BackgroundColor" Value="White" />
                <Setter Property="CornerRadius" Value="6" />
                <Setter Property="HasShadow" Value="False" />
                <Setter Property="HorizontalOptions" Value="Center" />
                <Setter Property="VerticalOptions" Value="Center" />
                <Setter Property="HeightRequest" Value="4" />
                <Setter Property="WidthRequest" Value="4" />
            </Style>

            <Style
                x:Key="BackgroundDotsStyle"
                BasedOn="{StaticResource AnimatingDotsStyle}"
                TargetType="Frame">
                <Setter Property="BackgroundColor" Value="DimGray" />
            </Style>
        </ResourceDictionary>
    </ContentView.Resources>
    <ContentView.Content>
        <Grid ColumnSpacing="2" HorizontalOptions="Center">
            <Grid.ColumnDefinitions>
                <ColumnDefinition Width="25" />
                <ColumnDefinition Width="25" />
                <ColumnDefinition Width="25" />
            </Grid.ColumnDefinitions>

            <!--  Background Dots  -->
            <Frame Grid.Column="0" Style="{StaticResource BackgroundDotsStyle}" />
            <Frame Grid.Column="1" Style="{StaticResource BackgroundDotsStyle}" />
            <Frame Grid.Column="2" Style="{StaticResource BackgroundDotsStyle}" />

            <!--  Animating Dots  -->
            <Frame
                x:Name="Dot1"
                Grid.Column="0"
                Style="{StaticResource AnimatingDotsStyle}" />
            <Frame
                x:Name="Dot2"
                Grid.Column="1"
                Style="{StaticResource AnimatingDotsStyle}" />
            <Frame
                x:Name="Dot3"
                Grid.Column="2"
                Style="{StaticResource AnimatingDotsStyle}" />
        </Grid>
    </ContentView.Content>
</ContentView>

 

There you go. Just like we discussed we have our UI set up in a reusable ContentView control, just like we discussed above. Oh and don’t be worried by the use of Styles, I just like to make my XAML look neat and clean. 😉

Building the Animation!

Here’s the golden part of the whole post, the actual Animation magic brewed purely with Xamarin.Forms! Most people are aware only of the Xamarin.Forms Animation Extension methods, the typical FadeTo(), ScaleTo(), etc whatnot. But that’s just the tip of the ice berg I tell you! 😀

Here’s a little heads up if you’re not aware: Xamarin.Forms.Animation!
The whole Xamarin.Forms.Animation class itself has many more awesomeness possibilities, it allows us to create our own Animation sequences. Oh yeah! how cool is that eh!

These custom Animation objects can be attached to any Xamain.Forms.View and make them dance like whatever the ways we want, as in to animate any of its properties as we wish. They can sequentially change value of any property for any given period of time, even repeatedly. That is the whole bread and butter of this implementation. The Animation object constructor allows us to execute a sequential loop of an action with any given value, incremented or decremented, with the Easing properties, and finishing it with another action. Let’s use this for our advantage…

new Animation(alpha => Dot1.Opacity = alpha, 1, 0, Easing.CubicOut, () => Dot1.FadeTo(1))

 

So we’re going to using the Opacity property of our Frame view, and change its value from 1 to 0 in a loop, with an CubitOut Easing behavior, and reversing it back in the end of the execution, thus creating the blinking effect! 😀

And here’s the coolest part, you can actually attach an Animation object into another Animation object, and so on, so that you can execute a bunch animations sequentially across multiple views. Animation.Add() method gives you this awesomeness, where as you can define a starting point of the timeline and ending point for that specific animation object, in the whole animation sequence. So given our three animating elements, let’s break our timeline into 3 time chunks, giving each element a time span of 0.33 milliseconds.

var pulseAnimation1 = new Animation();

pulseAnimation1.Add(0, 0.33, new Animation(alpha => Dot1.Opacity = alpha, 1, 0, Easing.CubicOut, () => Dot1.FadeTo(1)));

 

So using that we’re going to animate three of our “dot views”, Dot1, Dot2 and Dot3, by attaching their own animation objects to a single Animation. We’re going to repeat the same above Add() call to Dot2 and Dot3 in the next step.

Before I get into the full animation code, the way we actually run this animation sequence is by calling the Animation.Commit() method, passing the parent View and some useful bits we could use to customize the animation sequence altogether.

private void RunAnimations()
{
	var pulseAnimation1 = new Animation();

	pulseAnimation1.Add(0, 0.33, new Animation(alpha => Dot1.Opacity = alpha, 1, 0, Easing.CubicOut, () => Dot1.FadeTo(1)));
	pulseAnimation1.Add(0.33, 0.66, new Animation(alpha => Dot2.Opacity = alpha, 1, 0, Easing.CubicOut, () => Dot2.FadeTo(1)));
	pulseAnimation1.Add(0.66, 0.99, new Animation(alpha => Dot3.Opacity = alpha, 1, 0, Easing.CubicOut, () => Dot3.FadeTo(1)));
	
	pulseAnimation1.Commit(this, 
		"loadingIndicatorPulseAnimation",
				10, 1100, null, null, () => true);            
}

 

So you can see how we have allocated each animation chunk 0.33 milliseconds and most importantly at the end the Commit() call, passing in the current view we’re attaching this animation to, the time in milliseconds between frames, the allocated time in milliseconds  for the whole animation sequence, and the null for easing and finishing action, since I’ve already defined them in the child animations themselves, and the last parameter, enabling the repeating functionality. So the animation will keep running forever as long as its active.

Now we have a self sustaining animation that runs repeatedly, but what if we want to stop it and discard it, in the case of the disposing or removing the View? that’s where AbortAnimation() call comes in.

// abort the animation on element disposing
this.AbortAnimation("loadingIndicatorPulseAnimation");

 

Remember we gave a little name to our animation? yeah that’s what we’re going to use and such a simple call the animation will stop and discard itself.

A true self sustaining Animation Control!

Alright! So now we have our full Animation implemented, the next thing we need to do is to make sure its self sustaining, since we’re going to use it inside an independent control.

So whenever the Control is attached to the UI or made visible, we need to make sure to start the Animation and when the Control is removed from UI or disposed, then we should stop the animation and dispose itself.

In order to do this we need to look into the life cycle of a Xamarin.Forms.View!

Let the Hack-be-unfolded!

So this is a little hacking around I came up with myself after overriding a bunch of methods and debugging the run time of Xamarin.Forms, where as when any given View gets attached to a parent or becomes visible, there’s an internal property that gets fired, which is called “Renderer”, even at the time of View goes out of visibility or removed from parent, the same property will get fired. I’m presuming this to a call to the native renderer of the View itself back and forth at runtime. I’m going to use this as Entry and Exit points for managing our Animation.

We shall override the OnPropertyChanged event of our ContentView and watch out for the “Renderer” property change, maintain a little flag to mark down our Animation started and ended state.

public partial class AnimatingDotsControl : ContentView
{
     public AnimatingDotsControl()
     {
          InitializeComponent();
     }

     private bool _animationStarted;
     
     protected override void 
          OnPropertyChanged(
               [CallerMemberName] string propertyName = null)
     {
          base.OnPropertyChanged(propertyName);

          if (propertyName == "Renderer")
          {
               if (!_animationStarted)
               {
                    // start the animation on element rendering
                    _animationStarted = true;

                    RunAnimations();
               }
               else
               {
                    // abort the animation on element disposing
                    this.AbortAnimation(
                            "loadingIndicatorPulseAnimation");
               }
          }
     }

     private void RunAnimations()
     {
          ...    
     }
}

 

There you go, now we have a fully self sustaining animation which will start on its own when the Control is attached to a parent or made visible, and then dispose itself when the Control is removed from parent or made out of visibility! 😀

Let’s consume it!

No more waiting, let’s consume this bad boy!

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage
    x:Class="XFAnimatingDotsControl.LoadingScreen"
    xmlns="http://xamarin.com/schemas/2014/forms"
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
    xmlns:xfAnimatingDotsControl="clr-namespace:XFAnimatingDotsControl;assembly=XFAnimatingDotsControl"
    BackgroundColor="Gray">

    <Frame
        BackgroundColor="Transparent"
        HasShadow="False"
        HorizontalOptions="Center"
        OutlineColor="Transparent"
        VerticalOptions="Center">
        <StackLayout
           BackgroundColor="Transparent"
           Orientation="Vertical">
            <Label
                FontAttributes="Bold"
                FontSize="23"
                HorizontalOptions="Center"
                HorizontalTextAlignment="Center"
                Text="Loading"
                TextColor="White" />
            <!--  Embedding our Animating Dots Control  -->
            <xfAnimatingDotsControl:
                 AnimatingDotsControl HorizontalOptions="Center" />
        </StackLayout>
    </Frame>

</ContentPage>

 

There we have embeded our own AnimatingDotsControl into a ContentPage that we would be using as a “Loading Screen” or an Activity Indicator screen as some might call it. Then you could use that page as a Modal Page and make it visible or discard whenever you wish so. 😉

You can attach our little awesome Animation dots control anywhere as you wish and it will work out nicely like a charm, while behaving and maintaining itself.

 

That’s our bad boy in action on iOS and Android! 😀

Github it if yo lazy!

So all of this is hosted on my git repo: https://github.com/XFAnimatingDotsControl

Feel free to grab your copy if you’re too lazy to DIY! 😛

Imagination and creativity is your weapon against the odds, keep on pushing the limits and hacking your way through my fellow developer! That’s what makes us the “Developers”, we build cool stuff yol!

That’s it for today.

Cheers all! 😀 Share the love!

Advanced Prism Tab Navigation with MVVM & Test friendly manner in Xamarin.Forms!

If you’re looking for how to navigate inside a Xamarin.Forms Tab Page programatically in a MVVM friendly and Test-able manner, without having any XAML-Code-Behind garbage. Welcome to my post!

Keep in mind, since this is an advanced topic, there’s not going to be any step by step intro’s to Prism or MVVM or whatnot ;)!

Sneak Peak!

Here’s a little sneak peak of the outcome of it.

PERKS:

  • Switch between Child-Tabs when you are,
    • Coming into the TabbedPage
    • Already in the TabbedPage
    • Coming back to the TabbedPage
  • Fully MVVM compatible
  • Fully Test-able, yaay!
  • Binding, Commands and Interfaces FTW!
  • Almost no XAML-code-behind garbage
  • Coming back to the TabbedPage, the Child-Tab switching occurs only when the TabbedPage is actually visible

How cool is that eh! 😉

 

Woot! Let’s get started then…

My MVVM addiction…

You know me, I’m all about that MVVM & Test-able Software Architecture life forever yol! xD

Being hustling with one of the best dot net application craftsman, has made a massive impact on my perspective of software engineering, rather than just writing some code, putting some shit together and make it work. I’m extremely obsessed with architecture of any given application I develop now, long last extendability, and fully test driven approach. High quality, clean code with all of dot net standards and complete separation of Views and ViewModels.

Backstory…

So recently, I was working on this Xamarin.Forms application which was using Prism as the MVVM framework with a fully test driven architecture. There we had all of our Views and ViewModels separately implemented with a clean architecture, whereas we didn’t have a single line of extra XAML-code-behind garbage. 😛

So the requirement was to implement a TabbedPage and which should be able to switch between its Child-Tabs programatically at runtime, to be more specific, we should be able switch the selected Child-Tab when the user is:

  • Coming into the TabbedPage
  • Already in the TabbedPage
  • Coming back to the TabbedPage after navigating forward.

And the most interesting part was this we had to handle this in a fully MVVM and Testable manner. 😮

Now this would have been much easier, if you had taken out the whole MVVM and Test-first aspect out of the equation, with some dirty XAML-code-behind garbage you can easily handle this. But in this situation, I was backed against the wall, How on earth could anyone achieve this?

but as usual, I figured it out!

The Recipe time…

So here’s how I implemented it, in conclusion we’re going to use an Interface that will allow us to bridge the View-ViewModel separation and a Bindable property inside the TabbedPage, that will react to the changes of the ViewModel’s “SelectedTab” property.

That interface is going to be implemented into the ViewModel. Then through the ViewModel we’re going to register that whole instance in our IoC container, when the user navigates into the TabbedPage. The bindable-property of the TabbedPage will be bound to the property in ViewModel. 😀

Which will allow us to access the interface instance from the IoC container from anywhere in our code and change the Selected Child-Tab.

Oh also I forgot to mention that with Prism, by default we can set the selected Tab-Child when we ‘first navigate into the Tab Page’, so handling that scenario is going to be a no-brainer, thus I will not focus on it in this post.

We shall work on navigating inside the TabbedPage when we’re already inside it, and when we’re coming back to the TabbedPage from another page after navigating forward. Which is going to be a piece of cake with our interface implementation approach.

Just to add something extra, we will maintain a flag property inside the TabbedPage, to make sure to allow the Selected Child-Tab switching happens only when the TabbedPage is visible to the user. Just to make it look nicer!

Since all of this is a simple combination of Bindable-Properties, Interfaces and Commands, this whole implementation is fully test-able. Yeah fine, I’ll show you how to write some tests for it as well! 😛

Sounds pretty straight forward eh! 😀 time for coding! 😉

Implementation time…

So just a heads up, my project configuration is as follows.

I’m using a Xamarin.Forms project (dot net Standard 2.0) created with Prism Templates for Visual Studio. And the IoC container is the default Unity container comes with Prism.Forms setup. As of the Tests I’m using a xUnit Dot net project, which I will get into details later.

So before you begin make sure you have the above setting in place.

1. interface to save the day…

First, the simple Interface which is going to save the day like we discussed above…

public interface IMyTabbedPageSelectedTab
{
	int SelectedTab { get; set; }

	void SetSelectedTab(int tabIndex);
}

 

There we have a SelectedTab property, and a separate setter method for it, just in case for backup scenario. If you don’t need both then stick to one of them. 😀

2. the TabbedPage…

Alright then let’s get started with our TabbedPage implementation, let’s call it MyTabbedPage.

<TabbedPage
    x:Class="AdvPrismTabNavigation.Views.MyTabbedPage"
    xmlns="http://xamarin.com/schemas/2014/forms"
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
    xmlns:local="clr-namespace:AdvPrismTabNavigation.Views;assembly=AdvPrismTabNavigation"
    xmlns:prism="clr-namespace:Prism.Mvvm;assembly=Prism.Forms"
    Title="{Binding Title}"
    prism:ViewModelLocator.AutowireViewModel="True"
    SelectedTabIndex="{Binding SelectedTab}">
    <TabbedPage.Children>
        <local:TabChild1Page />
        <local:TabChild2Page />
        <local:TabChild3Page />
    </TabbedPage.Children>
</TabbedPage>

 

There’s the XAML code for our MyTabbedPage, notice how we’re binding the SelectedTabIndex property to the ViewModel’s property which I’ll show later in this post. Meanwhile let’s have add some child pages to our MyTabbedPage as well.

Alright next take a look at the MyTabbedPage‘s code behind stuff, which is very minimal.

public partial class MyTabbedPage : TabbedPage
{
	private bool _isTabPageVisible;

	...
        // SelectedTabIndex 
	// bindable property goes here...
	...

	public MyTabbedPage()
	{
		InitializeComponent();
	}
	
	protected override void OnAppearing()
	{
		base.OnAppearing();

		// the tabbed page is now visible...
		_isTabPageVisible = true;

		// go ahead and update the Selected Child-Tab page..
		this.CurrentPage = this.Children[SelectedTabIndex];
	}

	protected override void OnDisappearing()
	{
		base.OnDisappearing();

		// the Tabbed Page is not visible anymore...
		_isTabPageVisible = false;
	}

	protected override void OnCurrentPageChanged()
	{
		base.OnCurrentPageChanged();

		// when the user manually changes the Tab,
		// we need to update it back to the ViewModel...
		SelectedTabIndex
			= this.Children.IndexOf(this.CurrentPage);
	}
}

 

As I mentioned in the recipe, there’s the flag _isTabPageVisible, we’re going to use to keep track of the Visibility of the TabbedPage. There when we’re coming back to the TabbedPage from a backward navigation, we’re executing the selected Child-Tab according to the SelectedTabIndex bindable property.

Important Note: You can even make the above little chunks of code go away from the XAML-Code-behind, by using triggers and attached properties, which I’m not going to get into here, to maintain the simplicity of the implementation. Come on, use your own creativity people! 😉

Next we’re creating the Bindable Property inside the TabbedPage which will handle the View-ViewModel communication. Let’s call it SelectedTabIndex property.

public static readonly BindableProperty SelectedTabIndexProperty =
	BindableProperty.Create(
		nameof(SelectedTabIndex), 
		typeof(int),
		typeof(MyTabbedPage), 0,
		BindingMode.TwoWay, null,
		propertyChanged: OnSelectedTabIndexChanged);
static void OnSelectedTabIndexChanged
	(BindableObject bindable, object oldValue, object newValue)
{
	if (((MyTabbedPage)bindable)._isTabPageVisible)
	{
		// update the Selected Child-Tab page 
		// only if Tabbed Page is visible..
		((MyTabbedPage)bindable).CurrentPage 
		= ((MyTabbedPage)bindable).Children[(int)newValue];
	}
}
public int SelectedTabIndex
{
	get { return (int)GetValue(SelectedTabIndexProperty); }
	set { SetValue(SelectedTabIndexProperty, value); }
}

 

Looks neat eh, so its a simple Bindable property as you can see, but however we’re handling it’s OnSelectedTabIndexChanged event ourselves because when the value changes from ViewModel’s end we need to update it on our UI’s end, as you can see we’re having a little flag property inside our MyTabbedPage 

3. the ViewModel…

Now is the time for MyTabbedPageViewModel stuff to come along. Nothing fancy just a standard ViewModel, but we need a reference to the IoC container (whichever it is you’re using) because we need to register our interface instance in it. This ViewModel as we discussed before is going to implement our IMyTabbedPageSelectedTab interface and its method and property.

public class MyTabbedPageViewModel 
          : ViewModelBase, IMyTabbedPageSelectedTab
{
     private readonly IUnityContainer _unityContainer;

     private int _selectedTab;
     /// <summary>
     /// Binds to the View's property
     /// View-ViewModel communcation
     /// </summary>
     public int SelectedTab
     {
          get { return _selectedTab; }
          set
          {
             SetProperty(ref _selectedTab, value);
             Title = $"My Tabbed Page - Tab [{SelectedTab + 1}]";
          }
     }
     
     public MyTabbedPageViewModel
          (INavigationService navigationService,
                         IUnityContainer unityContainer)
          : base(navigationService)
     {
          Title = $"My Tabbed Page - Tab [{SelectedTab + 1}]";

          this._unityContainer = unityContainer;

          // register this instance so we can access 
          // IMyTabbedPageSelectedTab anywhere in the code
          _unityContainer.RegisterInstance<IMyTabbedPageSelectedTab>
                    (this, new ContainerControlledLifetimeManager());
     }

     public void SetSelectedTab(int tabIndex)
     {
          SelectedTab = tabIndex;
     }
}

 

The SelectedTab property in the ViewModel is the one that’s binding to the SelectedTabIndex property in the MyTabbedPage, now you can see the bridge between the View-ViewModel.

Here we’re registering this ViewModel instance by the type of IMyTabbedPageSelectedTab so that we can access it from anywhere using the same type and also we’re passing in ContainerControlledLifetimeManager() parameter because we need to make sure that instance is properly managed by the container and garbage collected later when not in use.

4. finally Consume it…

So here is the little Magic code snippet you need to execute, wherever you wish to have access to programatically switching the Selected Child-Tab of our MyTabbedPage.

_unityContainer.Resolve<IMyTabbedPageSelectedTab>().SetSelectedTab(tabIndex);

 

You simply access the registered service interface and call on the SetSelectedTab() or simply you could also call the IMyTabbedPageSelectedTab.SelectedTab property directly as well. 😉

Just a little note, well this may not be the best of all approaches but this is what I believe is a better solution given my experience and expertise. But if you have a better alternative, please feel free to share!

Let’s fire it up!

So here’s this bad boy in action…

 

That’s the Child-Tab being switched programatically while inside the TabbedPage!

 

And here’s how nicely the Child-Tabs are switching programatically while outside the TabbedPage! As you can see when coming back to the TabbedPage, it nicely moves to the Selected Child-Tab…

Eyyy look at that! 😀

How about UnitTest-ing…

Uh fine, let me show you. 😛

In my case I used xUnit.net for my Test project, along side Prism.Forms and Xamarin.Forms.Mocks for mocking Xamarin.Forms run time.

Switching between Child-Tabs inside the TabbedPage:

//  Let's Tab-Navigate to TabChild2Page
_appInstance.Container.Resolve<TabChild1PageViewModel>()
			.GoToNextTabCommand.Execute("1");

//  Am I in the MyTabbedPage-> TabChild2Page?
Assert.IsType<TabChild2PageViewModel>
			(myTabbedPage.CurrentPage.BindingContext);

//  Let's Tab-Navigate to TabChild3Page
_appInstance.Container.Resolve<TabChild2PageViewModel>()
			.GoToNextTabCommand.Execute("2");

//  Am I in the MyTabbedPage-> TabChild2Page?
Assert.IsType<TabChild3PageViewModel>
			(myTabbedPage.CurrentPage.BindingContext);

 

I’m calling the Commands through my child page’s ViewModel and switching the Selected Child-Tab and then asserting to make sure the myTabbedPage instance has updated accordingly.

Switching between Child-Tabs outside the TabbedPage:

//  Am I inside the DetailPage?
Assert.IsType<DetailPageViewModel>
		    (navigationStack.Last().BindingContext);

// Let's go back to Tabbed Page -> TabChild3Page
_appInstance.Container.Resolve<DetailPageViewModel>()
		    .GoBackToTabChild3PageCommand.Execute();

//  Am I inside the MyTabbedPage?
Assert.IsType<MyTabbedPageViewModel>
		    (navigationStack.Last().BindingContext);

//  Am I in the MyTabbedPage-> TabChild3Page?
Assert.IsType<TabChild3PageViewModel>
		    (myTabbedPage.CurrentPage.BindingContext);

 

Here you can clearly see I’m calling the GoBackToTabChild3PageCommand in an page(DetailPage) which Ihave navigated to after the TabbedPage, and what happens in that command is I’m changing the Selected Child-Tab in the MyTabbedPage and immediately going back to it by exiting the DetailPage. Then I’m coming back to the MyTabbedPage, and the Child-Tab 3 is selected in the TabbedPage.

Here’s where you could take a look at the full test implementation : https://github.com/AdvPrismTabNavigation.xUnitTest

Voila! 😀 UnitTest-ing Done!

Github it if yo lazy!

So all of this is hosted on my git repo: https://github.com/AdvPrismTabNavigation

Feel free to grab your copy if you’re too lazy to DIY! 😛

That’s it for today.

Cheers all! 😀 Share the love!

A Keyboard disabled Entry control in Xamarin Forms?

A Xamarin Forms Entry Control without a keyboard? So when the user clicks on the Entry, the keyboard wouldn’t pop up? Yep, that’s what I’m talking about yo!

Oh sweet! So that I could use my custom keyboard or key buttons to enter values into it without the keyboard popping over and covering up the view? Oh yeah! that’s awesome! 😀

So it all began..

There was this one time where I was asked to implement a page which had an Entry with a bunch of custom buttons in the page, which would insert their specific values into the Entry controls when they’re clicked.
But if the User somehow clicked on the Entry, the Keyboard shouldn’t pop up and hover over the custom keyboard. And keep on mind the Entry field or the whatever alternative text editor view should be exactly similar to an entry looks and feel! 😮

Why such a requirement you ask? Imagine an text field which has limited or custom character inputs or a security code input field, where you want to have a custom keyboard on the view without using the default system keyboard for security reason, and many more. 🙂

Alternatives?

You could say, use a Label control where you would append its text value upon the custom key button clicks.
But the problem is, Label control doesn’t have the looks and feel of an Entry control, and it would be a big hassle to customize it to look as an Entry. Also from the performance aspect as well, since it will surely require custom rendering approach. 😦

Then you might say use the Keyboard dismissal service which I posted last time in my blog, and call up on it every time the user clicks on the Entry? But nope, that would look extremely distracting while the keyboard keep on popping up and down when the User clicks on the Entry every time.

So the solution?

So the only solution here is to have a Custom Entry control which doesn’t allow the popping up of the keyboard, or in other words, an Entry which has no Keyboard attachment up on focus.  😉

This is obviously the easiest and the fastest solution to execute, since we already got the Entry’s generic look and feel, along with all the behavior, except for the on Focus Keyboard attachment behavior. 😀

^there you go 😉

How could we do this?

Alright since we are going to customize our Entry control, we need to drill down to native levels of the actual Entry’s control rendering.

The Android EditText control that associates with the Xamarin Forms Entry’s has a property called ShowSoftInputOnFocus property which allows you to disable Keyboard attachment behavior upon focus for the EditText.

Then for iOS UITextField control that associates with the Xamarin Forms Entry’s has a property called InputView property which allows you to disable the Keyboard attachment by assigning it to an empty UIView object.

So we are going to use those native properties to implement this awesomeness! 😀

Coding it is!

First of all create a Custom Entry control by sub-classing it.

namespace WhateverYourNamespace
{
    public class SoftkeyboardDisabledEntry : Entry
    {

    }
}

 

Let’s call it SoftKeyboardDisabledEntry, just for the kicks of it 😉 !

iOS Custom Renderer…

Alright let’s drill down to iOS renderering of our custom control.

[assembly: ExportRenderer(typeof(SoftkeyboardDisabledEntry), typeof(SoftkeyboardDisabledEntryRenderer))]
namespace WhateverYourNamespace.iOS
{
    public class SoftkeyboardDisabledEntryRenderer : EntryRenderer
    {
        protected override void OnElementChanged(ElementChangedEventArgs<Entry> e)
        {
            base.OnElementChanged(e);

            // Disabling the keyboard
            this.Control.InputView = new UIView();
        }
    }
}

 

Alright there we assign an empty UIView to the InputView property of the native control instance, which will replace Keyboard attachment at run time.

Android Custom Renderer…

Ok then comes the Android renderer, with a bit of work though.

[assembly: ExportRenderer(typeof(SoftkeyboardDisabledEntry), typeof(SoftkeyboardDisabledEntryRenderer))]
namespace WhateverYourNamespace.Droid
{
    public class SoftkeyboardDisabledEntryRenderer : EntryRenderer
    {
        protected override void OnElementChanged(ElementChangedEventArgs<Entry> e)
        {
            base.OnElementChanged(e);
        
            if (e.NewElement != null)
            {
                ((SoftkeyboardDisabledEntry)e.NewElement).PropertyChanging += OnPropertyChanging;
            }

            if (e.OldElement != null)
            {
                ((SoftkeyboardDisabledEntry)e.OldElement).PropertyChanging -= OnPropertyChanging;
            }

            // Disable the Keyboard on Focus
            this.Control.ShowSoftInputOnFocus = false;
        }

        private void OnPropertyChanging(object sender, PropertyChangingEventArgs propertyChangingEventArgs)
        {
            // Check if the view is about to get Focus
            if (propertyChangingEventArgs.PropertyName == VisualElement.IsFocusedProperty.PropertyName)
            {
                // incase if the focus was moved from another Entry
                // Forcefully dismiss the Keyboard 
                InputMethodManager imm = (InputMethodManager)this.Context.GetSystemService(Context.InputMethodService);
                imm.HideSoftInputFromWindow(this.Control.WindowToken, 0);
            }
        }
    }
}

 

So there we are disabling ShowSoftInputOnFocus property by setting it false, to disable Keyboard attachment event. 😀

But then you notice that we are subscribing to the IsFocused PropertyChanged event as well. This is because in Android if we move the focus to our Custom Entry from another Entry which already had the Keyboard attached, the Keyboard wouldn’t dismiss itself. So in order to dismiss the Keyboard in case if it was already popped up, we are calling the InputMethodManager to forcefully dismiss the Keyboard. 🙂  Well this is more of a fail safe for our object, but if you think you wouldn’t run into such a scenario as above then you could remove the additional fail safe bit. 😉

Try it out?

Alright to test this out, below is a cool demo I threw in together, which you could also find in my github repo: https://github.com/XFNoSoftKeyboadEntryControl

Here’s how to consume it in your XAML!

<StackLayout Padding="10,10,10,0">

	<Label Text="Welcome to the Entry with disabled Keyboard!"
		   FontSize="22" FontAttributes="Bold" Margin="0,0,0,10"/>

	<Label Text="here is the normal Entry with Keyboard popping up on Focus"  TextColor="Gray" />
	<Entry Placeholder="Normal Entry Control..."/>

	<BoxView HeightRequest="0.7"  Margin="0,5,0,5"/>

	<Label Text="and here is our Entry with Keyboard disabled on Focus (but still editable)"  TextColor="Gray" />
	<local:SoftkeyboardDisabledEntry Placeholder="Keyboard disabled Entry Control..." x:Name="SoftkeyboardDisabledEntry" />
	
	
	<StackLayout VerticalOptions="EndAndExpand" Margin="0,0,0,10">
		<Label Text="So a simple custom keyboard may be? 😉 "  TextColor="Gray" />
		<StackLayout Orientation="Horizontal">
			<Button Text="A" Clicked="Button_OnClicked" WidthRequest="35" />
			<Button Text="B" Clicked="Button_OnClicked" WidthRequest="35" />
			<Button Text="C"  Clicked="Button_OnClicked" WidthRequest="35" />
			<Button Text="D"  Clicked="Button_OnClicked" WidthRequest="35" />
			<Button Text="E"  Clicked="Button_OnClicked" WidthRequest="35" />
			<Button Text="Clear All"  Clicked="ButtonClear_OnClicked" />
		</StackLayout>
	</StackLayout>

</StackLayout>

 

Next let’s add some Custom Key buttons to enter text to our Custom Entry with no Keyboard attached control! 😉

public partial class MainPage : ContentPage
{
	public MainPage()
	{
		InitializeComponent();
	}

	private void Button_OnClicked(object sender, EventArgs e)
	{
		SoftkeyboardDisabledEntry.Text 
                                  += ((Button) sender).Text;
	}

	private void ButtonClear_OnClicked(object sender, EventArgs e)
	{
		SoftkeyboardDisabledEntry.Text = "";
	}
}

 

that’s it.

Fire it up!

Hit that F5 and see the magic! 😀

 

WOOT! WOOT!

How cool is that eh! 😉

github repo: https://github.com/XFNoSoftKeyboadEntryControl

Enjoy and share.

Forcefully dismissing Keyboard in Xamarin Forms…

Wait… what? You want to forcefully dismiss your keyboard? A-B-S-O-L-U-T-E-L-Y!

Thanks to my experience in  working with high-expectation- seniors at my company, who demands me to push the limits of the Xamarin Forms Framework (frankly I love it, although it is kind of exhausting at times), I keep on sharing cool stuff which is quite out of the norm. And heyyy buckle up, since this is one of those instances where I pushed the limitations of Xamarin Forms! 😉

Once upon a time…

So there was this one time where I had to mimic a translucent layer on top of a login screen, where once the user enters username and password, I would simple capture a screenshot, blur it, and display as a blurred view on top of the page. But the problem there was as soon as user hits “Enter” on the keyboard, the screenshot will be captured but the keyboard would also be visible in the screenshot, since keyboard still stays up until a new layer is popped on top of the page (until the Entry’s focus is dismissed). 😦

Thereby the screenshot and the blurred view had the Keyboard visibility, which was pretty ugly, and my UX Lead wasn’t happy about it (perfectionists! lol).

“YOU MUST GET RID OF THE KEYBOARD VISIBILITY INSTANTLY, NO EXCUSE!”, demanded the UX Lead. 😮

Although this was no way possible out of the box from Xamarin Forms, I was asked to get rid of it one way or the other.

Nah I Didn’t give up!

You might think it’s just a matter of dismissing the focus of the Entry’s Completed event, but hell no it wasn’t! Because there was a specific delay from the Completed event to the keyboard dismissal event firing, which caused our screenshot capturing to capture the page with the Keyboard in view. 😮

So I knew I had to override or interrupt or short-wire the keyboard dismissal event myself forcefully. 😉

So after trying out many different solutions to get rid of the Keyboard visibility when the screenshot was captured, which ended up failing, I finally had the moment of “eureka!”.

le moment of eureka! 😀

Basically, what I did was to create a dependency service which would forcefully dismiss the keyboard, as in, push down the keyboard from which ever the current view of focus.

Sounds pretty simple eh? nah it wasn’t. lol

Up on the Entry’s Completed event I would first of all call up on my custom Keyboard dismissal service and then perform the screen capture and blurring view effect and so on. Which worked out pretty nicely!

Behold the results…

Yeah here’s something I built up to demonstrate the awesomeness of this hack!

How cool is that right? 😉

Besides the coolness, now you might ask what else could this be used for? Isn’t that obvious bro? 😛

Instances where,

  • you want to limit the user from entering text into an Entry after a given timeout?
  • may be dismiss the keyboard after a certain text length is reached?
  • instantly dismiss the keyboard straight from the ViewModel itself without having to go through a UI Event chain?

and so many other aspects, or it might as well be the same situation I had. 😉

Let me show you how it’s done…

So there’s no doubt we need to drill down to the native level when we try to push the limits of Xamarin Forms Framework, as usual.

In Android we could gain the access for the InputMethodManager which gives us the capability to hide the keyboard on demand.

And on iOS we use the UIApplication instance which gives us the access to the PresentedViewController property (current active ViewController), in return allowing us to call the EndEditing on its View to resign the first responder.

Finally I unite those two native calls via dependency service and be used from Xamarin Forms PCL level.

Here’s how to code it…

Blah blah blah.. yeah I talk too much when I’m enthusiastic about a hack I came across lol! 😀

First step create the interface for the keyboard dismissal service…

namespace WhateverYourNamespace
{
    /// <summary>
    /// Forcefully dismiss the keyboard
    /// </summary>
    public interface IForceKeyboardDismissalService
    {
        void DismissKeyboard();
    }
}

 

Now we could use this interface to do the native implementations which could be used via DependencyService of Xamarin Forms.

Next native hacking… or short circuiting you could say!

This is the time for native project level implementation of our service. Go ahead create your platform specific implementation of the IForceKeyboardDismissalService interface.

So for Android, we need to access the current Activity to access the InputMethodManager, for which we would use the Plugin.CurrentActivity library. So if you don’t have it, you might as well go ahead add that to your solution via nuget before implementing the below.

[assembly: Xamarin.Forms.Dependency(typeof(AndroidForceKeyboardDismissalService))]
namespace WhateverYourNamespace.Droid
{
    public class AndroidForceKeyboardDismissalService : IForceKeyboardDismissalService
    {
        public void DismissKeyboard()
        {
            InputMethodManager imm = InputMethodManager.FromContext(CrossCurrentActivity.Current.Activity.ApplicationContext);

            imm.HideSoftInputFromWindow(
                CrossCurrentActivity.Current.Activity.Window.DecorView.WindowToken, HideSoftInputFlags.NotAlways);
        }
    }
}

 

As you can see we are calling up the HideSoftInputFromWindow() method to dismiss the Keyboard via the InputMethodManager instance we retrieved.

Oh don’t forget to add the assembly attributes to register this for the Xamarin Forms DependencyService.

Then on iOS, we already have the singleton access to UIApplication where we are given access to the active PresentedViewController, which holds the instance for the current active view controller.

[assembly: Xamarin.Forms.Dependency(typeof(IosForceKeyboardDismissalService))]
namespace WhateverYourNamespace.iOS
{
    public class IosForceKeyboardDismissalService : IForceKeyboardDismissalService
    {
        public void DismissKeyboard()
        {
            UIApplication.SharedApplication.InvokeOnMainThread(() =>
            {
                var window = UIApplication.SharedApplication.KeyWindow;
                var vc = window.RootViewController;
                while (vc.PresentedViewController != null)
                {
                    vc = vc.PresentedViewController;
                }

                vc.View.EndEditing(true);
            });

        }
    }
}

 

Alright we are then calling the EndEditing() method from the current active View related to the active ViewController. There we are passing true as the parameter to let it know we mean business! 😛 lol uikit/uiview/1619630-endediting

Alright now time for the consumption of some cool code.

Consume it. (not literally) 😛

Here’s how you could use the above awesome service in Xamarin Forms.

DependencyService.Get<IForceKeyboardDismissalService>().DismissKeyboard();

 

That’s it!

Where’s the cool demo? 😮

Now don’t worry I shall not leave you hanging fellas!

You may be wondering where’s the cool implementation you saw at the beginning of the post… 😉
 

Here I have shared it on my github: UdaraAlwis/XFForcefulKeyboardDismiss

Alright, happy coding fellas! 😀

Enjoy and Share!

-Udara Alwis