=> More informations about this toot | View the thread
=> More informations about this toot | View the thread
=> More informations about this toot | View the thread
If you voted for Donald Trump, please unfollow me so I know to unfollow you.
And Americans, I don’t want to hear the words “Leader of the Free World” ever again. It’s bullshit and at this point you absolutely don’t deserve to keep rolling it out. #uspol
=> More informations about this toot | View the thread
=> More informations about this toot | View the thread
=> More informations about this toot | View the thread
Builds are processing so much faster after upload to AppStoreConnect than they used to, mere seconds.
Either they have substantially sped up something at their end, or my progressive upgrade and removal of old code and resources from my app has removed something that was previously slowing things down.
Either way, I love the result, and @intro v2.0.3 with significant performance improvements for background sync operations is now in review. #iOSdev #IndieApp
=> More informations about this toot | View the thread
=> More informations about this toot | View the thread
Ah damn, looks like it's a SwiftUI bug: https://forums.developer.apple.com/forums/thread/758922
=> More informations about this toot | View the thread
Trying to use the new #SwiftUI .onScrollPhaseChange on a List… No matter which level in my view hierarchy I’ve tried attaching it I get an initial call to the closure with an .idle state but no phase changes are reported when scrolling…
Anyone encountered this? #iOSDev
=> More informations about this toot | View the thread
=> More informations about this toot | View the thread
I have a #SwiftUi view with an .onReceive handler that triggers an update to a fetchRequest when relevant additional data has been added in the background.
If the user is scrolling when the change is integrated there’s a tiny hitch. What I’d like to do is detect if the user is scrolling and defer the update until scrolling stops.
Is there a good mechanism to implement this in SwiftUI? I already have a debounce system so I guess I need to add an ‘is the user scrolling now’? #iOSDev
=> More informations about this toot | View the thread
=> More informations about this toot | View the thread
=> More informations about this toot | View the thread
=> More informations about this toot | View the thread
I simply ended up in this situation because I hadn't originally had the refetchTrigger in place, and so failed to learn that the earlier step of pinning the query generation and refreshingAllObjects() was both completely unnecessary and additionally was indeed the cause of my performance problems.
There’s nothing like the satisfaction, joy even, of solving a significant performance issue. 🎉
=> More informations about this toot | View the thread
It transpires this was completely superfluous, it appears, and highly problematic performance-wise.
I already had viewContext.automaticallyMergesChangesFromParent = true in my setup, so the context was being updated automatically.
All I had to do was prod my list with a stick, setting a new UUID on my refetchTrigger I passed to the view. That correctly causes the list to refetch when relevant objects have been imported. And since it turns out they were already in the viewContext, sorted!
=> More informations about this toot | View the thread
Ah awesome, it looks like I have solved this. Turned out, essentially, that I was just doing far more work that I needed to. I realise now how this happened. Because originally I hadn’t found the mechanism to ensure my SwiftUI list was updated when there were additional objects in the viewContext, I’d thought from research I had to do a heavy:
`try? viewContext.setQueryGenerationFrom(.current)
viewContext.refreshAllObjects()`
…once I’d finished background processing. 1/3
=> More informations about this toot | View the thread
I just feel the need to say, since I’m working my GST return, that Microsoft is a US$3.17 trillion company, but if you could download a series of six monthly invoices from @intro they would be called: Intro-2024-04.pdf through Intro-2024-09.pdf
…not:
E0305RWD0S.pdf E0320S9FK2.pdf E0310SPV8P.pdf E0310T1EF3.pdf E0309VEOVX.pdf E0302TTEJ6.pdf
Love the way they keep all that money razor focussed on the user experience.
=> More informations about this toot | View the thread
So... I’ve traced my performance issue down to the way I’m updating my main SwiftUI lists in response to incoming NSPersistentStoreRemoteChange #CoreData notifications from iCloud. I was processing them on a background context, then sending notifications observed by lists. If they displayed types that were updated they’d refresh.
Clearly I was not doing this well because the view-side-subscription-and-refresh part could cause multi-second UI pauses. Obv not great.
Advice welcome. #iOSDev
=> More informations about this toot | View the thread
=> This profile without reblog | Go to babbage@iosdev.space account This content has been proxied by September (3851b).Proxy Information
text/gemini