Twitter Feed Popout byInfofru

Becoming Product Owner

Finally it came through! As of tomorrow I'm officially working as a Product Owner for blueKiwi software in Paris, France. It's not a big change for my personal life, because I will be working mostly from my home town, as blueKiwi is part of Atos I can still use the office spaces in the Netherlands as well. 

Sound on breakpoint hit in Visual Studio

While developing a Windows Phone application I normally do all the testing on my device to get a feel for the usability of the app I'm building. Sometimes though, I'm waiting for an action to complete on the phone, then the application suddenly seems to hang for no reason. Most cases (in fact all cases) it's Visual Studio hitting a breakpoint.

A colleague of me tweeted a solution for this little discomfort this morning. You can make Visual Studio make a sound when it's hitting a breakpoint. I decided to work that out in a blog. 

First: open control panel:

Then go to hard ware and sound:

Click Change system sounds:

then scroll all the way down to Microsoft Visual Studio and select the Breakpoint Hit node:

Finally you select the sound you want there and click OK. It's as easy as that.

Tilteffect on custom controls on Windows Phone 8

At times you have to create your own control and want it to tilt just like buttons and list items do. This is actually very simple to do, if you know how.

The tilt effect is controlled by a static class called TitleEffect in the Microsoft.Phone.Controls namespace of the Phone control toolkit package.

The only thing you need to do to add  the tilt effect to your control is to add the controls type to TiltEffect's TiltableItems collection.

To do so you have to add the Windows Phone control toolkit nuget package if you haven't done so yet.

Then the TiltEffect.TiltableItems is a generic list of Type so you can add your custom control type to it with the add method of it.

A good place to do this in the App.xaml.cs constructor like this:

        public App()

            // Global handler for uncaught exceptions.
            UnhandledException += Application_UnhandledException;

            // Standard XAML initialization

            // Phone-specific initialization

            // Language display initialization

            // Show graphics profiling information while debugging.
            if (Debugger.IsAttached)
                // Display the current frame rate counters.
                Application.Current.Host.Settings.EnableFrameRateCounter = true;

                // Show the areas of the app that are being redrawn in each frame.
                //Application.Current.Host.Settings.EnableRedrawRegions = true;

                // Enable non-production analysis visualization mode,
                // which shows areas of a page that are handed off to GPU with a colored overlay.
                //Application.Current.Host.Settings.EnableCacheVisualization = true;

                // Prevent the screen from turning off while under the debugger by disabling
                // the application's idle detection.
                // Caution:- Use this under debug mode only. Application that disables user idle detection will continue to run
                // and consume battery power when the user is not using the phone.
                PhoneApplicationService.Current.UserIdleDetectionMode = IdleDetectionMode.Disabled;

(I've highlighted the change bold)
And that's it!

Do more with standard controls in a MVVM project

The following works for WPF and WinRT too, but at some point in about every Windows Phone project I do, I wish some control just had this or that functionality added or had a command binding specific for my needs.

 I could of course create my own user control to wrap the original control and add my own functionality, but I generally dislike the idea. This has several reasons. First of all it's a new control to maintain every time. Another valid reason is that you mask of default behavior, so every time you need something of off the original control you actually have to write code or you sometimes end up with loads of controls in your project based on the same.

A much nicer way to get the control to do what you need is to add a behavior. Behaviors are very easy to write, to maintain and to apply to a control.

All you need to do to create a behavior is to inherit a new class from Behavior<T> which sits resides (at least for Windows Phone) in System.Windows.Interactivity. T needs to be a type which is or inherits from a DependencyObject, which means that you can add it to every control you have on the screen.

so a basic useless behavior looks like this:
using System.Windows;
using System.Windows.Interactivity;

namespace PhoneDemoApp.Behaviors
    public class SimpleBehavior:Behavior<DependencyObject>
        protected override void OnAttached()
            //Do stuff here for when the behavior is attached to the control
            //for instance event binding
            //by the way, the control is reachable using "AssociatedObject"

        protected override void OnDetaching()
            //Do stuff here to clean up you mess when the behavior is detached
            //like unbinding the events

you can attach this to a control by including the interactions in your xaml:
when you have this you should also add the namespace where your behavior lives: (I allways put them in "Behaviors")
And then finaly you can add it to a control:
<Button Content="Simple button">
           <behaviors:SimpleBehavior />

All the above looks a bit abstract so lets make a behavior that actually could be useful.
A button doesn't have a default bindable command that executes on double tap, so we want to add that behavior to eh.. a behavior.
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Interactivity;

namespace PhoneDemoApp.Behaviors
{ public class SimpleBehavior : Behavior<Button> { public static readonly DependencyProperty DoubleTapCommandProperty = DependencyProperty.Register("DoubleTapCommand", typeof(ICommand), typeof(SimpleBehavior), new PropertyMetadata(default(ICommand))); public ICommand DoubleTapCommand { get { return (ICommand)GetValue(DoubleTapCommandProperty); } set { SetValue(DoubleTapCommandProperty, value); } } protected override void OnAttached() { base.OnAttached(); //subscribe to event AssociatedObject.DoubleTap += AssociatedObject_DoubleTap; } protected override void OnDetaching() { base.OnDetaching(); //unsubscribe the event AssociatedObject.DoubleTap -= AssociatedObject_DoubleTap; } private void AssociatedObject_DoubleTap(object sender, GestureEventArgs e) { if (DoubleTapCommand != null && DoubleTapCommand.CanExecute(null)) { DoubleTapCommand.Execute(null); } } } }

You can see that I expanded the SimpleBehavior so an ICommand can be bound to it. For the rest there's nothing really interesting to it, OnAttached I subscribed the event, and when it fires, the ICommand will be executed.

When you are using this your XAML looks like this:
<Button Content="Simple button">
           <behaviors:SimpleBehavior DoubleTapCommand="{Binding DoubleTapCommandFromViewModel}" />
You should declare the DoubleTapCommandFromViewModel as ICommand (or a derivative) on the viewmodel you set as Datacontext to your page.

Next up: Extending the LongListSelector to pull to refresh