Better Forms – PlatformEffect to Modify iOS Return Key

In this lesson

  • Create RoutingEffect
  • Create PlatformEffect
  • Apply Effect in Xaml


Tap on time to skip ahead


In this video, we’re going to explore how we can better indicate to our users what will happen when they hit the return key of our keyboard. For example, if I click on our email field, we’ll see that we just have this return key here, which is kind of a standard thing if you look at your computer’s return key. When it comes to iOS, UIKit has some features that allow us to clue the user in on needs to happen next, whether it should go to the next form field or submit the form all together. How can we do this with Xamarin.Forms?


I did some work before this video and I’m going to uncomment this XAML right here and then we’re going to rerun our application. Then, I’ll break down what I did. Basically what I just uncommented is known as a PlatformEffect. Now, PlatformEffect is basically a mechanism that Xamarin has provided for their forms applications that allow you to stylize or tweak various UI controls or elements for your application per platform.


Now, when I click on the password field, we see we now have a Done button instead of just your typical Return. Let’s kind of break down how I was able to accomplish this.


The first thing you need to do is in your Xamarin.Forms PCL or your core forms library, you need to create your effect and have it extend off RoutingEffect. RoutingEffect, or this class in general, basically acts as a PCL placeholder for your effect that you will be implementing per platform. You can see, it is extremely bare bones. You have your typical constructor and then we’re passing this namespace of sorts to the parent class or to the base class. Here I’m calling it Brax.ReturnKeyEffect.


If we go into our iOS application, we’ll see we have a similar named class but there is a bit more involved with it. The first thing you’ll see is we’re using these assembly attributes up here to specify a couple things. We want to specify what our resolution group name is, which is kind of, again, like a namespace. We need to also export out this effect to match up with any PCL calls to ReturnKeyEffect. One thing to keep in mind is this type of ReturnKeyEffect, we actually want that to reference our iOS effect, not our PCL effect.


If we dig deeper into our ReturnKeyEffect, we’ll see that we are overwriting two methods: OnAttached, OnDetached. We don’t really need to do anything for this particular use case for OnDetatched so I just have a comment here that says “do nothing.”


On our OnAttached, I get a reference to the control, which every effect gets a reference to a control, and I cast it as a UITextField and I set it’s return key type to Done. I wrapped this statement in a try-catch just in case another developer, or if I forget something down the road, I can spit out something to the console that says, “Hey, you can’t apply this effect to this particular control.”


If we take a look at our entry XAML, we’ll see that we’ve added this Entry.Effects node. One thing that’s also very important with our XAML is that we have to import in our effects namespace to be able to reference it correctly. We do this by specifying the namespace, BetterForms.Effects, we’ll see that this matches our namespace here. Then I specify which DLL or assembly that will be in.


That’s basically how we set up a platform effect for iOS to modify the appearance of the return key. In our next video, we’ll explore how we can add parameters to our effect.