You’ve got your Xamarin Forms (or native Android/iOS) application up and running and now you need to start thinking about what happens when your application hibernates.

An application can go into hibernation (or sleep mode) and then resume at some point. The OS hibernates an application in response to events, such as power off or lock screen but also if it’s running low on memory. Therefore, so that our application “places nicely” on the OS, we need to think about how we will persist state and restore state during this hibernation phases.

Let’s look at the various methods in Xamarin Forms for handling different aspects of the application’s life cycle…

Xamarin Forms

Initialization/Starting

By default a Xamarin Forms application will create an OnInitialized method which is basically where the InitializeComponent method is called. It’s a good place to set up any initialization for your UI elements etc.

Assuming we’re starting our application from cold (i.e. first start) Then the following lifecycle methods are called in order

1. OnInitialized
2. OnStart

According to the App Lifecycle documentation “On Android, the OnStart method will be called on rotation as well as when the application first starts, if the main activity lacks ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation in the [Activity()] attribute”.

So OnInitialized remains the best place to set defaults up, but OnStart may be the best place to make any UI changes based upon orientation etc.

Entering sleep mode

If the device goes into sleep mode (we can simulate easily by hitting the power button on our emulator or device). The following is called

1. OnSleep

This is our opportunity to persist state from the device so that when we resume the application it’ll appear in the same state as when it went into sleep mode.

There’s various ways to achieve this, if we’re using a pure MVVM approach with Prism (for example) we might use the EventAggregator to send a sleep message to all listening view models etc., which would then persist their data, or maybe we hold a cache (or similar) as a single data store and we persist this. Whichever way we go, the intention is that everything that is required to get the application back to the state pre-sleep, needs persisting. This also includes things such as which view (in a multiple view application) is displayed along with things like the view stack – well you get the idea, it depends how far you want to go to recreate the state of your application.

Note: another useful way to deal with view model data etc. is to actually persist it automatically when it changes, I don’t mean for every change of an entry control, but for example if you get data from a service, then you might store this in a cache and persist at the same time – obviously it depends on your specific scenarios and design.

Resuming from sleep mode

When an application is resumed, the following is called

1. OnResume

At this point we need to read any persisted data, hydrate our data/view models with this previously stored data and then get the application back into the state it was when it went into sleep mode. As mentioned for OnSleep, this includes any changes to the UI to put the correct view in place. Basically the user should not even realise that the application was, essentially, closed and restarted.

To test OnResume we simply click the power button on the emulator or unlock the device at which point OnResume will be called.

References

Xamarin.Forms App Lifecycle
Android Activity Lifecycle
UIApplicationDelegate Class

To get nice, material ui, visuals on your Android and/or iOS application you can use the Xamarin.Forms.Visual.Material nuget package, see Xamarin.Forms Material Visual for a full explanation of using this package. I’m just going to summarise this information in this post for my own information.

Add the nuget package Xamarin.Forms.Visual.Material you may need to upgrade your Xamarin Forms if it’s an older version.

Init the FormsMaterial in the AppDelegate of the iOS project

global::Xamarin.Forms.Forms.Init();
global::Xamarin.Forms.FormsMaterial.Init();

and the same in the MainActivity

global::Xamarin.Forms.Forms.Init(this, savedInstanceState);
global::Xamarin.Forms.FormsMaterial.Init(this, savedInstanceState);

Finally set the Visual element of the ContentPage, i.e.

<ContentPage Visual="Material"
/>

That’s all there is to it.

A simply way to send email from Android and iOS using Xamarin is by using the Xamarin.Essentials.Email class. This allows us to use the default email client on the device to send our email, so we simply compose the email then pass the user to the default client to press the send button. What’s useful about this is our application can then leave the user to add any further information to the email without having to create the entry fields in our app.

You’ll need to add the NuGet package Xamarin.Essentials, then we can use the following code (don’t forget to add using Xamarin.Essentials)

try
{
   var message = new EmailMessage
   {
      Subject = subject,
      Body = body,
      To = recipients,
      Cc = ccRecipients,
      Bcc = bccRecipients,
      BodyFormat = EmailBodyFormat.PlainText
   };

   if (attachments != null && attachments.Count > 0)
   {
      attachments.ForEach(attachment =>
      {
         message.Attachments.Add(new EmailAttachment(attachment));
      });
   }

   await Email.ComposeAsync(message);
}
catch (Exception ex)
{
   // Log exception
}

On Android this will display the default email client, for example gmail, with all the fields filled in along with any attachments.

When writing platform specific code within our iOS, Android and UWP projects we can use the built-in lightweight dependency injection code and attributes that comes out of the box with Xamarin, but when using Prism we’re probably using Unity or DryIoc as our preferred IoC library.

Let’s look at a simple example, whereby I have an interface in my shared code, which looks like this

public interface IFileService
{
   void Save(string data);
}

although there is file handling code etc. in .NET standard and we can implement something like this in the shared code, maybe we want some other more specific platform code. Here’s an Android file (i.e. within the Android project)

[assembly: Dependency(typeof(FileService))]
namespace Droid.Services
{
    public class FileService : IFileService
    {
        public void Save(string data)
        {
            // some Android specific code
        }
    }
}

The use of the DependencyAttribute makes this class available via Xamarin Forms built-in DependencyService, but not available to DryIoc, for example – hence what we want to do is use the built-in DI container and map this to our preferred IoC library.

All we need to do in our shared project’s App.xaml.cs file within the RegisterTypes method, we just do something like this

containerRegistry.RegisterInstance(DependencyService.Get<IFileService>());

Simple.

I wanted to have a clickable label in my Xamarin Forms application. A button was just a little too large for my requirements, but a standard Label does not have a click command. However, it’s easy to create such an command handler, this also works for other UI elements.

In your XAML just use the GestureRecognizers collection and add a TapGestureRecongizer, like this

<Label Text="More...">
   <Label.GestureRecognizers>
      <TapGestureRecognizer Command="{Binding MoreCommand}" />
   </Label.GestureRecognizers>
</Label>

Simple.