I have a Apple Watch app that let's users record audio and they syncs it with the cloud. Once the user is done recording, I upload the file and some corresponding data.
Problem is that if I use a defaultSessionConfiguration for foreground requests, as soon as the app goes into the background (user drops their wrist), the NSURLSession pauses until the app is in the foreground again.
I've tried using a background session but that doesn't seem to work for data tasks. Any guidance on this would be much appreciated.
Related
So, on watchOS, I know you can schedule (and reschedule) a WKRefreshBackgroundTask to do work for you in the background. This is great for my app to make sure that data is current and up-to-date on watchOS - especially since it doesn't receive updates like iOS and macOS.
Except, my data uses CloudKit to store a user's data.
I want to use something like the URLSession scenario, where you schedule a WKApplicationRefreshBackgroundTask where you create a background URLSession task and hand it to the system. The system in turn hands you a WKURLSessionRefreshBackgroundTask where you check if your data completed its URLSession (by checking if the downloaded data exists).
My question is, how do you do something like this with CloudKit?
I could just do the downloading of my user's data in the WKApplicationRefreshBackgroundTask, but I don't think I'm guaranteed it will finish in the time the system gives to my app. This is why (it seems) Apple recommends you split this into two Background Tasks:
WKApplicationRefreshBackgroundTask - to create the URLSession and hand it to the system.
WKURLSessionRefreshBackgroundTask - to act upon the data downloaded from step 1.
I am not sure you can do this with CloudKit? Or, at least I can't seem to find something of the sort.
If you want to use WKURLSessionRefreshBackgroundTask you have to access the iCloud database via URLSession. This is possible from an app but much more complicated.
iCloud web service documentation
send a web request to iCloud from a swift app
Don't forget to get your API request token for your database on the iCloud dashboard if you want to try it out.
When a Push Notification is received on an Apple Watch, pressing the "dismiss" button dismisses the notification and returns to the watch face screen.
Within my Apple Watch app, I would like to implement a similar experience to a notification. That is, tapping an icon or selecting a "dismiss" menu item would close or background the app and return the user to the watch face.
This behavior would allow the user to quickly select a new option and go back to the watch face in a single action, without fiddling with the digital crown.
Is it possible, from within an app, to programmatically cause the watch to return to the watch face?
On iPhones, the iOS Human Interface Guidelines prohibit applications from closing programmatically, as "people tend to interpret this as a crash."
However, the user experience of the watch seems much more oriented around liberally and regularly returning to the watch face. Is it possible to quit or background an app programmatically and return to the watch face, without the user touching the digital crown?
Can anyone please so let me know precisely that how can I accomplish the task in which I need to show Push Notification to user when App is Quit/closed?
Currently, I am able to get the push notification done when App is running in background or opened. But App couldn't receive Notification when it is quit/closed by the user.
Right now, it's a really critical task on my shoulders. It's pretty clear do tell me in case if you guys need me to brief in details.
I am having a very hard time to believe that your scenario is Really the following:
When the app is either: open and in the foreground, or open and in the background, you are able to receive a notification to the device, and have its contents displayed in the app, but
When the app is quit (as in not running), the notification does not arrive to the device at all.
I have tested several devices and several push-enabled applications (event source, tag-based). The notification does arrive to the device, after the user subscribed to either a tag or by logging-in (in the case of event source-based), after which sending a notification always arrived to the device.
I don't understand this sentence:
my app logouts with the user
You need to be CLEAR in your explanation. Is there a logout button that the user clicks? If yes, are you also for some reason perform an unsubscribe API invocation? If no, edit the question and provide DETAILED, step-by-step reproduction instructions, AS WELL as provide your application, or any code that you use so that it could be inspected for possible issues.
I am building an app which exits on going to the background. I have set "UIApplicationExitsOnSuspend" flag to TRUE.
Multitasking feature
Keep the content of your app up-to-date by adopting the new
multitasking APIs in iOS 7. The new services allow your app to update
information and download content in the background without draining
the battery unnecessarily. The updates can happen at opportunistic
times and are intelligently scheduled according to usage, so your app
can update content in the background just when your users need it." to
do this "Double Press the Home Button
My app screen is shown as black screen in multitasking tray/app switcher till it comes into foreground.
Is there a way to show launch graphics/splash screen when the app is in the background during Multitasking tray/ app-switcher?
Can anyone please let me know how to show the launch graphics of my app during multitasking.
Is it possible to ask a Trigger.io Forge mobile app to close itself through the forge JS api?
We're seeing users having problems with reloads:
We pop up a message when a reload is available, but it's difficult for us to explain that they have to
come out of the app
wait an unknown amount of time (for the reload update to download)
launch the app again
People either don't understand, or the force-quit the app meaning the reload doesn't download, or they come out and go straight back in before it's downloaded - and then see our 'reload' popup message immediately again.
I wondered if we could close the app for them if this would smooth things out a bit. Unless people have better suggestions for this user flow?
Are you listening for the updateReady events to pop up your message? If so, the Reload update has actually already been downloaded and is ready to go: all the user needs to do at that point is switch away from the app and back again; no delay required.
The only way to programmatically close a Trigger.io is in the backPressed event listener, which won't be of use to you in this situation.