Xamarin.Forms development domains

As we have seen so far in this book, application development using the Xamarin.Forms framework is executed on multiple domains. While the Xamarin.Forms layer creates a shared development domain that will be used to target native platforms, the target platforms can still be utilized for platform-specific implementation.

If we were to separate a Xamarin.Forms application into four quadrants by development strategy and application domain category, it will look like this:

In this setup, quadrant I (that is, the shared business logic) would represent the core logic implementation of the application. This domain will contain the view models, domain data descriptions, and service client implementation. Most importantly, the abstractions for platform-specific APIs (that is, the interfaces that will be implemented on the native platform) should be created in this domain so that each other domain, as well as the view models within this domain, can make use of them.

Quadrant II and III represent the UI customizations that we will need to implement to create the desired UX for the application. Up until now, we have been creating our visual trees using only quadrant II. Simple data-driven applications and line of business (LOB) applications can solely utilize this domain. However, if we were to create a consumer-facing application, complying with the branded UX requirements and creating an intuitive UI should be our main goals. In this case, we can resort to creating customizations for Xamarin.Forms views with quadrant III.

In this paradigm, quadrant I only connects with quadrant II using data binding and converter implementations. Quadrant II is responsible for propagating the delivered data to quadrant III.

In quadrant II, the customization options for developers are mostly related to using the extensibility options provided by the out-of-the-box views offered by the Xamarin.Forms framework. Compositions of these views and behavioral modifications can provide highly maintainable cross-platform source code. By using styling options, visual states, and data-driven templates, the UX can meet these requirements.

Moving from the shared to the native platform (that is, crossing from quadrant II to quadrant III), the developers are blessed with platform specifics, as well as Xamarin.Forms effects. Using these extensibility points, we, as developers, can modify the behavior of native controls, as well as modify the rendered native UI, creating a bridge between the Xamarin.Forms view abstractions and the target native controls. A combination of these extensibility features with Xamarin.Forms behaviors can improve the maintainability of the application.

Quadrant-III-specific development is comprised of custom renderers and native controls. Native controls can be created and combined under Xamarin.Forms compositions, thereby decreasing the complexity of the Xamarin.Forms XAML trees (that is, the composite controls).

Finally, quadrant IV represents the platform-specific APIs, such as geolocation, the usage of peripherals, such as Bluetooth or NFC, or SaaS integrations/SDKs that require native implementation.