I'm implementing a simple hierarchical interface for a watchOS app, using pushController(withName: String, context: Any?) to add views onto the stack. When trying to test on a watchOS 3 device, my app will reset itself back to the root view controller, losing the navigation state, after a "sleep" event.
Is this expected behavior? I would expect the navigation state to reset if the app was purged from memory, but not after the screen goes to sleep.
Setting the app target to watchOS 3 and implementing the handle(_:) WKExtensionDelegate method (which I had not done, since the watchOS targets were generated under Xcode 7) seems to provide the behavior I expected.
Related
I want to set the initial view controller for the watch app base on different type of notification received on the watch. But I don't know where's to set it.
This is the answer for an iOS app
Multiple entry points to a storyboard
watchOS 2
WKExtensionDelegate is the equivalent of the app delegate, where you can:
respond to actionable notifications and manage Handoff transitions. You also use the delegate to respond to life-cycle events, such as the activation and deactivation of your app
In applicationDidFinishLaunching(), you can call reloadRootControllersWithNames(_:contexts:) to specify the set of pages displayed when your app launches.
You can also call reloadRootControllersWithNames(_:contexts:) at runtime to switch view controllers.
watchOS 1
There's no app delegate equivalent.
To create a custom per-notification UI, create a new Notification Interface Controller with a distinct name for the Notification Category. If you need additional customization, see Managing a Custom Long Look Interface in the docs. Specifically:
When a notification of the correct type arrives, WatchKit chooses your static or dynamic interface based on several factors. WatchKit automatically displays the static interface when a dynamic interface is not available, there is not enough power to warrant displaying the dynamic interface, or you explicitly tell WatchKit not to display the dynamic interface. In all other cases, WatchKit displays your dynamic interface. After making the choice, WatchKit loads the appropriate storyboard resources and prepares the interface as shown in Figure 16-2. The loading process for the dynamic interface is mostly the same as for your app’s other interface controllers, with the exception of processing the notification payload, which is specific to notification interface controllers.
The category name should exactly match the category field in your push notification JSON, like INVITE_CATEGORY in this example:
{
"aps" : {
"alert" : "You’re invited!",
"category" : "INVITE_CATEGORY",
}
}
(If you're using local notifications, not push notifications, just set the category property on your UILocalNotification.)
Apple Watch will display the notification interface controller corresponding to your category.
See also Notification Essentials.
In WatchKit 2 there is an extension delegate.
From watchOS 2 Transition Guide
In watchOS 2, your WatchKit extension has an extension object and corresponding delegate object to manage behavior that is central to your app. The WKExtension object is a shared object that is available whenever your Watch app runs. The extension object has an associated delegate object that conforms to the WKExtensionDelegate protocol.
I want to handle the push notification dictionary in my root view controller (and not in my AppDelegate), but when using a NSNotification it does not work! Why?
Working with NSNotification to pass the push notification dictionary, will work only when the app is already open. The reason for that is that the root view controller is not yet initialized, when the push notification is handled (at startup).
Implement PushApps delegate and specific that method
Inside this method, save the push notification dictionary to the NSUserDefaults.
Inside your root view controller ViewWillAppear method, take the parameters back from the NSUserDeafults
Do not forget to erase the dictionary from the NSUserDefaults, so that next time you won’t handle the same push notification again.
Overview:
I am trying to create a PoC application that mimics WebIntents-like feature.
So, in my Qt application, I create two QWebviews launching two different webApps. Now let's call them apps A and B.
Scenario:
Main Application creates two QWebViews each launching an App i.e. AppA, AppB.
App A is programmed to fetch some data via AJAX, automatically.
App B also needs part of that data. AppB simply displays a button (HTML) called .
Note: Since, AppA already has that info, I would like the AppB to invoke a JavaScript API which was injected into it's(appB) DOM by means of addToJavaScriptWindowObject() method call when the QWebView was launched.
App-A completed the Ajax Call and indicates the completion in its WebView.
User clicks the button in AppB,
App B invokes that JavaScript API i.e. fetcData({source: "AppA");
Now the control is in the QT-world:
Question: the Control is in the context of AppB, How should I communicate with the WebView in AppA -- i.e. AppB asks AppA: hey AppA, please give me that data that you have fetched?
Can Signals and Slots help me here? Or should I use some other form of IPC.
I read this page: http://qt-project.org/doc/qt-4.8/qtwebkit-bridge.html, but I still didn't get a hint for a solution for my problem.
Another related question: Are QWebViews created in their own threads ?
Can't you just emit some sort of signal from AppB that basically says, "Hey, I finished fetching my data if anyone wants it" or am I missing something? It would happen at the end of AppB::fetchData().
All you have to do after that is connect any interested objects to that signal.
I am new to Blackberry playbook native development, I feel some difference(in handling touch events) with existing platform like android, iPhone and nokia, in existing platforms we just register a callback with an event and callback got called as soon as there is some event and all that stuff is parallel where as in blackberry you have to query device if there is some event present or not and this is somewhat serialized and due to this users has to experience some delays for their input to work.
So to handle this scenerio I have decided to create a thread and in thread routine there would be an infinite loop that will keep on querying device and as soon there is some event available code will handle this.
Now I have two questions
1. Is this is the best way we can handle this scenerio, If No how could I efficiently handle this kind of scenerio.
2. If this method is right to cater this kind of scenerio then I am having trouble in getting screen events in child thread, I have created screen context, init egl and requested screen events in parent/main thread.
Please guide me
Regards
Ahsan
I have a childwindow with an associated VM that gets created each time I ask the child window to open. when the childwindow opens, it registers a listener for an MVVM Light message. After I close the window, I'm pretty sure that I'm releasing all references to it, but I don't actually call dispose because it does not implement IDisposeable.
When I instanciate another child window of the same type, and send it a different context, I know that I'm receiving the message from the previous instanciation of the VM... each time I use the window, more and more VM are listening, and the code repeats.
How can I be sure that my previous VM that registered to listen to a message, has actually been released and is no longer active. Is there a deterministic way to do this?
Whenever you register a message you should make sure that you unregister the message as well. To unregister you can use Cleanup method on classes deriving from ViewModelBase. In other cases, e.g. a view, you should implement a method hat is called when the view is unloaded - e.g by trapping and handling the unloaded event on a control or view. In this method you then call Messenger.Unregister(EventTarget).
This behaviour is a quirk in the current version of the toolkit, and Laurent is aware of it.
How have you coded the handler for the message in the VM? It sounds like you're probably pointing it to a method inside the same VM which is registering for the message. This causes the Messenger class to maintain a reference to the VM and prevent it's garbage collection (see here for discussion). There are two solutions: implement IDisposable and unregister all messages for your VM instance or simply unregister all messages from the VM instance when the child dialog closes. Personally I'd do both to ensure the entire object web is released.
You can use either the Cleanup method or manually unregister the message. For more details click here.