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

Feature/mac support #46

Open
wants to merge 21 commits into
base: master
Choose a base branch
from
Open

Feature/mac support #46

wants to merge 21 commits into from

Conversation

ZvonimirMedak
Copy link
Collaborator

Summary

Added macOS support with a new SwiftUI example

Changes

  • Podspec updated (removed CustomLocation from default podspec, added macOS support)
  • Added a new SwiftUI example (we will most likely need to add the SPM every time the project is downloaded since currently it has my local path)
  • Added macOS target to the UIKit example
  • Added macOS support to the DeviceTool
  • exposed SentinelTabBarView to be public
  • refactored Preferences to use PreferenceSection so that the users can't add other items than Toggle ones (We will introduce other ones later on or maybe we can set it to toggle/custom)

Type

  • Feature: This pull request introduces a new feature.
  • Bug fix: This pull request fixes a bug.
  • Refactor: This pull request refactors existing code.
  • Documentation: This pull request updates documentation.
  • Other: This pull request makes other changes.

Additional information

  • This pull request introduces a breaking change.

Description

I've mentioned everything in the changes section

Checklist

  • I have performed a self-review of my own code.
  • I have tested my changes, including edge cases.
  • I have added necessary tests for the changes introduced (if applicable).
  • I have updated the documentation to reflect my changes (if applicable).

Additional notes

After this gets reviewed, I would like to try to push team members to try out the new version where possible so we can test it out. Also, I would like to improve the current state of the navigation on macOS

@ZvonimirMedak ZvonimirMedak added documentation Improvements or additions to documentation enhancement New feature or request labels Jan 20, 2025
@ZvonimirMedak ZvonimirMedak added this to the 2.0.0 milestone Jan 20, 2025
@ZvonimirMedak ZvonimirMedak self-assigned this Jan 20, 2025
Copy link
Member

@nikolamajcen nikolamajcen left a comment

Choose a reason for hiding this comment

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

This is such a great work 👍 I'm glad that I can finally run Sentinel on macOS.

Based on your changes, I've added some comments so please check them out.

Copy link
Member

Choose a reason for hiding this comment

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

I would recommend to use buildable folders and re-arrange file structure a bit. I'm okay with you to continue using e.g. Example for iOS and Example for macOS folder naming like it was already used (but they were groups).

Copy link
Member

Choose a reason for hiding this comment

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

Additionally, try to use the same naming definition for targets; e.g. use Example-iOS and Example-macOS.

Comment on lines +33 to +35
func applicationWillTerminate(_ aNotification: Notification) {
// Insert code here to tear down your application
}
Copy link
Member

Choose a reason for hiding this comment

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

Remove methods that are not used.

func applicationSupportsSecureRestorableState(_ app: NSApplication) -> Bool {
return true
}

Copy link
Member

Choose a reason for hiding this comment

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

Remove redundant new line.

Comment on lines +15 to +25
override func viewDidLoad() {
super.viewDidLoad()

// Do any additional setup after loading the view.
}

override var representedObject: Any? {
didSet {
// Update the view, if already loaded.
}
}
Copy link
Member

Choose a reason for hiding this comment

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

Remove methods and properties which overrides are empty.

@@ -10,3 +11,9 @@ target 'Sentinel_Example' do
inherit! :search_paths
end
end

target 'MacOSExample' do
Copy link
Member

Choose a reason for hiding this comment

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

Update target names for both iOS and macOS - as mentioned in the previous comment.

Comment on lines +53 to +65
.init(title: "Model", value: getModelIdentifier() ?? ""),
.init(title: "Name", value: ProcessInfo.processInfo.hostName),
.init(title: "System version", value: systemVersion),
.init(title: "UUID", value: hardwareDeviceUUID ?? "???")
])
#else
CustomInfoTool.Section(title: "Device", items: [
.init(title: "Model", value: UIDevice.current.model),
.init(title: "Name", value: UIDevice.current.name),
.init(title: "System version", value: systemVersion),
.init(title: "UUID", value: UIDevice.current.identifierForVendor?.uuidString ?? "???"),
.init(title: "Battery state", value: batteryState),
.init(title: "Proximity state", value: UIDevice.current.proximityState ? "Close" : "Far")
Copy link
Member

Choose a reason for hiding this comment

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

Replace .init methods with real class names.

Also, additionally, if the objects of the array are the same, you could instead return the array from a method instead creating the whole object inside the if-else branches. Even better approach here would be a factory method or abstract factory (due to other methods), but I believe this can be added and improved in other PRs.


/// The trigger type which is triggered on the specified notification name.
public static func notification(forName name: Notification.Name) -> Trigger {
NotificationTrigger(notificationName: name)
}
#if !os(macOS)
Copy link
Member

Choose a reason for hiding this comment

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

Would it be better to use #if os(iOS)? Because with this, e.g. tvOS or watchOS in the future would support this. I know we will not add the possibility for that, but it is easier to work with constrained things than the opposite.

Copy link
Member

Choose a reason for hiding this comment

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

Also, add a note to the comment (or discussion), on which platforms are those methods available.

@@ -19,7 +19,9 @@ struct TextEditingToolView: View {

Button(action: {
viewModel.didPressSave(viewModel.value)
presentationMode.wrappedValue.dismiss()
#if !os(macOS)
Copy link
Member

Choose a reason for hiding this comment

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

Can we use os(iOS) here as well?

})
}))
.frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .topLeading)

Button(action: {
viewModel.didPressDelete()
presentationMode.wrappedValue.dismiss()
#if !os(macOS)
Copy link
Member

Choose a reason for hiding this comment

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

Same here as well.

Copy link
Member

Choose a reason for hiding this comment

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

Regarding the SwiftUI example, I think this is a bit redundant in the current form. We have a new project that we need to maintain, while the implementation is different only for view part (app delegate counterpart is same).

I would rather propose to add the SwiftUI code in the existing example in one of the provided forms:

  • Create two screens (for iOS and macOS targets) - one with UIKit and another with SwiftUI examples (with summoning Sentinel)
  • Create a new target that will work on both iOS and macOS

@nikolamajcen
Copy link
Member

Also, one additional note; I've seen you've done a lot of work, but you've mixed that into bigger PRs, e.g. podspec update, macOS support, preferences update. On the other PR there are multiple topics as well.

Try to separate them in future PR for easier review process and separation of concerns. The work you did is great, but this can make things easier to understand and will produce quicker review times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants