Forms Unity Bootstrapper

[Mike-E-angelo]

Ideally, my vote would be to make the Forms Unity Bootstrapper as much like the WPF version as possible, if possible. For instance, the Logger should be part of the initialization process, in my view.

Also, there is a lot of room for improvement with the guidance provided with Xamarin's initialization. For instance, they do not define their Application object in Xaml, which I think is unoptimal. Here is an example of this in action:
https://github.com/DragonSpark/Framework/blob/Multiversal/DragonSpark.Testing.Client/ApplicationDefinition.xaml

You can also see that I define the MainPage defined in the Xaml there, so there is no need to create it during the setup (bootstrapper) phase.

Also consider that I define my bootstrapper in Xaml as well. Here is the WPF version of what I am working on (I am currently building a Xamarin.Forms WPF renderer as a proof-of-concept project):
https://github.com/DragonSpark/Framework/blob/Multiversal/DragonSpark.Testing.Client.Application/Setup.xaml

And you can see that this is assigned here:
https://github.com/DragonSpark/Framework/blob/Multiversal/DragonSpark.Testing.Client.Application/Application.xaml#L16

The reason I bring this up is that the Bootstrapper has typically had protected or non-public properties, and hinders it from being defined in Xaml. This would be something to be mindful of for design considerations.

[brianlagunas]

The Forms bootstrapper will be as close as possible to the WPF version, but it will be different. Prism for Forms will be completely different guidance than for WPF. There are a ton of differences in the frameworks and XAML implementations that impact this guidance.

Logging will be part of the Forms initialization, it just hasn't been implemented just yet.

When creating guidance for application development for a particular platform, it is important that we follow that platforms standard practices as much as possible. Changing the way you initialize a Forms app impedes on the adoption of the guidance, complicates getting started with the guidance, and opens yourself up for potential issues when changes are made to the target framework.

While some devs may enjoy configuring application startup in XML, this is not something the Prism has ever done, and will not start doing. We don't plan on changing the core concepts of Prism for our Forms support. We must keep all concepts as similar, consistent, and familiar as possible. There are also a number of limitations that you will run into by trying to configure everything in XML. Then, we will wind up writing a ton of code trying to work around them. For example, using a NavigationPage as your initial page. Also, I'm a lazy developer, and writing application configuration in XML is not as efficient, or type safe, as creating a bootstrapper class, overriding 3 methods, and calling Run().

[Mike-E-angelo]

OK... great to hear about the direction. This is where a forum will do well before it makes its way as an issue. :)

However, I do have to challenge you here in that Prism does currently use Xaml definitions (which is way better than XML -- this might be the source of my confusion) as a way to define its Module Catalogs. In fact, that is where I got the idea of configuring its other components as Xaml in the first place. :)

(I would also like to stress that we are talking about Xaml here, not XML. These are two completely different development experiences, especially where tooling and design support are concerned.)

Along those lines, it would be nice to know what you mean by Xaml not being type-safe. As when you compile a Xaml file it checks for type-safety as part of its compilation process (if you meant XML, then disregard this). Additionally, it would be nice to know what you mean by limitations by configuring elements in Xaml. We define presentation elements all the time in Xaml and there aren't any problems there... so what makes the Bootstrapper (or any other class) any different? I guess my ask here is not that I want you to overhaul Prism and make everything Xaml-based, but just to be aware that your users are following your already-prescribed guidance and are using it in other interesting ways around your product. This is good to be aware of from a product-owner perspective.

If you mean XML then what you say makes perfect sense. I would not suggest using that at all. The .NET XML configuration system is terrible (not to mention, dated) and I have sat in P&P workshops where the team has said as much where they completely tore it apart as a terrible API. I personally haven't used it since Xaml broke out into the System.Xaml assembly. .NET XML Configuration is an ugly beast that deserves its due death (and actually should be removed from Prism, IMO). :P

Finally, to be fair here, the Bootstrapper is the only Prism element that I directly define as Xaml, as it is an initialization object much like the System.Windows.Application and Xamarin.Forms.Application. So, fundamentally, it would be nice to see going forward as a consideration that this class would be made more Xaml-friendly as an initialization object. That's really all that I am saying here.

(This is all really a moot point as I have already done this in my extension of the Bootstrapper, but I am just getting it out there as a concerned and passionate user of your product. :) )

[brianlagunas]

I was specifically talking about XML, but not too much changes with XAML though. Not so much from the XAML property intellisense, but rather the values for the properties. I realize Prism uses XAML for module catalog support. My specific statement was around Prism never supporting application setup via an XAML/XML file.

Keep in mind, in your implementation, you derived from Application which gives you access to the application object. Prism's bootstrapper doesn't have this ability. I guess you could define the bootstrapper as a resource in the App.xaml, override the OnStartup, and then get the resource using FindResource, and call the Run method on it. But then, what Is the benefit? Just a coding style?

As far as limitations, the thing that stands out to me immediately is the inability to use your container to resolve your shell (maybe not a big deal). You also have to be able to register types in your container prior to them being used in the bootstrapper. Also in the case of Forms, if using a NavigationPage, there would be no way to navigate to a particular view while passing dynamic parameters. There may also extensibility issues that come into play. There may be more, but I won't know until I really get into it.

This is something that would require some big changes to the bootstrapper for sure. New public properties, and behavior changes such as showing the shell automatically (which might be a good thing to do anyways).

I will keep this on the backlog for consideration. As with all feature requests, there is also the aspect of how many devs will actually use this. If only 5 % use this, then it's probably not worth us spending our limited dev time on this feature. But, if 50% of devs use it, then maybe it would be time well spent.

I need to look into some type of user voice account to help track these ideas, and allow the Prism community to vote on them. GitHub isn't the best medium for capturing this info.

[Mike-E-angelo]

The primary benefit/advantage of using Xaml/Configuration is that it is structured and constrained input into an application/system, and therefore is cheaper to build an maintain over the lifetime of an application. That is, there is no custom (or "loose") logic that adds to the overall complexity (and consequent management/maintenance) of an application. From a business/project management perspective, finding the required talent and resources required to maintain Xaml (after deployment) is easier (and cheaper) than finding the resources required for code. Furthermore -- and this is debatable now that C# is so ubiquitous but this also happens to be one of the tenants/principles of XML -- Xaml is language-agnostic so anyone familiar with .NET will be able to work with it in a limited-friction capacity (in theory, of course :)). By using Xaml/configuration, you significantly reduce the barrier to finding resources (from an organizational perspective) that can possibly work on and maintain a product.

After cost, the biggest benefit is that it is designer-friendly. It's surprising, but what a lot of developers do not understand (or know) is that any object defined in Xaml can be edited in a designer-friendly way right now in our current IDE without any extensions or installations.

If you recall, the P&P group invested heavily a configuration designer for EntLib. It was really an incredible feature of the product, IMO. However, it was also very involved and burdensome to extend and tie into... but the concept I thought was, again, incredible (and in hindsight necessary due to how terrible .NET configuration was, but I digress).

Thankfully, through the use of Visual Studio, we get all of the designer goodness that the EntLib configuration manager was driving at for free right now with our current IDE. It is untapped and a little unknown, however, but it is nonetheless a great feature available that we can utilize without any extra installation required. As an example, here is the Setup (Bootstrapper) right now in my IDE:

Granted, this is not really all that impressive right now (see: more Xaml-friendly properties for Bootstrapper :) ), but if additional properties were added and configured, it would "light up" (to use the expression of the ASP.NET vNext team when they talk about editor experiences) considerably -- just like presentation elements you might be familiar with in Blend. The point here is that the design infrastructure is already in place, ready to go, and doesn't require an install or application from EntLib (or other party) to take advantage of immediately.

As for your question about how objects are initialized and to instantiate a shell: now we get into why Xaml is easily the most powerful serialization mechanism in the marketplace today. It features something no other markup language possesses and is the top reason why I love it so much (and is the reason why I am into Xamarin.Forms and avoid WinRT like the plague that it is): MarkupExtensions. :) Indeed, in the Setup object that I define, I create a Shell by using a LocateExtension which ties into ServiceLocation... like magic! <3

In regards to registering types for the bootstrapper, early in my initialization process I utilize the IContainerConfigurationCommand, which is an interface that is actually based off a (for whatever reason) now defunct interface that Unity 1.0 (or 2.0?) used to have that would simply execute a command on a container. This is where all the magic happens in my Setup (Bootstrapper object). All of my commands are defined in Xaml and you can see them here as an example. (For instance, I use convention-based registration which is done by the ApplyRegistrationsCommand, but I also have a UnityContianerConfiguration that can also manually register types and instances as well.)

Finally, I unfortunately do not follow you in regards to your NavigationPage concern. I can assure you that whatever it is, it can be achieved via a mix of Xaml and MarkupExtensions, however. :) I have done some pretty incredible things with markup extensions and again they are the reason why I am so lit-up on Xaml and consider it such a powerful language.

To wrap up here, I am all for a vote. I am even more appreciative of you just hearing me out. :) I also hope that my reasoning above resonates with you (and others). Essentially, this approach is motivated by cost (configuration is cheaper than code over the course of an application) and designer-friendliness (which also makes applications cheaper/faster to develop/maintain). The other consideration for me is that MSFT has worked so hard to create such a powerful object definition/serialization language but everyone still views and considers it just for presentation (even though it now has its own assembly, is standalone, and has all sorts of designer capabilities in VS). This is a result of poor internal guidance and messaging on their part. That's where P&P and projects like yours should pick up the slack, IMO! :)

[brianlagunas]

Well I disagree with your statement regarding configuration being cheaper, especially in the case of the Bootstrapper. Look at everything you have to do in order to even support this, including custom interfaces and classes, and markup extensions to do something I can do with two words in C#. What I see is an over complicated and over architected implementation. The Bootstrapper shouldn't be so complicated that you need a designer to create it. Configuration has its place in an application, but I don't think this is one of them. If the configuration item is essentially a data structure only the developer understands, it’s not configuration. The point of configuration is letting you concisely and declaratively express your intentions in a higher level of abstraction. If you have configuration that requires just as much detail, or more, as the code would, you don’t really have configuration at all, you’ve got imperative code, just in a very inconvenient language for writing imperative code, the worst of both worlds. Adding in a layer of configuration adds complexity. It's not cheaper by any means.

[Mike-E-angelo]

LOL... and just what are those two C# words, Brian? ;)

[brianlagunas]

Container.Resolve

[Mike-E-angelo]

I am not sure that compiles, dude. ;)

It sounds like I am doing a poor job of explaining my position, so I will just leave this here for now. I appreciate the discussion and look forward to your progress and success. 👍

[brianlagunas]

I could be completely misunderstanding what you are trying to accomplish. Maybe you should implement it on your fork and submit a pull request. Then I will see exactly what you mean :0)

[JohnTasler]

As much as I like XAML for many things, even outside of UI, I have to agree with Brian here.

System.Xaml is great, but the only platform it fully works on is .NET 4.x. These days, XAML implementations are too varied. Many still don't have {x:Type} and {x:Static} markup extensions. For a bootstrapper, C# seems simple and sufficient.

[Mike-E-angelo]

Haha yes @JohnTasler code is "simple" to us coders during design and development, but after an application has been deployed nearly every organization (read: the profitable ones) that I have been in has valued configuration over code when it comes to maintenance and management of the application post-development/design. The reason for such is that the organizational resources that are required to manage configuration/xaml/xml are cheaper than those that have to manage/maintain C#/VB.NET. That is my experience and subsequently the driving motivation here for my point of view.

Configuration/Xaml works perfectly and very well for WPF (which is where I derive my "over complicated and over architected implementation" and concepts from, btw 😛) and my assertion here is that the same power and principles that are in it can be applied to other areas of the application (and even other applications altogether, such as on the server-side).

(Again, Prism started this with their ModuleCatalog in 4.1... I am just keeping the party going here in a BIG way!)

I point again to what EntLib did with their configuration manager. Pretty awesome stuff, and it was appreciated by the management in a few of my previous engagements due the cost efficiency it provided by reducing code. Xaml is much more powerful, expressive, and designer-friendly than the XML that EntLib dealt with, so really the opportunity (and potential) that we're dealing with here to provide the same cost savings is even greater (IMO, of course). There is work to be done around this, obviously, but that is really my bottom line here.

Along such lines, please do keep in mind that intend on building my own consultancy based on Xamarin.Forms (and Prism is a part of this now, thankfully), so I have a vested interest in building applications in the most cost-efficient way possible... not just for during development process but through the entire lifetime of the application. :)

I hope that helps explain my position a little more (even though I said I would leave this alone, LOL! Sorry, I guess I couldn't resist.)

Finally @brianlagunas ... Thank you for the offer. I would love to send you a PR some time from my fork but it already includes a few changes that you have already said no to. ;) Maybe we can work around them, though. I need to get more experience (and better) with Git!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.