Mobile development is hard!
That’s why Xamarin Guru Michael Ridland will walk us though Xamarin.Forms; a powerful way to design Android & iOS UI’s from a single, shared C# codebase. Easy!
Let us know how you feel, take the poll!
Michael Ridland: Hi everybody. Thank you for coming along today. I am going to be talking about Real World Apps with Xamarin.Forms. So I’m Michael Ridland on Xamarin MVP and Featured Community Blog. I have been doing Xamarin for about four years now and I run a company called XAM Consulting. We pretty much do Xamarin all day and night. I love it. And so I have been [00:00:31 inaudible] Xamarin before Xamarin.Forms and I have used it after with Xamarin.Forms. This is what you usually see on the Forms. Xamarin.Forms is bit of a love-hate relationship with a lot of people and it is an [00:00:48 abstraction]. So you’ve got the lower-level APIs of Xamarin iOS and Xamarin.Android, but Xamarin.Forms is an abstraction. So anytime you do get an abstraction, there is always going to be potential problems with it. It is getting better and once you do actually sort of figure out the correct in Xamarin.Forms, it can be a very, very powerful tool. The truth is no matter what you do, mobile development is hard. So you [00:01:19 inaudible] have the option of doing three teams – an iOS team doing Objective-C and Android team is doing Java and the Windows team that is doing Windows Mobile. So you have to elect this – the Windows Team, the Apple team and the Android team – and then you’ve got a UI designer with three different interpretations of the UI. So whatever it is and then you can try phonegap. So doesn’t matter what you’re doing [laughter]…doesn’t matter what you are doing…yeah [laugh] …So I guess phonegap is making progress. I get a lot of customers that come from phonegap. So [00:02:01 inaudible] too much progress maybe [laugh]…yeah, so Xamarin.Forms…Xamarin traditionally was having the shared C shop application logic with native UI on each platform. Xamarin.Forms had now with this line up here has shared user interface code and with just a little bit of Native. It really depends. Sometimes you have to have a little bit more native on each platform, but there is an amount of logic that can be shared for the user interface. So because it is an abstraction you always are going to get late and it is only a year old. So over time it’s going to improve. So it’s only version 1.5, you know. It’s not perfect. There is always trade offs. So if you want to do a game, Xamarin.Forms is not going to be the right choice, but if you are doing a business application that’s probably going to be the right choice. And it does kind of sucks less than everything else.
So I think what makes Xamarin.Forms awesome is the fact that it has Xamarin.iOS and Xamarin.Android underneath. Xamarin.Forms allows you to break in and out of the Xamarin.Forms model and back to Native iOS and Native Android. So any trouble you get yourself into, you can actually get yourself out of and have a Native app. So it is a Native app when it comes down to [00:03:38 inaudible] into a Native app, different to phonegap and other solutions.
So you don’t have to just use Xamarin.Forms. So in the past, you can see down here. This is Xamarin traditional, the Native part of Xamarin. This is the Xamarin.Forms, and that’s Html5. So you can with Xamarin…you can essentially have your own mini phonegap’s imbedded in Xamarin application from the past to make sense, and then you can easily jump out and go back to Xamarin.Forms and then go back to Native as well. So you are not sort of constrained to any single thing with Xamarin. You can flip between them.
So Xamarin.Forms is fast and easy to create UIs. It’s good, the extensibility points. And anything you can do in a Native app, you can do in Xamarin.Forms, as long as you sort of know how to do it and look at documentation that’s good on the [00:04:36 inaudible] custom renderers where you can break out and go into the Native code and there is also dependencies which allow you to call Native APIs. And the good thing about Xamarin.Forms is that it makes you think in a Cross-platform way. If you ever did Xamarin traditional, you have a tendency to put too much logic in the UI because that’s the way sort of iOS encourages you to do it. But while using Xamarin.Forms, you have to go out of your way to put lots of logic in the UI code. So it still suffers lowest common denominator. So some parts where you go, this is the Android way of doing things. You might not be able to get there with Xamarin.Forms. You might have to make a couple of compromises, but you can still do a good user interface. The coverage of UI elements isn’t huge, but there is definitely enough there to build [00:05:33 inaudible]. This is like a few tiny cuts with no Bordering, Padding, Radius, and there is a few missing extensibility points, when tapping into the Framework if you want override different areas.
So my tip is be patient. Mobile is hard. So you are going to encounter issues. There’s always going to be problems. So just estimate accordingly. So if you are used to doing web projects, just multiply it by 3-5 which is the general consensus [00:06:07 inaudible] last week. So may not be that far off. So don’t fight the Framework. If you come from an iOS Native application background or Android Native, there is certain ways that you are probably going to want things. But really you just need to think about the Xamarin.Forms and [00:06:27 inaudible] solve the same problem doing in the Xamarin.Forms. Right? Because if you want to try and take everything you have done on Android to iOS Native [00:06:37 inaudible] and do it in Xamarin.Forms it’s going to be hard. Well it’s pretty big API. So when you are using Xamarin.Forms, there is any 4000 APIs. As soon as you break out into native code, iOS has got 33,000, Android has got 40,000. So as much as you can actually keep within the Framework, you are going to say [00:07:05 inaudible].
Once you do go into a custom renderer, it can be 3-10 times more expensive because of the extra code that you have to write and the APIs that you need to learn, but if you need to then you can go in this. So you have got the option there, but try to keep it within the constraints of Xamarin.Forms.
I use XAML. Originally I started out, I used to do lot of code in [00:07:33 C shop] Xamarin.Forms. But after doing a couple of projects using XAML, I find it a lot easier to read, especially you are coming back to it. It does lack a little bit of flexibility, but I think I would just come back and read it a lot easier. It’s a lot better. So the Xamarin.Forms has a messaging center for publish/subscribe. So it is great for communicating between different parts of the application, but don’t overdo it because essentially it’s like a goto statement.
So if you want to learn Xamarin, the place that I did originally was github. So Xamarin has a lot of samples on github and there is a few other [00:08:18 bloggers] out there and work for Xamarin [00:08:21 inaudible]. So use Mvvm. I inherit a lot of Xamarin.Forms applications and the worse ones that I inherit are when people don’t use Mvvm. Xamarin [00:08:34 inaudible] you can roll your own Mvvm, but following on the people who do that, they just don’t do well enough and the code just ends up being a sort of like in sphaghetti logic and UI [00:08:47 couple] to the navigation. So there is an awesome one called FreshMvvm and then there is a few other ones out there. So the one thing that Xamarin.Forms doesn’t have is like loading screens not built into the Framework and there is a good Framework out there called Userdialogs, so you can easily just put that into your Xamarin.Forms application and start using that. So there is [00:09:16 inaudible] project called Xamarin.Forms Labs which kind of fill some of the gaps that there are in Xamarin.Forms. So this thing is like HybridWebViews and Network services and [00:09:30 inaudible] projects. If you are actually doing Xamarin.Forms a lot, it’s good to actually go and understand how Xamarin works and what it’s actually doing behind the scenes. So you can actually even jump into Xamarin.Forms code and you can see what the custom renderer is doing and I use that a lot. If there’s ever a bug that I encounter with Xamarin or I want to understand how something works, I will just jump into the source and just see. Other day, there was a bug in the Master Detail and I was able to take a look at this code and figure out the issue and work around it.
Should I use Xamarin.Forms? Probably. There’s some sucky parts, but it’s still better than every other option.
So thanks our sponsors – SSW and the University of New South Wales and developer experts. Thank you very much.