Forum Xamarin.Forms

ContainerView/Fragment for XAML use

ChrisBoydChrisBoyd USMember ✭✭


iOS has ContainerViews that allow you to Embed another Controller inside a view.
Android has Fragments (which it seems like there's substantial internal Xamarin.Forms code for already) that do the same.

This is the primary thing that I see as "missing" from Xamarin.Forms, which is easy to do with both iOS and Android.

API Changes

Make available a ContainerView that represents a ContainerView on iOS and Fragment on Android, which could be used in XAML layouts.

Intended Use Case

My main use-case would be to add an app-wide, updatable "header" view over a TabbedPage.

Yes, it's currently possible to put a separate header view within each tab's layout, but that seems excessive and would require extra work to keep them all updated.

    <Label Text="Header text"
           VerticalOptions="CenterAndExpand" />

      <local:TabsPage />

I'm sure there's many other use-cases that this would allow people to develop.


Open · Last Updated


  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Its not uncommon for an Android fragment to be initialized from a method, making it impossible to instantiate from XAML. So you have to subclass the fragment.

    Its pretty easy to just use a native fragment without trying to "dumb down" the process.
    At some point a developer should actually have to understand what they're doing.

  • ChrisBoydChrisBoyd USMember ✭✭
    Sure, you CAN use native code.

    Just like you can skip Xamarin.Forms entirely and create a "native" app using Storyboards and Android XML layouts, which would inevitably be more performant than using Forms. (Or, for that matter, continue using Xcode and Android Studio over paying for Xamarin Studio Enterprise.)

    The reality is that Forms is intended to make it easier to develop cross-platform apps (not just for iOS and Android but also Windows).

    The more native elements you use, the more platform-specific code you have to write and maintain.

    Similarly, CarouselView hasn't seen any real development (on GitHub at least) since last year. If the ContainerView existed, then the user could just use CarouselPage inside a container.
  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Putting in the native control turns out to be about 2 lines.
    Even if you wrap the native control in a Xamarin.Forms friendly wrapper you are still stuck with the inability to initialize it unless you subclass it. Xamarin doesn't change the laws of java.

    The CarouselPage was so fragile/broken etc. it wouldn't matter how you put it on a page. Then when they realized that a View was more re-usable everything stopped on the Page implimentation. Stalled or not the View version is far more stable than the Page version.

    The reality is that Forms is intended to make it easier to develop cross-platform apps

    Yep. Easier. That doesn't mean 'Never ever have to do some things natively`. They've made it easy to use native controls. Just like how you have sometimes make native renderers.

    But hey, maybe some smart cookie at Xamarin will see this thread and get a spark and prove me wrong. I hope so. In situations like this I like to be proven wrong.

  • AdamMeaneyAdamMeaney USMember ✭✭✭✭✭
    edited May 2017

    I remember some threads from back when @GeorgeCook was on the forums about his PageContainer, which was for hosting a XF page as a View on the page.

    It has been shown to be possible, just needs some tweaks and official support.

    EDIT: Add a link to the github repo

  • ChrisBoydChrisBoyd USMember ✭✭

    @AdamMeaney That's awesome! I was starting to look into implementing my own (or, more likely, a specialized page for my app that only adds the header), but I'll definitely check out @GeorgeCook 's.

Sign In or Register to comment.