Question: 3 different DataTemplates - how to? DataTemplateSelector is limited - what ist DrawnUi Style?

[bnSonic]

Hi :)

I'm just trying to understand this cool idea of DrawnUi.
I like to build a replacement for a CollectionView where I display Data of different types

• Header
• Detail-informations
• Placeholder with Actions for the user to insert more data at specific positions

with ListView / CollectionView I'm doing this with the DataTemplateSelector

The Items are of kind ObservableCollection<IMyData>
And IMyData has an enum like enum DataType {Group, Data, Action}

In the DataTemplateSelector I then can do something like this

protected override DataTemplate OnSelectTemplate(object item, BindableObject container)
	{
		if (item is IMyData data)
		{
			if (data.DataType == MyDataType.Data)
			{
				return _dataTemplate;
			}
			else if (data.DataType == MyDataType.Group)
			{
				return _groupTemplate;
			}
                      ...
		}
	}

now with DrawnUi I see, that item is always null.

        public virtual object CreateContentFromTemplate()
        {
            if (ItemTemplateType != null)
            {
                return Activator.CreateInstance(ItemTemplateType);
            }

            if (ItemTemplate is DataTemplateSelector selector)
            {
                //obsolete case for limited compatibility with MAUI
                var tpl = selector.SelectTemplate(null, this);
                if (tpl == null)
                {
                    throw new ApplicationException("DrawnUI has limited compatibility wih DataTemplateSelector " +
                                                   "as it is not needed here as you can modify your cell view on the fly, at the same time template selector prohibits enhanced optimizations. Your legacy selector will be called upon first cell creation only with a null context. Kindly consider adapting your code to DrawnUI style.");
                }

                return tpl.CreateContent();
            }

            return ItemTemplate.CreateContent();
        }

The documentation in the throw states that this is intended I that I could modify the cell on the fly …
Well … How?
If I like to design the template with XAML and I need different layouts for different kind of data - what would be the DrawnUI style do solve this? :)

I haven't found a DataTemplateSelector in the Demo-Code … but then I wasn't sure what to search for …

thanks a lot for anyone who can offer some time to explain that to me

[taublast]

Yep, please let me get back to you with a more complete doc/example in a few days.

What i can tell so far: you are the master of the cell here. In MAUI if you create different native views for different purposes inside the same cell and then try to change their size/content/visibility when context changes this all would:
A-not change contained views sizes/visibility for same cells instances
B-lag like hell
And the only solution would be to to use different templates = a small lag to avoid bigger lag. Here we dont need that small lag at all, this is why throw new ApplicationException("DrawnUI has limited compatibility wih DataTemplateSelector...

Basically what you'd want to:

Create a cell and include your UI's inside for different cases and set their content/visibility upon context.
Please look inside the demo app for now, again, will get back with more info in a few days.

DrawnUI recycling goes up to tracking different heights of cells so you dont have a cell already measured for 50pts to be reused (recycled) for an index that needs 100pts height and vice versa. On native we get nice lags when native cells are remeasuring for different content, forcing us to disable recycling completely. And we still see lags when those different templates are switching on Android with DataTemplateSelector.

Anyway:

You can design the UI in XAML no problem. But no maui bindings on cells, otherwise the data will be updated not when you want, but when the runtime decides to. You could even come up to a situation wher you have some updated on one frame, and some on another, re-measuring a new cell 2 and more times instead of 1. Inside a recycled cells scroll the "ui-thread-focused philosophy" of bindings is creating lags. Android accelerated canvas is rendering your code on a dedicated GPU thread, views adapter sets the new bindingcontext on this thread inside the frame window too, and you'd want to update all properties in 1 pass in code behind (when bindingcontext changes), not with app/runtime switches to UI-thread.

[bnSonic]

I didn't expect that fast of an answer 👍Wow thank you!

About the different Layouts:

• i have now created ONE Template Layout (a XAML based on SkiaLayout)
• inside of that I have added TWO SkiaLayouts: One for my Group-Headers, One for my Items
• in CodeBehind in override OnBindingContextChanged... I switch the visibility of those two SkiaLayouts
  (I still have the Text="{Binding Text1}" etc. in it)

Result:
"Are you F*ING KIDDING ME" 😂😂 What the heck how freaking fast is that?! I cannot believe what is see here!! 🤯
As a long time Xamarin (now MAUI) User this feels so "wrong" :D guess I have to learn a lot about the different philosophy of this DrawnUI 😅

So thank you - I never would have tried such an approach

Now to the "No Binding" thing:
I know that those Binding things can be a performance problem - I've read this a lot but never was able to really speed things up without bindings … (Xamarin/MAUI) - now in Maui you can set x:DataType="classname" to geht those Bindings compiled and even with that I never was able to see a real difference …

So now to DrawnUI :)

• I removed my Bindings from my Template
• and instead I set x:Name="xamlTheThing" for Labels/Controls I need to fill with Data
• then in CodeBehind in the OnBindingContextChanged I set all the values

Now I have the problem, that the height of the cells is not correct anymore
(With Bindings it works and the heights are correct)

Reading this - do have an idea why this happens - any classic fault on my side?
(I can upload a Demo-Repository later if this helps)

Basically this is the CodeBehind of the Template:

	IMyData _oldItem = null;
	protected override void OnBindingContextChanged()
	{
		base.OnBindingContextChanged();

		var item = BindingContext as IMyData;
		if (item != null && item != _oldItem)
		{
			_oldItem = item;
			SetContentFull(item);
		}
	}

	private void SetContentFull(IMyData item)
	{
		if (item.DataType == MyDataType.Group)
		{
			SetGroupContent(item as MyGroup);
			xamlGroup.Update(); //this is the SkiaLayout which holds the Grid/Label for the Group-Header
		}
		else if (item.DataType == MyDataType.Data)
		{
			SetItemContent(item as MyData);
			xamlEntry.Update(); //the SkiaLayout which holds the Grid/Labels/Controlls for the Items
		}

		Update();
	}

	private void SetGroupContent(MyGroup group)
	{
                //switching Layouts
		xamlGroup.IsVisible = true;
		xamlEntry.IsVisible = false;

		xamlGroupTitle.Text = group.Title;
	}

	private void SetItemContent(MyData item)
	{
                 //switching Layouts
		xamlGroup.IsVisible = false;
		xamlEntry.IsVisible = true;

                //filling/updating Data
		xamlItemText1.IsVisible = !string.IsNullOrEmpty(item.Text1);
		xamlItemText2.IsVisible = !string.IsNullOrEmpty(item.Text2);
		xamlItemText3.IsVisible = !string.IsNullOrEmpty(item.Text3);
		xamlItemText1.Text = item.Text1;
		xamlItemText2.Text = item.Text2;
		xamlItemText3.Text = item.Text3;

		xamlLinePrev.IsVisible = item.HasPrev;
		xamlLineNext.IsVisible = item.HasNext;
		
	}

[bnSonic]

Here is a Demo-Repository:
https://github.com/bnSonic/DrawUITest

If you click the first Button you see the Test-Page which uses a Template that is filled with CodeBehind

• here the Item heights are not working correctly

If you click the second Button you see the Page which uses Binding

• here the Item heights are working

In both cases you can click the green Headers to collapse / expand them (the Items are reloaded then to only show the visible ones)

My problems here:
a) the Item height not working correctly with the CodeBehind solution (and if I understand you right, this should be the way to go because of performance, shouldn't it?

b) the overall performance sure is better than what I expected (using only one template and switching the complete layout based on the data :D) - but now that I have added a bit more controls it really is not that snappy … sure in Debug it's getting really slow but I think that's normal for DrawnUI too as MAUI in debug mode is known to be slow. But even in Release Mode it's not as snappy I though it would be (scrolling is stuttering a bit and it takes a bit to open/close the groups … the more items are there in the "Items"-Collection, the slower it gets (is my feeling)

I've tried different things with "UseCache" (I look into the Sandbox example code) but it either changes nothing or getting WAY worse (setting UseCache to ImageDoubleBuffered or ImageComposite for the SkiaLayout that holds the Template: It took VERY long to fill/update the List - but THEN it was smooth like butter … that didn't help if the user needs to wait after each click ;))

I'm pretty sure I don't understand the philosophy completely and I'm not yet sure what to search/look for in the sandBox Demo (where I find Bindings too) - so please don't get too frustrated with me 😅 I'm just so hyped that there is Skia-based framework with this quality and so well thought out … and you mentioned EXACTLY the problems I have with the CollectionView in the Readme/documentation … so im SURE my problem can be solved but I need some help to learn this and to think in the right direction.

Thank you so much

[taublast]

Thank you very much for the repro, i could check it out tomorrow and we will make it work. I hope the repro is close to your real case at max, so if we fix repro we fix your case.

Can tell so far that my recent drawn chat with different cells of different height (and they have different layout for image, message, reply etc) is not using xaml at all, all code behind. Smooth even on Android. For my chat im loading messages my chunks of 50 with loadmore command, do you have one?

[bnSonic]

Chunks
No, currently I don't load the items in chunks 🤔 I didn't though it would be necessary because only visible rows would be rendered?
And - even if I would load in chunks: What if a user is scrolling down until the App loaded 300 items … then the user collapses or expands a group or two … it would be "slow" anyway because at least then there would be a lot of Items in the collection :) so I better test the "worst case" at first 😅

in a Xamarin.Forms app i have a ListView with binding to a Items-Collection which can hold 40.000 Items and it is fast! (yeah sure, the loading of those items from the database can take a second or two but the users are aware of that - but scrolling / refreshing (which I do a lot when filtering/searching) is really quick. So having the Items in the collection "shouldn't" be a problem?
And yes, I know what you might think like so many others I told this: "What? 40k Items? No App can do this, Smartphones not made for that, no one needs that, something is wrong with the App-Layout/concept" 😅 But no, it's not! It's not a regular case but there are clients with such an amount of data and yes they need all that data. And no, with Xamarin.Forms and the ListView this wasn't a problem 😁 (yes I tweaked the Templates and loading functions but it's really usable - the layouts are a bit lighter though - not that complex but still variable height, multiple columns, svg Image …)

Demo close to real case
The Major Layout flaw is in this example. It's the Connector-Lines (see in the Demo HasPrev and HasNext which are showing a connector line to the top or to the bottom of the row to connect the rows visually. In MAUI this is problematic:

• the Height of the row is Auto because it needs to adjust for the 3 Text Labels
• BUT the Height of the row could be defined by the Icon-Column if there is only short text which has less height than the Icon
• then the Column with the Connector Lines needs to be separated into two rows inside the column to have a line up and a line down <-- this when real problems start with MAUI Grid-Templates

That said:
The real case (currently using CollectionView and MAUI-XAML-Templates) is a bit more complex:

• the Group has one more column (two strings on the right with on two lines - here it would be a SkiaLayout "Column" in a 3rd column with two labels centered in the row)
• the Item have two more columns: one on the very left showing a short string; one on the very right showing two strings like the group

If you are interested, you can see the more complex layout that is closer to the real case in this Demo-Repository:
https://github.com/bnSonic/CollectionViewIssues
That one is showing the Layout-Problem with CollectionView and the Rows getting the wrong height when the List is scrolled and/or refreshed. It's a demo for the MAUI Team but you can see the more complete / original Layout of the cells.

Other cases not in Demo
In other cases both Layouts then have one more column at the very top which is visible when in "selection mode" - then there is a SVG showing the Selected-State which switches when you tap the row (when you tap the group, the group + all items inside that group are selected / deselected)
this Selection Mode can be enabled / disabled - resulting in this "Selection-Indicator-Column" being visible or not. In my current App this is solved with a Grid which has ColumnDefeinitions="Auto, 50, *, Auto" - This first column is this Selection Indicator Column. Inside of that is a small layout (an SVG Image) which has a IsVisible="{Binding IsSelectionMode}"

The MAUI CollectionView + Templates are struggling with that too - so when I have a longer list (say 30 to 100 items in 3 to 10 groups) then after switching SelectionMode on / off and then scrolling, some Rows still have the first column with a "width" so that all other columns are moved to the right or being smaller like there is a visible Image - but there isn't … it's just that Layout not being refreshed correctly with the caching strategy of that collection view 😔
I have no demo for this cases yet

[taublast]

Hey i digged down and found several issues that prevent the needed result. Let me fix this and get back, might take several evenings at first glance.

[bnSonic]

did you have time for it yet? :)

should i open a new discussion about your idea/workaround "using a collectionView with just one Template which is only a Canvas and draw all myself"? I think i will experiment with that this weekend because it could be a "simpler" solution as a workaround-replacement in a more complex app 🤔 but i wonder if the problem with the CollectionView (reusing Templates and not calculating / respecting the variable heights) can be solved with this approach?

[taublast]

@bnSonic Hi yes, totally i had time and would need more as it's deeper that small fixes. Talking abount "UnevenRows" case here, the approach to make a smooth scroll for dynamic cells sizes is totally different from "different but not changing cells sizes". I know that I could have went the way of a "custom control with groupping option" but it's not universal, so no, this gave me the driver to work on my 3-planes (red/green/blue) scroll. The point here is data is prepared and drawn by chunks (by 3 recycled planes) and for scroll position we draw only 1-3 times instead of *"number of visible cells" and the upcoming plane(s) is(are) prepared in background. Need more time, im juggling with paied work and this, but we'll get there.

FastRepro_sWYNqg1KLM.mp4

[taublast]

I will not stop untill i get your interesting case to be smooth on Android. 😅

[bnSonic]

haha 😄 - I'm glad I could show an "interesting case" 😄 It's so funny how my case is so obvious for me and at the same time so difficult 😆
In fact, meanwhile I'm VERY surprised that my layout had no problem at all with Xamarin.Forms … seeing Maui struggling with it (CollectionView - and ListView too if I set it to recycle caching) and now your framework too makes me think: Is really nobody daring something like this? (I saw Lists with variable height and connecting lines in other apps too, I think "Toot!" (Mastodon Client) is doing that but I don't know in which language it's written.

Really: My deepest respect for your work! I've tested it in release build on an Android emulator and even with my Binding-Template (Canvas/SkiaLayout but Binding) it's faster than Maui CollectionView or ListView.
As you said: not using binding is even faster - but only noticeable in Release Build so it would be really cool if the layout would work :)

THANKS A LOT for maintaining this project and for looking at my case! I REALLY appreciate that A LOT!
Or to quote one of my favorite movies: "YOUUU ARE OUR LAST HOPE!" (Galaxy Quest) 😄

[taublast]

Thank you for your kind words!

Such list with "connected dots" could also be done with an alternative approach:

1. Every set of connected dots is one cell (like cell per group)
2. This group is a custom control (the real key to performance).
   It would:

• Contain a set of cells for connected children
• Act as expander. What is happening now: when we hide dotted cells they get recycled = time spent measuring them is not preserved and spent again after that when showing/creating cells agains. While expander is NOT destroying/invalidating its content when collapsed, instead it just changes self size, internally preserving the content (the content would not even know that parent got collapsed "thinking" it still has same size)

Current implementation requires MAX from a recycled cells scroll so it's the best stress test we must respond to, so it's very interesting. :)

[taublast]

Here we go: bnSonic/DrawUITest#1

[bnSonic]

Cannot wait to merge and test / Analyse it 😀👌

I will report back as soon as I checked it out! I hope by tomorrow evening 👍

[bnSonic]

OK, Wow! I downloaded your PR and run it on the Emulator - even in Debug it's worlds better now! I have yet to try a release build on a real device but it's out of power right now 😆

ScrollTo "MakeVisible" equivalent?

I have a first question about the "ScrollToIndex":
I'm looking for an equivalent to ".ScrollTo(item, position: MakeVisible)"

That is:

• is the View/Cell with the item is somewhere visible on the Screen? Fine, do nothing!
• is the View/Cell with the item outside the visible area or isn't it FULLY visible? Then scroll it into view.

This "Scroll it into view" means:

• was it outside of the view beyond the bottom of the view? then scroll everything up so that the View/Cell is visible at the bottom of the scroll view
• was ist outside of the view above the top? then scroll everything down so that the view becomes visible at the top of the scroll view

Example:

the first case happens a lot if a user likes to open a group that is down at the bottom of the screen:
you see a collapsed group at the bottom

now if you hit the group header to make the children visible, I would like the app to show this:
the group expands and I like to scroll the list up so that the first child becomes "visible" inside the view so that the user can see the first item after opening a group

You know what I mean?
Is there a way to achieve that?

(scrolling the group to the very top like in your example wouldn't be a good behavior for my real app :) )

[bnSonic]

Rows are missing

Do you see this behavior on your side too?
to reproduce see video:

• open the page
• just close one group after the other … suddenly the items are not displayed anymore
• Open the last group - you see empty space
• scroll further - items appear …
  🤔 very strange behavior- but I'm sure you already have an idea 👍

small-DrawUI-missing-items-demo.mov

[taublast]

thank you for taking this video! it shows that this happens when we start collapsing groups before background measurement is complete, creating a bug for those chunks that get measured after first collapses happend.
the repro is to start collapsing when background measurement still running and if you start colapsing later all is ok..
anyway fixed this.

[taublast]

Hey
For the performance the next upcoming nuget will be better (you dont have it yet), i just compared with your app and noticed a visible difference.
For the missing rows yes i have an idea, this is due to the fact rows are not active (out of the screen), will find a workaround.
For the "ScrollToIndex" i'm a bit lost here, i mean all shoud work, unless for me its working on windows and android: when i click on headers it scrolls to upper part of the screen. Not for you? Or we are talking about different things?

devenv_bET2Ok8ymv.mp4

[bnSonic]

For the scroll to item:
What you added: yes it works.
but you implemented a „scroll to the top“ which is not what I need :)

so it’s different things.
see my two screenshots above:

1. shows a group header at the very bottom
2. Shows what I need after I tapped the group: expand the group and scroll the list up to show the first item in the group. (Not all the up to the top)

if you create a default Maui ListView you can see what I mean if you do a „ListView.scrollTo(firstItemInGroup, ScrollPosition.MakeVisible)

it should scroll the item into the visible area to make present the whole item.
But if the item already fits in the visible area of the scroll view, just do nothing.

(English is not my main language so I hope you understand what I mean :))

[taublast]

Yeah i got you now, sorry. shouldn't be hard at all, lemmi finalize this tonight.

[taublast]

devenv_9Vpeg057UV.mp4

is this okay? for both cases open/close?

[bnSonic]

in that video it looks EXACTLY like the way I need it 👍

[taublast]

haha my bad, so:
1 both scroll and stack have their own firstvisibleindex and lastvisible index. scroll tracks them only if prop something like "trackvisibleindex" is set cuz its costly. while stack can easily track it. so we use not scroll but layout below.
2 we need to check AFTER we oopen not just before because you would have last index on screen for example 11 (our closed header), then 22 (other group). so we wait bit, then last index would be relevant - 12! thats why we check after delay:

[taublast]

Pushed. You would also maybe notice ReserveTemplates="10" on stack what this does it pre-creates cells so we dont create then while scrolling when starting with minumum number of cells and do not lag while doing so.

[bnSonic]

Wait - What?
You:

• solved the problem with the missing rows when collapsing/re-expanding "too early"
• added a feature to "Scroll to End If needed"

Yesterday - Minutes/Hours after I wrote here? 🤯

And you say that you have an even faster version on your side too?

you don't stop to impress me 🤩

Quick Test:

• Scroll to End works!
• collapsing quickly after navigating to the page works too

I will have to play further with it to add more features I need for my real app (like adding a Swipe-Gesture on a Row/Cell to then - AFTER the Swipe - Animate the Row a bit the the left to present some Context-Options)

[taublast]

For some lazy scenarios a SkiaDrawer could be used like shown in drawnui demo app, but for a heavy list like this i would handle gestures inside the cell to translate the main view and make optional context controls visible. Don't forget to cache controls too, and make em invis for rendering loop to skip em when "cell is not swiped/closed".

[bnSonic]

Yes that was one of my ideas:

• a SkiaLayout with the Context-Information
• above that a SkaiLayout with the Cell-Layout (like currently in the Demo)

On the Cell-Layout listen for the Swipe -> then make the Context-Layout visible and Translate the Cell-Layout to the left … or to the right again and make Context-Layout invisible again

Will See…
Today I'm exhausted from my job 😓 - I hope to find time tomorrow to play a bit more! I cannot say often enough how happy I am that I found this project and YOU … I'm blown away! :D

[taublast]

Please update nuget to 1.6.2.6 might be "a bit" smoother

[bnSonic]

Thank you! I have changed that (not yet pushed an update of my demo project … Will play a bit to see if I can Re-Build my Maui-SwipeGrid for DrawnUi :)

Did is see that right, that you have added some really clever and helpful features in that Gesture Processing?

I mean in public override ISkiaGestureListener ProcessGestures(SkiaGesturesParameters args, GestureEventProcessingInfo apply) I see args.Event.Distance and in that there is .Total with .X, .Y - I'm sure you know what a hassle it normally is to reset x/y at "Down", summarize at "Move" … 🤪 - And now in DrawnUI this is all ready calculated?! 🤩

BTW: There is args.Event.Total.X but the TotalVelocity is in args.Event.TotalVelocity and not in args.Event.Total.Velocity Not a problem, I just saw this :)

[bnSonic]

Haha - First Step works!

drawui-ios-myswipe.mov

But: currently the context Layout is always set to IsVisible = true because if I set it to false when I initialize it, the layout is not measured so I don't know how wide it is when I like to move the Cell to the left enough to reveal the complete context layout :)

Anyway - I will play around with it a little more (where and how to get the tap for everything I need and check it out in release build on a real device :)

I also have to test a List with VERY many, I mean A LOT of Items, like 40k Items or so … I think that's were the LoadMore-Feature kicks in :) but then I might have questions … but on step after the other :D

and let me add another BIG THANK YOU for this project and your enthusiasm! This can be a real game changer for us MAUI developer!!

[taublast]

Awesome! 🎈
For many items i would personally use loadmore, or we need to tune up measurevisible to NOT measure all in background, i didnt have time to work on scenario of >1000, but as i would see it, must be a sliding measurement window, so we dont really have in memory more that 1000 measurements, that would not be wise. Anyway its doable just need to work on that, do not have much time approaching 31 august when all xamarin apps will be kicked out of gogleplay.
If i hade to show a scroll for 40_000 items i would use:

1. Loadmore obviously, first chunk is 100 items max. Example of loadmore in tutorial: https://drawnui.net/articles/news-feed-tutorial.html
2. Split the presentation of 40_000 into presentation of different itemssources introducing a filter with dates. No user would ever sit and scroll with finger from 0 to 40_000, I hope we are on same page here. At the same time a user would want to jump to a certain date: so you could introduce a filter of for example, 3 months length of items to be loaded into the list. And on top of it it would use loadmore.

[bnSonic]

haha 31. August - yeah, same problem here :) I wish you good luck with that.

The 40_000 items case is a very special one (one client) but a few thousand can happen very often.
There is no good way to present it in a different / splitter way. It's a list of data and some clients have more than others.
But yes: No human is really looking at 40k items completely :D So a "LoadMore" could be a good solution.

I just wonder why this would be a problem at all with a virtualized list presentation where a couple of "cells"/layouts are reused anyway? Is it because the List likes to know how far the scroll can go (the total length of the List for a scrollbar or something?)
I thought it might be a problem if the user likes to "Scroll To Item 30_500" and then the List would have to measure thousands of items … but if that's not the case? 🤔

Anyway - I will play around with some smaller List … one problem at a time :D
Let us all reach the August timeline fist :)
Thanks again for this really great support!

[taublast]

Thanks! It's just the 40_000 items it's not a very common case for me, so.. To handle the scroll to item nb 1_000_001 would need to implement that "sliding window". The scroll doesn't know where to scroll for that item since it wasn't measured, so it would use like an "average height" to if we needed do have a progress bar (optional) and then measure a chunk containing that item and jump there. So it could end up with many measured chunks having unmeasured chunks between them, you see the mess. But anyway when we have our own control "all is doable".

[taublast]

@bnSonic Say, regarding that filter, in case you would try today, i just fouund an issue for resetting itemssource in MeasureVisible case: fix will be in the next nuget.

[bnSonic]

A follow up question about multiply Layouts in a List:
What would be your / the suggested way?
a) Build ONE Layout (as we did here) with every Layout-Variations in it that will be set to Visible true/false in code-behind?
b) Build One "Frame"-Layout (a XAML with the Core Layout, a Frame/Shadow/…) and then add the needed Sub-Layout to it in Code-Behind?

For Example: Imagine a List showing about 7 to 30 Days
For every day we need a header (the day) and everything for that day inside a Frame/Border maybe with a shadow (a Day-Tile if you will)
inside that day, depending on the data, we show either of these:

• Holliday information
• "no data" information
• Weekend information
• Appointment information

And with Appointments: These are complex Borders again where every Appointment has it's own header with Text, Icon, … and a List of additional Information that depends on data.

I'm currently thinking to build it up like so:

• TheDay.xaml
• Weekend.xaml
• Holliday.xaml
• NoData.xaml
• Appointment.xaml
• AppointmentPerson.xaml
• AppointmentMachine.xaml
• AppointmentInfo.xaml

And then I would use "TheDay.xaml" as Layout for the List/Template

In CodeBehind of "TheDay" I would then

• depending on the Data Add Holliday/Weekend/NoData as Child to it (instead of having them all inside and switching IsVisible)
• If I have data to add "Appointment" to it:
• … "Appointment" would have a function that is called and then is scanning thru the data/context to add Personal/Machine/Info as many of them as needed

Is this a (the?) way to think with DrawnUI? To really build up the complete layout in a BindingContextChanged?

If you think this is a good approach my feelings would be better :)
From a developer point of view I kind of like it because this way I have multiply small XAML that I can overview and change better than having one giant layout with Visibility Flags :)

[taublast]

Sorry i might not quite totally understand, but if i undertood correctly (pls tell me if not):

Compare the speed of execution (just mentallly) of 2 different ways:

A. A cell is instantiated with the whole layout, then the layout is adapting to context with: IsVisible, HeightRequest of children/self etc.

B. A a cell is instantiated with a partial layout, then when context changes it creates/add children controls

If you ask me i would say that B is much slower than A, imagine a fast scrolling list?

So persinally i would go with:

1. Create partials:

• heDay.xaml
• Weekend.xaml
• Holliday.xaml
• NoData.xaml
• Appointment.xaml
• AppointmentPerson.xaml
• AppointmentMachine.xaml
• AppointmentInfo.xaml

2. Include them all in the main cell

3. Set visibility/size requests upon the changed context

Again i might missunderstod the question?

[bnSonic]

You understood me exactly :)
So: One Big Layout (and switching parts of it on/off via visibility) is better than a small layout and adding more layouts to it at runtime.
Interesting! Thanks a lot … I cannot wait to play around with that 👍

[taublast]

Okay i could re-phrase: with A you "adjust an existing instance", with B ".net runtime creates new instances", add to this logic processing for AddSubView and you easily end up with a lagging list when fast scrolling..

[taublast]

Published new nuget ending with 12. If you have time could you give your feedback on this?

https://taublast.github.io/DrawnUi/articles/news-feed-tutorial.html

[bnSonic]

This News-Feed Demo is unbelievable fast! I mean - even in Debug Mode! It's blazing fast …
.12 Version also fixes the Problem with iOS Apps working with <Grid IgnoreSafeArea="True"> again 👍

my new issue with SkiaScroll not really working inside an app with a FlyoutPage is valid for the .12 too

For the News-Feed Demo what I recognized:

• A Template is showing some Image (good)
• I scroll thru the list fast
• … then I see the already know Image again and think: "Huh? I know this already" - and then it's replaced by a new Image :)

I haven't researched the code but I'm sure you are loading the Images in an own Task and so it can happen that the Template is showing some old content until the Task has finally downloaded the new one from the internet …
I would recommend to instantly "clear" the image (fill a placeholder or something) before starting the Loading Thread? … But hey, it's a Tutorial, a Demo 😁 It's more than fine!

[taublast]

Thanks, would appreciate even more critical feeback!

1. Yeah one could set EraseChangedContent of the SkiaImage to True for that, it would clear previously loaded image content when starting loading a new source - i will add this mention to tutorial!
2. What is the issue with FlyoutPage i think i missed that? EDIT: sorry i got it in issues yeah missed im mails for some reason.