Caliburn.Micro 3.0.1 released
06 May 2016This is a minor bug fix release.
I’m really pleased to finally announce the release of Caliburn.Micro 3.0.0 after a long period of being in beta. The major features of 3.0.0 are Windows 10 / UWP and Xamarin.Forms support. With this release you can use your view models across all major platforms that support C#!
It’s important to note this is a change in the major versions to there may be breaking changes.
The Windows 10 release follows along with the Windows 8.1 and Windows Phone 8.1 releases and combines them into a single library which is great from a maitenance perspective. If we need to start adding features specific to Phone, Xbox or even HoloLens they’ll be done using feature detection via Windows.Foundation.Metadata.ApiInformation
.
It includes conventions for new controls such as SplitView
.
Also included is a sample showing how to set up a SplitView
style app with the Frame
not being the root visual but inside the ShellView
, this sample is available at Hello UWP.
We now use the new open sourced XAML Behaviours package.
This release drops support for Windows 8.0 (different from Windows 8.1).
This release brings support for Xamarin.Forms which in abstraction layer over the different UIs in iOS, Android and Windows Phone Silverlight (Windows 8 / 10 support coming later). What’s really interesting is that it comes with it’s own XAML syntax (not the same as Windows XAML but very similar), this means we can get a closer to standard Caliburn.Micro experience. I was pleasantly surprised by how much I got ported reasonable easy.
There are some limitations of the Xamarin.Forms flavour of of XAML, primarily there is no programmatic access to x:Name
mean we cannot support named based conventions. We can still support attached properties such as cm:Message.Attach
as well as convention based view / view model location.
<ListView ItemsSource="{Binding Features}" HasUnevenRows="True"
cm:Message.Attach="[Event ItemSelected] = [ShowFeature($selectedItem)]">
<ListView.ItemTemplate>
<DataTemplate>
<ViewCell>
<ContentView cm:View.Model="{Binding}" HorizontalOptions="FillAndExpand" VerticalOptions="FillAndExpand"/>
</ViewCell>
</DataTemplate>
</ListView.ItemTemplate>
</ListView>
Also included is the now standard navigation service and navigation helper methods
navigationService.For<ProductViewModel>()
.WithParam(v => v.ProductId, 42)
.Navigate();
A sample of this sort of app is can be found at Hello.Forms in the GitHub repository.
One of the more interesting features here is that Xamarin.Forms runs on top of the existing mobile platform (Xamarin.iOS, Xamarin.Android and Windows Phone Silverlight). This makes it the first version where two different platforms of Caliburn.Micro have to run side by side. We essentially have two instances of ViewModelLocator
, one in Caliburn.Micro.ViewModelLocator
for the current host platform and one at Caliburn.Micro.Xamarin.Forms.ViewModelLocator
if Xamarin.Forms is present.
This release primarily targets Xamarin.Forms, however work has been done to allow your view models to be reused within a Xamarin.iOS or Xamarin.Android applications with no support around binding or conventions.
These features will be added in later feature releases.
A sample of this sort of app is can be found at Hello.Xamarin in the GitHub repository.
One new feature in this release is the CachingFrameAdapter
. This subclass of FrameAdapter
(which implements INavigationService
in WinRT platforms such as Windows 8.1, Windows Phone 8.1 and Windows 10) will cache internally view models and reuse them on the appropriate navigation. This allows scenarios where the built in NavigationCacheMode
doesn’t make sense but still preserve your view model state. A sample of this in action is available at Caliburn.Micro.State.
MainWindow
when it’s disposed.ViewLocator.LocateForModelType
failing to deal with improperly reused views in WinRT.Action.Invoke
.FrameAdapter
.BindingScope
has been cleaned up a lot so will be easier to extend.CanLogin
will be used as a guard for LoginAsync
and will be attached to a control with xName="Login"
.MessageBinder
.Screen.IsActive
, Screen.IsInitialised
and PropertyChangedBase.IsNotifying
are now virtual, we don’t see then behaviour being overriden but a lot apps will need to add their own custom attributes to these properties.Bind.Model
had a feature enabling you to pass a string which used IoC
to find the model. This was deprecated in 2.0.0 and has now been removed.SimpleContainer
now only uses public constructors.UriFor
method has been deprecated in favour of just For
given the lack of uri support on a number of platforms.AssemblySourceCache
which means if your view models do not implement INotifyPropertyChanged
or views subclass from UIElement
then they may not be found by ViewLocator
or ViewModelLocator
. This behaviour can be changed by modifying AssemblySourceCache.ExtractTypes
.Thank you to all who have contributed fixes, reported issues and generally feedback on the extended pre-release versions.
As well a bit thanks to Marker Metro who sponsored a lot of the time it took me to put this 3.0.0 release together.
I’ve just pushed the 3.0.3
release of Caliburn.Micro to nuget.
This release reverts #339, this PR changed the way Caliburn.Micro resolved views from the container.
Previously the framework only called GetAllInstances
to attempt to resolve the view, relying on the fact that most containers wouldn’t error when the view wasn’t resolved.
View Models however were resolved using GetInstance
. #339 made this consistent calling GetInstance
for both.
This was noted as a breaking change and included in 3.0.2
by mistake, it should not have been included as it caused exceptions when the developer was using an IoC container that threw exceptions on dependency resolution expcetions such as Autofac.
Since the release it’s become apparent this has been a problem so 3.0.3
reverts this change.
Apologies to anyone affected by this.s
I’m really pleased to announce the release of Caliburn.Micro 3.0.0-beta1, this is a major milestone in that it adds support for a new platform Universal Windows Platform / Windows 10 as well as for the three new platforms Xamarin.iOS, Xamarin.Android and Xamarin.Forms added in 3.0.0-alpha.
This is an early beta in order to get feedback and testing from the wider community (which is now a lot bigger thanks to this release).
All the release notes from 3.0.0-alpha apply to this release as well.
The Windows 10 release follows along with the Windows 8.1 and Windows Phone 8.1 releases and combines them into a single library which is great from a maitenance perspective. If we need to start adding features specific to Phone, Xbox or even HoloLens they’ll be done using feature detection via Windows.Foundation.Metadata.ApiInformation
.
Also included is a sample showing how to set up a SplitView
style app with the Frame
not being the root visual but inside the ShellView
, this sample is available at Hello UWP.
One new feature in this release is the CachingFrameAdapter
. This subclass of FrameAdapter
(which implements INavigationService
in WinRT platforms such as Windows 8.1, Windows Phone 8.1 and Windows 10) will cache internally view models and reuse them on the appropriate navigation. This allows scenarios where the built in NavigationCacheMode
doesn’t make sense but still preserve your view model state. A sample of this in action is available at Caliburn.Micro.State.
NavigationHelper
which adds the For<TViewModel>
method to allow easier view model navigation.navigationService.For<ProductViewModel>()
.WithParam(v => v.ProductId, 42)
.Navigate();
MainWindow
when it’s disposed. Thanks dvdorle.ViewLocator.LocateForModelType
failing to deal with improperly reused views in WinRT.Action.Invoke
.FrameAdapter
.BindingScope
has been cleaned up a lot so will be easier to extend.All the breaking changes from 3.0.0-alpha apply to this release as well.
Bind.Model
had a feature enabling you to pass a string which used IoC
to find the model. This was deprecated in 2.0.0 and has now been removed.SimpleContainer
now only uses public constructors. Thanks belyansky.UriFor
method has been deprecated in favour of just For
given the lack of uri support on a number of platforms.AssemblySourceCache
which means if your view models do not implement INotifyPropertyChanged
or views subclass from UIElement
then they may not be found by ViewLocator
or ViewModelLocator
. This behaviour can be changed by modifying AssemblySourceCache.ExtractTypes
.For Xamarin.iOS, Xamarin.Android or Windows 10 simply use the normal Nuget package Caliburn.Micro, if you’re wanting to checkout Xamarin.Forms then use the package Caliburn.Micro.Xamarin.Forms.
Previously the code for all these new features was spread across a number of branches, it’s now consolidated in a single 3.0.0 branch.
I’ve had a few people ask me how Caliburn.Micro will work with compiled bindings in Windows 10. Here’s a brief summary based on I know from chatting to some of the engineers at Microsoft.
For those who aren’t familiar with them (most people given it’s a new technology), compiled bindings are a way to have the compiler generate static code for a binding rather than using a dynamic binding that depends on reflection. This increases performance quite a bit and can be used quite heavily, there’s also some features where you can bind an event to a method.
What used to be:
<TextBox Text="{Binding Username, Mode=TwoWay}" />
becomes (where ViewModel is a strongly typed property on the view)
<TextBox Text="{x:Bind ViewModel.Username, Mode=TwoWay}" />
To get a better understanding I’d recommend watching Sam Spencer’s Build talk Data Binding: Boost Your Apps’ Performance Through New Enhancements to XAML Data Binding
Out of the box Caliburn.Micro checks properties for existing bindings before applying conventions. For instance this stops the convention for SomePropertyName
overwriting the existing Binding
.
<TextBox x:Name="SomePropertyName" Text="{Binding Username, Mode=TwoWay}" />
Unfortunately there is no programmatic way to test if a DependencyProperty
has a compiled binding, which means that if you’re mixing convention based binding and compiled bindings there is a chance they could collide.
<TextBox x:Name="SomePropertyName" Text="{x:Bind ViewModel.SomeOtherProperty, Mode=TwoWay}" />
Interestingly because a compiled binding isn’t a real binding then the convention doesn’t overwrite the compiled binding but they exist in parallel which will most likely just confuse everyone.
I’d recommend using one or the other and not mixing them both. You can potentially save yourself some pain and get a performance increase by disabling conventions either on a per view basis
<Page cm:View.ApplyConventions="false">
or on a global basis.
ViewModelBinder.ApplyConventionsByDefault = false;
Of course Windows 10 is still in preview and things could change.