Xamarin - Cross platform developer
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
James, Mike
Building cross-platform native UIs with one shared codebase was once just a dream. With Xamarin.Forms, this dream is now a reality. Xamarin.Forms allows you to build a native UI for three platforms with one shared C# codebase. Simply put, if you know C# then you already know how to build iOS, Android, and Windows Phone apps.Leverage the .NET Framework to build out your shared business logic including integration with web services and Azure Mobile Services and then build out your shared UI in C# or XAML. Xamarin.Forms also features a built-in two-way data binding, dependency service to help you implement platform-specific code, an advanced cross-platform animation system, support for custom controls, and lots of other powerful features to help you build the best apps possible in the least amount of time.
 you you. You couldn't get any already compiled binaries, you would have to build it yourself. I'm not sure if anyone's built Q from scratch. It's a pretty lengthy process, right? It's not a quick thing. You start at night, you come in the morning and if you're lucky, it may be built. They were releasing Nightly Builds, it was horrible. There was no way I could use Q to build a mobile solution. We were across platform shop, I couldn't go ahead and write a mobile app for the guys using Objective C. It's not cross platform, we can't use this. I did something horrific. I used jQuery mobile. I used a built-in web server. It's got the rest of the API. I would ask what lights are on, what lights are off, can I start firing some effects, I can make it do a rainbow. I made a nice little UI using jQuery mobile. Then we tried to scale that out to other installations. The Westfield shopping centre in Stratford, all of their exterior lighting, it's all static now because they didn't actually get planning permission, which is genius. All their exterior lighting is intelligent. They wanted to walk around with an iPad and control the lights. They could select a tree and say I want this tree to be red. It would magically be red. I was using jQuery mobile again. I sat in sublime text writing HTML and JavaScript and sometimes a bit CSS. We would ship the app to them. They would actually just put it on a memory stick and shove it in the side of the LPC. We would then connect from our phones onto the device. That app got so complicated because they wanted real-time colour selection. I had to build a colour picker in JavaScript. It was nasty. When you would move around, we would sometimes doff the box with so many messages that we want to send so many updates that it would just die. Or we would send too many people with connect at once and it would just die because it's only a tiny alarm processor. The app was horrible. It most likely killed the device at least once a day. There's got to be a better way. I was sick and tired of writing JavaScript and HTML. I wanted to get back into a real IDE. I had two options. Option one was to go into work on a Monday and hand in my resignation and say, Simon, I'm out. I cannot do this anymore. I want to use real programming tools and I want to use a real programming language. Or I can find an alternative to this horrible solution. On the Friday, I went home and I sat there contemplating, write my letter of resignation or find the alternative and I opted to just do some Googling. I thought, what's the ideal situation here? I want to be able to run.NET on an iPhone. That's all I typed into Google..NET on iPhone. Xamarin was a top link. This was three or four years ago. I'm not sure if anyone used Xamarin back then but the website was really horrible. We looked very amateur. The company was about 30 people. It was really, really small. They were only about a year old at that time. It was very amateur. I was like, I'm going to give it a go. I pulled out my credit card and I bought a pizza because no good programming project starts without pizza. When the pizza arrived, I pulled out the credit card again and bought a license to Xamarin. Over the 48 hours of my weekend, I just sat in my room and I hacked and I hacked and I hacked. By the end of it, Monday morning, I had 100% native iOS app built in C sharp. But a portable class library that I could reuse across Android and Windows phone and all of the other platforms that we might want to target in the future. I rock up to work with really cocky on the Monday morning and I say, hey, Simon, I built us an app and it's a proper app this time. Let's have a look. I pull out my phone and I hand it to him. There you go. I'm feeling pretty smug about it. He looks at it and says, yeah, we can't use this. What's the problem? He says, well, you built it with Objective C. I was like, I haven't. I know it's native but I can still share a lot of this code. I showed him and he was blown away by what I had done with Xamarin. About a week or two later, I applied for a job at Xamarin and I left Pharros. He wasn't most pleased about that. That's my story of how I came into Xamarin development. I had gone down a hybrid approach and I found a limiting factor pretty quickly. I knew I needed to go mobile and I don't want to write my code three different times. I don't want to write it for Windows and then for Android and then for iOS because that's mad. Today we're going to talk about how you guys can avoid that technique of reinventing the wheel and how you can use Xamarin to write once and run anywhere. That's the Xamarin platform. We also have a couple of other products. Was anyone in the earlier speech by Carl? He works for our test cloud team. For those of you who don't know, test cloud is a product where you built your app, you tested it with your unit test and you're like, we think it's rock solid. We've tested it on about four or five Android devices. We've got coverage. We'll ship it. We're excited to get this out. You ship it off and then you get app store reviews saying it don't work. They never give you a stack trace. They never give you details of how to reproduce it. They never tell you exactly what's wrong. So you end up basically asking your users to test the app for you. With Android, this is really important because there are 17,000 different varieties of Android which is quite a lot for you to test on. Who here is actually testing more than 100 devices? More than 50? More than 25? We're going to do this. Come on. Someone's going to have to raise their hand at some point. More than 10 devices? 10? About 10? Okay. More than 25? This is still really bad. More than two. Come on. Okay. Do you guys write software? This is a problem. Most people aren't testing their apps properly. They write the app, they side load it onto their device and then they go, well, it works here. If I could get a pound for every time I went onto bugzilla and I found the developer wrote, it works on my machine. I wouldn't have to work. The reality is when we're testing on our devices, they're not normally set up in exactly the same way as our customers are using. Our customers will install some really horrible things, especially on Android. So it's really important to test. So with test cloud, the idea is you build your app, it's lovely. You think you've got it rock solid and we'll prove it by running it on over 2,000 physical devices in our warehouse in Denmark. So you literally upload your app to a device and we've got a test runner which will start tapping buttons and swiping and we take photos at every step and we let you see every single step of the application. So when you tap on a button, you want to go to the welcome screen. Boom, there's a welcome screen. We'll take a picture. The welcome screen doesn't load, we're going to tell you instantly. We're going to send you a message and say, hey, the welcome screen didn't load on this device. You might want to look into that. So that's a pretty cool product. The test cloud guys, we've got two of them here today. So if you want to learn more about test cloud and how you can integrate that into your release system, then do come and find us on the stand. We also have Xamarin insights which is our analytics and crash reporting tool. This became into general availability just in November, but we've had it in preview for what feels like forever. But it's now, you know, we're pretty happy with it. We're at the point where we're happy to charge for it. But we have a free tier which allows you to catch any uncalled exceptions and we'll report them to the cloud. Now, we do re-throw them. So we're not just going to consume exceptions for you. We'll catch them, report them and re-throw them. But that allows you to very quickly find out where your app is crashing. So rather than, you know, just getting the app store review that say it don't work, you can go on to insights and you can find the exact user and see the crash that they had and have the stack trace. So then you can go into your project, find the line of code where you have the issue and make the fix. And if you're using test cloud, then you can update your test, upload the new app with a fix in it, going through the processes that the original reporter of the issue went through and then you can say, yeah, this works lovely. And then it's all underpinned by Xamarin University which is our online course. But I won't talk about that if you want to learn about that and you talk to me afterwards. So what is native? There are three parts of what I would describe as making a native app. There's native UI. So what I don't want is, you know, the Qt version with Qt 5, they can build native apps and I'll tell you it's a native app. But actually in terms of what you're looking at on the screen, they're drawing every single pixel. So it's not really a native UI. It's Qt's interpretation of what a UI should look like on an iPhone, on an Android and on Windows phone. You're not going to get a UI button or a UI table view controller. You just get their version of. If you go with hybrid, you're just wrapping a website. So again, it's not a native UI. Somebody has very talented CSS coder and created some CSS that makes a button look similar but it's not a native button. There are some differences when you do long taps and long presses and you're swiping from views of you. On hybrid, it often doesn't look quite as slick as a native UI. Underneath that is API access. If I can't access 100% of the API is available to me on a particular platform that I'm trying to target, I don't qualify that as a native solution. I want to be able to have access to every single API that the objectives see Swift or Java developers have access to. When Apple comes out with a new API such as 3D touch, I want to be able to implement that in my app. The hybrid guys and the guys using Qt and the other competing frameworks that aren't native aren't able to do that. And then native performance. I'll talk about performance a little later. Mobile users aren't sat at desktops where they can wait 30 seconds to a minute for something to load and you can lock the UI thread and they'll just accept it. Mobile users expect really high-quality software that's really performant. It's often that they're in a queue in Starbucks and they just pull out their phone and they're going to tweet and they're going to check Reddit. If they pull up your app and it takes too long to load in the data or even just load to the first screen, they're going to quit and move on to the next app or order their latte with vanilla, whatever the hell they want. There are a few approaches to developing mobile apps. I've already mentioned the hybrid approach. We have the siloed approach as well which is what I mentioned earlier where you reinvent the wheel for each platform. You write it once in Objective C or Swift if you're really modern. Has anyone used Swift? It's quite nice. I quite like it. It's like F sharp version 1, but it's still quite nice. If you really like Swift, check out F sharp. You've written it for iOS. It's huge success. You're earning loads of money. You're like, let's get our app to be the number one pirated app for Android. We'll write it for Android. Boom. We'll use Java. I want to hit Windows phone. I want to UWP. You reinvent it again for using C sharp in Visual Studio. Now you've got three different code bases, three different IDEs, often three different teams depending on how big your company is, all developing effectively the same app. Not showing any code. This is a pretty mad approach to developing mobile applications, but it's really easy to fall into this approach. Is anyone using this approach today? No one? Is anyone here developing mobile apps today? Okay. Websites? Perfect. Silverlight? I guess that in a website kind of. WPF? Awesome. So we're all.NET developers. Great stuff. Okay. So if no one's using this approach, that's great. Just don't use this approach. So the Xamarin approach is unique because we're saying we're still going to have a native user interface. We're going to have that native element, the native performance, all access to the API. And we're going to do that by having one-to-one bindings and we're going to create our user interface using those bindings and using the UI buttons, the UI table view controllers for iOS. We'll use a table and a button for Android and the same for Windows. It's a native type. And we're going to share all the boring bits of our application. So this is all the models, all the business logic, all the respal calls, all the data persistence, all the bits that the users really, really don't care about. Because they only care about that top 20%. The APIs that are unique to them, the peak and pop on iOS, the searching, all of the lovely features that Apple give us and Google give us within the OS. That's what they care about. They don't care about this bit. So you can write your code once in C sharp and we'll share it across all of the platforms. And because it's C sharp, we can run it really everywhere. So not only can we run it on iOS, Android and Windows phone, but we can go ahead and run it on Linux using Mono or we can run it in Azure as well. And do we have any F sharp developers in the room? Okay. Well, maybe you in the future. This time next year. We also support F sharp. F sharp is a first class language for us. Our design team are actually all developers as well. And they love F sharp. So we've got top notch support for it within Xamarin. Everything you see me talking about today is applicable with F sharp as well. I'm just not intelligent enough to use it. I can read it and it's lovely. When I debug F sharp, I'm like, wow, this is magic. But then when I try and write it, I'm like, can't do it. Too hard. So just like when Microsoft give us some new APIs and we've got that base class library, so all of the namespaces and in turn classes we've been using for years, system.link, system.x now, the stuff that we used to, our bread and butter, they give us some new APIs and we're like, meh, we've got this. We understand it. There's nothing too new here or too scary. We're just going to build on top of our existing knowledge. Well, we've done the same with iOS and Android. So with iOS, as I mentioned before, we've got that one-to-one mapping. So every single API, the Swift and Objective C developers have access to, I have access to as well in C sharp using Visual Studio. So I can use resharper on this code as well, which is amazing. So we have access to things like UI kit, map kit, iBeacons, every single API, it's 100% coverage. And then we did exactly the same for Android. So again, all the base class libraries, all the stuff you know and love. And then on top of that, a one-to-one binding to every single API that Java developers have access to. So Xamarin.embrace and extended.net. Has anyone peered in votes to a native library before? One couple? Okay. So that's basically what we're doing. I mean, if you strip away our nice designer and all the build tools that we use and all of the extra fluff that make using Xamarin a pleasant experience, you pull that all away and actually look at what we're giving you, it's a wrapper. It's just a wrapper to allow you to peer invoke into these native libraries, which is how you get that native app. It's how you know, instantiate the native controls because it's just a thin wrapper. So if you've done peering, you understand the core of how we work. So there isn't any magic here. It feels like magic when you run C sharp on an iPhone. You're like, yeah, this can't be right. But it's not magic. And I wanted to talk about performance. Performance is really, really important with mobile. And there's two sides of the performance story with Xamarin. On iOS, we have to do ahead-of-time compilation. This is a rule from Apple. They've said that they will not allow any apps on the app store that are jitting. So we can't jit. So we have to do the ahead-of-time compilation. So what that results in is that you'll build time when you want to release to the actual physical device. It's a little bit slower. But we can do a lot of optimizations with the ahead-of-time compilation. So we use things like a linker to strip out all the files you're not using to bring down the overhead of using mono and our runtime down to an absolute minimum. We feed the... We take the IL, so the C sharp goes down to IL, just like your WPF apps or your WinForms app. We take that IL, we convert it to a bytecode that we can feed through the LNVM compiler, then at the end of it we get the native ARM assembly. So we don't lose any performance using Xamarin for iOS. On Android, we can jit. So we tend to jit on Android. We do have an ahead-of-time option for Android if you want to go down that route. You're not going to see a huge performance increase if you do that. But Android tends to be faster using Xamarin than if you had used the Delbit and used Java. So we've got some benchmarks. And these were produced by an ex-Googler. You can go and check out the link if you'd like. He was an early Google employee. He now owns a racing car team. So he did very well out of his stock options. And he likes to write apps now for his team. And when he was looking to write the mobile app, he went and he compared all of the options. And he's looked at a lot of competitors for us. And he's benchmarked them. And then he put it online and naturally he put it on GitHub and said to all the other developers that were saying, well, you know, I can improve this switch code. I can improve this objective C code. He's like, please do. Send in a pull request, I'll rerun the test and we'll update. We want the best information. So he's done that. And this is always, you know, improving. But you can see here that, you know, we're a little bit slower than Swift. But we're looking at less than a second anyway. So it's pretty performant anyway. But we tend to be faster than objective C. And the reason for that is objective C is a pretty difficult language to write in anyway. And because of all the messages, it's pretty hard to optimize that. So Xamarin, you're not going to have a performance loss for using Xamarin iOS and C sharp compared to objective C. So there's nothing to worry about there. On Android, as I say, the story is a bit different on Android. We tend to be faster than Java. Again, you can see we're so close to Java in terms of performance that we're only fractionally faster. So your users are never going to be like, wow, they must have rewritten this in Xamarin. It's so much more performant. No one will ever say that. But you're not going to have your users waiting around forever for something pretty trivial to happen as if you were using titanium, for example. So anything you can do in objective C, Swift or Java can be done in C sharp using Visual Studio. And that's really key. We're built into Visual Studio 2015. So you don't have to go to our website and download extra bits and bobs to get us installed. As long as you've installed everything with Visual Studio, you selected that cross-platform development option. We're in there by default. And C sharp runs on 2.6 billion devices. When I worked for Faros and we were building the cross-platform software, C++ was really the only option for us to do cross-platform in a reasonable language. And now I kind of feel that, you know, if I had to build a cross-platform app, I would never use C++ because I'm not building real time apps. I don't need that level of performance. C sharp gets me such good performance that I can use C sharp and not have to deal with the nastiness of using C++. Now, I love C++ and don't get me wrong, but I'm much, much nicer to program in C sharp. And I want to show you some of the devices that C sharp runs on. I'm not going to try and list them all because there's quite a lot. This is the ugliest slide I've ever produced just in case you're wondering. It's designed to be a little ugly. I think that's it. So we've got Android devices, we've got Xbox 360, we've got the PS4, we've got Apple Watch, we've got Android TV, we've got Macs, we've got glasses. Anyone buy Google Glass? Nope. Pretty standard. They're horrible. You've got a Net3no. So you can run it on microprocessors as well. So you can really run C sharp almost everywhere. Can anyone tell me the one thing that's missing here that seems a bit strange given that we've got a PS4 and an Xbox 360? Xbox One. Microsoft was the last company to get C sharp running on a console. We even have it running on a Wii as well. So it's madness. But anyway. But you can also run C sharp in the cloud. So the same C sharp, that base class library, all the code that you've already written and that you're sharing across all of your different internal projects. You can run in the cloud. So I can take the same C sharp and run it on a Net3no or on my watch and run it in app service, which I think is amazing. So before we jump into the code, I want to briefly just talk about the apps that I'm writing and how this talk kind of came to be. So I moved to Belgium, to Brussels in 2013, 2012, to go and drink beer. I told everyone that I was trying to impress that it was to learn Flemish and be cultural, but actually I just wanted to go and drink beer. So I jumped on the Euro star and I moved over there for seven months. And has anyone been to Brussels? Have you been to Delirium Cafe? Yeah. Well, Delirium is a family-owned recipe that's brewed by Big Brewery now. I'm a real beer nerd. But the family earned so much money from the big brewery to distribute it. They've got a couple of pubs in Brussels. And one of their most famous pubs is Delirium Cafe. And this is a bar that's in a basement with over 3,000 different types of beer. And can you imagine walking into a bar when you say, can I get the menu and they give you a book? And I'm not exaggerating. It's actually a book of beer. And it just names the beer, tells you the percentage, and then it tells you the price. Now me as a tourist for the first few weeks, I didn't know what beers I should be drinking. And the bar's always full because it's a tourist hotspot. Everyone's like, it's got 3,000 beers. We've got to go. So you can't get to Ars Abarman. Hey, what do you recommend? I really like Stella Artois because he's just too busy. And even if you said that, he wouldn't serve you anyway. So when I was in the UK preparing my liver for this trip, I was using an app called Untapped. Does anyone use this, Untapped? It's a hybrid app. It's built using Cordova. And the back end is hosted in AWS. And I think they use some like Redis Cache. And their infrastructure is very, very different to the way that I'm developing my app. But the biggest problem with their app is there's no offline capability. So there I am in Brussels, really excited to get into this bar and try some beers. And I go into the bar and they give me the menu and I'm going to use Untapped to find me some beer. Because it's got some recommendations. And I load up Untapped and it's like, eh, can't do anything. You've got no signal. I'll connect to the Wi-Fi. A pub without Wi-Fi, that doesn't exist, right? So I asked the barman, what's the Wi-Fi code? He said, you don't have Wi-Fi. So here I am in a cellar with 3,000 beers to pick from and I've got no idea where to start. So I was like, there's got to be a better way. I'm going to fix this. I'm going to write a beer app myself that has offline capabilities. So that's what I've been doing for a while in my spare time. It's based on Azure. So it's got an app service back end. I've just migrated from mobile service. It's got offline sync. We're using Azure Search so that we can do fuzzy matching and do spelling corrections and do hit highlighting. We can boost turn. So if you're in an area where a particular beer is trending, we can boost that in the search results for you. Yeah, we're going to be using machine learning as well to be able to make the predictions for you for what beers you're actually going to love. And when you do things like check in a beer, I even take your current location and then go and look up the weather conditions so that I can work out on a hot day. I really like Stella, but on a cold day, I love a Castile Donker. So that when you're asking, hey, what beers do you think I should drink, the machine learning can actually take into account the current weather that you're currently in in order to make that prediction. So it's pretty fun. It's all open source and it's on GitHub. And I'll quickly show you the project and then I'll show you the really, really, really simple version of it to show why Forms is awesome. So I'll just share my screen with you. No, no. Well, the beauty of it is that, you know, I don't have to wear money from this. Xamarin pays for all the expenses. So, I mean, Azure Search is 150 quid a month. It's the cheapest option. So if I roll that out throughout the world and I start to duplicate so that we've got performance around the world, you know, it's 150 quid per location. So I've only got it in Dublin at the moment, but I want it in Amsterdam. I want it on the east coast and the west coast. And I'm probably going to need one in Australia as well. I can probably miss out in the Middle East. I don't think I'm going to have a huge amount of app installs there. But, yeah, so it's 150 times the location that I want to go to and then you've got app service on top. But Xamarin just pays for it all. And my boss is quite happy because it's all on GitHub, so he doesn't mind what I'm up to. So I think it's great. But here is the main project. It's just for iOS at the moment. I've started on UWP because that's awesome. And I've got a friend working on the Android version. But it's a pretty big app. And as I say, it's all open source, but we'll get it running so you can have a look. I did break it whilst I was on the stand earlier. Sometimes, you would be amazed with what we can expense. Although I think, yeah, we're probably going to get audited soon, so I think that's starting to get strict on that. But you can see this hit highlighting. I'm using suggestions with Azure search. So as I type in a character, it's going to tell me. So I can be really, really bad at spelling. So golden drunk is a really nice caramel, 8%, maybe 9% Belgian beer. Delicious. And as a British man, when I'm drunk, I'm going to call it golden drunk because I'm drunk and I'm trying to over pronounce. And you would think if you're typing that in that you would type in golden drunk, maybe? You can see I made the spelling mistake and if I was using a link query to look this up in app service, go and find that equals, you know, named or equals this, I would never find these beers. But it's made the correction for me. This is a possible match. Yep, that is. So I can tap it and it does the real search and I get the proper results back. And I can tap on it and we can see that bug I was talking about. I broke it. That's scaling incorrectly, but I'll fix that afterwards. So it's 11%. So it's even stronger than I thought. But it's a delicious beer. It's lovely. And then I can check that in and it gets added to app service and we keep that in the future when we're using machine learning. So it's pretty cool little app, but this is traditional. So most of the code that you see here for the UI and bits, I'm not able to share any of this. Now, naturally, I've got ViewModels and Bits and Bobs that I can share and I've got an API client that I'm able to reuse across all platforms. But there's a lot of stuff like the list views that I should be able to share. This isn't terribly difficult for iOS or Android, but all the code I write is unique to those platforms. And to really show you that, I'll... In fact, let's do it in Visual Studio. Here's Visual Studio running out iOS designer. And this is an even simpler version of the proper beer drinking app. I call this basic beer, but this may actually... The forms version may be turned into a beer drinking light in order to get UWP support very quickly. But I've got a couple of views. I've got my navigation controller so that I can push and pop view controllers. I've got a list view. I've created a table. We've got an image. We've got a beer name. And then I go to a description. It's super simple. It doesn't get much simpler than that. But the code I'm writing, if we take a look at... I've got this UI table view controller because it's that one-to-one mapping to the iOS APIs. I have to inherit from that. And then I've implemented some of the events and I've got some pop-ups to show I'm loading. But I've got this data source. And the data source, again, is an iOS plus. So we'll go to declaration. Where did I actually define that? Here we go. So you can see I'm having to override. And all of this code is only for iOS. I can't use any of this code on Android or Windows Phone. And all it's doing is showing me a list of beer. I mean, let's run it on an iPhone simulator. And it will pop up down on the simulator icon. Tap down here. Hopefully. It is building. iOS builds tend to take slightly longer than Android on the whole. Just because we do that ahead of time. On the simulator, we don't actually do ahead of time. We can do it on the device. So it's really important. And this is a general thing. When you're developing in the simulator, you need to make sure before you ship to the device that you run on a physical device. Because the simulator has access to every single resource on my computer, which happens to be four cores and 16 gigs of RAM. Now, the iPad Pro is pretty good, but it still doesn't have four cores or 16 gigs of RAM. So you can write some really horrible code that will be really performant on the simulator. But it's going to run horribly on the actual device. So there we go. I can search for a beer, do val, boom, we've got the beer result come back, and I hit go forward and we're good. But I'm not sharing any of this code. And if I type in golden drunk, even worse, because I'm not using my Azure search, it's actually not going to return the beer I want. It's returned beers, but none of the beers I want. Because it doesn't have that fuzzy matching. It's horrible. If you look here, we've got 122 lines excluding white space of, or including white space, of code just to be able to populate that table view. 122 lines of code. Now, I want to show you Xamarin Forms. Because Xamarin Forms makes this a trillion times better. So with Xamarin Forms, we've looked at our developers and we've seen that they're reinventing these views for all the different platforms. They want to have a list view or maybe a map view, such as here. So Apple Maps for iPhone, Google Maps for Android, and then Bing Maps for Windows Phone. They all do the same thing. You get a location, you drop some pins. But the API is really, really different across all of these platforms. And we thought it was mad that you couldn't have a common API across all of them. So just like with the traditional approach, we've got the shared T-Shark backend, which is about 75% of your app, and then you've got that 25% that's unique to the platform. We can actually bring up the amount of code that we share, because now we're able to share our UI layer as well, or parts of our UI level. So in a best case scenario with Xamarin Forms, we're looking at a 99.9% cross-platform app. So your code is 99.9% cross-platform, and that 0.1% is just code that's unique to each platform project to get it started. So we need to initialize Xamarin Forms on iOS. We need to initialize it on Android and UWP. But all of the code that you write is in a possible class library or a shared project, and we can just run that everywhere. So iOS has 33,000 APIs, and Android has 40,000 APIs. Plus, these are increasing with every new version of iOS and Android. So that's a lot of APIs for you to learn and to take advantage of. So Xamarin Forms tries to abstract some of these away from you so that the common things across all of the platforms, you just have one API to learn. But it is worth learning some of these APIs that are unique to the platform in order to start customizing. I'm actually going to show you a custom renderer as we finish, which is, I think people call it an advanced subject for Xamarin Forms, but it really is an advanced, and you'll see just how easy it is a little later. So Xamarin Forms allows you to quickly and easily build 100% native apps, just writing it once. And you can mix and match Xamarin with these native APIs. So as I say, with the custom renderers, we can drop down from this high-level abstraction into the native implementation, and so we can get access to every single API that we want. My colleague, M Hutch, has actually written a library, which we're still not sure if we're going to be allowed to release properly, but it's a library that allows you to say, hey, Xamarin Forms, give me this button on iOS as a native type, and it will just give you straight back a UI button. And at that point, you have access to every single control that a UI button has. So you don't even have to go into custom renderers. So it's even more customizable within the possible class library. And that's truly magic. The key point with the mix and match is that you're not limited by Xamarin Forms. Although it's a abstraction API when you need to start customizing and jumping down into the lower level, we've got you covered. So what's included? You get 40 pages layout controls. You can build this from code. So in C sharp or S sharp or XAML, you guys must be XAML developers because you use WPF, right? So who here is a XAML developer? You use WPF without XAML? Wow. Interesting. Well, if you're a XAML developer, you'll love Xamarin Forms because we absolutely support it, which naturally means two-way data binding. And is anyone here used NVVM? It's pretty awesome. If you've not used NVVM, it really feels like cheating. It takes a lot of the boilerplate code that you would be writing to send events from the UI back to storing it in data and vice versa. You update your view model and you want your UI to update. We give you consistent navigation and animation API across all three platforms. And we give you a dependency service which allows you to drop down into that lower level when you need to. And on top of that, we give you a messaging center. And the messaging center allows objects that have no idea about each other to communicate with each other so that you have really decoupled code. So it makes unit testing really easy. So we have a couple of pages that we give you by default. You get a content page, master detail navigation tabs in Carousel. You'll do most of your work in a content page, to be perfectly honest with you. You'll sometimes throw a content page within a tabs page so that you can have tabs. And tabs are an interesting example within Xamarin Forms because on iOS they live at the bottom, on Android they live at the top and on Windows Phone they become a Carousel. Now, you don't have to specify the layout for that within Xamarin Forms because we're just creating the native type. The OS will lay that out for us. But if we want to get into layouts within our content pages, we've got a couple of options. So we've got stack, absolute, relative grid, content view, scroll view, frame. I do 90% of my work in a stack view. Because a stack view is a managed layout. Things like the absolute isn't a managed layout. So with absolute you can have to do way more calculations of how you move things around and how you scale depending on the device size. With a stack, we do a lot of that for you. So with stack you can just throw view items into the stack layout and present that on the screen and it's going to look great no matter what size device you're running on. We give you a couple of controls out the box. These are the controls that we've mapped that we found were common across all the platforms. But there are so, so many third party controls now. It's unreal. If you go on to new get, you'll find that the community is just endlessly adding to this list. So the community fills in this blank space. You can fill in this blank space using those lower level APIs when you want to get access to them. And you can even go so far as buying controls from people like infragistics or Syncfusion. So you're not limited just to what we give you. In terms of the XAML, although we don't have a huge amount of XAML developers in here, to the 2009 XAML specification, we're pretty similar. So if you've already done XAML development before, you'll feel right at home within Xamarin.Forms. There are a few new keywords that you'll need to learn, but apart from that, you'll understand the basic idea of how you can get started within Xamarin. So let's actually have a look at some forms code. I'll open up the project within Xamarin Studio. Yeah. Well, the specification is pretty loose. You would think as a spec it would be nailed down, but it's quite airy-fair in areas, which is how we've been able to extend it to work across all three platforms. So, yeah, it's... The key thing is if you already know the approach to NVVM and XAML and how you do the data binding and create your view models, you're going to find Xamarin.Forms really easy. In this example, and this is all on GitHub, everything you see code-wise today is on GitHub and you can download it right now, I've actually got within this project two different types of view. So I've got the XAML view and then I've got a code behind view to show... Because often I'll talk to a room and there won't be any XAML developers and I just want to see C sharp. C, C sharp. So I want to show you from the very top. So if I created this in Visual Studio, I would actually have four projects within the solution, so I'd have a Windows phone option as well. Now, we've got UWP support in preview and we've had a lot of success with customers rolling out UWP apps that they've built with forms. And all they had to do was add a new project, which is a UWP project, download a new get package, which is Xamarin.Forms, add that couple of lines of initialization and it was all done. They've built their app already. So the main part of your application is going to live in this portable class library. And this is all your views, your view models, maybe your business logic, some of your models, although you might have those in a separate portable class library that you bring into this as well. But the Droid project and iOS project and Windows phone project really don't need to have a huge amount in them. If we take a look at the iOS project, we have this app delegate. Now, an app delegate deals with the application lifecycle on iOS. Now, we've got this, we override this finished launching method, which is exactly the same as the standard iOS app. So lifecycle would happen within the app delegate. But you can see that we init Xamarin.Forms. Now, we write this code for you. And this is that bit with 0.1% that isn't cross-platform. It's unique to that device or platform in particular. But we write it for you, but it is there. So there's a general rule when you're doing Xamarin.Forms, you can just close their projects and not really need to look at them again. Whilst we're here, we'll fire up that. If we come into the portable class library, we have our entry point, which inherits from application. So just like with iOS, we've got our app delegate, which inherits from UI application delegate. We inherit from application here. And I've got a property of app or property of the class, which is main page, which I can set to be a content page. But in this case, I'm setting it to be a navigation page, which is like the navigation controller, so it allows me to push and pop without the app crashing. And there I'm adding my search page. Now, the search page is the page that I built using XAML. So let's take a look at that. Boom. And the search page is the page where we do the search and we show the list of results. Can anyone remember how many lines of code that was to do in the traditional version? 120? Yeah, it was 122, to be exact. Very good. So we've taken 122 lines of code that are unique to iOS. And now we're doing it in XAML in forms, and we've got the UI down to 19 lines of code. Now, I do have a view model, which is where most of this magic is happening, because you can see, you know, when I change text, I'm going to update the search term within the view model. I've got search beers command. So when I press the search button, I fire a command off in the view model, and that's some of the heavy lifting to go back and populate this list view. So let's have a look at the view model. There's nothing particularly exciting about the view model. It is just generic C sharp. Obviously, I've imported some Xamarin forms namespace in order to get access to R command type. But it really is just if you've done NVVM, it's just generic NVVM approach. There's nothing really magical about this. So if I run this, let's see, we'll run it on Android first. Perfect. I selected the wrong device. So this is our Android emulator. It's actually not emulating anything. It's x86, so it's hardware accelerated. It's super fast. It starts in about 17 seconds. So does anyone use the default Google emulator? Congrats for getting here today, because it's probably still starting. It's horrifically slow. It takes about a minute and a half, two minutes to go from nothing to being useful. Perfect. What more could you want? Let's have a look. I'll try Kit Kat. I was going to show you this all in Visual Studio, as I mentioned to you earlier, but I bravely decided to update my Android SDK when I was on the stand. When you update your SDK 20 minutes before you go on stage, you're guaranteed to break something, and it broke everything. So that's why we're sporting Xamarin Studio here. We'll try that again. It's going to install the app. When Android the first install takes a little while because we installed a shared runtime. The shared runtime is used by all of the other Xamarin apps that are in debug. If you build a release app, it's going to bundle the runtime with your application. We link it so it's really small, but we'll bundle it so that the runtime doesn't change from underneath you, because we don't want the next app to be installed to use version 2 of the runtime and you were using version 3 and now your app doesn't work. We'll always bundle it. After we link it with beer drinking, and I've already told you just how much that's doing, it's about two megs. It's about the same as a high-quality image. Our link is incredible, to the point where it can almost overlink, and when I say almost overlink, it does overlink in certain situations, especially if you're using generics, it will start ripping stuff out and then your app will crash because it can't find the type. You have to sometimes tame our linker in order to not get rid of everything. A linker tamer, yeah. It's more difficult than a lion tamer. We can see the Android app here. It's pretty hard to see because of the Android theme, but I'm going to search for dovel again. Dovel being a Belgian beer that's pretty strong, and then we've got the results. I'm loading the images, I think, so I'm not locking up the UI thread, and I can come in here and I can tap on the beer, and again, I get the results and I get an image at the top. Now, the image has a circle around it. The default image I get back from BreweryDB, which is a database, just comes back as square. I'll show you how I created that circle in a moment. You can see it's a pretty ugly app, but I've not spent any time on theming this. I could go into the Android project and update the theme, I could change the colors, I could really design this to look lovely, but I wanted to show you just out of the box, file new project style, what we get with very minimal amounts of coding. Let's see how this looks on iOS. We'll set a startup, and we'll run that again. The same code is going to run on iOS as the Android version, so it's still not going to look beautiful, so I've done no custom styling. There we go. Then I'll search for dovel again, it gets the text faster than the images. We also cache images as well with Xamarin forms for you, so that you're not constantly going and downloading that, which is pretty nice. There we go. We've got the results, and it's exactly the same code. I could then go ahead and run this on UWP, so I could have the same app without any modification running on an Xbox. I get this running on a HoloLens, if Microsoft would give me one. I've not made any modifications to the project, I just have to hit rebuild, and I'm good to go. That's the real power of Xamarin forms, that as new platforms come out that are exciting, we can make sure that we're on them. If we all go out tomorrow and buy a BlackBerry, you can be guaranteed that Xamarin is going to make sure that we support the BlackBerry. I don't think BlackBerry is ever going to take off again, so I don't think that will happen, but if it did, we would be there. When I click here, interesting, there we go. When I click here, we've got the square image, because I've not implemented a custom renderer for iOS. On Android, I said I want to be, within my view, when I'm displaying this, I want it to be a circle image, and in order to make that a circle image, I had to drop down into the native API in Android to implement that. I'll show you the implementation, custom renderers. Has anyone developed for Android before? Android is a beautiful disaster of an operating system. It shouldn't work, because it just shouldn't, but it does. Somehow Google make it work. As a user, it's a really, really nice OS, but as a developer, it's pretty horrible. You can kind of see this between the difference between how to crop a photo in Android, which is this code, which is pretty damn nasty, versus if we look at the iOS equivalent, you know, much, much simpler. So the key thing here is this custom renderer. I'm exporting a renderer. It's a type of image circle. Image circle is a type within Xamarin, within Xamarin forms. I've got this method, which is create circle. If I uncomment this line of code, we'll actually then be calling into this method to do that cropping. We'll rerun that. While we're running it, we'll pop in here. We'll see that I create a new image circle. If I don't provide a concrete type for image circle on iOS or UWP, because I'm inheriting from just a standard image, Xamarin forms is intelligent enough to say, well, this should just be a normal image. He doesn't have an implementation for iOS, so we'll just give him a normal image for you. Does that make sense? So you don't have to go ahead and implement each platform if you don't want to. If you only want to customize for Android, just do it for Android, and you're good to go. We'll search again for Stella, which is a Christmas beer, first brewed in Lervon. There we go. We've got the circle because we've cropped it. That's custom renderers. When you talk to Xamarin developers that are using forms, when they very first start out, they're often scared to take advantage of the custom renderers because they see it as scary to drop down into this platform Pacific APIs, but it's really, really simple. There's nothing too intimidating about using a custom renderer, and it allows you to take advantage of those 33,000 iOS APIs or the 40,000 Android APIs. You have access to everything when you're dealing with the renderers. So in November, we announced version 2 as Xamarin forms. I wanted to stand here and tell you a long list of features that version 2 adds, but version 2 is very much just stability. So version 1 as Xamarin forms was something that took off in a way that we 100% didn't expect. We initially called Xamarin forms Duplo when we developed it, the project name, because we expected it for childishly easy apps to build. But people were just like, this is amazing. I can use Xamarin and write it everywhere so I'm going to. They pushed it and pushed it to the extreme and we're always trying to catch up. We think we're at a point now with version 2 where we've caught up to what developers expect of it because, as I say, they used it in a way we didn't think they would. So we're at a point now where we're stable. We've got lots of big customers using it and we're very happy with it. So version 2, I only add a couple of features, but the list of bug fixes is huge. One of the most interesting features of version 2 is we now do compiled XAML. It was one of our most requested features from developers. Our XAML interpreter is actually incredibly fast, so there's not a performance increase when you're using the compiled XAML instead, but people wanted it so we gave it to them. If you want to learn more about Xamarin, we've got numerous options, but we also have a conference in Orlando. Has anyone been to Orlando? Well, you should go again because you know how lovely it is, especially in April. Yeah, so it's end of April. We have two days of training, which is the Danu Instructors, our university instructors, and they're genuine experts on so many different technologies and they'll be standing on stage and teaching you about everything from garbage collectors to cell reuse on Android. You can get one-to-one with engineers as well. So if you've got a problem, a bug in your project, you can sit down with Miguel, who's our CTO, and he'll sit there and code review for you and tell you that you're a great programmer or a terrible one, depending on your code. So it evolved pretty awesome. And after the two days of training, we then go on to the conference, which is I think two or three days of just having fun and learning about loads of different tech. We've got this great thing, which is the Darwin lounge, and this is going to be even bigger, but we have drones flying around. We've got an Oculus Rift. We have mini hacks, and we've got the experts on hand. And if you do all the mini hacks, you win prizes, and the prizes are actually worth trying to win. Hence why we've got so many people trying to win them. Once you've bought your ticket, everything else is pretty much paid for. You get your breakfast, your lunch, we'll take you out for dinner to some lovely places. Last year, we went to, we had an old train shed that we put loads of amusement arcade stuff in it as well, and we had all the local experience. We're in Georgia. We had loads of barbecue places come along, and we had ribs, and it was lovely. And then the next day, we were at the aquarium, and it's just, it's loads of fun. So highly recommend it. If you've got a training budget that you've been allocated for the year, and you're thinking of a fun way to spend it, just saying. So I've been Mike James, developer evangelist at Cameron. I write loads of apps, and I write them all in C sharp. They're all on GitHub, apart from Hydrate. That's not on GitHub because it's really horrible. So don't use that. But it's my only OS 10 app, again built entirely in C sharp. So thank you very much. Do we have any questions? I realize I've kind of just dumped my brain out to an audience for 14 or five minutes. I would be quite fried by now. No questions? There's always a couple of questions. Perfect. Let's go and get coffee then. Thanks, guys.
 you  you .  You couldn't get any already compiled binaries, you would have to build it yourself. I'm not  sure if anyone's built Q from scratch. It's a pretty lengthy process, right? It's not a  quick thing. You start at night, you come in the morning and if you're lucky, it may be  built. They were releasing Nightly Builds, it was horrible. There was no way I could  use Q to build a mobile solution. We were across platform shop, I couldn't go ahead  and write a mobile app for the guys using Objective C. It's not cross platform, we can't  use this. I did something horrific. I used jQuery mobile. I used a built-in web server.  It's got the rest of the API. I would ask what lights are on, what lights are off, can  I start firing some effects, I can make it do a rainbow. I made a nice little UI using  jQuery mobile. Then we tried to scale that out to other installations. The Westfield  shopping centre in Stratford, all of their exterior lighting, it's all static now because  they didn't actually get planning permission, which is genius. All their exterior lighting  is intelligent. They wanted to walk around with an iPad and control the lights. They  could select a tree and say I want this tree to be red. It would magically be red. I was  using jQuery mobile again. I sat in sublime text writing HTML and JavaScript and sometimes  a bit CSS. We would ship the app to them. They would actually just put it on a memory  stick and shove it in the side of the LPC. We would then connect from our phones onto  the device. That app got so complicated because they wanted real-time colour selection. I  had to build a colour picker in JavaScript. It was nasty. When you would move around,  we would sometimes doff the box with so many messages that we want to send so many updates  that it would just die. Or we would send too many people with connect at once and it would  just die because it's only a tiny alarm processor. The app was horrible. It most likely killed  the device at least once a day. There's got to be a better way. I was sick and tired of  writing JavaScript and HTML. I wanted to get back into a real IDE. I had two options. Option  one was to go into work on a Monday and hand in my resignation and say, Simon, I'm out.  I cannot do this anymore. I want to use real programming tools and I want to use a real  programming language. Or I can find an alternative to this horrible solution. On the Friday,  I went home and I sat there contemplating, write my letter of resignation or find the  alternative and I opted to just do some Googling. I thought, what's the ideal situation here?  I want to be able to run.NET on an iPhone. That's all I typed into Google..NET on iPhone.  Xamarin was a top link. This was three or four years ago. I'm not sure if anyone used  Xamarin back then but the website was really horrible. We looked very amateur. The company  was about 30 people. It was really, really small. They were only about a year old at  that time. It was very amateur. I was like, I'm going to give it a go. I pulled out my  credit card and I bought a pizza because no good programming project starts without pizza.  When the pizza arrived, I pulled out the credit card again and bought a license to Xamarin.  Over the 48 hours of my weekend, I just sat in my room and I hacked and I hacked and I  hacked. By the end of it, Monday morning, I had 100% native iOS app built in C sharp.  But a portable class library that I could reuse across Android and Windows phone and  all of the other platforms that we might want to target in the future. I rock up to work  with really cocky on the Monday morning and I say, hey, Simon, I built us an app and it's  a proper app this time. Let's have a look. I pull out my phone and I hand it to him.  There you go. I'm feeling pretty smug about it. He looks at it and says, yeah, we can't  use this. What's the problem? He says, well, you built it with Objective C. I was like,  I haven't. I know it's native but I can still share a lot of this code. I showed him and  he was blown away by what I had done with Xamarin. About a week or two later, I applied  for a job at Xamarin and I left Pharros. He wasn't most pleased about that. That's my  story of how I came into Xamarin development. I had gone down a hybrid approach and I found  a limiting factor pretty quickly. I knew I needed to go mobile and I don't want to write  my code three different times. I don't want to write it for Windows and then for Android  and then for iOS because that's mad. Today we're going to talk about how you guys can  avoid that technique of reinventing the wheel and how you can use Xamarin to write once  and run anywhere. That's the Xamarin platform. We also have a couple of other products. Was  anyone in the earlier speech by Carl? He works for our test cloud team. For those of you  who don't know, test cloud is a product where you built your app, you tested it with your  unit test and you're like, we think it's rock solid. We've tested it on about four or five  Android devices. We've got coverage. We'll ship it. We're excited to get this out. You  ship it off and then you get app store reviews saying it don't work. They never give you  a stack trace. They never give you details of how to reproduce it. They never tell you  exactly what's wrong. So you end up basically asking your users to test the app for you.  With Android, this is really important because there are 17,000 different varieties of Android  which is quite a lot for you to test on. Who here is actually testing more than 100 devices?  More than 50? More than 25? We're going to do this. Come on. Someone's going to have  to raise their hand at some point. More than 10 devices? 10? About 10? Okay. More than  25? This is still really bad. More than two. Come on. Okay. Do you guys write software?  This is a problem. Most people aren't testing their apps properly. They write the app, they  side load it onto their device and then they go, well, it works here. If I could get a  pound for every time I went onto bugzilla and I found the developer wrote, it works on my  machine. I wouldn't have to work. The reality is when we're testing on our devices, they're  not normally set up in exactly the same way as our customers are using. Our customers  will install some really horrible things, especially on Android. So it's really important  to test. So with test cloud, the idea is you build your app, it's lovely. You think you've  got it rock solid and we'll prove it by running it on over 2,000 physical devices in our warehouse  in Denmark. So you literally upload your app to a device and we've got a test runner which  will start tapping buttons and swiping and we take photos at every step and we let you  see every single step of the application. So when you tap on a button, you want to go  to the welcome screen. Boom, there's a welcome screen. We'll take a picture. The welcome  screen doesn't load, we're going to tell you instantly. We're going to send you a message  and say, hey, the welcome screen didn't load on this device. You might want to look into  that. So that's a pretty cool product. The test cloud guys, we've got two of them here  today. So if you want to learn more about test cloud and how you can integrate that  into your release system, then do come and find us on the stand. We also have Xamarin  insights which is our analytics and crash reporting tool. This became into general availability  just in November, but we've had it in preview for what feels like forever. But it's now,  you know, we're pretty happy with it. We're at the point where we're happy to charge for  it. But we have a free tier which allows you to catch any uncalled exceptions and we'll  report them to the cloud. Now, we do re-throw them. So we're not just going to consume exceptions  for you. We'll catch them, report them and re-throw them. But that allows you to very  quickly find out where your app is crashing. So rather than, you know, just getting the  app store review that say it don't work, you can go on to insights and you can find the  exact user and see the crash that they had and have the stack trace. So then you can  go into your project, find the line of code where you have the issue and make the fix.  And if you're using test cloud, then you can update your test, upload the new app with  a fix in it, going through the processes that the original reporter of the issue went through  and then you can say, yeah, this works lovely. And then it's all underpinned by Xamarin University  which is our online course. But I won't talk about that if you want to learn about that  and you talk to me afterwards. So what is native? There are three parts of what I would  describe as making a native app. There's native UI. So what I don't want is, you know, the  Qt version with Qt 5, they can build native apps and I'll tell you it's a native app.  But actually in terms of what you're looking at on the screen, they're drawing every single  pixel. So it's not really a native UI. It's Qt's interpretation of what a UI should look  like on an iPhone, on an Android and on Windows phone. You're not going to get a UI button  or a UI table view controller. You just get their version of. If you go with hybrid, you're  just wrapping a website. So again, it's not a native UI. Somebody has very talented CSS  coder and created some CSS that makes a button look similar but it's not a native button.  There are some differences when you do long taps and long presses and you're swiping from  views of you. On hybrid, it often doesn't look quite as slick as a native UI.  Underneath that is API access. If I can't access 100% of the API is available to me  on a particular platform that I'm trying to target, I don't qualify that as a native  solution. I want to be able to have access to every single API that the objectives see  Swift or Java developers have access to. When Apple comes out with a new API such as 3D  touch, I want to be able to implement that in my app. The hybrid guys and the guys using  Qt and the other competing frameworks that aren't native aren't able to do that. And  then native performance. I'll talk about performance a little later. Mobile users aren't sat at  desktops where they can wait 30 seconds to a minute for something to load and you can  lock the UI thread and they'll just accept it. Mobile users expect really high-quality  software that's really performant. It's often that they're in a queue in Starbucks and they  just pull out their phone and they're going to tweet and they're going to check Reddit.  If they pull up your app and it takes too long to load in the data or even just load  to the first screen, they're going to quit and move on to the next app or order their  latte with vanilla, whatever the hell they want. There are a few approaches to developing  mobile apps. I've already mentioned the hybrid approach. We have the siloed approach as well  which is what I mentioned earlier where you reinvent the wheel for each platform. You  write it once in Objective C or Swift if you're really modern. Has anyone used Swift? It's  quite nice. I quite like it. It's like F sharp version 1, but it's still quite nice. If you  really like Swift, check out F sharp. You've written it for iOS. It's huge success. You're  earning loads of money. You're like, let's get our app to be the number one pirated app  for Android. We'll write it for Android. Boom. We'll use Java. I want to hit Windows  phone. I want to UWP. You reinvent it again for using C sharp in Visual Studio. Now you've  got three different code bases, three different IDEs, often three different teams depending  on how big your company is, all developing effectively the same app. Not showing any  code. This is a pretty mad approach to developing mobile applications, but it's really easy  to fall into this approach. Is anyone using this approach today? No one? Is anyone here  developing mobile apps today? Okay. Websites? Perfect. Silverlight? I guess that in a website  kind of. WPF? Awesome. So we're all.NET developers. Great stuff. Okay. So if no one's using this  approach, that's great. Just don't use this approach. So the Xamarin approach is unique  because we're saying we're still going to have a native user interface. We're going  to have that native element, the native performance, all access to the API. And we're going to  do that by having one-to-one bindings and we're going to create our user interface using  those bindings and using the UI buttons, the UI table view controllers for iOS. We'll use  a table and a button for Android and the same for Windows. It's a native type. And we're  going to share all the boring bits of our application. So this is all the models, all  the business logic, all the respal calls, all the data persistence, all the bits that the  users really, really don't care about. Because they only care about that top 20%. The APIs  that are unique to them, the peak and pop on iOS, the searching, all of the lovely features  that Apple give us and Google give us within the OS. That's what they care about. They  don't care about this bit. So you can write your code once in C sharp and we'll share  it across all of the platforms. And because it's C sharp, we can run it really everywhere.  So not only can we run it on iOS, Android and Windows phone, but we can go ahead and  run it on Linux using Mono or we can run it in Azure as well. And do we have any F sharp  developers in the room? Okay. Well, maybe you in the future. This time next year. We  also support F sharp. F sharp is a first class language for us. Our design team are actually  all developers as well. And they love F sharp. So we've got top notch support for it within  Xamarin. Everything you see me talking about today is applicable with F sharp as well. I'm  just not intelligent enough to use it. I can read it and it's lovely. When I debug F sharp,  I'm like, wow, this is magic. But then when I try and write it, I'm like, can't do it.  Too hard. So just like when Microsoft give us some new APIs and we've got that base class  library, so all of the namespaces and in turn classes we've been using for years, system.link,  system.x now, the stuff that we used to, our bread and butter, they give us some new APIs  and we're like, meh, we've got this. We understand it. There's nothing too new here or too scary.  We're just going to build on top of our existing knowledge. Well, we've done the same with  iOS and Android. So with iOS, as I mentioned before, we've got that one-to-one mapping.  So every single API, the Swift and Objective C developers have access to, I have access  to as well in C sharp using Visual Studio. So I can use resharper on this code as well,  which is amazing. So we have access to things like UI kit, map kit, iBeacons, every single  API, it's 100% coverage. And then we did exactly the same for Android. So again, all the base  class libraries, all the stuff you know and love. And then on top of that, a one-to-one  binding to every single API that Java developers have access to. So Xamarin.embrace and extended.net.  Has anyone peered in votes to a native library before? One couple? Okay. So that's basically  what we're doing. I mean, if you strip away our nice designer and all the build tools  that we use and all of the extra fluff that make using Xamarin a pleasant experience,  you pull that all away and actually look at what we're giving you, it's a wrapper. It's  just a wrapper to allow you to peer invoke into these native libraries, which is how you  get that native app. It's how you know, instantiate the native controls because it's just a thin  wrapper. So if you've done peering, you understand the core of how we work. So there isn't any  magic here. It feels like magic when you run C sharp on an iPhone. You're like, yeah, this  can't be right. But it's not magic. And I wanted to talk about performance. Performance  is really, really important with mobile. And there's two sides of the performance story  with Xamarin. On iOS, we have to do ahead-of-time compilation. This is a rule from Apple. They've  said that they will not allow any apps on the app store that are jitting. So we can't  jit. So we have to do the ahead-of-time compilation. So what that results in is that you'll build  time when you want to release to the actual physical device. It's a little bit slower.  But we can do a lot of optimizations with the ahead-of-time compilation. So we use things  like a linker to strip out all the files you're not using to bring down the overhead of using  mono and our runtime down to an absolute minimum. We feed the... We take the IL, so the C sharp  goes down to IL, just like your WPF apps or your WinForms app. We take that IL, we convert  it to a bytecode that we can feed through the LNVM compiler, then at the end of it we  get the native ARM assembly. So we don't lose any performance using Xamarin for iOS. On  Android, we can jit. So we tend to jit on Android. We do have an ahead-of-time option  for Android if you want to go down that route. You're not going to see a huge performance  increase if you do that. But Android tends to be faster using Xamarin than if you had  used the Delbit and used Java. So we've got some benchmarks. And these were produced by  an ex-Googler. You can go and check out the link if you'd like. He was an early Google  employee. He now owns a racing car team. So he did very well out of his stock options.  And he likes to write apps now for his team. And when he was looking to write the mobile  app, he went and he compared all of the options. And he's looked at a lot of competitors for  us. And he's benchmarked them. And then he put it online and naturally he put it on GitHub  and said to all the other developers that were saying, well, you know, I can improve  this switch code. I can improve this objective C code. He's like, please do. Send in a pull  request, I'll rerun the test and we'll update. We want the best information. So he's done  that. And this is always, you know, improving. But you can see here that, you know, we're  a little bit slower than Swift. But we're looking at less than a second anyway. So it's  pretty performant anyway. But we tend to be faster than objective C. And the reason for  that is objective C is a pretty difficult language to write in anyway. And because of  all the messages, it's pretty hard to optimize that. So Xamarin, you're not going to have  a performance loss for using Xamarin iOS and C sharp compared to objective C. So there's  nothing to worry about there. On Android, as I say, the story is a bit different on  Android. We tend to be faster than Java. Again, you can see we're so close to Java in terms  of performance that we're only fractionally faster. So your users are never going to be  like, wow, they must have rewritten this in Xamarin. It's so much more performant. No  one will ever say that. But you're not going to have your users waiting around forever  for something pretty trivial to happen as if you were using titanium, for example. So  anything you can do in objective C, Swift or Java can be done in C sharp using Visual  Studio. And that's really key. We're built into Visual Studio 2015. So you don't have  to go to our website and download extra bits and bobs to get us installed. As long as you've  installed everything with Visual Studio, you selected that cross-platform development  option. We're in there by default. And C sharp runs on 2.6 billion devices. When I worked  for Faros and we were building the cross-platform software, C++ was really the only option for  us to do cross-platform in a reasonable language. And now I kind of feel that, you know, if  I had to build a cross-platform app, I would never use C++ because I'm not building real  time apps. I don't need that level of performance. C sharp gets me such good performance that  I can use C sharp and not have to deal with the nastiness of using C++. Now, I love C++  and don't get me wrong, but I'm much, much nicer to program in C sharp. And I want to  show you some of the devices that C sharp runs on. I'm not going to try and list them  all because there's quite a lot. This is the ugliest slide I've ever produced just in case  you're wondering. It's designed to be a little ugly. I think that's it. So we've got Android  devices, we've got Xbox 360, we've got the PS4, we've got Apple Watch, we've got Android  TV, we've got Macs, we've got glasses. Anyone buy Google Glass? Nope. Pretty standard. They're  horrible. You've got a Net3no. So you can run it on microprocessors as well. So you can  really run C sharp almost everywhere. Can anyone tell me the one thing that's missing  here that seems a bit strange given that we've got a PS4 and an Xbox 360? Xbox One. Microsoft  was the last company to get C sharp running on a console. We even have it running on a  Wii as well. So it's madness. But anyway. But you can also run C sharp in the cloud.  So the same C sharp, that base class library, all the code that you've already written and  that you're sharing across all of your different internal projects. You can run in the cloud.  So I can take the same C sharp and run it on a Net3no or on my watch and run it in app  service, which I think is amazing. So before we jump into the code, I want to briefly just  talk about the apps that I'm writing and how this talk kind of came to be. So I moved  to Belgium, to Brussels in 2013, 2012, to go and drink beer. I told everyone that I was  trying to impress that it was to learn Flemish and be cultural, but actually I just wanted  to go and drink beer. So I jumped on the Euro star and I moved over there for seven months.  And has anyone been to Brussels? Have you been to Delirium Cafe? Yeah. Well, Delirium  is a family-owned recipe that's brewed by Big Brewery now. I'm a real beer nerd. But  the family earned so much money from the big brewery to distribute it. They've got a couple  of pubs in Brussels. And one of their most famous pubs is Delirium Cafe. And this is  a bar that's in a basement with over 3,000 different types of beer. And can you imagine  walking into a bar when you say, can I get the menu and they give you a book? And I'm  not exaggerating. It's actually a book of beer. And it just names the beer, tells you  the percentage, and then it tells you the price. Now me as a tourist for the first few weeks,  I didn't know what beers I should be drinking. And the bar's always full because it's a tourist  hotspot. Everyone's like, it's got 3,000 beers. We've got to go. So you can't get to  Ars Abarman. Hey, what do you recommend? I really like Stella Artois because he's just  too busy. And even if you said that, he wouldn't serve you anyway. So when I was in the UK  preparing my liver for this trip, I was using an app called Untapped. Does anyone use this,  Untapped? It's a hybrid app. It's built using Cordova. And the back end is hosted in AWS.  And I think they use some like Redis Cache. And their infrastructure is very, very different  to the way that I'm developing my app. But the biggest problem with their app is there's  no offline capability. So there I am in Brussels, really excited to get into this bar and try  some beers. And I go into the bar and they give me the menu and I'm going to use Untapped  to find me some beer. Because it's got some recommendations. And I load up Untapped and  it's like, eh, can't do anything. You've got no signal. I'll connect to the Wi-Fi. A pub  without Wi-Fi, that doesn't exist, right? So I asked the barman, what's the Wi-Fi code?  He said, you don't have Wi-Fi. So here I am in a cellar with 3,000 beers to pick from  and I've got no idea where to start. So I was like, there's got to be a better way. I'm  going to fix this. I'm going to write a beer app myself that has offline capabilities.  So that's what I've been doing for a while in my spare time. It's based on Azure. So  it's got an app service back end. I've just migrated from mobile service. It's got offline  sync. We're using Azure Search so that we can do fuzzy matching and do spelling corrections  and do hit highlighting. We can boost turn. So if you're in an area where a particular  beer is trending, we can boost that in the search results for you. Yeah, we're going  to be using machine learning as well to be able to make the predictions for you for what  beers you're actually going to love. And when you do things like check in a beer, I even  take your current location and then go and look up the weather conditions so that I can  work out on a hot day. I really like Stella, but on a cold day, I love a Castile Donker.  So that when you're asking, hey, what beers do you think I should drink, the machine  learning can actually take into account the current weather that you're currently in in  order to make that prediction. So it's pretty fun. It's all open source and it's on GitHub.  And I'll quickly show you the project and then I'll show you the really, really, really  simple version of it to show why Forms is awesome. So I'll just share my screen with  you. No, no. Well, the beauty of it is that, you know, I don't have to wear money from  this. Xamarin pays for all the expenses. So, I mean, Azure Search is 150 quid a month.  It's the cheapest option. So if I roll that out throughout the world and I start to duplicate  so that we've got performance around the world, you know, it's 150 quid per location. So I've  only got it in Dublin at the moment, but I want it in Amsterdam. I want it on the east  coast and the west coast. And I'm probably going to need one in Australia as well. I  can probably miss out in the Middle East. I don't think I'm going to have a huge amount  of app installs there. But, yeah, so it's 150 times the location that I want to go to  and then you've got app service on top. But Xamarin just pays for it all. And my boss  is quite happy because it's all on GitHub, so he doesn't mind what I'm up to. So I think  it's great. But here is the main project. It's just for iOS at the moment. I've started  on UWP because that's awesome. And I've got a friend working on the Android version. But  it's a pretty big app. And as I say, it's all open source, but we'll get it running  so you can have a look. I did break it whilst I was on the stand earlier. Sometimes, you  would be amazed with what we can expense. Although I think, yeah, we're probably going  to get audited soon, so I think that's starting to get strict on that. But you can see this  hit highlighting. I'm using suggestions with Azure search. So as I type in a character,  it's going to tell me. So I can be really, really bad at spelling. So golden drunk is  a really nice caramel, 8%, maybe 9% Belgian beer. Delicious. And as a British man, when  I'm drunk, I'm going to call it golden drunk because I'm drunk and I'm trying to over pronounce.  And you would think if you're typing that in that you would type in golden drunk, maybe?  You can see I made the spelling mistake and if I was using a link query to look this up  in app service, go and find that equals, you know, named or equals this, I would never  find these beers. But it's made the correction for me. This is a possible match. Yep, that  is. So I can tap it and it does the real search and I get the proper results back. And I  can tap on it and we can see that bug I was talking about. I broke it. That's scaling  incorrectly, but I'll fix that afterwards. So it's 11%. So it's even stronger than I  thought. But it's a delicious beer. It's lovely. And then I can check that in and it gets added  to app service and we keep that in the future when we're using machine learning. So it's  pretty cool little app, but this is traditional. So most of the code that you see here for  the UI and bits, I'm not able to share any of this. Now, naturally, I've got ViewModels  and Bits and Bobs that I can share and I've got an API client that I'm able to reuse across  all platforms. But there's a lot of stuff like the list views that I should be able to  share. This isn't terribly difficult for iOS or Android, but all the code I write is unique  to those platforms. And to really show you that, I'll... In fact, let's do it in Visual  Studio. Here's Visual Studio running out iOS designer. And this is an even simpler version  of the proper beer drinking app. I call this basic beer, but this may actually... The forms  version may be turned into a beer drinking light in order to get UWP support very quickly.  But I've got a couple of views. I've got my navigation controller so that I can push and  pop view controllers. I've got a list view. I've created a table. We've got an image.  We've got a beer name. And then I go to a description. It's super simple. It doesn't get much simpler  than that. But the code I'm writing, if we take a look at... I've got this UI table view  controller because it's that one-to-one mapping to the iOS APIs. I have to inherit from that.  And then I've implemented some of the events and I've got some pop-ups to show I'm loading.  But I've got this data source. And the data source, again, is an iOS plus. So we'll go  to declaration. Where did I actually define that? Here we go. So you can see I'm having  to override. And all of this code is only for iOS. I can't use any of this code on Android  or Windows Phone. And all it's doing is showing me a list of beer. I mean, let's run it on  an iPhone simulator. And it will pop up down on the simulator icon. Tap down here. Hopefully.  It is building. iOS builds tend to take slightly longer than Android on the whole. Just because  we do that ahead of time. On the simulator, we don't actually do ahead of time. We can  do it on the device. So it's really important. And this is a general thing. When you're developing  in the simulator, you need to make sure before you ship to the device that you run on a physical  device. Because the simulator has access to every single resource on my computer, which  happens to be four cores and 16 gigs of RAM. Now, the iPad Pro is pretty good, but it still  doesn't have four cores or 16 gigs of RAM. So you can write some really horrible code  that will be really performant on the simulator. But it's going to run horribly on the actual  device. So there we go. I can search for a beer, do val, boom, we've got the beer result  come back, and I hit go forward and we're good. But I'm not sharing any of this code.  And if I type in golden drunk, even worse, because I'm not using my Azure search, it's  actually not going to return the beer I want. It's returned beers, but none of the beers  I want. Because it doesn't have that fuzzy matching. It's horrible. If you look here,  we've got 122 lines excluding white space of, or including white space, of code just  to be able to populate that table view. 122 lines of code. Now, I want to show you Xamarin  Forms. Because Xamarin Forms makes this a trillion times better. So with Xamarin Forms,  we've looked at our developers and we've seen that they're reinventing these views for all  the different platforms. They want to have a list view or maybe a map view, such as here.  So Apple Maps for iPhone, Google Maps for Android, and then Bing Maps for Windows Phone.  They all do the same thing. You get a location, you drop some pins. But the API is really,  really different across all of these platforms. And we thought it was mad that you couldn't  have a common API across all of them. So just like with the traditional approach, we've  got the shared T-Shark backend, which is about 75% of your app, and then you've got  that 25% that's unique to the platform. We can actually bring up the amount of code that  we share, because now we're able to share our UI layer as well, or parts of our UI level.  So in a best case scenario with Xamarin Forms, we're looking at a 99.9% cross-platform app.  So your code is 99.9% cross-platform, and that 0.1% is just code that's unique to each  platform project to get it started. So we need to initialize Xamarin Forms on iOS. We  need to initialize it on Android and UWP. But all of the code that you write is in a  possible class library or a shared project, and we can just run that everywhere.  So iOS has 33,000 APIs, and Android has 40,000 APIs. Plus, these are increasing with every  new version of iOS and Android. So that's a lot of APIs for you to learn and to take  advantage of. So Xamarin Forms tries to abstract some of these away from you so that the common  things across all of the platforms, you just have one API to learn. But it is worth learning  some of these APIs that are unique to the platform in order to start customizing. I'm actually  going to show you a custom renderer as we finish, which is, I think people call it an  advanced subject for Xamarin Forms, but it really is an advanced, and you'll see just  how easy it is a little later. So Xamarin Forms allows you to quickly and easily build  100% native apps, just writing it once. And you can mix and match Xamarin with these native  APIs. So as I say, with the custom renderers, we can drop down from this high-level abstraction  into the native implementation, and so we can get access to every single API that we  want. My colleague, M Hutch, has actually written a library, which we're still not sure  if we're going to be allowed to release properly, but it's a library that allows you to say,  hey, Xamarin Forms, give me this button on iOS as a native type, and it will just give  you straight back a UI button. And at that point, you have access to every single control  that a UI button has. So you don't even have to go into custom renderers. So it's even more  customizable within the possible class library. And that's truly magic. The key point with  the mix and match is that you're not limited by Xamarin Forms. Although it's a abstraction  API when you need to start customizing and jumping down into the lower level, we've got  you covered. So what's included? You get 40 pages layout controls. You can build this  from code. So in C sharp or S sharp or XAML, you guys must be XAML developers because you  use WPF, right? So who here is a XAML developer? You use WPF without XAML? Wow. Interesting.  Well, if you're a XAML developer, you'll love Xamarin Forms because we absolutely support  it, which naturally means two-way data binding. And is anyone here used NVVM? It's pretty  awesome. If you've not used NVVM, it really feels like cheating. It takes a lot of the  boilerplate code that you would be writing to send events from the UI back to storing  it in data and vice versa. You update your view model and you want your UI to update.  We give you consistent navigation and animation API across all three platforms. And we give  you a dependency service which allows you to drop down into that lower level when you  need to. And on top of that, we give you a messaging center. And the messaging center  allows objects that have no idea about each other to communicate with each other so that  you have really decoupled code. So it makes unit testing really easy.  So we have a couple of pages that we give you by default. You get a content page, master  detail navigation tabs in Carousel. You'll do most of your work in a content page, to  be perfectly honest with you. You'll sometimes throw a content page within a tabs page so  that you can have tabs. And tabs are an interesting example within Xamarin Forms because on iOS  they live at the bottom, on Android they live at the top and on Windows Phone they become  a Carousel. Now, you don't have to specify the layout for that within Xamarin Forms  because we're just creating the native type. The OS will lay that out for us. But if we  want to get into layouts within our content pages, we've got a couple of options. So we've  got stack, absolute, relative grid, content view, scroll view, frame. I do 90% of my work  in a stack view. Because a stack view is a managed layout. Things like the absolute isn't  a managed layout. So with absolute you can have to do way more calculations of how you  move things around and how you scale depending on the device size. With a stack, we do a  lot of that for you. So with stack you can just throw view items into the stack layout  and present that on the screen and it's going to look great no matter what size device you're  running on. We give you a couple of controls out the box. These are the controls that we've  mapped that we found were common across all the platforms. But there are so, so many third  party controls now. It's unreal. If you go on to new get, you'll find that the community  is just endlessly adding to this list. So the community fills in this blank space. You  can fill in this blank space using those lower level APIs when you want to get access to  them. And you can even go so far as buying controls from people like infragistics or  Syncfusion. So you're not limited just to what we give you. In terms of the XAML, although  we don't have a huge amount of XAML developers in here, to the 2009 XAML specification, we're  pretty similar. So if you've already done XAML development before, you'll feel right  at home within Xamarin.Forms. There are a few new keywords that you'll need to learn,  but apart from that, you'll understand the basic idea of how you can get started within  Xamarin. So let's actually have a look at some forms code. I'll open up the project  within Xamarin Studio. Yeah.  Well, the specification is pretty loose. You would think as a spec it would be nailed  down, but it's quite airy-fair in areas, which is how we've been able to extend it to work  across all three platforms. So, yeah, it's... The key thing is if you already know the approach  to NVVM and XAML and how you do the data binding and create your view models, you're  going to find Xamarin.Forms really easy. In this example, and this is all on GitHub,  everything you see code-wise today is on GitHub and you can download it right now, I've actually  got within this project two different types of view. So I've got the XAML view and then  I've got a code behind view to show... Because often I'll talk to a room and there won't  be any XAML developers and I just want to see C sharp. C, C sharp. So I want to show  you from the very top. So if I created this in Visual Studio, I would actually have four  projects within the solution, so I'd have a Windows phone option as well. Now, we've  got UWP support in preview and we've had a lot of success with customers rolling out  UWP apps that they've built with forms. And all they had to do was add a new project,  which is a UWP project, download a new get package, which is Xamarin.Forms, add that  couple of lines of initialization and it was all done. They've built their app already.  So the main part of your application is going to live in this portable class library. And  this is all your views, your view models, maybe your business logic, some of your models,  although you might have those in a separate portable class library that you bring into  this as well. But the Droid project and iOS project and Windows phone project really don't  need to have a huge amount in them. If we take a look at the iOS project, we have this  app delegate. Now, an app delegate deals with the application lifecycle on iOS. Now, we've  got this, we override this finished launching method, which is exactly the same as the standard  iOS app. So lifecycle would happen within the app delegate. But you can see that we  init Xamarin.Forms. Now, we write this code for you. And this is that bit with 0.1% that  isn't cross-platform. It's unique to that device or platform in particular. But we  write it for you, but it is there. So there's a general rule when you're doing Xamarin.Forms,  you can just close their projects and not really need to look at them again. Whilst we're here,  we'll fire up that. If we come into the portable class library, we have our entry point, which  inherits from application. So just like with iOS, we've got our app delegate, which inherits  from UI application delegate. We inherit from application here. And I've got a property  of app or property of the class, which is main page, which I can set to be a content  page. But in this case, I'm setting it to be a navigation page, which is like the navigation  controller, so it allows me to push and pop without the app crashing. And there I'm adding  my search page. Now, the search page is the page that I built using XAML. So let's take  a look at that. Boom. And the search page is the page where we do the search and we  show the list of results. Can anyone remember how many lines of code that was to do in the  traditional version? 120? Yeah, it was 122, to be exact. Very good. So we've taken 122  lines of code that are unique to iOS. And now we're doing it in XAML in forms, and we've  got the UI down to 19 lines of code. Now, I do have a view model, which is where most  of this magic is happening, because you can see, you know, when I change text, I'm going  to update the search term within the view model. I've got search beers command. So when  I press the search button, I fire a command off in the view model, and that's some of  the heavy lifting to go back and populate this list view. So let's have a look at the  view model. There's nothing particularly exciting about the view model. It is just generic C  sharp. Obviously, I've imported some Xamarin forms namespace in order to get access to  R command type. But it really is just if you've done NVVM, it's just generic NVVM approach.  There's nothing really magical about this. So if I run this, let's see, we'll run it  on Android first. Perfect. I selected the wrong device. So this is our Android emulator.  It's actually not emulating anything. It's x86, so it's hardware accelerated. It's super  fast. It starts in about 17 seconds. So does anyone use the default Google emulator? Congrats  for getting here today, because it's probably still starting. It's horrifically slow. It  takes about a minute and a half, two minutes to go from nothing to being useful. Perfect.  What more could you want? Let's have a look. I'll try Kit Kat. I was going to show you  this all in Visual Studio, as I mentioned to you earlier, but I bravely decided to update  my Android SDK when I was on the stand. When you update your SDK 20 minutes before you  go on stage, you're guaranteed to break something, and it broke everything. So that's why we're  sporting Xamarin Studio here. We'll try that again. It's going to install the app. When  Android the first install takes a little while because we installed a shared runtime. The shared  runtime is used by all of the other Xamarin apps that are in debug. If you build a release  app, it's going to bundle the runtime with your application. We link it so it's really  small, but we'll bundle it so that the runtime doesn't change from underneath you, because  we don't want the next app to be installed to use version 2 of the runtime and you were  using version 3 and now your app doesn't work. We'll always bundle it. After we link it with  beer drinking, and I've already told you just how much that's doing, it's about two megs.  It's about the same as a high-quality image. Our link is incredible, to the point where  it can almost overlink, and when I say almost overlink, it does overlink in certain situations,  especially if you're using generics, it will start ripping stuff out and then your app  will crash because it can't find the type. You have to sometimes tame our linker in order  to not get rid of everything. A linker tamer, yeah. It's more difficult than a lion tamer.  We can see the Android app here. It's pretty hard to see because of the Android theme,  but I'm going to search for dovel again. Dovel being a Belgian beer that's pretty strong,  and then we've got the results. I'm loading the images, I think, so I'm not locking up  the UI thread, and I can come in here and I can tap on the beer, and again, I get the  results and I get an image at the top. Now, the image has a circle around it. The default  image I get back from BreweryDB, which is a database, just comes back as square. I'll  show you how I created that circle in a moment. You can see it's a pretty ugly app, but I've  not spent any time on theming this. I could go into the Android project and update the  theme, I could change the colors, I could really design this to look lovely, but I wanted to  show you just out of the box, file new project style, what we get with very minimal amounts  of coding. Let's see how this looks on iOS. We'll set a startup, and we'll run that again.  The same code is going to run on iOS as the Android version, so it's still not going to  look beautiful, so I've done no custom styling. There we go. Then I'll search for dovel again,  it gets the text faster than the images. We also cache images as well with Xamarin forms  for you, so that you're not constantly going and downloading that, which is pretty nice.  There we go. We've got the results, and it's exactly the same code. I could then go ahead  and run this on UWP, so I could have the same app without any modification running on an  Xbox. I get this running on a HoloLens, if Microsoft would give me one. I've not made  any modifications to the project, I just have to hit rebuild, and I'm good to go. That's  the real power of Xamarin forms, that as new platforms come out that are exciting, we  can make sure that we're on them. If we all go out tomorrow and buy a BlackBerry, you  can be guaranteed that Xamarin is going to make sure that we support the BlackBerry.  I don't think BlackBerry is ever going to take off again, so I don't think that will  happen, but if it did, we would be there. When I click here, interesting, there we go.  When I click here, we've got the square image, because I've not implemented a custom renderer  for iOS. On Android, I said I want to be, within my view, when I'm displaying this,  I want it to be a circle image, and in order to make that a circle image, I had to drop  down into the native API in Android to implement that.  I'll show you the implementation, custom renderers. Has anyone developed for Android  before? Android is a beautiful disaster of an operating system. It shouldn't work, because  it just shouldn't, but it does. Somehow Google make it work. As a user, it's a really, really  nice OS, but as a developer, it's pretty horrible. You can kind of see this between the difference  between how to crop a photo in Android, which is this code, which is pretty damn nasty,  versus if we look at the iOS equivalent, you know, much, much simpler.  So the key thing here is this custom renderer. I'm exporting a renderer. It's a type of image  circle. Image circle is a type within Xamarin, within Xamarin forms. I've got this method,  which is create circle. If I uncomment this line of code, we'll actually then be calling  into this method to do that cropping. We'll rerun that. While we're running it, we'll  pop in here. We'll see that I create a new image circle. If I don't provide a concrete  type for image circle on iOS or UWP, because I'm inheriting from just a standard image,  Xamarin forms is intelligent enough to say, well, this should just be a normal image.  He doesn't have an implementation for iOS, so we'll just give him a normal image for  you. Does that make sense? So you don't have to go ahead and implement each platform if  you don't want to. If you only want to customize for Android, just do it for Android, and  you're good to go. We'll search again for Stella, which is a Christmas beer, first  brewed in Lervon. There we go. We've got the circle because we've cropped it. That's custom  renderers. When you talk to Xamarin developers that are using forms, when they very first  start out, they're often scared to take advantage of the custom renderers because they see it  as scary to drop down into this platform Pacific APIs, but it's really, really simple. There's  nothing too intimidating about using a custom renderer, and it allows you to take advantage  of those 33,000 iOS APIs or the 40,000 Android APIs. You have access to everything when you're  dealing with the renderers. So in November, we announced version 2 as Xamarin forms. I  wanted to stand here and tell you a long list of features that version 2 adds, but version  2 is very much just stability. So version 1 as Xamarin forms was something that took  off in a way that we 100% didn't expect. We initially called Xamarin forms Duplo when  we developed it, the project name, because we expected it for childishly easy apps to  build. But people were just like, this is amazing. I can use Xamarin and write it everywhere  so I'm going to. They pushed it and pushed it to the extreme and we're always trying  to catch up. We think we're at a point now with version 2 where we've caught up to what  developers expect of it because, as I say, they used it in a way we didn't think they  would. So we're at a point now where we're stable. We've got lots of big customers using  it and we're very happy with it. So version 2, I only add a couple of features, but the  list of bug fixes is huge. One of the most interesting features of version 2 is we now  do compiled XAML. It was one of our most requested features from developers. Our XAML interpreter  is actually incredibly fast, so there's not a performance increase when you're using  the compiled XAML instead, but people wanted it so we gave it to them.  If you want to learn more about Xamarin, we've got numerous options, but we also have a conference  in Orlando. Has anyone been to Orlando? Well, you should go again because you know how lovely  it is, especially in April. Yeah, so it's end of April. We have two days of training,  which is the Danu Instructors, our university instructors, and they're genuine experts on  so many different technologies and they'll be standing on stage and teaching you about  everything from garbage collectors to cell reuse on Android. You can get one-to-one with  engineers as well. So if you've got a problem, a bug in your project, you can sit down with  Miguel, who's our CTO, and he'll sit there and code review for you and tell you that  you're a great programmer or a terrible one, depending on your code. So it evolved pretty  awesome. And after the two days of training, we then go on to the conference, which is  I think two or three days of just having fun and learning about loads of different tech.  We've got this great thing, which is the Darwin lounge, and this is going to be even bigger,  but we have drones flying around. We've got an Oculus Rift. We have mini hacks, and we've  got the experts on hand. And if you do all the mini hacks, you win prizes, and the prizes  are actually worth trying to win. Hence why we've got so many people trying to win them.  Once you've bought your ticket, everything else is pretty much paid for. You get your  breakfast, your lunch, we'll take you out for dinner to some lovely places. Last year,  we went to, we had an old train shed that we put loads of amusement arcade stuff in  it as well, and we had all the local experience. We're in Georgia. We had loads of barbecue  places come along, and we had ribs, and it was lovely. And then the next day, we were  at the aquarium, and it's just, it's loads of fun. So highly recommend it. If you've  got a training budget that you've been allocated for the year, and you're thinking of a fun  way to spend it, just saying. So I've been Mike James, developer evangelist at  Cameron. I write loads of apps, and I write them all in C sharp. They're all on GitHub,  apart from Hydrate. That's not on GitHub because it's really horrible. So don't use  that. But it's my only OS 10 app, again built entirely in C sharp. So thank you very much.  Do we have any questions? I realize I've kind of just dumped my brain out to an audience  for 14 or five minutes. I would be quite fried by now. No questions? There's always a couple  of questions. Perfect. Let's go and get coffee then. Thanks, guys.
Xamarin_0_59.png Xamarin_60_179.png Xamarin_180_371.png Xamarin_372_8399.png Xamarin_8400_14831.png Xamarin_14832_15011.png Xamarin_15012_15131.png Xamarin_15132_18287.png Xamarin_18288_18539.png Xamarin_18540_20675.png Xamarin_20676_23447.png Xamarin_23448_24047.png Xamarin_24048_24119.png Xamarin_24120_25151.png Xamarin_25152_26279.png Xamarin_26280_28427.png Xamarin_28428_30467.png Xamarin_30468_32687.png Xamarin_32688_32735.png Xamarin_32736_32795.png Xamarin_32796_34067.png Xamarin_34068_34583.png Xamarin_34584_40055.png Xamarin_40056_40175.png Xamarin_40176_40235.png Xamarin_40236_44843.png Xamarin_44844_45791.png Xamarin_45792_46007.png Xamarin_46008_46055.png Xamarin_46056_47087.png Xamarin_47088_47363.png Xamarin_47364_47495.png Xamarin_47496_49475.png Xamarin_49476_50219.png Xamarin_50220_50483.png Xamarin_50484_52595.png Xamarin_52596_52643.png Xamarin_52644_52895.png Xamarin_52896_54083.png Xamarin_54084_55871.png Xamarin_55872_56747.png Xamarin_56748_58571.png Xamarin_58572_59243.png Xamarin_59244_59303.png Xamarin_59304_59363.png Xamarin_59364_63395.png Xamarin_63396_66299.png Xamarin_66300_66671.png Xamarin_66672_66803.png Xamarin_66804_67559.png Xamarin_67560_67619.png Xamarin_67620_67667.png Xamarin_67668_68303.png Xamarin_68304_68351.png Xamarin_68352_71915.png Xamarin_71916_72035.png Xamarin_72036_75551.png Xamarin_75552_76079.png Xamarin_76080_77939.png Xamarin_77940_78011.png Xamarin_78012_79955.png Xamarin_79956_80051.png Xamarin_80052_80123.png Xamarin_80124_81275.png Xamarin_81276_82775.png Xamarin_82776_82823.png Xamarin_82824_82943.png Xamarin_82944_83015.png Xamarin_83016_83195.png Xamarin_83196_83963.png Xamarin_83964_83977.png