 On today's Visual Studio Toolbox, Nish and I are going to talk about how you can take an existing WPF line of business app and mobilize it using Xamarin. Hi, welcome to Visual Studio Toolbox. I'm your host Robert Green and joining me today is Nish Anil. Hey Nish. Hey Robert. Thanks for coming on the show. Thanks for having me. All the way from Bangalore. Absolutely. That's awesome. Lovely city. Love traffic. Nish is a PM in the Xamarin team. Yes. He wrote a blog post, Visual Studio blog post a little short while ago, where you took an existing WPF app and you mobilized it. Yes. I thought, oh, that's pretty cool, especially since the app you used would be familiar to long-time viewers of the show, because it's an expenses app that I had used. We did a few shows on how to cloud enable an existing WPF app, and this is the app we used. Yes. I realized that was a shortcut to get your show. When I was looking for a blog post where I can convert a WPF app into a mobile app, well because there's a lot of dotnet code out there, legacy codes, a lot of people don't realize that they're all ready for mobile development today. We can directly port that code to mobile. So I was looking for a fairly simple app. When I say simple, I'm also talking about, it's not the UI which is simple, but then it's written in such a way that it is easily portable. Yes. Like it's following some patterns like MVC, MVVM, basically separation of concerns. Right. So WPF was my best bet because it would have followed MVVM and you could technically use the VM as well into Xamarin.Forms app these days, right? So. Actually, the app originally was written with that intention. Right. We said, when we build this app, we need to architect it so that if somebody came along and wrote additional front-ends, whether it was Windows 8 at the time, or UWP or Xamarin that would be easy to do. Right. So I picked that up and it was quite easy in a way to port it, but there were complexities involved as well. So I'll explain that as we hit that. Okay. So the app is WPF, it talks to a WCF service, talks to SQL Server all locally, of course, the SQL Server would in real life live on a server somewhere with the WCF service. Yeah. Then what we did in the Cloud Enabling is we took the data from SQL Server and moved it to SQL Azure, then we took the WCF service and published it to Azure, and then left the WPF app alone. Yeah. It's talking to WCF in the Cloud, talking to data in the Cloud. So then the idea is that you could have any client like a Xamarin client talk to that same thing. Absolutely. I mean, there's one thing that I changed in the backend. I'll tell you the reason why I did that as well. Technically, you can take your Xamarin Forms app or Xamarin app connect to a WCF backend, which is fine. But when we are talking about mobile apps, we're also talking about a very disconnected scenarios. Yes. Right. We may be offline, people are doing the transaction, you're going offline. Thanks. So when I looked at it, your backend was fairly simple as well. So I could reuse that backend code to build the Azure mobile apps. Right. So I put it to Azure mobile apps first, the backend, it was very straightforward because you had the data architecture. So I just have to expose the endpoint and then enable the offline sync for that. Okay. Cool. So I did that first and then I wrote the WPF app connecting to the mobile apps using the Azure client SDKs. Yeah. So that was fairly simple. Excellent. Yeah. So talk us through what you did, what you ran into, what advice you'd have for people trying to do this, how does this all work? Yeah. The first thing that I want to tell is, every app is different. So the approach should be the same. The complexity may be different. And also when you're porting the app, the first thing, yeah, you are getting the benefit of reusing the code, but also you have to give importance to the mobile platforms, right? You need to see how you can embrace the platform features, not just reuse the code. Sometimes the code is great for reuse. I'll tell you an example in WPF. We have this huge real estate, right? So you have buttons here, you change combo box somewhere. This title bar changing, the status bar changing. There's so many things happening within the large real estate. When we're talking about mobile apps, we don't have so much real estate. We're talking about four inch to six inch phones, people are using with a very less attention span. So you want to be very creative in how you want to present the view to the user and break it down. So that means some of your code are reusable, but they need to be broken down in such a way that it is ready for mobile. Right. You want to write a mobile app that looks like a mobile app. It doesn't look like something that you ported to run on a device. Which, I mean, that's a good first step. But you're going to wind up with an app that doesn't really look like it belongs. And then if people have to use it, fine, you can get away with it. But you really should write an app that not only takes advantage of the platform, whether it's iOS or Android or Win 10, but also write an app that looks like other apps and behaves like other apps so that people, A, know how to use it and be immediately comfortable with it. Absolutely, absolutely. That's right. So, do we go ahead and explain this? Yeah. Okay, so this is the awesome WPF app, fairly simple, but it has its own complexity within that. So we have this, it's a simple expenses app where as and when you incur charges, you create a new charge, put in your build amount, transaction amount, and then go ahead and save that, right? So once, when you are time to submit your report, you go to the reports and then create a new report, add those expenses that you want to do, add here, right? So you have to create new, oh yeah. So you have, yeah, you could actually get the associate charges when I add it there and then save it and then submit it to be your manager for the reimbursements. So this is fairly simple. Now, first thing what I did to port this app is to make it mobile. So let me show you the app that was built finally. Okay, yeah. So then we can go and talk about the other things. So your app didn't have the authentication mechanism in the WPF space, which I was looking at. So we could now, with Azure Mobile Apps, you could technically go and implement Azure AD directly because there is mobile apps done. So for this demo, I haven't implemented that, so I'm just going to skip that, right? So once we go into the expenses app, you will see a very similar UI that you have seen there. But in the sense that you will have similar tap and other things, but the way it is placed is very different. So you can see that. So these are my charges right now. So if I want to go ahead and create a new charge, I could just go and create a new one so you have the same old stuff, right? So you pick up the category. If you're picking a taxi or a meal, let me just go do that, right? So I'll just say Uber. Build is 20. There's a transaction amount, oops, 20. And some notes there. So I came in from Belvedere this morning, so I'll just use that to Redmond. And then just go click save, right? So what it's doing right now is it's actually connecting to the Azure Mobile Apps backend. And if you go back into the backend, you can actually refresh this page and you will see this connection updated here, like the data updated here. So if there was no internet connection, it would still be there and it wouldn't have synced. So that is the advantage that you can make use of when you go with mobile apps. So if I open an iOS app or a Windows app, which obviously comes from Xamarin.Forms, you could see the same data reflecting there. So technically you're building all the three platforms in a single chart. Right, because the mobile apps have really good support for offline sync, using SQL Lite on the device. On the device, yes. Right, so yeah, then there's like, you can go to the reports, you can add this report. So if I wanna create a new report, I can just go ahead and just create the report. Add the expenses. You can see the differences between the UI that we had in the WPF and the mobile. So the advantage of now moving to mobile is maybe I don't have to really key in the charges. I could just literally scan the bill and we can use the cognitive services to convert the image into the text and then create a charge for it. It makes life so simple. So yeah, so that's what I did so far. Okay. So now let's look at the code real quick. What, how did I do this? Well, I could technically, let me just open your code first. It's the WPF app. Okay, so there's data, basically a separation for the data. And then there's the WCF app, which I haven't really used it much except the data layer because I just put it into mobile apps, right? And then there's the WPF app. So now how do you know which all these things are really portable, right? Well, clearly everything that is not a view and not platform dependent, it's portable. That's clearly, it's easy to understand that. But there is an amazing tool called Dotnet Portability Analyzer, which you can actually download from this website in the Visual Studio Extensions. You can download this and go, once it gets installed, you will have that in your Visual Studio. So you can just say Analyze Portability, Project Portability, and yes, I wanna stop debugging and we'll see how. Right, because this app is written on full.net framework, probably four or five might even be earlier than that. Oh, yeah. It's a track of time. Right. But you wanna run it on Xamarin, you wanna target.net standards. Yeah. So you need to know if there's code in there that isn't supported in standard and therefore won't run on in Xamarin apps, correct? Right, yes. We need to know what exactly doesn't run. So I can just open this. This basically gives you a report in different HTMLs and Excel format and things. So it's easier for us now to take a look at it this way. So we'll just open the Excel sheet. So one thing to understand is this is gonna give you a fair estimate of what your project work is gonna be looking like. So you can see that. So for dotnet standards, it's really 68% and for Xamarin Android, it's around 79.17%. So this says that of the code in WPF, of that code, 68% would be found in dotnet standard and close to 80% of it would run. On Android and iOS. On Android and iOS, okay. So I did not. So is that a dauntingly low number or is that good? It's a good number because if you look at the WPF app, I mean, if you go to the details, all the things that is available here, they're all UI related, like their message box, this grid, you would use data grids and all that kind of things, right? So, I mean, those are not anyway supported. So we need to write. You wouldn't be reusing them anyway because you'd be writing this in Xamarin Forms XAML. Right. I mean, XAML is XAML, yes, but they're not literally the same. Right. And you also had a data layer there, right? So that would have much better thing. We can just go ahead and look at that too. I would predict that would be, that would should be close to 100. But let's find out. Oh, let's find out. We're not opening the same report. How do you know which one it is? Let me open that. Let me clear this place. So it's easier too. That's gone away. We can just start off here. So we'll do the portable analyze this project. Oops, not the signals. Cool. We don't, okay. So I think we'll go with the number, maybe the eight. Oh, it won't be the number, but it is. Yeah, should be this one. That needs a clearing there. Yeah, so you can see that. All right, cool. Yeah, because there shouldn't have been anything in the data that wasn't, because we wrote it fairly standard. So you wouldn't expect anything in there that didn't move along. Okay, good. So this is a good estimate for us to know what's the kind of work that's ahead of us. Now we will start porting that. So the easier way to do that is to create a new app, File New Xamarin Forms app. So you can just do this File New project. Oops, let's go to one which doesn't have. We do File New project and open cross platform, choose a mobile app and then go next. And you will be thrown in a view with, are you starting with a blank app or a master digital? I'll always choose a master digital because we do have multiple pages. So it will give us an easy tap view. And yeah. Are you a shared project or a.NET standard guy? I don't know, I mean I started doing Xamarin much before the.NET standard came in. So I was more a shared project guy because I was not choosing PCL much. But then I continued to use that, but.NET standard also is better. I mean, it's a charge, right? Yeah. So yeah. So I choose the shared project and then click okay. So if you want to back in, you can just include an Azure back in. Which you did. So in this point, would it be easier to create it yourself or to check that and let Visual Studio spin it up for you? You can check that and create a basic project and then you can dump in your code and then wipe it up in the right way. That would be the right way to do it. So I'm gonna, not this right now. Go back to the My Expenses app. Okay, this is my app which has the shared project. So all the things that I have ported from your project including some of the view models. I mean this is the most beautiful thing. I mean you can port an application from WinForms too, right? But WPF you have view models which are clear separation from the user views, right? So yeah. So you can take that. So I also retained the view models like as a legacy view model and I also wrote a couple of other view models. I'll tell you the reason why. WPF has a large view with a large real estate. So view models work for the entire view model, the entire view, right? So it is having ribbon related tasks, it is having the other ones. So I had to split up. So what I did is I created new view models and reused those view models that was already there. You can completely rewrite it if you want to. It's just technically moving the codes around. But just to show that hey, I'm not touching this code at all. So I went with this approach to keeping the legacy code as this. Okay. Yeah. And then I created view models separately for each pages. So yeah, you have the app.apps.zamo page which is the starting point of it. And then I go into the main page where I'm setting the tabs and that kind of things. So you can see that this is my end point Azure Mobile App URL. Yeah. That's where all the data is coming from. Yeah. So yeah, that was pretty easy to do that. All right. Yeah. Is there anything else? So let's take a look at some of the views. Yeah, sure. These you had to basically redo from scratch? Oh yeah. All the views are written from scratch. So you can't really use the .apps.zamo. There's no real good converters out there, right? Not it. Maybe. Yeah. Maybe in future. Maybe. Yeah. So as of now, no. And but it's fairly easy to do it. But you've got labels, you've got text boxes. I mean, things are called a little bit differently. Yeah. StackLad versus StackPanel, TextBox versus Entry. I mean, it's pretty easy to figure out the basic things. So it's not that hard to figure out how to do a relatively straightforward page. And then obviously, if you want to do the harder stuff, there's learning involved. But to get to at least a first pass on it, again, it's XAML. It's XAML. So if you are familiar with WPF, you will just pick it up real quick, very straightforward. Like maybe this StackPanel, it's StackLayout, but the rest of the things remain the same. OK. Yeah. So we have the views here. And it's clearly separated with view models and services, helpers. There's a ton of code that has been reused. And I don't have much of the code written in Android, iOS, and UWP, because everything that I've taken it from the expenses app from WPF, it's all in the shared project. Right. Yeah. OK. So what did you do with the service, the WCF service? How did you get that to be a mobile app? So what it did is that's on a different project. I could have just added it here, but I'll just explain that. So you have the data layer, which had everything doing it. It had a repository service and things, right? So you had a repository service. So what I could do is I could have the Azure mobile app endpoint with these pages, like charge, expenses, and things. And when they got the request, I used to remodel that request directly into your repository service and reuse the regular method that you were using already. So it's a separate project type, right? Yeah. Yeah. OK. Can you bring that up? Yeah, we can do that. And how do you just show us in the new project where you would start with that? Yep. So this is the mobile app service backend project. So it has the model's data. So you have these data objects that you already had, like charge and client things. So I'm reusing that here. And then there are controllers, which is going to receive your request, the ones which are coming in, like charge controller, employee controller, expenses report controller. So I created the endpoint, and it is basically winding up behind the scenes to the data. So did you get to do all of this in Visual Studio? Did you have to go into Azure and create the mobile app first? I could do everything in Visual Studio. Because when you create a new project, right? You create an app. Let's see that. Go to File New Project and show us where that is. Oh, you mean the backend? Yeah. So OK. The backend, what I did, I had it on a different project. So when we created a File New Project, there was something called Include Mobile Backend. So I enabled that. So that would give me the project type. Then added Azure Mobile Apps related new gets. And then I started from there. OK. So you let Visual Studio do that part for you. It spun that up on Azure. It created that in Azure. And then you took the code from the WCF service, because the way you talk to the database stays the same. Whether it's. It's the models, mainly. The models. Yeah, OK. And then the code for talking to the database, was that reused from the service? No. Because I was using, there was a direct connection with the, it is using an entity framework to connect to the SQL database. So I just reused the same thing. OK. What I did is I took the models and attached it to the end points, so that that will receive all the data, and then it goes straight forward, say. OK. This mainly I did it to make use of the offline thing capabilities. Right. Yeah. OK. Cool. So what was the, what were some of the hardest parts of this, if someone was going to do this, what's your advice on where they can expect it to take a while and where they can expect it to just be easy? Yeah, I mean, first thing is to don't expect. Straight forward. I hate using the word easy. Yeah. Straight forward. Straight forward way. Yeah. The first thing is to have a mobile mindset. When you look at portability, trying to port the code, don't look at, I'm going to reuse the entire thing and try to fit in there. I mean, it's a good part. It's a good thing that you can reuse a lot of things, but it's also important to see being creative. And don't look for a magic brand which is going to just convert everything for you and then give you an app because that would, like, waste your creativity in that. Right. So you should look at a code that can be ported and then look at building mobile apps in a way it is meant to be built. Like follow the design principle. There's documentation on Xamarin site. There is enough documentation on how do you understand iOS versus Android, platform differences. So go through those things and then keep those mobile mindset in mind. Then it will be easy for you to port any code. If you're looking for a magic brand, that's not a straight forward way. And you will find it really hard to port it because you're always thinking about taking the code directly and, you know, baking in. You always have to think, OK, let me take this code and how do I make it better on mobile platforms. Right. And reuse them. Right. And in terms of learning what a good UI is, I think the best recommendation is go look at a bunch of existing apps. Yeah, absolutely. Go look at, in this case, go look at expense report apps. There's probably 1,000 of them out there. Yeah, exactly. Go look at them and see what they did and adopt techniques that you like. Yes. Adjust techniques that you think are kind of there and don't make it look like the WPF app. Exactly. So this is what I do. I'm not a designer myself. So my app may not be the best in design, but what I did is I looked at the other expenses app, how are they built, and used the same principles to just build the app for this. Right. Yeah. Cool. So this code is out there on GitHub? Oh, it is. Yes. Well, we'll put a link to that in the show notes, as well as to the blog post. So basically, it's a WPF app. So you know XAML, you know C-Sharp. You basically know what you need to know to start down the path of building mobile apps with Xamarin because Xamarin Forms is based on XAML and C-Sharp. Yeah. Yes, as we said a couple of times, you've got to learn the paradigm. You have to learn the mobile environment. Yes. But in terms of the code, huge amounts of your code are totally reusable. Absolutely. And this is kind of a good way to start down this path. And again, we're not getting rid of the WPF app. It's still potentially the main way people enter expenses or do whatever it is they're doing. It's a lot of business that, which means it's running the business. But you have the ability to add mobile front ends to it so that people can, as you said, do their expenses when not at the office. You know, you're at the kid's soccer game and you remember that you didn't approve expense reports. So it wouldn't be cool to be able to take out your phone and go, oh, approve, approve, approve, reject. And in that sense, I'm caring a little bit less about the UI. It needs to be usable. It can't be horribly ugly. But it doesn't have to be a five-star app. If I can take out my phone, authenticate, approve expense reports, put it back in my pocket, while I'm watching the kids play soccer or standing in line at the grocery store. That's a lot of value that you can bring to the app at your company without ever having to even talk about tossing out the code you already have. That's true. That's right. Most importantly, keep mobile mindset whenever you're putting the apps. Cool. All right. Thanks for coming on and doing this. Thanks so much for having me, Robert. Hope you enjoyed that. And we will see you next time on Visual Studio Toolbox.