SwiftUI often feels like an embodiment of Alan Kay’s: “Simple things should be simple, complex things should be possible”
It took quite a bit of head-scratching to get this to work, but I was eventually able to get three different ScrollViews (each with a differently scaled chart in them) to synchronously scroll in real-time w/ backwards compatibility to iOS 17 Phew… 😮💨
Though on mornings like this I do wish more stuff was in the “Simple Things" bucket rather than the “Complex Things” bucket.
=> More informations about this toot | More toots from _Davidsmith@mastodon.social
(Probably worth mentioning that this isn't actually the UI I'm building...but a necessary intermediate building block) That UI would be mind bending (🤯) in the actual app.
=> More informations about this toot | More toots from _Davidsmith@mastodon.social
@_Davidsmith Okay that is extremely neat
=> More informations about this toot | More toots from njvack@ruby.social
@_Davidsmith very cool! Is this Swift Charts or your own thing? (I know nothing about Swift Charts so don’t even know if that’s a stupid question!)
=> More informations about this toot | More toots from joethephish@mastodon.gamedev.place
@joethephish Completely custom stuff. Swift Charts is great for basic stuff but as soon as you need anything at all custom I find it very frustrating.
=> More informations about this toot | More toots from _Davidsmith@mastodon.social
@_Davidsmith hah, sounds very familiar! Totally makes sense, and your implementation looks great
=> More informations about this toot | More toots from joethephish@mastodon.gamedev.place
@_Davidsmith I was wondering! But it would be very fun to have!
=> More informations about this toot | More toots from dxzdb@mastodon.social
@_Davidsmith ship it.
=> More informations about this toot | More toots from braden@mstdn.party
@_Davidsmith very cool David
=> More informations about this toot | More toots from simonharper@mastodon.social
@_Davidsmith That's great—can you still scroll any of the three views directly and have the others come with? I've done this once in UIKit but I wonder what the sources of truth would look like for SwiftUI
=> More informations about this toot | More toots from easeout@mastodon.social
@easeout In this implementation there is a switchable ‘driving chart' which controls the others, but it would be pretty straightforward to generalize this into "whichever chart was last touched should become the driver”. The tricky part is just making sure we avoid creating any loops where scrolling a chart causes it to try and re-scroll itself.
=> More informations about this toot | More toots from _Davidsmith@mastodon.social
@_Davidsmith Would love a technical write-up on the strategy here, just out of curiosity. 🤯
=> More informations about this toot | More toots from caseyliss@mastodon.social
@caseyliss @_Davidsmith same, would be very interesting to see how you’ve solved this.
Really neat UI nonetheless!
=> More informations about this toot | More toots from jeanetienne@mastodon.social
@caseyliss @_Davidsmith me too.
I know how I would try to do it, but would like to know if the way it’s done is the same.
=> More informations about this toot | More toots from fmarini@mastodon.social
@caseyliss @_Davidsmith me three!
=> More informations about this toot | More toots from michaelrowe01@mstdn.social
@caseyliss @_Davidsmith Ditto. My first pass would be to put the “selected date” into the model and have each view reflect that by scrolling appropriately. But I could see that leading to some unreconcilable discrepancies between the views.
=> More informations about this toot | More toots from Gte@mastodon.social
@Gte @caseyliss The tricky part was getting them to scroll precisely. In the old days of UIKit (or in SwiftUI on iOS 18) you could just say ‘scroll to this X offset’, but in iOS 17 that isn't available...the trick ended up being using a regular old ScrollViewReader but generating a custom UnitPoint as the .scrollTo(:anchor) value. Which (once you've don't the weird math to find the right value) surprisingly, actually works 🤪. The data layer side was just the regular, weird Preferences stuff.
=> More informations about this toot | More toots from _Davidsmith@mastodon.social
@_Davidsmith @caseyliss Wow! That’s the sort of unreconcilable discrepancy I’d imagined but that’s a super clever workaround. Very nice work as usual. Good luck with the rest of it!
=> More informations about this toot | More toots from Gte@mastodon.social
@_Davidsmith this is a lovely UI
=> More informations about this toot | More toots from Migueldeicaza@mastodon.social
@_Davidsmith That is some clever UI that I never considered for viewing historical data. Now, having seen it, it just seems obvious! Hidden complexity from the user.
I have a sign hanging in my office that reads “Simple does not equal easy.” that I put up to remind those requesting my designs equipment be “simple”, that what they’re really asking for is “easy for the end user”, and that might require a lot of complexity up front. “Simple for whom?” is usually my first question.
=> More informations about this toot | More toots from chrishuck@fosstodon.org
@_Davidsmith wow.. that’s very cool… are you doing it all with a single struct for the data and three subviews all looking at the same struct?
=> More informations about this toot | More toots from michaelrowe01@mstdn.social
@_Davidsmith Very slick!
=> More informations about this toot | More toots from GeekAndDad@mastodon.social This content has been proxied by September (ba2dc).Proxy Information
text/gemini