I have implemented iOS/iPadOS 13 state restoration using NSUserActivity, mainly because my app supports multiple scenes.
The problem is that when I'm running the Simulator with two side-by-side scenes and force restart the app by rebuilding the activities are not saved and the UI is not properly restored on relaunch.
On the other hand if I first go back to the iPad home screen and then I force relaunch the app, the activities are properly restored.
Would this mean that a crash of my app would prevent saving these activities leading to an inconsistent UI state on relaunch?
And how could I periodically "force" saving activities (get stateRestorationActivity(for scene:) called)?
The problem is that when I'm running the Simulator with two side-by-side scenes and force restart the app by rebuilding the activities are not saved and the UI is not properly restored on relaunch.
What you're seeing when you "force restart the app by rebuilding" is the expected behavior. When you force restart like that, the app does not have a chance to save your NSUserActivities. Per Apple's state restoration tutorial:
If you want to test your app’s ability to restore its state, do not use the app switcher to kill the the app during debugging. Instead, use Xcode to kill the app, or kill the app programmatically. One technique is to suspend your app using the Home button, and then stop the debugger in Xcode. When you launch the app again using Xcode, UIKit initiates the state restoration process.
I understand that you weren't killing the app in the switcher, but any "forced" stop will disable state restoration (with a caveat). To test state restoration, instead use the technique suggested by Apple's tutorial above.
Would this mean that a crash of my app would prevent saving these activities leading to an inconsistent UI state on relaunch?
I think so. This is the caveat from earlier. While Apple says that killing the app (whether in the app switcher or from a crash or whatever) will disable state restoration, this is not necessarily true. You can see for yourself that Apple's own apps have odd state restoration inconsistencies when killed in the app switcher and re-opened (you may have to try it a few times to get inconsistent behavior). While I haven't tested this, I'd imagine that those same inconsistencies can occur from app crashes.
Related
My app is using Firebase Analytics and I believe starting in iOS 13.2 started getting the errors described here: Why I get the console warning: [Process] kill() returned unexpected error 1 when I load a WKWebView in iOS13.2?
I guess it wasn't a big deal
Since I planned for my app to go live in January, I began bigger tests in physical devices. I noticed after a while the app started to behave erratically, specially after receiving a [general] Connection to daemon was invalidated error. This doesn't occur in the simulator
Searching the internet I found a post that describes the same problem: https://forums.developer.apple.com/thread/124306
In my case, only Firebase seems to be calling WKWebView, but every time I open the UIMenuController I get the error described in the console and the app appears to be missing inputs. This is specially troublesome with UIScrollViews, which my app uses a lot. The pinch gesture seems to work at will. On an iPhone 6s, the issue isn't as noticeable, on an iPad, it's like a 50% chance the pinch gesture will work properly
Outside of removing Firebase, is there a way to mitigate this issue?
1 June 2020: The console message still persists, however, I have seemed to resolve the UIScrollView issue by deactivating delaysContentTouches, now the pinch gesture seems to work most of the time
23 October 2020 If anyone notices their app starting to behave erratically with no apparent reason I HIGHLY suggest to test it on an iOS 13 physical device if possible. Seems that Apple removed the warning from iOS 14, but testing it on iOS 13 you can pin point the exact reason after the warning appears in the console
Upon further testing, I've reduced the view down to a dead-simple UI view with a single SwiftUI TextField and the 'Connection to daemon was invalidated' still appears after I type the first character into the field. Soon thereafter the app crashes with a sigAbort. (So I don't think the reason is the UITextView wrapper I was using in the previous post). Once the invalidated message appears the app is doomed to crash, not right away but soon thereafter.
I have no idea what causes the 'invalidate' message and a Google search seems to imply that no-one else does either. Some folks appear to have made (experimental?) changes to their UI that stops the message but it appears to be impossible to determine a definite cause. (and like before it only occurs on a real phone)
Same issue without using Firebase at all. What I did: Delete build folder and compile again. Issue does not appears again.
On Xcode:
Clean the Build Folder
This will delete all of the products and intermediate files in the build folder. To clean the build folder you can use the shortcut Command+Option+Shift+K or Menu Bar → Product → Hold Option Key → Clean build Folder.
On Flutter:
Just delete build folder.
Problem summary
I'm attempting to establish a connection between HoloLens and an Android device, which worked sporadically in the beta-version of the MRTK.
However since moving to the MRTK RC1 (Also Refresh), I've encountered issues regarding the QR-scanning. When pressing connect, the two devices seemingly finds eachother, however when the wearer of the HoloLens1 looks directly into the QR-code, nothing happens. (the white dot and "Locating marker..." text is showing)
Background summary
1. The Setup:
Implemented working MRTK RC1 Refresh
Cloned Feature-SpectatorView separately, copying only the "MixedRealityToolkit.Extensions" folder to the MRTK project.
"Spectator View - HoloLens" prefab added to scene.
First pressing "HoloLens" in the PlatformSwitcher, building for HoloLens1, then switching to "Android" and exporting the project to Android Studio.
Building the .apk from Android Studio
(opencv binaries are downloaded and implemented since beta version, I haven't since changed them from when they worked the last time.)
2. The Proces:
On the HoloLens, I press the "Connect" button in which a white text appears saying "Locating Marker..."
The Android phone presses connect and it goes to "Waiting for User" then as soon as a HoloLens is connected, it switches immediately to a QR code that should be readible from said HoloLens.
Looking directly at the QR-code and nothing new happens, connection does not establish further.
I checked if something was not ticked in Player Settings/Capabilities, but I can't seem to find what the culprit would be. Did I forget something in this proces?
There are a few things that could be causing this issue.
If the Android device is showing a marker, this means the two devices have established a network connection and are communicating with one another. Typically, when I run spectator view I enable the following capabilities: "Internet (Client & Server), Internet (Client), Microphone, Pictures Library, Private Networks (Client & Server), Spatial Perception, Videos Library, Webcam" in the Package.appxmanifest in visual studio. Pressing "HoloLens" on spectator view's unity platform switcher should typically achieve enabling these capabilities, but sometimes the package.appxmanifest doesn't get updated correctly in the visual studio project with subsequent builds in Unity. You can fix this by deleting your visual studio directory and rebuilding the visual studio project in unity.
If these capabilities are checked in the package.appxmanifest, it may be that you rejected a capability request when first running the application. If you open Settings -> Privacy -> Camera on the HoloLens, you can check whether your deployed spectator view application has camera access granted. You should be able to enable the camera functionality here if it is disabled.
There have been changes to both MixedRealityToolkit and MixedRealityToolkit-Unity spectator view logic, so cloning these items at different points in time may cause functions to no longer resolve (We're hoping to consolidate this code into the same repo/commit history in the future to prevent this from continuing to happen). Typically, in the Unity logs there will be errors stating that a function was not found for SpectatorViewPlugin.dll if the dll functionality is not resolving correctly. It sounds like this is not the issue you are hitting if things worked previously. But if it does turn out the case, it may be that you need to rebuild the SpectatorViewPlugin.dll to match the feature/spectatorView code you are using.
If you recently copied the SpectatorViewPlugin.dll and its dependencies to a new unity project, it may be that they aren't getting registered as usable by the windows uwp unity player. Make sure these binaries are in a Plugins\WSA\x86 folder within your assets folder. Also check the *.dll.meta definitions in the unity inspector to ensure the dll's are declared as usable for the unity wsa player/x86 builds.
I'm making a BB10 app with a headless component that's normally supposed to run nonstop, except when a certain field in its QSettings changes (to save battery power).
I tried looking everywhere for the documentation. But I still can't find out how to make a headless app terminate itself.
You can get notified every time your settings file change using QFileSystemWatcher and calling bb::Application::instance()->quit() when a certain QSettings value changes. Here's an example from BlackBerry that uses QFileSystemWatcher in headless to get notification whenever the QSettings file changes.
I prefer using invocation or my own headless communication mechanism though, you can see an exemple of how I usually deals with terminating the headless app here.
Our test automation sometimes makes the simulator crash. In these cases, we often see the dialog below throw on the simulator's next launch. This modal UI dialog breaks automation by preventing application execution until the user chooses an action.
When the iOS Simulator crashes, the application state may be saved in ~/Library/Saved Application State/com.apple.iphonesimulator.savedState. The presence of this folder or values in the data within triggers the modal dialog.
Removing this folder (rm -rf "~/Library/Saved Application State/com.apple.iphonesimulator.savedState") before restarting iOS Simulator will prevent the dialog from appearing. This has been tested with iOS Simulator shipped in Xcode 9.4.1.
I have an app that uses HKWorkoutSession. This app also support background modes. It uses HealthKit only to notify user in set intervals and doesn't collect any data.
Everything works fine, if it running alone, but if a user follows the next steps:
Start native Workout app
Start my app
Go back to native Workout
Apple Workout app crashes. Does anybody have an idea why?
There is also another scenario. If user starts my app first and then native app, my app refuses to work in background.
Bug takes place on watchOS 3.
Unfortunately, you can't have two simultaneous HKWorkout sessions running at the same time. So starting a new HKWorkout session (such as on your app) ends another pre-existing HKWorkout session (such as on the native Workout app). I don't believe either app should crash if this occurs, based on personal experience. I believe the crash may have something to do with the way you are handling either the start or end of the workout session. Hope this helps! :)