This blog post is about an example Xamarin Forms project I wrote to show using Prism, Unity, and Ocean Validation in several scenarios.
I decided to make this a video blog post and have six videos for you.
You learn the following:
- Using the sample Xamarin Forms app and understanding the line of business scenarios it covers.
- Using Prism and Unity in a real-world Xamarin Forms App
- Dependency injection in a real-world Xamarin Forms App
- Abstracting Static services and Static Device information behind interfaces to promote testing and maintainable code
- Using Prism NavigationService and PageDialogService
- Async Await contrasted with the Promise pattern in a Xamarin Forms App
- Ocean validation framework with Xamarin Forms
- Using IDataErrorInfo to surface validation errors for properties or the entire object. (Yes, IDataErrorInfo!) This also works for UWP. These two platform’s binding pipeline lack data validation. No worries, it’s very easy to do now.
- Using Ocean validation to validate an object in multiple states. Multiple validation states imply that the object is going through a workflow, where an object can be valid for a certain state, but not valid for other states. This is a common scenario in complex business applications like insurance claims or when an object is completed over several Xamarin Forms pages.
- At the end of November 2016, the Xamarin Forms ListView view began to have some problems that cost me over a day. In the last video, I explain the issues and what I did to get around them. I also wrote up bugs and communicated with Microsoft about these issues.
Introduction to Ocean for Xamarin Forms
Prism and Dependency Injection in Ocean for Xamarin Forms
Async Await and Promise Pattern in Ocean for Xamarin Forms
Introduction to Ocean Validation Framework for Xamarin Forms
Ocean Multi-Object State Validation for Xamarin Forms
Xamarin Forms ListView Troubles (as of 1 Dec 2016)
I hope these videos have helped with your understanding of Prism, Unity, and Ocean in Xamarin Forms.
Have a great day,
Just a grain of sand on the world’s beaches
I remember when I first started using MVVM I found myself putting not only view logic, but small pieces of business logic in my viewmodels. It was testable and reduced the number of classes related to the front end. These viewmodels were not blobs, but they did take on more responsibilities than a single-responsibility class would have.
Then in 2013 I changed my application design so that any business logic was relegated to a business logic class that was injected into the viewmodel. My viewmodels were now leaner and followed the single-responsibility principal much closer.
Motivation for Thin View Models
Motivation for thin viewmodels is strong and simple: cross-platform.
Given the advent of Xamarin.Forms and its capability to author applications for UWP, IOS, Android, and OS X (Xamarin only), as an application architect I would strongly recommend that applications put their business logic in Portable Class Libraries (PCL) and keep their viewmodels thin. If you do this, you can also share that same business logic with desktop platforms like WPF or Windows Forms.
If you have platform specific logic you can abstract it behind one or more interfaces and then inject it into the proper layer.
I’m excited about Xamarin.Forms and the potential it has for cross-platform development using .NET programming languages.
While Xamarin.Forms does not currently work with OS X, the PCL libraries you author will. You’ll need to Xamarin Studio to author the OS X UI.
Using this architecture also gives you the advantage of unit and integration testing on a single UI agnostic shared code base.
In the end its about giving yourself, your team, your company the option and capability to meet market driven cross-platform requirements without a rewrite.
Exciting times to be an architect and developer.
Hope this helps someone and have a great day
Just a grain of sand on the worlds beaches.