SwiftUI ScrollView contentOffset / infinite scroll into leading side

Hey folks,

I need to implement a view for a live activity (so using. WidgetKit), so any UIKit/SceneKit is a non-starter.

The thing to implement is a horizontal representation of a 360 degree protractor ('degree triangle').

I would like this view to be inifintely scrollable as if the user has a circular shape around their head and they can rotate their head to look at all the numbers, and when they reach 360/0, they simply continue with new round. In both directions.

I've managed to get this working for the positive values by using a LazyHStack and which is populated using ForEach, using a custom class that implements RandomAccessCollection where the endIndex is Int.max (not truly infinite, but good enough). However, I can't get the scrollview/ForEach to start in the 'center' of the Int.max range (I'm sure this would cause some performance issue as well).

So my question is: how to get a SwiftUI scrollview to behave like a infinite scrollview, pretty much like Josh Shaffer explained in WWDC 2011 in the session with Eliza Block called 'Advanced ScrollView Techniques'?

  • If Scrollview is not the right fit, I can probably manage using regular views. I am not looking for user interaction anyway, but to set the offsrt programmatically based on sensor input.

  • Each object in your forEach can conform to Indentifiable. Let each object's id equals a degree on the tape. Assign each objects.id to the view that draws the stroke on the tape. Then using a scroll view proxy, you can use the proxy to scroll to a given id in the collection based on the sensor input.

Add a Comment

Replies

I'm surprised there is no actual answer to this question. SwiftUI seems to take us quite some steps back when trying to do real-world things. I would be happy to use UIKit for this (less than a morning to get it done), but since this needs to live in a live activity, that is a no-go.

Is it really that difficult to 'declare' in SwiftUI that subviews do not need to be re-rendered during animation, animate(:::) does not neet to be called 60 times for each subview for the same time, and layout should be differently during animation as opposed to between animations?

Where is the documentation that goes in-debt in how things work together? Or are documentation writers as lost in generics&protocols-land as developers are?

<rant mode> I'm starting to feel like Jules Winfield, with the following phrase going throug my head: "Say 'declarative' again. SAY 'DECLARATIVE' again! And I dare you, I double dare you <redacted>! Say 'declarative' one more time." </rant mode>