Post

Replies

Boosts

Views

Activity

Incorrect scene is activated on opening handoff user activity on macCatalyst
I have a doc app consisting of two types of scenes, "Default Configuration" and "About". When an about scene is created, I set its activation condition to NO, so it does not get activated for any userActivity or URLContext: scene?.activationConditions.canActivateForTargetContentIdentifierPredicate = NSPredicate(value: false) Now, I open an about scene and some default configuration scenes. If the about scene is on top, then when opening a handoff user activity, this about scene gets activated instead of the default ones, or a new default scene being created. If the about scene is in background or it is not created, a correct default scene is activated and passed the activity. Opening documents from finder works fine in both cases, a default scene is activated and it gets URLContext objects. Is this the expected behaviour? I found a workaround but it feels like a workaround. I enable activation on the about scene: scene?.activationConditions.canActivateForTargetContentIdentifierPredicate = NSPredicate(value: false) Then in the about scene, I listen to scene(_:userActivity:), get the activity when it gets activated, pass it to UIApplication.shared.delegate, which in turn requests a new scene activation and passes the activity object to this new scene. In this case, a scene with the correct default configuration gets activated. I'm running the tests on macOS 12.4 if it matters.
1
0
824
Oct ’22
Prevent creating "Default configuration" scene on macCatalyst at startup
I want to create an Welcome window for my app to show it at the first launch. While this window is visible, no other window/scene should be created. The user should click a "Continue" button to be able to use the app, and create new scenes. I defined two scenes, "Default Configuration" and "Welcome", and at the end of "application(_ :willFinishLaunchingWithOptions:)" I display the Welcome scene. It works ok, but a default scene is also created at startup while the Welcome window/scene is visible. I also tried using a macOS plugin. I defined the Welcome window in a xib in the plugin, and launched it from there. I did set "Visible at Launch", but that did not prevent a second scene to be created at startup, with the "Default Configuration". How can I temporarily prevent new scenes to be created?
3
0
1.1k
Aug ’22
Named pasteboard not working on MacCatalyst
Hi, I'm storing a string on a named UIPasteboard, and when reading it back, it comes as nil. It works fine on iOS, but on MacCatalyst it always returns nil. I store it like that: let p = UIPasteboard(name: UIPasteboard.Name(rawValue: "aaa"), create: true)! p.string = "some text" print("hasStrings: \(p.hasStrings)") // hasStrings: true and I read it like that: let p = UIPasteboard(name: UIPasteboard.Name(rawValue: "aaa"), create: false)! print("hasStrings: \(p.hasStrings)") // hasStrings: false I'm running the two pieces of code from two different methods of a UIViewController. Say I store the string in 'viewWillAppear', and read it back in 'viewDidAppear'.
1
0
993
Mar ’22
Disable the focus system for a MacCatalyst app
I'm building a MacCatalyst app, where the Tab key is used for a special functionality within the app. For that, I inserted a UIKeyCommand in the main menu for "\t". When I press Tab, the default functionality takes over, and the focus moves to a button in the toolbar and stays there, which I don't want. As a result, the action of my key command is not called. I set tabKeyCommand.wantsPriorityOverSystemBehavior = true, but it makes no difference. The root view controller of my app is an UISplitViewController. I overloaded 'shouldUpdateFocus(in:)' and always return false hoping that this will disable moving the focus for the whole app, but it's not working. It looks like it's more difficult then needed. How can I instruct the system to not interfere with the Tab key?
1
0
1.1k
Feb ’22
iPadOS 15, cannot replace/destroy foreground scene, and activate an existing background scene.
I have a document based app, and if the user tries to open a document in the active/foreground scene, and that document is already open in another existing scene, I would like to activate that existing scene, and destroy the current foreground one. I do it like that: UIApplication.shared.requestSceneSessionActivation(existingSession, userActivity: activity, options: nil) UIApplication.shared.requestSceneSessionDestruction(foregroundSession, options: nil) When I run this code, the foreground scene is destroyed, but the activated one is not brought to foreground, it simply takes me to home screen. On iOS14, it kinda works, the existing one is brought to foreground and splits the screen with the current foreground one for a split second, then the current one is destroyed, and the existing scene now takes all the screen. The intermediate split state is not visually nice but it does it's job. How can I achieve the same behaviour on iOS15?
Topic: UI Frameworks SubTopic: UIKit Tags:
1
0
956
Sep ’21