 Hello, welcome to another.net.com presentation. I am your host for the moment, David Ort now, Xamarin Forms program manager. And I'm really excited you've joined us here. I have to start off by doing one thing though. I understand nobody has done a spin in the chair yet, so that had to happen. I don't know how people resist doing that, so. But hey, listen, I started off with 40 sides. I pruned it down to 51. I think I'm up to 52 or more, so we're going to go fast and furious. I have a lot of updates for you on Xamarin Forms, and I want to make sure I get through them all. So if you have questions as we go, definitely put them in the chat wherever that thing is. And I'll make sure that I try to get to as many of them as I can at the end time permitting. All right, so here we go. So first, let's talk about some of the basic details just to make sure that everybody knows where we stand today. 310 is our current stable release of Xamarin Forms. And 3.2.0 is our current pre-release. So if you haven't been checking the pre-releases, please do, because there's a lot of really good stuff in there, and we depend heavily on your feedback to know how we're doing. Is it stable? Is it meeting your needs and your particular scenarios? We obviously dog food and test heavily as well, and you may see that I file plenty of bugs as pre-releases come out. And then we also have the next stuff, our master builds, which come out nightly. So nightly means that as long as the builds are all green and we're good to go, then those will get posted to this feed, this MyGit feed. So be aware of those things. Check those out, please. In terms of when 3.0 will go stable, we're on pre-release three. That went up a couple of days ago. We're hoping that's a stable candidate. We found maybe a couple other things in there. I'm not sure if they're blockers, but hoping within a very short period of time, maybe the next week, that that will be our stable release. All right, so where you can find good information on a day-to-day basis. So we maintain our GitHub projects. So if you want to know what the current sprint is, what the work is in that sprint, we do three-week sprints, as well as what's blocking for upcoming next releases, check out our GitHub projects. You'll find lots of really good up-to-the-moment information there. And then the feature roadmap. So in the Wiki, in addition to the feature roadmap, there's other things. But if you want to know what we're working on, where we're going, it doesn't necessarily reflect absolutely every detail. We might do a spike here and there to investigate some things. But in terms of what you can expect and general time frames of when you can expect to receive it, that's the place to be. And then in addition to the feature roadmap, there's also details about which platforms are currently being supported and what the status is of those platforms. So if you are interested in Mac OS, GDK for Linux, Tizen, or WPF support, that's a place where you can find good information on that to know exactly where things stand. All right, so here's what we're going to dive into. We're going to talk about some big things, some little things, and some next things. And I imagine based on the feedback that I've gotten on Twitter, as well as through the Community Xamarin Slack channel that the next things is really what you're mostly interested in. So I'll barrel through the big and the little and we'll get to the next, but you got to stick around for that. So that's the price you got to pay. All right, so let's talk about big things first. So the first big thing that I want to talk about is that my son just today, just before I came in here and got his driver's license. And if you happen to be in this general area of St. Louis West County, you may want to avoid some of these roads. I know that's the common thing every parent says when their kid ventures out on the road. My concern mostly is that you may not get there on time because he's probably gonna be going the speed limit as he should. But why am I bringing this up? First of all, I'm obviously proud of my kid. So congratulations, Declan, on getting your driver's license. But most importantly, when it comes to teaching your kids to drive, you end up hearing yourself repeating things over and over and over again. And emphasizing some of the basics and some of the fundamentals that you yourself may have not been paying much attention to. So this is what I'm gonna start by talking about in the big things. Over the past year, we've shipped quite a few things that are hugely beneficial to you. And I wanna make sure that everybody's aware of them and hopefully using them. So first of all, XAML-C and compiled bindings. XAML-C is compiled XAML. So that's gonna give you compile time checking of your XAML. You don't have to wait till runtime to find out if it's gonna blow up on you. And then compiled bindings is going to give you that little bit of performance boost for all of your bindings. You specify your data type here. And for example, here I've got a named color, which is coming off of a view model. And then I'm binding to my color. So do simple things like this. It can really improve the performance of your app and get you there. Something in terms of XAML-C, if you were at all concerned about the impact on your build times. And we recently did quite a bit of work on build times and we got it down the smart hotel 360 app as a matter of fact, that Miguel was showcasing in the first presentation. In that particular case, XAML-C was taking upwards of seven seconds in some situations and we got it down to a second or below. So plenty of good work happening there. And also, I mean, I just really have to emphasize if you haven't watched yet Miguel's portion of the presentation this morning, please do. A lot of really good work in the tooling, especially build and compile times and that loop that you have in terms of how quickly you can see your changes is happening. And I'm just, I'm focusing on the SDK side of things. So I'm not talking about tooling and build system stuff, but know that that is very important to us. We ourselves are very much involved with it from the SDK standpoint. So check that out, very good information there. So that's XAML-C. Android fast scrolling, did you know you could do this? So this is a feature of Android and you can enable it using this platform specific. Turn that puppy on and you'll get much better, smoother fast scrolling on Android. Android fast renderers. So if you're a long time Xamarin.Forms user, you're aware of this. If you're new to Xamarin.Forms, I'll kind of explain what happens here. When you ask for a button in XAML, what you actually get when that's rendered on Android is you get a button renderer with the app compact button inside of it. So in terms of Android view inflation, you actually inflate two views. So that's not ideal. And more views slows things down, creates deeper nesting in your UI. So what we've done with fast renderers, too fast when we went to fast renderers, we were able to refactor out everything that was in that button renderer and make sure that everything still worked with the app compact button. So this greatly reduces the UI that needs to get inflated to do your app and thus improves performance, both in terms of runtime and startup. So to enable this, we have a set flags method. You call this just before you call the forms in it and you pass in the fast renderers experimental. Now I get the question all the time, is it just experimental? Why is it experimental? When is it going to be not experimental? When are you going to un-steal it and let us extend these particular renderers for the button, the image and the label? I think that's coming very soon and the shell work, which is a tease for what we're going to be talking about later, leads us into some of the things that will allow us to do that. But for now, this is what it is. Lots of customers are using it and having good success with it. I myself use it all the time. Let us know of course, file issues if you have issues with it, but the experimental is there more of just a warning. But it's been out for more than six months, almost a year now, so use it. It makes your stuff faster. So layout compression, this pairs very well with fast renderers and it's kind of in the same theme. So if you consider this particular layout, you have your content page, within there you have a stack layout and then within that you've got a grid. That grid has three labels and then you have a list view below that. Now, that's a fairly deep stack of UI and really some of those things are unnecessary from a representation on screen standpoint. So with layout compression, what you can do is you can decorate the different layout elements that are really not necessary to be visually represented and you can say, make those headless. So compressed layout dot is headless equals true and what happens is, as you can see in the image, those views don't need to get inflated anymore. That is handled at layout time. The calculations are all done for you and the nice result here is that, for example, in this particular UI for a profile, that uncompressed profile has 130 views that need to get inflated to generate that guy. The compressed version is 111, so we're able to reduce the layouts quite significantly just with compressed and then when you combine that with fast renderers, you get down to 70 views. So you've gone from 130 views that needs to get inflated down to 70. That's a significant improvement, which will improve every aspect of the performance of your Android applications. All right, another benefit for you is native forms. So native forms is when you can take a Xamarin.Forms UI and embed it directly into an iOS or Android or WPF or macOS or GDK application. And what this allows you to do is, instead of Xamarin.Forms being necessarily the driver and the container for your whole application, you can have your native UI and just where you want that shared UI or those more suitable UI to Xamarin.Forms or just you wanna be able to share more Xamarin.Forms across everything that you're doing, then you can use native forms to embed that. It does work with Xaml-C, Binding's Message Center, dependency services and essentially what you end up doing is you call a create method, a simple helper on the particular content page that you want to embed and it will hand off to you the native control element. On iOS, that's a UI view container or UI view controller, excuse me, activity on Android, a fragment on Android or a framework element on UWP. And then the appropriate elements on those other platforms that I mentioned. So, yep, here's a quick example. If you go look at the smart hotel 360 repository on GitHub and check out the maintenance application, I believe is what this is called. Really, all you need to do is you need to initialize Xamarin.Forms one time before you try to get that content page. And then in this particular example, I'm setting up a view model. So again, all my bindings work and then I'm calling create view controller off of that content page. That hands me my UI view controller and I can push that onto my navigation stack just like I push a normal UI view controller when I'm doing iOS development. But again, huge benefit here. I hear from customers all the time that they're benefiting from this. Matter of fact, two days ago, I heard from a customer who said, how do I do XYZ on UWP with Xamarin.Forms? And I was like, you know, you ought to look at native forms and it took me a couple of days to get back to them. And he says, actually, that's exactly what I did and it's working fine, so no complaints there. So that's great. Another feature that I wanna make sure everybody's aware of is left to right. So when you are doing your globalization of your applications and you need to support those languages and cultures that have left to right, this is now supported very easily for you. It's a lot of code, no, it's not a lot of code. It's one line of code. So you set the flow direction on the elements or on the context in which you want to change that direction and it's as simple as that. We provide for you a device.flow direction which will surface the user's phones settings and tell you which direction they want and then you can customize it from there and you can override it at any level down the UI tree that you need to. If you were paying attention at build or anytime since, you've heard us talk about flex layout. And this is a flex box inspired layout system. So if you're coming from a web development standpoint, this will be very familiar to you. One of the nicest things about this is it prioritizes distribution and alignment of your content. It's great for adaptive layouts and I actually have a blog about that which I have a link to below. You have, so if you have multiple form factors, different things that you need to account for which if you're doing any kind of mobile development you absolutely do within iOS and especially within Android you need to accommodate many different sizes. So this is fantastic for that. It promotes also a flatter layout. So just like I was talking about layout compression and fast renderers in terms of impact on performance it's really important to reduce your UI nesting wherever you can and flex layout because of the way that it does layout is really good for that sort of thing. So my blog just flew by, come back blog. So hit that blog if you wanna get a couple more details and see some examples and samples of that and get you going with that. So CSS styles are expressed via cascading style sheets. They're parsed at runtime and this does not replace XAML styles. It does support a ton of properties out of the box but not all and the styles are applied one by one in definition order which is the cascading aspect of CSS. So this is a really well, it's a great feature to pair especially with flex layout because you can start grabbing samples from the web and use them pretty much as is. And that's a very cool feature. I know that Miguel is a huge fan of the CSS as I think he mentioned this morning, as am I. But again, it doesn't replace XAML styles. It's really your preference in terms of what you want to do. And the style is defined on the item itself or always applied last. Things are a little out of sync on my computer so I'm double checking. All right, so here's a quick video demonstrating some flex layout. You can see that I'm specifying a direction so that I can do column, I can do row. There's also column reverse and row reverse which is pretty awesome. And then you can wrap and several different wrap settings. And you'll see as I'm doing this, I'm getting my updates over there in the XAML previewer. I have a CSS over here on the side as well so you can see that that's working in concert and I'm overriding the flex layout settings here that were specified over there. And there we go. So several samples like this, this particular UI is actually in the conference vision app which is up on Microsoft GitHub.com, Microsoft conference vision. You can check that out. But I've got actually quite a few flex different layouts that you can accomplish. And this is by no means an exhaustive demonstration of what flex layout can do. But it's a good start and you can really push it to the limits. And there's several properties you'll need to learn to master but once you've got them down, I find it to be extremely flexible. All right, and then quickly visual state manager. So with visual state manager, if you're familiar with UWP and WPF, this will be very familiar to you, of course. It allows you to specify property changes that you want to initiate based on state changes. So you can kind of bundle some things up and then initiate that state change and update your UI. There are some common states that are provided for you with many of our controls, normal, focused and disabled and to trigger these, you call a go to state. And that's fairly straightforward. I have a sample here. This is the URL I was spouting off earlier for the conference vision app. And so this is the camera. So what you see actually happening here is that it is changing the orientation. As the phone changes orientation, it's redoing some of the layout. So we want to make sure that the preview, that little green square there is where it needs to be and is in the right orientation when the phone changes so that things are good. So check out that sample. A lot of cool things actually in that sample. I tried to put a bunch of little tips and tricks in there along the way. All right, so that's the big things. How are we doing? We're good, only 416. All right, so the little things. So let's talk about the little things. So when I say little things, I'm mostly talking about the F100s. So back around December, January timeframe, I started asking the community, reaching out and saying, hey, what do you want to be celebrating at the end of next year? What are you excited for? What's causing you friction right now? And about that same time, one of our community contributors posted a poll and said, hey, what are you having to write over and over again that should just be baked into Xamarin forms? Why do you have to do these things? And what we came up with through that and through also talking to other developers and the team was this list of F100s. This is not the full list here. These are the things that we're delivering or will be delivering soon. So essentially what these are, they're little paper cuts. These are the things that you're like, oh man, why do I have to go down into native code when all I need to do is set one property or do one little thing? Or things that are very common that need to be done that are just currently not very easy to do in Xamarin forms. Now the great thing obviously about Xamarin forms, and I don't want to minimize this at all, is that it's riding atop the native platforms. So Xamarin iOS, Xamarin Android, it's all there. You have full access to all of the native APIs, the native UI, you can do it all. Xamarin forms just makes it easier for you in terms of creating you that common UI layer as well as some of the common API layers that are there for you to achieve more of that cross-platform productivity. So not to minimize that, that's an awesome power and that's what drew me initially to Xamarin forms when I came from native development, is that I could always access those things and I was not restricted in any way. But when you're doing the same things over and over again, let's go ahead and address those things. So this is here, hit that project board link. You can see what is in progress, what's being worked on. But the thing about the F100 that's been very cool is that it's been fueled by community contributions. And so I had to take a moment to say thank you so much to everybody who has contributed, whether it was just to the conversations, whether it was to the review of the code, or whether it was to the actual PRs. A lot of this would not have been possible without you. Certainly not in the timeframe in which we've been able to deliver it. And so thank you so much. It has been very, very cool to not only see those things come through, but to participate with you in that. And I look forward to much more of that. And in terms of that, if you wanna join in on that fun, these are a couple of great blog guides, one for what we're looking for in terms of contributions, and another one in terms of when you pull down the Xamarin.Forms repo, how do you get it building and how do you debug it from John Goldberger, one of our great writers. So check that out. And one other shout out in terms of contributions. You may notice in our release notes, and that's the word I was looking for. When you look in our release notes, you may notice that multiple PRs are associated to certain features being shipped. And if you click through them and look, you'll notice that almost every PR that we ship for an iOS, Android, UWP core thing is matched by one for Tizen. And so a huge thank you to the Samsung team for your continued contributions. You guys are amazing. And I love having you guys contribute that stuff. Tizen, if you haven't checked it out, well worth checking out. We've got a blog post coming up that will give you some updated details about that. All right, Android bottom tab. So what we'll do, I'll look at some of the key, the highlights of those little things and show you how they work and you can get started with them today. So bottom tabs is something that people were asking for for a very long time. And we really wanted to deliver it and so excited that we were able to. And the first, I think this shipped in 3.1 actually. And so some of these things in terms of which versions that they are in. You know, I'm going to tell you use 3.2. It's going to be stable very soon. Just go ahead and start using it. And so don't worry about whether it's a 3.1 or a 3.2 release type thing. But yeah, this one in particular, the 3.1. So with bottom tabs, really all you need to do is on that tab page use another platform specific. So you knew up the name space for the Xamarin.Android and then you're going to do Android tab page and all the different properties that you can set there. So in this particular case, if I had just changed the bottom orientation, it wouldn't have been styled exactly like iOS. And I wanted to get that iOS styling. So I added some of the bar item colors, bar selected item colors, as well as that bar background color to make sure it was consistent for me across iOS and Android. And I'll give you a link to these samples later as well. They're all up on my GitHub. So title view is another one. And this one is coming in 3.2. And that, you know, it's just not easy in particular on iOS to customize stuff that's in that title space. You want to put an image up there. You want to put something interactive up there, something that's a button or something that you can interact with. And so title view enables us to do more of that. And it's fairly easy to do. It's actually a, we have a helper, XAML extension helper off of the navigation page. So that in your content page, as you can see here in the code, you can access that title view and then you can put whatever content view into it that you need to. In this particular case, I have a stack layout with an image. And you'll notice that I have a gesture recognizer on that image. So I'm handling a tap and that works out well. There is a particular issue right now and I'm not sure if it's something we are going to be able to add. But if you try to do commands on those gestures, that wasn't working for me last night. So I reported that. But tapping works great. So you have more control over that. Now in terms of full control of that whole navigation space, that's where something like Shell is going to come in. So we'll talk about that a little bit later. Bindable spans. So this was an exciting one. Adam Pedley contributed this. And very excited and super useful, right? So I think, you know, I was talking to a customer, sorry, a side conversation, right? So I was talking to a customer recently, we were doing a bunch of interviews about Shell and Android performance in particular. And one of the things that they mentioned is that they found that using formatted text in labels was a huge performance boost in particular on Android. Which makes perfect sense when you consider that if you can replace three labels with one label, then you're not inflating all those views that we talked about earlier and everything. So, but then of course, once you start using formatted text, then you're starting to want to do things like what you see here. You want to be able to bind into those spans. And so now that's available. Thank you, Adam, for contributing that. And I think everybody will get a lot of use out of that. Now, something that goes along really, really well with that is commandable span gestures. So you can add gestures onto the span itself as you see here and commands work great. And yeah, I mean, it's really as simple as that. And it's super useful. So here's a quick little animation, or not animation, but a recording of me. Clicking the xamarin.com, which now redirects to visualstudio.microsoft.com, which I'm okay with, it's okay. But we do miss the xamarin.com. Yeah, so use that, that's very cool. Button padding, you know, this is definitely in the realm of the paper cut because man, if you just want to make that button a little bit fatter for that particular call to action or something, it's such a drag to not be able to just to put padding into it. But of course, now you can. Whereas previously you'd have to create a custom renderer or maybe even an effect, which is, I think James Montemagno calls the effect custom renderer's light, which makes perfect sense. So now just simply add the padding to your button and you're good to go. Now this is absolutely one of my favorites and it's funny because I think this one actually has gotten more reactions on GitHub than most. So essentially on platform and on idiom, Daniel Casolino, we call him Kazoo, submitted this PR where you can have this XAML extension to have a much more concise on platform on idiom syntax. It supports default values, supports converters and converter parameters. So here on the background color, you see that I'm calling on platform and I'm just passing it the values I want for the particular platforms and I have a fallback of green. You know, if you've ever done the XAML on platform on idiom, you know it can get a little verbose and that's not necessarily the nicest thing to figure out and type. This is so sweet. This is just, you know, it's the simple things sometimes and it's, you know, the little things that make things really nice and put a smile on your face. So that's awesome. Thank you, Daniel. So this is the URL to samples that cover all of these things and many more. So if you wanna check that out, what this application actually does, I have a 3.1 and a 3.2 tab and I give samples of all the major F-100s that we shipped in there and you can just grab that code sample and explore it. You know, it's not, it's a basic app but I think it gets the job done. All right. So we've actually got plenty of time to talk about the next things. Woo-hoo! Hey, I'm on the screen. All right, so next things. So first of all, I wanna call attention to Xamarin Essentials. Xamarin Essentials, we've heard from James earlier and from Miguel earlier as well, is that cross-platform API. So you can think of Xamarin Forms as your UI cross-platform, whereas Xamarin Essentials is your cross-platform API. So all these things, accelerometer, battery state, clipboard, connectivity. Everybody's app has a connectivity plugin in it. Permissions is in here as well. There's actually, I think more stuff than is listed on this particular slide. And more is coming. So it's in preview now and I believe we'll be going stable very soon. I've been using it. I know many of you have been using it. So go for it. And the API is nice and clean and smooth and super easy to use. Check it out. Highly recommend that. More CSS properties. So this is coming in 3.2 and what comes next. And so we've added just generally some more properties because what we were hearing from customers and what I started complaining about as soon as I started using CSS was this is awesome but I can only go to here and I need to style this, this and this and how do I style that? And I don't wanna have to jump between my CSS and my XAML styles. So we started adding more of those properties where we can. What we started with was essentially what CSS naturally supports, which I think makes sense. But we wanted to start adding these. So these elements are getting some new CSS properties available to them. And then coming very soon, we're actually borrowing from the vendor prefix idea. So if you're a web developer, you're very familiar to the web kit prefix, the Moz, the IE prefix, all those sorts of things. So we're doing the same thing here. So for those properties that really are not analogous at all to what you would get in web development and they're specific to Xamarin.Forms, then we're going to, or we are decorating them with a XF prefix and you can access them. So a lot more coming. I think this is a short list and we'll be working to ship more of these things. Ideally, so that for those who love CSS and wanna use that as their primary styling mode, you can do all the work there and you don't need to jump between CSS and the appearance class are for iOS and XAML styles and all those sorts of things. All right, collection view. So we have a spec up and we did a spike and the spike went well enough that we're proceeding with this. So it's list view, but better. List view is perhaps 25% or more of the issues filed on GitHub for us and it's something that we continually battle but it's also one of the oldest pieces of code in the project so a lot of skeletons maybe, I think is what some people might say. So we wanna do this better. I see questions on the screen so now I'm distracted but I won't do that. So it's list view, but better. Performance is definitely a key priority but also some of the functionality things that customers that you might have trouble with when it comes to implementing things in list view, swipe gestures and things like that as I mentioned here at the bottom, fully customized context menus. On Android, it does use the recycler view. That's a question I have frequently gotten. Hey, when can we start using recycler view? Can you just replace list view with a recycler view for Android? So that is what collection view is using on the native side. And then one of the really cool things about the way collection view works is that you provide the layout. So it can go horizontal and vertical. Right now, there's really no great way to do horizontal. So this fulfills that need grid layout. So you can do two up, three up, four up, you know, whatever you need to do from a grid standpoint. And then flex layout is something that we've experimented with. The main concern right now with flex layout is in terms of virtualization. If we were to do flex layout, the way that the measurement works and everything, it's not really very virtualizable. So if you were to use flex layout, you may have to opt out of that. We're not, you know, that's a conversation. And if you have thoughts on that, join the spec up on GitHub and say, hey, heard you guys are toying with the idea of flex layout. Here are my thoughts. Here's what I'd like to see, in particular about the virtualization topic. Which kind of also gets to the repeater view question in terms of I just need something to just paint a bunch of stuff on the screen. Collection view kind of meets that need as well. But again, it's maybe a bit heftier. So I invite those comments and conversations there. So yeah, context menus and gestures. So here's a quick video. I think this may be the same or very similar to what Miguel showed earlier today. So we've got a grid layout. We've got each of these as a card and it's painting those all out there. It does respond to horizontal and vertical, you know, landscape and portrait. So very straightforward. It's still very early. We've got a lot of work to do. Primarily working on Android right now. If you hit the roadmap, actually, I just put up the spec link and the branch that is the working branch right now. And you can go check out that work directly, read the code, see what's going on. And of course, check out the projects tab. So you can kind of see the progress on things. So here's some of the code. So the XAML collection view. My collection view is named Spaces. Really nothing happening in XAML. You will eventually be able to do everything in XAML, of course, but in this particular case in the C-Sharp, we have the items layout. We're adding the grids item layout to it and then specifying how many columns, how many up we want and then the orientation. Specify the item template. Data templates is definitely driving things. View cells is a problem, problematic. It adds another one of those layers of view to our UI. And we want to make sure that we're eliminating as much unnecessary view inflation as possible, speeding everything up. So data templates are key here. And then, of course, I'm binding the items to the item source. So while this was happening, there's a PR that we've been working on for a long time. And we were like, how do we respond to this? Where are we at with this? What are we going to do? And as we were considering collection view and what it all does, we realized that collection view actually affords us something else, which is a carousel view. So if you consider what a carousel view fundamentally needs to be able to do, let's display a list of things. And we just needed to add, not just. It was work. Don't get me wrong. We needed to add that locking and then adding pagination and being able to step through things. So here's a couple of more functional examples that's in our gallery. So if you download this particular branch and you run the gallery, you should be able to run these carousel view samples yourself. But you can see that you can choose whether or not you're actually animating as you're advancing programmatically or if you want to just jump to something. It paints numbers of items very quickly, which is awesome. That one's not going. You can play the other video too. You can see both videos going at the same time. There we go. So we did a spike on this. We feel it's very promising. And at this point, we feel like this is going to be our carousel view. So there's a whole history of carousel view for us. And we have concerns about the one that we initially put out there as a preview. And this is a much better approach to it. And we've had several community contributors work with us on trying to integrate their carousel views into Xamarin Forms. And I want to take a moment and say thank you so much for doing that because it was a huge learning process for us. I know that there's been a lot of back and forth. And it hasn't been a very smooth. I mean, carousel view is a huge amount of code. It's not inconsequential. So we feel like this is the best path forward for us with carousel view. It maximizes the use of collection view as well and also kind of minimizes the amount of code that we need to worry about maintaining. So yeah, that's carousel view. Very excited about it. And as we have updates to it and these samples, I'll make sure that I publish those. And I'll let everybody know through Twitter and I'll post it to GitHub as well. All right, next up. So Xamarin Forms Shell. So Xamarin Forms Shell is a very interesting thing. I believe the way that Miguel described it earlier is when you get Xamarin Forms right now, it's like you have a box of Legos with no instructions. Whereas Xamarin Forms Shell is an opinionated approach to generating the scaffolding for your application. And that is very true. And I think that many of you will find yourselves being much more productive in the early stages of your application by doing this. Selfishly, I have some very key things that I want to see delivered in Shell. And they're listed here on the screen. Because I know that these things are super important to you in terms of the applications you're building and the time that you're spending building applications and achieving the results you want to achieve. And Shell is a perfect vehicle for us to be able to deliver these things. So first and foremost, it's performant by default. So Shell actually takes a little step outside of Xamarin Forms. It's still part of Xamarin Forms. You can almost think of it, Jason, our engineer, described it as a really, really fancy tab page. So but because we're able to take a slight step away from Xamarin Forms, we can step away from the navigation, which is problematic for us in terms of implementing UI and managing the stack and when do things get cached or not cached and things like that, we can reinvest in that, as well as how renders are realized. In terms of that inflation, whether or not it's synchronous or asynchronous, again, caching is a big thing. So Shell affords us a lot of opportunities to optimize that performance. We have not implemented all of them yet, so if you go play with some of the early bits that are out there, you won't see necessarily the performance at this time, but you will definitely see what I believe is zero GPU overdraw on Android, which is awesome, something we've been wanting to achieve and deliver to you for quite a while. So that is definitely a key thing here. Now, another major request, when we survey customers and talk to customers about what they're building in their enterprises, as well as to commercial and consumers, we hear sometimes upwards of 90% of you saying, hey, I need to be able to deliver the same or mostly the same UI on iOS and Android. That's a key thing for me to be able to deliver and sometimes that's difficult to do in terms of styling it as you do today with custom renderers or effects or just the styling APIs. So how can we make that better for you and improve your productivity? That's another key feature that we're able to ship with Xamarin.Form.Shell. So with this, you will still have the option absolutely of a platform design via shell, but if you want to have a consistent starting point from a styling, you can choose the material shell or perhaps in the future a Cupertino shell that has a starting point of those particular design styles. And then from there, you can diverge. You can always say, hey, I need this control specifically to be platform designed or I need this particular control to be material designed. But that power will be in your hands and rather than as it is today, you have to unify that design. You'll be able to start from a more consistent unified place and then diverge where you want to diverge. You can easily describe your entire app in one file. So this is probably the coolest thing from a productivity standpoint in terms of, hey, you get a design from your designer or this is certainly the case for me. I had 10 years of running my own consulting shop before I joined Microsoft and we would get designs from all over the place, whether it was a creative agency or whether it was an independent or it was somebody's nephew. And you get that design and you just want to quickly say, okay, here's the skeleton for the app. And I know that my navigation works. I know that my pages are all there and I can start filling it with content. The shell.xaml file or shell.cs, your choice in terms of that, gives you that ability to specify those things in terms of layers of shell items, shell sections and shell content. And then customizing the content within the flyout menu and things like that, which I'll show some examples of here in just a few minutes. You get flyout and tab navigation provided for you. You get URL routed navigation with deep linking, which is very desirable. And then the back navigation handling, it's just, it's almost one of those paper cuts where it's like, man, I need to be able to stop the user when they hit that back button so that I can intercept it and say, hey, are you sure you want to leave the screen? This is going to be much easier to do in shell. Whoops, I don't want to go forward, go back. Got too eager. All right, back navigation handling, integrated search handler. So this is where you have that search bar that appears at or just below your navigation bar and then can kind of animate in and out of there. And I think that video on the left-hand side here, if I fire it back up, was doing that on one of the screens. So that's provided for you. You really just decorate your content page with a search handler. You overwrite a method for filtering your data and you're good to go. All the UI is really handled for you. You just need to style it. Snack bar, bottom sheet, floating action button. These are more material design things and you will get in the material shell. And they will work both on Android and iOS. That's a key piece that we're delivering there. Again, it's part of that consistent UI, consistent design across platforms. Left bar button, being able to more easily customize that and this really kind of goes back to that title view area thing too. You'll have full access to override and customize the entire navigation bar. Whereas today, the title view gives you a place to put content. In Shell, you'll be able to really master that whole space. Of course, once you do master the whole space, you own it. So in terms of navigation of back buttons and any of the other OS related UI that gets put there, you are now responsible for that. Screen segues and screen transitions. So screen segues is essentially declaratively saying, when this happens, go to this page. And it's very similar to iOS now if you're doing interface builder and things like that where you're creating your segues there. So you can do this in XAML, you can do it in C-Sharp and you can build your routes based off that. And then screen transitions. This is something that I'm very excited to be able to start shipping is the ability for you to specify, okay, when you do execute this segue, I want you to curl or I want you to go left to right or right to left or top to bottom, cross fade, those sorts of things. So being able to provide you with more transitions to customize that, which today is more difficult to do. And then the key thing, as I mentioned, this is really part of Xamarin Forms. This isn't a new Xamarin Forms. This is just a new control and a new paradigm with which to build your applications and we believe it will be the default in the coming days or not days. I can't ship it that fast. It'll be, when it ships, it'll be the default is our expectation, but you can do everything today that you can do in Xamarin Forms when you have a shell application. So let's take a look at a XAML sample here. Well, I got some code, I've got a couple of images and then I think we're about done. So in shell, this is my top level part of the application. You have your resources where you can specify your styling, any of your other dependencies that you need to specify in your resource dictionaries. And then you start specifying shell items, shell sections, and shell content. Shell content is a content page. And you can see here in this particular example, I'm using data templates and that is the preferred way to do this. That makes sure that you're not eagerly loading those things and having that big bump in performance at the very beginning of your application and those things get loaded when they need to be loaded. I mentioned caching APIs earlier and that's something that we're working on and investigating the best way to implement, but you'll have control of saying, okay, I want this particular page to be retained or I don't care, you can recreate this page over and over again, those sorts of things. And so shell items, what they represent are the menu items that appear in your flyout menu and then within there, you specify shell sections. So in this particular case, I have one left menu item, which if I had a flyout, it's just one menu item, but I can also disable that flyout. If I don't want the hamburger menu, totally fine. Disable the flyout, it's not there. And then shell sections end up representing bottom tabs of your UI. So these are the main sections of your UI. When a shell section has one content page in it, that's what you're gonna see, just as if you had a tab page today. But if you have a shell section like the activity section here in the middle, then that has two shell content, those get represented as top tabs. So at that point, I now have three bottom tabs, one for home, one for activity, one for updates, and then at the top on activity, I have shared and notifications. So this is very powerful in that, I'm just showing a very brief snippet here, but you can compose and combine these things in different hierarchies, or the hierarchy's always the same, but in different ways to achieve the UI that you need to achieve very easily, and it will still obey the native paradigm, right, for that particular UI. So if you go to UWP where tabs are handled slightly differently than iOS and Android, you will be able to expect when you do something on UWP that you will get that result. All right, so here are a couple of screen samples of the different UIs. So you've got a single page, you've got a bottom tab, top tab, et cetera. So we can look at some XAML samples for these. So that single page, very simple, I don't even need a data template for it because I just, you know, go ahead and new that guy up, I don't need to lazy load that, that doesn't make any sense. And because I just have one page, I don't need to fly out, I can disable that, like I said. So at the shell level, I'm disabling it, I'm obviously omitting a bunch of the namespaces and that sort of thing. Something you'll also note is that I have a shell content here and I'm not representing the shell item and the shell section that are actually there. So we wanna make sure that your XAML doesn't get more verbose than it needs to be. And so we have some little syntax here that you can omit them and they will be inferred and be created for you. Well, go back, I wanna go back to some of the other samples. All right, so bottom tabs. So if we wanna look at what that looks like, as I mentioned, you can have a shell section with two shell content in it. And you say, well, Dave, you just said shell section, all I see is a shell item. Well, like I just mentioned before, if I don't specify that element, it's created for me. So what you actually have here is a shell item at the outer level, and then a shell section with two shell content. Now, because I just have one bottom tab, it's not gonna be shown by default. You do have full control to show and hide the bottom tab bar, which is cool. But by default, if you just have one bottom tab, there's no need to have it. It's gonna be hidden for you. So in this particular case, I actually have two shell content, so I have two shell sections at the bottom. I did it again. Who taught me how to use PowerPoint? All right, top tabs. Go to me. All right, so in this particular case, I need to actually tell shell that I want them to be top tabs, and so therefore, I need to wrap the two shell content in a shell section, and that very easily tells shell what to do. If I want both bottom and top tabs, then within my shell item, I specify that first shell content, and then the second shell content. Of course, I can specify more than one shell content within a shell section. As mentioned, they become top tabs. So a little bit of learning curve for sure, but you can specify these things, and it's very easy to get a handle of. There's really only three of them. If you have thoughts about this, this is still very much in development. Feedback for us, please let us know over the past two weeks. I think I've had at least 15 one-on-one developer interviews, and I will be scheduling more. If you're interested in talking to me about this particular feature and how we're putting it together and how it works, I would love to talk to you about that. So hit me up. I'll show you my contact information at the end. All right, so now let's move on. So that's shell, and I guess I should just mention, because the questions will come in terms of shell. When are we gonna see it? How can we use it, et cetera? So up on my GitHub, there's a repository called Gastropods. I neglected to actually include the link in the presentation, I apologize. But you can check that out. It has a very early NuGet package bundled into it, and it's really for exploring the API. Again, a lot of the features and functionality are there, but plenty of things are not. So you can explore the API, you can use this XAML syntax and see what it feels like to structure your application and give us some feedback based on that. All right, so lastly, and then I'll take some questions, gestures. So this is, when we go down the list of when I talk to developers and customers about what are their major friction points, and we wanna be able to deliver the most value for the effort that we invest in them. Something that comes up very frequently, and we've already hit on the ones that are at the top of the list that we're already working on now, is gestures. Cause right now you get basically three gestures in Xamarin forums, but what do you do for the rest of them? There are some third-party libraries out there, but as you know, the more third-party NuGets and libraries that you add to your application, that's more code that you don't really know about that you're using, but more importantly, in terms of build times and runtime performance, there are potential impacts there that you need to be aware of and be cognizant of. So Xamarin Essentials is something that, one of the main reasons that we did that was so that we could bundle a bunch of those NuGet packages together that were very useful, but when you put them all together, that's a lot of assemblies that are in your project and in your build system, so we wanna be able to minimize the number of NuGets that you have. So Essentials is a big thing towards that, and I think that improving our gesture support within Xamarin forums is another thing that we wanna be able to do, to both address that, but also just make things easier. We hear from customers all the time, hey, I just wanna be able to do things in Xamarin forums. I don't wanna have to go to native. Again, you can absolutely go to native, and that's fantastic, and we'll never take that away. That's key to what Xamarin forums delivers and what Xamarin delivers. So we have specs up on GitHub, and we need your input. We need you to go up there and register a reaction, tell us, yes, I wanna see this, or if you don't wanna see it and you're like, I don't think you guys should be investing time on that, then don't vote or let us know that it's not a big friction point for you. But if it is, we need that feedback. Again, I feel like I've got a pretty good signal talking to many developers and customers that this would be a very welcome thing, but we're not committed to doing these particular things yet. We wanna have that conversation with you and to know that this is something that would really be of value to you, or if you're more than comfortable using what's already out there. But some of the things that are on here, long press, pan, pinch, rotate, tap is tapping. Some of these are enhancements to existing gestures and some of them are additional gestures. And there are more up on that GitHub. So look at the gestures label. So with that, I'll start answering some questions. My contact information is on the slide. Feel free to email me anytime to share what you're doing, what your projects are. I love seeing projects. I just saw some AR stuff recently that was amazing and I'm really excited to talk to that company. I'm always excited to talk to all of you. So let me know what you're doing, what you're frustrated with, what I can do to make things better for you. Follow me on Twitter, David Ort now. All right, let's look at some of the questions. We've got, we've got what, 10 minutes? Yeah, no one, 908. All right, Jeremy asks, is there any more work being done to speed up Xamarin Android startup time? Or is it as fast as we can get? So I think I've kinda hit on that hopefully throughout that it is absolutely a priority for us and it's something that we're working on. Deep investigation is happening. As a matter of fact, the Android support library is 2702.1, has some performance improvements in there specifically for Android. AOT is something that we're continuing to investigate the impact in and wanna make sure that that is both useful and reasonable because there are trade-offs with it but that is your biggest bang for the buck right now in terms of startup time. But yeah, lots of deep investigation going on both at the Android SDK level and the Xamarin Forms level. Is text-to-speech support for speech-to-text? Well, so I'll answer that by saying that yes, anything that you can do in the native APIs you can absolutely do in Xamarin Forms. So that is not particularly a feature of Xamarin Forms itself, but you can absolutely get to it in a Xamarin Forms application. What's the roadmap for releases? You mentioned 3.2, what's the target release date? My target release date was like several weeks ago to be quite honest. But we're not gonna ship something until it's ready. And so we identified some blocking issues, which kudos to the team for investigating those issues and identifying them. And so we'll release it as soon as it's ready. My best guess, I don't mind guessing, but in the next couple of days, if not the next week. Are there links to anything that was talked about today? Absolutely, so I posted links throughout the slides. I know I went really fast and blew through a lot of them. If you hit my GitHub, which is github.com, David Ortenow, you'll find most of these samples there. I mentioned the Microsoft conference vision sample, and then hit our repository and check out the gallery there as well. And our documentation, I can't forget the documentation. We've got great documentation on a lot of this stuff. Obviously the new stuff we don't have docs for, but check out the documentation. It links to all the samples that are out there. We have quite a few samples for the recent 3.1 and the 3.2 stuff either already published or ready to go. Xamarin.Form.Shell is like an embedinator for Xamarin projects. Is it like, I don't know that I would describe it that way. So yeah, Shell is more of just a way of rethinking how you structure your Xamarin.Forms applications and making it a whole lot easier, providing you guides for things. And in terms of extensibility and flexibility, that's one thing I didn't really mention, but extensibility is very important. It's something that I want to see more of. And when I hear anybody complain, I can't override this or I can't get to that. That's like, oh man, what can we do about that? Can we extend that? Like now, you can actually load XAML from anywhere. That method used to be internal only and now that's public. And so people are taking advantage of that, whether you're loading it from a database or from elsewhere. Now, you own that once you start doing that, you pay the price for it. But anything we can do to make things more extensible. While Xamarin.Forms shell is a opinionated, here's how you build your app. You still have, and more so now in shell, access to extend those things. So for example, that flyout menu, by default, you can customize the header space, you can style those menu items, but you can't drop things at the bottom and anchor things to the bottom of the flyout menu. By default, that's the way that that flyout menu works. If you want to replace that flyout menu with your own menu, we make that extensible for you. Same thing with the menu items as well, it's icon, text, and a little bit of styling. If you want to fully customize that, you provide a data template for it, and you're good to go. So that's more of how I'm describing shell in bednator for Xamarin apps, not so much. Any other questions? Anything else? All right, I think we're good. So thanks for watching. Please hit me up at the email and the Twitter. And I'll see you around.