SwiftUI ベースに MVVM のパターンを考えたとき。
Apple と Orange の子 View があるとして、こういう感じで認識していましたけども MVVM。
1つの View に対して、1つの ViewModel でライフサイクルは同期している。
その View の子の View に対しては親の ViewModel を渡したり、差し込んでいく。
著名な公開されているコードを見てると、こういう形が多いように見えるし、そのほうが書きやすいように思える。
世の中そんな流れですかね。
どうなんですかね。
ModelContext てそんな子に向けてのツールですよね。
どこかなんかいい参考記事ないですかね。
まあ、ざっくりの話なんですけども。
これ持ってる人、工具を購入するときには、マキタがいいかもしれません。
マキタのバッテリーは最強です。
兼用で使っていきましょう。
初心者向け低価格帯はこれぐらいでしょうか。
対応商品は、100以上ありますので、さらに上位のものを探すこともできます。
バッテリー自体は、非 Makita の同規格の製品もある模様。
しかし、バッテリーこそやっぱり「マキタ」ですね。
【セキュリィティ】スマートフォン を ドリル で破壊する https://t.co/BkHWz013Vb #iphone #android #google #apple
— chanzmao (@maochanz) July 28, 2024
UI スレッドをブロックしてるんですよね。
10万レコードのような大きいデータを fetch() すると。
バックグラウンドで大量インサートなどしながら、
UI側でリストなどをスクロールするともっと顕著に分かります。
どうやら、
「インスタンス生成をどこで行うか」
が大事なようです。
singleton の ModelActor 側。
@ModelActor
actor DataSource {
nonisolated(unsafe) private(set) static var shared: DataSource!
// static func createInstance(modelContainer: ModelContainer) {
// print("createInstance()", Thread.current) // main
// shared = DataSource(modelContainer: modelContainer)
// }
static func createInstance(modelContainer: ModelContainer) async {
print("createInstance()", Thread.current) // not main
shared = DataSource(modelContainer: modelContainer)
}
View 側。インスタンス生成はバックグラウンドで。
// .onAppear { // main
// DataSource.createInstance(modelContainer: modelContext.container)
// }
.task { // not main
await DataSource.createInstance(modelContainer: modelContext.container)
}
どうなんすかね。
SwiftData も苦しんでる感じに見えます。
