Is Realm blocking access to the database if iOS background fetch is running while at the same time opening the app?
I know it is on UWP because if I run a background task while running the app I get an exception "%USERPROFILE%\AppData\Local\Packages\appname\db_name.realm: Encrypted interprocess.". Is something similar happening on iOS?
Turns out NSFileProtection is kicking in when the device gets locked.
See https://realm.io/docs/swift/latest/#using-realm-with-background-app-refresh
Make sure you put the database in a separate folder and set the protection on the folder. Trying to change the protection on the Documents folder itself will not work!
Related
I know iOS allows background tasks to run and, for example, continue to receive location updates, but is it possible to do this in a watch app?
In Xcode 9.3, I have configured my app for "background modes" and selected location, and that has created for the WatchKitExtension's an Info.plist, an entry for "Required background modes" of "App registers for location updates".
But my watch app still suspends when the screen turns off, and when it is in the dock.
The App Programming Guide for watchOS, however seems to exclude the possibility of running in the background to receive location updates as it only allows background processing for four classes of activity:
Background App Refresh Tasks. Use a WKApplicationRefreshBackgroundTask object to ...
Background Snapshot Refresh Tasks. Use a WKSnapshotRefreshBackgroundTask object to update ...
Background Watch Connectivity Tasks. Use a WKWatchConnectivityRefreshBackgroundTask object to receive data sent by your iOS app ...
Background NSURLSession Tasks. ...
Other posts to SO indicate it's not possible, but proving a negative is difficult, so I'm asking again:
Am I "flogging a dead horse" by trying to keep the watch App operating in the background for receiving location updates, or is Xcode is making promises that WatchOS won't deliver.
I'm delighted to be able to report that the horse I have been flogging for the past two weeks was not dead after all!
I have discovered an additional state in which my watch app will continue to run in the Background which does not require HKWorkoutSession.
These settings did the trick:
locationManager.allowsBackgroundLocationUpdates = true
and in watchKitExtension info.plist:
set UIBackgroundModes (Required background modes) to location (App registers for location updates)
And I repeat: I am NOT using healthKit
Now my app continues to run even when the screen is off and when the app is out of the Dock.
No, it is not possible.
As the WatchKit Programming Guide clearly states, WatchKit apps cannot use background execution except for 3 use cases:
Network operations using URLSession
Playing audio using WKAudioFilePlayer or WKAudioFileQueuePlayer
Run a workout using HKWorkoutSession
You cannot receive location updates in the background, according to the WatchKit Programming Guide, that should be done in the iOS app that is connected to your watchOS application.
I'm having crashes in my sandboxed app related to reading desktops pictures which I can not reproduce on my Mac but I got rejected on the App Store for it crashing and other users have reported crashing.
The desktop pictures are being read from "/Library/Desktop Pictures" or using NSWorkspace's desktopImageURLForScreen method. These work just fine on my Mac but I'm a little confused because I don't know how I'm getting access to "/Library/Desktop Pictures" without the directory being chosen manually in an NSOpenPanel. As for desktopImageURLForScreen I'm not sure if this is sandbox safe depending on where the file is stored on that users screen.
Can anyone verify these 2 methods for getting the desktop picture are safe in all cases or do I need to request the user select the directory where the desktop pictures are stored (even from desktopImageURLForScreen) in a NSOpenPanel?
First, having the sandbox deny access to a URL does not cause a crash - methods will return error indications. So if your app is crashing it is either because you cannot access the URLs, or because you are not testing correctly for failure.
If you wish to quietly access desktop images you can specify the com.apple.security.assets.pictures.read-only entitlement - this will give your app access to common image locations. It does not guarantee that your app can access the URL of the desktop image, just increases the probability. So you must still test for success or failure.
If your program requires access and if silent access fails you can then put up a standard file dialog; with suitably customised prompts, buttons, etc; to request the user grants access to the URL.
HTH
I have developed a windows phone application and it works fine when it is open and running actively.
It tracks the user movements on the map and shows the position moves with push pins.
Now I want to ensure that the same application runs even the phone is locked when this app was open.
I have added the below code for it to work under lock screen. After this when I verified the app I realized it is not running when the application is locked.
Is there any other change I need to make to get this work under lock screen.Any help would be greatly appreciated.
private void initiliazesettings()
{
PhoneApplicationService.Current.UserIdleDetectionMode =
IdleDetectionMode.Disabled;
}
To have your app running under lock screen on Windows Phone 7.0/7.1/8.0, you need to set ApplicationIdleDetectionMode, not UserIdleDetectionMode. See details here.
Supossing you placed the method in the right place, that code only keeps the screen on, but doesn't make your app run in background when the lock screen is activated. Windows Phone 7 apps cannot run in background, they get tombstoned.
For Windows Phone 8 this is possible - see the sample here from MSDN.
However for Windows Phone 7/7.1 you can't do this.
You can prevent the screen from locking due to the user not interacting with it (as your code shows). However if you manually lock the screen the app will still be made dormant or tombstoned and your location code won't run.
Your only other option is to use a scheduled background task to read the location of the phone, but bear in mind that this is far from real time data (it is a cached location and you only run once every 30 minutes in the best case scenario).
I have an app that I have been developing that can display sensitive user data.
When the user backgrounds the app, the OS appears to take a screenshot of the app as it was running, and displays it so when the user returns, their state is restored.
I am trying to prevent the user's information from being seen in this screenshot.
My initial idea was to display a Popup of my splash screen image, but it does not seem to render it in ApplicationDeactivated. Is there any other way you might accomplish this?
I am not sure you are analyzing this correctly. I don't see how the OS could take a screenshot of an app and use that to restore state. Also, if it was true that the OS did that, Tomb Stoning wouldn't be such a big issue in the requirements for an app in the submission process. A dev needs to handle grabbing and saving state on exit and reloading it on start-up again.
If you didn't code this tomb stoning, are you using a frameowrk that has built in support for this? You could disable the tombstoning so certain pieces of information are not stored, and in fact if this data is that sensitive you should make sure it isn't saved. But, if you save it make sure you encrypt it so nothing else could examine the saved state. Although, that shouldn't be possible on Win Phone as the OS is supposed to enforce the boundries between apps.
Received a response from Microsoft which indicates that this is not possible in the Mango SDK; it may be added into future releases of the platform.
I found when I lock my phone screen and unlock,The xaml page seems to be reload.This is not the point,the point is the whole program I wrote is just like fresh restart.It is true?What can I do with this issue?
You should read the Execution Model Overview. Your app is getting Tombstoned. You need to handle this.
An application in the foreground can continue to run when the phone screen is locked by setting the PhoneApplicationService.ApplicationIdleDetectionMode property.
By setting up your application to run when the phone screen is locked, a user is able to access the application quickly upon unlock. However, when your application runs under a locked screen, it could consume power outside of the user's control. For this reason, your application must minimize power usage when running under a locked screen