Post

Replies

Boosts

Views

Activity

Reply to Crash: [NSTaggedPointerString count]: unrecognized selector sent to instance 0x8000000000000000
Yes, properties() is called on the main thread. Also data is being accessed from the main thread, and from a background thread that corresponds to the first async work. func properties() { let group = DispatchGroup() group.enter() UNUserNotificationCenter.current().getNotificationSettings { (notification) in let value = … some calculation … self.data.updateValue(value, forKey: "my_wonderful_key") group.leave() } group.enter() MyClass.someMethod { (granted) in let value2 = … some calculation … self.data.updateValue(value2, forKey: "my_wonderful_key_2") group.leave() } group.notify(queue: DispatchQueue.main) { print("Yay. Operation completed!") completionHandler(self.data) } } As you can see, in the first block, data is being accessed in the getNotificationSettings completionHandler which is executed on a background thread. On the other hand, in the other two (2) blocks data is being accessed on the main thread, since those two blocks MyClass.someMethod and group.notify run in the main queue. One more thing is that I have crash reports for all these 3 lines: self.data.updateValue(value, forKey: "my_wonderful_key") self.data.updateValue(value2, forKey: "my_wonderful_key_2") completionHandler(self.data) So I wonder if the fact that data is accessed from a background thread in the first block is causing that the app is crashing then when the same data is accessed from the main thread in the block 2 and 3? if that would be the cause, just wrapping the code with an async block in the main queue would work? That way the data is only accessed from the main thread group.enter() UNUserNotificationCenter.current().getNotificationSettings { (notification) in let value = … some calculation … DispatchQueue.main.async { self.data.updateValue(value, forKey: "my_wonderful_key") group.leave() } Thanks!
Jun ’21
Reply to How to detect if an iPad has GPS
Thanks eskimo. While the Core Telephony Framework provides APIs to access the carrier data, cellular data state, and so on, this does not seem to provide an API to return if the device is cellular capable or not. While it might be true today, it’s easy to imagine Apple adding GPS to a device that doesn’t have cellular. Right, a new device like this would break this implementation. But until then, we would have a hacky way to detect this, which does not seem bad. I also think it's a good moment to think if this is really needed.
Topic: App & System Services SubTopic: Hardware Tags:
May ’21