Embedded Player

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Transcription

Hello everyone and welcome to THE .NET Core podcast - the only podcast which is devoted to:

  • .NET Core
  • ASP.NET Core
  • EF Core
  • SignalR

and not forgetting The .NET Core community, itself.

I am your host, Jamie "GaProgMan" Taylor, and this is episode 20: Xamarin
with Jim Bennett. In this episode, I talk with Jim Bennett about Xamarin and .NET Standard. Jim - in his own words - is a Senior Cloud Advocate at Microsoft, Xamarin Certified Developer, author of Xamarin In Action, blogger, speaker, father and lover of beer, whisky and Thai food.

So lets sit back, open up a terminal, type in dotnet new podcast and let the show begin.

Jim Bennett's Introduction

Jamie
First thing I'd like to say is, thank you very much for being on the podcast, Jim.

Jim
It's my pleasure.

Jamie
Is it ok to call you Jim, by the way? Or would you prefer like, James or his Jim your actual?

Jim
So the only people who actually call me James is my parents and my wife. Everyone else calls me Jim. I keep trying to convince my parents and wife to call me Jim, but it's just just not happening. Unfortunately my dad's a Jim as well, so it gets very confusing.

Jamie
Considering that I'm not one of those... So I was wondering if you could first just sort of introduce yourself a little to the very small number of listeners that I have that will have never heard of you before.

Jim
Yeah, of course. So as you said, I'm Jim. I'm Jim Bennett. I'm a cloud advocate at Microsoft. So the team I work on you kind of think of it as almost like they're people facing part of developing relations.

So Microsoft has got this awesome develop relations team that covers things like docs, we've got our online learning platform called Learn, we've got our MVP program, which I'm sure a lot of your listeners have heard off. And then we have cloud advocates and we're kind of the people facing side of things.

So we work with developers. We meet developers where they are. We try to make their lives easier when it comes to using Microsoft products, or using open source software with Microsoft, or just anything we can help them with. And some of what I do is things like conference talks. So I'll go to conferences, I'll evangelise are products spread the word show off the things that we do. I work on things like our docs, our learn platform to help developer actually get on board and use the tools that there.

I'm an engineer, a heart. So I've got a strong background in Xamarin, former Xamarin MPV. I've written a book on Xamarin called Xamarin in Action published by Manning. I've been a Xamarin developer for quite a long time. So I worked with Xamarin developers, I work through the docs that we've got to make sure that they're friendly towards Xamarin developers. I create blog post showing off the cool things we can do, or help people solve problems, I create sample code. And I advocate for our developers.

So I kind of like to think that I worked for the developers and I fix Microsoft. If that makes sense. So when we have Xamarin developers have problems, part of my job is to go back to engineering and say,"Fix it. This is not right. And here's why." I can do that from prospective an engineer. So that's pretty much what I do. As I say, my focus is pretty much Xamarin and obviously Azure, because Azure is awesome.

Yeah, I guess that's kind of the the short elevator pitch.

Jamie
Fantastic. You've talked a lot about Xamarin in there. You have talked about the book that you've written "Xamarin in Action". I'd like to come back to the later, if we have a chance.

Jim:
Okay.

Jamie:
Mainly because I've interviewed Dustin Metzgar of the .NET Core in Action book, and by the time this episode goes out, I'll have interviewed Andrew Lock with his ASP.NET Core in Action. So it's kind of like the three related books that I'd like to talk to you all about - and I have talked to those about it, so if it's okay we could circle back to the book at some point.

Jim:
Yeah, of course. It's quite cool that we've all written books with Manning - the "in action" gives that away - and Manning's a fantastic publisher. It's very cool that we're all Manning authors that you're interviewing.

But What Is Xamarin?

Jamie:
Could you give us a brief sort of elevator pitch our brief idea of what Xamarin is for the developers who haven't used it before?

Jim:
Yeah. So Xamarin at its most basic is .NET wrappers around the iOS, Android, and MacOS APIs and SDKs; a .NET Framework style implementation that runs in those platforms; and then a tool chain that allows you to use Visual Studio to build apps for those platforms.

So essentially what it means is you can build 100% fully native apps for iOS, for Android, and for MacOS using .NET technologies such as C# or F#. 100% API access, so everything you could do with the Objective-C or Swift or Java or Kotlin, you can do using C# or F#. And then it compiles down using the native tool chain so it uses XCode under the hood, it uses the Android compilers the hood, to build a native application with fully native performance.

It's basically Mac, iOS, Android, totally native, but using C# and F#.

That's the very, very brief elevator pitch. Behind that it's a lot more, but the very brief one is:

you want to go to mobile app thats C# and F#, but you want to have access to everything? It's Xamarin.

Jamie:
So I guess you could have one code base that has your business logic, and may be a separate code base or the same code base with several different view systems. So you could have a iOS view and an Android view, and you just it build and you get both out. Or is it that this project will have to have thie Android view for it, and this project will have to have the iOS build?

Jim:
It is pretty much what you say. You have multiple projects. You have an iOS app and that is fully access in the iOS SDKs and in there you define your views. And these views you define exactly the same way as if you're using Objective-C or Swift.

So things like storyboards, you can design a storyboard you drop that in and you can use that. And you create your view control as the same as you do with the Objective-Cor Swift, but you do it using the C# to wrap around the underlying Objective-C UI ViewController class.

On Android same kind of idea, you can create yuor layout.xml, you can create your resources the same as you do in Android studio. But then you define your activities or your fragments using the C# wrappers around the underlying Java activity and fragment classes. And that's at your view level, but the rest of your code you can essentially share.

So the implementation of Xamarin on IOS is a .NET Standard compliant framework. Same on Android: it's a .NET Standard compliant framework. So you usually end up with another project which is your core business logic code. It's basically everything that doesn't need to access the native APIs directly, and that code is shared. So it's compiled down to IL on that IL is then used by your iOS project and compiled Using XCode down to native LLVM and byte code for iOS; or it's compiled to IL code and then JIT'd on Android. So you end up sharing pretty much anything that doesn't need those underlying native APIs.

Now, how much you share is very dependent on your project that we typically talk about 60 to 70% code sharing between your two apps. And that's, kind of, the big ticket item. This is the massive reason for using Xamarin: is you write your code, with the bulk of your code, you write it once and then you share it between the two platforms.

On top of that, the other sort of kick arse reason for using it is: it's .NET. So because it's a .NET Standard implementation. If you've got NuGet packages that you want to use, you can use those. There's a kind of whole world of NuGets that you can use inside your apps and use from both iOS and Android.

So one could example would be JSON passing. So if you think about a lot of mobile apps, they usually talk to a server and they download some data. And in a lot of cases, you make a call to a REST API, and you download some JSON. Now if you're writing that in Objective-C you would use your NSURLSession, you'd download some code, you'd have a JSON passing library that does things in a certain way. On Android, again, you'd have a different way of making that connection to the REST API, you download some data, you'd the handle of the JSON a different way. And sometimes you end up with some quirks around things like dates or different representations where your data doesn't get treated in exactly the same way.

If you do this in Xamarin, you'd use HttpClient, same code and both platforms, and on under the hood it will use the native implementations for making network calls. And then you just use NewtonSoft.JSON to deserialise the JSON, so you know that the Jason is being deserialised in exactly same way and both platforms

So it's just really, really good that you've got this huge ecosystem of tools. You've kind of got this consistency between two platforms. You're writing your code once you're fixing your code once. If you've got bugs, you know things gonna work the same way.

Jamie:
I see. How does that work with debugging? So let's say I want to debug on a piece of hardware and I connected to my computer. I run the debugger, and I put a break point in. Is there lots of magic wizardry that happens that converts code on the way to the device and back from the device, or is that just not a possibility?

Jim:
It's totally possible, is totally possible. All that magic is there. It is a full debugger experience. The only thing you don't get, which some of our listeners who are used to things that's certain .NET implementations might want things, is things like edit and continue don't get; because the code has to be compiled on run on the device, but other than that, is a full degubbing experience.

So I can stick a break point inside some C# code, and I could hit that break point while it's running on an iPhone simulator on actual iPhone and Android emulator. or an actual Android. And now I can step through my code. I've got the full watch, immediate window, everything you want to do.

So the way you build Xamarin apps is Visual Studio. Every thing is done inside of Visual Studio, the same as you would do if you were building a WPF app, and running that Windows. And you get the same level of debugging, the same kind of experience that you would see if you were doing a desktop application.

And actually one thing that Xamarin does that's really cool - and so far as I know Xamarin is the only cross platform framework the does this, and this is amazing, I love this - is you can actually debug an app running on your iPhone from a box. Now that in itself is just phenomenal. So Apple has a whole load of restrictions around there SDKs. You're only legally allowed to build an app for iOS on a Mac. You have to run XCode, you have to run the XCode tools Mac. And Xamarin has this incredible way that from a Windows box it can, behind the scenes: SSH into a Mac on your network; use the XCode libraries and CLI to build your app on the Mac; deploy it to your iPhone, either over cable over WiFi on, then debug it. So from the Mac, it uses SSH to Windows to run, sorry to the Mac, and uses the full XCoe debugger on you can step over code running on your phone via the Mac on Windows.

So it just is completely crazy debugging experience. But it works, and it works beautifully.

Jamie:
So that I understand it correctly:

  • My Windows box would create an SSH to my Mac
  • Send over the code
  • Tell the Mac go to the build, do whatever it is
  • Get the response
  • Then push it to the iPhone and then somehow maintain a connection.

This, like,juggling connection between the iPhone and the Mac and Visual Studio in order to do the debugging experience?

Jim:
Yeah, it's exactly that. It's compiled to IL on windows. The IL is pushed the Mac. It's compiled down to the the byte code, deployed to your iPhone, and then you can debug it.

And what's even cooler as well, is if you don't have an iPhone and you want to use the simulators that come as part of the Mac - there are no simulators for Windows, the simulators only run in the Mac. But what Xamarin can do is Xamarin can actually screen share the simulator from your Mac to your Windows box. So you from Vision Studio on Windows, you connect to a Mac - and that Mac could be in the cloud, there's a service called Mac in Cloud, where Macs run in the cloud as the name kind of suggests - and from your Windows box you can connect, over the Internet, to Mac in Cloud, build your app,it'll launch the simulator in Mac in Cloud, screen share that simulator back to Windows, and you're debugging it as if the simulator ran on Windows.

And in some ways, the simulator windows is actually better because on the Mac there's no touch screen. So when you're doing two finger gestures on the Mac, it's actually quite convoluted. Where as on Windows, you've got the touch screen. So you just use the touch screen as if it was the touch screen of the iPhone, and you get a full, multi-finger gesture experience. It's just bananas, absolutely bananas this, and it just works beautifully.

Jamie:
That really is amazing. I can't even imagine the amount of engineering effort has gone into that.

Jim:
Yeah, there are so many smart people working on making this work and it is, just, it is incredible, absolutely incredible.

Why Xamarin over PWAs?

Jamie:
As someone who has never used Xamarin, my question to you - and I realize this might be a bit of a leading question- what would be the main difference between creating a Xamarin app, I feel like you've already answered this, but we'll ask it anyway, as Xamarin app and, say, a Progressive Web App.

Jim:
So the big difference really is that Xamarin apps are totally native apps. And so by "totally native" I mean, its native performance, native controls, and its native APIs.

So if you are building a Progressive Web App, yes, it could run a mobile and there are ways that can access some parts off the hardware and some parts of the SDKs. Whereas a Xamarin app has got total, 100%, native API access.

You want to build an AR Kit app on iOS? You can do that. You want to build a sharing extension, a SIRI shortcut? You could do that. You want to start tying into the android alarm system? You can do that? Manage your notifications? You could do that. Everything you can do with a native platform you could do with Xamaring. Whereas Progressive Web Apps they limit the capabilities of what you can do.

That was not say that PWAs aren't a great thing, They like to do a lot of good things. But Xamarin just gives you everything. It's as if you are building with the native platforms. It's as if you're building with the tools that Apple and Google provide. You're just doing it in one language. And you can compile your app, deploy it to the store, exactly as you would if you doing Objective-C or Java.

Jamie:
The full developer experience off, "I have an idea for an app," all the way to, "people are using my app on real devices In the real world." That whole experience, I can manage from Visual Studio?

Jim:
Yeah. You can build it, you can deploy to the stores. All from inside Visual Studio. And yeah, you could do everything.

So at the next WWDC When Apple announce iOS 13 with whatever cool funky features it's got, you will be able to use all those features out the box; absolutely everything as if you're building a native app.When Android Q comes out when everybody eventually gets that - well I suppose everyone is still on lollipop now. But you know when Android Q comes out, and people get that, again all those APIs, you'll be able to use. So you've got that total control.

You know, that's kind of another way where things that Xamarin is better than tools like React Native or Flutter. So if you wanted to access those native APIs from React Native, it's a bit of a janky experience. The same with Flutter: You have to, kind of, mix the Dart with Objective-C or Java. And although obviously things like React Native has its upsides in terms of the way that does all the JavaScript code, if you're a JavaScript developer; and Fluttter, has its upsides the way it builds its UIs. If you need the native access, with Xamarin it just works. On those other platforms, you don't get that same hundred percent native API access.

Well so on classic example recently: We're hearing with With Flutter is because Flutter draws its own UI controls on screen, The whole accessibility model isn't quite as good as it could be. Whereas iOS, the native iOS APIs has got fluent accessibility. It's brilliant if using it for like a vision impaired person, for example. The way that iOS works is just fantastic. If you build with Xamarin, because you're using native controls, you get the accessibility out the box and it just works. Whereas with platforms like Flutter, there's a certain amount of work you have to do to get accessibility baked in. So if you want, take advance those things that make those platforms great, Xamarin is it's definitely answer.

Forms and Fabulous

Jamie:
You're really selling me on Xamarin in here.

Jim:
It's great. And I probably should add for the benefit of the listeners: Yes, I work for Microsoft. Yes, my job is to evangelize Xamarin. But I do this job because I love Xamarin. I don't love Xamarin because I do this job. I was talking about Xamarin, blogging about Xamarin, writing about Xamarin before I had a job working for Microsoft. I think it's a phenomenal platform.

And I think one of things that I really love about as well is Xamarin is a completely unopinionated platform. So it just wraps those APIs, that's it, and how you handle that is entirely up to you.

So one example is the MVVM design pattern. If you have listeners who've done WPF or UWP, they've probably heard of MVVM. The MVVM design pattern is very popular with Xamarin. It works really, really well because allows you to put a lot of your code in your your shared code. You put your UI logic in your shared code through your view models. But you don't have to use MVVM. You can use reactive UI, if you want to You can use different ways of building your apps if you want to. You're not forced into one particular paradigm. And on top of Xamarin, it's very easy for people to build different frameworks to allow it to do different things. And one framework I think it's definitely worth talking about is Xamarin Forms.

I don't know if you ever heard of Xamarin Forms, but the idea behind Xamarin Forms is to provide a platform agnostic abstraction of the UI. So you think about what we talked about earlier: you'd have your UI defined with storyboards or and Android XML with shared code underneath. Xamarin Forms allows you to actually share your UI code. You define your UI with an abstraction, and you could do that in C# code, or you could do it in XAML - if you're off the WPF or UWP bent, definitely want to do it in XAML. And then when you define your controls, when the app is actually running on the device, the controls are rendered using the native controls.

So you say, for example, in your Xamarin Forms page, "I want a button," and then, when you're app runs on iOS, he uses a UI button from UI Kit; on Android it uses the Android widget button from the Android Widget Library. So use it the native controls, but when you define your UI, you do it using this abstraction so you can end up with defining your UI one. And so, you ramp up that code sharing - you know, the 60 to 70% code sharing - you can easily ramp that up to 90-95% if you want to. It's just a phenomenal capability, and you could easy mix and match. So you could say I won't have a native app because I want to have access to all the underlying capabilities of the native platform, but then I'm going to a few pages in Xamarin Forms using this abstraction later. You can have a nice mix if you want to.

It's just great. It's a brilliant framework built on top of Xamarin. And its actually gotten to the point now where, to a lot of people, Xamarin Forms is Xamarin. We're seeing three out of every four Xamarin developers using Xamarin Form to build their UIs once. But they've still got access to native controls, they've still got access to native APIs. They can do absolutely everything you could do on the native platform, but you end up sharing 90-95% of your code. It's just amazing what you can do with it.

And then you even go one step further on top of that, if you want to. And there's a thing called Fabulous, which is an MVU Architecture - a Model-View-Update architecture - based upon Elm that uses F# to give an Elmish style architecture to Xamarin Forms apps.

So because it's got this different, this unopinionated Xamarin layer, and you can put Forms on top of that and Fabulous on top of that, or even UNO, which is built on top of Xamarin. You can do so much with it. You're not constrained to, "you have to build your apps one way." You've got so much freedom to build the apps the way that works for you, and the team of people you're working with.

Jamie:
Wow, that's amazing. That's a lot of information. But that's amazing

Jim:
Yeah, sorry. As you can tell, I kind of love this happen things so, you know, so much great stuff about it.

Jamie:
So with his Xamarin tools, is it a case off, "I just want to target iOS," or "I just want to target Android"? Or do I have to say, "I have to target Android SDK level 24 or iOS 6"?

Jim:
Yeah. It's kind of baked into the way that the iOS apps and Android apps work. Because they are fully native apps, you have to follow the paradigms off the native platform. So when you create your iOS app, you have to specify what your base SDK is that you're targeting. And obviously then, in your code, you have to say "if I'm targeting iOS eight, I could do X. If I'm targetting eleven I have to do X" as the SDKs change. The same with Android,you've got the same three: compile version, minimum, and target framework versions that Android uses. And, obviously, Android users don't update devices very often because a lot of the time, they can't. So you have to support older versions. But you have that same level of, "I've got to choose the version that I support." You have the same kind of manifest files that you get on Android. So it is the exact same as an Android app.

But again, you got that control you can say, "I just want to support iOS 12 because I just want the latest greatest," and you get on your 60% percent of users. Or, "I just want to support Android from Marshmallow and above for the new permissions model". You have that control.

Jamie:
I really like that. I think I'm gonna have to start playing with Xamarin over the weekend

Jim:
It's really cool. And it's part of Visual Studio. So if you got Visual Studio installed on a Mac, you'll have the Xamaring tools just installed by default. On Windows, you just launch the installer, and there's a mobile tools for .NETT workload, you just tick the box, and it installs all the stuff for you. It installs the Android SDKs and the emulators, and it'll install the code to talk to your Mac to do everything for you.

Actually, just going back to the Mac thing. What's cool as well, if you don't have to configure your Mac. From Windows, it will connect to the Mac and actually push the relevant pieces to the Mac for you. The only thing you have to do from the Mac is install XCode from the Mac app store and launch at once to install the other bits. Because Apple don't seem to be able to create an XCode installer that works properly unless you run the app once. But other than that, you can just manage it all from Windows, which is very cool.

Jamie:
So, you know, .NET Core and Mono are still pretty new-ish. Hardcore .NET developers are kind of Windows only, so being able to do it from an environment that they're familiar with is pretty cool.

Jim:
Yeah, So one big thing about Xamarin forms actually is if you come from the Windows desktop background - so if you know WPF, and know UWP, and you know XAML - you can literally launch Visual Studio, an environment that you know well; you go "File > New > Cross platform mobile app". an experience you know well; you design your XAML, the names of controls are a little bit different because they behave differently. But you design your XAML, you write the code, you click run, and you've got a mobile app running.

Now that's not to say that mobile apps are completely easy. They are very different. You've got memory constraints; you've got different UI paradigms cause it's a small screen. But if you want to get started, if you could build a WPF app, you can build a cross platform mobile app, inside the tools that you know and you love, using the languages that you know and you love. It's just absolutely bananas, it's great.

What About Windows Mobile?

Jamie:
I don't know whether this is going to be a contentious question or not, but for the uses who are still using Windows Mobile, can you target Windows Mobile 8 or is it literally just iOS and Android?

Jim:
So for both of those users who are still on Windows Mobile. No, it used to target Windows Mobile 8. Back in the day, you used to be able to create a Xamarin Forms app for Windows Mobile 8, but that's been dropped, its Windows 10 and above now. The Windows Mobile platform is not supported. So no one at Microsoft will be supporting that platform, including the Xamarin developers.

Jamie:
I mean, that's fair enough. Like you say, they're they're not supporting the platform anymore.

Jim:
Though saying about supported platforms, I do have to drop this in as to just how cool Xamarin Forms is.

So, as I said earlier, Xamarin Forms is this UI abstraction. It sits on top of the native user interface for iOS and Android. but they've added a lot more platforms and just iOS or Android. With a Xamarin Forms that you can target iOS; you can target Android; you can target Mac OS; You can target Windows, by building UWP apps; you can target Linux, there's a GTK - we call her backend, it's kind of the thing that makes it work - there's a GTK one that runs on Linux. We have one built by the community that runs using WPF, so it can run on Windows Sever. And if you have a Samsung TV, Samsung Watch, or even on of those Samsung Smart Fridges, the Tizen Operating System has said that the official platform for building apps on Tizen is .NET Core, and the official platfrom is Xamarin Forms. So you could build one app, define and UI once and run it on:

  • iOS
  • Android
  • Mac OS
  • Windows 10
  • Windows 7
  • Xbox
  • Holo-Lens
  • Linux
  • Tizen TV's and Tizen Fridges

One app running on all those platforms. I cannot think of any other technology that allows you to build 100% native apps across all those platforms. It's insane.

Jamie:
I cannot wait to push my first TODO app to a fridge. I have to just say that.

Jim:
Seriously, I need to get my hands on one these fridges that runs Tizen. I would love to go on stage and do a .NET Anwyhere demo and say, "look, here it is on a phone; Here it is on this; Here's it on Xbox; Here's it on the Holo-Lense; here it is on the fridge.

I'm not sure I could put a fridge in my hand luggage,, maybe checked luggange wouldn't be a problem. But one day, one day, I will show off a Xamarin Forms app on a fridge. I've been saying this for a year or so. I will do it one day. I'll put on a fridge.

Jamie:
Fantastic. You've mentioned it a few times: you said that Xamarin is a .NET Standard compatible framework. Is it Mono? Is it .NET Core? Is it .NET Framework? Or is it its own thing?

Jim:
So Xamarin is based on Mono.

Jamie:
OK

Jim:
So I don't how much you know about the history of mono, but one of the main founders of Mono is a very, very smart, awesome gentleman called Miguel de Icaza, and he was actually one of the founders of Xamarin. So he built Mono to put .NET on Linux. He then built, obviously along with the rest of the team, he built MonoTouch and MonoDroid to bring Mono to the iOS and Android platforms. And is that that became Ximian, that became Xamarin, that's now part of Microsoft.

So everything's based on top of Mono. The framework is, it were; the .NET Standard compatible framework is based off of Mono, it uses the Mono Base Class Libraries for everything, and it uses things the Mono Linker, and tthe various Mono compiler tool chains. So, yes, it's all based on Mono.

Obviously, if you're building a UWP app with Xamarin Forms that would use the .NET Framework, with the UWP parts of taht. But when it runs on Linux with GTK it uses Mono, an on Mac it uses Mono. So mono is the core behind it. And currently it's all .NET Standard 2 compliant. And there's been .NET Standard 2.1 released, or is releasing some point. And so Mono is going to updated to support that.

Jamie:
it's the little framework that could, I think, is Mono.

Jim:
Yes. Not so little: the big framework that could.

Jamie:
Well, okay. It was originally the little dream in Miguel de Icaza mind that has somehow managed to take over the world. We've got Xamarin, we've got Unity3D, wee've got Blazor now. It's amazing.

Jim:
It is this incredible.

So I often joke that the acquisition was actually Xamarin taking over Microsoft and people say to me, "No, no it can't be like that." But it's like, let's go back 10-15 years or whatever. Microsoft, .NET, closed source; Xamarin, .NET, open source. Where are we now? .NET open source. Xamarin has won. So, you know, Xamarin took over Microsoft.

I'm sure there's very senior people in my company who would be scowling to hear that.

Jamie:
Don't worry, we can edit that out.

Jim:
Sorry, Mr. Guthrie didn't mean to say that.

I think it's great. It's just shows that Miguel was very much ahead of his time in terms of the way he thought about .NET, and the fact he thought this should be open, this should be available. And Some great people at Microsoft also had the same belief. It just took a bit of time for the great big, slow container ship that is Microsoft to slowly, spin round. And now Microsoft believes the same thing that Xamarin does: that this should be open source, it should be built out in the open. It should be something that the community is involved in. I think I think it's incredible.

.NET Core, for example, I think, is just phenomenal. The fact that Microsoft saying we want to build .NET in the open and we want to make it the best we can with the help of the community, I think is brilliant.

Jamie:
It really is. As we record this I've recently been editing an episode where I talked to Dave Rael of Developer on Fire and we sort of geeked out over the CLI and over .NET Core being so open. And it sparked the conversation I had with someone I work about how the SDK And the runtime .NET Core are growing so quickly. If you go back in time to early 2001/2002 and look at the speed of which .NET Framework evolved, it's a snail's pace, considering

Jim:
Yeah, it's incredible just just how fast he's growing. And so far we haven't really broken anything bad. That's always the worry when you have some moving quickly is: are you going to break something?

Yeah, Microsoft has bean absolutely regimented when it comes to backwards compatibility. But we haven't broken anything with .NET Core that I've seen, which is pretty good. So we've got the right things in place, the right tools in place, the right people in place so that we can iterate much faster and not worry about the problems. So I think I think that's phenomenal.

Jamie:
Sure. So here's a hypothetical for you, then.

Jim:
Yeah.

Jamie:
There was a lot of talk when .NET Core first came out and people are saying, "But what about UIs? You've no UI framework," and that's entirely understandable from Microsoft's core .NET team's point of view: It would be almost impossible to write a single UI framework that worked across all the platforms. I think maybe you can see where I'm going with this question. Obviously, .NETT Core 3.0 brings a lot of UWP stuff to Windows only, but it brings some of the UWP and WPF, sort of, WinFormsy stuff to Windows only builds for .NET Core. How far out of the question, or is even out of the question, for me to build a .NET Core app with the Xamarin Forms UI that effectively runs anywhere?

Jim:
Well, right now, obviously, that's not something we have. But it's interesting you mentioned that. So one thing that's happened with the rise of .NET Core, the growth of Mono and obviously the the lovely coming together that is Xamarin and .NET Core - well, Xamarin and Microsoft - is that there is a lot of code being shared between Mono and .NET Core. So if you actually look at the kind of break up of Mono it's - these are very rough numbers, and somewhere on the Mono GitHub repo theres all the actual numbers there - But that thing's like the base class libraries is pretty much a third of it came from Mono originally, a third of it comes from Core, and a third of it comes from the Microsoft reference sources. So there's been code coming from .NET core into Mono, and code coming from Mono into .NET Core.

In fact, someone was saying that the day that Mono lifted 120,000 unit test from .NET Core; could literally just lift them up, drop them in, run them, and they all just passed. So it feels like there's a great big coming together of the two. I don't know whether there will be one day, just one platform. I don't know, but I wouldn't be surprised if one day there is just one platform to rule them all that's made up of .NET Core and Mono. I don't know this for a fact. I'm just totally theorizing here. This is just my opinion, but I feel that one day there will just be this one platform And then, when you've got your Core of .NET as it is, which would be .NET Core you then just pick your platform that goes on top and you picked WPF, or WinForm, or you UWP, or iOS, or Android, or GTK for Linux. Or, you know, maybe even Unity will be on their, with ASP.NET Core top of that. And then you think about .NET Forms as that becomes the natural abstraction that sits on top.

So yeah, I can see that happening. You think about how we've got a community who built a WPF back end for Xamarin Froms, that allows you to run a Xamarin Forms app as a WPF app running on Windows 7. At some point, someone's gonna need to update that to support .NET Core, and WPF because that's the future.

So, yeah, give it a few years and My personal thought is there will just be the one .NET Mono Core technology. And then, yes, you'd better spin up a Xamarin Forms app. And using technologies like Ooui, for example, you could then run that on Web assembly, and that's obviously built for Xamarin Forms. So you run it on everywhere.

So yeah, I could see happening, definitely happening.

Jamie:
Cool, because we've had a slight minor controversy on the show before. I just wanna point out to listeners: That was Jim's opinion. That is not a road map, that is not confirmed in any way. That is one person's opinion of the way that things could go. Because we had something similar said on an earlier episode taken completely out of context, and I saw even Scott Hunter was commenting on it at one point, so that was a bit scary if I'm honest.

Jim:
Yeah, this is totally my opinion. This is me guessing as to where the future might go.

One thing is very cool, of course, is that .NET Core and Mono are being built out in the open. Now there are some cool things coming the .NET Core space, which I can't talk about. But I don't if you know that there's Microsoft Connect up on the 4th of December, which is a virtual conference that's being streamed from much Channel9 studios. We've got the two Scots, the upper Scott and the lesser Scott. So we've got have Scott Guthrie doing the keynote talk about cool stuff in Azure and then Scott Hanselman talking about some of the great stuff coming up. And there will be a lot of stuff on there around the new things that are coming.

So if you don't know of Connect, you should check it out. You should watch it. It's going to be streamed from about half past 8 in the morning, Pacific time on the Fourth of December. All the videos of available on demand afterwards, you can watch them.And one thing that's really cool about this, is we're going to be streaming a lot of the sessions over Twitch and Mixer, so they'll be interactive sessions. So when you've got one of the .NET team showing off the new shiny that's coming in .NET Core you will be able to actually ask them questions, and have those questions answered. It's not just going to be a case of watching a video some person talking there will be a chance to be interactive. So yet that on December the Fourth, if the UK based stay up all night and watch Connect, it's going to be incredible.

Jamie:
I will have to point out though, that with the way that this episode of scheduled, that will be in the past because of the great time machine podcast wibbly wobbliness.

Jim:
Okay, so connect was it was a few weeks ago. And Connect was where lots of great things were announced, which I've completely forgotten and ca'tn tell you about.

Jamie:
precisely

Jim:
There's definite. There's gonna be some cool stuff coming at Connect, because there always is cool stuff coming.

But yeah all the stuff around Mono and .NET Core, that's totally my guess as to what's gonna happen. But .NET Core is been developed in the open, Mono is being developed in the open. The published road maps are available. And the numbers, the fact that there's a certain percentage that comes from .NET Core, all that's publicly available. And so yeah, you have watch that and see where that goes over time. But I'm very, very excited for the future of Mono and for the future of .NET Core just because there's things that each platform has that the other one doesn't. Like, for example, the Mono linker.

So .NET historically hasn't had a linker. It's just being JIT'd IL code, whereas Mono has needed a linker so that you could compile to the smallest possible apps to run on iOS or Android. And, of course, the Mono linker can then be used on any IL code. So you can, in theory, use the Mono linker with .NET Core code to build .NET native apps. So it's just really cool, what's happening between those two platforms and the capabilities that both have. Because they share a common understanding of IO and the whole of the commonality between the two.

Jamie:
Can you imagine in the late nineties, with all of the people at Microsoft was saying:

Hey, we need to build this thing when we're not sure what we're gonna call it yet, but we're going to eventually call it .NET. We need to build this one thing, and then in twenty five years time, it will be everywhere.

Can you imaging?

Jim:
Yeah.

Jamie:
I don't think that have believed you if you told them.

Jim:
No. And certainly the company culture back in those days. Whereas if you said that their core flagship development technology but run on Linux, and Apple devices, and Google devices, and that it would be open source. They were thought you were mad. But that's how it is. It's part of the new way of Microsoft, and that's why Microsoft is becoming such a successful company.

Obviously, I don't what's the state of play is gonna be when this episode has gone out, but over the past few days the stock market has gone a bit crazy, and Microsoft pipped Apple for the most valuable company world for a few minutes here and there, and it's kind of vying for first place. Go back ten years that's wouldn't have seemed, well even a year, and that wouldn't have been unheard of.

So the way that Microsoft are do things these days, the way that we're embracing open source, we're building incredible tools out in the open, and we're putting those tools everywhere. It's just changed the company for the better. And the fact that we've got this one consistent platform, we've got .NET. So if you're a C#er, or an F#er, or a VB.NET developer, you can put your code anywhere. VB.NET, not supported on Xamarin, unfortunately. But if you got, say, C# code, you can run that inside an Azure function up in the cloud; you could run in a WebApp in the cloud; You can run it inside a SQL Database on-prem and the cloud; You could run up on the desktop app; on a website; on a mobile app.

You hear Satya talk about ubiquitous computing, it's just stuff that runs everywhere. And, yeah, .NET is pretty much the power that does that. You know, you install Java and it says so many billion devices run Java. Well, so many billion devices run.NETT and it's a phenomenal platform.

So excited for the future of .NET.

Jamie:
Yeah. I remember, was it last year or the year before, I remember screen capping it for a blog post I wrote. There was a wonderful slide that literally said ".NET Anywhere," and it had a picture of the Android logo, the iOS logo, windows and a few other logo's all around it. And I thought, "That's what Java originally promised."

Jim:
Yeah, Java kind of promised this write once, run everywhere, and two some way it works. And Java is a fantastic language, with some great capabilities. I wouldn't say Java UIs have ever been the best, but for server side code, there's a lot of good stuff. And there are some people who have created some fantastic Java UIs. But .NET also seems to have met that promise and it's doing it in style. It's got some incredible capabilities. It is definitely that write once, run anywhere technology.

And even down to IoT, for example. So I don't know if you've been following but there's a KickStarter called Meadow, and they have got an Arduino style board running .NET. The kickstart has literally closed a few hours ago, as we as we speak it's closed a few hours ago. This company founded by one of the former VPs from Xamarin. And this has got a full .NET Standard framework running on an IoT device.

Jamie:
Wow.

Jim:
So it doesn't matter what you're on, there is .NET for it.

Jamie:
That is amazing. It says on their KickStarter page:

The power of raspberry pi and the computing factor of Arduino, and the managability of a mobile app.

Yup. That is just... wow. The future is amazing.

Jim:
Yeah, it is. It's incredible. It's absolute incredible. And to me the future is .NET, to millions and millions of developers the future is .NET. It's incredible technology. I honestly can't see why you wouldn't want to be a dot net developer.

You know, Scott Hanselman often says that, "now is the best time to be a developer," and you can say that every single day. But now and .NET is definitely the best place to be a developer.

Jamie:
Yeah, definitely.

Jim:
Exciting times, isn't it? Exciting times.

Jamie:
It really is. It really is.

So a couple of shorter questions before we sign off, then if that's OK.

Jim:
Yeah

Jamie:
What was the name of the book again, sorry?

Jim:
So the book I've written is called Xamarin in Action, it's published by Manning. If you want to buy a copy if you had to xam.jbb.io, then that would take the Manning website. If you use the Code xamarininaction all one word, lower case, you'll get a substantial discount. It's about forty percent. I think it is, which is pretty cool.

Now, the whole premise of Xamarin in Action is to take somebody who's got some C# knowledge - a few months minimum - but take them from zero to a full mobile app. So it focuses from Xamarin native rather Xamarin Forms, and focuses on a deep understanding off the MVVM design patternn; how you can use this to build mobile apps and share your code between the two platforms. And then how you actually design a mobile app; think about the experience of a mobile app. And then build it; understand the way mobile works and things like SDK versions; the structure of a mobile application. You then create your app. It uses Visual Studio app centre to do things like analytics; crash reporting; testing - it's got a whole thing on user interface testing, using the Xamarin UI test tooling. And then it's get your app distributed testers to test itt out, and then actually deploy to the stores.

So it's the idea being that you can build a complete Xamarin app, understand the architecture, build it and deploy it, you know, from back of a napkin idea to the store, all in one. Rather than just being here is an API reference for stuff, it's the actual underlying architecture, mobile paradigms, absolutely everything. So you can take an app and ship it.

Jamie:
Wow. Okay, I like that. I like the idea by the inaction books. Because, like you say, you could have, a completely different situation but if you look at C# in Depth by Jon Skeet, that's very much a case off:

Here are some incredibly detailed descriptions of the parts of the spec which are useful, but not if you're building a CRUP app.

Jim:
Yeah.

Jamie:
Whereas the in action books are:

Here. Is that an idea for an app. Lets go through the process off creating the entire thing. And, like you say, how you would build unit tests and CI/CD and all that kind of stuff.

Jim:
Yeah, it's one thing I think Manning does really well: is it pigeonholes the different books into the appropriate place for them. So that inaction series is, "I want to get started. I want to build something. I want to understand what I'm building." And then the in depth series is, "Right, now that you know what you're doing, let's dig in deeper. So you can learn about the hard things, how to do things better." So it's kind of a place for both series of books. It's like when I first start with something I want in action, as I know more I want in depth.

So Manning do that very well. And I must admit, Manning, they're phenomenal publisher. Just the amount of effort they put into making sure they're writers are good writers. So I had, I hate to think of how many hours of training from my editor about how to write a book, before they even let me write my first chapter. And then So many reviews; so many editorial teams; so many technical editors; technical correctness checkers.

Yeah, the book is not a cheap one. Manning are not one of those companies that will do: "every day there's another book for a fiver." You know, they are really good quality books. They put a lot of effort into them. So I'm really proud to have written a book for Manning. And I like to think my book is quite good. I've had some good reviews, so I'm sure other people think the same thing.

Jamie:
It's definitely on by my list of "the next book to buy from Manning,"is that one. Because I have, like, I said at the beginning, I have the .NET Core or in action and the ASP.NET Core in action. The Next one, his Xamarin and in action. And then there's like Microservices in action. I'm just going to have the whole collection, and be the envy of everyone I work with. I could be the person who goes into working goes, "Yes, you're doing ASP.NET Core. Here's what you need to do. You're doing in Xamarin and here's what you need to do."

Jim:
Yeah, I would love to have a whole shelf of those. But I'm not allowed to have lots of books. I did have a lot of programming books, and I was quietly encouraged to dispose of them.

Jamie:
Okay, so where can people go to find out more about you and the work you're doing and all that kind of stuff?

Jim:
So the best place to find out more about me is on the twitters. So my twitter handle is Jim Bob Bennett. So I'm on there, my DMs are open. You can ping me and ask me any questions you want. I blog at jimbobbennett.io So I've got a blog there, and I blog regularly about Xamaring and Azure based things. If you want to come meet me, see me at a conference, I'm going to be at NDC London at the end of January. I'm giving a talk there on Fabulous which is the F# model-view-update style architecture that sits on top of Xamarin Forms. So I'll be there. Come and hang out. Come see my session or DM me on Twitter if you wanna meet up for a beer.

Other than that, we're taking some of great Microsoft Azure as your content on tour. So you have a thing called Microsoft Ignite: The Tour. We've got, I think it's either 14 or 17 stops all around the world, where we've got other Cloud Advocates like me, showing off some great things. We got some fantastic learning paths, so you can come along and say, for example, you want to deploy a WebApp, we will take you through the whole process throughout the day. So rather just lots of different disparage talks. It's a whole flow you can go through, depending what you want to learn, with phenomenal people presenting. I'm probably going to be a in Singapore, Seoul Washington and London for that - that's still to be confirmed. But otherwise is cool people like me going to be at this various stops, so just Google "Microsoft Ignite: The Tour" to find out what's going on there. That's an azure focus thing rather than a Xamarin focused thing.

Other than that I'm usually on the conference circuit or on the various meet ups. So if you want me to come to a conference or your meet up and talk about Xamarin, just get in touch.

Jamie:
Fantastic.

We were talking just slightly over about recording and software that I used to record, and you mentioned that you have a podcast. Is this something that is a going concern, or is this on hold?

Jim:
So it's a little bit on hold. I created The Jim & tonic Show where I was just chatting to other cloud advocates that I worked with. And I did about eight episodes, and I haven't done any more sense. so I do need to reboot that podcast at some point. You can check it out, it's on iTunes and all the various other podcasting apps. So it's called The Jim & tonic Show. And yeah, I haven't done anything for a while, I desperately need to reboot it, and you've now publicly shamed me.

Jamie:
Well, maybe this could be it. This could be you saying publicly, it may or may not be rebooted.

Jim:
Yes. My New Year's resolution is to try to record a hole load more episodes, and get some more out there.

Jamie:
Fantastic. Okay. Well, yeah, that's all the questions that I have for this chat. I just want to say Thank you ever so much, Jim, for being on the show. There's been a real pleasure talking to you. I've learned so much about Xamarin just in the 50 minutes we've been talking, it's amazing.

Jim:
Thank you very much for having me, it's been a lot of fun. And, as you can tell, I never get bored told about Xamarin. So if anyone else want to get bored senseless by me talking about Xamarin, just send me a twitter DM and I'll talk your ears off.

Jamie:
Well, there you go listeners you've been told. "Bye bye inbox," is what I'll say.

Thank you ever so much Jim, it's been fantastic talking to you.

Jim:
Thanks.

Wrapping Up

That was my interview with Jim Bennett. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and a collection of text snippets from the interview. The show notes, as always, can be found at dotnetcore.show.

And don't forget to spread the word, leave me a rating or review on your podcatcher of choice, and to come back next time for more .NET Core goodness.

I will see you again real soon. See you later folks.

, often