insidegui / multipeerkit Goto Github PK

This crash manifests itself when stop() is called on MultipeerTransceiver during the lifetime of the application. It usually takes multiple starts/stops for the crash to be reproduced. I can reproduce it reliably in macOS 11.4 and 12 beta 2.

Searching for this assertion produced this thread in the Apple Developer Forums, which seems to indicate that it's some problem with the internal implementation of MultipeerConnectivity, not something caused by improper use of the API.

In my testing, it seems to only occur when browsing is stopped and restarted multiple times with the same instance of MCNearbyServiceBrowser. If the browser is destroyed and reconstructed, it doesn't occur. Therefore, the workaround will be implemented in MultipeerKit so that it destroys the browser when stop() is called, and creates a new one if resume() is called after that.

Hey Gui,

• Developers should have the ability to disable the os_log in production builds to protect user data.
• Developers should have the ability to customize the subsystem to their own need

Both can be achieved by providing a logging factory mechanism that can be overridden.

These can both be achieved by creating a factory or configuration passed into the transceiver at construction time. What are your thoughts on this as a privacy enhancement?

First thing I do when logging is make an extension on OSLog or Logger types that just take a category, the subsystem is usually the main bundle identifier.

Hi, @insidegui

How do I actually use the closure to detect a new peer was added?

I try

`transceiver.peerAdded { peer in

}`

But it gives a syntax error

I use it for a App Clip, and set the keys in the info.plist, but there is still the error, but in the main app it is OK.
2021-07-05 21:36:28.179939+0800 New_Clip[77918:7943474] [MCNearbyServiceAdvertiser] Server did not publish: errorDict [{
NSNetServicesErrorCode = "-72008";
NSNetServicesErrorDomain = 10;
}].
2021-07-05 21:36:28.286791+0800 New_Clip[77918:7943450] [MultipeerConnection] The multipeer connection failed to start browsing for peers. This could be due to missing keys in your app's Info.plist, check out the documentation at http://github.com/insidegui/MultipeerKit for more information. Error: Error Domain=NSNetServicesErrorDomain Code=-72008 "(null)"

When running example code on 2 physical devices, and leaving the app for a moment to background and re-entering it, the list of nearby users contains 2 of the same users.

Hi all,

I attempted to recreate sample code in Xcode 13.4.1.
I added swift package of MultipeerKit, copied sample files, added keys to info.plist new location and I'm getting the following error:
Thread 1: Fatal error: No ObservableObject of type MultipeerDataSource found. A View.environmentObject(_:) for MultipeerDataSource may be missing as an ancestor of this view. in ContentView.swift on line: ForEach(dataSource.availablePeers) { peer in

Can anyone reproduce the same issue? Maybe we could create new sample code to support the newest version of Xcode.
Sample project from repo runs without problems, problem shows when trying to integrate MultipeerKit to new app.

Is there a way we can return a CLIResponse asynchronously, or do the message handling methods passed to transceiver.receive have to be synchronous calls which return a String?

Hi,

although I try to minimize states, in an upcoming project I could use additional, local state information inside a Peer, e.g.

• last "heartbeat" timestamp
• a "busy" state
• additional ready/in-sync state on top of isConnected

Normally I would subclass Peer but MultiPeerKit would not use it obviously. In rare cases I would use objc dynamic runtime and add an "object association" but Peer is a struct.

Currently, a "wrapper" would be needed to map an additional local struct to a peer. This creates update problems, keeping the local struct and the peer list in sync - an ugly and weak approach.

I thought about the common userInfo dict approach each Peer could offer for custom key-values. Sadly this is not very Swift-friendly although a local extension with computed properties could hide the dict.

This userInfo dict is probably the least invasive approach for the current code, or do you have another idea in mind that is better suited?