HKWorkoutSession isn't keeping app at front of Apple Watch - watchkit

It has been stated that an app running a HKWorkoutSession will have special privileges over other watchOS 2 apps, so when a user looks at their Apple Watch, it will go to the view showing running a workout rather than the watch face.
Currently, on both my device and simulator, this is not the case. If I start a HKWorkoutSession and then leave for 5 minutes and then interact with either the Apple Watch, or the Watch Simulator, it presents the watch face.
If I then open my app, it appears to have been frozen, rather than terminated (which is what I imagine happens to other apps). As the UI will update when I need receive a response in my query.updateHandler. Also if I set it to provide haptic feedback every time my query.updateHandler receives a new HKQuantitySample it will do so, so the app must be running in the background in some form.
Has anyone else noticed this behaviour, and am I doing anything wrong, or expecting something I shouldn't?
Here is how I start my HKWorkoutSession:
self.workoutSession = HKWorkoutSession(activityType: HKWorkoutActivityType.Other, locationType: HKWorkoutSessionLocationType.Indoor)
self.healthStore.startWorkoutSession(self.workoutSession) {
success, error in
if error != nil {
print("startWorkoutSession \(error)\n")
self.printLabel.setText("startWorkoutSession \(error)")
self.printLabel.setTextColor(UIColor.redColor())
}

We're seeing that too, for the moment we've made sure 'opens last activity' is configured.
When the UI is active we start a dispatch_timer to request and process data in 1 second intervals.
Make sure you do any significant processing using the NSUserProcessInfo method though and pause the dispatch_timers whenever you are no longer active. You'll get crashes otherwise.

Related

ProgressNotification callback not triggered without an initial download in Realm 10

We are using MongoDB Realm in our app.
The first time the user is connected to the app, the ProgressNotifcation callback is triggered correctly, and it will work and trigger whenever a new download is coming.
Even if no download is pending, the ProgressNotification callback will be triggered (the Progress object pass in the callback will contain values from the last download) at least once(when creating it). I supposed this is due to the fact that we are downloading the first data set of the user.
But after killing the app and launching it again, the ProgressNotification callback is not triggered anymore until new data are received by the app. And from this point, the callback will be called every time we need it.
It seems that now, the framework needs a first download since the app is launch to make ProgressNotification callback to be triggered every time we need it.
This was working in the previous version of Realm (5.X.X). We just finished the migration to Realm 10 and discover this issue.
I am a bit stuck here, do not know if this is an intended change or a bug on my part. But I am pretty sure this was working in the previous version of the SDK.
Can anyone help me with this? Thanks
Note: this is no more working in both mode : .forCurrentlyOutstandingWork and .reportIndefinitely
Example
self.token = syncSession.addProgressNotification(for: .download, mode: .forCurrentlyOutstandingWork) { progress in
.......Some code........ <- this part of the code is not triggered anymore
}
EDIT - 21/12/2020
For clarification, the token returned contains a value and the .invalidate is not being called.
There is no error in the session and any new download is triggering the callback. After an initial download, everything works as expected. This means that when I add a progressNotifcation later on, the callback is triggered immediately with the progress of the previous download. But if there is not an initial download, the callback is never called.
For the scope, this method is actually in the custom publisher that I created and it is not deallocated.
Realm 10.5.0
iOS 14.3

When is sessionReachabilityDidChange(_:) called on a watch WCSessionDelegate?

Apple's documentation says this in the discussion section of the method description:
This method is called to let the
current process know that its counterpart session’s reachability
changed.
The description of the isReachable property says this: WatchKit
extension. The iOS device is within range, so communication can occur
and the WatchKit extension is running in the foreground, or is running
with a high priority in the background (for example, during a workout
session or when a complication is loading its initial timeline data).
I am assuming this would mean that if the watch moves out of or into range of the iOS device, the WatchKit extension would be launched and the WCSessionDelegate's sessionReachabilityDidChange() method would be called, and the WCSession's isReachable would be true if the iOS device just came into range and false if it just when out of range.
I have not found a way to verify this in xcode. For example I put a log message in sessionReachabilityDidChange(_:) and walked out of range, but xcode simply says the app lost connection with the iphone and can no longer debug it. Can someone verify this or point me to some documentation that better describes this?
I think you cannot verify this in Xcode.
I have an app on iOS and watchOS. To check this kind of situation, I can enable debug alerts on iOS and watchOS. When func sessionReachabilityDidChange(session: WCSession) is triggered, I display a debug alert.
Now, if I run (not under Xcode) my watch extension, and then switch off the paired iPhone, the debug alert is shown on the watch.
This shows that sessionReachabilityDidChange is actually called as expected.
Apparently, under Xcode a connected iOS device is always reachable.
EDIT:
To check the situation when the watch extension is not in foreground, I did the following:
Instead of showing a debug alert, I set now the complication to a unique value that is not possible otherwise. I launched the watch extension and put it into background by showing the watch face with the complication.
When I now switch off the iPhone, the complication is not updated.
This indicates to me that sessionReachabilityDidChange is not called in background.

Don't know how to kill app process in KaiOS

I am developing an app that uses ws connection on KaiOS. When I press back and put the app in the background, somehow the app instance is not killed. I can still get message coming in from ws connection even though the app is in background. This makes the phone runs out of battery quickly because exited app remains in the runtime process I suppose.
But, I do need a situation where the app runs in background (not killed).
So, the question is, do we have access to kill an app process, for example when user press something or normally when app is closed and screen back to menu screen from app screen?
I think you can observe the Backspace key and close the window.
Such as:
function handleKeydownEvent(e) {
if (e.key == 'Backspace') {
e.preventDefault();
window.close();
}
}
document.body.addEventListener("keydown", handleKeydownEvent);

"The Internet connection appears to be offline" when making URLSession requests on Apple Watch using LTE

Bug:
I'm consistently getting error code -1009 "The Internet connection appears to be offline." errors when making URLSession requests in an Apple Watch extension on an Apple Watch Series 3 when connected to the Internet only via LTE.
Steps to Reproduce:
Install the app.
Configure your device so that it's only on LTE.
Verify your connection to LTE using iMessages, e.g.
Launch the app.
Initialize a URLSession using the .default or .ephemeral session configuration.
Make a data task request for any known-good https URL.
Expected Behavior:
The request manages to reach the destination.
Observed Behavior:
The request fails immediately with error code -1009 "The Internet connection appears to be offline."
Code Sample:
let config = URLSessionConfiguration.ephemeral
let sesh = URLSession(configuration: config)
let url = URL(string: "https://google.com")!
sesh.dataTask(with: request) { (_, _, error) in
print(error)
}.resume()
NOPE: SEE UPDATE #3 BELOW: The crucial missing element: you must set the waitsForConnectivity flag on your session configuration to true.
let config = URLSessionConfiguration.ephemeral
config.waitsForConnectivity = true
let sesh = URLSession(configuration: config)
let url = URL(string: "https://google.com")!
sesh.dataTask(with: request) { (_, _, error) in
print(error)
}.resume()
If you do not set that flag, the requests fail immediately because LTE access isn't available instantly but only after the briefest of delays. Setting this flag to true makes the requests work. In my testing there even seems to be no appreciable difference in timing between enabling the waitsForConnectivity over LTE and making the same request without enabling waitsForConnectivity but conducted over WiFi, almost like the waiting period enabled by waitsForConnectivity in some scenarios is a next-turn-of-the-runloop kind of situation.
Update #1
I am unable to make any requests over LTE. When waitsForConnectivity is set to true, the requests just timeout according to the timeout properties of the session config. When waitsForConnectivity is false, the requests fail immediately. I'll update my question and answer when I have more information. I'm waiting on a response from an Apple TSI request which usually takes several days.
Update #2
Adding to the mystery, the same sample code runs fine over cellular on two other developers' hardware. I know that my hardware is good because Apple's apps fun fine over LTE on it (phone calls rolling down the highway with nothing but my watch in the car). So there's something really fishy going on. I've asked Apple DTS to look into this, and they can't reproduce the issue either. I'll be following up with them as soon as I can.
Update #3
Sometime in the intervening weeks after I last updated this post, cellular requests started working in my apps. I didn't change anything about my watch, no software updates, no resets, nothing. I didn't even recompile the code; the same build is still on my watch as previously. It just started working as expected, same as it did on other developers' devices.
The only thing strange I noticed is that I got three, back-to-back, identical SMS messages from AT&T notifying me that my Apple Watch is now linked to my iPhone number. Which is strange, because that linkage supposedly occurred the night I unboxed my phone, not two months later. I have no idea if this is related to my issue. All I know is that cellular requests are now working.
I had the same problem but was developing an App for the iPhone. This is what finally solved the problem. I set the configuration objects property:
config.allowsCellularAccess = true
This is very confusing, because the Apple documentation states that this property is set to true by default... but in my case it was not. Also, even though I am using "background tasks," and they are always meant to wait for connectivity, I also set waitsForConnectivity = true, too, just in case.
Just in case someone runs into this error but has everything set up correctly. I was running my project from xCode onto a real device but couldn't get past the internet connectivity issue.
In the code there was a check for __DEV__ to determine what API url to use.
I was building this for running not testing so i assumed it would make __DEV__ false. but it did not, so I had to change the code for that check and set it to a non-localized api url.
even if you are injecting your url, it might not grab the correct one based on if it thinks it is a DEV build or not.

Using apple script to press the return key when prompted to connect to server

Currently this is my delima. Once in a while a build agent will reboot. It needs to always stay connected to share on one of our servers. The idea was to tell finder to mount the volume, wait 2 seconds, and then press enter...since the user name and pssword are both part of the address when I enter it such as SMB://username:password#Server1/DFS it pops up the pasword dialog fully populated but I can't get applescript to recognize it, then press either connect or the return to say "Yes" login witht hat name and don't prompt me.
it worked fine when connecting at home to a synology device but it's not working when connecting to a server in the office.
tell application "Finder" to mount volume "SMB://username:password#Server1/DFS"
delay 2
tell application "System Events" to keystroke "return" -- key code 36
Any help for this seemingly simple step would be greatly apprecited.
I have looked ove the forums and found variou stratagies but they all relate to an application like Firefox or some other script aware app. I just need it to press enter when the password dialog comes up.
First of all the Finder is not needed to mount a volume, you can delete the tell block.
Secondly, if username and password are passed the volume is supposed to mount without a dialog. Maybe you could find the reason why it doesn't.
Nevertheless the password dialog belongs to the process SecurityAgent, you have to use (ugly) GUI scripting to press the button:
tell application "System Events"
repeat until exists process "SecurityAgent"
delay 0.5
end repeat
tell window 1 of process "SecurityAgent"
click button 2
end tell
end tell
The script waits until the window appeared, this is much more reliable than an hard-coded delay.
Looks like a possible XY Problem as I would expect a solution such as https://apple.stackexchange.com/a/698/204318 to work for you to directly mount the share:
mount -t smbfs //username:password#MACHINENAME/SHARENAME /SomeLocalFolderOfChoice
However, if you are really required to interact with the dialog, and as you asked about it, take a look at this tutorial (written in Python) for scripting up something:
detect missing connection
attempt connection
capture screen periodically
look for dialog box, else loop
error after a few seconds of failure
if dialog is detected, interact with it
input username and password
wait, then press return
check if connection worked after a small delay
success or failure
This type of strategy is very powerful for interacting with all sorts of different dialogs you may encounter and should be possible in AppleScript if you are much more familiar with it (or another scripting language).
If you are open to non-AppleScript solutions, then you might consider Keyboard Maestro, one of the best Mac automation tools available.
You said:
it pops up the pasword dialog fully populated but I can't get
applescript to recognize it, then press either connect or the return
to say "Yes" login witht hat name and don't prompt me.
You could probably do this very easily using Keyboard Maestro. Here's an example of the KM Actions to accomplish this.
If you'd like help with KM, please visit the forum at:
https://forum.keyboardmaestro.com/
I'm a big AppleScript/JXA user, but I often find it easier/quicker to use KM for many automation tasks. Of course, KM Macros can execute AppleScript, JXA, Shell Scripts, and other scripts easily.
You can try a full version of KM for free for 30 days.

Resources