Building a “Next Entry” Effect for iOS and Android in Xamarin.Forms

Update June 26th: Eagle eyed commenter @Brandon Minnick pointed out that ReturnType and ReturnCommand are now supported properties in Xamarin.Forms 3.1 (Documentation). You can find his comprehensive sample here or an amended sample below.

And the code behind:

Of course, if you are using an older version of Xamarin.Forms or just want to do it yourself, my original post follows:

Almost every Xamarin.Forms mobile build I have done has required a “form” to be presented to the user. Whether it be for creating a new item in a task list, registering a new user, or other function, a point of frustration while constructing these views was there was no obvious way of setting focus to the next input field on the screen. Without it, users would hit the return key (dismissing the keyboard), and they would be required to tap the next field to proceed or simply hope the on screen keyboard didn’t cover the next field so that the user could proceed manually… a frustrating and inefficient UX to say the least. To circumvent this, we’d need to implement a few key features, we just need a few extra steps to make our form complete and make our UX much more fluid.  While this is fairly obvious when dealing with native development, the means of achieving it in Xamarin.Froms is not so plain. But, with a few simple components, we can configure our Xamarin.Forms Entry fields to specific the next field in the form and make things so much easier for the user. We’ll need a custom control to leverage in our Xamarin.Forms as well as some new effects to make it happen.

Custom Control

Custom controls are a very powerful way of of combining and configuring out-of-the-box Xamarin Components to suit your needs. With a little xaml and a little know-how, we can combine and customize existing tools to suit our needs and easily re-use them throughout a project. In our case, we just need to extend the existing Entry control ever so slightly so that we may specify the next Entry in the form. Take a look:

The key takeaways here: we’ve slightly extended the basic Entry control to add a new bindable property so we may specify the next entry in line and created a simple method for setting the focus to the value of that property when called. We can now deploy this in our xaml, like so:

Personally, I find it easier to set the NextEntry in code behind, but you could realistically do everything all in the xaml. For reference however, here is my xaml.cs:

namespace samples.core.Views
{
    public partial class EntryMoveNextView : ContentPage
    {
        public EntryMoveNextView()
        {
            InitializeComponent();

            Entry_First.NextEntry = Entry_Second;
            Entry_Second.NextEntry = Entry_Third;
        }
    }
}

At this point, (on iOS, at least) we’ve actually got a pretty good representation of the functionality we want: so long as we set a value for our NextEntry property, we can direct focus to the next item.

That said, with just a little more effort, we can customize the keyboard to better indicate to the user what will happen when they hit “return”. We can achieve this with a simple effect per platforms

Android Effect

Our Android Effect will look like so:

With a simple check, we can determine if we should show a “Next” key on place of the return key, which makes it much more obvious to the user that they will advance through the form.

iOS Effect

Let’s apply the same line of reasoning to iOS:

Note that we have a little extra logic on this side of the house: In some keyboard configurations (such as numeric), there is no return button, so we need to customize the keyboard with a toolbar. In fact,  if it makes more sense for a given application, we could show the toolbar for every keyboard type, which would give us more power to expose functionality like adding a “previous” button. We’ll stick with a simple implementation in this case, and save the advanced configuration for another time 😉. We now need to apply our effect to the appropriate page xaml.cs, like so:

Entry_Second.Effects.Add(Effect.Resolve("Effects.EntryMoveNextEffect"));

Here is what the result would look like in either keyboard configuration:

And thats a wrap! This example and others can be found on my GitHub