Xamarin, Web & Mobile Software Developer/Engineer

Menu

I would like to announce that SlideOverKit for Xamarin.Forms is now Free and Open Source.

It’s been two months since SlideOverKit was released and the ‘business plan’ was to have the component as premium component for Xamarin.Forms. A component that we would invest in developing, people would purchase and we would continue developing. Since this release something was bugging me, I was frustrated because not enough people were buying and using the component. We had put alot of effort in building this component and we wanted people to use it.

One of my most enjoyable projects in recent years has been the successful FreshMvvm for Xamarin.Forms, it’s amazing to see people use (and love) something that you’ve built. It’s really good to now be a Contributor to open source not just a consumer, in the past I’ve help fix bugs in jquery mobile but nothing as serious FreshMvvm.

There’s been so many open source projects that I’ve loved developing with like JSON.net, jquery, UserDialogs, MvvmCross etc, etc. I hope that one day people will use and love SlideOverKit also.

Only some awesome new features, actually really nice extended and very useful features. With such a big take up of FreshMvvm we’ve ramped up the development. As always we take feedback and iterate on it so let us know of anything.

WhenAny

I’ve always loved the WhenAny feature in ReactiveUI and just wanted to have it. Not to mention it’s strongly typed which makes it so much better.

So now your ViewModels (or anything with INotifyPropertyChanged) you can subscribe to the changes of a property using the WhenAny features.

Here’s how you can use it:

C#

1

2

3

4

5

6

7

8

9

10

11

publicContactPageModel(IDatabaseService dataService)

{

_dataService=dataService;

this.WhenAny(HandleContactChanged,o=>o.Contact);

}

voidHandleContactChanged(stringpropertyName)

{

//handle the property changed, nice

}

Pushing different views

Another awesome feature that we’ve been loving is the ability to push with a different view. This means you can have multiple views for a single ViewModel.

Clean up after page is Popped

FreshBasePageModel now has a PageWasPopped event, this can be used to cleanup after a page has been Popped.

C#

1

2

3

4

5

/// <summary>

/// This event is raise when a page is Popped, this might not be raise everytime a page is Popped.

/// Note* this might be raised multiple times.

/// </summary>

publiceventEventHandler PageWasPopped;

We’ve linked up all the parts within the FreshMvvm project so that the event is always called and always called once, but this might not always be the case if you use a CustomNavigationService and don’t implement correctly.

This is a breaking change on the IFreshNavigationService as it now has a NotifyChildrenPageWasPopped().

If you have a custom navigation service you will need to implement this, here’s a sample of how the builtin master detail service handles it.

Ability to use ViewModel naming instead of PageModel, thanks to this contribution by Olexandr Leuschenko

Multiple Navigation Services

Support for custom IOC containers

Ability to Push a NavigationContainer

It also handles async better thanks to Olexandr Leuschenko

Let’s take a look at some of the bigger features in the release.

Multiple Navigation Services

It’s always been possible to do any type of navigation in FreshMvvm, with custom or advanced scenarios were done by implementing a custom navigation service. Even with this ability people found it a little hard to do advanced navigation scenarios in FreshMvvm. After I reviewed all the support questions that came in for FreshMvvm I found that the basic issue people had was they wanted to be able to use our built in navigation containers multiple times, two primary examples are 1) within a master detail having a navigation stack in a master and another in the detail 2) The ability to push modally with a new navigation container. In order to support both these scenarios I concluded that the FreshMvvm required the ability to have named NavigationServices so that we could support multiple NavigationService’s.

I’m sure you know of behaviours in Xamarin.Forms but have you heard of Attached Properties?

Have you ever wondered how you define properties for a Grid on a Label, eg <Label Grid.Row=”5″, and the Grid just seems to know about it. This is attaching a piece of data onto the Label so that the Grid can reference the data.

Let’s take a look at how it works in the Grids case. In our Xaml we’d normally have something like the code above, so somehow we tell the Grid that we want to be on Row number 5. In order for this to work the Grid needs to have a static ‘attached’ bindable property. Let’s take a look at what the Grid actually has.

So yep the Grid has the attached property for Row, awesome, now how does the Grid get that data?

In order for the Grid to be able to access that data it needs a static method which will extract it as follows.

C#

1

2

3

4

publicstaticintGetRow(BindableObject bindable)

{

return(int)bindable.GetValue(Grid.RowProperty);

}

We can also see that the Grid calls this method to get the data from the child element.

C#

1

introw2=Grid.GetRow(child);

So that’s some pretty cool stuff.

Now for the Trick

Considering this is a bindable property we can actually attach anything to this static property, our own object or even a command. We can also get notifications when the property changes, during that notification we can obtain references to both the Element and the bindable property. This means we can link up custom behaviours without even using behaviours.

Say for instance we wanted to attached a TapGesture for a View to a Command? Normally this is fairly verbose to add in Xaml but setup correctly it can become just a property on the View.

C#

1

local:TappedGestureAttached.Command="{Binding OpenNewPage}"

So what’s TappedGestureAttached? Let’s take a look.

Below we have a Static property called CommandProperty, that property name is Command, has a return type of ICommand and a declaring type of View. You can also see it’s linked to the OnItemTappedChanged command, which means when the property changes that event gets called.

Static Bindable Property

C#

1

2

3

4

5

6

7

8

9

10

11

publicclassTappedGestureAttached

{

publicstaticreadonlyBindableProperty CommandProperty=

BindableProperty.CreateAttached(

propertyName:"Command",

returnType:typeof(ICommand),

declaringType:typeof(View),

defaultValue:null,

defaultBindingMode:BindingMode.OneWay,

validateValue:null,

propertyChanged:OnItemTappedChanged);

Below we have the OnItemTappedChanged command, as I mentioned before we have access to both the View and the Command hence we can wire up the TapGestureRecognizer.

We can also use this to hook up events that are directly on the control without using the code behind of the Xaml. Below we link up the ListView.ItemTapped event to a Command, which will be inside our ViewModel rather than codebehind.

I’m very happy to announce XAM Consulting’s first Premium component release, SlideOverKit for Xamarin.Forms. As I’ve discussed before at XAM Consulting we have a goal to contribute to the Xamarin ecosystem and help companies build great things, our premium components are one part of this goal.

This component is something we’ve been working on for a while after being frustrated with the lack of high quality sliders in Xamarin.Forms.

This component is flexible enough to create any type of Slider you might like, some examples might be a Large Menu that slides from the top of the screen, a small draggable context menu from the right/bottom of the screen or even a right side master detail. There’s a large amount of options that you can tweak to allow you to get your menu looking just right. In this component we’ve done all the slider code in Native (eg we’ve done the hard native work), this means that the component is… 1) it’s super quick 2) you don’t need to use the slow Xamarin.Forms layouts 3) the touch/gesture support is very smooth.

In some ways we would love to give it away for free but after consideration we would prefer to offer a higher quality product with support rather than a half finished product with no support, hence why it’s a ‘Premium Component’. If you would like to read more about our thoughts in regards to pricing components please take a look at this blog post on Pricing Xamarin.Forms Components.

SlideOverKit is available in nuget right now and is available for purchase @ $100 USD. Please head over the the SlideOverKit for Xamarin.Forms website to get more details on how to get started. We have a github repository with a bunch of samples for the component.

Take a look below to see some of the awesome options available for the SlideOverKit.

This post is primarily documenting my thought process when trying to come up with pricing for two premium components that we’re about to release at XAM Consulting. We’re very excited about releasing these components. We’re looking forward to contributing to the Xamarin ecosystem and helping developers build great things. Many companies I’ve worked for have clearly stated that their whole company has been built on the back of great component vendors like DevExpress and Telerik. It’s pretty amazing to know that something you’ve built has also helped build an amazing company or change the world.

The first component we are releasing is called SlideOverKit. This is a powerful component that allows you to slide over from anywhere on the screen, with nice smooth animations. It can be used to create slide menus such as a Right Side Master Detail, Mini Context Menu’s or the display of Contextual Information. The key advantage of this menu is that internally we’ve built the code using Native APIs and therefore it is has the advantages of not only being incredibly quick but it also supports swipe/touch gestures. (Note* that when I refer to Native APIs, that’s only from our internal perspective, from a developer’s perspective the component is built completely from Xamarin.Forms). To illustrate its performance and ease of use, I’ve included some samples below with the SlideOverKit component.

The second component, called TEditor, is a rich/html text editing component designed for Xamarin.Forms. It is intended to be used for the editing, importing and exporting of HTML documents. As such, it supports the majority of rich text editing functions such as Bold, Italic to text color. Like the first component, it takes only a few lines of code to include this component in a project.

So what price do I sell it for?

This is a very hard question; if you price it too high then people won’t see it’s value and if you price it too low then you won’t have enough money to continue it’s development. It’s important to me that we have continued development on the components that we sell. Nobody wants a component vendor that’s not committed.

To investigate further, I researched the components supplied within the ecosystem. There’s the many big vendors like DevExpress and Telerik, who sell their components at over $1000 per year. I’ve also know about the MR.Gestures component developed by Michael Rumpler, who sells it at a very affordable $10. That’s a huge difference in pricing, so I wanted to reach out to Michael and see if he could provide any insights based on his experiences. Michael mentioned that the amount of demand was much less than was suggested on the uservoice website for his component. He also mentioned that at the price of $10, combined with the amount of sales, it wasn’t anywhere near the amount of effort he had to put in to develop it. Michael confirmed a few suspicions that I had:

1) there’s likely to be a much lower demand than you think for a component and

2) there’s a reason companies like telerik must charge so much for their components. eg. component development is hard and it’s very time consuming.

I’ve been in software long enough to know there’s a lot of hidden time and costs in software. At a minimum you need to calculate:

Initial development costs

Costs in writing documentation

Costs in handling support requests (per sale)

Maintenance development costs

Xamarin.Forms is a fast moving target, not only because of the speed of development from the Xamarin team, but also because of the rapidly changing underlying platforms (iOS, Android and Windows). The other issues we also encounter is that most components need to use the Native APIs on the platforms.

So far we’ve spent ~150 hours on each of the components, and on top of this there is a yearly maintenance of ~50 hours. Adding these up, based on an estimate of $75 per hour development cost, leads to a cost of $11,250 in the first year and $3,750 each year after that.

It would be nice if the components were to break even in the 24 months. In order to calculate this, we need to guesstimate the amount of sales each component will generate each year. Given that each component is a niche component inside Xamarin.Forms, which is a niche in Xamarin, which is a niche in Native Apps, which is a niche in the software world. I’m really not expecting a huge amount of sales each year, for SlideOverKit. I don’t think that I would expect more than 50-100 sales per year. Assuming 75 sales in 12 months, the costs are $15,000 in the first 2 years, then $15,000 / 150 = $100 per component. Now the RichTextEditor is an even more Niche component, which I’m only expecting a few sales each per year. Assuming 10 sales per year, then $15,000 / 20 = $750.

Shouldn’t it be free and open source like in XLabs and other components?

Open source software is great, I get a lot from the open source community and love contributing to the open source community, I spent a lot of time developing the FreshMvvm Framework. The problem with projects like XLabs, is that many of the components are not feature complete or are half finished (or are implemented on only a single platform). The reason for this is that most of us contributors to XLabs, also have full-time jobs and can only work on the project in our spare time.

XLabs works great if you’re an expert in Forms, Android, or iOS and don’t mind getting your hands dirty delving deep into code. Many developers and business don’t have all day and night to be working on building components.

So I wanted to put in the effort up front so that I can help time-poor developers and businesses, so we invest in developing production ready components that are easy to use, feature rich, well documented and production ready and developers can just build awesome stuff.

If you would like early access to any of the components please feel free to contact me anytime.

Since the first release of FreshMvvm it’s been a wild ride, the up take of FreshMvvm has been very impressive it’s really good to see others having success using FreshMvvm. While I’ve been using and loving FreshMvvm for a long long time, even since before it was called FreshMvvm, it’s great to see others also enjoying the Framework.

Since this release has a few large features and breaking changes I’ve decided bump the version up to 1.0 preview. Please see below of a description of the features.

Multiple Navigation Services

It’s always been possible to do any type of navigation in FreshMvvm, with custom or advanced scenarios were done by implementing a custom navigation service. Even with this ability people found it a little hard to do advanced navigation scenarios in FreshMvvm. After I reviewed all the support questions that came in for FreshMvvm I found that the basic issue people had was they wanted to be able to use our built in navigation containers multiple times, two primary examples are 1) within a master detail having a navigation stack in a master and another in the detail 2) The ability to push modally with a new navigation container. In order to support both these scenarios I concluded that the FreshMvvm required the ability to have named NavigationServices so that we could support multiple NavigationService’s.

Ah so now when you’ve learnt MVC/MVVM, everyone’s decided that we shouldn’t do it anymore? Huh?

MVVM is a great pattern which allows for a clean separation between views and logic, it also lends itself well to unit testing, but is it the only way? If you didn’t already know there’s some new kids on the block, Unidirectional User Interface Architectures which is basically applying the CRQS/Event Sourcing pattern on the client side. The idea of these patterns is to have a single DataStore which is the source of truth and data is updated via events, all Views read from the single source of Data and can only update via events/actions. From what I can gather at the moment, the specific problems they solve are 1) Avoid data being duplicated across viewmodels and stale data 2) Avoid the situation of Fat ViewModels. At the moment this concept is being driven from the web clientside world, but eventually it might make it’s way into the Xamarin world and become popular, maybe?

There’s new unidirectional frameworks appearing all the time, the ones I’ve looked into recently are Flux and Redux.

Flux Diagram

Redux Diagram

So can we have these in Xamarin? Yes, these are simply design patterns and can easily be implemented in C#. Infact someone has already created a project based on Redux named Redux.net. In some R&D we’ve been doing on a project we’ve also implemented a Xamarin.Forms sample for the Redux.net project.

Here’s some code from the redux project:

Let’s start with our Application state.

C#

1

2

3

4

5

6

publicclassApplicationState

{

publicImmutableArray<Todo>Todos{get;set;}

publicTodosFilterFilter{get;set;}

}

The Actions are basically any changes in your apps state.

C#

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

publicclassAddTodoAction:IAction

{

publicstringText{get;set;}

}

publicclassDeleteTodoAction:IAction

{

publicGuidTodoId{get;set;}

}

publicclassCompleteTodoAction:IAction

{

publicGuidTodoId{get;set;}

}

publicclassCompleteAllTodosAction:IAction

{

publicboolIsCompleted{get;set;}

}

publicclassClearCompletedTodosAction:IAction

{

}

publicclassFilterTodosAction:IAction

{

publicTodosFilterFilter{get;set;}

}

The application reducer will then take an Action and modify the state.

In all truthfulness I (like most people) don’t know if Unidirectional User Interface Architectures are the answer but I feel like they’re going to be around for a while.

I feel like I’ve hardly done these architectures justice in my explanations but I encourage you to look further into these patterns (maybe even try them or built a Unidirectional Framework for Xamarin). Anyways here’s some links for further reading.

Dont forget to subscribe to michaelridland.com.

Here’s the next video in the FreshMvvm n+1 series. The idea of this series is to get the video’s out to the eager listeners (you) as quickly as possible, therefore these videos are done live with almost no editing.