If you are using Xamarin Forms for your next awesome cross-platform mobile app, there are things you need to remember when dealing with images for Android.

1. No folders

Even though you can group images into subfolders at root level for Windows Phone or under Resources for iOS, all images have to be inside the Drawable folder for Android. Images in folders are not used.

However, Images/picture.png still resolves on Android.

Which brings us to the obvious…

2. No duplicates

You cannot have two images with the same name in two different folders like Company1/Logo.png and Company2/Logo.png.

Because you cannot have two files with the same name in the same folder.

However, there are still problems with file names…

3. Invalid characters in file names

After reading point 2, you renamed your files and put all images into Drawable. You renamed those files with the same name to something more obvious like Company1-Logo.png and Company2-Logo.png. And it still doesn’t work.

// aapt resource value: 0x7f020020
public const int Icon = 2130837536;

Picture above: Android’s awesome resource handling code.

Due to the way resources are processed in Android, all file names are converted to C# identifiers. And you can resolve images by using their C# counterpart. This, unfortunately, means that only those file names which are valid C# identifiers are valid file names.

This means removing dashes and using underscores. This also means that your images starting with numbers are also invalid. Forget all those 1.png and 13thStreet.pngh, use some “better” names.

Till’ next time, happy coding.

Xamarin.Forms are awesome, but the framework is young and there are some very annoying bugs. Consider the following common, and simple, scenario: you have a ListView bound to an ObservableCollection. If you want to clear/fill that list, e.g. you are building a search page, you will get the following errors (the numbers may vary):

MonoTouch.Foundation.MonoTouchException: Objective-C exception thrown. Name: NSInternalInconsistencyException Reason: Invalid update: invalid number of rows in section 0. The number of rows contained in an existing section after the update (1) must be equal to the number of rows contained in that section before the update (6), plus or minus the number of rows inserted or deleted from that section (1 inserted, 0 deleted) and plus or minus the number of rows moved into or out of that section (0 moved in, 0 moved out).

There is a simple workaround: clear the list by removing each item individually. Instead of writing:

list.Clear();

use:

while (list.Any())
    list.RemoveAt(list.Count - 1);

Happy coding :)

2014 was a turbulent year with lots of fun stuff. I finally quit my day job and became a full time freelancer working on Windows Phone, Windows Store, Xamarin and ASP.NET projects. Even though it’s only been a few months, I must say I am enjoying it so far. As usual I gave a few talks at regional conferences, blogged a little, and was renewed as MVP for C# for the second year in a row.

With all that behind me, it’s time to prepare for the future and this post will serve as both a todo list and a reminder for next year’s me. It will be fun comparing what I wanted to do and what I actually managed to do.

Without any particular ordering, here is the grand list of things for the year 2015:

  • Working more on side projects – there are quite a lot of ideas gathered over the year, let’s see which projects are worth pursuing and which projects are not. Hopefully some of them will create some income, but I wouldn’t bet on it. Lots of these side projects include .NET Compiler Platform aka Roslyn in one form or another. If I manage to finish any of ideas based on Roslyn, they might prove beneficial for the community.
  • Startup stuff – yes I know they are all the rage right now. My brother and I joined Core Hub contest with the idea of building scalable real-time platform on .NET. There are some other ideas in the pipeline, mostly about tourism and IT, but those are ideas for this summer/autumn.
  • Blog a little bit more – I should blog more regularly about what I am doing and fun stuff I encounter. I have a bad habit of starting a new series and forgetting all about it. Not anymore! Writing should ease my mind, not add more burden to it. So let’s make that 52 blog posts this year.
  • Games! – ever since I became a programmer I wanted to work in game industry. Actually, creating games was the sole reason for learning programming in the first place. That’s why I decided to join One Game a Month Challenge and see if I can do it. I’ve made zero games so far in my career so let’s make 12 games this year alone :)
  • Open source stuff – most of my side projects/ideas/games can and will be open source. In fact, the first game I am working on this year is already at GitHub and you can check it out here
  • Speaking at conferences – speaking at conferences became a regular thing for me, but there is always next level stuff. This year I will speak about Roslyn at DevWeek conference in London which marks my first conference outside of mainland Europe :)
  • Traveling – so it seems I travel twice a year to USA, once for Build and once for MVP Summit. I want to keep that tradition and I want to add a few more locations around the world if possible. After all, technology does connect us all.
  • Learn a new language – and by that I mean programming language. Since functional programming is all the rage, let’s dive into Haskel and/or F# to see what they can offer.

Well, that will keep me busy :) It will be fun working on any and all of these, but realistically I cannot do all of them. Some things I am already working on. Some things can be combined (open source and games/side projects). The more I manage to do, the better.

So, what is your list for 2015?

Update: the code was updated to support two additional scenarios: inherited classes and classes that cannot inherit DependencyObject<T>.

Writing dependency properties for XAML controls is annoying and contains some redundant parts. Let’s take a look at an example dependency property (generated from snippet):

public static readonly DependencyProperty PropertyTypeProperty = DependencyProperty.Register(
    "PropertyType", typeof (propertyType), typeof (SampleDependencyObject), new PropertyMetadata(default(propertyType)));

public propertyType PropertyType
{
    get { return (propertyType) GetValue(PropertyTypeProperty); }
    set { SetValue(PropertyTypeProperty, value); }
}

While the property (at the bottom) itself cannot be simplified anymore, the registration part at the top can be simplified quite a lot. Let’s take a closer look at the necessary parameters:

  • First is the property name which one should never write in string literals. The new feature in C# 6: nameof will help fix that, but for now we are stuck with this.
  • The second parameter is the type of our property, which is already written below and should somehow be inferred automatically. Reflection could help with that, but it’s a heavy artillery and is not an ideal solution here.
  • The third parameter is the type of the enclosing class, a context sensitive information that should be omitted.
  • Finally, in most cases the default value is the default value for the property type.

Our goal here is to remove redundancy, use contextual information and remove string literals all in once. And to shorten our code, of course. Luckily, we can already do that in C# 5 without the upcoming nameof feature and the final syntax for the registration part (the property, unfortunately, stays the same) can be reduced to this:

public static readonly DependencyProperty SampleProperty = Register(d => d.Sample);

read more »

Converters are an essential building block in XAML interfaces with one simple task: converting values of one type to another. Since they have a input, usually a view model property, and an output, it would be wonderful if we could somehow chain them to create a new converter that processes all internal converters. Luckily, this is quite simple to do, but we do need to create a new converter which will hold other converters and whose implementation will iterate over nested converters. Full code can be found over at Github repository here, only interesting parts will be highlighted in this blog post.

Our combining converter class is also a converter itself, but it can contain other converters inside it:

[ContentProperty("Converters")]
public class ChainingConverter : IValueConverter
{
	public Collection<IValueConverter> Converters { get; set; }
}

Converter functions are trivially implemented and iteratively go through the converters list and apply the converter on the previous value.
read more »

When it was introduced, LINQ to Objects brought something very interesting to C# world – fluent API. Take a look at the following code:

var result = list.Where(i => i.Extra != null)
                 .Select(i => i.Extra)
				 .OfType<Advanced>()
				 .ToList();

Ignoring the types of objects involved, the underlying algorithm, nay, the purpose of this code is visible at a glance. We take the list of objects, extract only those that satisfy the given condition, create a projection, cast to a new type, filter out null values, and finally create the resulting list.

Working with collections allows method chaining because all methods are actually defined as extension methods on IEnumerable<T>. Chaining is something we are also used to when dealing with objects. Calling a member function or changing the property of a property is a simple matter of typing dot, writing member name, typing dot again, etc.

In case you are a fan of that coding style, you might find the following code slightly annoying to write:

((Bar)foo).Invoke();

Why would that be annoying, that is perfectly legal C#! And quite common actually. To better understand the source of frustration, let’s see how one would arrive at such code.
We start with innocent variable foo of some type. It is irrelevant which type it is and all we know at that point is that we want to invoke the method cleverly named Invoke on it. However, after typing dot, we realise that foo is actually an instance of some other type and that we need to cast it first to get to an appropriate type. Let’s ignore type checking and presume that we know that foo is indeed what we need (e.g. attached properties in XAML platforms have this pattern; even though it is an object, you know what type it is).

So have the following code currently on the screen at that moment:

foo.

To cast foo to an appropriate type from we need to add go back to the beginning of the expression and add two left braces, the appropriate type, right brace, go to end of the expression, put the brace just before the dot and then move cursor to the right and we can now find Invoke in our auto complete list.

This little process disrupts our natural flow. It would be so much easier if we could somehow continue typing to the right of dot once we realise that our variable is not of the correct type.

Something like:

foo.Cast<Bar>().Invoke()

read more »

One can argue that BooleanToVisibilityConverter is rooted deeply in the XAML-based platforms. It is the simplest IValueConverter one can implement and you can find it implemented in various toolkits, frameworks or simply reimplemented time and time again by developers. Part of the reason is that the default facility for showing and hiding is unbindable to regular boolean property.

Historical reason for this can be found in WPF where controls can be in one of the three following states: Visible, Hidden, and Collapsed. When Silverlight was introduced, the Hidden state was removed and only two possibilities existed and which correspond to boolean states.

However, the syntax is atrocious. Look at the following example:

Visibility={Binding IsVisible,
                    Converter={StaticResource BooleanToVisibilityConverter}}

Imagine writing that every time you need to hide a control? Well, you just imagined a lot of code out there.

So, how can we fix this and shorten the syntax? By using attached properties of course. Even though there is no such thing as an IsVisible property, it doesn’t mean we cannot invent one ourselves. The final syntax appears similar to this one:

common:Alt.IsVisible={Binding IsVisible}

Isn’t that much readable? Both the namespace and the owner class names can be shortened to get an even shorter syntax.

Here is the implementation:

/// <summary>
/// Definition of alternative attached properties for various
/// controls.
/// </summary>
public static class Alt
{
	public static readonly DependencyProperty IsVisibleProperty = DependencyProperty.RegisterAttached(
		"IsVisible", typeof(bool?), typeof(Alt), new PropertyMetadata(default(bool?), IsVisibleChangedCallback));

	private static void IsVisibleChangedCallback(DependencyObject d, DependencyPropertyChangedEventArgs e)
	{
		var fe = d as FrameworkElement;
		if (fe == null)
			return;

		fe.Visibility = ((bool?)e.NewValue) == true
			? Visibility.Visible
			: Visibility.Collapsed;
	}

	public static void SetIsVisible(DependencyObject element, bool? value)
	{
		element.SetValue(IsVisibleProperty, value);
	}

	public static bool? GetIsVisible(DependencyObject element)
	{
		return (bool?)element.GetValue(IsVisibleProperty);
	}
}

The source code and the accompanying sample project can also be found on the Github repository here: github.com/MassivePixel/wp-common.

In case you haven’t heard the news, the new version of Visual Studio is out: Visual Studio 2015 Preview. You can grab it here. With you’ll get:

  • A new version of C# language currently at version 6
  • .NET Compiler Platform formerly known as Roslyn: the new compiler for C# and VB.NET which is open source and exposes quite a lot of the underlying infrastructure for the user
  • New JIT compiler i.e. RyuJIT which is also open source
  • Open source subset of .NET Framework

Small things really :) This post will focus on the new features in C# 6 which can both shorten your code and make it more understandable. So let’s begin. In fact, only a couple of new features can be used to add more code to your existing code base.

Class properties enhancements

Writing immutable classes is relatively hard in C# and a few small additions to the language make things easier. Take a look at the following class: read more »

MVP goodies :)

It was April 1st, but the mail was real – I was re-awarded the MVP status for Visual C#. It was about time I replace the stickers on my devices anyway :) I hope that this year will be filled with more C# development now that Roslyn is officially available.

Speaking of Roslyn, the real shocker was the announcement at last week’s Build conference about Roslyn being open source. Wow, this will have a great impact on open source community in .NET world. If only .NET Native is open source (asking for open source .NET itself is a long shot), that would open the flood gates towards other platforms in no time. Even though everyone claimed .NET is dying or being abandoned just a year ago, at Build we had a chance to see the beautiful future for .NET.

Pictured: beautiful .NET future

Pictured: beautiful .NET future

This week I had two sessions at WinDays and NTK about the future of C# and awesome things you can do with Roslyn. Next week I am talking about app to app communication between Windows Phone and Windows Store applications at MS Network. I have to mention that all three conferences are held in beautiful locations in this region: Umag, Bled and Banja Vrućica.

Happy coding :)

This is definitely the coolest thing I found today: running XNA in Visual Studio 2013. Thanks to the unofficial contribution, it is possible to use XNA 4.0 in Visual Studio 2013, 2012 and 2010. Find the appropriate download links at codeplex.

This brings XNA development back in the latest version of Visual Studio, but sadly, although you can develop Windows Phone 7 XNA games in VS 2013, you cannot deploy them from Visual Studio since it doesn’t support WP 7. But that can be fixed since the final XAP is valid and XapDeploy can be used to deploy built games to emulator.

XNA 4.0 running from Visual Studio 2013

XNA 4.0 running from Visual Studio 2013

So as XNA projects can be loaded in the same solution as MonoGame projects, porting old games will be easier. Since the project promises porting XNA to DirectX 11, we now have two projects with same scope in mind.