DeutschEnglish

Sep 23

Reference base class event handlers in Windows Phone Silverlight

The short story:

In a Silverlight XAML page it’s not possible to reference an event handler that is defined in the page’s base class.

The long story:

Imagine you have a Windows Phone Silverlight project with (at least) one page that does not directly inherit from PhoneApplicationPage but from a custom base class that is defined within the project. This page base class contains event handler methods. When you register any event in the page’s XAML code and reference one of these event handlers defined in the base class, this will compile without problems. However, when running the App, the page can’t be loaded as a XamlParseException occurs while executing the InitializeComponent() method within the page’s constructor.

The workaround:

The reason for this behavior is a bug in Silverlight’s XAML parser (which, by the way, has been known for years but was never fixed). This is actually good news, because it means you can simply attach the event handler to the according event in codebehind instead of within XAML code, and everything will work fine!

Permanent link to this article: http://www.mobilemotion.eu/?p=1282&lang=en

Sep 10

[MVVMbasics] New version 2.0 features #5: Event Binding

Notice

All blog posts with a title that starts with [MVVMbasics] are related to the MVVMbasics framework. If you are only interested in my regular blog posts and not in MVVMbasics, ignore these. To list all articles covering MVVMbasics, go to http://mvvmbasics.mobilemotion.eu/documentation!

Binding events directly to commands

This is a widely discussed topic among developers: Most XAML controls allow Command Binding, which means that a custom command (defined in the Viewmodel) is invoked as soon as a specific event is raised on that control. For example, a command binding to a button’s Command property will be invoked when the button’s Click or Tap event fires. However, in some cases you’d want to react to different events – an usually end up with event handler methods in the View’s code-behind that do nothing more than call one of the Viewmodel’s commands. Code that works but smells: violating the MVVM pattern, being complex to read and maintain,and resulting in redundant code parts in cross-platform projects.

Unfortunately, in spite of the improvements brought by .NET 4.5, there is still no real platform-independent solution for this problem. (By the way, I’m planning a separate series of blog articles on this dilemma, for all those who are interested in the technical backgrounds!)

If you’re developing only for WPF (.NET 4.5) or the Silverlight 5 platform, you might be interested in taking a look at my EventBinding Library. For all other use-cases (especially App projects targeting multiple platforms!), I decided to integrate a somewhat unconventional workaround in version 2.0 of the MVVMbasics framework. This approach does not solve all of the problems concerning event handling in an MVVM context, but it should work for most cases that might occur in real-world App projects.

The declaration of the MVVMbasics Event Binding mechanism consists of two parts that are typically done directly in XAML code:

  • First, for all events that shall be redirected to a command their XAML event handler is specified as EventToCommand (in most cases, this will be exactly one event, but you might as well specify the same handler for as many events as you like).
  • Second, the command that shall be invoked on each of these events is specified by binding it to the attached property Event.Command.

In addition, the namespace MVVMbasics.Helpers (in which the attached property Event.Command is defined) needs to be declared within the View’s header. This is defined withing the MVVMbasicsWPF (for WPF applications), or MVVMbasicsRT (for WinRT projects, e.g. Universal Apps), or MVVMbasicsPS (for Windows Phone Silverlight Apps) assembly, respectively.

All this is shown in the following two examples:

  1. Binding a single event to a command:

    <views:BaseView
            xmlns:mvvm="clr-namespace:MVVMbasics.Helpers;assembly=MVVMbasicsWPF"
            ...other properties and namespace declarations follow here... >
    	<ListBox SelectionChanged="EventToCommand" mvvm:Event.Command="{Binding SelectionChangedCommand}">
    		... other properties and ListBox contents ...
    	</ListBox>
    </views:BaseView>
    
  2. Binding multiple events to the same command:

    <views:BaseView
            xmlns:mvvm="clr-namespace:MVVMbasics.Helpers;assembly=MVVMbasicsWPF"
            ...other properties and namespace declarations follow here... >
    	<CustomControl DoubleClick="EventToCommand" DoubleTapped="EventToCommand"
    		mvvm:Event.Command="{Binding ActivatedCommand}" />
    </views:BaseView>
    

This solution has two major drawbacks:

  • It allows binding only one custom command (in addition to the built-in Command Binding functionality of most controls) to an arbitrary number of control events. As in the above example, it is possible to bind both the DoubleClick and the DoubleTapped (and as many other events as are desired) to the ActivatedCommand. However, it would not be possible to bind each of these events to a separate command.
  • On the Windows Phone Silverlight (not Universal Apps!) platform, there exists a bug that prevents setting inherited event handlers in XAML code. As a workaround, we can declare the assign handlers in the View’s constructor:
    public MyPage()
    {
    	InitializeComponent();
    
    	MyListBox.SelectionChanged += EventToCommand;
    	// add the EventToCommand handler also to all other events that shall be redirected to a command
    }
    

    Unfortunately, this again includes code-behind coding, but limited to a few simple statements in the constructor (in comparison to declaring full event handlers that need to access the View’s Viewmodel, when using the conventional approach of handling control events). The command binding itself using Event.Command="{Binding CommandName}" can be done within XAML as on the other platforms.

As mentioned before, this is a workaround that cannot provide all the functionalities that would be desirable for an event-to-command binding mechanism, but it’s a start that should fit most applications. Let’s hope that a real platform-independent solution is introduced in future versions of .NET!

Permanent link to this article: http://www.mobilemotion.eu/?p=1266&lang=en

Sep 09

[MVVMbasics] New version 2.0 features #4: Navigation events and parameters

Notice

All blog posts with a title that starts with [MVVMbasics] are related to the MVVMbasics framework. If you are only interested in my regular blog posts and not in MVVMbasics, ignore these. To list all articles covering MVVMbasics, go to http://mvvmbasics.mobilemotion.eu/documentation!

Navigation principles

Let’s start with a short summary of the navigation service as we know it from previous version. Based on this, the following two sections Passing navigation parameters and Passing navigation parameters will present those functions that are new in release 2.0.

The MVVMbasics framework’s navigation service provides standardized methods for navigating between views, which is especially useful in cross-platform development since the same Viewmodels can be used for all platforms. To make use of the navigation service, a reference to the NavigatorService class is necessary within each Viewmodel:

var _navigator = ServiceLocator.Retrieve<INavigatorService>();

The NavigateTo method can be used to navigate to a new View. In addition, it excepts an arbitrary number or parameters to be passed to the new view’s Viewmodel:

_navigator.NavigateTo<NextViewmodel>(
	new Parameter("param1", "content),
	new Parameter("param2", 3.1415),
	new Parameter("param3", DateTime.Now));

To navigate back to a previously shown View, the NavigateBack method can be used. To pass parameters in this case, the SetBackParameters methods needs to be called anytime before the NavigateBack method:

_navigator.SetBackParameters(
	new Parameter("param1", "content),
	new Parameter("param2", 3.1415),
	new Parameter("param3", DateTime.Now));
_navigator.NavigateBack();

In both cases, the OnNavigatedFrom event is raised on the current Viewmodel (the one that invokes the navigation), and the OnNavigatedTo event is raised on the newly loaded Viewmodel (the one that belongs to the navigation operation’s target View). In some cases (to be exact, in those cases that allow the navigation operation to be cancelled), also the CancelNavigatingFrom event is raised on the current Viewmodel. When overriding the CancelNavigatingFrom method, you can decide whether to cancel the navigation operation or not by returning either true or false.

When overriding the OnNavigatedTo method on the target Viewmodel of a navigation operation, the navigation parameters that were passed using one of the methods discussed above can be retrieved:

public override void OnNavigatedTo(ParameterList uriParameters, ParameterList parameters, ViewState viewState)
{
	string param1 = parameters.GetString("param1");
	
	if (parameters.Contains("param2"))
		double param2 = parameters.GetDouble("param2");
	
    DateTime param3;
    parameters.TryGetDateTime("param3", out param3);
}

In addition, in all of the OnNavigatedTo, CancelNavigatingFrom, and OnNavigatedFrom methods, the view state that will be reached after the navigation operation is finished can be retrieved:

public override void OnNavigatedTo(ParameterList uriParameters, ParameterList parameters, ViewState viewState)
{
	switch (viewState)
	{
		case ViewState.Activated:
			// View is loaded for the first time
			break;
		case ViewState.Reactivated:
			// View has been inactive and is reactivated
			break;
		case ViewState.Shown:
			// The whole App is reactivated from the background (on Phone and Tablet platforms) or reloaded from
			// minimized mode (on the Desktop platform)
			break;
		case ViewState.Awakened:
			// The whole App returns from tombstoning (occurs only on Phone and Tablet platforms)
			break;
	}
}
 
public override void OnNavigatedFrom(ParameterList uriParameters, ParameterList parameters, ViewState viewState)
{
	switch (viewState)
	{
		case ViewState.Deactivated:
			// Another View is loaded, the current one is not unloaded but remains in the background
			break;
		case ViewState.Closed:
			// View is completely unloaded and removed from the backstack
			break;
		case ViewState.Hidden:
			// The whole App is moved to the background (e.g., because another App becomes active on Phone and
			// Tablet platforms, or because the App is minimized on the Desktop platform)
			break;
		case ViewState.Hibernated:
			// The whole App is hibernated (occurs only on Phone and Tablet platforms)
			break;
	}
}

Passing navigation parameters

The NavigateTo and SetBackParameters methods are quite flexible as they allow to pass any number of navigation parameters to the next Viewmodel. In practice, however, in most of the cases you’ll need to pass exactly one parameter. With MVVMbacics, there is a new, shorter way of specifying a single navigation parameter:

_navigator.NavigateTo<NextViewmodel>("paramName", paramContent);

The same applies to back parameters that are passed back to a previously shown View:

_navigator.SetBackParameters("paramName", paramContent);
_navigator.NavigateBack();

Additional view states while handling navigation events

In MVVMbasics 2.0, the handling of view states has been harmonized: The Hibernated view state is used only when the App really is suspended by the operating system, while the newly introduced Hidden view state is used whenever the App is moved to the background (e.g., because another App becomes active) but remains in memory. In WPF desktop applications, the Hidden view state is used to indicate that the application is minimized to the taskbar by the user. Accordingly, a new view state Shown is introduced when reactivating the App from Hidden state.

For details about navigation event and view states, refer to the article Handling navigation events that has been updated to reflect the changes in the 2.0 version!

One final blog post is missing in this series: New version 2.0 features #5: Event Binding presents a solution to the problem of redundant event handler methods in code-behind classes.

Permanent link to this article: http://www.mobilemotion.eu/?p=1258&lang=en

Sep 08

[MVVMbasics] New version 2.0 features #3: Intelligent Command Binding

Notice

All blog posts with a title that starts with [MVVMbasics] are related to the MVVMbasics framework. If you are only interested in my regular blog posts and not in MVVMbasics, ignore these. To list all articles covering MVVMbasics, go to http://mvvmbasics.mobilemotion.eu/documentation!

Intelligent Command Binding

Commands must be defined as public properties of the Viewmodel or Model they are exeuted in, and they must be instantiated which is usually done in the Viewmodel’s or Model’s constructor. This isn’t new, but what’s new is the way how they are instantiated, since there exist a few new features and shortcuts.

Command instantiation:

Let’s assume SearchCommand is a custom command defined in some Viewmodel. It is defined as a Viewmodel’s property using the BaseCommand helper class:

public BaseCommand SearchCommand { get; set; }

In the Viewmodel’s constructor, this command is instantiated and paired with either a private method or a delegate. Depending on whether the command expects to retrieve a CommandParameter from the View or not, one of the following two constructors of BaseCommand can be used:

private void Search()
{
    // ... business logic goes here
}

public MyViewmodel()
{
    SearchCommand = new BaseCommand(Search);
}
private void Search(object parameter)
{
    // ... do something with the parameter
}

public MyViewmodel()
{
    SearchCommand = new BaseCommand(Search);
}

(Note that we could have also used an inline lambda expression instead of the Search method.)

Still nothing new so far, but now it comes: As alternative to calling the BaseCommand‘s constructor in order to instantiate the command, we can call the CreateCommand method (which is new in version 2.0, and is defined within the BaseModel class, meaning it is available in all Models and Viewmodels inheriting from the framework’s generic BaseModel and BaseViewmodel classes):

SearchCommand = CreateCommand(Search);

This has no advantage when dealing with such a simple command, but it has as soon as a CanExecute condition shall be specified for the command, which will be shown in the next section. I just wanted to show that both ways are valid. (By the way: Internally, the CreateCommand method just calls the BaseCommand constructor and returns its result, nothing fancy here.)

Specifying a CanExecute condition:

This is the interesting part. As we know, each command can contain a condition that is evaluated at runtime to decide whether the command may be executed or not. If this condition resolves to false, the visual control the command is binding to is disabled. I generally refer to this condition as CanExecute condition.

In most cases, this condition depends on one or multiple of the Viewmodel’s bindable properties. For example, the CanExecute condition of our SearchCommand could look like:

IsUserLoggedIn && !String.IsNullOrEmpty(SearchText)

In this example, the command may only be invoked if a boolean property indicating whether the current user is logged in is true, and if a property of type string that represents the entered search criteria contains some text.

In previous versions of the MVVMbasics framework, it was necessary to specify for each property all the commands that depend on it (technically, this was done by listing all commands that depend on a particular property as part of the property’s Set method). As stated in the previous blog post, this is not necessary any more. We simply specify the CanExecute condition as additional parameter while instantiating the command, and the MVVMbasics framework takes care of the rest:

SearchCommand = CreateCommand(Search,
    () => IsUserLoggedIn && !String.IsNullOrEmpty(SearchText));

The MVVMbasics framework will analyze the expression that represents the CanExecute condition, store each bindable property it finds and force the condition to be re-evaluated each time one of these properties is changed. Analyzing the expression works fine in practice and should find all properties involved automatically, except for two special cases:

  • In case a method call is specified somewhere within the expression, the framework will only take into account this method’s parameters (if bindable properties are among them), but not analyze the body of this method! For example, if the condition contains an expression like

    () => String.IsNullOrEmpty(SearchText)
    

    the SearchText property will be registered as property the command depends on (and the command’s CanExecute condition will be re-evaluated when the SearchText property changes). This works, because the SearchText property is passed to the String.IsNullOrEmpty method as parameter.

    On the other hand, if the command is instantiated with a condition structured as follows:

    SearchCommand = CreateCommand(Search,
    	() => CheckIfEnabled());
    
    private bool CheckIfEnabled()
    {
    	return String.IsNullOrEmpty(SearchText);
    }
    

    then no properties will be recognized as dependent properties, because the SearchText property is only referenced within the CheckIfEnabled method’s body, which is not parsed and analyzed in detail. In this case, you need to manually specify the properties the command depends on. See the next section on how to do this!

  • In some cases, you want to omit parsing the CanExecute expression, e.g. for performance reason when using rather complex conditions. To do so, you can also manually specify all properties the command depends on – see the next section on how to do this. If properties are specified manually, the expression will never be automatically analyzed!

Manually specifying properties the command’s CanExecute condition depends on:

If the properties a command’s CanExecute condition depends on shall be specified manually (instead of letting the condition be analyzed automatically), they can be passed to the CreateCommand method as additional parameters. The method allows an arbitrary number of optional parameters that all represent these dependent properties, as shown in the following example:

SearchCommand = CreateCommand(Search,
    () => IsUserLoggedIn && !String.IsNullOrEmpty(SearchText),
	() => IsUserLoggedIn, () => SearchText);

In this case, the CanExecute condition is not parsed by the BaseCommand‘s initializer, and the properties IsUserLoggedIn and SearchText are registered as properties the command depends on (and the command’s CanExecute condition will be re-evaluated when one of those two properties changes).

It should be noted, however, that the two approaches of specifying dependent properties (automatical parsing of the CanExecute expression vs. manually specifying them) can not be combined. If at least one property is passed to the CreateCommand method as third parameter, the expression will not be analyzed.

Alternatives to the CreateCommand method:

For the sake of completeness, I’d like to add that it’s still possible to invoke the BaseCommand‘s constructor directly, instead of using the CreateCommand method:

SearchCommand = new BaseCommand(Search,
    () => IsUserLoggedIn && !String.IsNullOrEmpty(SearchText),
	this);
SearchCommand = CreateCommand(Search,
    () => IsUserLoggedIn && !String.IsNullOrEmpty(SearchText),
	this,
	() => IsUserLoggedIn, () => SearchText);

These two examples show the only drawback of this approach: A reference to the command’s host (the Model or Viewmodel it resides in) must be passed to the constructor as third parameter. When using the CreateCommand method, this can be omitted.

Migrating to MVVMbasics 2.0 from an earlier version:

Compared to earlier versions of the framework, which expected the CanExecute condition to be passed as Func<bool> or Predicate<object> to the BaseCommand‘s constructor, the new 2.0 version of the BaseCommand‘s constructor expects a LINQ Expression (Expression<Func<bool>> or Expression<Func<object, bool>>). This is necessary to allow the BaseCommand class to analyze the given expression and detect dependent properties automatically.

When migrating existing projects to MVVMbasics 2.0, you can keep most of the existing command initializers, because they will be automatically passed as LINQ Expression. The only exception to this rule is a case where a separately defined method is passed as CanExecute condition, as in the following example:

SearchCommand = new BaseCommand(Search, IsEnabled);

private bool IsEnabled()
{
	// ...
}

These need to be rewritten to an Expression by switching to the following syntax:

SearchCommand = new BaseCommand(Search, () => IsEnabled());

private bool IsEnabled()
{
	// ...
}

A note about backwards compatibility:

The “old” versions of the BaseCommand constructor are still available, but are flagged as deprecated and will be removed from the framework in a future version. When creating a new project, never use deprecated functions but only the new ones. When migrating an existing project to MVVMbasics 2.0, you can still use the old constructor calls, but remember to plan an upgrade task to replace these with the new CreateCommand at a later point in time. It’s not that complex, and it guarantees that you’re project is future-proof. (By the way, Visual Studio will not let you forget about that since it shows a compiler warning for each deprecated function that is still in use…)

The next blog post will present the new, shorter way of passing parameters between Views, and two new view states that can be useful when handling navigation events – read all about it in New version 2.0 features part #4!

Permanent link to this article: http://www.mobilemotion.eu/?p=1236&lang=en

Sep 07

[MVVMbasics] New version 2.0 features #2: Simplified Data Binding with more flexibility

Notice

All blog posts with a title that starts with [MVVMbasics] are related to the MVVMbasics framework. If you are only interested in my regular blog posts and not in MVVMbasics, ignore these. To list all articles covering MVVMbasics, go to http://mvvmbasics.mobilemotion.eu/documentation!

Data Binding: Simpler and more flexible

As we know, all Viewmodel properties that shall allow Data Binding need to be implemented in a special way in order to raise the PropertyChanged event when their value is updated. MVVMbasics introduced the Set method that significantly reduces those properties’ Setters. That’s what we already know from version 1.9, but let’s take a look at how this Set method has changed in the 2.0 version:

Simple property Setter:

In its simplest form, the Set method does the following:

  1. check if the property’s new value differs from the old one
  2. if yes, replace the old value with the new one
  3. and fire the PropertyChanged event

In all the 1.x versions, this Set method had the following signature:

Set(ref _propertyName, value, () => PropertyName);

Thanks to .NET 4.5 and a few adaptations in the MVVMbasics framework, we can now reduce this to:

Set(ref _propertyName, value);

Which is already a bit shorter and easier to write! An example of a full bindable property specification could look like the following:

private string _someText;
public string SomeText
{
	get { return _someText; }
	set { Set(ref _someText, value); }
}

Additional methods within the Setter:

It has always been possible to add an additional task to the Set method: An additional method that is called automatically after the property’s value has been updated, but only if the old and new values were different. This is quite useful to, for example, fire the PropertyChanged event for additional properties that depend on the current one.

This is still possible, but – of course – using the shorter Set method as presented above:

private string _someText;
public string SomeText
{
	get { return _someText; }
	set { Set(ref _someText, value, AdditionalMethod); }
}

private void AdditionalMethod()
{
	// do whatever is appropriate after the SomeText property has been updated
}

Version 2.0 allows you to specify an additional method that is called before the property’s value is updated (but only if the old and new values are different) – this one returns the type bool to express if the Set method should continue its work with updating the property and firing the PropertyChanged event, or not! This additional method (it’s called before in the Set method’s signature can be specified as the first parameter:

private string _someText;
public string SomeText
{
	get { return _someText; }
	set { Set(CheckIfUpdate, ref _someText, value); }
}

private bool CheckIfUpdate()
{
	// return either TRUE to continue with updating the property and
	// firing the <code>PropertyChanged</code> event, or FALSE to abort
}

And, of course it’s possible to specify both the before and the after method:

private string _someText;
public string SomeText
{
	get { return _someText; }
	set { Set(CheckIfUpdate, ref _someText, value, AdditionalMethod); }
}

private bool CheckIfUpdate()
{
	// return either TRUE to continue with updating the property and
	// firing the <code>PropertyChanged</code> event, or FALSE to abort
}

private void AdditionalMethod()
{
	// do whatever is appropriate after the SomeText property has been updated
}

Dependent Commands:

In all previous versions, it has been possible to specify all Commands that have a CanExecute condition which depends on the current property’s value, as part of the Set method. Due to a really cool new feature of MVVMbasics 2.0, this is not necessary any more – Commands can do this on their own (as you will learn in Part #3 of this series of articles)! This means: The Set method stays as clean as it appears in the above examples, no more parameters to add.

A note about backwards compatibility:

The “old” versions of the Set method are still available, but are flagged as deprecated and will be removed from the framework in a future version. When creating a new project, never use deprecated functions but only the new ones. When migrating an existing project to MVVMbasics 2.0, you can still use the old methods, but remember to plan an upgrade task to replace these at a later point in time. It’s not that complex, and it guarantees that you’re project is future-proof. (By the way, Visual Studio will not let you forget about that since it shows a compiler warning for each deprecated function that is still in use…)

Alright, let’s move on and learn how much easier is has become to define custom commands in Part #3: Intelligent Command Binding!

Permanent link to this article: http://www.mobilemotion.eu/?p=1221&lang=en

Sep 06

[MVVMbasics] New version 2.0 features #1: Package structure & supported platforms

Notice

All blog posts with a title that starts with [MVVMbasics] are related to the MVVMbasics framework. If you are only interested in my regular blog posts and not in MVVMbasics, ignore these. To list all articles covering MVVMbasics, go to http://mvvmbasics.mobilemotion.eu/documentation!

Simplified package structure

With version 2.0, finally the complicated package structure consisting of the “core” package MVVMbasics and the platform-specific Extensions packages belongs to the past.

Now, there is only one package: To add the MVVMbasics framework to any project of any type, simply search NuGet for “MVVM basics” and download and install the MVVMbasics package – that’s it! NuGet will automatically add those packages that are required by each project.

Of course, you can still decide whether you want to keep all parts of your application in one project, or create different platform-specific projects containing the Views and one Portable Class Library containing data models and Viewmodels in order to create a cross-platform solution. In both cases, you only need to add the MVVMbasics package to each project. In case of a platform-specific project type, NuGet will add both a reference to MVVMbasics and to one of the platform-dependent extension libraries called MVVMbasicsWPF, MVVMbasicsRT, or MVVMbasicsPS – as you can see in the project’s References section in Solution Explorer. In case of a Portable Class Library, Nuget will add only the core MVVMbasics reference. However, no need to worry about that – since everything happens automatically there’s no need to even think about these internals.

Supported platforms

MVVMbasics can be included in projects targeting:

  • WinRT (Windows Store 8.1, Windows Phone 8.1, and Universal Apps)
  • WPF (.NET 4.5)
  • Windows Phone 8.0 (Phone Silverlight)

Unfortunately, WPF for .NET 4.0 and Windows Phone 7 are not supported any more. If you still need support for one of the two platforms, go for version 1.9, as described in Which version to use?

When adding MVVMbasics to a Universal App project, you should in any case install the MVVMbasics package into the Windows, Windows Phone, and the Shared project to ensure that all functions and features of MVVMbasics are available in both apps. If you want to keep the project extendable, I’d suggest that you add a Portable Class Library to the solution, create all Models and Viewmodels in there, and reference this PCL project from within the Shared project. This way, you can add support for additional platforms in the future with limited effort. In this case, the MVVMbasics package needs also to be installed into the PCL project.

Ready to dive into MVVMbasics‘s new coding features? Then continue with Part #2: Simplified Data Binding with more flexibility!

Permanent link to this article: http://www.mobilemotion.eu/?p=1219&lang=en

Sep 05

[MVVMbasics] Which version to use?

Notice

All blog posts with a title that starts with [MVVMbasics] are related to the MVVMbasics framework. If you are only interested in my regular blog posts and not in MVVMbasics, ignore these. To list all articles covering MVVMbasics, go to http://mvvmbasics.mobilemotion.eu/documentation!

With the publication of MVVMbasics 2.0, actually two different versions of the MVVMbasics framework have been released at the same time: 1.9.0 and 2.0.0. Let me explain the reason for this, and which version to use for which application:

To use state-of-the-art technology and to provide new features, MVVMbasics 2.0 is based entirely on .NET 4.5. On the one hand, this enables the support of Windows 8.1 and Windows Phone 8.1 Universal Apps (finally!). On the other hand, this means that WPF applications using .NET 4.0 and Phone apps built for Windows Phone 7 are unfortunately not supported any more.

If you’re developing WPF applications on .NET 4.5, Store Apps for Windows 8.1 or Windows Phone 8.1, Phone Applications for Windows Phone 8.0, or event a cross-platform combination of all, this won’t bother you. Just install the latest version of MVVMbasics (when downloaded from NuGet, this will be the 2.0.0 version automatically) or upgrade existing projects to the 2.0 version, and take advantage of the various new features!

If you cannot upgrade to MVVMbasics 2.0, e.g. because one of your projects still requires .NET 4.0 or Windows Phone 7, you should use the MVVMbasics 1.9 version. This version includes the same functions and features known from the 1.4 version, enhanced only by minor bug fixes, and will be the last update to the 1.x release. To install the 1.9 version, you need to explicitly specify the version number 1.9.0 when installing the package(s) from NuGet:

PM> Install-Package MVVMbasics -Version 1.9.0
PM> Install-Package MVVMbasicsTabletExtensions -Version 1.9.0
PM> Install-Package MVVMbasicsPhoneExtensions -Version 1.9.0
PM> Install-Package MVVMbasicsDesktopExtensions -Version 1.9.0
PM> Install-Package MvvmBasicsFor.NET4.0 -Version 1.9.0

However, when your project’s requirements change in the future and .NET 4.0 and/or the Phone 7 platform need not be targeted any more, remember to take the time and upgrade to the 2.0 release – it has a lot of new functions and features to offer, as listed in detail in New version 2.0 features!

Permanent link to this article: http://www.mobilemotion.eu/?p=1217&lang=en

Sep 04

MVVMbasics 2.0 finally supports Universal Apps

Version 2.0 of the MVVMbasics framework is out now! This major update adds support for Universal App development (for both the Windows 8.1 and Windows Phone 8.1 platforms), as well as a bunch of new functionalities and convenience methods that make following the MVVM pattern a lot easier!                            

Permanent link to this article: http://mvvmbasics.mobilemotion.eu

Sep 03

Retrieving the Windows OS version #4

This is a very short extension to the series of blog posts discussing how to work with Windows OS versions.

After all the struggles and complicated workaround to get the OS version number retrieval to work for Windows Store Apps, here comes the good news: On the Windows Phone platform, everything is a lot easier.

Windows Phone provides the

Environment.OSVersion.Version

property, that offers access to (among others) major and minor version number as well as the build number. And the best is: This applies to the Windows Phone 7.1, 8.0 and 8.1 versions!

Permanent link to this article: http://www.mobilemotion.eu/?p=1200&lang=en

Sep 02

Simple EventToCommand binding using the MVVM EventBinding library

MVVM EventBinding allows the binding of events (directly in a window’s or page’s XAML code) to commands specified in the Viewmodel. This helps to follow the MVVM pattern and replace event handlers defined in a window’s code-behind by Viewmodel commands.                                        

Permanent link to this article: http://www.mobilemotion.eu/?page_id=1203

Older posts «