Onionizing Xamarin Part 1

For those who just want code: https://github.com/SuavePirate/Xamarin.Onion 

A strong and scale-able architecture is important in applications, especially in Mobile Apps. APIs and SDKs are constantly changing, new technology is constantly released, and team sizes are always changing. A solid Onion Architecture can save a development team a lot of time by making it simple to change service implementations, restrict access to certain areas, making logic flow easy to follow, and making testing isolated blocks of code easier.

Some of the important topics this will cover:

  • Separation of Concerns
  • Inversion of Control
  • Dependency Injection
  • Model-View-ViewModel
  • Testability
  • Why all these things are important

Part 1

This first post will talk about the general project structure and high level role of each layer in the solution. Later posts will touch on the individual projects’ code, why things are where they are, using the structure to build out tests, and ways to bend or change the structure to work for you.

Project Structure

For this example we will be talking about Xamarin.Forms, but the same patterns can be applied in the exact same way without it.
Lets just take a look at the high level structure and layers of the solution:

xamarinonionsolution

Domain

This is the lowest level. Projects within Domain should not reference any projects outside of this layer and should also avoid referencing any external libraries.

Domain.Models

These are our base data models. This project shouldn’t reference any other projects, even within Domain.

Domain.Interfaces

These are the definitions for our data access layer. Repositories, Stores, etc. There should be no implementation in this project and should only reference the Model project.

Application

This layer is what defines our Services and Business logic without implementing any of it. Projects in this layer can only reference Model layers of Domain.

Application.Models

These are our application models such as input models, data transfer objects, as well as any helpers for mapping Domain models to these. This project will only reference the Domain.Models to help map them to DTOs or other models. This, however, is also optional. You could opt to handle mapping externally when the models are needed in business logic rather than in the Application layer.

Application.Interfaces

These are the definitions for our business logic layer. Services, Managers, etc. There should be no implementation in this project and it should only reference the Application.Models project

Infrastructure

This is where we implement our data and business logic.

Infrastructure.Data

This is the implementation of our Data access layer. Communicate with 3rd party data providers, local storage, databases, etc. Domain.Interfaces should be implemented here.

Infrastructure.Business

This is the implementation of our Business logic layer. Communicate with the data layer through contracts from the Domain.Interfaces. This project should NOT reference the Data project. Application.Interfaces should be implemented here

Clients

This is where we implement client logic, set up IoC, create ViewModels, and controls. If we are using Xamarin.Forms, this is where the PCL or Shared Library with Xamarin.Forms is. This Layer can reference any of the above layers in order to wire up IoC. If you have multiple Xamarin.Forms projects in one solution, they can both be here.

Clients.Controls

This is where reusable controls within Xamarin.Forms exist. Pretty straightforward.

Platforms

This is the section where the Native Projects live. If you have too many native projects for things like wearables, or the different TV OS’s, then it might make sense to break this section into smaller sections for things like “Apple”, “Google”, “Windows”, or something similar. But for the sake of this demo, we are only working with one project for each platform, so they live together.

This layer should only reference the Client layer and Binding Layer

Droid

This is the Xamarin.Android project. If any native services need to be called from one of the shared layers, the IoC set up can be extended into this project and one of the interfaces could be implemented here and registered.

iOS

This is the Xamarin.iOS project. As stated above, native services can be set up and injected from here as well.

UWP

This is the UWP project. As stated above, native services can be set up and injected from here as well.

Binding

This is where Xamarin Binding projects should be if there is a need for binding to any native libraries. As with the Platforms layer, if there are many different binding projects, this layer could be split into different sections for each OS. This layer should be exclusive and not reference any other layer.

Tests

This is where UI and Unit tests are. This layer can reference any other level in order to test them. This layer can wire up a completely different IoC container, contain mock projects for simulating any other layer, or any other external reference.

 

Continue on:

Onionizing Xamarin Part 2

Xamarin Component Review: ModernHttpClient

These reviews consist of a Pros/Cons, some things developers might need to be aware of before using or during the use of a given component, and a quick code sample that might help people get started.

Links:
Component https://components.xamarin.com/view/modernhttpclient
Nuget – https://www.nuget.org/packages/modernhttpclient/
Github – https://github.com/paulcbetts/ModernHttpClient

Pros:

  • Increase HTTP request speeds.
    This really does make a noticeable difference from using the base
    HttpWebRequest,HttpClient, or WebClient. By using native libraries, it can skip through the Mono runtime bottleneck.
  • Ease of Use.
    Probably the easiest to use component you’re going to find, especially if you are already using HttpClient for your requests. It’s a simple one line drop on each instantiation of HttpClient.
new HttpClient(new NativeMessageHandler());
  • Lightweight.
    A common issue with components is that they increase the overall size of your app. Bigger apps get uninstalled quicker if they don’t do anything important for the user.

Cons:

  • Component conflict.
    Most people won’t run into this issue, and it is most prevalent on Android (at least it is the only place I’ve run into it). The problem arises because of ModernHttpClient’s use of OkHttp from SquareThe way they include this library is different from some others that are dependent on it. You’ll find components such as Picasso or Rounded Image View that also use OkHttp handle it differently, so that at build time, you’ll get a very deceiving error message.

Things to know:

The only things that I have been made aware of so far in my use of ModernHttpClient are a few out of place errors or bugs I’ve run across. Note that these are only found on Android.
1. The component conflict issue (as stated above): You can see an example from a thread here on this type of issue.
2. Android “crash” while debugging. This is an issue apparent with OkHttp that seems to cause crashes while debugging an Android app, while still maintaining the debugger. It is important to note that this does NOT cause this type of crash if the debugger is not attached. Also, after a crash, upon re-opening the app, the debugger remains attached and usable. Something along the lines of

F/libc( 1044): Fatal signal 5 (SIGTRAP), code -6 in tid 1131 (OkHttp Dispatch)

I haven’t tried the pro version, since the free license does exactly what I need, but if anyone has any insight into the pro license, let me know.

Sample:

...
using ModernHttpClient;
...

public class WebRequestUtils
{
    public async Task<string> GetResponseString(url)
    {
// Instantiate HttpClient with ModernHttpClient handler
using(var client = new HttpClient(new NativeMessageHandler())
        {
            var result = await client.GetAsync(url);
            return await result.Content.ReadAsStringAsync();
        }
    }
}

Make sure to keep an eye out for more component reviews as I get around to playing with more in real life situations.

Creating Google Hangouts Style Images in Xamarin iOS

If you haven’t seen it yet, there is this nifty style of thumbnail, icon, image, etc that Google does in their Hangouts app along with some of their others.

hangouts
Google Hangouts

Notice the second image and the last one where they take images from members of your hangout and lay  them together in an orderly fashion based on the number of people you have.

Here is the logic:

  1. One other person – Show the other user’s image
  2. Two other people – Show both other user’s images diagonally from each other
  3. Three other people – Show the three images in a triangle or pyramid shape
  4. Four or more people – Show 4 images in a square

This logic is straightforward with platforms like Windows and Android where you can create the layouts for each one and switch which one is visible based on the number of members. In this case, however, we are going to explore my favorite way to do it in iOS while still using the standard UITableViewCell.

This means rather than using multiple UIImageViews to display each one, we need to create the image in ONE UIImageView. Here is a simple method I use to do something like this:

  private UIImage GetHangoutImage(HangoutVM hangout, UIView container)
        {
            var members = hangout.Members
                    .Where(im => CurrentUser.FullName != im.Name)
                    .Where(im => !string.IsNullOrEmpty(im.ImageUrl))
                    .Take(4)
                    .ToList();
            if (!string.IsNullOrEmpty(hangout.ImageUrl))
            {
                //if the hangout has an image, use that url
                return Extensions.UIImageFromUrl(hangout.ImageUrl);
            }
            else if (members.Count == 0)
            {
                //if no other members, show self
                return Extensions.GetRoundImage(Extensions.UIImageFromUrl(CurrentUser.ImageUrl));
            }
            else if (members.Count == 1)
            {
                //show the one other member's image
                return Extensions.GetRoundImage(Extensions.UIImageFromUrl(members[0].ImageUrl));
            }
            else if (members.Count == 2)
            {
                //if 2 other members, show both their images diagonally
                UIGraphics.BeginImageContext(new CoreGraphics.CGSize(container.Frame.Height, container.Frame.Height));
                UIImage image1;
                UIImage image2;
                UIImage combinedImage;
                image1 = Extensions.GetRoundImage(Extensions.UIImageFromUrl(members[0].ImageUrl));
                image2 = Extensions.GetRoundImage(Extensions.UIImageFromUrl(members[1].ImageUrl));

                image1.Draw(new RectangleF(22, 0, 22, 22));
                image2.Draw(new RectangleF(0, 22, 22, 22));
                combinedImage = UIGraphics.GetImageFromCurrentImageContext();
                UIGraphics.EndImageContext();
                return combinedImage;
            }
            else if (members.Count == 3)
            {
                //if 3 other members, show all three images in a triangle
                UIGraphics.BeginImageContext(new CoreGraphics.CGSize(container.Frame.Height, container.Frame.Height));

                UIImage image1;
                UIImage image2;
                UIImage image3;
                UIImage combinedImage;
                image1 = Extensions.GetRoundImage(Extensions.UIImageFromUrl(members[0].ImageUrl));
                image2 = Extensions.GetRoundImage(Extensions.UIImageFromUrl(members[1].ImageUrl));
                image3 = Extensions.GetRoundImage(Extensions.UIImageFromUrl(members[2].ImageUrl));
                image1.Draw(new RectangleF(0, 0, 22, 22));
                image2.Draw(new RectangleF(22, 0, 22, 22));
                image3.Draw(new RectangleF(11, 22, 22, 22));
                combinedImage = UIGraphics.GetImageFromCurrentImageContext();

                UIGraphics.EndImageContext();
                return combinedImage;
            }
            else
            {
                //if 4 or more show first 4 in square
                UIGraphics.BeginImageContext(new CoreGraphics.CGSize(container.Frame.Height, container.Frame.Height));

                UIImage image1;
                UIImage image2;
                UIImage image3;
                UIImage image4;
                UIImage combinedImage;
                image1 = Extensions.GetRoundImage(Extensions.UIImageFromUrl(members[0].ImageUrl));
                image2 = Extensions.GetRoundImage(Extensions.UIImageFromUrl(members[1].ImageUrl));
                image3 = Extensions.GetRoundImage(Extensions.UIImageFromUrl(members[2].ImageUrl));
                image4 = Extensions.GetRoundImage(Extensions.UIImageFromUrl(members[3].ImageUrl));

                image1.Draw(new RectangleF(0, 0, 22, 22));
                image2.Draw(new RectangleF(22, 0, 22, 22));
                image3.Draw(new RectangleF(0, 22, 22, 22));
                image4.Draw(new RectangleF(22, 22, 22, 22));

                combinedImage = UIGraphics.GetImageFromCurrentImageContext();
                UIGraphics.EndImageContext();
                return combinedImage;
            }
        }

In this situation I’m using some hard coded values for the sake of readability. The height of my UITableViewCell is 44 (hence seeing the 22’s everywhere for splitting it in half).

Also, I use a static extensions class to get images from a url and also to create round images. I talked about these in previous blog posts here:

  1. Creating Round Images in Xamarin.iOS
  2. Creating a UIImage from a URL

So now that we have our means of getting the image, we can create it in our GetCell override method in our TableViewSource class we are using to populate our UITableView:

  public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
        {
            var cellIdentifier = _hangouts[indexPath.Row].ID.ToString();
            var currentHangout = _hangouts[indexPath.Row];

            UITableViewCell cell = tableView.DequeueReusableCell(cellIdentifier);

            //// if there are no cells to reuse, create a new one
            if (cell == null)
                cell = new InstanceTableViewCell(currentInstance);
            cell = new UITableViewCell(UITableViewCellStyle.Subtitle, cellIdentifier);
            cell.TextLabel.Text = currentHangout.DisplayName;
            cell.DetailTextLabel.Text = string.Format("{0}{1}", currentHangout.LastMessageMember, currentHangout.LastMessage);
            cell.ImageView.Image = GetHangoutImage(currentHangout, cell.ImageView); // Get the Hangout Style Image
            return cell;
        }

That’s really as far as it goes! Now using that, you’ll get something looking like this:
instancesscreenshotioscropped

The lack of spacing may be misleading, but you’ll notice the first cell has 2 other members, the second has one, the third has 4+, the 4th has 3, etc.

Feel free to comment if you have any questions or want more advice on how to make something like this more appealing!

Xamarin iOS Creating Round Table Cell Images

One more freebie to be referenced in a later post. Here is how I create rounded images to be used in iOS table cells:

 public static UIImage GetRoundImage(UIImage im)
        {
            if (im == null)
                return null;
            UIGraphics.BeginImageContextWithOptions(new SizeF((float)im.Size.Width / 2, (float)im.Size.Height / 2), false, 0);
            UIBezierPath.FromRoundedRect(
                new RectangleF(0, 0, (float)im.Size.Width / 2, (float)im.Size.Height / 2),
                im.Size.Width / 2
            ).AddClip();
            im.Draw(new RectangleF(0, 0, (float)im.Size.Width / 2, (float)im.Size.Height / 2));
            UIImage im1 = UIGraphics.GetImageFromCurrentImageContext();
            UIGraphics.EndImageContext();
            return im1;
        }

Creating a UIImage with a URL in Xamarin iOS

Here is another freebie that I’m going to reference in a later blog post. This is the way I create UIImages from web URLs:

public static UIImage UIImageFromUrl(string uri)
{
    using (var url = new NSUrl(uri))
    using (var data = NSData.FromUrl(url))
        return UIImage.LoadFromData(data);
}

Creating a Circular Image in Xamarin.Android

If you’re working with mobile applications, sometimes something as simple as creating a circular image can be a bit more time consuming than it should be. Here is the snippet I use to create Circular Images in Xamarin.Android to follow up with my post about Creating Circular Images in XAML.

CircleDrawable:


public class CircleDrawable : Drawable
 {

     Bitmap bmp;
     BitmapShader bmpShader;
     Paint paint;
     RectF oval;

    public CircleDrawable(Bitmap bmp)
     {
         this.bmp = bmp;
         this.bmpShader = new BitmapShader (bmp, Shader.TileMode.Clamp, Shader.TileMode.Clamp);
         this.paint = new Paint () { AntiAlias = true };
         this.paint.SetShader (bmpShader);
         this.oval = new RectF ();
     }

    public override void Draw (Canvas canvas)
     {
         canvas.DrawOval (oval, paint);
     }

    protected override void OnBoundsChange (Rect bounds)
     {
         base.OnBoundsChange (bounds);
         oval.Set (0, 0, bounds.Width (), bounds.Height ());
     }

    public override int IntrinsicWidth
    {
         get
         {
             return bmp.Width;
         }
     }

    public override int IntrinsicHeight {
         get {
             return bmp.Height;
         }
     }

     public override void SetAlpha (int alpha)
     {

     }

    public override int Opacity {
         get {
             return (int)Format.Opaque;
         }
     }

    public override void SetColorFilter (ColorFilter cf)
    {

    }
 }

And here is an example of how to use it:

var bitmap = new Bitmap(); //do something else here to create your bitmap
var circleImage = new CircleDrawable(bitmap);

Organized Architecture for a Cross-Platform SignalR Application

SignalR is a great tool for keeping not only your web applications synced in real-time, but with it’s easy to use APIs for clients, it is perfect for use in your mobile applications.

I have some previous posts that are going to help in designing the of an architecture for a cross-platform implementation with SignalR. Take a look at these:

In this scenario, we are going to focus on two major layers of separation within our applications, although you can always add more layers of abstraction if that is your style or preference. Our two layers are the Portable Class Library and Native Client Libraries. This example is going to be using one PCL with all of our shared code, and then individual projects for Windows Phone 8.1, Windows 8.1, Xamarin.iOS, and Xamarin.Android.

The Portable Class Library

In this architecture, we want to focus on sharing as much code as possible. This implies that the only code that should not be in our PCL is code that includes the UI (Note we are not using Xamarin.Forms), updates the UI, or accesses the device’s native features (cameras, location, etc). This would include things such as ViewModels if you’re using the MVVM pattern (this example is using MVVM Light), Models, Web Request Logic, and even our SignalR Managers.
With that in mind, here are some nuget packages to consider for your PCL:

So let’s get started with a simple BaseHubManager to manage our connections. I’m going to follow a basic Inheritance pattern for these managers so that we can share as much of our SignalR code in our Base Manager as possible.

BaseHubManager:

  public class BaseHubManager
    {
        public HubConnection Connection{ get; set; }
        public IHubProxy Proxy { get; set; }

        // The empty constructor should only be used for a basic connection with no specific Hub
        public BaseHubManager()
        {
            Connection= new HubConnection(Constants.BaseUrl);
        }

        // Connect to specific Hub
        public BaseHubManager(string hubProxy)
        {
            Connection= new HubConnection(Constants.BaseUrl);
            Connection.Headers.Add(&quot;Authorization&quot;, string.Format(&quot;Bearer {0}&quot;, App.CurrentUser.TokenInfo.AccessToken)); //add access token to authorize
            Proxy = Connection.CreateHubProxy(hubProxy);
        }

        public async Task Start()
        {
            await _connection.Start(new LongPollingTransport());
            //Add additional shared Start logic
        }

        public void Stop()
        {
             _connection.Stop();
             //Add additional shared Stop logic
        }

        public virtual async void Connect()
        {
            await this.Start();
            //Add additional shared Connect logic
        }
    }

Now that we have a solid base, we can easily spin up individual Hub managers to connect to specific Hubs. Below is an example of a HubManager that would connect to the “ChatHub” on your server.

ChatHubManager:

 public class ChatHubManager : BaseHubManager
    {
        public ObservableCollection&lt;string&gt; Messages{ get; set; }

        public ChatHubManager ()
            : base(&quot;ChatHub&quot;)
        {
            this.Connect();
        }
        // Send new message to ChatHub
        public async Task&lt;string&gt; Create(string newMessage)
        {
            //establish connection
            await this.Start();

            var message= await Proxy.Invoke&lt;string&gt;(&quot;Create&quot;, newMessage);

            return message;
        }

        // Get all messages from ChatHub
        public async Task&lt;IEnumerable&lt;string&gt;&gt; Get()
        {
            //establish connection
            await this.Start();

            var messages = await Proxy.Invoke&lt;IEnumerable&lt;string&gt;&gt;(&quot;Get&quot;));

            Messages = new ObservableCollection&lt;string&gt;(messages);
            return messages;

        }

    }

Expanding new HubManagers like this one make it very easy to call server-side methods from our client by simply creating an instance of our Manager and calling our Invoking methods:

var manager = new ChatManager();
var messages = await manager.Get();

Now what about the other side of SignalR – Client methods? There are some things to consider. Most importantly, will your client end points update anything in the UI? This also includes updating ViewModel properties that will cause updates in the UI.
The problem is that the client end point listeners don’t stem from any sort of UI action the way that calling a server method might. Thus, it can’t run on the UI thread by itself and you would likely run into some sort of Threading Exception.

If you don’t need to update the UI at any point from your client listener, consider adding your listeners in your manager with something like this:

public ChatHubManager ()
    : base(&quot;ChatHub&quot;)
{
        this.Connect();
        Proxy.On&lt;string&gt;(&quot;newMessage&quot;, async data =&gt;
        {
            //Do something that is NOT on the UI thread
        }
}

One thing that SignalR does wonderfully is give you the ability to add these listeners from anywhere. That includes from your individual client projects that reference your PCL. So, let’s look at how to add these kind of requests to our client projects so we can update our UIs.

The Individual Client Projects

Let’s use a Windows Phone 8.1 project as our example, although the same logic can be applied to any type of project. So we need to add our client listener like we did above, but we also need it to make changes to our UI, which will require tapping into our UI thread. For this case, let’s add a ChatSignalingManager to our Windows Phone project that contains a reference to our ChatHubManager in our PCL above:

 public class ChatSignalingManager
    {
        private ChatHubManager _hubManager;
        private CoreDispatcher _dispatcher;
        public ChatSignalingManager (CoreDispatcher dispatcher)
        {
            _hubManager= new ChatHubManager ();
            _dispatcher = dispatcher;
            InitializeChatEndpoints();
        }

       //Add client end points for the ChatHubManager
        private void InitializeChatEndpoints()
        {
            var newMessage = _hubManager.Proxy.On&lt;string&gt;(&quot;newMessage&quot;, async data =&gt;
            {
                await _dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, () =&gt;
                    {
                        // process your UI changes here
                    });
            });

           // Add additional end points for the ChatHub here
        }

    }

Notice the biggest difference in how we handle our end point in our client project versus our PCL. The Dispatcher. In this case, we can pass Windows CoreDispatcher to our constructor, and by calling _dispatcher.RunAsync we are able to execute our process on our UI thread to successfully run code against our UI.

Here is an example of constructing the ChatSignalingManager from the MainPage of a Windows Phone app:

public sealed partial class MainPage : Page
{

    private ChatSignalingManager _signalingManager;
    public MainPage()
    {
        this.InitializeComponent();

        this.NavigationCacheMode = NavigationCacheMode.Required;
        _signalingManager = new ChatSignalingManager (Dispatcher);

    }

}

Hopefully that is enough code to get you started, but feel free to ask more questions in the comments. Just remember to share as much code as possible in your PCL and use your Client Projects to handle updates to your UI and also to utilize SignalR’s flexibility and versatility.