I wrote up a series of blog posts about our experiences while building Wallaroo in . The first article is up today with more coming over the course of the week. Let my pain be your gain!

· · Web · 2 · 0 · 4

Part 2 of my series about building Wallaroo in is up! This time I talk about how I implemented parallax and blurs:

I just published part 3 of my Wallaroo and series! Today I talk about a couple of performance issues that came up and why I wrote my own AsyncImage.

@bigzaphod is .onAppear also not lazy inside of ScrollView? that'd be simpler than multiple GeometryReaders (parallax aside), but I'd also assume that's what AsyncImage is using already

@shadowfacts it seemed to me that onAppear (and task) seem to fire when the view first comes into existence in the view hierarchy no matter if it is off screen or not or wrapped in a scroll view or not. (Seems wrong, IMO, but I'm sure they had some good reason for this... hopefully...)

@bigzaphod my guess is they're all fired off at once when the hosting controller gets its will/did appear called

but it's definitely odd behavior given the name (though i guess it makes more sense for .task)

@shadowfacts yeah I suspect that's when they fire - but even in UIKit those will/did appear things aren't tied to actual visibility on screen - it's just when they're added to a view. So I suppose it makes sense. There's just something about how it's presented in SwiftUI, though, that makes it feel like it should work the other way by default. Dunno.

@Gargron I shouted out Mastodon in the post since I would never have known about it otherwise!

@bigzaphod Way, way back in the iOS 5 days I had to return a placeholder image on first call even if there was a cached image. Just pulling the (properly scaled) image from the cache slowed things down.

I'm glad things have got this much faster.

@tewha oh yeah I remember those days. It was part of why I went down the road of making a complex caching system before I realized I didn't even need it. I assumed I still did - but nope! In this case, being able to use async to decode/fetch the images is a huge win because it can happen on another thread (likely another whole core) while layout is still happening, too!

@bigzaphod sometimes the hardest part of being a professional coder is knowing what code shouldn't be written. And one of the most pride-injuring tasks can be figuring out which code should be deleted.

but it feels so good after!

@bigzaphod I'm sure you've read this Bill Atkinson tale (though I'll link just in case) but I try to filter through it.

@tewha I love deleting older code. I hate deleting code that's like... a day old, though.

@bigzaphod yeah. I try to stay positive. “Look how many things I learned overnight!” But it doesn’t work.

Sign in to participate in the conversation

The original server operated by the Mastodon gGmbH non-profit