Using client using delegate pattern through @Dependency property wrapper.

[Malauch]

I hit some strange problem when trying to use ComposableCoreLocation via @Dependency property wrapper and find even weirder solution, which I would like to discuss here. I have no idea if it's some TCA bug, Apple bug or it's working as expected ;)

Naturally I have added DependencyKey conformance for LocationManager and extended DependencyValues.

extension LocationManager: DependencyKey {
  public static var liveValue = LocationManager.live
  public static var testValue = LocationManager.failing
}

extension DependencyValues {
  public var locationManager: LocationManager {
    get { self[LocationManager.self] }
    set { self[LocationManager.self] = newValue }
  }
}

However, when I tried to use this client in a reducer via @Dependency(\.locationManager) var locationManager it wasn't fully working. LocationManagerDelegate was set a delegate of CLLocationManager but any delegate's methods wasn't called.

Original code for setting up delegate in ComposableCoreLocation is like this:

extension LocationManager {
  public static var live: Self {
    let manager = CLLocationManager()

    let delegate = Effect<Action, Never>.run { subscriber in
      let delegate = LocationManagerDelegate(subscriber)
      manager.delegate = delegate

      return AnyCancellable {
        _ = delegate
      }
    }
    .share()
    .eraseToEffect()

    return Self(
  [...]

I suspected that the problem is something with @TaskLocal nad propagating delegate instance/action through system of Swift Concurrency. When browsing Isowords code base I noticed that some delegates are setup on MainActor inside new Task. I tried something like this:

extension LocationManager {
  public static var live: Self {
    let manager = CLLocationManager()

    let delegate = Effect<Action, Never>.run { subscriber in
      let delegate = LocationManagerDelegate(subscriber)
		
      // Delegate set on MainActor
      Task {
        await MainActor.run {
          manager.delegate = delegate
        }
      }
			
      return AnyCancellable {
          _ = delegate
      }
    }
    .share()
    .eraseToEffect()
    
    return Self(
  [...]

However it didn't change anything. Delegate endpoint still wasn't called by CLLocationManager. 😅

I was experimenting more and finally found working solution! I tried setup CLLocationManager in DependencyValues and then when creating live LocationManager instance I used manager accessed via @Dependency property wrapper.

extension CLLocationManager: DependencyKey {
  public static var liveValue = CLLocationManager()
}

extension DependencyValues {
  var coreLocationManager: CLLocationManager {
    get { self[CLLocationManager.self] }
    set { self[CLLocationManager.self] = newValue}
  }
}

extension LocationManager {
  public static var live: Self {
    // 1. CLLocationManager has to be get from DependencyValues.. but why???
    @Dependency(\.coreLocationManager) var manager

    let delegate = Effect<Action, Never>.run { subscriber in
      let delegate = LocationManagerDelegate(subscriber)
		
      // 2. Delegate has to be set on MainActor. Don't know why, but otherwise doesn't work.
      Task {
        await MainActor.run {
          manager.delegate = delegate
        }
      }
			
      return AnyCancellable {
          _ = delegate
      }
    }
    .share()
    .eraseToEffect()
    
    return Self(
  [...]

This one finally works! Both additional steps are mandatory to make it works. However I have no idea why and feels hacky ;) I would really appreciate if someone can confirm if it's right way to do and why it has to be like this?

I used examples above from Combine version of ComposableCoreLocation, however Swift Concurrency version from this PR has exactly the same problem. Naturally, I tried creating minimalistic CoreLocation from the beginning and it shared the same problem. Is all about setting up delegate for CLLocationManager.

Here is my fork of ComposableCoreLocation which has two branches: main which uses combine and swift-concurrency one. Both branches have workaround applied.

EDITED:

Is even weirder than I previously thought. When I tried to prepare fresh example project, I noticed that hack described above sometime works but sometime not. For now I have no idea what is a culprit. However I have noticed that reading value of LocationManager inside of reduce function solved problem, even for client version without hacks.

struct LocationReducerUsingDependency: ReducerProtocol {
  @Dependency(\.coreLocationClient) var coreLocationClient

  func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    _ = coreLocationClient  // <- this line makes delegate of `CLLocationManager` properly responding.
    
    switch action {
    [...]

I checked on simulator and real device and it behaves the same on both.

[Alex293]

You might need to keep a reference to your delegate as it’s only kept as weak to avoid circular reference. As soon as you function returns nobody has a strong reference to you delegate object so it get dealocated.
well I’m not sure it’s the solution to your issue but not storing a delegate declared inline seems fishy.

[Malauch]

Delegate is captured in returned AnyCancellable. I believe is captured successfully and not deallocated from manager, because:

• it works when client is passed directly to ReducerProtocol via initializer,
• CLLocationManger doesn't throw fatal error, which happens when delegate is not configured or not listening to particular endpoint.
• it works through @dependcy after applying two mentioned hacks.

[Alex293]

Indeed, I missed that.

[Malauch]

I prepared some example project to show the issue. It's simplified as much as possible. To see CoreLocationClient behavior change, please uncomment/comment line 18 in LocationReducer.swift.
CoreLocationDelegateInDependencies.zip

To make it works, it uses simpler hack/workaround with _ = coreLocationClient in reduce method.

[saroar]

I try this all is good with iPhone 12 iOS 16.2 without uncomment line 18

[Malauch]

I just checked. On either real device and simulator is still not working (it is on 16.2 the same as before on 16.1). So probably some race conditions?

[saroar]

strange all work good in my real device

[acosmicflamingo]

I "think" this is what's happening but anyone can correct me if I'm wrong. Your typical variable/property is instantiated when the class/struct it resides in is instantiated. However, I think @dependency values actually behave more like lazy variables.

You can see this by adding this to your LocationReducer,

  public init() {
    print("HI")
  }

your CoreLocationClient initalizer...

struct CoreLocationClient {
  var authorizationStatus: @Sendable () -> CLAuthorizationStatus
  var delegate: @Sendable () -> AsyncStream<LocationManagerDelegate.Action>
  var requestLocation: @Sendable () -> ()
  var requestWhenInUseAuthorization: @Sendable () -> ()

  init(authorizationStatus: @escaping () -> CLAuthorizationStatus, delegate: @escaping () -> AsyncStream<LocationManagerDelegate.Action>, requestLocation: @escaping () -> Void, requestWhenInUseAuthorization: @escaping () -> Void) {
    self.authorizationStatus = authorizationStatus
    self.delegate = delegate
    self.requestLocation = requestLocation
    self.requestWhenInUseAuthorization = requestWhenInUseAuthorization
    print("HELLO")
  }
}

and then running the app. Notice that "HI" immediately appeared but "HELLO" doesn't appear until you actually send an action to the reducer. That means coreLocationClient is first instantiated in an asynchronous thread, and bad stuff happens I guess ¯\(ツ)/¯? The following pretty much does the same thing but is the convention for passing values from synchronousville to async-city.

func reduce(into state: inout State, action: Action) -> Effect<Action, Never> {
  switch action {
    case let .coreLocation(.didUpdateLocations(locations)):
      let coordinate = locations.first!.coordinate
      state.coordinate = .init(latitude: coordinate.latitude, longitude: coordinate.longitude)
      return .none
    case .coreLocation(.didChangeAuthorization):
      requestLocation()
      return .none
    case .coreLocation:
      return .none
    case .delegateButtonTapped:
      // Without [coreLocationClient], coreLocationClient.delegate() returns nothing
      // and the for-loop never iterates
      return .run { [coreLocationClient] send in
        for await action in coreLocationClient.delegate() {
          await send(.coreLocation(action))
        }
      }
    case .getLocationButtonTapped:
      requestLocation()
      return .none
    }
  }
}

I hope someone smarter than me can chime in to say what is actually happening :)

[saroar]

so what is your last solution I check your GitHub where you folk this [composable-core-location](https://github.com/Malauch/composable-core-location) also there you try other way yes ? with MainActor?

[Malauch]

@saroar My previous reply about locks was wrong. I just get lost during my exploration of different approach. However, In a meantime I also checked that TCA version before merging #1510 0.43.0 behaves exactly the same as 0.47.2.

In summery, currently I have found two workarounds for a problem.

1. CoreLocationClient side one which is implemented in my fork of composable-core-location. Which is storing CLLocationManager in @Dependency and mutating its properties on MainActor.

2. Reducer side which is one about referencing client in reduce function before using it

func reduce(into state: inout State, action: Action) -> Effect<Action> {
  _ = coreLocationClient 
[...]

or more elegant mentioned by @acosmicflamingo to capture client value in run closure

func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
  switch
    case .delegateButtonTapped:
      return .run { [coreLocationClient] send in
        for await action in coreLocationClient.delegate() {
        [...]

[saroar]

you check this it work ? pointfreeco/composable-core-location#31

[Malauch]

This post is only about registering LocationManager in DependenciesValues which I done exactly as described. What derailed me is that it has some side effect which changed behavior of CLLocationManager which is wrapped by LocationManager.

[saroar]

o I see but your code work find for me using ur demo project now inside my app (its open source but will ready within 5 days or more)
if you to see how it work we can have screen share call

[ahbou]

It seems CLLocationManager needs to be initialized from the main thread for the delegate to receive events.

From Apple docs:

Core Location calls the methods of your delegate object using the RunLoop of the thread on which you initialized the CLLocationManager object. That thread must itself have an active RunLoop, like the one found in your app’s main thread.