 So do you guys know that you came for this talk? Yeah, C-Sharp on Android? How many of your Android developers here? Wrong question. How many of your native Android developers here? OK, how many on the hybrid's front phone gap? Perfect, C-Sharp developers. Oh, just him, just him. All right, there's one person there. Anybody who's tried Xamarin before? No? Perfect. So this is going to be a very primer session to Xamarin, C-Sharp on Xamarin. But how many of you are ready to learn Xamarin? Sorry, C-Sharp. C-Sharp. It's like Java, right? Brother from another mother, that's it, right? Better than Java, all right? OK, so if you know Java, you would find it at home doing C-Sharp. All right, so my name is Nish, and I work as a developer evangelist at Xamarin. And I'm also a Microsoft MVP for C-Sharp. That's why I've been advocating C-Sharp a lot, but I love Java as well. So my Twitter handle is nishanl, and my email is nishatxamarin.com if in case you want to reach out to me after this session. So just to give you, connecting the dots, Xamarin. How many of you heard about Xamarin in the past one year, right? Past three years? Anybody? Three years? Nobody? Ten years? No? Nobody at all, wonderful, right? So it was never there 10 years ago, but I want to connect this dot. Anybody know this project called Mono? Yes, few of us. So the guy, Miguel de Icaza, he has been a contributor to the FOS community for a long, long time. He's famous for the Genome project. He had this, whenever he saw this dot in the implementation submitted to the ECMA standards, he was like, hey, I want to build this. He's a Linux geek, and he said, I want to build a compiler for this in Linux. And that's when everything started. And he named it as Mono. Mono is a runtime, basically a dot in the implementation on Linux. That's when it started. So in the year 2001, a company called Ximion was found along with Miguel and Matt Friedman. They founded this company. After two years, it all happens to all the startups. And a quiet thing happened. And it was Novell, which took over the Ximion. And because Mono was in open source nature, it got ported into various of the platforms. And two of the platforms that you would know maybe is the Mono for Android, and also known as MonoDroid, and also Mono for iOS, which is MonoTouch. So these were the two platforms which came out of Novell platform. And in 2011, the Mono team was sent out, definitely a layoff. And that's when the Xamarin was found. So Xamarin is the new name to the old Mono team. So we have the same team which built Mono for ages. Cool. So just to give you a brief, what Xamarin is today, Xamarin is focused completely on mobile development. It is focused on iOS, Android development, in C-Shell. And we are also a big supporter for this technology called Calabash. You guys have heard about Calabash, automation testing for iOS and Android. So we are big supporters for Calabash as well. And we have something called a test cloud where you can take your test scripts, automation test scripts, and run it on real devices, thousands of devices, and test your Android and iOS applications. Cool. All right, so talking about mobile approaches, how many of you have an Android phone here? Great. iOS, iPhones, iPhones, yeah, quite a few. A Windows phone. Great. Great. So how many of you have all the three? Great. You may be in a serious business, right? You might be in a serious business. You own a shop or something, yeah? OK, so when you build for mobile, right? We build for consumers at the end of the day. So we look at three platforms at the least. One is the Android, the Windows phone, and the iOS. So as a developer, if I want to build for Android, you guys know. You use Eclipse or Android Studio and then use Java as a language and build this application. And similarly, if you want to build on iOS, the problem is you as a developer may not be able to build it, but if you are good enough, you can learn Objective-C, and you can use this tooling called Xcode, and then build this native application in iOS. And same with Windows, right? There's a completely different tooling. There's a Visual Studio, and there is .NET and C Sharp there. Completely different tooling. And this is exactly the reason why. Today we have something called as right once from anywhere approach, right? I mean, you would have heard about this. If you're a building native, your manager would have come and said, hey, we want to ship things really fast. Why don't we look at some other cross-platform solutions? And one thing which comes up all the time is right once from anywhere approach. What is this approach all about? At the end of the day, it's nothing but a simple web view put in front of the user 100% height, 100% width, and all that this thing does is takes HTML, JavaScript, CSS, and then displays that to the user as an app, right? Now this is good for small apps, but can it scale? I don't know. It's too early to talk about that. So Xamarin took a different approach. As you know that we have a runtime which runs on Linux, and similarly we wrote it for iOS and Android. So we took a completely different approach in building a cross-platform solution. So one thing I want you guys to understand is Xamarin is not a right once from anywhere approach. That's not our intention at all. What we do is we expose the existing platform as this in C-Shelf. So we project this. You would have heard it as called as projections, but internally we call it as bindings. So we bind this entire Android Azure and you project it into the C-Shelf. So what is the advantage of it? You can build everything native. There is no HTML-based solution. It's completely native. And the beautiful thing about this is since you're writing in a single language, you can share technically almost all the business logic across all the three platforms. That way you get the native UI, you get the native performance, and you're not compromising on sharing the code as well. We will look at how we do that. And another thing is if you're building Android apps, you know that how do you build it, the UI. That is in XMLs, right? Android XMLs, right? It is exactly the same XML that you will be using to build your UI in Xamarin. In case of an iOS, you will still use the same storyboards. Now in iOS, the storyboards, or whatever you design in the UI, that is connected back in Objective-C. And in Android, it's your Java code which is basically inflating your XML, right? Now here, all these back in code is run in C-Shelf, not in Java or Objective-C. So that's what makes it unique in its approach. You get this point, right? All right, so just to give you a little more depth of how this whole thing works, right? At the bottom of it is the SDKs. Apple gives an SDK, gives you UI kit, map kit, scene kit, sprite kit, whatever kits, right? And Android has its own APIs, NFCs, you know, whatnot, the UI widgets and all those kind of things. We expose that in C-Shelf using a technology called bindings. So we have Xamarin iOS and Xamarin Android. Those are the bound layers, okay? And if you see this, you have this dem, dem is nothing but we are talking about Apple and the Google, and us, we provide you as a platform. And this is a whole lot of your code which is you will have platform-specific code written in separate projects, plus you will also have a shared code which can be shared across all the platforms. I'm just showing you Android and iOS, but it could be technically any platform which uses C-Shelf as a language or F-Shelf as a language for that matter, okay? So just to give you, I'm not sure if you see this right, but probably in the code you'll be able to see that. In Java, let's say if you have a list view and you have to provide a click event for that, you set the set onItemClickListener and you provide this whole code into this. Now C-Shelf, it becomes a little more simpler by saying listView.ItemClick and then you have this whole lambda expression that you can go in and you give the same thing. More or less, very similar thing. And also C-Shelf has this beautiful async and await support which is nothing but when you wanna spawn multiple threads, it's very easy to do that at the compiler level itself. Right, so let's look at a demo. So usually you can do this demo completely in Visual Studio, but Xamarin Studio is a free IDE based on an ID called MonoDevelop, again an open source project, and it's completely free. So I'm using that so you can build C-Shelf projects in Mac using this Xamarin Studio as well. Cool, so to start an Android project, you just file a new solution and you have an option called Android and iOS. You all can see it, right? You're good, perfect. So you have an Android and iOS. So again, the same options that you get usually in Java. Are you building an Android application or are there sort of templates? So I usually go and pick up the Android application so it gets me the latest application, right? And once it is done, on the right side, you can see the solution out there. What I'm gonna do is I'm gonna just zoom in, right? So that's your project. Do you see those assets, resources, and then you see main activity.cs? In Java, you would just see it as .java, right? So if I open the resources, do you see the same folders, right? Drawable, layout, menu, values, exactly the same thing. Now if I go to layout, you all know that your XMLs, that's where your UI relies on, right? So we tagged this as .axml. It's the same XML, but then we wanted our IDs to understand an Android layout, which is different from XML, that's all. It's just a .axml extension. But at the end of the day, it's the same XML that you would write. Now let me just zoom this out. Okay, so that's the designer. So you can choose on what platform you're designing, and whether you want alternative layouts, like you want to build on landscape, HDPI, LDPI, all those kind of things. Right, so let me just show you the source. Now this is the same linear layout that you would see on Android, exactly the same thing. So then let's go and write something out here. What I'm gonna do is I'm gonna put an image, so I'm gonna drag and drop an image, and then two buttons, right? I'll tell you what exactly these things are gonna do is I want one button, which takes a photograph from my gallery, and the other button, just to make a share, sharing the photo on Twitter or Facebook or whatever it is, like very simple. And you obviously need to name these stuffs. So you can go to the source and name it or else. There is something called as properties window, which because of its, it's stuck to 1024.764 resolution, so okay, let me go to the button and then give this name, instead of button one, I'll call it as pick button. And you technically get the same thing, like the text, that's what you will go and edit in your XML. So I'll say pick an image, pick an image. And now there are button, which is a share button, and I'll just say share image. Okay, so that's all done. I'm gonna close this XML view. And what's the next thing that you're gonna do? This XML, this layout has to be inflated, right? In your activity, so you have this activity.cs, which is in your case, it would be activity.java, and you have this method called onCreate, right? And there is a method called setContentView. Can you see that? Can you see this from there? Last? Yeah, perfect. So you have a setContentView, and in Java you would have r.layout.blah, right? The thing is in C-sharp, we usually give the full name. So it's resource.layout.main, that's all the differences. So it inflates that main XML that it was showing right now. And now let's get the handle of it. Now in C-sharp, when I want to wire up the code, when I click on this button, I basically wanna pick a photo, right? So what do you do in Java? Summon from the Java world, what do you do? Yeah, yeah exactly, findViewById, that's it. So we have generics method for findViewById, where now you can say resource.id. I created a button called pickButton. Now, when this inflates, this gives in C-sharp object. Exactly the same thing I would do for the shareButton as well, right? So I'll just create a shareButton, and perfect. Now I wanna create an event listener, right? On this click of a button, I want to inflate. Sorry, not inflate, I want to write an event for it. So I have a click method, and now I can decide whether I want to do a synchronous method or a synchronous event handling. So right now I will stick to the synchronous event handling, and I already have written a few methods out here. Basically, it's something called as pickPhoto, the same intent, I open the intent with, I'm looking for image slash star, and then I start the activity and say intend or create, choose it, blah, blah, right? And also once this photo has been picked up, I need to assign that to that image view, right? And that is done in your, obviously in your method, which is onActivityResult, where you set this up. So I need to get the handle of that image view as well. To do that, it's very simple again, so I just pick up the picture. It's a variable that I created already, and I say imageViewResource.id.imageView1, that's it. And I can also create the share button, there you go, sharePhoto, again, if you go down, there is a sharePhoto method, which writes to the stream and all those things. So I mean, this is pretty same, exactly the same thing that you would do in Java. So I'm gonna run this. So we're running on the 5.0. So there you go, you have the buttons. You see that material design theme? That's because in the SMD.manifest file, gone and set the theme. So pick an image, and there you go, this beautiful Xamarin monkey. It works, right? And I can say shareImage, now that I don't have any of the contracts other than just messaging, and this opens this SMS stuff. Isn't this the same thing that you do in Java? Yes or no? Yes. Everybody awake or asleep? I thought demos are gonna be interesting. I know that is Java, I think, maybe, right? Right, so now when you build for platforms, when you build for mobile, you have to give importance to the platform importance because more platforms definitely is more customers. So now as a developer, imagine if you were a Java developer, if you had to build an iOS application, how hard is it to go learn Objective-C and do that? It's gonna be really tough, it's not easy. So that's what teams do. They spin up a different team all together. An Objective-C team and a Java team, Java team does the Android, Objective-C does the iOS, and all those things. But now having this particular platform like Xamarin, being a C-Shop developer, and knowing just one ID like Xamarin Studio or Visual Studio, you can program the iOS and Android as well. All that you need to do is how these APIs work. That's it. Just like you saw, now you saw Android. Everything that you do in Android is exactly the same. Exactly the same way you would do it in iOS world. You would use Objective-C there, but in this case, you would use C-Shop. So one important thing that I didn't show here is the first thing I wanted to show you is that this is exactly the same as your Java. The next thing is now why are you doing Xamarin because you have the benefit of architecting for cross-platform. So that means the one important aspect of building for cross-platform is sharing a majority of the code across all the platforms. So there are multiple ways to do it, but let me focus on one way. That is using the Portable Class Library. It's basically a single assembly targeting multiple platforms. So any business logic that is not dependent on your platform can be ported into a Portable Class Library, compile it and reference these libraries in those other projects. That way, you have the majority of the code that can be shared across all the platforms. Because you're writing in single language. For example, I take this photo, I'm uploading to the cloud. Now uploading to the cloud is just one piece of code or one set of code that I don't have to repeat itself in Objective C and Java because that is a C-Shop that can be shared across all the places. That's what makes Xamarin a little different from other cross-platform solutions. So generally, this is always the question I get. What's the statistics? How much of the code can be shared? Well, it totally depends on the application. If your application is completely UI intense, then you will have more code on those layers. If your application is less UI intense, then you will have more code to be shared across. A simple example is, let's say, a healthcare company which has a huge set of business logic, HIPAA rules, a huge set of business logic. That company can take this whole set of code and port it to all the three platforms without much worrying about the other layers. Other layers is nothing but the UI which has to be recreated in all the three platforms. That way, you can get up to 90% of code shared. These are real-time applications like iCircuit, Touch Draw, these are award-winning applications in the app stores who have shared about 90% of the code shared. But there are ways to, you know, using open-source libraries like MVVM Cross, and now with Xamarin Forms, you can actually reach up to 99% or 100% of the code shared as well. But again, it totally depends on your project. Okay, so a very simple question. So what code will go into my PCL or a shared library? Very simple. Anything that is not dependent on your platform, you can't take anything from ImageView into the portable class, because that wouldn't work, that wouldn't compile. Anything that, after you pick the ImageView, you took the image, that's a stream. That can be ported easily, something like that. So anything which is not dependent on the platform can be shared to all the other platforms easily. One simple example is Azure or PaaS. We had a good demonstration of PaaS. So one of the questions I heard that, you know, what if I want to switch from Azure to PaaS? What would I do? Easy in Xamarin. That's very, very easy in Xamarin. Because that, you will be writing a database layer which is accessing the Azure or which is accessing the PaaS. I can create an interface by which my entire flow works, but the concrete implementation can be either PaaS or Azure and I can switch within the app itself. Okay, I'll show you that. So what other codes can go in? Any business logic? Any cloud integration? Anything like database access? You know that all the three platforms have SQLite. So the code to access the SQLite remains the same across all the three platforms. You don't have to read the people. Right, so let's see a sample. So do I have enough time? I do, right? Cool. So ideally a cross-platform solution would look like this. This code, you can get it from my GitHub. It's all up there. It also has a simple test solution which you can run into Windows which will tell you how much of code has been shared across all the three platforms. Okay, so here's how I design it. Any Android application, I call it as .android or .droid and then I have other applications with iOS and then I have the Windows Phone application as well. Now you see this part, .portable. That's the library which is referenced in all the other three places. Okay, so let me show you what is there in the portable class library. So everything that we call it as business layer, data layer, all the helpers, interfaces, models, all these things, doesn't have to repeat. It's in one encapsulated library. Okay? So let's look at... Let me run this application to show you what exactly this is. So while that runs, if you want to see one of the questions that comes up is how do I target different Android builds, right? So I can go and set these things out here. I can choose... How am I targeting Android 5 or any other versions that I'm interested in, right? So that's all in the options. Again, this is all nothing but which is fixed up from the manifest file. Cool. So this is an expense app, okay? Just recording my expenses. I add a new expense. Let's call it as cab expense or something like that. Cab to .droid.con.avent, right? Total of 100, and I can choose what category I'm interested in and save. Now, when I save this, what exactly is happening is it is saving in a SQLite. Just to show you how exactly this works, you have a database layer, and this is an expense database, and you can see that SQLite connection, right? And it has this save method, saveItem method, which updates the database. Now, where exactly this saves is using this shared project. I'm trying to explain it so that I don't confuse you enough because this is all c-sharp, but at the end of the day, you understand that it's just a simple repository pattern, right? You have database, you're saving it, and all those kind of things. Okay. So you have all these data. Now, let me show you this iOS, same iOS application. So you open the iOS. Anybody iOS developers here? Okay, perfect. So you have app delegates there, yeah? So we start everything from app delegate. You have the same method finish launching, and you have navigation controllers. If you look at the view, you have expense view controller. So all those UIs specific to iOS remains there. There, when you save, ultimately it calls this library, which is a portable class library, within that the class out there. You had a question? To save, right? Cool. So now let me run this iOS app. Gonna set this as the start project. Run with maybe iPhone 6, iOS 8.1. So this would open your iOS simulator. That's something strange. Let's take another simulator. Okay. So that's your iOS simulator, and you exactly have the same features. Okay, expense and add and all those things. Perfect. Now the next thing is, now you have shipped your app, which is, obviously it's only having the SQLite behind the scenes. But if you want your users' data to be scaling, you have to obviously take everything to the cloud, right? So that you know you have, someone has saved in his Android device, he should be able to get the same data when he opens up his iOS device, right? So that's when Mbass Solutions comes into picture where as a mobile developer, I don't have to worry about my infrastructure, all those kind of things, right? You just have a mobile back-end. Somebody like PaaS can give you that. Or, you know, even for that matter, Azure Mobile Services, which I'm going to show you the demo right now, but you can do it on PaaS. So if you want those components, they are all available to you in REST-based services. They're very simple REST calls. You can do that, but also the PaaS and Microsoft have written components in Xamarin, which you can use, which is nothing but a set of client SDKs that will give you access to the PaaS and Azure Mobile Services. So you can just say get more components and search for PaaS, assuming that I have a good internet. Yeah. So if I want PaaS, I would just go and search for PaaS. And it would give me a PaaS framework, and then I can just add to the app. So that gives me the PaaS SDK. And I can now take all the data that I was saving right now in SQLite to the PaaS, okay? Here, what I did for this demo, I'm using Azure Mobile Services. So when you're using Azure Mobile Services, again, they have the same component. Once I wrote that component, all that I need to do to make sure both my iOS and Android app, plus my Windows Phone app, they are cloud compliant. All that I do is I go to my portable library because that's the shared library. Within the portable library, I go and say services. Now, there's two services, ExpenseService.cs, which is until now which was using cloud, which is going to connect to the cloud, okay? All that I'm going to do is if you have attended any of the other talks, you initialize it using the keys and the URL that you are pointing to. That's it. This is my Azure backend. I initialize it. That's all about it, and I just run this. Now, what's going to happen is no more this application is working with your SQLite locally. It is going to work with the cloud backend, right? It is that fast. You can build on all the platforms. So now you saw something called authenticateScreen, which is coming up. Okay? So what I did is, when you're pushing your data to the cloud, right, you need to authenticate the user because you can technically store anything into the cloud. But you need to make sure that, hey, this is the user and this is the user's data. The best way is use any of the authentication services. And I did not write any of these codes here, right? I said that authenticate with Azure and automatically it put the screen in front of the user. So I'm just going to sign in. Let me also start my Android. So now, when I save something, let's say Android, Con, Me, like, Spencers or something like that. And which is about 150. That's too much. Now when I'm saving, it is not saving locally. It's saving to the cloud. But my architecture is in such a way that, it also saves in the SQLite locally, but it also pushes the cloud. Now that's the offline sync. You can do it, you can implement it in many other ways as well. Okay, let me just did that run. I don't think it did. So let me just say that's the app. So you saw that Android application also started with authentication. It was not there. It's just that one line of code that I uncommented, it brings in that new feature all together. All right, so let's wait. Do you have any questions? I can take it up because it's just the last demo that I want to show. Yeah, please. So it's like C sharp, we write the code and Android will support it, right? You have a mapping around like C sharp and Android code. So can be, it is possible like you have an Android code already and there are shared components which can be used directly in iOS. So can we do like, give the code of Android and then run in that shared component? Let me understand this question. The SQLite thing you have developed for Android, the full layer of database. Can it be reused in iOS directly? It is what is happening right now. It is reused directly. I mean, I have to write C sharp code for that, right? Correct. Can it be like converted to C sharp? You can. There are technologies like sharpen, there are tools like sharpen where you can convert the Java code that you already written to C sharp, compile it in C sharp and then you can take it to iOS and Android as well. And if you, there is another question that usually comes up like, hey, I already have a component written in Java, right? The huge component Java. Now I want to take the component to Android. I don't want to rewrite this whole thing. You can bring it because that's how we brought the entire framework up in C sharp. That project is called bindings and that's a whole lot of things. So using bindings, you can bring in even those APIs to C sharp. Okay. The UI widgets. Hi. Is there any way of using existing Java libraries like, for example, Crashlytics which do not have a Xamarin port with Xamarin using this? Yeah, that's what I said. You can use the same. It's a doc pudding. No, I mean existing libraries, even which are not port, I mean, I don't have the source code of or something. You can. That's how we do it, like iOS. We don't know iOS source code at all, right? We brought the iOS bindings to C sharp. Just the bindings you need, right? Yes. In iOS what happens is we use that P in working technology but you directly call the C. In Android, what happens is we make the JNI calls to the Javas. So you can bring the Java library to C sharp but the same library wouldn't work in iOS because of its nature, right? Yeah. Maybe you're not the right guy to ask but what are the cons of using... What is... Okay, that's a great question to ask. But here's why. I don't see it as a con but since we are making use of mono, right? Mono is the framework that runtime that is running below this particular thing. So your mono runtime, you know that Java runs on Dalvik. Now Dalvik is there available everywhere, right? All the devices that you buy in Android has Dalvik but mono doesn't come with that. So mono gets attached to your app which means your size can go up a little bit and we use a linker technology to extract out the code that you don't use it but still there are chances that your size will be a little larger than what you would write in Java. Yeah, ideally what this demo is supposed to happen is it is going to authenticate and you would see the same thing because it just saves in the cloud and it just matches from the cloud, right? So how fast does Samaritan keep up with the changes in different platforms? Same day, same day. Yeah, so so I basically wanted to... When I talk about that I'll take your question just a minute. So reuse the Java library, it's possible. And it's there on my home page because I wrote a blog on bringing the YouTube API to C-Sharp. So you can see how it is done, bringing Java to C-Sharp. And variable programming, that's another thing where I wanted to talk about. C-Sharp now supports even Google Glass and on the same day when Google Glass was released when it was announced in the IEO that the API I'm talking about and our team came and wrote the bindings for it because it's pretty easy to write bindings once it is available. But they are available on the Alpha channel almost within a week. But for it to get stabilized, it would take some time. But if you want immediate support, you can take the Alpha channel and we are there to support you on the forums. So you can actually do all these things. You know, program for the Android Wear, Glass or Amazon Fire TV, everything is possible. And if there is any other new device coming up, you can do it as well. You can bring it to C-Sharp as well. Any other questions? Yes, you can do that. You can call the native because, as I told you, the mono itself is written in the C-C++ layer. The mono runtime. So that gives you the native capability to call the C and C++ codes as well. I can show it to you. That's a completely different stack altogether. Any other question? What about the pricing of Xamarin? Is it something we have to pay for? No, it's a free saturation which is good enough for all the small apps. If you're an open source developer, if you're an open source company for a very long time and supporting open source, we give you free if you're developing an open source application. And it's free for students completely. But the business edition there is a pricey because if you're working with Visual Studio and other kind of things, because that's where the real enterprises things stuff comes in and we want to make a little bit of money there. So enterprises will pay. Thank you. Sorry? Any company which is larger than five developers? Okay, I mean, yeah. Requiring Visual Studio to develop, you know, any individual studio investments and all those kind of things. If any company wants to develop using the Xamarin Studio? Yeah, I mean, there is an indie version. But again, the Xamarin Studio, indie version has... See, Starter Edition has a cap that, you know, there is a size limit and other things. But indie version doesn't have any cap. You can build on Xamarin Studio completely. But if you want it on Visual Studio because a lot of our customers, like, you know, it's C-Shop customers, right? So that's what we want to pay for the business edition like this. Okay. Hi. Yeah. So my question is that how does Xamarin different from hybrid app development? Yeah, it's totally different, right? Because when you say hybrid app, I told you in the beginning we have this HTML-based solution, right? Xamarin is not about HTML-based solution. What we do is we predict the existing platform up in one language. So you have the benefits of sharing the code across all the other platforms. Java, much we have a higher level of performance issue than we are converting in it Xamarin. So Xamarin is doing C-Shop to Java and then Java to Xamarin. No, no, no. It is not doing C-Shop to Java. It is using JNI technologies to call whenever there is a Java widget or something which you are using from the Java world, it makes a JNI call. That's it. It does not, every other C-Shop runs on the mono runtime in case of an Android. No, so how can I use native apps basically like the native development done in like third-party JAR files or something like that. That's what I talked about the bindings, right? You can. You can bring the third-party library because what it does is it writes a wrapper on top of it which is nothing but JNI calls. Which is nothing but JNI calls. So your JAR is going to run on your Dalvik VM, right? Your JAR is going to run on that and when our code is running on C-Shop mono runtime, whenever you have a call there, it is going to make a JNI call. So basically why Xamarin and not so much into replacing hybrid? No. We are into native development. We give everything that a Java developer would get. You get the same thing in C-Shop. But the benefit is core-sharing. That's it. No, no. Basically the idea is that we have iOS native, we have Windows native, we have Android native. So if Xamarin is like providing C-Shop to develop all of the platforms, then why users or developers like us are not moving to Xamarin? So okay, probably you didn't get that. Why we are doing native development in .java and iOS Objective-C and like that. My question is, you are a Java developer. Are you doing the iOS application yourself? Yeah. Are you doing the iOS application yourself? No. Right now I am working in .NET and Java. So that's why I am thinking that if I have to go for iOS also, so I know C-Shop and I can move with Xamarin. So that's why what I want to ask that why all the developers are making native apps in Java and Objective-C and why they are not using Xamarin? Probably I think they are not listening to my talks too much. That's why. Just joking, but the thing is, I know why you are asking this question is why Xamarin is very slow, right? It's the other way to put it on. No, I am not saying that Xamarin is slow in this and that way, but I just want to ask why Xamarin had not evolved like this? Like if from the first day I may know that there is a tool like Xamarin which can be used to convert the application in native Android and iOS and Windows, so I may be using Xamarin from the day one. Not everybody are C-Shop developers, right? That's one answer to that. No, basically C-Shop development is quite okay with this phase. Like the evolution of Android came up with lots of Java developers but before that everybody is going into web-based application development, so I just want to know that why Xamarin is not so much into popular is another way because I am not using, so it's not popular, but why the basic is why all developers are not moving into Xamarin? They will move. Maybe we can put it this way. It's about awareness and adoption of Xamarin and I guess that's actually what people have started really as. Why was the phone gap adoption was so high because all the web developers are mobile developers from C-Shop. They are able to develop mobile application very, very soon. So again, Xamarin is very focused on C-Shop and that could be one reason where not everybody is interested to learn C-Shop and then build on iOS and Windows phone. Though you see the benefits of being native, and we are getting there that message is loud and clear. We have a lot of people coming back from phone gaps and other HTML solution where they have burned their fingers and say, hey, now we can't go to native but we really want to do something cross-platform. That's where Xamarin is picking up. It's coming up. And also the price could be one other factor. Price could be one other factor. Hi. One last question. Okay, there's two. I'll take the two. Very soon, very soon, yeah. Okay. So you talked about the mono runtime is exported with the app for C-Shop, right? Yes. Okay, and then it does GNI calls to Java. Correct. Now, earlier till Android KitKat. Dalvik was the default VM. Dalvik was the default runtime. Yeah, now. Lollipop comes out. Yeah. Okay. Which as far as I understand is much more optimized ahead of time compilation, path prediction and all that is there. I feel that they're trying to do what JVM does very well. Right. So can you throw some light on what kind of is mono that optimized that I can run that amount of business because you said like business logic is the heavy business logic is a very good use case for this. Yeah. Right. So does mono do such kind of optimizations? It does. So in mono, mono has been 13 years old. It's much more powerful than Dalvik is actually. If you look at the performance devices and things, but it is not the full mono which is there in Android yet. So mono is optimized. We have ahead of time compilation in mono for iOS because iOS doesn't allow you to run any kind of runtime. So mono has AOT as well. So that those optimization has been carried forward in the Java world as well and we support ART to the fullest. You saw every I was running everything on 5.0. Yeah. So it supports fullest and it is optimized very well for the ART as well. What, how is the documentation about this? I mean the Android document, Java documentations are like humongous. Correct. What about Xamarin? So Xamarin documentation has been very focused on C-Shop developer adapting to Android APIs. So here's what I do. When my documentation I feel that it is not enough, I can go to Java documentation. I can do the exact same thing in C-Shop because I just have to refer. We are all developers. We understand the algorithms there. We can just make it so the Android documentation that you see there is as good for even Xamarin Android as well. Thank you Nishan. Thanks a lot.