Techniques in creating great cross platform apps
29 Sep 2017My NDC Sydney 2017 talk “Techniques in creating great cross platform apps” is now available on Youtube.
My NDC Sydney 2017 talk “Techniques in creating great cross platform apps” is now available on Youtube.
In many of my talks I’ve recommended using a messenger style class. These help to reduce coupling between view models when decomposing from a single “view model per screen” to a tree of view models. This intermediary class is called by a few different names, Messenger in Xamarin.Forms, Mediator in some others and in Caliburn.Micro, Event Aggregator.
If you’ve ever spoken to me personally at a convention or a user group (I’ll be at NDC Sydney if next week, comes say hello) then you may have heard me talk about disliking command objects in MVVM.
One thing you’ll notice if you’re experimenting with the new csproj project structure used in .NET Standard is the difference in Output Path. Typically the default output path for a new full .NET Framework assembly would be bin\$(Configuration)\ resulting in bin\Debug\ and \bin\Release\. In .NET Standard projects by default this output path isn’t defined in the csproj but defaults to much the same except that the Target Framework is also appended to the path. So for example if I created a new project targeting .NET Standard 1.4 like follows:
One feature of the new csproj format (is there an official name for these?) that I wasn’t aware of is the automatic generation of the assembly: attributes we would normally see in AssemblyInfo.cs. This can catch you by surprise with some odd errors, especially when migrating existing projects to the format.