Xamarin.Forms Shell New Paradigm
Xamarin.Forms Shell New Paradigm

Hello friends, Xamarin.Forms 4.0 Preview was made available for some time already, and it has several features which I’m excited about. These features where announced months ago, but the one which caught my attention was the Xamarin.Forms Shell. This feature is not yet available on the UWP platform as I’m writing this blog post today. But you can play with it and get acquainted with the awesome benefits it brings to you on iOS and Android. Do this by browsing and running the source code of the demo application on Github. Or reading the documentation available. I though of making this blog post earlier, but as all my subscribers might have noticed, I wasn’t active here for a few months now I’m glad I’m back ???… 

What is the Xamarin.Forms Shell?

The Shell simply put is a brand-new way of structuring your entire application. This approach is very opinionated and comes with several goodies to facilitate the process of scaffolding your entire application, implementing navigation, search etc…

What Are The Awesome Features Brought To You With Xamarin.Forms Shell?

  • The shell provides URI navigation from one page to another, which is easier and more efficient than the previous navigation. This liberates you from the lot of code you needed to write to implement navigation and managing the navigation stack.
    • You simply specify a URL to the page to which you want to navigate and let Xamarin.Forms do its magic and take you to the appropriate page.
    • You can intercept navigation before it completes, and perform what ever task you wish, what ever animation and personalise the navigation’s behavior as you wish.
    • You can easily pass data from one page to another while navigating, by adding this data as a URL parameter, (very similar to calling a controller on ASP.Net Core).  
  • Real access to the navigation bar. As stated by David Ortinau in this video. The navigation bar will be modifiable and really customized by the developer. As compared to the TitleView which permits you to only add views to the navigation bar, with the Xamarin.Forms Shell, modifying core components of the navigation bar like the “Back Button” could be handled by the developer. This brings much more power into our hands ?.
  • You can easily structure your application in one main file. Thanks to this, scaffolding your application into hierarchical visual elements is very easy. You just need to grasp the basics and smoothly define the whole structure of what your application will look like directly. In a very clean hierarchical fashion with the shell items, shell section and shell content. Before moving ahead, I think I should state what the shell items, shell section and shell content is all about. As stated in this documentation,
    • The Shell Item represent one item present in the shell’s fly-out. This item is represented on the fly-out with a title, an icon and this representation on the fly-out can obviously be personalized with a data template. You can also have Menu Items present on the fly-out, but unlike shell items, menu items lack shell sections.
    •  Shell sections are children of Shell Items. There can be several shell sections in a shell item. These shell sections will be navigable via bottom tabs. Each has its title and Icons can be set for them too.
    •  Shell content, these are children of the shell section and each represent a content page of your application. A shell section can have several shell contents. Shell contents are represented by top navigation tabs. As you might have noticed while going through these, adding bottom and top tabbed navigation and separating the content for each section is easy. This along side the flyout navigation, permits you to worry less about structuring complex apps which you build.
  • Searching through the content of your page is facilitated by the search handler, which provides you a smart way of handling search. As you can see in this demo source code, all you do is just implement an appropriate search handler for your page, Override the OnQueryChanged” method for it to perform what ever you want with the searched keyword typed by the user, and add your custom search handler to your page.
  • Consistent Look and feel for your app on each platform is possible by default in Xamarin.Forms. As stated by David Ortinau in this video, you will be able to either chose the Material theme or later, the Cupertino theme. And still have the option to have native look and feel for your applications. I wish “Fluent Design” by Microsoft could be available as a them. Fluent design is so beautiful according to me and should not be neglected.  

Conclusion

The Xamarin.Forms Shell is a brand-new feature, and an awesome paradigm for building apps with Xamarin.Forms. Several other awesome features to improve developer productivity and ameliorations to Xamarin.Forms are available with the Shell. But these are the ones which I think will impact directly every Xamarin.Forms developer. I think the more Xamarin.Forms will permit building applications with less need to access Platform specific code, the better it becomes for developpers.

To have a detailed explanation and a deep insight of the features talked about in this blog post, source code is required. I could make a demo as I usually do for other blog posts, but here are links to resources which have already been made available to serve this purpose. I went through these resources to write this blog post so, why re-invent the wheel? ?  

Gastropods and TailWindTraders apps on Github and the Microsoft documentation about Xamarin.Forms Shell.

Follow me on social media and stay updated

5 comments

  1. MShaker

    Reply

    Sadly this is too little too late. It’s been almost 5 years since XF came out and now we are getting this ? As always Microsoft/Xamarin are playing catch up and know that flutter will blow XF apart / Flutter is a v1.0 product as of 5th Dec 2018 – the API is years ahead to XF v4 – app productivity is crazy – I mean what takes a hardcore XF developer to do in 1 week takes a single day if not hours to accomplish and above all / your app will work without fail on both iOS and Android / the whole development eco system is superb and not flaky like VS studio – there are just so many things wrong with Xamarin and just too painful an experience to develop with it.

    This post sums up the pain very well :-

    https://link.medium.com/OBLtP5hwRS

  2. Reply

    “what takes a hardcore XF developer to do in 1 week takes a single day if not hours to accomplish and above all / your app will work without fail on both iOS and Android”

    I agree with most of what you say but come on… You can’t be serious… Otherwise you are not a hardcore XF developper / never met one 🙂
    Maybe that’s true for a very common app or an app without any framework (from scratch) or if you compare with a hardocre Flutter/Dart developper. I master Xaml enough to write tons of working code without having to look at a documentation/website. I can use tons of service I wrote in the past with dependency injection and a very good architecture. This not yet true for Flutter.

    I’ve started to learn Dart a few months ago (Simple Web then Angular and then Flutter) and I can’t disagree with what you said : it’s just a matter of times before it totally blows Xamarin away. I’ve been writting C# my whole carrer and I even start to prefer Dart over C# for a lot of scenarios. I also tend to use Dart for web, mobile, (and even for backend even if I never put some Dart for server on production) as much as I can. In few words, I love Dart and I love Flutter.

    But saying you do 5 days of work in only 1 is a joke. The first time I wrote a XF app, it took me less than 1 month to build a quite nice looking app : from the front to the back while dealing with push notification myself (push sharp) and other things.

    I still got the feeling I’m far from getting as productive with Flutter as I am with XF. I know I lack of practice with Flutter and it’s just the beggininng for me.

    And if you ever used Prism, navigation by URI with parameters and most of those kind of stuff exist since a while. I know it should have been given in the box. But please don’t make this kind of assumption. I was disappointed by Xamarin because I invested a lot of time and resource into it. And when I see the whole Flutter ecosystem, tooling, etc, I feel fustrated I didn’t switch on Flutter before.

  3. MShaker

    Reply

    Actually yes, I am one of those ‘so called hardcore Xamarin developers’ and I’m not just talking XF but Xamarin.Android and Xamarin.iOS. My productivity in Flutter is as I mentioned 5 x more productive then using Xamarin.

    It seems your experience is more XF based then native Xamarin so I will tailor my response to XF.

    I have architected sophisticated Xamarin apps utilising Prism (since version 2.2 when it was know as CAL/CAB and stopped at 7.0) and a whole bunch of nugets.

    I , like you have also developed through the years many components to allow for swift development – I have created hundreds of renderers and effects to fill the missing gap and add the ‘sweet spot’ that XF should give natively.

    To this day there is still no component to handle back button support for both iOS/Android – in Flutter we just wrap in a WillPopScope – job done. In Xamarin we need to create native extensions via effects/renderers. Xamarin have now bridged this crucial missing component in V4 with Xamarin Shell but this is still too buggy and its a reaction to flutter rather then being something that will compete against flutter.

    Since when in the Xamarin world could we fire up 5+ emulators in addition to physical devices connected to your MAC and run your XF app deployed to ALL of these devices in under 1 min ? Additionally – when could you ever make a change to XAML or Code and see the change propagated to ALL connected devices/emulators ?? Even with LiveXAML – its just not possible, this is one of the very many reasons why I say I am 5 x more productive using Flutter then XF.

    My XAML knowledge is superior and quite outstanding as I have developed for over 12 years doing WPF writing RX driven table blotters and interfacing into dev express, syncfusion and Telerik’s UI for WPF. I have also spent 17 years crafting exceptional C# apps and 12 years developing Swing based Java apps so my UI knowledge is quite simply staggering.

    Thus, moving my declarative UI knowledge over to Xamarin was not a complicated task – I didn’t need to learn MVVM, Behaviors, Converters, Styles, Triggers, etc – I just needed to immerse myself in XAML for Xamarin which as you know has subtly differences. My Xamarin apps are all enterprise driven absorbing ML and other high powered Azure services .

    All Xamarin UI’s that I have coded are XAML based – with only ANIMATION code in code behind. My XAML files are typically 4500+ lines of XAML code for pretty complicated designs and maybe 200-1000 lines for basic. When I say that a Flutter developer is 5 x more productive then a XF developer – its because I have developed for some time in both environments and languages that I can compare and contrast quite effectively both languages/API’s – I have dissected Flutter into what is comparable to XF and what can/can’t be achieved in the same way things are achieved in Xamarin.

    XF apps straight out of the box are plain and boring – this cannot be said about Flutter.

    Flutter widgets for Material/Cupertino exceed XF by about 30 to 1. This is probably much higher if you consider NVO’s such as IgnorePointer and AbsorbPointer etc.

    Spending a ridiculous amount of time getting all my assets ready for various different device sizes for Android/iOS are a thing of the past. Adding images, fonts is too simplistic in Flutter.

    Managing your public packages with pubspec.yaml – again too easy compared with Xamarin, too much time invested in PCL based apps 5 + years ago only to have to go through the (sometimes) painful and troublesome experience in moving to .NET standard.

    CSPROJ files becoming corrupt or just not working for no apparant reason other than you just compiled your app ?!!

    Yes I am 5 x more productive doing mobile apps in Flutter than I am in XF – I can say that because I have spent time developing mobile apps in both languages and for the past 14 months have been doing Flutter for approx 14 hours a day, I’m guessing you are only just touching the surface on Flutter so are not really in the position to sing Flutter’s praises or justify being more productive with Flutter than XF. Once you spend 12 months solid Flutter development it would be great to hear your perspective on this subject.

    Most XF developers struggle with Flutter because they do not appreciate Flutters state architecture and immediately try and develop Flutter apps with a Binding mindset.

    Once you throw away your old bad practices of WPF/Xamarin development which are completely unsuitable to flutter and embrace Flutters rapid eco development system , you will in time, like me , say ‘I am 5 x more productive developing in Flutter than XF’.

  4. Wayne Winter

    Reply

    Have to reconsider using Xamarin if they are going to go half-cross platform, for instance one of the latest features the ‘Shell’ is only applicable to Ios and Android apps and they have completely left out UWP

  5. Reply

    I have been in Xamarin both platform and XF. I got painful experience at the beginning at first. However, in the long run, XF is easy already and stable. I was involved in projects and I created in XF end to end from app down to the api all using C# and got an impressive feedback from client. very small bugs. I know it takes skills but overall, we don’t experience already what your problems are. I didnt go to flutter yet but I guess the UI of flutter is better and faster to do. But I guess XF will win in business codes, stability of business flow logics, easy to read codes, lesser lines of business coding,end to end automated testing for enterprise apps.

    What I see of flutter is expensive for enterprise apps because you need to create 2 separate teams one doing code of dart and another language who will do the api backend. bridging 2 teams coming from different language is another cost. another problem is where will you host your backend and since it is dart, most likely an aws cloud which is another painful for business hiring another expertise of infra related and costly than by just using azure with easy click then done. Just my 2 cents.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.