Evolve 2014 Summary: Extending Xamarin.Forms with Custom Controls – Jason Smith, Xamarin

I’m going to be doing a series of blog posts on the Xamarin Evolve 2014 Conference, they’ll be detailed summaries of the sessions.

My first one, Extending Xamarin.Forms with custom controls by Jason Smith, was a very very good session. Jason is a lead dev on Xamarin.Forms, this is fairly clear in the session as he goes into great details and his Q&A was amazingly insightful.

Intro

To begin with Jason explains that the amount of APIs on iOS and Android are huge.

• iOS 33,000 APIs
• Android 40,000 APIs

He then shows a quote from Albert Einstein.

“Everything should be made as simple as possible, but not simpler” – Albert Einstein

Jason then explains that “Writing code is about managing complexity”,  “Complexity is what makes your app special, but complexity is also what makes your app hard to develop.”

• “Complexity is a source of bugs”
• “Complexity is what makes your app amazing”
• “Complexity is a necessary evil”

I understand Jason’s point in this, as personally I’ve always thought ‘managing complexity’ was a important part of what software developers do. It’s also very true in Xamarin and Xamarin.Forms as in order to build apps that users love we need to add this complexity.

Custom Renderers

A renderer is what turns a button into a button:

To start off Jason shows a basic framework of an app built with Xamarin.Forms, it’s a very basic app. He then proceeds to tell us how to use the built in styles to do styling for Xamarin.Forms. Once done the app looks nicely styled but Jason then moves on to show us how it can be taken to the next level with custom renderers.

Jason explains that Export Renderer is the bases of Renderers, he also explains that the reason Export Renderer is on the assembly is because it’s more performant to read attributes from the assembly that the classes.

Jason’s first sample of a custom renderer is a CircleImageRenderer that inherits from ImageRenderer. I’ll include some important points that Jason makes.

The OnElementChanged method is the most important method when using custom renderers. It tells you the element your watching has changed, therefore you must adapt and change. It’s possible for a ListView to reuse renderers rather than new up new renderers. You must be aware of this. He describes the best way to handle this, as per the screenshot further down this post.

When handling the OnElementChanged event you initially check if the Control is null, then if the old element is null unhook old events, if the new element is not null then hook the new events.

Jason then demonstrates a loading view custom renderer,  interestingly Jason uses a single ContentPage and fades in the loading view as the content then hides it and swaps the content with the view he actually wants.

Jason claims it’s the coolest loading view of all time and it’s actually fairly impressive, well for geek programmers anyway.

He then continues and explains a bug that we might hit when developing Xamarin.Forms Custom Controls.

OnElementChanged event gets called many times, well as many times as we choose. Sometimes it’s once and sometimes it’s hundreds. But you do need to handle this, as SetNativeControl needs to be set one time.

Bad Code

Better Code

 

The (good) Pattern:

– First check if your control is null, if null create a new control.

– If your old element is not null, then unsubscribe

– If your new element is not null, then subscribe

 

Q & A:

Attendee: Is the only way to set renderers is to export them?

Jason: The answer is yes, renderers are only associated through exporting. Jason also makes a point saying that *dont override the default renderers, make a custom subclass.

The attendee then suggests that you can’t use two renderers for a single control. Jason confirms this is correct.

 

Attendee: An attendee wanted to know about the roadmap in regards to transitions.

Jason: It’s on the radar and it’s something we want to do.

 

Attendee: Is there any plans to swap out the service locator so we could have multiple renderers for a control?

Jason: At the moment it’s not possibly and not exactly on the radar either.

 

Attendee: Mentions that Jason did a great presentation and doesn’t give himself enough credit, as Jason and his team has really built something special.

 

Attendee: What about extending layouts?

Jason: At the moment you can subclass layouts, the Layout is internal but soon it will be exposed to you.

 

Attendee:  So in layouts we can add our own sprite kits etc

Jason:  Yes, this should work and be fairly easy

 

Attendee: Can you explain what’s in 1.3 release

Jason: Styles, Behaviours, Triggers, Dynamic Resources, Styles Based on Dynamic Resources (which is new to the whole world).

 

Attendee: Is there any plans to add more gestures to Xamarin.Forms? What about popups?

Jason: Popups will be added. Generally people want two gestures Long Tap and Swipe. Well we’ve got something better coming context actions, so on your cell you set the context action and easily add mailbox swipe style cells.

*I’ll be very interested in seeing what context actions are, I feel like they could be something amazing.

 

Attendee: Wondering why you created Xamarin.Forms on Android to be a single Activity rather than multiple activity?

Jason: At the time we started fragments weren’t fully back ported. Google was promoting the single activity approach. The navigation in Activities didn’t fully map to the Xamarin.Form navigation.

 

Attendee: We use alot of 3rd party components and many time these 3rd part components require a native View or ViewController. At the moment we use a Custom Renderer as this is the only way to do this right now, will there be better ways in the future, some sort of Native Hookiness?

Jason: Yes there will be some Native Hookiness.

 

Attendee: Is there intention to make some sort of UI Designer, Xamarin.Forms Designer.

Jason: The big question, the elephant in the room. There is an intention is to make something that will really help with designing Xamarin.Forms, will that be a drag and drop designer? Probably not! Why, because it’s actually not that useful in a cross platform scenario, because you want a live preview. What you really want is live Xaml coding and a popup of the stuff on all three platforms. I’m not announcing anything coming at any point other than saying it would be really stupid for us not to do it. That is not a blood contract so please don’t kill me.

 

Attendee: I notice a lot of the support around Xamarin.Forms is centred around phones, do you think Xamarin.Forms will be a good solutions for tablets?

Jason: It means that tablets are supported but it’s not automatically adapted to it. It’s your job to adapt Xamarin.Forms to tablet. Which basically means you need to change your layouts to adapt to the tablet.

*Which is how it always is/was on mobile development.

 

Summary

This was a great video for myself as it was related to the work I do every day, it also provided some great insights into the future of Xamarin.Forms.

Thanks to Jason for the great presentation.

Here’s a link to the video if you want to watch.

Michael