I understand how to use #EnvironmentObject to make global data available to any view class, but I can't find a way to pass the variable to a non-view class.
My situation, which seems like a common issue, is:
Login, returns an access token. This token is required to be used in all subsequent api calls
Store access token in a UserSettings class
Place the UserSettings in an Environment bucket
let contentView = ContentView()
.environmentObject(UserSettings())
Each view will display data based on the data returned in an api call
struct HomeView: View {
#EnvironmentObject var user: UserSettings <=== ACCESS TO GLOBAL DATA
#ObservedObject var categories = Categories() <=== GET DATA FOR THIS VIEW
var body: some View {
...
}
Categories() is a non-view Swift class that will retrieve the data, but requires the access token which is stored in UserSettings
class Categories : ObservableObject {
#Published var allCategories = CategoriesModel()
#EnvironmentObject var user: UserSettings <==== CANNOT ACCESS THIS DATA!
init() {
fetchCategories(page: 0, pageSize: 20)
}
UserSettings is empty because this class is not a View struct and doesn't seem to behave like a View class would. Since the access token I need is stored in the UserSettings class, how can I get access to this? Is there an alternative way to store/access this data?
Use a Singleton Pattern. Call UserSettings.sharedInstance from Categories & let contentView = ContentView().environmentObject(UserSettings.sharedInstance)
https://developer.apple.com/documentation/swift/cocoa_design_patterns/managing_a_shared_resource_using_a_singleton
Related
Context
I have two different realms that a user can switch between at any point they decide; in-memory or on-disk.
I store this Realm configuration on an observable object which publishes the change when required:
class RealmServiceConfig: ObservableObject {
static var config = CurrentValueSubject<Realm.Configuration?, Never>(nil)
}
I have a class that stores realm filters/sorts as #Published variables that a user can change at any point.
class Store: ObservableObject
{
static var shared = Store()
#Published var realmFilter: NSPredicate? = nil
#Published var realmSortKeyPath: String = "fieldOnMyRealmModel"
#Published var realmSortKeyPathAscending: Bool = false
}
I have two views:
ListView - This shows the live results of Objects in the current Realm.
As the filter/sort changes, the filteredObjects is recalculated thanks to the #Published values, but, it still points to the same config.
//import SwiftUI
//import Combine
//import RealmSwift
struct ListView: View
{
#ObservedObject var store = Store.shared
#ObservedResults(MyRealmModel.self, configuration: RealmServiceConfig.config.value) var unfilteredObjects
var body: some View {
let filteredObjects = unfilteredObjects
.filter(store.realmFilter ?? NSPredicate(value: true))
.sorted(by: [SortDescriptor(keyPath: "\(store.realmSortKeyPath)", ascending: store.realmSortKeyPathAscending)])
return VStack(spacing: 0) {
ScrollView {
VStack {
ForEach(filteredObjects) { object in
Text(object.name)
}
}
}
}
}
}
SettingsView - The user can change their Realm configuration between in-memory and on-disk here which updates the aforementioned RealmServiceConfig.config value
When navigating to SettingsView, the ListView is moved to the background, it is not removed from the view hierarchy.
Question
When a user changes the realm and therefore updates the RealmServiceConfig.config value, is it possible to force reload #ObservedResults with the latest configuration?
Based on the current setup, even though my configuration parameter points to the published value, this is never applied.
Workaround
I have implemented this on a model class that stores the Results<Object> in a #Published variable which allows me to react and update the query based on the config changes and pass the results through to the views.
It would just be cleaner to have this all contained in the SwiftUI view where it's needed.
Maybe this is not available yet/works against how #ObservedResults is meant to be used?
I'm testing #ObservedObject to test how SwiftUI handles the lifecycle of the model.
As I understand things now, from WWDC videos and documentation, is that the View that creates the model object (a class adopting ObservableObject) should use #StateObject.
From WWDC videos they clearly state that #ObservedObject does not own the observed instance lifecycle.
So I created this simple setup:
struct TestParentView: View {
#ObservedObject var model:TestModel
var body: some View {
VStack {
Text("TEST TEXT. \(model.name)")
TestChildView(model: model)
}
}
}
struct TestParentView_Previews: PreviewProvider {
static var previews: some View {
TestParentView(model: TestModel())
}
}
struct TestChildView: View {
#ObservedObject var model:TestModel
var body: some View {
Button(action: {
print("change name")
model.changeName()
}, label: {
Text("Change Name")
})
}
}
struct TestChildView_Previews: PreviewProvider {
static var previews: some View {
TestChildView(model: TestModel())
}
}
The model I used here is this:
class TestModel:ObservableObject {
#Published var name:String = ""
let id = UUID()
func changeName() {
name = "\(UUID())"
}
deinit {
print("TestModel DEINIT. \(id)")
}
}
When I run this app, I was expecting the TestModel instance created in TestParentView to be de-initialized at least at some point since #ObservedObject does not own the lifecycle of the model.
When I tap on the button to trigger a name change all works, but the TestModel DEINIT never gets called.
From all of this, it looks like TestParentView has a strong reference to the TestModel and it never lets it go.
So, what do they mean then when they say that #ObservedObject does not manage the lifecycle of model in this case?
Why is the TestModel DEINIT never called if #ObservedObject does not manage the model's lifecycle?
I'm obviously missing something here.
Assume this View:
struct Foo: View {
#ObservedObject var model = TestModel()
var body: some View {
Text(model.name)
}
}
Every time this view is created, it instantiates a new instance of TestModel.
SwiftUI views are really more like view descriptions which are created and destroyed a lot during your app lifecycle. Therefore it's important that the structs are lightweight. The Foo view isn't very lightweight because every rendering pass it instantiates a new model.
If you instead used #StateObject, the framework will only instantiate a TestModel the first time. After that it will reuse that same instance. This makes it way more performant.
Rule of thumb:
If the view creates its own model (such as the Foo view), use #StateObject.
If the model is passed in from the outside, use #ObservedObject.
To answer your question: "Why is the TestModel DEINIT never called".
You state that: "When I run this app, I was expecting the TestModel instance created in TestParentView to be de-initialized at least at some point".
The subtle detail is that the TestModel is not created in the TestParentView, it's merely passed in.
It is created in the TestParentView_Previews. And since the body of the TestParentView_Previews is only executed once, the TestModel will also only be initialised once, and thus never deallocated.
I am trying out this quick start for SwiftUI and Combine in order to try and understand how to connect my Realm database to Combine.
The example observes a RealmSwift.List and keeps a table populated with its data. This is is a linked list to a child class. I'm wondering how to observe a Results collection so I can keep track of any changes to an entire Realm class.
For example, let's say I have a Workspace class:
class Workspace: Object, ObjectKeyIdentifiable{
#objc dynamic var id = UUID().uuidString
#objc dynamic var name = ""
#objc dynamic var archived = false
}
In the state object, I can set up a Results<Workspace> variable like this:
class AppState: ObservableObject {
#Published var workspaces: Results<Workspace>?
var cancellables = Set<AnyCancellable>()
init(){
let realmPublisher = PassthroughSubject<Realm, Error>()
realmPublisher
.sink(receiveCompletion: { _ in }, receiveValue: { realm in
//Get the Results
self.workspaces = realm.objects(Workspace.self)
})
.store(in: &cancellables)
realmPublisher.send(try! Realm())
return
}
}
But when it comes time to observe the object, I can't because Results isn't an object (I assume).
struct ContentView: App {
#ObservedObject var state = AppState()
var view: some View {
ItemsView(workspaces: state.workspaces!)
}
var body: some Scene {
WindowGroup {
view.environmentObject(state)
}
}
}
struct ItemsView: View {
#ObservedObject var workspaces: Results<Workspace> //<!-- Error
var body: some View {
//...
}
}
Xcode gives a syntax error on the workspaces property:
Property type 'Results' does not match that of the 'wrappedValue' property of its wrapper type 'ObservedObject'
Is it possible to observe a set of Results just like we can have a notification listener on a collection of Results?
Technically, you could hook up a sink to state.workspaces (state.$workspaces.sink()), but in this case, I think you're overcomplicating the problem.
You already have an #ObservableObject in your ContentView (AppState) that is managing the results for you. So, change ItemsView to just take this as a parameter:
var workspaces: Results<Workspace>?
It doesn't need to be an #ObservedObject -- either way, whether it's getting observed in that view or it's parent view, it's going to get re-rendered. It does have to be optional here, since it's an optional value on your AppState, unless you want to keep passing it with the force unwrap (!), but that's generally a bad idea, since it'll crash if it ever is in fact nil.
Also, above, in your Realm code, make sure it's matching the tutorial that you were following. For example, you have Publisher.sink which should really be realmPublisher.sink
You are correct, Results is a struct, and therefore cannot be covered by #StateObject or #ObservedObject. Your workaround is suitable for now.
Once https://github.com/realm/realm-cocoa/pull/7045 is released, you will be able to use one of the new Realm property wrappers to embed your Results into the view directly. At the time of this posting, that would be #FetchRealmResults, but that is subject to change.
In a SwiftUI app, I have an ObservableObject that keeps track of user settings:
class UserSettings: ObservableObject {
#Published var setting: String?
}
I have a view model to control the state for my view:
class TestViewModel: ObservableObject {
#Published var state: String = ""
}
And I have my view. When the user setting changes, I want to get the view model to update the state of the view:
struct HomeView: View {
#EnvironmentObject var userSettings: UserSettings
#ObservedObject var viewModel = TestViewModel()
var body: some View {
Text(viewModel.state)
.onReceive(userSettings.$setting) { setting in
self.viewModel.state = setting
}
}
}
When the UserSettings.setting is changed in another view it causes onReceive on my view to get called in an infinite loop, and I don't understand why. I saw this question, and that loop makes sense to me because the state of the ObservableObject being observed is being changed on observation.
However, in my case I'm not changing the observed object (environment object) state. I'm observing the environment object and changing the view model state which redraws the view.
Is the view redrawing what's causing the issue here? Does onReceive get called everytime the view is redrawn?
Is there a better way of accomplishing what I'm trying to do?
EDIT: this is a greatly simplified version of my problem. In my app, the view model takes care of executing a network request based on the user's settings and updating the view's state such as displaying an error message or loading indicator.
Whenever you have an onReceive with an #ObservedObject that sets another (or the same) published value of the #ObservedObject you risk creating an infinite loop if those published attributes are being displayed somehow.
Make your onReceive verify that the received value is actually updating a value, and not merely setting the same value, otherwise it will be setting/redrawing infinitely. In this case, e.g.,:
.onReceive(userSettings.$setting) { setting in
if setting != self.viewModel.state {
self.viewModel.state = setting
}
}
From described scenario I don't see the reason to duplicate setting in view model. You can show the value directly from userSettings, as in
struct HomeView: View {
#EnvironmentObject var userSettings: UserSettings
#ObservedObject var viewModel = TestViewModel()
var body: some View {
Text(userSettings.setting)
}
}
You might be able to prevent infinite re-rendering of the view body by switching your #ObservedObject to #StateObject.
In my initial ContentView() I have a button that presents a UIImagePicker, when an image is chosen I then navigate to SecondView where I can view the image and it’s data from UIImagePickerController.InfoKey
I currently have an ImageManager class that’s set as an EnviromentObject that I pass the InfoKey to that then sets up all the variables in that class — it works but this feels messy.
What I’d like to do is init the ImageManager class when I navigate to SecondView as that’s the only view that needs that data.
I’d tried passing the InfoKey as a variable:
#State var InfoKey: [IImagePickerController.InfoKey: Any]
SecondView(key: self.infoKey)
but this crashes because I don’t have any data until an image is chosen
What would be the best way to tackle this?
#State must have initial value, so use just empty container
#State var infoKey: [IImagePickerController.InfoKey: Any] = [:]
then pass it in SecondView as binding
SecondView(key: self.$infoKey)
where
struct SecondView: View {
#Binding var key: [IImagePickerController.InfoKey: Any]