Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dispatching delegates in designated queues #273

Merged
merged 3 commits into from
Mar 1, 2019

Conversation

philips77
Copy link
Member

This PR should solve issue #249.
CC @DevAndArtist

There are still 3 calls for main dispatch queue. Do you have an idea how to solve it? I guess I should use the queue used for central manager to be consistent.

@philips77 philips77 added this to the 4.3.0 milestone Feb 26, 2019
@philips77 philips77 self-assigned this Feb 26, 2019
@philips77
Copy link
Member Author

Ok, I guess that's it. Could you check if it works for you? Or at least if the API will work for you?

@DevAndArtist
Copy link
Contributor

@philips77 thank you for the effort, I will add it tomorrow to our project and check how it behaves. Btw. I scanned over the patches and haven't seen any use of dispatchPrecondition, how did you verified the queue on which the code is being run?

@philips77
Copy link
Member Author

philips77 commented Feb 26, 2019

The main reason for not using it is that I don't know how to use this method :)
I assume that all CBCentralManager and CBPeripheral delegate calls are done on a queue given in CBCentralManager connector. All other calls in the lib are called from one of the delegate methods, except from starting dfu, where the current queue is used, it delayed called, where I use the same queue explicitly. Isn't that enough?

@philips77
Copy link
Member Author

Hello, any updates on this? I watched a video and I'm now pro in dispatchPrecondition, but still don't think it's necessary due to what I said earlier.

@DevAndArtist
Copy link
Contributor

@philips77 not yet. I'm currently fixing other parts of our library which prevent me from being able to compile the project. I'll try to test your patch by the end of the day, I hope, and report back.

If you're interested to read more about dispatchPrecondition here is a Swift thread where I asked for some more clarifications: https://forums.swift.org/t/what-is-the-default-target-queue-for-a-serial-queue/18094

@philips77
Copy link
Member Author

Other thing, dispatchPrecondition is available on iOS 10+ while DFU is now supported on 9.0+ (after migrating Zip -> ZipFramework in #251).

@philips77
Copy link
Member Author

I'm thinking about merging the PR tomorrow and releasing 4.3.0 if you have no objections.

@DevAndArtist
Copy link
Contributor

DevAndArtist commented Mar 1, 2019

I finally updated to project to test the changes but I'm hitting an issue:

dyld: Library not loaded: @rpath/ZIPFoundation.framework/ZIPFoundation
  Referenced from: /private/var/containers/Bundle/Application/D5798A54-60A6-4F27-9BC1-F3E9AD9164B5/App.app/Frameworks/iOSDFULibrary.framework/iOSDFULibrary
  Reason: image not found

Should I include the new dependency manually or are the projects dependencies messed up? (I'm using carthage to include the DFU lib.)

You are missing a cartfile with the new dependency to ZIPFoundation, otherwise Carthage has now idea that this project depends on it.

@DevAndArtist
Copy link
Contributor

Resolved the dependency here and the framework gets added into the app bundle, but I'm hitting the next issue and unable to run the app.

dyld: Library not loaded: @rpath/ZIPFoundation.framework/ZIPFoundation
  Referenced from: /private/var/containers/Bundle/Application/6768A1C7-5C6E-471B-9969-F84AEFE42EA3/App.app/Frameworks/iOSDFULibrary.framework/iOSDFULibrary
  Reason: Incompatible library version: iOSDFULibrary requires version 1.0.0 or later, but ZIPFoundation provides version 0.0.0

I'm currently out of ideas why this issue happens. I cleared Derived Data and clean build the project.

@DevAndArtist
Copy link
Contributor

I resolved the issue above, it's an issue ZIPFoundation has, I'm not sure if my PR will be approved. I found the solution in a different project after searching the web for it: jpsim/Yams#131

I fixed the issue here:
weichsel/ZIPFoundation#91


In your case you still need to add a cartfile so Carthage can pull ZIPFoundation.

@philips77
Copy link
Member Author

I've created cartfile with

github "weichsel/ZIPFoundation" ~> 0.9

in the main directory. Is there anything else needed for me to push?

@philips77
Copy link
Member Author

Btw, we didn't have cartfile before switching to ZipFoundation, or at least I don't see it. Was it working for you before, or you had to include that dependency in your cartfile?

@DevAndArtist
Copy link
Contributor

That's a good question. To be honest I'm not sure how Carthage previously pulled Zip.framework. It just didn't worked for me this time.


I'm fixing some internal dispatchPrecondition cases related to the changes made here. Give me an hour or so, I'll report if I could flash without issues.

@DevAndArtist
Copy link
Contributor

Okay I could flash multiple times without any issues. Feel free to merge.

@philips77
Copy link
Member Author

I've added Cartfile. Is that the right place for it?

@DevAndArtist
Copy link
Contributor

DevAndArtist commented Mar 1, 2019

Looks good on my end, Carthage can now pull ZIPFoundation correctly, the only requirement for the project to run correctly is them to merge my PR.

@philips77 philips77 merged commit 47d2c19 into develop Mar 1, 2019
@philips77 philips77 deleted the feature/callback-queue branch April 3, 2019 14:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants