Extract Xamarin Forms Utils Nuget

GaryMcGheeGaryMcGhee AUMember
edited December 2016 in Xamarin.Forms Evolution

Summary

Separate out non-visual infrastructure classes eg. dependency injection, MessagingCentre, Position (from Maps) etc to an easily portable PCL for all platforms, even those not yet supported by Xamarin Forms.

API Changes

No API changes - just a new nuget package eg. "Xamarin.Forms.Utils" and rearranging of code

Intended Use Case

Most Xamarin projects would now begin based on Xamarin Forms, and so it makes sense to adopt the utility and infrastructure classes from Xamarin Forms. Later however, when you decide some code needs to be more widely useable eg. on the server or Mac etc, you can't install Xamarin Forms nuget and so you have to refactor your code to use another portable DIC, messaging framework etc.

ModEdit - Formatting

2
2 votes

Accepted · Last Updated

No implementor has been assigned. Let us know in a comment below if you wish to implement this proposal.

Posts

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    We want this. We welcome any implementation of this.

  • StephaneDelcroixStephaneDelcroix USInsider, Beta ✭✭✭✭

    Note that this is a breaking change

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    Yes it is, however its been a change thats needed to happen and requested internally for quite a while.

  • ChristianSvrdChristianSvrd SEMember ✭✭✭
    edited December 2016

    common types in Xamarin forms like Xamarin.Forms.Color class should be in this library, so they can be used in shared projects in non forms application. quite handy.

  • StephaneDelcroixStephaneDelcroix USInsider, Beta ✭✭✭✭

    Guys, we accepted the idea of this proposal and we found a way to make it non breaking.

    Here's the question we need to discuss:

    • Will the assembly de distributed as a separate nuget, or a different assembly in the same nuget ?
    • What will be the name of the assembly ?
    • Which types do you think should be moved ? Or better: what rule will you use to decide which type goes in which assembly ? If I had to propose one, it would be: anything public that doesn't depend on Bindable[Property|Object]. And to that we would add case by case exceptions...
  • DavidDancyDavidDancy AUMember ✭✭✭✭

    There's quite a lot of internal stuff that's generally useful, especially when you get into custom renderers. This may be a separate proposal but I would appreciate that making its way into this new assembly so it can be used by all of us, not just the XF framework.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    That stuff needs to be migrated into IViewController interfaces.

  • ChrisgozdChrisgozd USMember ✭✭

    I'd be interesting in starting this conversation up and using it as a way to introduce myself to the Xamarin Forms codebase, since it doesn't sound too difficult.

    • Will the assembly be distributed as a separate nuget, or a different assembly in the same nuget ?

    I'm not 100% sure how a different assembly in the same Nuget works, but from above comments, it seems like the original idea was a separate Nuget so that users don't have to download the Xamarin Forms Nuget.

    • What will be the name of the assembly ?

    Xamarin.Forms.Utils?

    • Which types do you think should be moved ? Or better: what rule will you use to decide which type goes in which assembly ? If I had to propose one, it would be: anything public that doesn't depend on Bindable[Property|Object]. And to that we would add case by case exceptions...

    Sounds fair. I think the big types that would be really useful in its own Nuget are listed above. We could start small and get the infrastructure going and then iterate on it with more types in the future.

  • RyanDixonRyanDixon USMember ✭✭✭
    edited August 16

    Here's my twopence in the matter :smile:

    Will the assembly be distributed as a separate nuget, or a different assembly in the same nuget ?

    100% in its own Nuget package with a dependency from Forms. This means you can segment tools into its own forum group and bugzilla to clean it up a little bit, as well as letting us adopt it in other projects (If we so wished)

    What will be the name of the assembly ?

    I think Xamarin.Utils, simply because all of the tools should be transparent to forms and should be able to be adopted in other projects, for example Native Xamarin.

    Which types do you think should be moved ? Or better: what rule will you use to decide which type goes in which assembly ? If I had to propose one, it would be: anything public that doesn't depend on Bindable[Property|Object]. And to that we would add case by case exceptions...

    Pick a popular MVVM Framework as a base and start there? Things like Messaging, Commanding, Binding, etc... Basically everything that Native doesn't completely overhaul in some way such as Navigation

    Let me know if I am talking rubbish!

Sign In or Register to comment.