Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add qff feed preferences page #20

wants to merge 6 commits into
base: master


Copy link

commented Apr 22, 2019

I picked another screen from the Qantas app to recreate.


Source vs XF iOS vs XF droid

What went well?

I was able to easily create a grid based layout - which I understand would have been painful/custom renderer territory pre CollectionView days. The layout is pretty basic and it was appropriately easy to create with the CollectionView control. I consider it a success and so will focus on the 'things to improve' below.

What didn't go well?

These points may be CollectionView related or just me doing a Bad. To date in my apps I have use XF embedding and most list-based screens are done natively, so I'm not super familiar with the Right Way to do it in XF.

  • The Material/Visual marker did not seem to be inherited by the template, so I had to specify it there explicitly - not sure if bug or feature

  • I wasn't sure how to alter the 'selected item' style from code, it looked like it needed XAML and VSM work which didn't seem code friendly, so I 'covered' the default view with a content view to prevent the selection colour from being displayed. It worked but resulted in a more nested layout than would otherwise be needed

  • I hacked in an appearance animation but it wasn't good (see missing/desired things)

  • Not a CollectionView thing, but I couldn't get android to build once bumping the target sdk to 9 - to get my screenshot I copied the screen into my VisualChallenge project and ran it from there.

How is the performance?

I don't know about performance as compared to ListView, but performance in Release builds was good for both iOS and Android. However, when scrolling very quickly in Android it was possible to reliably cause an ObjectDisposedException because of the appearance animation.

Missing or Desired Things:

  • I missed the VerticalScrollbarVisibility property

  • I'd like to be able to offset all the content in the CollectionView by some amount so that the first items appear lower than they do by default, but still allow scrolling to be flush with the top of the collection view. Notice in my iOS screenshot that I am actually slightly scrolled down to make the content match the source.

  • I'd like to have proper appearance hooks for items to allow for us to animate in content with more sophistication than what is currently possible. In my code you can see I hack an animation onto the end of the template definition, which feels pretty bad and it's probably just a coincidence that it works. Ideally we'd have an appearance callback that gives us enough information to do things like staggered appearance, don't reanimate things that have already animated, animate items differently based on their position in a grid layout etc.

    For example, UITableViewDelegate has a WillDisplay(UITableView tableView, UITableViewCell cell, NSIndexPath indexPath) method, which allows you to do things like use the row index to delay an item's appearance by a small amount, and keep track of which items have been animated so that you don't reanimate them (e.g. when scrolling back up). Other things that might be useful for a CollectionView is an indication of where the item is in the grid span - like in my screenshots here, if you know the item is in 'column 0' of the grid, you can animate it in from the left, or if it's in 'column 1' of the the grid, you can animate it in from the right.

  • I found the selection api a little awkward for my use case, I wonder if it makes sense to have an ItemTapped kind of event

  • This might not be CollectionView related, but I wasn't sure how to add pizzaz to my selection change. Ideally, I'd have faded the checkbox in and out on selection, but with a binding I didn't see a good way to intercept that.


This comment has been minimized.

Copy link

commented Apr 24, 2019

I had a play around with trying to hack entrance animations onto the items - they are in a commit on my entrance-animations branch, toggled by clicking the 'save' button.

Given the super hacky method it's easy for this to stop working properly after too much back and forth scrolling, but the results are ok and it shows the kind of effects we could achieve with a proper ItemAppearing callback - video:

(Some of these are a bit gratuitous but I do use staggered fade and staggered fade up a bit in the native world 😎)

CollectionView.SelectionChanged += (sender, e) =>
// this is not so great

This comment has been minimized.

Copy link

davidortinau Apr 26, 2019


@rdavisau can you expand on this? What would you prefer/expect to have in order to manage selection?

This comment has been minimized.

Copy link

rdavisau Apr 27, 2019


It was more a comment on the way my own code handling it - but the other ways it could work that I thought would be more natural from my perspective:

  • ItemTapped with args of item, then I can toggle its selected/unselected property
  • SelectionChanged with args of itemsAdded and itemsRemoved so that I have the delta already

Either of those allow avoiding the full list iterations which is what I didn't like about my current code. I haven't checked how it's implemented in the renderers, so not sure whether we already do/don't have to do a full iteration internally to raise the event.

Keep in mind I haven't thought about it as much as the team most likely has - I know I can get the outcome I want from the current api, and it's just as likely that that way it works now enables uses cases I wasn't thinking about.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.