Sunday, May 31, 2015

Wolf he cries! Internal handled exceptions in Xamarin Forms

Edit: According to my connections to NSA, I've heard that this specific case will be reviewed to avoid throwing of an exception.

Consider the following:

<Image Source="{Binding ImageUrl}" />

ImageUrl is a string pointing to an image, like


When you run this through Visual Studio with the debugger attached and break on all exceptions you get a System.InvalidCastException. The exception itself is handled internally and only visible if you break on all exceptions.

But, how is this an exception? Isn't it expected that the source might be a string? It's not an exception from the normal program flow in my opinion? Couldn't there just be a check of the type passed in and if the type is faulty, THEN throw an exception? String as a source IS valid.

Right now it's a pain to enable break on all CLR exceptions since you hit so many handled exceptions. And sometimes you need that option enabled...

It's a case of "Wolf he cries"... 

Any thoughts on this? Am I totally wrong?

Friday, May 22, 2015

SelectionChanged for a Panorama control in WP8.0

A small tip that might save you an hour or two. Observe that this is not using databinding.

Really short version

Wrap content in a PanoramaItem to get the SelectionChanged event to fire.

Somewhat longer version, but still short

If you programmatically create a Panorama control in, let's say a custom renderer for WP8.0 (silverlight) when using forms, wrap any content in an PanoramaItem if you want events to fire.

Not working

            var root = new Panorama();
      root.SelectionChanged += (s, a) => { Debug.WriteLine("Will not fire"); };
      root.Items.Add(new System.Windows.Controls.Image()
                Source = new BitmapImage(new Uri(""))



            var root = new Panorama();
       root.SelectionChanged += (s, a) => { Debug.WriteLine("Will fire"); };
       new PanoramaItem()
               Content = new System.Windows.Controls.Image()
                   Source = new BitmapImage(new Uri(""))

That's all...

By the way, if you are using data binding and not getting it to work, this stackoverflow post might help:

Thursday, May 21, 2015

Windows Phone Emulator is unable to set the VHD on the virtual machine

This Thursday morning could have started better. I'm in the middle of a month long process to hand over one of our projects to a customers internal dev department when this suddenly happens...

What the... I just have the WP stuff left to document.

I have changed, nothing? And suddenly there is a digital signature verification failure. My first google adventures tell me to reinstall my OS. Not gonna happen. That will send me back into the stone age again.

I tried the following so far:
  • Another emulator
  • Deleted all the emulators from Hyper-V manager
  • Tried to create a new virtual machine from scratch, same error
  • Created a disk manually and tried to attach it
  • Restarted Hyper-V
  • Restarted Windows
Things blew up...

Stressfactor: 60%...

Restart doesn't help, next up is Startup repair that also failed. Restore from a restore point... Didn't work... Refresh my PC? Looks that way... 

Summary of my experience

I'm buying a large external drive later on today to make more frequent backups to. Happy thoughts...

Friday, May 1, 2015

Combining Xamarin Forms with Windows Universal Apps

One of the most exciting news at this years //Build/ conference was Microsofts commitment to Universal Apps. One binary and one store for all Windows 10 devices available, ranging from a Rasberry Pi to Xbox.

This did however raise a concert from my part. What will the integration with Xamarin and specifically Xamarin Forms look like?

The way I would most probably suggest, knowing what I know today, is to create a Xamarin Forms project but drop the Windows Phone project and create a universal project to represent the windows platform. You might want to keep the WP project if you want to support WP 8.0 (silverlight) though.

I would also use a Mvvm-framework, like MvvmCross or MvvmLight to share ViewModels between all projects. I still think MVVM is the way to go to achive the most code share possible.

It's also going to be interesting to see what Xamarin Forms for Windows is going to target in the end.

Bottom line, it looks like you are going to have build two sets of UIs from now on...