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

Removing queues from UI #79

Merged
merged 9 commits into from
Oct 21, 2023

Conversation

Garfeild
Copy link
Contributor

This PR is intended to improve codebase by removing explicit queue usage when DeviceService functions are called from UI. Existing async functions are changed to accept callback closure and queue, where this closure should be executed.

@okwasniewski
Copy link
Owner

Why did you remove the Swift Concurrency commit? There were few minor issues but it was pretty good.

@Garfeild
Copy link
Contributor Author

Garfeild commented Oct 17, 2023

After you mentioned about switching to the main queue in Menu, I have realized that Swift Concurrency changes are not done right and require more thought through approach. Let me come up with proposal in Discussions later today.

But I would like to merge this PR as I see it as good improvement to the codebase. And I have branch with further improvements together with feature of pinning device to the top in the menu.

@okwasniewski
Copy link
Owner

Sounds good! I would leave this calls on the main queue to ensure we are not breaking stuff and we can merge it

Copy link
Owner

@okwasniewski okwasniewski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few more questions

MiniSim/Menu.swift Outdated Show resolved Hide resolved
MiniSim/Menu.swift Outdated Show resolved Hide resolved
if self.items.contains(item) {
item.keyEquivalent = keyEquivalent
}
if self.items.contains(item) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we are still missing the DispatchQueue.main

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added it back here.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to check if item exists inside of the DispatchQueue.main.async call as it might not exists when we get to executing the inner closure on the main thread. Can you please for now bring back the old approach? And later on we can refactor it with Async/Await.

MiniSim/Service/DeviceService.swift Outdated Show resolved Hide resolved
if self.items.contains(item) {
item.keyEquivalent = keyEquivalent
}
if self.items.contains(item) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to check if item exists inside of the DispatchQueue.main.async call as it might not exists when we get to executing the inner closure on the main thread. Can you please for now bring back the old approach? And later on we can refactor it with Async/Await.

self.safeInsertItem(menuItem, at: isAndroid && UserDefaults.standard.enableiOSSimulators ? (isFirst ? index : iosDevicesCount) + 3 : 1)
}

let iosDevicesCount = self.devices.filter({ $0.platform == .ios }).count
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also here we are missing the jump back to the main thread. You could add the DispatchQueue.main.async to the safeInsertItem method.

@okwasniewski
Copy link
Owner

@Garfeild Just two more small adjustments 😅

@@ -34,19 +34,16 @@ class Menu: NSMenu {
}

func getDevices() {
DispatchQueue.global(qos: .userInitiated).async {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code was the root cause of everything being not in the main queue. And that's the most important change in the PR. New DeviceService.getAllDevices executes callback closure on the main queue by default. This allows us to remove any DispatchQueue.main calls in the Menu.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, great thanks for the explanation!

@Garfeild
Copy link
Contributor Author

Hi @okwasniewski! Thanks for feedback. But I believe we are doing something wrong here.🙂I've left comment on the place, where we have main change, which makes all DispatchQueue.main calls redundant in the Menu file.

To be 100% sure, I've added print statements on the places you wanted me to add queue back. And here what it looks like if I run the app:

[MiniSim/Menu.swift:128] Thread.isMainThread: true
[MiniSim/Menu.swift:106] Thread.isMainThread: true
[MiniSim/Menu.swift:106] Thread.isMainThread: true

I also installed Monterey in VM and I want to check binary with my changes. I will post here once I've tested it there.

@okwasniewski
Copy link
Owner

Ah okay, if that's the case then we can remove those calls. I don't want to introduce regressions but if they were redundant from the beginning we can remove them

@okwasniewski
Copy link
Owner

Let me know how your testing went and I will approve the PR 👌🏻

@Garfeild
Copy link
Contributor Author

Update: It's working without issues on macOS 12.6.1
Screenshot 2023-10-21 at 22 20 51

Copy link
Owner

@okwasniewski okwasniewski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! 👌🏻

@okwasniewski okwasniewski merged commit cdc6827 into okwasniewski:main Oct 21, 2023
@Garfeild Garfeild deleted the feat/remove-queues-from-ui branch October 21, 2023 21:43
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