Architecture of Shiny

Shiny is built around a few core concepts - Services, Delegates, and Observables. These three concepts are the foundation of Shiny and are used throughout the library. Understanding these concepts will help you understand how to use Shiny effectively. Using Shiny for a single function is generally not recommended as it has a fair bit of library underneath it to facilitate core functionality like storage, logging, platform lifecycle hooks, and utilities. This is why Shiny is not “sold” as a set of plugins.

Below are some of the common questions we get asked about decisions made in Shiny’s architecture.

Why does Shiny use delegates instead of .NET based events?

For several reasons… the first ensures that all necessary services are hooked when they need to be. The second, events were often hooked at the wrong time (after they would be fired). The last, by ensuring a standard pattern, all services are ready can also be consumed by the delegate at the right time. Delegates also apply a nice clean piece of code to unit test.

Why does Shiny have it’s own platform lifecycles - why not just use what’s built into MAUI?

Because Shiny is not dependent on MAUI. Shiny is built to move into the ever changing .NET client world. Whether we go to MAUI, classic Xamarin, Uno Platform, Blazor, etc - we want to ensure a path is open.

Why does Shiny uses Reactive Extensions?

Observables are far more powerful and a little bit better at not leaking memory. Even the people C# team don’t like the way events were built for the C# language.