View transcript
Okay, hello everybody and welcome. So welcome to this talk about mobile development. Today we are going to talk a little bit about doing mobile development using Xamarin. We are also going to take a look at how we can use Umbraco to enrich some parts of our native apps. So today it's me on stage and my name is Thomas and I'm the founder and CTO of Blue Fragments. With me on stage I have Thomas. And Matthias who is one of my awesome developers. Matthias is normally one of my Xamarin developers and has really good insight into how to use Xamarin and make some awesome apps. So I've been a developer for many years, 16 years about so. And back in the days I knew Nils really good. And along the way I have seen how Umbraco has evolved. And it's really great to be here today to see how Umbraco has evolved. The tools, the development part and so on. So during my time as a developer I've been involved in a lot of different technologies. And when I started Blue Fragments a few years ago we of course focused on .Net and C-Sharp. Our focus was building line of business applications. And at that time we wanted to really be on the edge of technology. So we built Silverlight applications. Yeah, that was really something. And we of course also built a lot of ASP.Net applications. We built a lot of VPF applications. But actually Silverlight provided us with the ability to take some of this rich stuff we could present to users and put it out in the browser. And a lot of companies really wanted that actually. The story about Silverlight, well, I guess you know that. It didn't turn out that good. But what we did after that was take a good look at Windows Phone, Windows 8. We began building apps for different companies. And was together with Microsoft the frontliners in building applications on the Windows platform for Windows Phone and Windows 8. We managed to build a lot of applications for Windows Phone. But again, the market wasn't really sure that Windows Phone was the market to be in. So slowly we also began looking at iOS and Android. Microsoft themselves began looking at iOS and Android. So it was pretty natural for us as a consultant company to also look at the possibilities we have on the other platforms. It was actually quite a tough decision for us because we have always been a dedicated Microsoft development house. So suddenly looking into other platforms was quite a decision. So what we did at the time was to look pretty hard on which cross-platform tools are available. What can we do to reuse the knowledge we have in the company. We're really good .NET developers, really good at C-sharp. So how can we reuse that in some point? And it turned out to be Xamarin that we wanted to go with. We could still use Visual Studio, we could still use C-sharp, we could reuse all of our skills to build apps across the different platforms. Microsoft recently launched Windows 10 and Xamarin is actually also supporting that. So being able to take all of the stuff we do in Xamarin put it out to all platforms including the new ones we see is a really strong tool for us. Currently we're also looking a lot into IoT and bots but that's a quite different story. So what we're going to look at today is a bit about how can we take some of the stuff we have in our baggage and reuse that into the stuff we build to do. So many companies have apps for iOS and maybe also for Android. And a few actually also have for Windows phones still. So what is the spread on the different platforms in here? How many uses iOS? Okay, and Android? Okay, Windows phones? Really? Awesome! It's not that often we see Windows phones users and that's awesome. It is an awesome platform and it's really a shame that it hasn't been used more. So there are a few different approaches to building mobile applications. The first one is also the most used and common one in enterprises. We call it the siloed model where we have a development team doing Objective C. They write it in Xcode and they do the iOS application. There's another team, an Android team. They do it in Java and usually use Eclipse for the development. And finally we have the .NET developers doing Windows phone and Windows applications in C-sharp and they use Visual Studio. So this is the most common one. But this is also the most expensive one. And actually it's also the least satisfying one for both the company and for the developers. The developers are locked to one platform that they have to focus on. The users though, they're really happy because they get an app that is native and it performs really good on their phone. But it's also really expensive. You have to have dedicated teams for each platform. So on the other end we have a solution where we try to squeeze it all into one solution. We usually build a web solution and put that out as our mobile application. So from a developer's perspective this is actually better. Because you get to do something that is on all of the platforms. And all of the developers will be able to span across the entire platforms. For the company they are also happy because their costs are lower this way. But the end users, they are not that satisfied. They often, I just say often, get a poor performance. And they get a solution that is not optimized for them and for their phone. But instead try to squeeze one solution out to three different platforms. So what is the solution? Well of course, so in this case, and because we are going to talk about Xamarin today, Xamarin is the solution here. There are multiple other solutions. But we find that Xamarin is the best one for this. So we see three key elements why Xamarin is the best. First of all, we get to write native apps. The apps we develop in Xamarin are apps that are compiled towards the different platforms. And they will run as native apps on the phones. They perform like native apps because they are native apps. And the user will see a user interface that is optimized for each platform. We also see that the developers get to use one language. They will be using C-Sharp and Visual Studio. And we will see that developers can go from doing back-end to do middle-tier to do front-end or mobile development. As long as they know .NET, C-Sharp and can work in Visual Studio. So it is a really flexible solution for companies and for the developers. And we have the reusability in the code. So this is most likely the key selling point for Xamarin here. We can write some code and we can reuse that code between the different platforms. Xamarin themselves say we can reuse 96.1. Well, I guess that is the marketing percentage. And they have some solutions where they have proved that they actually can reuse 96 .1 of their code in the apps between the platforms. Our experience though, say it varies from project to project. But normally it is between 60 and 70%. If we use Xamarin.Forms, that I will tell a little bit about later, we see a higher number. And then we might get up to 80 or 90%. So how does Xamarin achieve all of this? Well, Xamarin exposes all of the controls that we see in the APIs from iOS. From Android and from Windows. And based on that we can use those controls and use them to build applications for the phones. That we would do if we did it in Xcode for example. And anything that we can do in Objective-C or in Java, we can also do that in Xamarin using C-sharp. So, we see two different types of Xamarin. The first one that we used was the one called Xamarin Classic. Xamarin Classic is where we can build all of our business logic in .NET and C-sharp using portable class libraries. And we will have a project for each platform that compiles against each platform. And where we will have all of our UI. So at Xamarin Classic, no UI is reused between the platforms. Only the business logic. And that's where we will have about 60% in a normal project that we can reuse between the projects. So on Xamarin Forms, being a Xamarin solution to how to build one app that can run on all platforms. It's a little bit different story. Because again we have the 60% reuse from the business logic. But on top of that we have the Forms layer. Being where we are using XAML to build our UI. And that UI is actually compiled to each platform automatically. And if we have some differences in the different platforms, we can specify that in each platform. So this brings the reusability up to a really high percentage. But Matthias, now it's time to see some code for the rest of the talk. Enough slides. So, yeah, I'm trying to hook up. Pull this out. Yeah, I'm trying to put it in my computer. So the first thing Matthias will try to show us here is how we in Visual Studio easily can create a Xamarin Forms project that we can actually run and reuse on all platforms. Yep. It doesn't look that good at the moment. Let me just... Like that. Great. So what I'm going to do first, I'm just going to make a whole new Forms project just to show you what you get out of the box when you're working with Xamarin Forms. So I'm just going to create this new one called App9. It's going to take a minute or so before it's ready. Can you elaborate on why you're using it? Why does it work? Yeah, well, so the two are really similar. But Xamarin themselves recommend that we use portable. So that's more or less why we're using that. So Matthias, while we wait, can you... Any good jokes? Yeah. Yeah, okay. How many developers does it take to put in a light bulb? Isn't that how it is? Damn it. I think it's ready. Yeah, perfect. Okay. No, Matthias. So the joke is how many developers does it take to change a light bulb? Oh, yeah. Oh, I don't know, Thomas. How many? None. It's a hardware problem. Do you have one more? No. Luckily, I don't. Crap. Yes, please. The iOS part. How does it build it? Do you need, like, an online iOS or something? Yes. Really good question. So there's a limitation when we are building. As you can see, Matthias is running on a Mac and I'm running on a Windows machine. The Android and the Windows we, of course, can compile on a Windows machine. But if we're going to compile iOS, we need to do... We need to do it on an Apple device. And there are multiple solutions for doing that. So Matthias is running Parallels and can use his own Mac to do that. The way I work is I have a Mac and Cloud solution where I simply have my build host up there. And another solution is, like, to have a Mac Mini or something like that. That you can use as a build server. Yeah, exactly. It's a little slow, but it works. So the way Xamarin works when you're going to build is that in the old days, it actually had a little agent that ran on the Mac. It used to compile through. But these days, they have evolved a lot. So you don't have to have a separate program as long as you have Xamarin. As long as you have Xamarin installed on the Mac, that'll work for you. Chris? Yes? Why does it take so long? So what it does here is actually creating a lot of projects for us. While it does this, I can explain what it is that we're going to see in a minute that it has created for us. So the way Xamarin Forms works is, first of all, it creates one project that works as our shared object. So we have a shared project, or our portable project. This portable project is where we put all of our shared UI that we are going to use. It also creates a project for iOS, one for Android, one for Windows UWP, one for Windows 8.1, and one for Windows Phone 8.1. So that we are using this shared portable project. This project can easily compile towards each platform. So Matthias, maybe you should just take your existing app and show the content of that. Yeah, I guess it's just my computer that's a bit mad at me at the moment. Okay, so I'm going to do that instead. So this is the example I want to show you, which is an example made in Xamarin Forms. It's one of my finest pieces. It's called the High Five app, which enables you to perform virtual high fives across the internet and across the entire world. It's fancy, I know. And the way we do that is simply by... Okay, wow. Yes, would you like to shut down anyway? Shut down. Cancel. Okay. Yeah, the way you do that is that you send... You execute and send out a high five on the internet with your name attached to it. And if someone else has done the same in the same short time span, you will perform a virtual high five. Yeah. So let me just close this again. Or do we want to speak about... No. Perfect. Perfect. So here we have my solution. And what I've done so far is I made an API, which is hosted up in Azure, that handles all our high fives. And I also have this business logic down in my portable class library here, where I have my view models, since we're using model view view model pattern. And this is where you have your reusability, your 60% reusability, right? Yes, exactly. And up here, we have our forms projects. Which we tried to make just before. And here you see we have an Android and iOS and universal Windows project, and also Windows and Windows Phone 8.1 projects. Which are all pretty nice. But the most nice thing about this is that we have this portable class library for forms. And it's here that we're going to use and going to make our... We have this as our code base, shared code base for all the forms. For all the platforms, which is in C sharp and SAML. So let's just try to see how it works now. This is just a whole new project, so it doesn't have any fancy things inside of it. So let me try to build this one. I need to still connect to my Mac in order to run it on iOS. Of course, we can also do it in the universal Windows project while we wait. Ah. Let's just do that instead. So, okay, so I put an image in already. But that's it. And then this is what you get when you're off the box. Made a new project. We're going to make a new forms project. It's just a plain page with some text on it. So that's not very interesting. So we want to put some vitality in it. We want to put some nice colors. You know, we want to put like a text box and stuff like that. We'll take that in a minute. So first we need to make a portable class library. We make a new SAML page. And in the SAML page, we call it Hi5 page. We don't have anything yet. Just a grid inside a grid. And then if we go into our app class, which is the class first we constructed when we started up the app, we are going to remove this, which is already made out of the box, which you just saw before, the text with welcome to SAML informs. And we're going to replace this with my SAML page, the Hi5 page, which simply just has a background color, a title on it, and then it's added to a navigation page, which provides us with this navigation bar on top of the screen, which you might know from iOS. And we set this as our main page. So if we try to have a look, now our iOS should work. We can try to run it here just to see that it's running and it's building. And we go over. Since we're in parallel, we're going to see it over here in our simulator on iOS. In a few seconds. Any time now? Yeah. No more jokes, right? No more jokes. Okay. Sadly. And there it is. It's the splash screen. And then in one, two, three seconds. Yeah. And there it is. So we got like our, yeah, thanks. We got our page with some nice colors, of course. And it says in the title in the navigation bar, it just says, hello, Code Garden. So that's very nice. But now we want to put some content inside of it. We want a text box where you can put in your name. We want a button where you can execute your high five. And we want some text to show whether or not you high-fived successfully. So let's try to do that. So we go back in our portable class library and we go into our page. And I've been cheating a bit from home. So we're going to take this code, put it up in our grid. And as you see here, we have three controls. We have an entry, which is the same as a text box. Then we have a button, which we call high five button. And we put an image inside of it, which was the hand you saw in the beginning. And then we have a label, which at the moment just says welcome for now. We're going to change that later. So let's just try to have a look. Okay. And while we're waiting, you can see up here, even though you share all your UI code, you're still able to go in and make some platform-specific changes for the sample page. Like up here, we actually have a different padding for each platform, which is different on iOS. So let's just wait a few seconds. And bam, there it is. It looks awesome. Yeah. I can put in my name up here, Matthias. I can press a button with a hand on it. And so cool. So let's just try to see how this is on the iOS. So if we try to do the same and look at the Universal Windows project as well. Here it is. Yeah. And then you might see that we have our text box. We have a button down here. And we have a text down at the bottom. But it kind of looks like a Smurf hand rather than like a normal hand. So I would very much like to change that. But actually, I'm pretty satisfied with how it looks on iOS. So I only want to make the change for the Universal Windows project as well. And we can do that with Forms. Like we're not locked in to have the same shared UI. You can go in and make some changes platform-specifically. So how we do that is that we go in into our Forms portable class library. Since how Forms work is that you have these Forms controls which you put in your page in Forms portable class library. And then these controls are then rendered natively on each platform, which gives you the same appearance, the same behavior you would expect on the target platform. So what we can do instead, we can go in, make a new button, which I call ImageButton. I found that appropriate. It doesn't do anything different than just derive buttons. So you will still have the same button as you saw before. But I can go in and make a custom renderer on one of the projects. So I go into my Universal Windows project. I go in. I made a class here called ImageButtonRenderer. And what this does is that it goes in, takes, derives from the button renderer, which you normally use to render a button. And as an attribute, you put up here, you specify that whenever I use an image button on the UVP project, I'm going to render it with my ImageButtonRenderer. So down here, I then specify how this image button should look, or should be rendered. And basically, you just change some properties, and I take the image and put it as the whole content of the control. So now I should, of course, just go into my page and not use the... Now I'm up in the portable class library again. I don't want to use my button. I want to use my image button. So now I'm going to render my image button differently with a bigger image. I hope. And there it is. Awesome. And this is on the Windows project. So again, I can wipe my tears. I can make high fives. But nothing happens yet because we haven't made our bindings down to our view model. So I think that's time to do that. So in order to do so, let's just say... If we just take a quick glance at our view model, which we have down in our portable class library in our business logic, we have this high five view model, which has some text in it. It has a property which is a high five message, which presents the result of our high five. We have the name property, which we're going to bind our text box to, or entry as we call it. And then we have a high five command, which we're going to bind to our button, which executes. So if we just try to go up back in the portable class library, we just want to put in these bindings, which we can do up here. So I put in, like, for the entry, I put it for the name. And for my button, I want to bind the button command. Okay. That's good. And then I also want to do it for the... Instead of just having the text say welcome, I want to have it bind to the name. So I put bind to our text result. So now it should work. But before we try it out, I just want to, like... Like, it needs some more vitality. It needs some, like, some bing bing, you know? So it's going to be a cool app people want to download. So first off, if I get a successful high five, I want, like, this grid. I want it to show. It's just a white grid that wants to show.
