Making It Snow! Xamarin.Forms and CocosSharp and Particles

Making It Snow! Xamarin.Forms and CocosSharp and Particles

It goes without saying that I’m a big fan of Xamarin.Forms. It’s the first framework I evaluate when taking on a new project. I love all of the out of the box goodness it provides – easy MVVM (especially the binding), layout engine, and now it’s very easy to get down to the platform – without necessarily having to resort to renderers. But … I also like the look of full screen apps that are, how should I say … a little more pizazz-y. You know the ones – they’re full screen, lots of cool graphics, maybe some “things” animating about the screen. Something that looks a bit like the apps below. Those apps are cool … but surely one couldn’t do that with Xamarin.Forms … right? Right? Wrong! Those apps are both done with Forms – and both are running pretty much with the normal Forms elements – Button, Grid, some data binding. But to give it a bit of pizazz – there’s some CocosSharp running in it as well. And it’s pretty easy to get setup and running. So let’s take a look at how to do so! (Full source can be found on GitHub here.) Hello CocosSharp The key to getting that cool background and those animations is CocosSharp. My inspiration for all of this was the weather app Carrot. If it’s snowing, it shows some snow falling – if it’s raining, it shows some rain… etc. I wanted to see if I could reproduce that with Xamarin.Forms. CocosSharp is a game development framework. It’s fully featured (I’m talking physics engine and everything). If you desire,...
Bindable Native Views in XAML – With Commands!?!

Bindable Native Views in XAML – With Commands!?!

Back when I wrote the post on the awesomeness that is binding platform specific, aka native, views directly in Xamarin.Forms XAML one of the things missing were Commands. For example, no tying button clicks to a Command in a view model. Using the UpdateSourceEventName attribute, you can introduce two way binding by having Forms listen for the event specified and then update the bindings when said event is fired. However, that doesn’t help us when our app needs to react and take an action when an event occurs on the native view embedded within the XAML. So what’s a developer to do? One way around this is to embed the native control in the code behind file and then all the events will be available for use. Handle that event, then invoke whatever command you want in your view-model. That works – but it isn’t optimal. You have to mix code-behind with XAML … AND … either use Shared Projects or make creative use of partial classes. There has to be a better way … and there is … Commanding From the Native View! Or Subclassing to the Rescue! The solution to the problem really is rather simple and it evolves subclassing. All the demo code and a working solution can be found on GitHub here. In the previous post on native XAML embedding with data binding, I mentioned there was a new extension method called SetBinding on UIView and Android.View objects. It’s this method the Xamarin.Forms XAML parser calls when it comes across a native property definition specified in the XAML to provide data binding. So … what...