Combining NSBonjourServices with NSLocation

We are working on a project that communicates location data via a network.

We are able to get the Location Services to work using:

<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>Location data will be used to monitor your position</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Location data will be used to monitor your position</string>

And we able to get the networking functionality to work using:

<key>NSBonjourServices</key>
<array>
	<string>_appName-data._tcp</string>
	<string>_appName-data._udp</string>
	<string>_appName-chat._tcp</string>
	<string>_appName-chat._tcp</string>
</array>

and

<key>NSLocalNetworkUsageDescription</key>
<string>appName needs to use your phone&apos;s data to discover devices nearby</string>

However, we are only able to use these independently. When both are included together, the NSBonjourServices quits working, but the location services works.

Any one know what needs to be done to have both working together?

Up vote post of BlastTeam5 Down vote post of BlastTeam5
562 views
Posted by
BlastTeam5
Reply
Add a Comment

Replies

When both are included together, the NSBonjourServices quits working

Always? Or only under specific circumstances, like when you move the app to the background?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo

  • It happens when the app is open and running. If I remove the NSLocationAlwaysAndWhenInUseUsageDescription and NSLocationWhenInUseUsageDescription, then chat will work as it is programmed to. But if I include the NSLocation options, the Multipeer Connection stops working or at least behaves as such. All indicators say that the connections have been made, however when moving beyond the connection screen, the app either locks out or boots the user out of the chat interface and the connection severs.

    —
    BlastTeam5
Add a Comment

Thanks for the reply.

Always? Or only under specific circumstances, like when you move the app to the background?

Always.

If I remove the NSLocationAlwaysAndWhenInUseUsageDescription and NSLocationWhenInUseUsageDescription, then chat will work as it is programmed to. But if I include the NSLocation options, the Multipeer Connection stops working or at least behaves as such. All indicators say that the connections have been made, however when moving beyond the connection screen, the app either locks out or boots the user out of the chat interface and the connection severs.

Posted by
BlastTeam5
Up vote reply of BlastTeam5 Down vote reply of BlastTeam5
Add a Comment

Weird. I’m not aware of any interactions between Multipeer Connectivity and the location subsystem.

First, the snippet you posted has a bug:

<key>NSBonjourServices</key>
<array>
    <string>_appName-data._tcp</string>
    <string>_appName-data._udp</string>
    <string>_appName-chat._tcp</string>
    <string>_appName-chat._tcp</string>
</array>

That last item should be _appName-chat._udp, right?

If that doesn’t help, my advice is that you open a DTS tech support incident so that I, or one of my colleagues, can look at your issue in depth.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo

  • That was a typo, we do have ._udp for our last item. After further investigation, it looks like the issue is that CLLocationManager is hogging the main thread. When I try to use MultipeerConnectivity, the app can't establish a connection between two phones because the main thread is busy updating the location. I've tried wrapping some code blocks in DispatchQueue.main.async but haven't had any luck. Is there a way I can thread this?

    —
    BlastTeam5
Add a Comment

After further investigation, it looks like the issue is that CLLocationManager is hogging the main thread.

For how long? I’m not a Core Location expert, but it seems like it’d be very weird for it to block the main thread for long periods of time. Are you sure it’s not your delegate code blocking the main thread?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

It seems to hog the main thread most of the time. The UI never freezes up though. It seems like I'm getting location updates way too often. How would the delegate be blocking the main thread? I'm a Swift newbie. Here is the output from the app showing how often it's getting location updates:

locationManager(:didChangeAuthorization:) authorizedWhenInUse locationManager(:didUpdateLocations:) <+39.15864560,-76.89928186> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:13 PM Eastern Daylight Time locationManager(:didUpdateLocations:) <+39.15864560,-76.89928186> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:15 PM Eastern Daylight Time locationManager(:didChangeAuthorization:) authorizedWhenInUse locationManager(:didUpdateLocations:) <+39.15864560,-76.89928186> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:15 PM Eastern Daylight Time locationManager(:didUpdateLocations:) <+39.15865652,-76.89927153> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:15 PM Eastern Daylight Time locationManager(:didUpdateLocations:) <+39.15865652,-76.89927153> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:15 PM Eastern Daylight Time locationManager(:didUpdateLocations:) <+39.15865991,-76.89926832> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:15 PM Eastern Daylight Time locationManager(:didUpdateLocations:) <+39.15865991,-76.89926832> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:15 PM Eastern Daylight Time locationManager(:didUpdateLocations:) <+39.15863612,-76.89924954> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:15 PM Eastern Daylight Time locationManager(:didUpdateLocations:) <+39.15863612,-76.89924954> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:15 PM Eastern Daylight Time locationManager(:didUpdateLocations:) <+39.15861112,-76.89923817> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:21 PM Eastern Daylight Time locationManager(:didUpdateLocations:) <+39.15861112,-76.89923817> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:21 PM Eastern Daylight Time locationManager(:didUpdateLocations:) <+39.15864310,-76.89931310> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:27 PM Eastern Daylight Time locationManager(_:didUpdateLocations:) <+39.15864310,-76.89931310> +/- 65.00m (speed -1.00 mps / course -1.00) @ 8/30/21, 2:04:27 PM Eastern Daylight Time

Posted by
BlastTeam5
Up vote reply of BlastTeam5 Down vote reply of BlastTeam5
Add a Comment

Again, I’m not a Core Location expert, but I’ve seen folks run into problems like this because they leak CLLocationManager objects. If all the objects have the same delegate then one location event translates into dozens of delegate callbacks as each of the leaked managers calls its delegate to notify it of that event.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment