Xamarin - Cross platform developer
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 133 | |
| Author | ||
| License | 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 | |
| Identifiers | 10.5446/48854 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC London 201650 / 133
2
6
10
12
15
17
23
24
28
30
31
32
35
36
39
40
43
44
45
47
51
52
55
58
59
60
61
62
63
64
67
69
71
73
74
75
82
84
86
87
97
103
107
108
111
112
114
115
117
120
123
126
128
129
132
133
00:00
Software developerComputing platformExterior algebraSemiconductor memoryFormal languageCodeWebsiteLink (knot theory)GoogolKey (cryptography)WordWeb 2.0PlastikkarteRight angleProcess (computing)Computer programmingMobile appMultiplication signVideo gameScripting languageJava appletSoftware developerInstallation artReal numberComputer configurationWindowReal-time operating systemComputing platformMessage passingSound effectCuboidSign (mathematics)QuicksortGame theoryForestServer (computing)Data conversionProjective planeGraph coloringDensity of statesSocial classAndroid (robot)Selectivity (electronic)Integrated development environmentCoprocessorRepresentational state transferWeightLibrary (computing)Programming languageDampingBoss CorporationNetwork topologyBitMobile WeboutputArmPortable communications deviceGoodness of fitJSONXMLUMLComputer animation
05:36
Complete metric spaceMobile WebSoftware developerSoftware testingPoint cloudMobile appQueue (abstract data type)TwitterPeripheralStructural loadDigital photographySoftware frameworkWindowCartesian coordinate system2 (number)Thread (computing)SoftwareMultiplication signProduct (business)Analytic setPoint cloudCrash (computing)Traffic reportingTouchscreenAndroid (robot)Software testingTable (information)Tap (transformer)Term (mathematics)PixelFirst-order logicMobile WebComputing platformInterpreter (computing)Process (computing)Speech synthesisMereologyPoint (geometry)Unit testingSolid geometryData storage deviceDifferent (Kate Ryan album)Variety (linguistics)Software developerCodeDivisoroutputBuildingView (database)Line (geometry)Java appletMultitier architectureException handlingOrder (biology)E-learningRaw image formatForm (programming)Mountain passStatuteObject (grammar)Hybrid computerSimilarity (geometry)Right angleVirtual machineProjective planePhysical systemUniverse (mathematics)WordMiniDisc
12:11
Software developerMobile WebMobile appCodeMultiplication signMobile appObject (grammar)Software developerSet (mathematics)Hand fanWindowCopyright infringementNumberKeyboard shortcutProcess (computing)Lie groupWebsiteUser interfaceAndroid (robot)Computing platformVisualization (computer graphics)Perfect groupWeight1 (number)Structural loadDifferent (Kate Ryan album)CodeRevision controlJava appletComputer animation
13:47
Software developerUniqueness quantificationPhysical systemWeightArmVisual systemJava appletAndroid (robot)Mathematical optimizationMobile appData storage deviceCompilation albumResultantComputer fileOverhead (computing)Visualization (computer graphics)Run time (program lifecycle phase)Maxima and minimaJava appletLinker (computing)Software developerLevel (video gaming)Wrapper (data mining)Formal languageNamespaceSocial classoutputPhysical systemCore dumpRule of inferenceArmCodeInsertion lossBitDefault (computer science)Computer configurationDifferent (Kate Ryan album)Term (mathematics)WebsiteBytecodeCompilerInformationRoutingLink (knot theory)User interfaceView (database)Inheritance (object-oriented programming)WeightType theoryCartesian coordinate systemWindowTable (information)Game controllerShared memoryLibrary (computing)InjektivitätBijectionCross-platformKeyboard shortcutComputing platformDisk read-and-write headMereologyMetropolitan area networkProcess (computing)Computer programmingCASE <Informatik>Point (geometry)Multiplication signPeripheralObject (grammar)MappingSineInstance (computer science)Real-time operating systemEndliche ModelltheorieGoogolSystem callDressing (medical)FreezingMoment (mathematics)Message passingLogicSoftware testingBenchmarkComputer animation
21:47
Software developerAndroid (robot)MicroprocessorBitVideo game consoleCASE <Informatik>Slide ruleCodePoint cloudService (economics)Social classStandard deviationLibrary (computing)Different (Kate Ryan album)Projective planeMobile app
22:43
Point cloudSoftware developerVideo trackingForm (programming)TouchscreenOrder (biology)PredictabilityOpen sourceProjective planeRevision controlDifferent (Kate Ryan album)AreaResultantFamilyUniform resource locatorMobile appMultiplication signPoint cloudSynchronizationService (economics)Menu (computing)Uniform boundedness principleType theoryMachine learningInheritance (object-oriented programming)Real numberCodeShared memoryConservation lawRight angleFuzzy logicMatching (graph theory)1 (number)Video gameComputer configurationTap (transformer)WebsiteHybrid computerData structureCasting (performing arts)Computer animation
26:48
Software developerMoment (mathematics)Service (economics)Mobile appMultiplication signBoss CorporationProjective planeoutputUniform resource locatorInstallation artAndroid (robot)Computer configurationState of matterOpen sourceRight angleComputer animation
27:50
Software developerAndroid (robot)Software bugComputing platformVirtual machineMobile appEndliche ModelltheorieCodeLink (knot theory)View (database)Visualization (computer graphics)Query languageoutputMatching (graph theory)ResultantBitType theoryClient (computing)Electronic mailing listMultiplication signService (economics)Insertion lossDrop (liquid)Computer animation
29:53
Software developerComputer simulationSource codeWindowDeclarative programmingElectronic mailing listRevision controlSystem callForm (programming)Lie groupView (database)Computer iconAndroid (robot)Table (information)Descriptive statisticsOrder (biology)CodeGame controllerMedical imagingMappingUltraviolet photoelectron spectroscopyInheritance (object-oriented programming)outputStructural loadSocial classVisualization (computer graphics)Event horizonProper mapMobile appComputer animation
31:24
Software developerAndroid (robot)CodeVisualization (computer graphics)Computer simulationNeuroinformatikDisk read-and-write headPeripheralMultiplication signCausalityGraphics tabletLogic gateLine (geometry)Table (information)Form (programming)Series (mathematics)TrailoutputType theoryMatching (graph theory)Core dumpResultantGoodness of fitView (database)Computer animation
32:55
Software developerAndroid (robot)BuildingWindows PhoneLattice (order)MappingView (database)Electronic mailing listLevel (video gaming)WindowComputing platformAndroid (robot)Software developerForm (programming)DemoscenePersonal identification numberUniform resource locatorMobile appComputer animation
33:39
Software developerShared memoryCodeAndroid (robot)CodeCASE <Informatik>Mobile appProjective planeLibrary (computing)MereologyLevel (video gaming)outputAndroid (robot)Computing platformCross-platformPoint (geometry)Revision controlComputer virusForm (programming)VolumenvisualisierungOrder (biology)MultilaterationComputer animation
35:03
Software developerShared memoryCodeGUI widgetBuildingKeyboard shortcutControl flowComputing platformService (economics)Boilerplate (text)View (database)Proper mapEvent horizonCodeConsistencySoftware developerLevel (video gaming)Matching (graph theory)Web pageForm (programming)Forcing (mathematics)Library (computing)Object (grammar)Point (geometry)Software testingMixed realityType theoryGame controllerAbstractionSingle-precision floating-point formatCheat <Computerspiel>Mobile appRight angleSampling (statistics)ImplementationEndliche ModelltheorieUnit testingVolumenvisualisierungoutput
37:15
Software developerComputer-generated imageryView (database)Cellular automatonWeb pageGreatest elementType theoryView (database)Default (computer science)Content (media)Electronic mailing listSpacetimeTouchscreenCuboidFrame problemGame controllerCalculationStack (abstract data type)Presentation of a groupComputer configurationTheory of relativityWindowComputing platformSoftware developerAbsolute valueTerm (mathematics)GradientStaff (military)Level (video gaming)
39:03
View (database)Software developerEllipseRectangleMarkup languageExtension (kinesiology)VolumenvisualisierungControl flowTemplate (C++)Analog-to-digital converterKeyboard shortcutCodeWindows PhoneAttribute grammarComputer fontFamilyDemo (music)Latent heatSoftware developerTerm (mathematics)Form (programming)Power (physics)CodeComputing platformProjective planeMobile appCartesian coordinate systemAiry functionEndliche ModelltheorieMereologyWindowKeyboard shortcutAreaLogicLibrary (computing)Type theoryPoint (geometry)Computer configurationVideo gameCycle (graph theory)Uniform resource nameoutputStandard deviationDifferent (Kate Ryan album)View (database)Visualization (computer graphics)Line (geometry)Portable communications deviceBitRule of inferenceSocial classFlow separationComputer animation
42:14
Software developerPoint (geometry)Library (computing)Social classPortable communications deviceCartesian coordinate systemMobile appCASE <Informatik>Web pageCategory of beingCodeCrash (computing)Boom (sailing)View (database)Electronic mailing listResultantLine (geometry)Order (biology)Generic programmingTerm (mathematics)Endliche ModelltheorieForm (programming)9 (number)NamespaceGame controllerRevision controlMathematicsComputer animationLecture/Conference
44:12
Software developerAndroid (robot)GoogolEmulator2 (number)Exception handlingInheritance (object-oriented programming)Computer hardwareDefault (computer science)Computer animation
45:02
Software developerSoftware development kitAreaLevel (video gaming)Visualization (computer graphics)Multiplication signFiber bundleMoment (mathematics)Run time (program lifecycle phase)Projective planeCartesian coordinate systemGraph coloringMedical imagingLink (knot theory)Revision controlPoint (geometry)CuboidAndroid (robot)MathematicsCodeMobile appCrash (computing)ResultantCircleDatabaseOrder (biology)Line (geometry)Type theoryLinker (computing)Generic programmingMaxima and minimaComputer fileInstallation artDefault (computer science)Computer animationSource code
47:40
Software developerChemical equationDuality (mathematics)Information managementWindows PhoneComputer fontAttribute grammarFamilyControl flowAndroid (robot)CodePower (physics)Square numberVolumenvisualisierungMedical imagingRevision controlPoint (geometry)Mobile appReal numberForm (programming)Projective planeoutputExtreme programmingElectronic mailing listSoftware bugStability theorySoftware developerExpected valueStandard deviationImplementationNormal (geometry)CircleType theoryView (database)Latent heatComputing platformOperating systemDifferent (Kate Ryan album)Digital photographyInterpreter (computing)Order (biology)GoogolInformationSource codePearson product-moment correlation coefficientRow (database)Line (geometry)ResultantWebsiteEquivalence relationComputer configurationFamilyProcess (computing)Level (video gaming)Computer animation
53:18
Software developerMobile appAndroid (robot)Cellular automatonSoftware bugCodeSpeicherbereinigungUniverse (mathematics)Expert systemLevel (video gaming)View (database)Wave packetStructural loadDifferent (Kate Ryan album)Projective plane
54:11
Software developerStructural loadWave packetExpert systemFilm editingComputer animationMeeting/Interview
55:11
Software developerAndroid (robot)Software developerMobile appStructural loadLecture/Conference
Transcript: English(auto-generated)
01:17
being released. You couldn't get any compiled binaries, you would have to build it yourself.
01:23
I'm not sure if anyone has built Qt 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, so it was horrible. There was no way I could use Qt to build a mobile solution. We were a cross-platform
01:41
shop. I couldn't go ahead and write a mobile app for the guys using Objective-C because my boss would be like, it's not cross-platform, we can't use this. So I did something horrific. I used jQuery Mobile and I used a built-in web server because it's got the RESTful API and I would ask it, what lights are on, what lights are off? Can I start firing
02:03
some effects so I can make it do a rainbow? And I made a nice little UI using jQuery Mobile. But then we tried to scale that out to other installations. So like the Westfield shopping centre in Stratford, all of their exterior lighting, I mean, it's all static now because they didn't actually get planning permission, which
02:22
is genius, but all their exterior lighting is intelligent and they wanted to be able to walk around with an iPad and control the lights so they could select a tree and say I want this tree to be red and it would just magically be red. And I was using jQuery Mobile again, so I was sat in sublime text writing HTML and
02:40
JavaScript and sometimes a bit of CSS. And we would ship the app to them and they would actually just put it on a memory stick and shove it in the side of the LPC and we would then connect from our phones onto the device. But that app got so complicated because they wanted real-time colour selections.
03:01
I had to build a colour wheel, so a colour picker in JavaScript. It was nasty. And when you would move around, we would sometimes DOS the box with so many messages that we want to send so many updates that it would just die. Or we'd send too many people would connect at once and it would just die because it's only a tiny little ARM processor. So the app was horrible.
03:21
It most likely killed the device at least once a day. So like there's got to be a better way. And I was sick and tired of writing JavaScript and HTML and I wanted to get back into a real IDE. So I had two options and 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.
03:40
I want to use real programming tools and I want to use a real programming language. Or I could find an alternative to this horrible solution. And so on the Friday, I went home and, you know, I sat there contemplating, write my letter of resignation or find the alternative and I opted to just do some googling. And I thought, what's the ideal situation here?
04:00
I want to be able to run .NET on an iPhone. And that's all I typed into Google, .NET on iPhone. And Xamarin was the top link. And this was three, three or four years ago. And I'm not sure if anyone used Xamarin back then, but the website was really, really horrible. We looked very amateur. The company was about 30 people. So it was really, really small.
04:21
They were only about a year old at that time. So it was very amateur. I was like, I'm going to give it a go. So I pulled out my credit card and I bought a pizza because no good programming project starts with our pizza. And when the pizza arrived, I pulled out the credit card again and bought a license to Xamarin. And over the 48 hours of my weekend,
04:41
I just sat in my room and I hacked and I hacked and I hacked. And 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. So I rock up to work really cocky on the Monday morning and I say, hey, Simon, I've built us an app.
05:04
And it's a proper app this time. And it's like, well, let's have a look. So I pull out my phone and I hand it to him. I'm like, there you go. And I'm feeling pretty smug about it. And he looks at it and he says, yeah, we can't use this. I'm like, oh, what's the problem? And he says, well, you've built it with Objective-C. I was like, hmm, I haven't. I know it's native, but I can still share a lot
05:23
of this code. And I showed him and he was blown away by what I'd done with Xamarin. And about a week or two later, I applied for a job at Xamarin and I left Faros. So he wasn't most pleased about that. But that's my story of how I came into Xamarin development. I'd used the alternatives. I'd gone down the hybrid approach and I'd found
05:43
a limiting factor pretty quickly. And I knew that 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. So today we're going to talk about how you guys can avoid that technique of
06:00
reinventing the wheel and how you can use Xamarin to write once and run anywhere. So that's the Xamarin platform. We also have a couple of other products. Was anyone in the earlier speech by Carl? Yeah. So he works for our Test Cloud team. For those of you who don't know, Test Cloud is a product where you've built your app, you've tested it with
06:23
unit tests 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'll ship it. We're excited to get this out. So you ship it off and then you get app store reviews saying it don't work. And 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
06:44
your users to test the app for you. And with Android, this is really important because I think there's 17,000 different varieties of Android, which is quite a lot for you to test on. Who here is actually testing on more than 100 devices? More than 50? More than 25? Are we going to
07:02
do this? Come on. Someone's going to have to raise a hand at some point. More than ten devices? Ten? About ten? Okay. More than five? Oh, this is still really bad. More than two. Come on. Okay. Do you guys write software? Yeah. So this is a problem. Most people aren't
07:24
testing their apps properly. They write the app, they side load it onto their device, and then they go, well, it works here. And 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
07:43
not normally set up in exactly the same way as our customers are using. And 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
08:03
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. If the welcome screen doesn't load, we're going to tell
08:22
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.
08:41
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 uncaught
09:04
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
09:20
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 had the issue, and make the fix. And if you're using test cloud, then you can update your test, upload the new app with the fix in it, going through the processes that
09:42
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 them, you talk to me afterwards. So what is native? There are three parts to what I
10:01
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 they'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
10:23
Qt's interpretation of what a UI should look like on an iPhone, on an Android, and on a Windows phone. You're not gonna 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 who's a very talented CSS coder has sat down and created some CSS
10:43
that makes a button look similar, but it's not a native button. And there are some differences, you know, when you do like long taps and long presses, and you're animating from, swiping from view to view. On hybrid, it often doesn't look quite as slick as a native UI.
11:01
Underneath that is API access. If I can't access 100% of the APIs 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 Objective-C, Swift, or Java developers have access to. When Apple comes out with a new API, such as,
11:24
you know, 3D Touch, I want to be able to implement that in my app. You know, the hybrid guys and the guys using Q and the other competing frameworks that aren't native, aren't able to do that. And then native performance. And I'll talk about performance a little later.
11:41
But mobile users aren't sat at desktops, you know, 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, you know, they're gonna tweet and they're gonna check Reddit. And if, you know, they
12:01
pull up your app and it takes too long to load in the data or even just load to the first screen, they're gonna quit and move on to the next app. Or order their latte with vanilla, whatever the hell they want. So there are a few approaches to developing mobile apps. I've already mentioned that the hybrid approach.
12:22
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? Yeah, it's quite nice. I quite like it. Yeah, it's like F sharp version one, but it's still quite nice.
12:40
So if you really like Swift, check out F sharp. Then you wanna, you know, you've written it for iOS, it's huge success, you're earning loads of money, you're like, let's get our app, you know, to be the number one pirated app for Android. So we'll write it for Android, boom, we'll use Java. And then you're like, I wanna hit Windows phone or I wanna use UWP, so you reinvent it again for using C sharp in Visual Studio.
13:02
And 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. So 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?
13:21
No one? Is anyone here developing mobile apps today? Okay, websites, perfect. Silverlight, I guess that had a website kind of. WPF, awesome. So we're all .NET developers, great stuff.
13:43
Okay, so if you're not, 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 gonna have a native user interface, we're gonna have that native element, the native performance, all access to the API, and we're gonna do that by having one-to-one bindings
14:02
and we're gonna 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 gonna share all the boring bits of our application. So this is all the models, all the business logic, all the RESTful calls, all the data persistence,
14:23
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 their OS. That's what they care about. They don't care about this bit.
14:42
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.
15:02
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. So F sharp is a first class language for us. So our design team are actually all developers as well and they love F sharp.
15:20
So we've got top-notch support for it within Xamarin. So 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
15:41
and we've got that base class library, so all of the namespaces and in turn classes we've been using for years, you know, system.link, system.xnow, you know, the stuff that we're used to, our bread and butter. They give us some new APIs and we're like, we've got this, we understand it. There's nothing too new here or too scary. We're just gonna build on top of our existing knowledge.
16:02
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,
16:20
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 the Java developers
16:42
have access to. So Xamarin embraced and extended .NET. Has anyone p-invoked 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
17:00
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 p-invoke into these native libraries, which is how you get that native app. It's how you instantiate the native controls because it's just a thin wrapper.
17:20
So if you've done p-invoking, 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, eh, this can't be right, but it's not magic. And I wanted to talk about performance because performance is really, really important with mobile. And there's two sides to the performance story with Xamarin. On iOS, we have to do ahead-of-time compilation.
17:42
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 your build time, when you wanna release to the actual physical device, is a little bit slower. But we can do a lot of optimizations
18:00
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 take the IL, so the C-sharp goes down to IL, just like your WPF apps or your WinForms app.
18:22
We take that IL, we convert it to a bytecode that we can feed through the LMVM 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
18:43
if you wanna go down that route. You're not gonna see a huge performance increase if you do that. But Android tends to be faster using Xamarin than if you'd use Delvik and use Java. So we've got some benchmarks. And these were produced by an ex-Googler.
19:01
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.
19:23
And he's benchmarked them. And then he put it online, and naturally he put it on GitHub, and he said to all the other developers that were saying, well, you know, I can improve this Swift 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 improving.
19:43
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, you know, 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.
20:01
And because of all the messages, it's pretty hard to optimize that. So Xamarin, you're not gonna 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's a bit different on Android.
20:22
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 gonna 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 gonna have your users waiting around forever for something pretty trivial to happen
20:42
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.
21:01
As long as you've installed everything with Visual Studio and 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 Pharos and we were building the cross-platform software, C++ was really the only option for us to do cross-platform in a reasonable language.
21:23
And now I kind of feel that 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
21:40
with the nastiness of using C++. Now I love C++, don't get me wrong, but I'm much nicer to program in C-sharp. And I wanna show you some of the devices that C-sharp runs on. I'm not gonna 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.
22:06
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 a Google Glass? Nope, pretty standard. They're horrible.
22:21
You've got a Net 3 note, 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.
22:41
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 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 Net 3 note or on my watch and run it in app service, which I think is amazing.
23:05
So before we jump into the code, I wanna 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.
23:22
I told everyone that I was trying to impress it, it was to learn Flemish and be cultural, but actually I just wanted to go and drink beer. So I jumped on the Eurostar and I moved over there for seven months. And has anyone been to Brussels? Have you been to Delirium Cafe? Yeah, well, Delirium is,
23:41
so 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 rights for 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.
24:01
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 and you say, can I get the menu? And they give you a book. And I'm not exaggerating, it is 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,
24:20
I didn't know what beers I should be drinking. And the bar's always full because it's a tourist hotspot. So everyone's like, it's got 3,000 beers, we've gotta go. So you can't get to ask the barman, 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,
24:42
preparing my liver for this trip, I was using an app called Untapped. Has anyone used this, Untapped? So 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 yeah, their infrastructure's very, very different to the way that I'm developing my app.
25:02
But the biggest problem with their app is there's no offline capability. So there I am in Brussels, you know, really excited to get into this bar and try some beers. And I go into the bar and they give me the menu. I'm like, I'm gonna use Untapped to find me some beer. Cause it's got some recommendations. And I load up Untapped and it's like, eh eh, can't do anything. You've got no signal.
25:21
I was like, I'll connect to the Wi-Fi. A pub without Wi-Fi, that doesn't exist, right? So I asked the barman, what's a Wi-Fi code? Oh, we 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 gotta be a better way. I was like, I'm gonna fix this. I'm gonna write a beer app myself that has offline capabilities.
25:42
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 backend. 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 like hit highlighting. We can boost turn. So if you're in an area where a particular beer
26:01
is trending, we can boost that in the search results for you. Yeah, we're gonna be using machine learning as well to be able to make the predictions for you for what beers you're actually gonna 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 Donca.
26:21
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
26:40
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 earn money from this. Xamarin pay for all the expenses. So, I mean, Azure search is 150 quid a month
27:00
as a 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 gonna need one in Australia as well. I can probably miss out the Middle East. I don't think I'm gonna have a huge amount of app installs there.
27:22
But yeah, so it's 150, you know, times the location that I wanna go to and then you've got app service on top. But Xamarin just pay 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
27:43
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. Yeah, sometimes you'd be amazed with what we can expense.
28:08
Although I think, yeah, we're probably gonna get audited soon, so I think they're 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 gonna tell me. So I can be really, really bad at spelling.
28:22
So Golden Drak is a really nice caramel, 8%, maybe 9% Belgian beer, delicious. And as a British man, when I'm drunk, I'm gonna call it Golden Drak, because I'm drunk and I'm trying to overpronounce. And you would think if you're typing that in that you would type in Golden Drak, maybe?
28:40
You can see I've made the spelling mistake. And if I was just using a link query to look this up in App Service, go and find the equals named or equals this, I would never find these beers. But it's made the correction for me. It's a diss. This is a possible match. Yep, that is. So I can tap it and it does the real search when I get the proper results back. And I can tap on it.
29:01
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 for in the future when we're using machine learning. So it's pretty cool it'll app. But this is traditional.
29:21
So most of the code that you see here for the UI in bits, I'm not able to share any of this. Now naturally I've got view models 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. Like this isn't terribly difficult,
29:41
you know, for iOS or Android. But all the code I write is unique to those platforms. And to really show you that, I'll, dun, dun, dun, dun, dun. In fact, let's do it in Visual Studio. Here's Visual Studio running our iOS designer.
30:00
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.
30:20
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, you know, 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,
30:41
dun, dun, dun, dun, dun. 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 class. So we'll go to declaration. Dun, dun, dun, dun, dun. Where did I actually define that? Here we go.
31:03
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'll pop up down on the simulator icon.
31:25
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.
31:41
On the simulator, we don't actually do ahead of time. We can JIT. 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 a 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,
32:01
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 gonna run horribly on the actual device. So there we go. I can search for a beer. Duval, boom, we've got the beer result come back. And I hit go forward, and we're good.
32:23
But I'm not sharing any of this code. And if I type in Gordon Drak, even worse, because I'm not using my Azure search, it's actually not gonna 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,
32:42
you know, 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
33:03
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 know, you get a location, you drop some pins.
33:20
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 C-sharp 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
33:43
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
34:04
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 an enforceable class library or a shared project and we can just run that everywhere.
34:21
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
34:41
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. And I'm actually gonna 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
35:01
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. You're 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
35:20
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 gonna 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.
35:40
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. But the key point with the mix and match is that you're not limited by Xamarin.Forms. Although it's this abstraction API when you need to start customizing
36:01
and jumping down into the lower level, we've got you covered. So what's included? You get 40 pages layouts and 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?
36:21
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 has anyone here used MVVM? It's pretty awesome. If you've not used MVVM, it really feels like cheating.
36:41
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 a 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.
37:02
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,
37:20
master-detail, navigation, tabs, and 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 tabbed 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.
37:41
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 wanna 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, and frame. I do 90% of my work in a stack view
38:02
because a stack view is a managed layout. Things like the absolute isn't a managed layout. So with absolute, you're gonna have to do way more calculations of how you move things around and how you scale depending on the device size. With the stack, we do a lot of that for you. So with stack, you can just throw view items
38:21
into the stack layout and present that on the screen. Then it's gonna look great no matter what size device you're running on. We give you a couple of controls out of 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 onto NuGet and you type in Xamarin.Forms,
38:41
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 wanna get access to them. And you can even go so far as buying controls from people like Infragistics or Syncfusion.
39:00
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, we're 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,
39:22
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.
39:56
Well, the specification's pretty loose. You would think as a spec it would be nailed down,
40:02
but it's quite airy-fairy in areas, which is how we've been able to extend it to work across all three platforms. The key thing is if you already know the approach to MVVM and XAML and how you do like the data binding and create your view models, you're gonna find Xamarin.Forms really easy.
40:21
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 they'll just wanna see C-sharp, see C-sharp.
40:42
So I wanna 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.
41:01
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'd built their app already. So the main part of your application is gonna live in this portable class library, and this is all your views, your view models, maybe your business logic, some of your models,
41:21
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.
41:43
Now we've got this, we override this finished launching method, which is exactly the same as a 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.
42:00
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 those 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,
42:20
we have our entry point, which is app, 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.
42:40
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
43:00
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 Xamarin.Forms,
43:20
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, when I change text, I'm gonna 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 does some of the heavy lifting
43:40
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 our command type,
44:01
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.
44:25
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.
44:41
It's super fast. It starts in about 17 seconds. So has anyone used 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.
45:01
Perfect, what more could you want? Let's have a look. We'll try KitKat. I was gonna 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.
45:20
And when you update your SDK, like 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 gonna install the app on Android, the first install. Takes a little while, because we installed a shared runtime.
45:42
The shared runtime is used by all of the other Xamarin apps that are in debug. If you build a release app, it's gonna 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 two of the runtime,
46:00
and you were using version three, and now your app doesn't work. So 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. So it's about the same as a high-quality image. Our link is incredible, to the point where it can almost over-link, and when I say almost over-link,
46:21
it does over-link in certain situations, especially if you're using generics. You'll start just ripping stuff out, and then your app will crash because it can't find the type. So you have to sometimes tame our linker in order to not get rid of everything. The linker tamer, yeah.
46:40
It's more difficult than a lion tamer. But we can see the Android app here, it's pretty hard to see because of the Android theme, but I'm gonna search for Duvel again. Duvel being a Belgian beer that's pretty strong, and then we've got the results. I'm loading the images asynchronously, so I'm not locking up the UI thread,
47:00
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 Brewery DB, which is a database, just comes back as square. So I'll show you how I created that circle in a moment.
47:22
But yeah, 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.
47:40
Let's see how this looks on iOS. So we'll set a startup, and we'll run that again, and the same code is gonna run on iOS as the Android version, so it's still not gonna look beautiful because I've done no custom styling.
48:02
There we go. Then I'll search Duvel again, and it gets the text faster than the images. Oh, 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. And there we go, we've got the results, and it's exactly the same code,
48:21
and 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'd get this running on a HoloLens if Microsoft would give me one. And I've not made any modifications to the project, I'd just have to hit rebuild, and I'm good to go. So that's the real power of Xamarin.Forms, that as new platforms come out that are exciting,
48:42
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's gonna make sure that we support the BlackBerry. I don't think BlackBerry's ever gonna take off again, so I don't think that will happen, but if it did, we would be there. So when I click here, hmm, interesting,
49:01
that's a, there we go. When I click here, we've got the square image because I've not implemented a custom renderer for iOS. So on Android, I said I wanna be, within my view, when I'm displaying this, I want it to be a circle image, and in order to make that circle image, I had to drop down into the native API in Android
49:22
to implement that. So I'll show you the implementation, custom renderers, and Android is, has anyone developed for Android before? Okay, Android is a beautiful disaster of an operating system. It shouldn't work because it just shouldn't,
49:42
but it does. Somehow, Google make it work, and as a user, it's a really, really nice OS, but as a developer, it's pretty horrible, and 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,
50:00
versus if we look at the iOS equivalent, you know, it's 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, within Xamarin,
50:21
within Xamarin forms, and I've got this method which is create circle. Now, if I uncomment this line of code, we'll actually then be calling into this method to do that cropping. We'll rerun that. Whilst we're running it, we'll pop in here. We'll see that I create a new image circle.
50:41
Now, 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 view.
51:01
Does that make sense? So you don't have to go ahead and implement it for 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. So we'll search again for, we'll do Stella, Stella Artois, which is a Christmas beer first brewed in Leuven.
51:20
And there we go, we've got the circle because we've cropped it. And that's custom renderers. People, 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 specific APIs.
51:40
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.
52:02
So in November, we announced version two, Xamarin forms. Version two, I wanted to stand here and tell you a long list of features that version two adds. But version two is very much just stability. So version one of Xamarin forms was something that took off in a way that we 100% didn't expect.
52:22
We initially called Xamarin forms Juplo when we developed it as a project name because we expected it for childishly easy apps to build. But people were just like, this is amazing. I can use XAML and I can write once and run it everywhere, so I'm going to. And they pushed it and pushed it and pushed it to the extreme and we were always trying to catch up. And we think we're at a point now with version two
52:41
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 two only adds a couple of features, but the list of bug fixes is huge. One of the most interesting features of version two
53:00
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 it, using the compiled XAML instead. But people wanted it, so we gave it to them. If you want to learn more about Xamarin,
53:21
we've got numerous options, but we also have our 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 as Dan Yu instructors, our university instructors,
53:43
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,
54:02
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 Evolve is 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.
54:20
And we've got this great thing, which is the Darwin Lounge and this is gonna 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.
54:41
You get your breakfast, your lunch, we'll take you out for dinner to some lovely places. Last year we went to, we had a old train shed that we put loads of amusement arcade stuff in it as well and we had all the local, we were 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
55:00
and it's just, it's loads of fun. So highly recommended. 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 sayin'. So I've been Mike James, developer evangelist at Xamarin. I write loads of apps and I write them all in C sharp. They're all on GitHub apart from Hydrate.
55:21
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? Cause I realize I've kind of just dumped my brain out to an audience for 45 minutes.
55:42
I would be quite fried by now. No questions? There's always a couple of questions. Perfect, well let's go and get coffee then. Thanks guys.