I am confused by the MVVM structure, particularly when in consideration with having references within @Observable
courses. Think about the next instance:
Suppose I am implementing an app that wants location authorizations. I need to show a sheet view asking for the authorization if the consumer hasn’t given it. For this, I would like some sort of location delegate that responds to authorization standing modifications. Sources ([1] [2]) usually counsel implementing one thing like this:
ultimate class LocationManager: NSObject {
static let shared = LocationManager()
personal let locationManager = CLLocationManager()
var isAuthorized = false
override init() {
tremendous.init()
locationManager.delegate = self
}
}
extension LocationManager: CLLocationManagerDelegate {
func locationManagerDidChangeAuthorization(_ lm: CLLocationManager) {
// Reply to auth modifications
change locationManager.authorizationStatus {
case .authorizedAlways, .authorizedWhenInUse:
isAuthorized = true
default:
isAuthorized = false
}
}
}
And take into account the only state of affairs the place I’m to implement a view that reveals a sheet when isAuthorized
is fake. My “view” and “view-model” may look one thing like:
struct ContentView: View {
@State var viewModel = ViewModel()
var physique: some View {
SomeOtherView()
.sheet(isPresented: $viewModel.isNotAuthorized) {
Textual content("Please authorize location companies")
.interactiveDismissDisabled()
}
}
@Observable class ViewModel {
var isNotAuthorized = !LocationManager.shared.isAuthorized
}
}
Appropriate me if I am improper, however I do not assume modifications to isNotAuthorized
are correctly noticed. So I see a couple of doable options:
-
I mark
LocationManager
itself as@Observable
, through which case the hope can be thatisNotAuthorized
withinViewModel
can be making an attempt to reference a printed variable within one other@Observable
class. I am undecided if this might work, nor whether or not if it will be a good suggestion from a code follow perspective. -
I exploit
LocationManager
instantly within my view, through which case I might be forgoing the “view-model” within the structure. Maybe that is wonderful since MVVM is only a assemble, however because of thisLocationManager
would now must handle the states of various views. i.e. I would wish to have one other variable namedisNotAuthorized
withinLocationManager
. When there’s a number of views and consider states, it turns into a large number. -
I forgo any sort of state administration within
LocationManager
and push all state managements to each view’s “view-model”, I can maybe obtain this with some form of name again, however this appears impractical. Specifically, this implies for any mannequin I implement, it can not maintain any state and should present methods for view-models to course of state modifications.
Therefore my confusion. It looks like I can both implement MVVM with nested commentary or pressure myself to do unnecessarily complicated state managements. Is there one thing easy I am lacking?