20 Aug 2014
We’ve just pushed 2.0.1 to nuget, it’s a small release mostly with bug fixes missing from 2.0.0.
What’s New?
- Resolved compilation errors in the Caliburn.Micro.Start package due to the breaking changes in 2.0.0.
PropertyChangedBase supports DataContract serialization on appropriate platforms.- Windows Phone 8.1 now exposes an
INavigationService.BackPressed to better let apps handle and potentially cancel hardware back button events.
- Added a convention for Windows Phone 8.1
Pivot.
- Resolved a bug where
OnViewReady argument was null.
ActionMessage is more resilient to null values.- Resolved BindingScope.FindNamedDescendants crashed on DependencyObjects
- Added
View.IsInDesignMode.
Thanks to all who contributed fixes, logged bugs etc.
21 Jul 2014
Application State and it’s management is an incredibly important part of building rich interactive applications. It’s also a broad topic that covers a lot of different scenarios and can mean different things to different people. The next major release of Caliburn.Micro will include a number of things to help address this in WinRT (Windows 8 and Windows Phone 8.1) and I want to start framing the conversation.
I’ll start with defining the different sorts of state, outline the solutions on existing platforms such as Windows Phone Silverlight, then talks about the differences in WinRT.
What is state?
First I want to break state up into three broad buckets. There is some overlap between these buckets thanks to bindings but they’re generally discrete. These buckets are:
- View State
- View Model State
- Frame State
View State
View state are the states of the controls that make up the view, this would be things such as scroll position, selected items in list boxes, partially entered text etc.
View Model State
This is often what developers think of as application state, this is the current state of the view model and includes child view models loaded from external services. There’s an overlap with View State here with what’s being bound between view and view model. When this occurs I include it in View Model state.
Frame State
Almost all Windows Phone and most Windows applications are view first in that the root window content is a Frame that is wrapped in a navigation service. What I refer to as Frame state is the back and forward stacks of that Frame control.
When should we consider state?
I believe there’s two major times we need to consider the state of the application. They are:
- Frame navigation
- Application Suspension / Resumption
Frame Navigation
Users expect that when that when they navigate back to a view within an application it will be in the same state it was when they navigated away. Often this can be a subtle thing but will frustrate the user ALOT if they’re navigating back and forth between views frequently and it’s state is not retained. View model state will also be something the user will expect to be retained including things such as partially entered text fields and data loaded from web services.
Application / Suspension
In the more mobile xaml frameworks such as Windows Phone Silverlight and WinRT there are systems in place that in order to conserve resources an suspended application in the background may be terminated. When the user relaunches the application there will be an expectation that it resumes to the state they left the application.
How does this come together?
Obviously there is a relationship between the different sorts of state and when we should consider them, almost all of it is driven by user expectation. This can be different for individual applications (banking software can for security reasons have a different idea about resuming).
Below is my general thoughts on user expectations and how they relate to the two above lists.
| |
Frame Navigation |
Suspension / Resumption |
| View State |
Views from back and forward stacks should retain state. |
Views are generally not expected to retain state. |
| View Model State |
View models corresponding to the back and forward stacks should retain state. |
The view model for the “current” view would retain some of its state. |
| Frame State |
N/A |
The back and forward stacks of the Frame are retained. |
Where to from here?
This post has been a lot of definitions to probably highlight what’s usually obvious but defining the terms for later discussion helps quite a bit.
In the next post I’ll outline how Caliburn.Micro deals with most of these problems on Windows Phone Silverlight.
28 May 2014
Announcing a new version of Caliburn.Micro with support for all Xaml platforms, PCL and Universal app support, an improved web site and docs and new leadership for the future.
The Release
I’m elated to announce that today we are officially releasing Caliburn.Micro 2.0. A lot of work has gone into this release, including some major re-design to enable PCL and Universal App support. We’ve taken this opportunity to fix up the core of the framework so that it’s better designed to function in a more friction-free way across all Xaml platforms. Naturally, we’ve also fixed a ton of bugs and added some new features along the way. You can get it now on Nuget. We hope you ejoy the new version and that Caliburn.Micro continues to make your Xaml app development less like work and more like play :)
There are some breaking changes that comes with such a major redesign. Most of these have been documented at Migrating to 2.0.0
The Web Site
Correspondent with this release, we’re launching a new web site: caliburnmicro.com. The new site will function as a source of news, documentation and releases. We hope that giving the project a more official home and providing the docs in a cleaner, easy-to-read format will help you and future developers pick up and learn the library faster.
The Leadership
Thanks for this incredible work go entirely to Nigel Sampson and Thomas Ibel. I had nothing to do with this release except to answer an occasional question. That brings me to an important point. I’m not working with Xaml much anymore and haven’t personally been using Caliburn.Micro for development for a while now. So, I feel it’s time to pass the torch. As part of this release, we’re officially announcing that Nigel Sampson will be taking over the role of coordinating the Caliburn.Micro project. He’s worked with and helped develop Caliburn.Micro for a long time and he’s committed to its future and to open source. He’s a great man for the job and I’m happy to pass along my work to someone who shares the same vision for Xaml development. I’ll be staying on as an advisor, of course, but I expect things will get along quite well with Nigel in charge and Thomas there to keep refining the core.
01 May 2014
Caliburn.Micro finally has it’s own website! Moving from Codeplex to GitHub leaves a bit of a gap in terms of good place to host documentation and provide announcements.
We now have a central place for announcements regarding the project rather than coming from individual team members blogs. So it should be easier to keep up with changes / new features etc.
As with most open source projects the documentation always needs a lot of work and especially with the move to PCL’s and the new XAML platforms available to us. While we already have a pile of docs we need to bring them back up to scratch and make them easier for new users.
From a technical level the website is built with Jekyll and hosted with GitHub pages. What’s cool about this is that there’s a publicly available repository for the site so if you find any typos or issues you can either create an issue on the repo or even send us a pull request.