 Good evening ladies and gentlemen, if you can give me two minutes so I can set up, it will be very, very quick. Mostly quick. So are we? Right. All right. We're ready. My name is Benjamin Levy. I am an entrepreneur into virus based on Bob's currently in IT, but I might turn into a Schmidt later on because it's really fun. And we've got to stop or start eating pandas that are not actually alive, which would be great. But anyways, what I am going to talk about today is about PCL application configuration for Xamarin forms in C sharp. So I don't know how many of you already use Xamarin at all or mobile development in any no mobile at all. Well, unlike, let's say, web application, APIs or desktop application, the difference between each platform is quite, quite big. And there is a kind of a bit of a challenge to try to keep it as simple as possible while configuring an application. So let's have a look at that. So configuration in the Donet world in ASP.net. For instance, we have the good old web config system configuration building transforms. Let's say that you have multiple deployment to debug UAT production, whatever you'll be able to use transform in ASP.net. For instance, or a web API to be able to deploy to those at build time or later on if you're using a deployment server, server like Octopus, you'll be able just to get those renderers and to transform your package later on. On WPF, Winform and services, you can have a mix of app config settings, settings, system configuration and use some third party libraries such as Loschita to transform your configurations into the settings that you actually need. Silverlight, we've got XAML web config, system configuration and also we have build-in transform. So that's kind of relatively sweet. Whoever you want to deploy, you'll be able just to get your configuration, stuff it there and then it will be transformed at deploy time at build time. That's all very great. So in Xamarin forms, obviously we are developing mostly using a portable class libraries. And if you have been developing with PCLs, you will know that it will be only a subset of the full .NET API. A couple of things are not included. A file system for instance is not really there because obviously each application which device each appointing system will have a different file system and that will be just a pain to unify it and it will literally point less to stuff that into the PCL API. SIFTAN.configuration for instance is another example because each platforms are quite different as we'll see later on. This is just simply not there. So pretty much as I mentioned each mobile platform has its own file management system. Each mobile platform has its own configuration management and also SIFTAN.configuration is a pretty heavy library especially when you're trying to create some custom configurations that is pretty heavy. So that might be a really good idea to not attempt to include it into the PCL library. So what would be the options available to configure our cross-platform app? So again as both Sol and Udara mentioned beforehand, we will end up in Xamarin forms having a PCL shared project that will have our view models, our views and just like any code that will access your API and so forth. And yes, literally the platform-specific project for iOS, Android and Windows form or else would be mostly empty shells. Well, it depends but mostly empty shells. So we've got literally three options, about options for configuration there. I'm talking about configuration within the application such as for instance probably the address to an API or just on an awesome settings just like the normal app config stuff. We have native configurations on each platforms. We also have constant configuration reader for instance and that is another option. And a unified configuration which is a little project I mocked up today that is actually already available on GitHub and that I might just package as a new get later on with other stuff. So let's have a look at the different platform configuration pros. So on native there is only one thing I can see really, it's built-in. You can just already use it out of the box. You don't need to write anything else. There are just a couple of differences that we'll see later on such as on top of having a normal simple application configuration, certain systems of roaming options that will migrate or just synchronize configuration between devices which is pretty useful. So the cons of native platform configuration is just one config per platform. If you are going to develop for iOS, Android and Windows Phone, you'll have to put that on the three platforms separately. There is no known Xamarin form support for this. So you can have a look at the documentation. You won't find much stuff there present. And different configuration APIs, the good old system of configuration, billowed by some of the developers, very simple. One configuration and the API, get your app settings or your config manager done. Here you'll have to just go native, do some bit of dependency injection if you really want to go this way, and you'll have just to learn how to do it. That's obviously a pain to maintain, especially if you tend to have large systems and many, many environments. No support for configuration transforms. So again, if you are using build and deployment servers and are expecting a package just to be delivered to your build server, to your deployment server and then just transform the relevant settings to then deploy to your environments, you'll be out of luck or you'll have just to script all that with your little hands. And it's obviously not familiar to the net developers. So again, this is something you'll have to learn from scratch. So let's have a quick look at what we've got natively. Native iOS config, we're using those files called PList, which is this kind of XML site repository. And we have some way to access this through the native iOS API doing this kind of stuff. It's not very exciting. It exists. This presentation will be online on my GitHub, so you can have a link to documentation if you're interested. And with config, I didn't even fill this part. You have the shared preferences that also exist, which is just like a key value per store. That's also another one. And then you've got the native UWP configuration. So you've got a few flavors here. The local app data, which is, again, good for persistency between app sessions. Roaming data, which allows just to synchronize your configuration between devices and a temp data, which is literally a cache. That can also, as a cache, be wiped by your user. So that's probably not a good place to put your configuration settings anyways. That's the way you access it. That's all very great and fun. No, I'm not going to do a demo about the native configuration because it's boring. So that's a good reason, I suppose. I'm going to discuss a little bit because we're going to get somewhere else. I'm going to talk to you about CoreApp, which is a little project, which is a wrapper around something called xlabs, which is where Xamarin is going to put some stuff in their main branch that happens before. There is quite a lot of goodies in this project, literally all the things that are missing. If you are into, let's say, Prism, if you've been doing a lot of WPF, that would be something similar instead of literally just looking at the view models and other views to handle the navigation and just stuff a lot on your UI element that allows you to separate the layers properly so you can access, let's say, an alert box from your view model directly via the navigation. Anyways, what it allows you to do is full control of the application lifecycle, unlimited dependency injection. I will get in details about it. There is a support on Xamarin on dependency injection, but it's not so great yet on Xamarin Forms. It allows you also to do some view and view model registration. On the demo we've seen a little bit earlier, I believe, by Sohail, the view model pairing with the view is kind of not really explicit. You just have to create your view, your view model, and then you will navigate to one that is paired with the other, and that will just happen, some magic will happen in the background, but you won't be able to do anything more exciting than navigating, and you won't be able to test it either. I'm going to show you. After this page, again, control on navigation. At present we can just really push and pop, but, for instance, the stack of the navigation won't be testable if you want to be able to test, let's say, your view models for a command that is going to produce some result of some sort, and that will ultimately result into navigating to a different view using the Xamarin Form built-in navigation that will not work. You need to be able to access a stack that is separated from the actual application navigation. And we do also have unified platform events, such as when the application goes to sleep, starts, wakes up, and that each platform will have a different way of handling it that is unifying it and makes the unit test testable. So let's have a look at a bit of code for what I've just been talking about. Code, code, code. It's not here. Hello? Oh, yes, of course. Okay, portable one. There we go. So this is just a very simple application that will later demonstrate how to manage application settings through the usual configuration manager API, cross-platform with Xamarin Forms. So let's have a look at what it is already. What did you do? Yes. Yes, no, I need to just go through another piece of slide. Sorry. Yes, so about the dependency injection on Xamarin Forms, we do have one which is called the dependency service. What it allows you to do is on the Xamarin Form shared project to declare an interface as you'll do with normal dependency injections and then create one implementation for each platform such as the camera, for instance. The camera will behave differently if you are developing on Windows app or Android or Apple, you will need to be able to have a unified hook through it. So usually you will just declare an interface that will have a method called takePicture, for instance. And then just provide a different implementation and then bind them when your dependency injection container will be just built and you will map your interface with your implementation for each platform. In Xamarin Form we do that this way by just using this kind of attribute on the concrete implementations of your dependencies. The problem with that is your dependency will only be meant for Xamarin Forms. Nobody else will be able to understand what those attributes are for. So if you are like me and like to share client and server code, for instance, that won't be able to be possible. This file will not be recognized and that would be a bit pointless. Also if you want to use the dependency injection service to make your choice like auto-fac, unity and inject, that will also be not possible. You will have to go with the one that is baked in the platform. Also if you want one registration method for all, for all your application ecosystem and for all the actual services that will be in the different platforms of your application, that will not work. And if you use advanced dependency injection features such as generic dependencies, which allow you to register some unknown generic services, let's say, that's not available. And if you want to register one concrete type with multiple interface, that will not do as well. But if you are quite heavy on class inheritance, having some core project, for instance, that will have a partial implementation of a feature that will have some other kind of more concrete implementation down the line that will also block you there. So what we got available again for reading is a constant reader. A constant reader is simply a simple reader that will just take a key and will then look at a switch statement that will just look up this key against what is there. So let's say I would like just to configure my connection string. So I will just pass to this connection string key that will then look into a switch statement, get like a constant and you get it. Well, it's not very elegant. Good thing it works on every platform and I will not really recommend it. It's a bit of a pain to maintain. So there is no support for configuration transformations. So if you want to have multiple environments, that is just... Well, you'll have some preprocessor directive, I suppose. That's going to be a lot of pound sign if and, and that's not going to be very, very fun. And you won't be able to alter that after a compilation, except if you start doing some extreme code weaving, but yeah, I wouldn't do that either. So let's say it's not very elegant. It's probably the one that is the most widely used so far in the Xamarin.Form community, I believe. DEMO, no, because it's also boring. That's why. Then we've got a fun one, the unified app one. So you just have one... It's literally a port of the app setting reader, but for the Xamarin.Form platform. So you just keep your XML file with your app setting and then add key. There you go. One config for all platform. You just need to stuff this file in your shared library and then simply reference the file on your platform project. One API, which is again simply... Well, we'll go through the API, but you simply just pass the key that you wanted to find, and that will fetch it. Familiar to the net developer. That's great. Support for configuration transform, all the same. So again, if you're using build server, you've got a lot of environments. You still will be able just to have your transformation at completion time through the code sheet, sorry, slow sheet library, or via a script that you'll have on your department server. And you'll be able to alter that after a compilation. So I think this is pretty good. Yes, because it's not boring. Actually, a little bit of that as well. In the meantime, somebody wants a monkey. Yay. I'd love to answer a question. How do you say monkey in Spanish? Google. Oh, come on. Really? Really, no? Okay. What's the name of the guy behind Xamarin? Oh, yes? Oh, yeah. Missed. Who is the guy that kind of found Xamarin and that did also the monoprojects? Who said that? Yeah. Yeah. Yeah. Hit. Oh, yeah. Okay. Two, four later. Got to save the monkeys. All right. By the way, I'm very, very happy Xamarin is kind of free now. That is just like very, very good. It was just like about a grand USD before license. Now it's just nothing. Like nothing. By the way, did I make sense? Was it just too quick or no? Did you care? If somebody's got the balls to say you care, you can get a monkey. No monkey then. Right. I did say balls. Right. So I'm not going to do some life coding. It's just something that I mocked a little bit today. So the idea is quite pretty simple. I'm just going to run it first. I'm going to run this one. I'm going to run it on iOS because I like iOS and it's a bit faster. So the idea is I'm just going to click on a button and that is going to give me a key from a config file, like a simple web app.config file. That's it. That's going to be cached as well. And also by the way, you can encrypt it as well. If you're afraid just to ship some config file that is in a plain XML, you can actually, because you've got full control over it, you can encrypt it, ship it encrypted. And the one you just actually run the app, you can actually decrypt it. And you can even decrypt it safely if you feel like it has a lot of ways to do that. Many ways. Is that running? Is it running? Is it thinking about it? Launching. Yes. There we go. So, yep. There we go. That was very, very exciting. I just clicked a button. It says hello from app settings. Have a look what app setting is. So, we are an examiner in form project, but it's been sweated with this kind of xlabs and a little library that I just shipped on GitHub today. And that will be newgeted. Think about prism, but in very, very lightweight. That will allow you to do roughly the same thing. We are in the app portable. Yes. So, that's our view model. If you're familiar with WPF, you probably will be familiar with commanding. By the way, if you are going to get into examiner in form, I really, really, really ask you to do something. Just lose the events. Let them die. Just like on click on whatever. No, please just kill them. Use commands. Commands are testable. They're good. And they are just like good for people in general. Events are just, as I've been there for a while, we just need to kill them. That's all. So, I do have like a few commands here. This command here is a special command. What I do, because I don't, I'm a bit lazy to write some commands all the time. If you're not familiar with commands, think about it as an action that you have security of execution that you can bind to literally any control on your example. And, yep, that's pretty much it. The good thing about it is if you want to test it, or if you are like a cucumberist or BDD enthusiast, or even a unit tester, you will be able to actually take your view model and then test the command directly. If you try to just test it on click, which is anything on behind on examiner in form, XAML, you won't be able to test it, and it is back practice in any case, especially if you keep on getting some new fresh developers. You won't understand a thing about what's happening in the code. Again, that's not a good thing to do. So, this command is simply just going to do something. It's going to execute this command, and that is just a prerequisite. It's true. We can execute it. You can also, in this kind of command wrapper, do some interesting stuff, such as before the execution of a command. You can tell, OK, I want to show a spinner after 50 milliseconds, for instance. If something goes wrong, I want to automatically log some thing to a logger, and I want to advise the user that something is going to explode, and you can do literally anything. You just need to step that into this nice little get command method, which is also shipped on GitHub, and we're using like a command delegate, which is like a good practice in the command world. Again, where you can just put all your interesting codes. OK. Hello. There you go. That's a command delegate we're talking about. So, we're just checking if it executes at the start, and then we can just spin a task that will be able to handle whatever you want to handle around this command, which is a bit more interesting than just clicking on an event if you ask me. So, let's go back to this co-application. No. Sorry. Where were we? On view model. There we go. So, we didn't implement that because we say it was not very interesting. And if we just click on the method itself, which is get PCL, what it's going to do is simply going to resolve something called the IconfigManager, and just get app settings, and it's going to get that the value that is stored in the file corresponding to this thing. Again, if you're not really familiar with dependency injection, here I'm just simply telling the program when it kind of starts spinning that anything, every time I call, I resolve this IconfigManager, I'm actually calling or resolving a single ton of type configManager. I can demonstrate it this way quickly. And yes, so here we go. That is how you do the things here. Instead of using the built-in Xamarin.Form dependency injection container, I'm just set up some hooks at every single level. So, at the PCL, at the PCL share library level, iOS, Android, and Windows Phone. You can literally register whatever you please. That would be available absolutely everywhere in your code. That doesn't have even to remain within the Xamarin.Code ecosystem. It goes everywhere. So here we're just saying IconfigManager is going to be of type configManager. By the way, if you're interested into generic registration with dependency injection, that's the way we do it. The delegate commands actually just takes two types, parameters, but we simply pass absolutely nothing and at runtime that will just be clever enough to figure out, oh, I just have like a virgin delegate command here. Let's resolve it. So, now if we go to configManager, we can see what's happening here. So, I actually made this one a bit extensible. It will be able to work with the normal app settings and then add value and then value, value. But you will be able to extend it to create any kind of custom, again, markup in your app.config because it's actually mapped to a simple Poco. We're mapping a Poco to a XML file and that just works like magic. So, the only thing I'm just doing here, I'm trying to, I'm loading an XML file which is done kind of here. And then I just, as you could have multiple configs, we load that into a dictionary and then whenever you try to resolve it, we know where it comes from and we simply get the key that is corresponding to this, to this stuff which is getting upsetting. There we go, upsetting that is we're loading this section, go to implementation. If the section is on the root, we just really want to get the root of the file and then we just take any configuration section that we have in real what it actually gets is, oops, sorry. There we go. That is the upsetting that is leaving in our PCL app demo app and that is precisely what is just getting returned by this configuration manager. So, ultimately you end up having a configuration manager that will work on iOS, Android, Windows Phone, any other platform using the good old app settings from the app.config file that you already have. This is cached. You can, if you just use Xamarin key value per store, you can just write it to the disk and just restore it whenever a user is going just to spin the app again. You can encrypt it. You can do just literally what you want because you just control over it, which is kind of cool. Yeah, that's literally pretty much it for this project. Again, I will give you the link if you want to actually get it, to use it for your development because actually nobody else did it yet and that's something that I needed really recently and that's why I'm talking about it today. There we go. I think that's it for me for this application configuration, I think. Do I have anything else to talk about there? Nope. Cool. Questions? About anything? Xamarin? Well, I've been literally looking with Xamarin at the time that just started existing in the new old times. I've been working with my team with Jason Smith that is developing, which is a lead for Xamarin Forms before it was in California and now they move to Seattle because Microsoft solved quite it. We've got a pretty good knowledge of the inside out of Xamarin so literally you can try to find anything at me and might have the answer. Ah, yes, there we go. You're the first to get the call. There you go. So, I started with Xamarin but I had a hard time compiling with making a compiling machine for the Mac and I moved on. So, is there any easy way to attach a Windows phone with a Mac for compiling and running on simulators? So, you're having a hard time compiling your application? Connecting a Windows platform with a Mac. So, is that the same Mac? Was that like a Mac that is... Are you using Mac Mini for that? Next up, maybe. Well, a good way to do it is just to use Parallels. So, you just actually use Windows as a VM on your Mac. That would be definitely the most reliable one. That's what I would recommend, number one. If you cannot do that, is your Mac Mini within your premises, your network? Yes. Well, there we go. Yeah, just install Windows on your Mac and just install Mac. Is there any cloud? Is there one test cloud? Xamarin Test Cloud. You want to know about it? Yes. So, it's pretty good. Xamarin Test Cloud, if you're not familiar with it, is literally a pool of devices that are attached to cloud-connected computers and you can actually push some BDD, which is PFCode-driven development tests which is written in Cucumber. To some extent, you may or may not be familiar, but basically, that goes along this. As an unauthenticated user, when I am on the login page and I put my username on the user mailbox and my password on the password box and then I click the log-in button, then I am directed to the welcome page and I can see on the top right corner, welcome button. So, that is literally what is Cucumber. So, that is really removing the fear of testing from people that are afraid of testing. This exactly is a text that I just told you. You just press a button that is going to create a scaffolding of things to test, so you don't even have to think about what to test. And then that's it. You just make your way up by Xamarin. That will be looking at a view model and then just look at the properties. Just simply call a command. So, I'm going to add the view model, my username, my password, and then I'm going to call the command login and then that is going to redirect me through navigation services that has been abstracted by using XLABS, which is a stuff I've talked about. If you just go playing Xamarin, you won't be able to do that. But by just using XLABS, you'll be able just to have a hook on the test navigation service and then you will be able to have a hook on the view model that is currently present. That's one thing. TestCloud will actually use the same test to simply input your username and password on a device and just actually run it through TestCloud. So, all you need to do is simply send your script, which is what I just told you in plain English, that is going to have behind the scenes a little bit of TestCloud specific for Gherkin or TestUI, that's what it's called, that is going to behind the scenes just tell the test runner to actually input some text and to click some buttons on the device. So, that allows you to literally test like, I don't know, ten hundreds of devices with just different operating system, different formats, form factors, whatever, and that will provide you as well with screenshots of when things go wrong or screenshots of every single step. So, you'll be able to figure out when your application is not behaving, if the UX is consistent, if the UI is just properly implemented for the MegaGIGA dooper tabs or just very, very small iOS watch. That is just pretty good. And now it's super cheap as well, right? Isn't it? The cost is only $1.99 per year. Yes, that's it. No. That would be good. No, I believe that with the MSN subscription, you just get like 25% or 50% off for something that is all right. And, yeah. Yeah, as of these days, there is a Xamarin involved, if you know now, it's in the US. So, there's some, something new will come out, hopefully with a, you can say this, it's good news, sir. Just stay tuned with Xamarin, okay? That's what I get. Yes, but then, by the way, Xamarin Test Cloud is not for testing Xamarin, it's just to test literally any single app. It is platform agnostic because we're not writing code against the actual application. We're just writing code about a runner that is going just to tap some buttons on one UI. So, in any case, very good. A lot of customers are actually, not necessarily using Xamarin, would be using it. How about one more thing? Yeah. So far, it's Xamarin is all for the C shop, right? Well, no, actually, I love F shop. F shop is great. Unfortunately, I don't know much about F shop, but there was one that was on the desktop, and he says the rest of it. C shop is great, but it's very busy. Yeah, but what about the support for the JavaScript framework like Angular, Backbone? Well, do you want to make all this opinion on JavaScript? No, you don't want it. That's good though. Yes, you can make it. That's good. That's good too. Wow, awesome. Before that, oh, yeah. But I don't believe I've got plans to do anything with JavaScript because it would be wrong. Just one point of that. They wanted to implement in C shop. For programmers that have this. Sorry. Yes, yes, yes. No, sorry, I really can't stand JavaScript. It's just type safety should be just like given. If you don't have type safety, don't talk to me. That's it. What are good resources to then look about Xamarin? What good resources actually is Xamarin? Platform already has got quite a shilling there. If you've got an MSDN subscription, you will have a link to the Xamarin University, I believe, which comes free for that. There is a huge support. The community is very vibrant. If you've got a question, just post anything on the forum. I can guarantee you'll have somebody replaying to you within not that much time, especially since Microsoft bought Xamarin. I support that a lot of Microsoft minions are going to help the Xamarin team and everything will go faster. It's a bot. Yes, a bot. Yes, yes, sorry. I've been fantasizing for Microsoft to buy Xamarin for the last three years. No, it happens. No, it happens. I can't register it. That's terrible. But yes, honestly, Xamarin forums are great. If you see any issue, yes, there's only one thing. Miguel, the ICASA, just really like Bugzilla. I don't know why. So it's just forcing Bugzilla on everyone, which I don't know. We've got JIRA. We've got a lot of nice bug tracking system. Bugzilla is not one of them. That's all. Except if you like, I suppose if you like common prompts a lot, or maybe, maybe, some extent. Xamarin forums, are they production-ready? All the production-release are good. Since release 1.3, they are fine. Before release 1.3, I wouldn't. But now when release 2.0, 2.0 a lot, it's really good. As both Soelle and Udara mentioned, they are very good. So there was a misconception on Xamarin forums, which was you cannot do what you have. You're just tied up a little bit, like an accelerator, or just a sensor, or this kind of stuff. No, the mapping is actually really, really open, and they keep on just adding some new features in order to make this mapping and customization easier. So for the line-of-business application, I think it's all good, because usually line-of-business don't really care about UX, or it just changed until at my last call. But I think if you don't want something overly pretty, that is still pretty, but just not like crazy. Xamarin forms natively as just all the control you will need, and all the animation you may need. If you want to do something slightly crazy, or really have a UX and UI guy that are really into pixel perfection, which, by the way, they should, then you use Custom Render Errors, FX, and that would be fine. And again, I mean, I wanted to give, like maybe in a couple of months, a talk about some best practices with Xamarin Forms, because that was a bit too long today to dive into. But I really strongly would recommend using Xamarin Labs, or like a wrapper for what I'm going just to put online, actually it's already online, or Prism actually released something for Xamarin, but it's not production ready yet. The reason why is if distance of tour has to be tested, and it has to be TDD, BDD, whatever, but tested first, otherwise it's just going to collapse, and nobody will cry because it was badly designed at the first place. So that, I think this little layer really allows you to do some great testing with Xamarin. There is something that is still not quite there on Xamarin Forms, but I actually solved the problem too, and I might just put that as well there. That allows you to do some BDD, properly using your favorite runner. So it would be the visual studio runner using a unit, Xunit, or MSS if you want as well. For example, there is a little issue that makes that, whatever, you need to actually run your test on the unit itself or on the simulator. That's a bit silly, but that's easily overcomeable. But production, yes, just go for it. If you haven't been doing an Xamarin Forms, six months time you can have an app out, I believe. Yep. Monkey. Oh, sorry. All right, wrong person. Yes, sir. Okay, my question is, do you have any controls or library for PoE and maybe for arbitration? Oh, no, no, no. Powering. Yes, control the library for? PoE, yes. Oh, yes, yes. So, luckily, oh, that's very noisy. Microsoft has been doing some really nice stuff with Xamarin indirectly through Azure, so you will have a lot of mobile services and a lot of support on Azure. You have some, I believe, some open authentication libraries for Xamarin. Xamarin, by the way, will have also a component store. It's got something called Recipes, which is where a lot of people post most of the problems that you may have. But ultimately, open authentication boils down to literally a couple of parameters on the header. You're sending what your username password. You get back a token. You keep your token. Ultimately, that's 15 lines of code to do it yourself, but people just wrote those 15 lines of code for you. I did. If you want them, I can just send it to you via email. We've got some pens. I'm not going to throw them because I might damage someone. But we've got two pens there. Whoever's got a question gets a pen, even if it's a question about cheeseburger. What is your favorite cheeseburger? Yes, yes. What are the challenges of migrating into the system? You already have the code base in Android and iOS. You want to explore Xamarin and see how to standardize to share the logic. Yes. What are the challenges? Do you have any advice? First of all, it depends on how it is on your app at the start. If you already separated your layers nicely, kept the UI in one end and the rest somewhere else through services, through whatever is your favorite practices, then that will be just like super fast because you've been doing some Windows on app, you're saying, right? Yes. And Android as well. So your team or yourself already have the knowledge of native apps. Native apps, yes. I always like Android apps. We have quite gone deep in it, and then we haven't written a lot of code out. That is good. So I would even recommend that to go and look at Xamarin. No, absolutely. If you've got native knowledge, that's going to be much easier because you'll be able to know what is actually the limits that you can push the framework to. You'll be able to see that you can achieve it. So again, as soon as long as your code is separated, you can actually take the code you already have that is non-UI and just put that. Is there any case study or something that I can refer to? Someone has already tried this, already published app. You have customers, and you want to try whether you can standardize it because we spend a lot of time trying to. Or you've been trying that code in different code bases, so it's missing a lot of time. Xamarin will help a lot. Xamarin will definitely help. And again, it's C-sharp. I've got a Donut background as well. That would be great. It's easier than people think. Mobile development used to be a little bit like five, six years ago, messy, to say the least, with all these different cross-platform companies launching devouts, product, JavaScript base, whatever based. And at the end, that was annoying because you had a hard time to be able to actually customize whatever you had. And again, if you were a developer, well, OK. You can go Java. It's easy, but it's just a bit slow. It's fine. Then at the time, Swift is better. But Objective C is literally not something that you really want to code with if you're a sane person. Yeah, maybe you can take it offline. Yeah. All right. I just want to add that. Oh, Pen. Thank you. If you are concerned that I spent six months on developing what I wrote up, and I spent another six months developing what I was at, why do I need to spend another six months developing the same in Xamarin? So the answer is you are just going to spend the six months in Android and iOS. You are not there to just do it six months and then publish it. You are going to maintain it for years then. So that's the main point. That's the main point when it comes to the cross-platform. You will maintain it very beautifully and using very nicely-totally, and that's fine with you as well. So that's the one thing that I want to add to your question. That's fine. I hope you have a good time. Thank you very much. Thank you. Well, that's it. Let's see what pen, couple of badges, and some stickers here for somebody. So can I get the pen then? I would like to say thank you very much to these speakers. And I would like to say thank you to Michael from engineers.sg for the recording. So if you miss out on anything, you can receive engineers.sg for the recording. Thank you very much.