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! :)
Related
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.
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.
I used an evaluated jxbrowser, which version is 6.14, I write an demo to use it. but i have a problem with it.
Use the demo app to start an application, which can show web UI, keep this applciation with opened, but then I start demo app again, system will throw below exception:
chromium profile directory is already/used by another BrowserContext instance or process
jxbrwowser cannot start two clients in one PC? if can, how to resolve it?
We strongly recommend that you don't use several BrowserContext instances with the same profile directory. Chromium engine wasn't designed for such usage and doesn't support it. Even if you don't see any issues right now, the issues will appear later in end user environments. For example, in macOS environment you will get the Chromium's error message dialog every time when you run your application instance developed in such way.
Since it's a critical requirement in the Chromium engine, I don't think we will make it configurable in next versions. This is how Chromium engine works. These is a recommendation we have to follow when working with the Chromium engine.
I'm writing this post because I don't know what I can do.
I'm developing an big app for iOS with a lot of users for my company; to log error and crashes I'm using Microsoft MobileCenter (Analytics and Crashed ver. 0.6), Xamarin.Forms ver. 2.3.3.168 and a lot of components such as Xam.Plugins, SQLite, PCLStorage, SharpZipLib.
As MobileCenter request the minimum target version for the app is 8.
Apart from minor bugs, the big problem is difficult to explain. I'm trying to ask you an advice.
The app is working fine. If I test it, I can't have any problems. At same point the app crashed for any apparently reason. No logs, no crashed, no nothing in MobileCenter. From this moment it's impossible to start the app and I can't have any logs about it: I can see the splash screen but after than the app is crashed again. It seems the problem raises after taking photo with camera.
When the app starts, it deletes images (if there are any in the folder), send a file to my server, and check with CrossDeviceInfo what the OS version is. Then the first page is called.
I tried to understand the problem to read the log in Xcode after connecting my device to my iMac but it's incomprehensible.
If I try to read the View Device Logs I can find one crash for my app but the log is still incomprehensible for me.
Then from Xcode I tried to open Organizer and under Crashes...
If I connect the device with this issue to my iMac and I deploy the app on it, the app is working fine. How can I understand where the problem is to fix it?
Update
In my App.xaml.cs I initialise MobileCenter like the following code:
public partial class App : Application
{
public App() {
// my code
}
protected override void OnStart()
{
MobileCenter.LogLevel = LogLevel.Verbose;
MobileCenter.Start(typeof(Analytics), typeof(Crashes));
}
}
It's Benjamin. I've already replied to you issues in our intercom but I wanted to reply to your issue here.
This scenario is not an actual crash but a kill of the app process by the operation system. The SDK runs as part of the app process and therefor can’t ever figure out that this kill even happened because the process is fully removed right away. Technically this is not a crash from an SDK perspective that it can detect and provide details for. Every single 3rd party SDK has this limitation and there is no way around it as Apple doesn’t provide the technical possibilities to do so.
In addition, none of your provided crash reports contain any reference to Mobile Center thus I can rule out our SDK is the cause of the kill.
I hope you find the cause for the issue.🖖
I seem to get a bug. When FragmentB is displayed and has been overnight and then in the morning when I open the app FragmentA is displayed first. When I hit the back-button it seems like FragmentA disapiers however underneath it it appears another FragmentA is hiding. When I try to "use" the app normally again it crashes.
My app is working like wonders otherwise when I activley use it. The only difference is when I leave my phone for a large amount of time (when I sleep)
As I said I discovered this bug when I woke up this morning and was gonna test out my app again. I've tried to recreate my actions from last night and the app works perfect :/
Any ideas?
This is likely to have something to do with Android's garbage collection. When your app is in the background and other processes are running, the garbage collection may delete your app's data or state, causing it to misbehave. This is especially true the longer the app spends running in the background.
Possible solutions:
Do you save your app's state in the savedInstanceState bundle and load it back in the onRestoreInstanceState() method?
If you think it might be an SQL error, you should save your variables so when your program resumes it can reload important values.
Some tips:
http://android-developers.blogspot.com/2009/02/track-memory-allocations.html