To understand each option completely and what different situations call for, let's define a solution structure for each cross-platform solution. Let's use the product search example used earlier in the chapter and set up a solution for each approach.

To set up file linking, perform the following steps:

When all is done, you will have a solution tree that looks something like what you can see in the following screenshot:

You should consider using this technique when you have to reference different libraries on each platform. You might consider using this option if you are using MonoGame, or other frameworks that require you to reference a different library on iOS versus Android.

Setting up a solution with the cloned project files approach is similar to file linking, except that you will have to create an additional class library for each platform. To do this, create an Android library project and an iOS library project in the same ProductSearch.Core directory. You will have to create the projects and move them to the proper folder manually, then re-add them to the solution. Right-click on the solution and navigate to Display Options | Show All Files to add the required C# files to these two projects. Your main iOS and Android projects can reference these projects directly.

Your project will look like what is shown in the following screenshot, with ProductSearch.iOS referencing ProductSearch.Core.iOS and ProductSearch.Droid referencing ProductSearch.Core.Droid:

To understand each option completely and what different situations call for, let's define a solution structure for each cross-platform solution. Let's use the product search example used earlier in the chapter and set up a solution for each approach.

To set up file linking, perform the following steps:

When all is done, you will have a solution tree that looks something like what you can see in the following screenshot:

You should consider using this technique when you have to reference different libraries on each platform. You might consider using this option if you are using MonoGame, or other frameworks that require you to reference a different library on iOS versus Android.

Setting up a solution with the cloned project files approach is similar to file linking, except that you will have to create an additional class library for each platform. To do this, create an Android library project and an iOS library project in the same ProductSearch.Core directory. You will have to create the projects and move them to the proper folder manually, then re-add them to the solution. Right-click on the solution and navigate to Display Options | Show All Files to add the required C# files to these two projects. Your main iOS and Android projects can reference these projects directly.

Your project will look like what is shown in the following screenshot, with ProductSearch.iOS referencing ProductSearch.Core.iOS and ProductSearch.Droid referencing ProductSearch.Core.Droid:

Let's create our first portable class library:

Each solution type has its distinct advantages and disadvantages. PCLs are generally better, but there are certain cases where they can't be used. For example, if you were using a library such as MonoGame, which is a different library for each platform, you would be much better off using a shared project or file linking. Similar issues would arise if you needed to use a preprocessor statement such as #if IPHONE or a native library such as the Facebook SDK on iOS or Android.

Let's create our first portable class library:

Each solution type has its distinct advantages and disadvantages. PCLs are generally better, but there are certain cases where they can't be used. For example, if you were using a library such as MonoGame, which is a different library for each platform, you would be much better off using a shared project or file linking. Similar issues would arise if you needed to use a preprocessor statement such as #if IPHONE or a native library such as the Facebook SDK on iOS or Android.

Now that we have a base class for all of the ViewModel layers, we can implement a ViewModel layer for the first screen in our application, the Login screen.

Now let's implement a LoginViewModel class as follows:

public class LoginViewModel : BaseViewModel
{
  public string Username { get; set; }
  public string Password { get; set; }
  public async Task Login()
  {
    if (string.IsNullOrEmpty(Username))
      throw new Exception("Username is blank.");

    if (string.IsNullOrEmpty(Password))
      throw new Exception("Password is blank.");

    IsBusy = true;
    try
    {
      settings.User = await service.Login(Username, Password);
      settings.Save();
    }
    finally
    {
      IsBusy = false;
    }
  }
}

In this class, we implemented the following:

Basically, this is the pattern that we'll follow for the rest of the ViewModel layers in the application. We provide properties for the View layer to be set by the user's input, and methods to call for various operations. If it is a method that could take some time, such as a web request, you should always return Task and use the async and await keywords.

Since we have finished writing our ViewModel class to log in, we will now need to create one for the user's registration.

Let's implement another ViewModel layer to register a new user:

public class RegisterViewModel : BaseViewModel
{
  public string Username { get; set; }
  public string Password { get; set; }
  public string ConfirmPassword { get; set; }
}

These properties will handle inputs from the user. Next, we need to add a Register method as follows:

public async Task Register()
{
  if (string.IsNullOrEmpty(Username))
    throw new Exception("Username is blank.");
  if (string.IsNullOrEmpty(Password))
    throw new Exception("Password is blank.");
  if (Password != ConfirmPassword)
    throw new Exception("Passwords don't match.");
  IsBusy = true;
  try
  {
    settings.User = await service.Register(new User { Username = Username, Password = Password, });
    settings.Save();
  }
  finally
  {
    IsBusy = false;
  }
}

The RegisterViewModel class is very similar to the LoginViewModel class, but has an additional ConfirmPassword property for the UI to be set. A good rule to follow for when to split the ViewModel layer's functionality is to always create a new class when the UI has a new screen. This helps you keep your code clean and somewhat follow the Single Responsibility Principal (SRP) for your classes. The SRP states that a class should only have a single purpose or responsibility. We'll try to follow this concept to keep our classes small and organized, which can be more important than usual when sharing code across platforms.

Next on the list is a ViewModel layer to work with a user's friend list. We will need a method to load a user's friend list and add a new friend.

Now let's implement the FriendViewModel as follows:

public class FriendViewModel : BaseViewModel
{
  public User[] Friends { get; private set; }
  public string Username { get; set; }
}

Now we'll need a method to load friends. This method is as follows:

public async Task GetFriends()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  IsBusy = true;
  try
  {
    Friends = await service.GetFriends(settings.User.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Finally, we'll need a method to add a new friend and then update the list of friends contained locally:

public async Task AddFriend()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  if (string.IsNullOrEmpty(Username))
    throw new Exception("Username is blank.");

  IsBusy = true;
  try
  {
    var friend = await service.AddFriend(settings.User.Id, Username);

    //Update our local list of friends
    var friends = new List<User>();
    if (Friends != null)
      friends.AddRange(Friends);
    friends.Add(friend);

    Friends = friends.OrderBy(f => f.Username).ToArray();
  }
  finally
  {
    IsBusy = false;
  }
}

Again, this class is fairly straightforward. The only thing new here is that we added some logic to update the list of friends and sort them within our client application and not the server. You can also choose to reload the complete list of friends if you have a good reason to do so.

Our final required ViewModel layer will handle messages and conversations. We need to create a way to load conversations and messages and send a new message.

Let's start implementing our MessageViewModel class as follows:

public class MessageViewModel : BaseViewModel
{
  public Conversation[] Conversations { get; private set; }
  public Conversation Conversation { get; set; }
  public Message[] Messages { get; private set; }
  public string Text { get; set; }
}

Next, let's implement a method to retrieve a list of conversations as follows:

public async Task GetConversations()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  IsBusy = true;
  try
  {
    Conversations = await service.GetConversations(settings.User.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Similarly, we need to retrieve a list of messages within a conversation. We will need to pass the conversation ID to the service as follows:

public async Task GetMessages()
{
  if (Conversation == null)
    throw new Exception("No conversation.");

  IsBusy = true;
  try
  {
    Messages = await service.GetMessages(Conversation.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Finally, we need to write some code to send a message and update the local list of messages as follows:

public async Task SendMessage()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  if (Conversation == null)
    throw new Exception("No conversation.");

  if (string.IsNullOrEmpty (Text))
    throw new Exception("Message is blank.");

  IsBusy = true;
  try
  {
    var message = await service.SendMessage(new Message 
    {
      UserId = settings.User.Id,ConversationId = Conversation.Id, 
      Text = Text
    });
    //Update our local list of messages
    var messages = new List<Message>();
    if (Messages != null)
      messages.AddRange(Messages);
    messages.Add(message);

    Messages = messages.ToArray();
  }
  finally
  {IsBusy = false;
  }
}

This concludes the ViewModel layer of our application and the entirety of the shared code used on iOS and Android. For the MessageViewModel class, you could have also chosen to put the GetConversations and Conversations properties in their own class, since they can be considered as a separate responsibility, but it is not really necessary.

Here is the final class diagram of our ViewModel layer:

Now that we have a base class for all of the ViewModel layers, we can implement a ViewModel layer for the first screen in our application, the Login screen.

Now let's implement a LoginViewModel class as follows:

public class LoginViewModel : BaseViewModel
{
  public string Username { get; set; }
  public string Password { get; set; }
  public async Task Login()
  {
    if (string.IsNullOrEmpty(Username))
      throw new Exception("Username is blank.");

    if (string.IsNullOrEmpty(Password))
      throw new Exception("Password is blank.");

    IsBusy = true;
    try
    {
      settings.User = await service.Login(Username, Password);
      settings.Save();
    }
    finally
    {
      IsBusy = false;
    }
  }
}

In this class, we implemented the following:

Basically, this is the pattern that we'll follow for the rest of the ViewModel layers in the application. We provide properties for the View layer to be set by the user's input, and methods to call for various operations. If it is a method that could take some time, such as a web request, you should always return Task and use the async and await keywords.

Since we have finished writing our ViewModel class to log in, we will now need to create one for the user's registration.

Let's implement another ViewModel layer to register a new user:

public class RegisterViewModel : BaseViewModel
{
  public string Username { get; set; }
  public string Password { get; set; }
  public string ConfirmPassword { get; set; }
}

These properties will handle inputs from the user. Next, we need to add a Register method as follows:

public async Task Register()
{
  if (string.IsNullOrEmpty(Username))
    throw new Exception("Username is blank.");
  if (string.IsNullOrEmpty(Password))
    throw new Exception("Password is blank.");
  if (Password != ConfirmPassword)
    throw new Exception("Passwords don't match.");
  IsBusy = true;
  try
  {
    settings.User = await service.Register(new User { Username = Username, Password = Password, });
    settings.Save();
  }
  finally
  {
    IsBusy = false;
  }
}

The RegisterViewModel class is very similar to the LoginViewModel class, but has an additional ConfirmPassword property for the UI to be set. A good rule to follow for when to split the ViewModel layer's functionality is to always create a new class when the UI has a new screen. This helps you keep your code clean and somewhat follow the Single Responsibility Principal (SRP) for your classes. The SRP states that a class should only have a single purpose or responsibility. We'll try to follow this concept to keep our classes small and organized, which can be more important than usual when sharing code across platforms.

Next on the list is a ViewModel layer to work with a user's friend list. We will need a method to load a user's friend list and add a new friend.

Now let's implement the FriendViewModel as follows:

public class FriendViewModel : BaseViewModel
{
  public User[] Friends { get; private set; }
  public string Username { get; set; }
}

Now we'll need a method to load friends. This method is as follows:

public async Task GetFriends()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  IsBusy = true;
  try
  {
    Friends = await service.GetFriends(settings.User.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Finally, we'll need a method to add a new friend and then update the list of friends contained locally:

public async Task AddFriend()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  if (string.IsNullOrEmpty(Username))
    throw new Exception("Username is blank.");

  IsBusy = true;
  try
  {
    var friend = await service.AddFriend(settings.User.Id, Username);

    //Update our local list of friends
    var friends = new List<User>();
    if (Friends != null)
      friends.AddRange(Friends);
    friends.Add(friend);

    Friends = friends.OrderBy(f => f.Username).ToArray();
  }
  finally
  {
    IsBusy = false;
  }
}

Again, this class is fairly straightforward. The only thing new here is that we added some logic to update the list of friends and sort them within our client application and not the server. You can also choose to reload the complete list of friends if you have a good reason to do so.

Our final required ViewModel layer will handle messages and conversations. We need to create a way to load conversations and messages and send a new message.

Let's start implementing our MessageViewModel class as follows:

public class MessageViewModel : BaseViewModel
{
  public Conversation[] Conversations { get; private set; }
  public Conversation Conversation { get; set; }
  public Message[] Messages { get; private set; }
  public string Text { get; set; }
}

Next, let's implement a method to retrieve a list of conversations as follows:

public async Task GetConversations()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  IsBusy = true;
  try
  {
    Conversations = await service.GetConversations(settings.User.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Similarly, we need to retrieve a list of messages within a conversation. We will need to pass the conversation ID to the service as follows:

public async Task GetMessages()
{
  if (Conversation == null)
    throw new Exception("No conversation.");

  IsBusy = true;
  try
  {
    Messages = await service.GetMessages(Conversation.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Finally, we need to write some code to send a message and update the local list of messages as follows:

public async Task SendMessage()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  if (Conversation == null)
    throw new Exception("No conversation.");

  if (string.IsNullOrEmpty (Text))
    throw new Exception("Message is blank.");

  IsBusy = true;
  try
  {
    var message = await service.SendMessage(new Message 
    {
      UserId = settings.User.Id,ConversationId = Conversation.Id, 
      Text = Text
    });
    //Update our local list of messages
    var messages = new List<Message>();
    if (Messages != null)
      messages.AddRange(Messages);
    messages.Add(message);

    Messages = messages.ToArray();
  }
  finally
  {IsBusy = false;
  }
}

This concludes the ViewModel layer of our application and the entirety of the shared code used on iOS and Android. For the MessageViewModel class, you could have also chosen to put the GetConversations and Conversations properties in their own class, since they can be considered as a separate responsibility, but it is not really necessary.

Here is the final class diagram of our ViewModel layer:

Since we have finished writing our ViewModel class to log in, we will now need to create one for the user's registration.

Let's implement another ViewModel layer to register a new user:

public class RegisterViewModel : BaseViewModel
{
  public string Username { get; set; }
  public string Password { get; set; }
  public string ConfirmPassword { get; set; }
}

These properties will handle inputs from the user. Next, we need to add a Register method as follows:

public async Task Register()
{
  if (string.IsNullOrEmpty(Username))
    throw new Exception("Username is blank.");
  if (string.IsNullOrEmpty(Password))
    throw new Exception("Password is blank.");
  if (Password != ConfirmPassword)
    throw new Exception("Passwords don't match.");
  IsBusy = true;
  try
  {
    settings.User = await service.Register(new User { Username = Username, Password = Password, });
    settings.Save();
  }
  finally
  {
    IsBusy = false;
  }
}

The RegisterViewModel class is very similar to the LoginViewModel class, but has an additional ConfirmPassword property for the UI to be set. A good rule to follow for when to split the ViewModel layer's functionality is to always create a new class when the UI has a new screen. This helps you keep your code clean and somewhat follow the Single Responsibility Principal (SRP) for your classes. The SRP states that a class should only have a single purpose or responsibility. We'll try to follow this concept to keep our classes small and organized, which can be more important than usual when sharing code across platforms.

Next on the list is a ViewModel layer to work with a user's friend list. We will need a method to load a user's friend list and add a new friend.

Now let's implement the FriendViewModel as follows:

public class FriendViewModel : BaseViewModel
{
  public User[] Friends { get; private set; }
  public string Username { get; set; }
}

Now we'll need a method to load friends. This method is as follows:

public async Task GetFriends()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  IsBusy = true;
  try
  {
    Friends = await service.GetFriends(settings.User.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Finally, we'll need a method to add a new friend and then update the list of friends contained locally:

public async Task AddFriend()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  if (string.IsNullOrEmpty(Username))
    throw new Exception("Username is blank.");

  IsBusy = true;
  try
  {
    var friend = await service.AddFriend(settings.User.Id, Username);

    //Update our local list of friends
    var friends = new List<User>();
    if (Friends != null)
      friends.AddRange(Friends);
    friends.Add(friend);

    Friends = friends.OrderBy(f => f.Username).ToArray();
  }
  finally
  {
    IsBusy = false;
  }
}

Again, this class is fairly straightforward. The only thing new here is that we added some logic to update the list of friends and sort them within our client application and not the server. You can also choose to reload the complete list of friends if you have a good reason to do so.

Our final required ViewModel layer will handle messages and conversations. We need to create a way to load conversations and messages and send a new message.

Let's start implementing our MessageViewModel class as follows:

public class MessageViewModel : BaseViewModel
{
  public Conversation[] Conversations { get; private set; }
  public Conversation Conversation { get; set; }
  public Message[] Messages { get; private set; }
  public string Text { get; set; }
}

Next, let's implement a method to retrieve a list of conversations as follows:

public async Task GetConversations()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  IsBusy = true;
  try
  {
    Conversations = await service.GetConversations(settings.User.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Similarly, we need to retrieve a list of messages within a conversation. We will need to pass the conversation ID to the service as follows:

public async Task GetMessages()
{
  if (Conversation == null)
    throw new Exception("No conversation.");

  IsBusy = true;
  try
  {
    Messages = await service.GetMessages(Conversation.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Finally, we need to write some code to send a message and update the local list of messages as follows:

public async Task SendMessage()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  if (Conversation == null)
    throw new Exception("No conversation.");

  if (string.IsNullOrEmpty (Text))
    throw new Exception("Message is blank.");

  IsBusy = true;
  try
  {
    var message = await service.SendMessage(new Message 
    {
      UserId = settings.User.Id,ConversationId = Conversation.Id, 
      Text = Text
    });
    //Update our local list of messages
    var messages = new List<Message>();
    if (Messages != null)
      messages.AddRange(Messages);
    messages.Add(message);

    Messages = messages.ToArray();
  }
  finally
  {IsBusy = false;
  }
}

This concludes the ViewModel layer of our application and the entirety of the shared code used on iOS and Android. For the MessageViewModel class, you could have also chosen to put the GetConversations and Conversations properties in their own class, since they can be considered as a separate responsibility, but it is not really necessary.

Here is the final class diagram of our ViewModel layer:

Next on the list is a ViewModel layer to work with a user's friend list. We will need a method to load a user's friend list and add a new friend.

Now let's implement the FriendViewModel as follows:

public class FriendViewModel : BaseViewModel
{
  public User[] Friends { get; private set; }
  public string Username { get; set; }
}

Now we'll need a method to load friends. This method is as follows:

public async Task GetFriends()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  IsBusy = true;
  try
  {
    Friends = await service.GetFriends(settings.User.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Finally, we'll need a method to add a new friend and then update the list of friends contained locally:

public async Task AddFriend()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  if (string.IsNullOrEmpty(Username))
    throw new Exception("Username is blank.");

  IsBusy = true;
  try
  {
    var friend = await service.AddFriend(settings.User.Id, Username);

    //Update our local list of friends
    var friends = new List<User>();
    if (Friends != null)
      friends.AddRange(Friends);
    friends.Add(friend);

    Friends = friends.OrderBy(f => f.Username).ToArray();
  }
  finally
  {
    IsBusy = false;
  }
}

Again, this class is fairly straightforward. The only thing new here is that we added some logic to update the list of friends and sort them within our client application and not the server. You can also choose to reload the complete list of friends if you have a good reason to do so.

Our final required ViewModel layer will handle messages and conversations. We need to create a way to load conversations and messages and send a new message.

Let's start implementing our MessageViewModel class as follows:

public class MessageViewModel : BaseViewModel
{
  public Conversation[] Conversations { get; private set; }
  public Conversation Conversation { get; set; }
  public Message[] Messages { get; private set; }
  public string Text { get; set; }
}

Next, let's implement a method to retrieve a list of conversations as follows:

public async Task GetConversations()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  IsBusy = true;
  try
  {
    Conversations = await service.GetConversations(settings.User.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Similarly, we need to retrieve a list of messages within a conversation. We will need to pass the conversation ID to the service as follows:

public async Task GetMessages()
{
  if (Conversation == null)
    throw new Exception("No conversation.");

  IsBusy = true;
  try
  {
    Messages = await service.GetMessages(Conversation.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Finally, we need to write some code to send a message and update the local list of messages as follows:

public async Task SendMessage()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  if (Conversation == null)
    throw new Exception("No conversation.");

  if (string.IsNullOrEmpty (Text))
    throw new Exception("Message is blank.");

  IsBusy = true;
  try
  {
    var message = await service.SendMessage(new Message 
    {
      UserId = settings.User.Id,ConversationId = Conversation.Id, 
      Text = Text
    });
    //Update our local list of messages
    var messages = new List<Message>();
    if (Messages != null)
      messages.AddRange(Messages);
    messages.Add(message);

    Messages = messages.ToArray();
  }
  finally
  {IsBusy = false;
  }
}

This concludes the ViewModel layer of our application and the entirety of the shared code used on iOS and Android. For the MessageViewModel class, you could have also chosen to put the GetConversations and Conversations properties in their own class, since they can be considered as a separate responsibility, but it is not really necessary.

Here is the final class diagram of our ViewModel layer:

Our final required ViewModel layer will handle messages and conversations. We need to create a way to load conversations and messages and send a new message.

Let's start implementing our MessageViewModel class as follows:

public class MessageViewModel : BaseViewModel
{
  public Conversation[] Conversations { get; private set; }
  public Conversation Conversation { get; set; }
  public Message[] Messages { get; private set; }
  public string Text { get; set; }
}

Next, let's implement a method to retrieve a list of conversations as follows:

public async Task GetConversations()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  IsBusy = true;
  try
  {
    Conversations = await service.GetConversations(settings.User.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Similarly, we need to retrieve a list of messages within a conversation. We will need to pass the conversation ID to the service as follows:

public async Task GetMessages()
{
  if (Conversation == null)
    throw new Exception("No conversation.");

  IsBusy = true;
  try
  {
    Messages = await service.GetMessages(Conversation.Id);
  }
  finally
  {
    IsBusy = false;
  }
}

Finally, we need to write some code to send a message and update the local list of messages as follows:

public async Task SendMessage()
{
  if (settings.User == null)
    throw new Exception("Not logged in.");

  if (Conversation == null)
    throw new Exception("No conversation.");

  if (string.IsNullOrEmpty (Text))
    throw new Exception("Message is blank.");

  IsBusy = true;
  try
  {
    var message = await service.SendMessage(new Message 
    {
      UserId = settings.User.Id,ConversationId = Conversation.Id, 
      Text = Text
    });
    //Update our local list of messages
    var messages = new List<Message>();
    if (Messages != null)
      messages.AddRange(Messages);
    messages.Add(message);

    Messages = messages.ToArray();
  }
  finally
  {IsBusy = false;
  }
}

This concludes the ViewModel layer of our application and the entirety of the shared code used on iOS and Android. For the MessageViewModel class, you could have also chosen to put the GetConversations and Conversations properties in their own class, since they can be considered as a separate responsibility, but it is not really necessary.

Here is the final class diagram of our ViewModel layer:

Let's set up a new project for unit tests by performing the following steps:

In addition to the required C# attributes, there are several others that are useful for writing tests, and they are as follows:

The next concept to learn about writing tests with NUnit is how to write assertions. An assertion is a method that will throw an exception if a certain value is not true. It will cause a test to fail and give a descriptive explanation as to what happened. NUnit has a couple of different sets of APIs for assertions; however, we will use the more readable and fluent versions of the APIs.

The basic syntax of a fluent-style API is using the Assert.That method. The following example this:

Assert.That(myVariable, Is.EqualTo(0));

Likewise, you can assert the opposite:

Assert.That(myVariable, Is.Not.EqualTo(0));

Or any of the following:

Feel free to explore the APIs. With code completion in Xamarin Studio, you should be able to discover useful static members or methods on the Is class to use within your tests.

Before we begin writing specific tests for our application, let's write a static class and method to create a global setup to be used throughout our tests. You can rewrite Test.cs as follows:

public static class Test
{
  public static void SetUp()
  {
    ServiceContainer.Register<IWebService>(() =>new FakeWebService { SleepDuration = 0 });
    ServiceContainer.Register<ISettings>(() =>new FakeSettings());
  }
}

We'll use this method throughout our tests to set up fake services in our Model layer. Additionally, this replaces the existing services so that our tests execute against new instances of these classes. This is a good practice in unit testing to guarantee that no old data is left behind from a previous test. Also, notice that we set SleepDuration to 0. This will make our tests run very quickly.

We will begin by creating a ViewModels folder in our test project and adding a class named LoginViewModelTests as follows:

[TestFixture]
public class LoginViewModelTests
{
  LoginViewModel loginViewModel;
  ISettings settings;
  [SetUp]
  public void SetUp()
  {
    Test.SetUp();
    settings = ServiceContainer.Resolve<ISettings>();
    loginViewModel = new LoginViewModel();
  }
  [Test]
  public async Task LoginSuccessfully()
  {
    loginViewModel.Username = "testuser";
    loginViewModel.Password = "password";
    await loginViewModel.Login();
    Assert.That(settings.User, Is.Not.Null);
  }
}

Notice our use of a SetUp method. We recreate the objects used in every test to make sure that no old data is left over from the previous test runs. Another point to note is that you must return a Task when using async/await in a test method. Otherwise, NUnit would not be able to know when a test completes.

To run the test, use the NUnit menu found docked to the right of Xamarin Studio, by default. Go ahead and run the test using the Run Test button that has a gear icon. You will get a successful result similar to what is shown in the following screenshot:

You can also view the Test Results pane, which will show you the extended details if a test fails, as shown in the following screenshot:

To see what happens when a test fails, go ahead and modify your test to assert against an incorrect value as follows:

//Change Is.Not.Null to Is.Null
Assert.That(settings.User, Is.Null);

You will get a very descriptive error in the Test Results pane, as shown in the following screenshot:

Now let's implement another test for the LoginViewModel class; let's make sure that we get the appropriate outcome if the username and password fields are blank. The test is implemented as follows:

[Test]
public async Task LoginWithNoUsernameOrPassword()
{
  //Throws an exception
  await loginViewModel.Login();
}

If we run the test as it is, we will get an exception and the test will fail. Since we expect an exception to occur, we can decorate the method to make the test pass only if an exception occurs as follows:

[Test, 
  ExpectedException(typeof(Exception), 
  ExpectedMessage = "Username is blank.")]

More tests are included with the sample code along with this module. It is recommended that you write tests against each public operation on each ViewModel class. Additionally, write tests for any validation or other important business logic. I would also recommend that you write tests against the Model layer; however, this is not needed in our project yet since we only have fake implementations.

Let's set up a new project for unit tests by performing the following steps:

In addition to the required C# attributes, there are several others that are useful for writing tests, and they are as follows:

The next concept to learn about writing tests with NUnit is how to write assertions. An assertion is a method that will throw an exception if a certain value is not true. It will cause a test to fail and give a descriptive explanation as to what happened. NUnit has a couple of different sets of APIs for assertions; however, we will use the more readable and fluent versions of the APIs.

The basic syntax of a fluent-style API is using the Assert.That method. The following example this:

Assert.That(myVariable, Is.EqualTo(0));

Likewise, you can assert the opposite:

Assert.That(myVariable, Is.Not.EqualTo(0));

Or any of the following:

Feel free to explore the APIs. With code completion in Xamarin Studio, you should be able to discover useful static members or methods on the Is class to use within your tests.

Before we begin writing specific tests for our application, let's write a static class and method to create a global setup to be used throughout our tests. You can rewrite Test.cs as follows:

public static class Test
{
  public static void SetUp()
  {
    ServiceContainer.Register<IWebService>(() =>new FakeWebService { SleepDuration = 0 });
    ServiceContainer.Register<ISettings>(() =>new FakeSettings());
  }
}

We'll use this method throughout our tests to set up fake services in our Model layer. Additionally, this replaces the existing services so that our tests execute against new instances of these classes. This is a good practice in unit testing to guarantee that no old data is left behind from a previous test. Also, notice that we set SleepDuration to 0. This will make our tests run very quickly.

We will begin by creating a ViewModels folder in our test project and adding a class named LoginViewModelTests as follows:

[TestFixture]
public class LoginViewModelTests
{
  LoginViewModel loginViewModel;
  ISettings settings;
  [SetUp]
  public void SetUp()
  {
    Test.SetUp();
    settings = ServiceContainer.Resolve<ISettings>();
    loginViewModel = new LoginViewModel();
  }
  [Test]
  public async Task LoginSuccessfully()
  {
    loginViewModel.Username = "testuser";
    loginViewModel.Password = "password";
    await loginViewModel.Login();
    Assert.That(settings.User, Is.Not.Null);
  }
}

Notice our use of a SetUp method. We recreate the objects used in every test to make sure that no old data is left over from the previous test runs. Another point to note is that you must return a Task when using async/await in a test method. Otherwise, NUnit would not be able to know when a test completes.

To run the test, use the NUnit menu found docked to the right of Xamarin Studio, by default. Go ahead and run the test using the Run Test button that has a gear icon. You will get a successful result similar to what is shown in the following screenshot:

You can also view the Test Results pane, which will show you the extended details if a test fails, as shown in the following screenshot:

To see what happens when a test fails, go ahead and modify your test to assert against an incorrect value as follows:

//Change Is.Not.Null to Is.Null
Assert.That(settings.User, Is.Null);

You will get a very descriptive error in the Test Results pane, as shown in the following screenshot:

Now let's implement another test for the LoginViewModel class; let's make sure that we get the appropriate outcome if the username and password fields are blank. The test is implemented as follows:

[Test]
public async Task LoginWithNoUsernameOrPassword()
{
  //Throws an exception
  await loginViewModel.Login();
}

If we run the test as it is, we will get an exception and the test will fail. Since we expect an exception to occur, we can decorate the method to make the test pass only if an exception occurs as follows:

[Test, 
  ExpectedException(typeof(Exception), 
  ExpectedMessage = "Username is blank.")]

More tests are included with the sample code along with this module. It is recommended that you write tests against each public operation on each ViewModel class. Additionally, write tests for any validation or other important business logic. I would also recommend that you write tests against the Model layer; however, this is not needed in our project yet since we only have fake implementations.

The next concept to learn about writing tests with NUnit is how to write assertions. An assertion is a method that will throw an exception if a certain value is not true. It will cause a test to fail and give a descriptive explanation as to what happened. NUnit has a couple of different sets of APIs for assertions; however, we will use the more readable and fluent versions of the APIs.

The basic syntax of a fluent-style API is using the Assert.That method. The following example this:

Assert.That(myVariable, Is.EqualTo(0));

Likewise, you can assert the opposite:

Assert.That(myVariable, Is.Not.EqualTo(0));

Or any of the following:

Feel free to explore the APIs. With code completion in Xamarin Studio, you should be able to discover useful static members or methods on the Is class to use within your tests.

Before we begin writing specific tests for our application, let's write a static class and method to create a global setup to be used throughout our tests. You can rewrite Test.cs as follows:

public static class Test
{
  public static void SetUp()
  {
    ServiceContainer.Register<IWebService>(() =>new FakeWebService { SleepDuration = 0 });
    ServiceContainer.Register<ISettings>(() =>new FakeSettings());
  }
}

We'll use this method throughout our tests to set up fake services in our Model layer. Additionally, this replaces the existing services so that our tests execute against new instances of these classes. This is a good practice in unit testing to guarantee that no old data is left behind from a previous test. Also, notice that we set SleepDuration to 0. This will make our tests run very quickly.

We will begin by creating a ViewModels folder in our test project and adding a class named LoginViewModelTests as follows:

[TestFixture]
public class LoginViewModelTests
{
  LoginViewModel loginViewModel;
  ISettings settings;
  [SetUp]
  public void SetUp()
  {
    Test.SetUp();
    settings = ServiceContainer.Resolve<ISettings>();
    loginViewModel = new LoginViewModel();
  }
  [Test]
  public async Task LoginSuccessfully()
  {
    loginViewModel.Username = "testuser";
    loginViewModel.Password = "password";
    await loginViewModel.Login();
    Assert.That(settings.User, Is.Not.Null);
  }
}

Notice our use of a SetUp method. We recreate the objects used in every test to make sure that no old data is left over from the previous test runs. Another point to note is that you must return a Task when using async/await in a test method. Otherwise, NUnit would not be able to know when a test completes.

To run the test, use the NUnit menu found docked to the right of Xamarin Studio, by default. Go ahead and run the test using the Run Test button that has a gear icon. You will get a successful result similar to what is shown in the following screenshot:

You can also view the Test Results pane, which will show you the extended details if a test fails, as shown in the following screenshot:

To see what happens when a test fails, go ahead and modify your test to assert against an incorrect value as follows:

//Change Is.Not.Null to Is.Null
Assert.That(settings.User, Is.Null);

You will get a very descriptive error in the Test Results pane, as shown in the following screenshot:

Now let's implement another test for the LoginViewModel class; let's make sure that we get the appropriate outcome if the username and password fields are blank. The test is implemented as follows:

[Test]
public async Task LoginWithNoUsernameOrPassword()
{
  //Throws an exception
  await loginViewModel.Login();
}

If we run the test as it is, we will get an exception and the test will fail. Since we expect an exception to occur, we can decorate the method to make the test pass only if an exception occurs as follows:

[Test, 
  ExpectedException(typeof(Exception), 
  ExpectedMessage = "Username is blank.")]

More tests are included with the sample code along with this module. It is recommended that you write tests against each public operation on each ViewModel class. Additionally, write tests for any validation or other important business logic. I would also recommend that you write tests against the Model layer; however, this is not needed in our project yet since we only have fake implementations.

The following are the methods in Navigation Controllers:

Perform the following steps to set up a Navigation Controller:

If you run the application at this point, you will have a basic iOS app with a status bar at the top, a navigation controller that contains a navigation bar with a default title, and a child controller that is completely white, as shown in the following screenshot:

The following are the methods in Navigation Controllers:

Perform the following steps to set up a Navigation Controller:

If you run the application at this point, you will have a basic iOS app with a status bar at the top, a navigation controller that contains a navigation bar with a default title, and a child controller that is completely white, as shown in the following screenshot:

Perform the following steps to set up a Navigation Controller:

If you run the application at this point, you will have a basic iOS app with a status bar at the top, a navigation controller that contains a navigation bar with a default title, and a child controller that is completely white, as shown in the following screenshot:

Return to the project in Xamarin Studio and perform the following steps:

The following screenshot shows you what the controller's settings will look like in Xamarin Studio after the changes have been made:

Now let's modify the layout of the controller by performing the following steps:

You will see that Xamarin Studio has generated properties for each of the outlets:

Go ahead and compile the application to make sure that everything is okay. At this point, we also need to add a reference to the XamChat.Core project created in the previous chapter.

Next, let's set up our iOS application to register all of its view models and other services that will be used throughout the application. We will use the ServiceContainer class that we created in Chapter 4, XamChat – a Cross-platform App, to set up the dependencies throughout our application. Open AppDelegate.cs and add the following method:

public override bool FinishedLaunching(UIApplication application,NSDictionary launchOptions)
{
  //View Models
  ServiceContainer.Register<LoginViewModel>(() =>new LoginViewModel());
  ServiceContainer.Register<FriendViewModel>(() =>new FriendViewModel());
  ServiceContainer.Register<RegisterViewModel>(() =>new RegisterViewModel());
  ServiceContainer.Register<MessageViewModel>(() =>new MessageViewModel());
  //Models
  ServiceContainer.Register<ISettings>(() =>new FakeSettings());
  ServiceContainer.Register<IWebService>(() =>new FakeWebService());
  
  return true;
}

Down the road, we will replace the fake services with the real ones. Now, let's add the login functionality to LoginController.cs. First, add LoginViewModel to a member variable at the top of the class as follows:

readonly LoginViewModel loginViewModel = ServiceContainer.Resolve<LoginViewModel>();

This will pull a shared instance of LoginViewModel into a local variable in the controller. This is the pattern that we will use throughout the module in order to pass a shared view model from one class to another.

Next, override ViewDidLoad to hook up the view model's functionality with the views set up in outlets as follows:

public override void ViewDidLoad()
{
  base.ViewDidLoad();
  login.TouchUpInside += async(sender, e) =>
  {
    loginViewModel.Username = username.Text;
    loginViewModel.Password = password.Text;
    try
    {
      await loginViewModel.Login();
      //TODO: navigate to a new screen
    }
    catch (Exception exc)
    {
      new UIAlertView("Oops!", exc.Message, null, "Ok").Show();
    }
  };
}

We'll add the code to navigate to a new screen later in the chapter.

Next, let's hook up the IsBusyChanged event to actually perform an action as follows:

public override void ViewWillAppear(bool animated)
{
  base.ViewWillAppear(animated);
  loginViewModel.IsBusyChanged += OnIsBusyChanged;
}
public override void ViewWillDisappear(bool animated)
{
  base.ViewWillDisappear(animated);
  loginViewModel.IsBusyChanged -= OnIsBusyChanged;
}
void OnIsBusyChanged(object sender, EventArgs e)
{
  username.Enabled =
    password.Enabled =
    login.Enabled = 
    indicator.Hidden = !loginViewModel.IsBusy;
}

Now you might be wondering, why we subscribe to the event in this manner. The problem is that the LoginViewModel class will last through your application's lifetime, while the LoginController class will not. If we subscribed to the event in ViewDidLoad, but didn't unsubscribe later, then our application will have a memory leak. We also avoided using a lambda expression for the event since it would otherwise be impossible to unsubscribe the event. Note that we don't have the same problem with the TouchUpInside event on the button, since it will live in memory as long as the controller does. This is a common problem with events in C#, which is why it is a good idea to use the preceding pattern on iOS.

If you run the application now, you should be able to enter a username and password, as shown in the following screenshot. When you press Login, you should see the indicator appear and all the controls disabled. Your application will correctly be calling the shared code, and should function correctly when we add a real web service.

Return to the project in Xamarin Studio and perform the following steps:

The following screenshot shows you what the controller's settings will look like in Xamarin Studio after the changes have been made:

Now let's modify the layout of the controller by performing the following steps:

You will see that Xamarin Studio has generated properties for each of the outlets:

Go ahead and compile the application to make sure that everything is okay. At this point, we also need to add a reference to the XamChat.Core project created in the previous chapter.

Next, let's set up our iOS application to register all of its view models and other services that will be used throughout the application. We will use the ServiceContainer class that we created in Chapter 4, XamChat – a Cross-platform App, to set up the dependencies throughout our application. Open AppDelegate.cs and add the following method:

public override bool FinishedLaunching(UIApplication application,NSDictionary launchOptions)
{
  //View Models
  ServiceContainer.Register<LoginViewModel>(() =>new LoginViewModel());
  ServiceContainer.Register<FriendViewModel>(() =>new FriendViewModel());
  ServiceContainer.Register<RegisterViewModel>(() =>new RegisterViewModel());
  ServiceContainer.Register<MessageViewModel>(() =>new MessageViewModel());
  //Models
  ServiceContainer.Register<ISettings>(() =>new FakeSettings());
  ServiceContainer.Register<IWebService>(() =>new FakeWebService());
  
  return true;
}

Down the road, we will replace the fake services with the real ones. Now, let's add the login functionality to LoginController.cs. First, add LoginViewModel to a member variable at the top of the class as follows:

readonly LoginViewModel loginViewModel = ServiceContainer.Resolve<LoginViewModel>();

This will pull a shared instance of LoginViewModel into a local variable in the controller. This is the pattern that we will use throughout the module in order to pass a shared view model from one class to another.

Next, override ViewDidLoad to hook up the view model's functionality with the views set up in outlets as follows:

public override void ViewDidLoad()
{
  base.ViewDidLoad();
  login.TouchUpInside += async(sender, e) =>
  {
    loginViewModel.Username = username.Text;
    loginViewModel.Password = password.Text;
    try
    {
      await loginViewModel.Login();
      //TODO: navigate to a new screen
    }
    catch (Exception exc)
    {
      new UIAlertView("Oops!", exc.Message, null, "Ok").Show();
    }
  };
}

We'll add the code to navigate to a new screen later in the chapter.

Next, let's hook up the IsBusyChanged event to actually perform an action as follows:

public override void ViewWillAppear(bool animated)
{
  base.ViewWillAppear(animated);
  loginViewModel.IsBusyChanged += OnIsBusyChanged;
}
public override void ViewWillDisappear(bool animated)
{
  base.ViewWillDisappear(animated);
  loginViewModel.IsBusyChanged -= OnIsBusyChanged;
}
void OnIsBusyChanged(object sender, EventArgs e)
{
  username.Enabled =
    password.Enabled =
    login.Enabled = 
    indicator.Hidden = !loginViewModel.IsBusy;
}

Now you might be wondering, why we subscribe to the event in this manner. The problem is that the LoginViewModel class will last through your application's lifetime, while the LoginController class will not. If we subscribed to the event in ViewDidLoad, but didn't unsubscribe later, then our application will have a memory leak. We also avoided using a lambda expression for the event since it would otherwise be impossible to unsubscribe the event. Note that we don't have the same problem with the TouchUpInside event on the button, since it will live in memory as long as the controller does. This is a common problem with events in C#, which is why it is a good idea to use the preceding pattern on iOS.

If you run the application now, you should be able to enter a username and password, as shown in the following screenshot. When you press Login, you should see the indicator appear and all the controls disabled. Your application will correctly be calling the shared code, and should function correctly when we add a real web service.

Now let's modify the layout of the controller by performing the following steps:

You will see that Xamarin Studio has generated properties for each of the outlets:

Go ahead and compile the application to make sure that everything is okay. At this point, we also need to add a reference to the XamChat.Core project created in the previous chapter.

Next, let's set up our iOS application to register all of its view models and other services that will be used throughout the application. We will use the ServiceContainer class that we created in Chapter 4, XamChat – a Cross-platform App, to set up the dependencies throughout our application. Open AppDelegate.cs and add the following method:

public override bool FinishedLaunching(UIApplication application,NSDictionary launchOptions)
{
  //View Models
  ServiceContainer.Register<LoginViewModel>(() =>new LoginViewModel());
  ServiceContainer.Register<FriendViewModel>(() =>new FriendViewModel());
  ServiceContainer.Register<RegisterViewModel>(() =>new RegisterViewModel());
  ServiceContainer.Register<MessageViewModel>(() =>new MessageViewModel());
  //Models
  ServiceContainer.Register<ISettings>(() =>new FakeSettings());
  ServiceContainer.Register<IWebService>(() =>new FakeWebService());
  
  return true;
}

Down the road, we will replace the fake services with the real ones. Now, let's add the login functionality to LoginController.cs. First, add LoginViewModel to a member variable at the top of the class as follows:

readonly LoginViewModel loginViewModel = ServiceContainer.Resolve<LoginViewModel>();

This will pull a shared instance of LoginViewModel into a local variable in the controller. This is the pattern that we will use throughout the module in order to pass a shared view model from one class to another.

Next, override ViewDidLoad to hook up the view model's functionality with the views set up in outlets as follows:

public override void ViewDidLoad()
{
  base.ViewDidLoad();
  login.TouchUpInside += async(sender, e) =>
  {
    loginViewModel.Username = username.Text;
    loginViewModel.Password = password.Text;
    try
    {
      await loginViewModel.Login();
      //TODO: navigate to a new screen
    }
    catch (Exception exc)
    {
      new UIAlertView("Oops!", exc.Message, null, "Ok").Show();
    }
  };
}

We'll add the code to navigate to a new screen later in the chapter.

Next, let's hook up the IsBusyChanged event to actually perform an action as follows:

public override void ViewWillAppear(bool animated)
{
  base.ViewWillAppear(animated);
  loginViewModel.IsBusyChanged += OnIsBusyChanged;
}
public override void ViewWillDisappear(bool animated)
{
  base.ViewWillDisappear(animated);
  loginViewModel.IsBusyChanged -= OnIsBusyChanged;
}
void OnIsBusyChanged(object sender, EventArgs e)
{
  username.Enabled =
    password.Enabled =
    login.Enabled = 
    indicator.Hidden = !loginViewModel.IsBusy;
}

Now you might be wondering, why we subscribe to the event in this manner. The problem is that the LoginViewModel class will last through your application's lifetime, while the LoginController class will not. If we subscribed to the event in ViewDidLoad, but didn't unsubscribe later, then our application will have a memory leak. We also avoided using a lambda expression for the event since it would otherwise be impossible to unsubscribe the event. Note that we don't have the same problem with the TouchUpInside event on the button, since it will live in memory as long as the controller does. This is a common problem with events in C#, which is why it is a good idea to use the preceding pattern on iOS.

If you run the application now, you should be able to enter a username and password, as shown in the following screenshot. When you press Login, you should see the indicator appear and all the controls disabled. Your application will correctly be calling the shared code, and should function correctly when we add a real web service.

Next, let's set up our iOS application to register all of its view models and other services that will be used throughout the application. We will use the ServiceContainer class that we created in Chapter 4, XamChat – a Cross-platform App, to set up the dependencies throughout our application. Open AppDelegate.cs and add the following method:

public override bool FinishedLaunching(UIApplication application,NSDictionary launchOptions)
{
  //View Models
  ServiceContainer.Register<LoginViewModel>(() =>new LoginViewModel());
  ServiceContainer.Register<FriendViewModel>(() =>new FriendViewModel());
  ServiceContainer.Register<RegisterViewModel>(() =>new RegisterViewModel());
  ServiceContainer.Register<MessageViewModel>(() =>new MessageViewModel());
  //Models
  ServiceContainer.Register<ISettings>(() =>new FakeSettings());
  ServiceContainer.Register<IWebService>(() =>new FakeWebService());
  
  return true;
}

Down the road, we will replace the fake services with the real ones. Now, let's add the login functionality to LoginController.cs. First, add LoginViewModel to a member variable at the top of the class as follows:

readonly LoginViewModel loginViewModel = ServiceContainer.Resolve<LoginViewModel>();

This will pull a shared instance of LoginViewModel into a local variable in the controller. This is the pattern that we will use throughout the module in order to pass a shared view model from one class to another.

Next, override ViewDidLoad to hook up the view model's functionality with the views set up in outlets as follows:

public override void ViewDidLoad()
{
  base.ViewDidLoad();
  login.TouchUpInside += async(sender, e) =>
  {
    loginViewModel.Username = username.Text;
    loginViewModel.Password = password.Text;
    try
    {
      await loginViewModel.Login();
      //TODO: navigate to a new screen
    }
    catch (Exception exc)
    {
      new UIAlertView("Oops!", exc.Message, null, "Ok").Show();
    }
  };
}

We'll add the code to navigate to a new screen later in the chapter.

Next, let's hook up the IsBusyChanged event to actually perform an action as follows:

public override void ViewWillAppear(bool animated)
{
  base.ViewWillAppear(animated);
  loginViewModel.IsBusyChanged += OnIsBusyChanged;
}
public override void ViewWillDisappear(bool animated)
{
  base.ViewWillDisappear(animated);
  loginViewModel.IsBusyChanged -= OnIsBusyChanged;
}
void OnIsBusyChanged(object sender, EventArgs e)
{
  username.Enabled =
    password.Enabled =
    login.Enabled = 
    indicator.Hidden = !loginViewModel.IsBusy;
}

Now you might be wondering, why we subscribe to the event in this manner. The problem is that the LoginViewModel class will last through your application's lifetime, while the LoginController class will not. If we subscribed to the event in ViewDidLoad, but didn't unsubscribe later, then our application will have a memory leak. We also avoided using a lambda expression for the event since it would otherwise be impossible to unsubscribe the event. Note that we don't have the same problem with the TouchUpInside event on the button, since it will live in memory as long as the controller does. This is a common problem with events in C#, which is why it is a good idea to use the preceding pattern on iOS.

If you run the application now, you should be able to enter a username and password, as shown in the following screenshot. When you press Login, you should see the indicator appear and all the controls disabled. Your application will correctly be calling the shared code, and should function correctly when we add a real web service.

The following are the common types of layouts:

Before we begin writing the login screen, delete the Main.axml and MainActivity.cs files that were created from the Android project template, as they are not useful for this application. Next, create an Android layout file named Login.axml in the layout folder of the Resources directory in your project.

Now we can start adding functionalities to our Android layout as follows:

Your layout will look something like what is shown in the following screenshot when complete:

Now create a new Android Activity file named LoginActivity.cs in the Activites folder we created earlier. We will use this as the main activity that starts when the application runs. Let's implement the login functionality as follows:

[Activity(Label = "@string/ApplicationName", MainLauncher = true)]
public class LoginActivity : BaseActivity<LoginViewModel>
{
  EditText username, password;
  Button login;

  protected override void OnCreate(Bundle bundle)
  {
    base.OnCreate(bundle);
    SetContentView(Resource.Layout.Login);
    username = FindViewById<EditText>(Resource.Id.username);
    password = FindViewById<EditText>(Resource.Id.password);
    login = FindViewById<Button>(Resource.Id.login);
    login.Click += OnLogin;
  }
  protected override void OnResume()
  {
    base.OnResume();
    username.Text = password.Text = string.Empty;
  }
  async void OnLogin (object sender, EventArgs e)
  {
    viewModel.Username = username.Text;
    viewModel.Password = password.Text;
    try
    {
      await viewModel.Login();
        //TODO: navigate to a new activity
    }
    catch (Exception exc)
    {
      DisplayError(exc);
    }
  }
}

Notice that we set MainLauncher to true to make this activity the first activity for the application. In some apps, a splash screen is used as the first activity, so keep this in mind if you need to add a splash screen. We also took advantage of the ApplicationName value and the BaseActivity class we set up earlier in the chapter. We also overrode OnResume to clear out the two EditText controls so that the values are cleared out if you return to the screen.

Now if you launch the application, you will be greeted by the login screen we just implemented, as shown in the following screenshot:

The following are the common types of layouts:

Before we begin writing the login screen, delete the Main.axml and MainActivity.cs files that were created from the Android project template, as they are not useful for this application. Next, create an Android layout file named Login.axml in the layout folder of the Resources directory in your project.

Now we can start adding functionalities to our Android layout as follows:

Your layout will look something like what is shown in the following screenshot when complete:

Now create a new Android Activity file named LoginActivity.cs in the Activites folder we created earlier. We will use this as the main activity that starts when the application runs. Let's implement the login functionality as follows:

[Activity(Label = "@string/ApplicationName", MainLauncher = true)]
public class LoginActivity : BaseActivity<LoginViewModel>
{
  EditText username, password;
  Button login;

  protected override void OnCreate(Bundle bundle)
  {
    base.OnCreate(bundle);
    SetContentView(Resource.Layout.Login);
    username = FindViewById<EditText>(Resource.Id.username);
    password = FindViewById<EditText>(Resource.Id.password);
    login = FindViewById<Button>(Resource.Id.login);
    login.Click += OnLogin;
  }
  protected override void OnResume()
  {
    base.OnResume();
    username.Text = password.Text = string.Empty;
  }
  async void OnLogin (object sender, EventArgs e)
  {
    viewModel.Username = username.Text;
    viewModel.Password = password.Text;
    try
    {
      await viewModel.Login();
        //TODO: navigate to a new activity
    }
    catch (Exception exc)
    {
      DisplayError(exc);
    }
  }
}

Notice that we set MainLauncher to true to make this activity the first activity for the application. In some apps, a splash screen is used as the first activity, so keep this in mind if you need to add a splash screen. We also took advantage of the ApplicationName value and the BaseActivity class we set up earlier in the chapter. We also overrode OnResume to clear out the two EditText controls so that the values are cleared out if you return to the screen.

Now if you launch the application, you will be greeted by the login screen we just implemented, as shown in the following screenshot:

Now create a new Android Activity file named LoginActivity.cs in the Activites folder we created earlier. We will use this as the main activity that starts when the application runs. Let's implement the login functionality as follows:

[Activity(Label = "@string/ApplicationName", MainLauncher = true)]
public class LoginActivity : BaseActivity<LoginViewModel>
{
  EditText username, password;
  Button login;

  protected override void OnCreate(Bundle bundle)
  {
    base.OnCreate(bundle);
    SetContentView(Resource.Layout.Login);
    username = FindViewById<EditText>(Resource.Id.username);
    password = FindViewById<EditText>(Resource.Id.password);
    login = FindViewById<Button>(Resource.Id.login);
    login.Click += OnLogin;
  }
  protected override void OnResume()
  {
    base.OnResume();
    username.Text = password.Text = string.Empty;
  }
  async void OnLogin (object sender, EventArgs e)
  {
    viewModel.Username = username.Text;
    viewModel.Password = password.Text;
    try
    {
      await viewModel.Login();
        //TODO: navigate to a new activity
    }
    catch (Exception exc)
    {
      DisplayError(exc);
    }
  }
}

Notice that we set MainLauncher to true to make this activity the first activity for the application. In some apps, a splash screen is used as the first activity, so keep this in mind if you need to add a splash screen. We also took advantage of the ApplicationName value and the BaseActivity class we set up earlier in the chapter. We also overrode OnResume to clear out the two EditText controls so that the values are cleared out if you return to the screen.

Now if you launch the application, you will be greeted by the login screen we just implemented, as shown in the following screenshot:

Let's implement our conversations screen. Let's begin by making a new Android Activity in your Activities folder named ConversationsActivity.cs. Let's start with only a couple of changes to the class definition as follows:

[Activity(Label = "Conversations")]
public class ConversationsActivity :BaseActivity<MessageViewModel>
{
  //Other code here later
}

Perform the following steps to implement a couple of Android layouts:

This will set up all the layout files we'll need to use throughout the conversations screen. Your ConversationListItem.axml layout will look something like what's shown in the following screenshot:

Now we can implement BaseAdapter as a nested class inside ConversationsActivity as follows:

class Adapter : BaseAdapter<Conversation>
{
  readonly MessageViewModel messageViewModel = ServiceContainer.Resolve<MessageViewModel>();
  readonly LayoutInflater inflater;

  public Adapter(Context context)
  {
    inflater = (LayoutInflater)context.GetSystemService (Context.LayoutInflaterService);
  }
  public override long GetItemId(int position)
  {
    //This is an abstract method, just a simple implementation
    return position;
  }
  public override View GetView(int position, View convertView, ViewGroup parent)
  {
    if (convertView == null)
    {
      convertView = inflater.Inflate (Resource.Layout.ConversationListItem, null);
    }
    var conversation = this [position];
    var username = convertView.FindViewById<TextView>(Resource.Id.conversationUsername);
    var lastMessage = convertView.FindViewById<TextView>(Resource.Id.conversationLastMessage);
    username.Text = conversation.Username;
    lastMessage.Text = conversation.LastMessage;
    return convertView;
  }
  public override int Count
  {
    get { return messageViewModel.Conversations == null ? 0: messageViewModel.Conversations.Length; }
  }
  public override Conversation this[int index]
  {
    get { return messageViewModel.Conversations [index]; }
  }
}

The following is a review of what is going on inside the adapter:

Overall, this should be fairly similar to what we did on iOS.

Now let's set up the adapter in our activity by adding the following to the body of ConversationsActivity:

ListView listView;
Adapter adapter;

protected override void OnCreate(Bundle bundle)
{
  base.OnCreate(bundle);
  SetContentView(Resource.Layout.Conversations);
  listView = FindViewById<ListView>(Resource.Id.conversationsList);
  listView.Adapter = adapter = new Adapter(this);
}
protected async override void OnResume()
{
  base.OnResume();
  try
  {
    await viewModel.GetConversations();
    adapter.NotifyDataSetInvalidated();
  }
  catch (Exception exc)
  {
    DisplayError(exc);
  }
}

This code will set up the adapter and reload our list of conversations when the activity appears on the screen. Note that we called NotifyDataSetInvalidated here so that ListView reloads its rows after the number of conversations has been updated. This is parallel to what we did on iOS by calling the UITableView's ReloadData method.

Last but not least, we need to modify the OnLogin method we set up earlier in LoginActivity to start our new activity as follows:

StartActivity(typeof(ConversationsActivity));

Now if we compile and run our application, we can navigate to a conversations list after logging in, as shown in the following screenshot:

Let's implement our conversations screen. Let's begin by making a new Android Activity in your Activities folder named ConversationsActivity.cs. Let's start with only a couple of changes to the class definition as follows:

[Activity(Label = "Conversations")]
public class ConversationsActivity :BaseActivity<MessageViewModel>
{
  //Other code here later
}

Perform the following steps to implement a couple of Android layouts:

This will set up all the layout files we'll need to use throughout the conversations screen. Your ConversationListItem.axml layout will look something like what's shown in the following screenshot:

Now we can implement BaseAdapter as a nested class inside ConversationsActivity as follows:

class Adapter : BaseAdapter<Conversation>
{
  readonly MessageViewModel messageViewModel = ServiceContainer.Resolve<MessageViewModel>();
  readonly LayoutInflater inflater;

  public Adapter(Context context)
  {
    inflater = (LayoutInflater)context.GetSystemService (Context.LayoutInflaterService);
  }
  public override long GetItemId(int position)
  {
    //This is an abstract method, just a simple implementation
    return position;
  }
  public override View GetView(int position, View convertView, ViewGroup parent)
  {
    if (convertView == null)
    {
      convertView = inflater.Inflate (Resource.Layout.ConversationListItem, null);
    }
    var conversation = this [position];
    var username = convertView.FindViewById<TextView>(Resource.Id.conversationUsername);
    var lastMessage = convertView.FindViewById<TextView>(Resource.Id.conversationLastMessage);
    username.Text = conversation.Username;
    lastMessage.Text = conversation.LastMessage;
    return convertView;
  }
  public override int Count
  {
    get { return messageViewModel.Conversations == null ? 0: messageViewModel.Conversations.Length; }
  }
  public override Conversation this[int index]
  {
    get { return messageViewModel.Conversations [index]; }
  }
}

The following is a review of what is going on inside the adapter:

Overall, this should be fairly similar to what we did on iOS.

Now let's set up the adapter in our activity by adding the following to the body of ConversationsActivity:

ListView listView;
Adapter adapter;

protected override void OnCreate(Bundle bundle)
{
  base.OnCreate(bundle);
  SetContentView(Resource.Layout.Conversations);
  listView = FindViewById<ListView>(Resource.Id.conversationsList);
  listView.Adapter = adapter = new Adapter(this);
}
protected async override void OnResume()
{
  base.OnResume();
  try
  {
    await viewModel.GetConversations();
    adapter.NotifyDataSetInvalidated();
  }
  catch (Exception exc)
  {
    DisplayError(exc);
  }
}

This code will set up the adapter and reload our list of conversations when the activity appears on the screen. Note that we called NotifyDataSetInvalidated here so that ListView reloads its rows after the number of conversations has been updated. This is parallel to what we did on iOS by calling the UITableView's ReloadData method.

Last but not least, we need to modify the OnLogin method we set up earlier in LoginActivity to start our new activity as follows:

StartActivity(typeof(ConversationsActivity));

Now if we compile and run our application, we can navigate to a conversations list after logging in, as shown in the following screenshot:

Now let's set up the adapter in our activity by adding the following to the body of ConversationsActivity:

ListView listView;
Adapter adapter;

protected override void OnCreate(Bundle bundle)
{
  base.OnCreate(bundle);
  SetContentView(Resource.Layout.Conversations);
  listView = FindViewById<ListView>(Resource.Id.conversationsList);
  listView.Adapter = adapter = new Adapter(this);
}
protected async override void OnResume()
{
  base.OnResume();
  try
  {
    await viewModel.GetConversations();
    adapter.NotifyDataSetInvalidated();
  }
  catch (Exception exc)
  {
    DisplayError(exc);
  }
}

This code will set up the adapter and reload our list of conversations when the activity appears on the screen. Note that we called NotifyDataSetInvalidated here so that ListView reloads its rows after the number of conversations has been updated. This is parallel to what we did on iOS by calling the UITableView's ReloadData method.

Last but not least, we need to modify the OnLogin method we set up earlier in LoginActivity to start our new activity as follows:

StartActivity(typeof(ConversationsActivity));

Now if we compile and run our application, we can navigate to a conversations list after logging in, as shown in the following screenshot:

Let's take a look at the first problem where the GC cannot keep up. Let's say we have a Xamarin.iOS application with a button for sharing an image on Twitter as follows:

twitterShare.TouchUpInside += (sender, e) =>
{
  var image = UImage.FromFile("YourLargeImage.png");
  //Share to Twitter
};

Now let's assume the image is a 10 MB image from the user's camera roll. If the user clicks on the button and cancels the Twitter post rapidly, there could be a possibility of your application running out of memory. iOS will commonly force close apps using too much memory, and you don't want users to experience this with your app.

The best solution is to call Dispose on the image when you are finished with it as follows:

var image = UImage.FromFile('YourLargeImage.png");
//Share to Twitter
image.Dispose();

An even better approach would be to take advantage of the C# using statement as follows:

using(var image = UImage.FromFile('YourLargeImage.png"))
{
  //Share to Twitter
}

The C# using statement will automatically call Dispose in a try-finally block, so the object will get disposed even if an exception is thrown. I recommend that you take advantage of the using statement for any IDisposable class where possible. It is not always necessary for small objects such as NSString, but is always a good idea for larger, more heavyweight UIKit objects.

Memory leaks are the next potential issues. C# being a managed, garbage-collected language prevents a lot of memory leaks, but not all of them. The most common leaks in C# are caused by events.

Let's assume that we have a static class with an event as follows:

static class MyStatic
{
  public static event EventHandler MyEvent;
}

Now, let's say we need to subscribe to the event from an iOS controller as follows:

public override void ViewDidLoad()
{
  base.ViewDidLoad();

  MyStatic.MyEvent += (sender, e) =>
  {
    //Do something
  };
}

The problem here is that the static class will hold a reference to the controller until the event is unsubscribed. This is a situation that a lot of developers might miss. To fix this issue on iOS, I would subscribe to the event in ViewWillAppear and unsubscribe ViewWillDisappear. On Android, use OnStart and OnStop, or OnPause and OnResume.

You would correctly implement this event as follows:

public override void ViewWillAppear()
{
  base.ViewWillAppear();
  MyStatic.MyEvent += OnMyEvent;
}

public override void ViewWillDisappear()
{
  base.ViewWillDisappear ();
  MyStatic.MyEvent -= OnMyEvent;
}

However, an event is not a surefire cause of a memory leak. Subscribing to the TouchUpInside event on a button inside the ViewDidLoad method, for example, is just fine. Since the button lives in memory just as long as the controller does, everything can get garbage collected without any problems.

For the final issue, the garbage collector can sometimes remove a C# object. Later, an Objective-C object attempts to access it.

The following is an example to add a button to UITableViewCell:

public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
{
  var cell = tableView.DequeueReusableCell('MyCell");
  //Remaining cell setup here

  var button = UIButton.FromType(UIButtonType.InfoDark);
  button.TouchUpInside += (sender, e) =>
  {
    //Do something
  };
  cell.AccessoryView = button;
  return cell;
}

We add the built-in info button as an accessory view to the cell. The problem here is that the button will get garbage collected, but its Objective-C counterpart will remain in use as it is displayed on the screen. If you click on the button after some period of time, you will get a crash that looks something similar to the following:

mono-rt: Stacktrace:
mono-rt:   at <unknown>
mono-rt:   at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication.UIApplicationMain (int,string[],intptr,intptr) 
mono-rt:   at MonoTouch.UIKit.UIApplication.Main (string[],string,string)  
... Continued ...
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
================================================================

It is not the most descriptive error message, but in general, you know that something went wrong in the native Objective-C code. To resolve the issue, create a custom subclass of UITableViewCell, and create a dedicated member variable for the button as follows:

public class MyCell : UITableViewCell
{
  UIButton button;
  public MyCell()
  {
    button = UIButton.FromType(UIButtonType.InfoDark);
    button.TouchUpInside += (sender, e) => 
    {
      //Do something
    };
    AccessoryView = button;
  }
}

Now, your GetCell implementation will look something like the following code:

public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
{
  var cell = tableView.DequeueReusableCell('MyCell") as MyCell;
  //Remaining cell setup here
  return cell;
}

Since the button is not a local variable, it will no longer get garbage collected sooner than needed. A crash is avoided, and in some ways this code is a bit cleaner. Similar situations can happen on Android with the interaction between C# and Java; however, it is less likely since both are garbage collected languages.

Let's take a look at the first problem where the GC cannot keep up. Let's say we have a Xamarin.iOS application with a button for sharing an image on Twitter as follows:

twitterShare.TouchUpInside += (sender, e) =>
{
  var image = UImage.FromFile("YourLargeImage.png");
  //Share to Twitter
};

Now let's assume the image is a 10 MB image from the user's camera roll. If the user clicks on the button and cancels the Twitter post rapidly, there could be a possibility of your application running out of memory. iOS will commonly force close apps using too much memory, and you don't want users to experience this with your app.

The best solution is to call Dispose on the image when you are finished with it as follows:

var image = UImage.FromFile('YourLargeImage.png");
//Share to Twitter
image.Dispose();

An even better approach would be to take advantage of the C# using statement as follows:

using(var image = UImage.FromFile('YourLargeImage.png"))
{
  //Share to Twitter
}

The C# using statement will automatically call Dispose in a try-finally block, so the object will get disposed even if an exception is thrown. I recommend that you take advantage of the using statement for any IDisposable class where possible. It is not always necessary for small objects such as NSString, but is always a good idea for larger, more heavyweight UIKit objects.

Memory leaks are the next potential issues. C# being a managed, garbage-collected language prevents a lot of memory leaks, but not all of them. The most common leaks in C# are caused by events.

Let's assume that we have a static class with an event as follows:

static class MyStatic
{
  public static event EventHandler MyEvent;
}

Now, let's say we need to subscribe to the event from an iOS controller as follows:

public override void ViewDidLoad()
{
  base.ViewDidLoad();

  MyStatic.MyEvent += (sender, e) =>
  {
    //Do something
  };
}

The problem here is that the static class will hold a reference to the controller until the event is unsubscribed. This is a situation that a lot of developers might miss. To fix this issue on iOS, I would subscribe to the event in ViewWillAppear and unsubscribe ViewWillDisappear. On Android, use OnStart and OnStop, or OnPause and OnResume.

You would correctly implement this event as follows:

public override void ViewWillAppear()
{
  base.ViewWillAppear();
  MyStatic.MyEvent += OnMyEvent;
}

public override void ViewWillDisappear()
{
  base.ViewWillDisappear ();
  MyStatic.MyEvent -= OnMyEvent;
}

However, an event is not a surefire cause of a memory leak. Subscribing to the TouchUpInside event on a button inside the ViewDidLoad method, for example, is just fine. Since the button lives in memory just as long as the controller does, everything can get garbage collected without any problems.

For the final issue, the garbage collector can sometimes remove a C# object. Later, an Objective-C object attempts to access it.

The following is an example to add a button to UITableViewCell:

public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
{
  var cell = tableView.DequeueReusableCell('MyCell");
  //Remaining cell setup here

  var button = UIButton.FromType(UIButtonType.InfoDark);
  button.TouchUpInside += (sender, e) =>
  {
    //Do something
  };
  cell.AccessoryView = button;
  return cell;
}

We add the built-in info button as an accessory view to the cell. The problem here is that the button will get garbage collected, but its Objective-C counterpart will remain in use as it is displayed on the screen. If you click on the button after some period of time, you will get a crash that looks something similar to the following:

mono-rt: Stacktrace:
mono-rt:   at <unknown>
mono-rt:   at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication.UIApplicationMain (int,string[],intptr,intptr) 
mono-rt:   at MonoTouch.UIKit.UIApplication.Main (string[],string,string)  
... Continued ...
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
================================================================

It is not the most descriptive error message, but in general, you know that something went wrong in the native Objective-C code. To resolve the issue, create a custom subclass of UITableViewCell, and create a dedicated member variable for the button as follows:

public class MyCell : UITableViewCell
{
  UIButton button;
  public MyCell()
  {
    button = UIButton.FromType(UIButtonType.InfoDark);
    button.TouchUpInside += (sender, e) => 
    {
      //Do something
    };
    AccessoryView = button;
  }
}

Now, your GetCell implementation will look something like the following code:

public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
{
  var cell = tableView.DequeueReusableCell('MyCell") as MyCell;
  //Remaining cell setup here
  return cell;
}

Since the button is not a local variable, it will no longer get garbage collected sooner than needed. A crash is avoided, and in some ways this code is a bit cleaner. Similar situations can happen on Android with the interaction between C# and Java; however, it is less likely since both are garbage collected languages.

Memory leaks are the next potential issues. C# being a managed, garbage-collected language prevents a lot of memory leaks, but not all of them. The most common leaks in C# are caused by events.

Let's assume that we have a static class with an event as follows:

static class MyStatic
{
  public static event EventHandler MyEvent;
}

Now, let's say we need to subscribe to the event from an iOS controller as follows:

public override void ViewDidLoad()
{
  base.ViewDidLoad();

  MyStatic.MyEvent += (sender, e) =>
  {
    //Do something
  };
}

The problem here is that the static class will hold a reference to the controller until the event is unsubscribed. This is a situation that a lot of developers might miss. To fix this issue on iOS, I would subscribe to the event in ViewWillAppear and unsubscribe ViewWillDisappear. On Android, use OnStart and OnStop, or OnPause and OnResume.

You would correctly implement this event as follows:

public override void ViewWillAppear()
{
  base.ViewWillAppear();
  MyStatic.MyEvent += OnMyEvent;
}

public override void ViewWillDisappear()
{
  base.ViewWillDisappear ();
  MyStatic.MyEvent -= OnMyEvent;
}

However, an event is not a surefire cause of a memory leak. Subscribing to the TouchUpInside event on a button inside the ViewDidLoad method, for example, is just fine. Since the button lives in memory just as long as the controller does, everything can get garbage collected without any problems.

For the final issue, the garbage collector can sometimes remove a C# object. Later, an Objective-C object attempts to access it.

The following is an example to add a button to UITableViewCell:

public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
{
  var cell = tableView.DequeueReusableCell('MyCell");
  //Remaining cell setup here

  var button = UIButton.FromType(UIButtonType.InfoDark);
  button.TouchUpInside += (sender, e) =>
  {
    //Do something
  };
  cell.AccessoryView = button;
  return cell;
}

We add the built-in info button as an accessory view to the cell. The problem here is that the button will get garbage collected, but its Objective-C counterpart will remain in use as it is displayed on the screen. If you click on the button after some period of time, you will get a crash that looks something similar to the following:

mono-rt: Stacktrace:
mono-rt:   at <unknown>
mono-rt:   at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication.UIApplicationMain (int,string[],intptr,intptr) 
mono-rt:   at MonoTouch.UIKit.UIApplication.Main (string[],string,string)  
... Continued ...
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
================================================================

It is not the most descriptive error message, but in general, you know that something went wrong in the native Objective-C code. To resolve the issue, create a custom subclass of UITableViewCell, and create a dedicated member variable for the button as follows:

public class MyCell : UITableViewCell
{
  UIButton button;
  public MyCell()
  {
    button = UIButton.FromType(UIButtonType.InfoDark);
    button.TouchUpInside += (sender, e) => 
    {
      //Do something
    };
    AccessoryView = button;
  }
}

Now, your GetCell implementation will look something like the following code:

public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
{
  var cell = tableView.DequeueReusableCell('MyCell") as MyCell;
  //Remaining cell setup here
  return cell;
}

Since the button is not a local variable, it will no longer get garbage collected sooner than needed. A crash is avoided, and in some ways this code is a bit cleaner. Similar situations can happen on Android with the interaction between C# and Java; however, it is less likely since both are garbage collected languages.

For the final issue, the garbage collector can sometimes remove a C# object. Later, an Objective-C object attempts to access it.

The following is an example to add a button to UITableViewCell:

public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
{
  var cell = tableView.DequeueReusableCell('MyCell");
  //Remaining cell setup here

  var button = UIButton.FromType(UIButtonType.InfoDark);
  button.TouchUpInside += (sender, e) =>
  {
    //Do something
  };
  cell.AccessoryView = button;
  return cell;
}

We add the built-in info button as an accessory view to the cell. The problem here is that the button will get garbage collected, but its Objective-C counterpart will remain in use as it is displayed on the screen. If you click on the button after some period of time, you will get a crash that looks something similar to the following:

mono-rt: Stacktrace:
mono-rt:   at <unknown>
mono-rt:   at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication.UIApplicationMain (int,string[],intptr,intptr) 
mono-rt:   at MonoTouch.UIKit.UIApplication.Main (string[],string,string)  
... Continued ...
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
================================================================

It is not the most descriptive error message, but in general, you know that something went wrong in the native Objective-C code. To resolve the issue, create a custom subclass of UITableViewCell, and create a dedicated member variable for the button as follows:

public class MyCell : UITableViewCell
{
  UIButton button;
  public MyCell()
  {
    button = UIButton.FromType(UIButtonType.InfoDark);
    button.TouchUpInside += (sender, e) => 
    {
      //Do something
    };
    AccessoryView = button;
  }
}

Now, your GetCell implementation will look something like the following code:

public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
{
  var cell = tableView.DequeueReusableCell('MyCell") as MyCell;
  //Remaining cell setup here
  return cell;
}

Since the button is not a local variable, it will no longer get garbage collected sooner than needed. A crash is avoided, and in some ways this code is a bit cleaner. Similar situations can happen on Android with the interaction between C# and Java; however, it is less likely since both are garbage collected languages.

To make development with Azure Mobile Services much easier, we need to add a reference to the .NET client library. To do this, we will use NuGet to add the library:

This will download the library and automatically add references to it in your projects. The NuGet package manager might complain of warnings, which can be ignored. NuGet was originally developed for Visual Studio on Windows, so any packages that contain PowerShell scripts or prompt for a license agreement might give you a warning.

Now, let's modify our AzureWebService.cs file. Add using Microsoft.WindowsAzure.MobileServices to the top of the file, and then make the following changes:

public class AzureWebService : IWebService
{
  MobileServiceClient client = new MobileServiceClient("https://your-service-name.azure-mobile.net/", "your-application-key");

  // -- Existing code here --
}

Make sure you fill in your mobile service name and application key. You can find your key on the Dashboard tab of the Azure Management Portal under the Manage Keys section.

Now let's implement our first method, Login, in the following manner:

public async Task<User> Login(string username, string password)
{
  var user = new User 
  {
    Username = username, 
    Password = password 
  };
  await client.GetTable<User>().InsertAsync(user);
  return user;
}

This is fairly straightforward, because of how nice this library is to use. The GetTable<T> method knows how to use a table named User based on the C# class name. Upon the first call, the dynamic schema feature will create two new columns named Username and Password based on the C# properties of our class. Note that the InsertAsync method will also fill in the user's Id property for later use in our application since we will need the Id for future calls to the mobile service.

Next, open the AppDelegate.cs file to set up our new service and add the following code:

//Replace this line
ServiceContainer.Register<IWebService>(() => new FakeWebService());

//With this line
ServiceContainer.Register<IWebService>(() => new AzureWebService());

Additionally, you will need to add some platform-specific setup for Azure Mobile Services. Add using Microsoft.WindowsAzure.MobileServices to the top of the file and add the following line of code to the bottom of FinishedLaunching in your AppDelegate.cs file:

CurrentPlatform.Init();

Now, if you compile and run your application after you log in, your app should successfully call Azure Mobile Services and insert a new user. Navigate to the Data tab of your Azure Mobile Service in the Azure Management Portal, and select the User table. You will see the user you just inserted, as shown in the following screenshot:

Next, let's make a new class named Friend.cs. Add it to the Azure folder that is next to the other class specific to Azure as follows:

public class Friend
{
  public string Id { get; set; }
  public string MyId { get; set; }
  public string UserId { get; set; }
  public string Username { get; set; }
}

We'll use this class to store the friends information about each user. Note that we also have an Id property, and all the classes saved in Azure Mobile Services should have a string property named Id. This will be the table's primary key in the SQL database.

Next, let's modify the Message and Conversation classes to prepare for push notifications down the road. Add a new property to the Message class as follows:

public string ToId { get; set; }

Then, add the following new property to Conversation.cs:

public string MyId { get; set; }

Here, we'll need to insert or seed some test data for our application to function correctly. The easiest way to insert data would be from C#, so let's implement the following simple method on our service to do so:

public async Task LoadData()
{
  var users = client.GetTable<User>();
  var friends = client.GetTable<Friend>();

  var me = new User
  {
    Username = "jonathanpeppers",
    Password = "password"
  };
  var friend = new User
  {
    Username = "chucknorris",
    Password = "password"
  };
  await users.InsertAsync(me);
  await users.InsertAsync(friend);
  await friends.InsertAsync(new Friend { MyId = me.Id, Username = friend.Username });
  await friends.InsertAsync(new Friend { MyId = friend.Id, Username = me.Username });
}

Next, let's add the following method to AppDelegate.cs and call it from within FinishedLaunching:

private async void LoadData()
{
  var service = ServiceContainer.Resolve<IWebService>() as AzureWebService;
  await service.LoadData();
}

If you run your application at this point, it will insert two users and make them friends with one another. Before doing so, let's add some more code to the LoadData method in AzureWebService.cs to insert conversations and messages as follows:

var conversations = client.GetTable<Conversation>();
var messages = client.GetTable<Message>();

var conversation = new Conversation
{
  MyId = me.Id,
  UserId = friend.Id,
  Username = friend.Username,
  LastMessage = "HEY!"
};
await conversations.InsertAsync(conversation);
await messages.InsertAsync(new Message { 
  ConversationId = conversation.Id, 
  ToId = me.Id,
  UserId = friend.Id, Username = friend.Username, 
  Text = "What's up?", Date = DateTime.Now.AddSeconds(-60)
});
await messages.InsertAsync(new Message { 
  ConversationId = conversation.Id, 
  ToId = friend.Id,
  UserId = me.Id, Username = me.Username, 
  Text = "Not much", Date = DateTime.Now.AddSeconds(-30)
});
await messages.InsertAsync(new Message { 
  ConversationId = conversation.Id, 
  ToId = me.Id,
  UserId = friend.Id, Username = friend.Username, 
  Text = "HEY!", Date = DateTime.Now
});

Now, if you run the application, it will seed the database with some good data to work with. I'd recommend that you remove the call to LoadData once it is successful the first time, and perhaps remove the method entirely when the development is complete.

Before going further, let's implement the rest of our IWebService interface. It can be done as follows:

public async Task<User> Register(User user)
{
  await client.GetTable<User>().InsertAsync(user);
  return user;
}
public async Task<User[]> GetFriends(string userId)
{
  var list = await client.GetTable<Friend>().Where(f => f.MyId == userId).ToListAsync();
  return list.Select(f => new User { Id = f.UserId, Username = f.Username }).ToArray();
}
public async Task<User> AddFriend( string userId, string username)
{
  var friend = new Friend { MyId = userId, Username = username };
  await client.GetTable<Friend>().InsertAsync(friend);
  return new User { Id = friend.UserId, Username = friend.Username };
}

Each method here is pretty simple. Register is very similar to Login, but the main complication for the other methods is the need to convert a Friend object to User. We used the ToListAsync method from the Azure library to get List<T>; however, since our interface uses arrays, we quickly converted the list to an array. We also utilized a couple of basic Linq operators such as Where and Select to accomplish our implementation of IWebService.

Now let's complete the methods related to conversations and messages, which are as follows:

public async Task<Conversation[]> GetConversations(string userId)
{
  var list = await client.GetTable<Conversation>().Where(c => c.MyId == userId).ToListAsync();
  return list.ToArray();
}
public async Task<Message[]> GetMessages(string conversationId)
{
  var list = await client.GetTable<Message>().Where(m => m.ConversationId == conversationId).ToListAsync();
  return list.ToArray();
}
public async Task<Message> SendMessage(Message message)
{
  await client.GetTable<Message>().InsertAsync(message);
  return message;
}

This completes our implementation of IWebService. If you run the application at this point, it will function exactly as before with the exception that the app is actually talking to a real web server. New messages will get persisted in the SQL database, and our custom scripts will handle the custom logic that we need. Feel free to play around with our implementation; you might discover some features of Azure Mobile Services that will work great with your own applications.

At this point, another good exercise would be to set up Azure Mobile Services in our Android application. To do so, you will merely need to add the Azure Mobile Services NuGet package. After that, you should be able to swap out the ServiceContainer.Register call in your Application class and call CurrentPlatform.Init(). Everything will function exactly like on iOS. Isn't cross-platform development great?

To make development with Azure Mobile Services much easier, we need to add a reference to the .NET client library. To do this, we will use NuGet to add the library:

This will download the library and automatically add references to it in your projects. The NuGet package manager might complain of warnings, which can be ignored. NuGet was originally developed for Visual Studio on Windows, so any packages that contain PowerShell scripts or prompt for a license agreement might give you a warning.

Now, let's modify our AzureWebService.cs file. Add using Microsoft.WindowsAzure.MobileServices to the top of the file, and then make the following changes:

public class AzureWebService : IWebService
{
  MobileServiceClient client = new MobileServiceClient("https://your-service-name.azure-mobile.net/", "your-application-key");

  // -- Existing code here --
}

Make sure you fill in your mobile service name and application key. You can find your key on the Dashboard tab of the Azure Management Portal under the Manage Keys section.

Now let's implement our first method, Login, in the following manner:

public async Task<User> Login(string username, string password)
{
  var user = new User 
  {
    Username = username, 
    Password = password 
  };
  await client.GetTable<User>().InsertAsync(user);
  return user;
}

This is fairly straightforward, because of how nice this library is to use. The GetTable<T> method knows how to use a table named User based on the C# class name. Upon the first call, the dynamic schema feature will create two new columns named Username and Password based on the C# properties of our class. Note that the InsertAsync method will also fill in the user's Id property for later use in our application since we will need the Id for future calls to the mobile service.

Next, open the AppDelegate.cs file to set up our new service and add the following code:

//Replace this line
ServiceContainer.Register<IWebService>(() => new FakeWebService());

//With this line
ServiceContainer.Register<IWebService>(() => new AzureWebService());

Additionally, you will need to add some platform-specific setup for Azure Mobile Services. Add using Microsoft.WindowsAzure.MobileServices to the top of the file and add the following line of code to the bottom of FinishedLaunching in your AppDelegate.cs file:

CurrentPlatform.Init();

Now, if you compile and run your application after you log in, your app should successfully call Azure Mobile Services and insert a new user. Navigate to the Data tab of your Azure Mobile Service in the Azure Management Portal, and select the User table. You will see the user you just inserted, as shown in the following screenshot:

Next, let's make a new class named Friend.cs. Add it to the Azure folder that is next to the other class specific to Azure as follows:

public class Friend
{
  public string Id { get; set; }
  public string MyId { get; set; }
  public string UserId { get; set; }
  public string Username { get; set; }
}

We'll use this class to store the friends information about each user. Note that we also have an Id property, and all the classes saved in Azure Mobile Services should have a string property named Id. This will be the table's primary key in the SQL database.

Next, let's modify the Message and Conversation classes to prepare for push notifications down the road. Add a new property to the Message class as follows:

public string ToId { get; set; }

Then, add the following new property to Conversation.cs:

public string MyId { get; set; }

Here, we'll need to insert or seed some test data for our application to function correctly. The easiest way to insert data would be from C#, so let's implement the following simple method on our service to do so:

public async Task LoadData()
{
  var users = client.GetTable<User>();
  var friends = client.GetTable<Friend>();

  var me = new User
  {
    Username = "jonathanpeppers",
    Password = "password"
  };
  var friend = new User
  {
    Username = "chucknorris",
    Password = "password"
  };
  await users.InsertAsync(me);
  await users.InsertAsync(friend);
  await friends.InsertAsync(new Friend { MyId = me.Id, Username = friend.Username });
  await friends.InsertAsync(new Friend { MyId = friend.Id, Username = me.Username });
}

Next, let's add the following method to AppDelegate.cs and call it from within FinishedLaunching:

private async void LoadData()
{
  var service = ServiceContainer.Resolve<IWebService>() as AzureWebService;
  await service.LoadData();
}

If you run your application at this point, it will insert two users and make them friends with one another. Before doing so, let's add some more code to the LoadData method in AzureWebService.cs to insert conversations and messages as follows:

var conversations = client.GetTable<Conversation>();
var messages = client.GetTable<Message>();

var conversation = new Conversation
{
  MyId = me.Id,
  UserId = friend.Id,
  Username = friend.Username,
  LastMessage = "HEY!"
};
await conversations.InsertAsync(conversation);
await messages.InsertAsync(new Message { 
  ConversationId = conversation.Id, 
  ToId = me.Id,
  UserId = friend.Id, Username = friend.Username, 
  Text = "What's up?", Date = DateTime.Now.AddSeconds(-60)
});
await messages.InsertAsync(new Message { 
  ConversationId = conversation.Id, 
  ToId = friend.Id,
  UserId = me.Id, Username = me.Username, 
  Text = "Not much", Date = DateTime.Now.AddSeconds(-30)
});
await messages.InsertAsync(new Message { 
  ConversationId = conversation.Id, 
  ToId = me.Id,
  UserId = friend.Id, Username = friend.Username, 
  Text = "HEY!", Date = DateTime.Now
});

Now, if you run the application, it will seed the database with some good data to work with. I'd recommend that you remove the call to LoadData once it is successful the first time, and perhaps remove the method entirely when the development is complete.

Before going further, let's implement the rest of our IWebService interface. It can be done as follows:

public async Task<User> Register(User user)
{
  await client.GetTable<User>().InsertAsync(user);
  return user;
}
public async Task<User[]> GetFriends(string userId)
{
  var list = await client.GetTable<Friend>().Where(f => f.MyId == userId).ToListAsync();
  return list.Select(f => new User { Id = f.UserId, Username = f.Username }).ToArray();
}
public async Task<User> AddFriend( string userId, string username)
{
  var friend = new Friend { MyId = userId, Username = username };
  await client.GetTable<Friend>().InsertAsync(friend);
  return new User { Id = friend.UserId, Username = friend.Username };
}

Each method here is pretty simple. Register is very similar to Login, but the main complication for the other methods is the need to convert a Friend object to User. We used the ToListAsync method from the Azure library to get List<T>; however, since our interface uses arrays, we quickly converted the list to an array. We also utilized a couple of basic Linq operators such as Where and Select to accomplish our implementation of IWebService.

Now let's complete the methods related to conversations and messages, which are as follows:

public async Task<Conversation[]> GetConversations(string userId)
{
  var list = await client.GetTable<Conversation>().Where(c => c.MyId == userId).ToListAsync();
  return list.ToArray();
}
public async Task<Message[]> GetMessages(string conversationId)
{
  var list = await client.GetTable<Message>().Where(m => m.ConversationId == conversationId).ToListAsync();
  return list.ToArray();
}
public async Task<Message> SendMessage(Message message)
{
  await client.GetTable<Message>().InsertAsync(message);
  return message;
}

This completes our implementation of IWebService. If you run the application at this point, it will function exactly as before with the exception that the app is actually talking to a real web server. New messages will get persisted in the SQL database, and our custom scripts will handle the custom logic that we need. Feel free to play around with our implementation; you might discover some features of Azure Mobile Services that will work great with your own applications.

At this point, another good exercise would be to set up Azure Mobile Services in our Android application. To do so, you will merely need to add the Azure Mobile Services NuGet package. After that, you should be able to swap out the ServiceContainer.Register call in your Application class and call CurrentPlatform.Init(). Everything will function exactly like on iOS. Isn't cross-platform development great?

Let's begin by navigating to http://developer.apple.com/account and performing the following steps:

This will create an explicit App ID similar to what you can see in the following screenshot, which we can use for sending push notifications:

For push notifications, we have to use a profile with an explicit App ID that is not a development certificate. Now let's set up a provisioning profile:

When finished, you should arrive at a success web page that looks similar to the following screenshot:

Next, we perform the following steps to set up the certificate our server needs:

This will create the certificate that we need to send push notifications to our users from Azure Mobile Services. All that remains is to return to the Azure Management Portal and upload the certificate from the Push tab under Apple Push Notification Settings, as shown in the following screenshot:

This upload concludes the configuration we need from Apple's side.

Next, let's return to our XamChat.iOS project in Xamarin Studio to make the necessary changes on the client side for push notifications. We will need to add a few new classes to our shared code to start with.

Open IWebService.cs and add the following new method:

Task RegisterPush(string userId, string deviceToken);

Next, let's implement this method in FakeWebService.cs (just so it compiles) as follows:

public async Task RegisterPush(string userId, string deviceToken)
{
  await Sleep();
}

Now, let's add a new class named Device.cs in the Core/Azure folder:

public class Device
{
  public string Id { get; set;}
  public string UserId { get; set; }
  public string DeviceToken { get; set; }
}

Finally, we can implement the real method in AzureWebService.cs as follows:

public async Task RegisterPush( string userId, string deviceToken)
{
  await client.GetTable<Device>().InsertAsync(new Device {
      UserId = userId,
      DeviceToken = deviceToken
    });
}

As for ViewModels, we need to add one more new method to LoginViewModel.cs:

public async Task RegisterPush(string deviceToken)
{
  if (settings.User == null)
    throw new Exception("User is null");
  await service.RegisterPush(settings.User.Id, deviceToken);
}

Then, we need to add a small modification to MessageViewModel.cs. Add the following line when creating a new Message object in the SendMessage method:

ToId = Conversation.UserId,

This modification concludes what we need to add to our shared code. We will reuse this new functionality when we add push notifications to Android, so go ahead and take the time to link in the new Device.cs file in your XamChat.Droid project to build your entire solution.

Now, let's add the iOS platform-specific code we need. Add the following methods to your AppDelegate.cs file:

public async override void RegisteredForRemoteNotifications(UIApplication application, NSData deviceToken)
{
  var loginViewModel = ServiceContainer.Resolve<LoginViewModel>();
  try
  {
    string token = deviceToken.Description;
    token = token.Substring(1, token.Length - 2);
    await loginViewModel.RegisterPush(token);
  }
  catch (Exception exc)
  {
    Console.WriteLine("Error registering push: " + exc);
  }
}
public override void FailedToRegisterForRemoteNotifications(UIApplication application, NSError error)
{
  Console.WriteLine("Error registering push: " + error.LocalizedDescription);
}

We implemented a couple of important methods in the preceding code snippet. RegisteredForRemoteNotifications will occur when Apple successfully returns a device token from its servers. It is returned within angle brackets, so we do a little work to trim those off and pass the device token through LoginViewModel to Azure Mobile Services. We also implemented FailedToRegisterForRemoteNotifications just to report any errors that might occur throughout the process.

One last thing to do is to actually make a call to register for remote notifications. Open LoginController.cs and add the following line of code directly after the successful call to log in:

UIApplication.SharedApplication.RegisterForRemoteNotificationTypes( 
UIRemoteNotificationType.Alert | 
UIRemoteNotificationType.Badge | 
UIRemoteNotificationType.Sound);

You can also call the method on startup; however, in our situation, we need a valid user ID to store in the Device table in Azure.

Now let's switch to the Azure Management Portal and make the remaining changes in JavaScript on the server side. Under the Data tab, create a new table named Device with the default settings.

Next, we need to modify the insert script so that the duplicate device tokens are not inserted:

function insert(item, user, request)
{
  var devicesTable = tables.getTable('device');
  devicesTable.where({ userId: item.UserId, deviceToken: item.DeviceToken }).read({ success: function (devices)
    {
      if (devices.length > 0)
      {
        request.respond(200, devices[0]);
      }
      else
      {
        request.execute();
      }
    }
  });
}

Last but not least, we need to modify the insert script for the Message table to send push notifications to the user. The message was sent as follows:

function insert(item, user, request) {
  request.execute();
  var devicesTable = tables.getTable('device');
  devicesTable.where({ userId : item.ToId }).read({
    success: function(devices) {
      devices.forEach(function(device) {
        var text = item.Username + ": " + item.Text;
        push.apns.send(device.DeviceToken, {
          alert: text,
          badge: 1,
          payload: {
            message: text
          }
        });
      });
    }
  });
}

After executing the request, we retrieve a list of devices from the database and send out a push notification for each one. To test push notifications, deploy the application and log in with the secondary user (if using our examples: chucknorris). After logging in, you can just background the app with the home button. Next, log in with the primary user on your iOS simulator and send a message. You should receive a push notification, as shown in the following screenshot:

Let's begin by navigating to http://developer.apple.com/account and performing the following steps:

This will create an explicit App ID similar to what you can see in the following screenshot, which we can use for sending push notifications:

For push notifications, we have to use a profile with an explicit App ID that is not a development certificate. Now let's set up a provisioning profile:

When finished, you should arrive at a success web page that looks similar to the following screenshot:

Next, we perform the following steps to set up the certificate our server needs:

This will create the certificate that we need to send push notifications to our users from Azure Mobile Services. All that remains is to return to the Azure Management Portal and upload the certificate from the Push tab under Apple Push Notification Settings, as shown in the following screenshot:

This upload concludes the configuration we need from Apple's side.

Next, let's return to our XamChat.iOS project in Xamarin Studio to make the necessary changes on the client side for push notifications. We will need to add a few new classes to our shared code to start with.

Open IWebService.cs and add the following new method:

Task RegisterPush(string userId, string deviceToken);

Next, let's implement this method in FakeWebService.cs (just so it compiles) as follows:

public async Task RegisterPush(string userId, string deviceToken)
{
  await Sleep();
}

Now, let's add a new class named Device.cs in the Core/Azure folder:

public class Device
{
  public string Id { get; set;}
  public string UserId { get; set; }
  public string DeviceToken { get; set; }
}

Finally, we can implement the real method in AzureWebService.cs as follows:

public async Task RegisterPush( string userId, string deviceToken)
{
  await client.GetTable<Device>().InsertAsync(new Device {
      UserId = userId,
      DeviceToken = deviceToken
    });
}

As for ViewModels, we need to add one more new method to LoginViewModel.cs:

public async Task RegisterPush(string deviceToken)
{
  if (settings.User == null)
    throw new Exception("User is null");
  await service.RegisterPush(settings.User.Id, deviceToken);
}

Then, we need to add a small modification to MessageViewModel.cs. Add the following line when creating a new Message object in the SendMessage method:

ToId = Conversation.UserId,

This modification concludes what we need to add to our shared code. We will reuse this new functionality when we add push notifications to Android, so go ahead and take the time to link in the new Device.cs file in your XamChat.Droid project to build your entire solution.

Now, let's add the iOS platform-specific code we need. Add the following methods to your AppDelegate.cs file:

public async override void RegisteredForRemoteNotifications(UIApplication application, NSData deviceToken)
{
  var loginViewModel = ServiceContainer.Resolve<LoginViewModel>();
  try
  {
    string token = deviceToken.Description;
    token = token.Substring(1, token.Length - 2);
    await loginViewModel.RegisterPush(token);
  }
  catch (Exception exc)
  {
    Console.WriteLine("Error registering push: " + exc);
  }
}
public override void FailedToRegisterForRemoteNotifications(UIApplication application, NSError error)
{
  Console.WriteLine("Error registering push: " + error.LocalizedDescription);
}

We implemented a couple of important methods in the preceding code snippet. RegisteredForRemoteNotifications will occur when Apple successfully returns a device token from its servers. It is returned within angle brackets, so we do a little work to trim those off and pass the device token through LoginViewModel to Azure Mobile Services. We also implemented FailedToRegisterForRemoteNotifications just to report any errors that might occur throughout the process.

One last thing to do is to actually make a call to register for remote notifications. Open LoginController.cs and add the following line of code directly after the successful call to log in:

UIApplication.SharedApplication.RegisterForRemoteNotificationTypes( 
UIRemoteNotificationType.Alert | 
UIRemoteNotificationType.Badge | 
UIRemoteNotificationType.Sound);

You can also call the method on startup; however, in our situation, we need a valid user ID to store in the Device table in Azure.

Now let's switch to the Azure Management Portal and make the remaining changes in JavaScript on the server side. Under the Data tab, create a new table named Device with the default settings.

Next, we need to modify the insert script so that the duplicate device tokens are not inserted:

function insert(item, user, request)
{
  var devicesTable = tables.getTable('device');
  devicesTable.where({ userId: item.UserId, deviceToken: item.DeviceToken }).read({ success: function (devices)
    {
      if (devices.length > 0)
      {
        request.respond(200, devices[0]);
      }
      else
      {
        request.execute();
      }
    }
  });
}

Last but not least, we need to modify the insert script for the Message table to send push notifications to the user. The message was sent as follows:

function insert(item, user, request) {
  request.execute();
  var devicesTable = tables.getTable('device');
  devicesTable.where({ userId : item.ToId }).read({
    success: function(devices) {
      devices.forEach(function(device) {
        var text = item.Username + ": " + item.Text;
        push.apns.send(device.DeviceToken, {
          alert: text,
          badge: 1,
          payload: {
            message: text
          }
        });
      });
    }
  });
}

After executing the request, we retrieve a list of devices from the database and send out a push notification for each one. To test push notifications, deploy the application and log in with the secondary user (if using our examples: chucknorris). After logging in, you can just background the app with the home button. Next, log in with the primary user on your iOS simulator and send a message. You should receive a push notification, as shown in the following screenshot:

For push notifications, we have to use a profile with an explicit App ID that is not a development certificate. Now let's set up a provisioning profile:

When finished, you should arrive at a success web page that looks similar to the following screenshot:

Next, we perform the following steps to set up the certificate our server needs:

This will create the certificate that we need to send push notifications to our users from Azure Mobile Services. All that remains is to return to the Azure Management Portal and upload the certificate from the Push tab under Apple Push Notification Settings, as shown in the following screenshot:

This upload concludes the configuration we need from Apple's side.

Next, let's return to our XamChat.iOS project in Xamarin Studio to make the necessary changes on the client side for push notifications. We will need to add a few new classes to our shared code to start with.

Open IWebService.cs and add the following new method:

Task RegisterPush(string userId, string deviceToken);

Next, let's implement this method in FakeWebService.cs (just so it compiles) as follows:

public async Task RegisterPush(string userId, string deviceToken)
{
  await Sleep();
}

Now, let's add a new class named Device.cs in the Core/Azure folder:

public class Device
{
  public string Id { get; set;}
  public string UserId { get; set; }
  public string DeviceToken { get; set; }
}

Finally, we can implement the real method in AzureWebService.cs as follows:

public async Task RegisterPush( string userId, string deviceToken)
{
  await client.GetTable<Device>().InsertAsync(new Device {
      UserId = userId,
      DeviceToken = deviceToken
    });
}

As for ViewModels, we need to add one more new method to LoginViewModel.cs:

public async Task RegisterPush(string deviceToken)
{
  if (settings.User == null)
    throw new Exception("User is null");
  await service.RegisterPush(settings.User.Id, deviceToken);
}

Then, we need to add a small modification to MessageViewModel.cs. Add the following line when creating a new Message object in the SendMessage method:

ToId = Conversation.UserId,

This modification concludes what we need to add to our shared code. We will reuse this new functionality when we add push notifications to Android, so go ahead and take the time to link in the new Device.cs file in your XamChat.Droid project to build your entire solution.

Now, let's add the iOS platform-specific code we need. Add the following methods to your AppDelegate.cs file:

public async override void RegisteredForRemoteNotifications(UIApplication application, NSData deviceToken)
{
  var loginViewModel = ServiceContainer.Resolve<LoginViewModel>();
  try
  {
    string token = deviceToken.Description;
    token = token.Substring(1, token.Length - 2);
    await loginViewModel.RegisterPush(token);
  }
  catch (Exception exc)
  {
    Console.WriteLine("Error registering push: " + exc);
  }
}
public override void FailedToRegisterForRemoteNotifications(UIApplication application, NSError error)
{
  Console.WriteLine("Error registering push: " + error.LocalizedDescription);
}

We implemented a couple of important methods in the preceding code snippet. RegisteredForRemoteNotifications will occur when Apple successfully returns a device token from its servers. It is returned within angle brackets, so we do a little work to trim those off and pass the device token through LoginViewModel to Azure Mobile Services. We also implemented FailedToRegisterForRemoteNotifications just to report any errors that might occur throughout the process.

One last thing to do is to actually make a call to register for remote notifications. Open LoginController.cs and add the following line of code directly after the successful call to log in:

UIApplication.SharedApplication.RegisterForRemoteNotificationTypes( 
UIRemoteNotificationType.Alert | 
UIRemoteNotificationType.Badge | 
UIRemoteNotificationType.Sound);

You can also call the method on startup; however, in our situation, we need a valid user ID to store in the Device table in Azure.

Now let's switch to the Azure Management Portal and make the remaining changes in JavaScript on the server side. Under the Data tab, create a new table named Device with the default settings.

Next, we need to modify the insert script so that the duplicate device tokens are not inserted:

function insert(item, user, request)
{
  var devicesTable = tables.getTable('device');
  devicesTable.where({ userId: item.UserId, deviceToken: item.DeviceToken }).read({ success: function (devices)
    {
      if (devices.length > 0)
      {
        request.respond(200, devices[0]);
      }
      else
      {
        request.execute();
      }
    }
  });
}

Last but not least, we need to modify the insert script for the Message table to send push notifications to the user. The message was sent as follows:

function insert(item, user, request) {
  request.execute();
  var devicesTable = tables.getTable('device');
  devicesTable.where({ userId : item.ToId }).read({
    success: function(devices) {
      devices.forEach(function(device) {
        var text = item.Username + ": " + item.Text;
        push.apns.send(device.DeviceToken, {
          alert: text,
          badge: 1,
          payload: {
            message: text
          }
        });
      });
    }
  });
}