Writing these packages has also been a fun exercise in how to design APIs now that we have concurrency.
For example, subscribing to IMAP idles (pushed events), I borrowed the 'updates' pattern used in the new StoreKit 2 API. It's an AsyncStream that just runs forever, and gets iterated over when new events occur.
Big Mail 2, nay, ALL my apps, wouldn't be possible if it weren't for the generous contributions of others in the OS community.
I can't wait to give back, so that's why I plan to open source all of Big Mail's core packages: SwiftIMAP, SwiftSMTP, and SwiftEmail.
They're all super Swifty, modern, and hopefully instantly familiar to anyone who's used Foundation. #Swift
There's also a sister package, GRDBQuery, which gives you a @Query property wrapper for SwiftUI (similar to @FetchRequest in Core Data)
You're then able to write views that automatically update when anything in the database changes.
Here's all the code needed for the account picker in Big Mail. So clean.
Related: I binned off Core Data for Big Mail 2, and instead have been using the phenomenal GRDB by @groue
Not only is my app now faster and less buggy, but it’s so much easier to reason with. No weird managed contexts and elaborate dances to pass stuff between threads. Just simple, safe, Swift structs.
(Also, the documentation is INSANE) https://github.com/groue/GRDB.swift
Swipey swipe 🫵
Edit: this is swiping left on the message viewer, not tapping the List. Don't worry it's not a transition 😬
Here it is on iPhone: https://mastodon.notsobig.co/@phill/109942899530912122
And here's the rub with SwiftUI: I'm sure there are certain things I'm still doing “the wrong way”, despite doing this everyday, and reading all the docs and examples I can.
But because there have been so many genuine issues (as seen by others), my default position is “Well, the API must be broken then”. That's not a helpful mindset when debugging.
Building a low level IMAP/SMTP library has been a breeze compared to understanding how to use these APIs correctly 😅
Anyways I'm back to use NavigationLinks(value:) again, which this time seems to be behaving.
I think the reason it wasn't working last time is because I had installed a navigationDestination on my Sidebar (which is shared between compact and regular size class). It looks like it was confusing NavigationSplitView.
Now I have the navigationDestination installed just in the compact size class, and things seem okay…
Okay, another update on my Navigation Saga, because sharing is caring.
After integrating, I noticed selected rows wouldn't unselect when popping back.
Turns out using .tags() will only work if:
1) The root List is bound directly to an ObservedObject. A Binding to the same value in an ObservableObject won't work.
2) The List must only contain Text or Label views (so no pinned Grid at the top).
I'm also not sure why the Binding gets fired so many times VS the ObservedObject either? #SwiftUI
If there's any poor souls stumbling across this in the future, here's a gist to my solution: https://gist.github.com/phillipcaudell/085580a9412284f381a4730930c7d52f
Now to refactor this back into Big Mail 🥲 #SwiftUI
…so instead, I'm switching to a Stack when compact. Only issue is getting NavigationLink, SplitView and Stack to play together.
In the end I found it was easier to remove NavigationLinks all together, and instead use tags. Lists then use this as their selection value.
Then, using those selections, I'm computing a path to drive the Stack. Once I caught EditMode, it all worked.
No jittery toolbars. Smooth transitions. Consistent and predictable across iPhone/iPad/Mac.
Thank god.
Hallelujah! 🙌
Finally got a workaround for the NavigationSplitView regression in iOS 16.4.
Transitions stop working when the content column no longer contains a List (say you have a “Select Mailbox" view, a Grid, etc).
Here's a gist of the issue: https://gist.github.com/phillipcaudell/6d4d0efac6a22cd42bf75f3acd7a033b
It seems to suddenly start behaving like a NavigationStack, which is why adding a navigationDestination sorta works (except now you've got wonky nav animations, and it still sometimes fails)…
Well hot damn, someone on Twitter suggested setting the Set's underlying type to Optional, and voila, editing and navigation!
I'm still not entirely sure why this works though. Surely an empty Set would denote no selection? Making the type itself Optional isn't intuitive at all.
Even the init signature doesn't give any hints, only that the Binding itself can be Optional... 🤷♂️ #SwiftUI
🏳️🌈 Founder / Maker
Building that new email app.
Swift and rollercoasters are my thing.
Recovering VC.