Xamarin.Forms element wrapper state

[Eilon]

List of Xamarin.Forms elements that are available in Experimental Forms binding for Blazor.

Note: Some elements have been wrapped, but not all of their properties have been implemented.

• BindableObject
  • Element
    • Application
    • Cell
      • EntryCell
      • SwitchCell
      • TextCell
        • ImageCell
      • ViewCell
    • GestureElement
      • Span
    • FormattedString
    • BaseMenuItem
      • MenuItem
    • NavigableElement
      • BaseShellItem
        • ShellContent
        • ShellGroupItem
          • ShellItem
            • FlyoutItem
            • TabBar
          • ShellSection
            • Tab
      • VisualElement
        • View
          • ActivityIndicator
          • BoxView
          • Button
          • CheckBox
          • DatePicker
          • Image (Add Image component #10)
          • ImageButton
          • InputView
            • Editor
            • Entry
            • SearchBar
          • ItemsView
            • CarouselView
            • StructuredItemsView
              • SelectableItemsView
                • GroupableItemsView
                  • CollectionView
          • ItemsView<T>
            • ListView
          • Layout
            • Layout<T> (Not Applicable?)
              • AbsoluteLayout - On hold because it requires Attached Properties
              • FlexLayout - On hold because it requires Attached Properties
              • Grid (Add Grid component #12)
              • StackLayout
              • RelativeLayout
            • TemplatedView
              • ContentView
                • Frame
            • ScrollView
          • Label
          • Picker
          • ProgressBar
          • Slider
          • Stepper (Add Stepper component #13)
          • Switch
          • TableView
          • TimePicker
          • WebView
        • Page
          • TemplatedPage
            • ContentPage
          • MasterDetailPage
          • NavigationPage
          • MultiPage<T> (Not Applicable?)
            • CarouselPage
            • TabbedPage
          • Shell (Add Shell component #11)

[smartprogrammer93]

Hello @Eilon ,
thank you for your work on this amazing project. Do you think there would be a way that automates wrapping elements as there are thousands of components in the xamarin environment other than the basic ones mentioned in this issue.

[Eilon]

This has come up before so I logged a suggestion here to track it: #25 . Let's continue the discussion there on thoughts for how to automate it (it's not easy to get 100%).

[0x414c49]

@Eilon I learned how to create new wrappers and adding XF properties to elements. Since you are keeping the project updated. Can't we create issues an assigned to ourselves to do it?

I know at the moment, you are looking for feedbacks maybe not contributions, but people like me can help to make the procedure faster.

[Eilon]

@0x414c49 we're looking for any kind of valuable contributions! For the wrappers, I'm working on a tool to help automate this: #25

The tool won't be perfect, because several Xamarin.Forms UI controls have some special requirements, but the tool will help get a lot further a lot faster.

[Pheros]

Is it possible to create a list of selectable items. No?

[Eilon]

@Pheros are you asking if there is a component that enables building a UI for multiple selection?

[Pheros]

Yes. I want to create a list of selectable items, define a couple of sliders, where the user could choose a number between 1 and 5 and then store those numbers to a database.

[Eilon]

Hi @Pheros I'm not aware of any built-in component that does this. A common way to do something similar is to have a list and have a <Switch> component for each row, and then you can select all the items that have the switch toggled.

If you have further questions about this, please log a new issue so that we can keep each issue focused on a single topic. Thanx!

[freever]

Hi @Eilon

I see CollectionView is on your list... how high is it on your list of priorities?

Performant lists are essential for most mobile applications and CollectionView is the recommended approach these days in XF.

I see you have used a StackLayout in a ScrollView in some of the samples - I guess this maps most easily to the HTML list concept and the data loading pattern in Blazor. But I wonder will this scale to large lists of items or even infinite scrolling lists?

I have also been wondering how the usual XF pattern of having an ObservableCollection of items databound as the ItemsSource of a layout would translate to the web paradigm that Blazor comes from?

For example, in the Xaminals sample, lists are populated like so:

 <ScrollView>
        <StackLayout>
            @foreach (var animal in MobileBlazorBindingsXaminals.Data.MonkeyData.Monkeys)
            {
                <AnimalTemplate Animal="animal" />
            }
        </StackLayout>
    </ScrollView>

and Monkeys is an IList. Now if Monkeys were an ObservableCollection, and I added a Monkey, what would happen? Would all the list items be recreated, or none of them, or only the new one?

I totally love the Blazor approach and I really hope it can become a first class way of building XF apps.

[Eilon]

Hi @freever thank you for the question. CollectionView is high on my list in terms of interest, but also high on my list in terms of complexity, so unfortunately this means it's not clear when it will happen. It is complex because it uses Xamarin.Form's templates, which I've had a difficult time trying to map to the Blazor world. I've made a few attempts but kept getting stuck.

As to the other parts of your question:

Blazor binding can be very efficient. If you have a list with 10 items in it and then add an 11th item, only the new controls needed for the new 11th item will be created. All the first 10 controls will be untouched. Currently in Mobile Blazor Bindings there are some more advanced internals that are not yet implemented that make it more efficient when you insert into the middle of a list. It'll work fine as things are, but not at maximum efficiency. As to ObservableCollection, there is generally no need for that in the Blazor world because Blazor works based on diffing, not reactive observations.

And for infinite scrolling, there are some neat approaches people have used with Blazor for the Web ("regular Blazor") that I'm hoping I can map to the world of Mobile Blazor Bindings. Haven't looked too deeply into it yet though.

[freever]

That is really interesting. I did some hasty reading up on Blazor collections and apparently if you apply the @key attribute to each <tr> that contains a component and map it to the backing model then Blazor will compare the existing <tr> with the new <tr> generated on state changes and only apply changes if there is a diff. That resolves a question I had about how Blazor knows whether to change, remove or add an item in a collection without re-rendering the whole thing each time.

It's an interesting challenge, applying Blazor to mobile, because the paradigms are so different. If you take away the INotifyPropertyChanged MVVM paradigm (which Blazor does) then Xamarin Forms becomes a completely different animal - probably a much easier one to code and reason about, and possibly more performant too.

Anyway, thanks for your response and well done on the work so far, I really like it!

[Eilon]

Yup, in Blazor @key is the trick to high-performing collection updates, but I don't think it works in Mobile Blazor Bindings yet. (Maybe it does work, but I haven't tried, and I think I left out the part that would make it work.)

Indeed, the INotifyXyz and MVVM patterns are a negative for some people - particularly those who like Blazor's patterns. That's why we have this project!

[aktxyz]

+1 for carousel and collectionview

[MvandeRuitenbeek]

I think this project is awesome!! Did a lot with normal blazor, now this was exactly what I was looking for to do mobile development