In OS4 the idea is sold to client is that the app is opened in background, and even if the user is on another app, the app can push data to server on regular basis (which would trigger push notifications btw)
BUT on what i read on the internet is that IOS4 multitasking is a fake one :
- it freezes the app, and doesn't leave it in background
- the developper has to specify the app must work in IOS4 (iOS4 qualification process) to ensure that returning on the app won't start agin from beginning
So can anyone confirm that in iOS4 on iphone 4 the app can push data to server in background process ?
Apps can receive and respond to location events in the background in two ways:
Applications can register for significant location changes only (your app runs in the background when a significant change in location occurs).
An application can declare itself as a continuous background location application (full-time background processing in response to all location events).
There's more information about iOS 4 multitasking available in Apple's guide to What's new in iOS 4, and the iOS 4 Application Programming Guide's Background Tasks section.
Related
My understanding for Windows 10 Apps Application life-cycle is that when you switch from one App to another, OS puts first App in suspended mode.
I am running several Apps but none of these is in suspended mode (see image below). I was expecting to see few of Apps in Status column here as Suspended. Can someone help me understand what I may be missing here?
Suspended mode means that the application will have very low memory usage, but not zero memory usage. It does not mean they become background tasks either.
Suspension allows developers to save the state of their app. For example, a user switches between 1 UWP (app1) to another (app2). App1 then has 5 seconds to save state of the application.
For a game that might be score and player position. When the user switches back, the app will show the same position of the game instead of restarting or going back to the beginning of the level. However if the user never goes back and opens 50 more applications most machines (especially phones) will terminate longer running tasks to free up memory aka your application. Now when your application is terminated and the user goes back to restart, it will bring back the same state.
This Channel 9 video explains more about it - https://channel9.msdn.com/Series/A-Developers-Guide-to-Windows-10/13
Actually turned out when I minimize the App, it shown as Suspended in the task manager after few seconds.
Our company wants to port its VoIP application to Universal Windows Platform.
I discovered new VoIP example for UWP https://github.com/Microsoft/Windows-universal-samples
I've checked previous ChatterBox examples - for WP8 and WP 8.1 (and did port own application to these platform).
I see that new VoIP example differs from previous ChatterBox example significantly.
Most of these changes are clear for me.
But I need advice.
New demo uses AppServiceConnection to tell VoipTasks component to run VoIP-related commands.
What is best way for reverse direction? How to dispatch events from VoipTasks/VoipBackend back to UI part of application?
Thank you :)
AppServiceConnection is indeed bi-directional. In terms of lifetime an app service can run as long as the client keeps the connection open. For example, in cases where the client is an app the user is currently looking at you can safely assume that the app service will stay running and respond to events until the user turns off the screen or heads to another app. When that happens Windows will usually come along and suspend the foreground app and terminate any app services it might have sponsored. When your app comes out of suspension it can simply reopen an app service connection to the app service and Windows will start it running again. In fact, I would recommend closing any open app service connections in your foreground app's suspension handler.
Here's the official app services sample that I wrote https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/AppServices and my Build session where I discuss app servies (about 25 minutes in) https://channel9.msdn.com/events/Build/2015/3-765. Feel free to reach me #aruntalkstech if you have more questions about app services.
It seems AppServiceConnection is bidirectional. I can send events back via SendRequestAsync. I still worry about its lifetime a bit - but experiments will reveal the truth
I need to have a background process that runs independent of my app and performs a set of tasks. These tasks need to execute even when my app isn't running. For example, continuously process a list of tasks that contain the date/time they need to be executed on. The background task would iterate over the list and process all of the ones that match the current time.
Is this possible to do locally without the need for a web server and utilizing the push notification services?
Here is a link to an overview of Background Agents on Windows Phone. At this point what you want is not possible with any degree of accuracy (periodic background tasks are run only once every half hour at the minimum) or dependability (background agents are disabled if the user does not open the associated app for a while).
So yes, at this time your only option is to create a push notification server and have that notification deep link to whatever app you want to open.
Team,
i'm developing an iOS application.
My requirement is to query for specific news service(REST API) in regular time interval.I wanted query the service twice for a day and update my sqllite db, even the applciation is in background state. My UI will be updated with data fetched from sqllite db, while the application is in foreground.
My question are,
Is it possible to run NSTimer in background continuously? if yes, is
there any maximum time limit for timer to run in background (say 10
mins or 60 mins)?
Is it possible to send request to download a file using
NSUrlConnection and save the file to documents directory, when the
application is in background ?
Your suggestions will be much helpful for my project design.
Thanks in advance.
What you are aiming for cannot be achieved on iOS:
Arbitrary apps cannot run in the background for an arbitrary amount of time.
You can try to mitigate some of this by using local notifications instead of NSTimer to schedule your updating. This will, however, only buy you a very limited amount of time to do your networking.
The question you should ask yourself at this point probably is:
If you are only updating twice a day, how bad can it be to initiate the download when your app becomes active?
Answering my own question, so that it will be helpful for others.
Ques 1: Is it possible to run NSTimer in background continuously?
Ans: Nstimer will not run while the application in background state. So there is no point of maximum allowed timer value in background. If the application enters into background while there is an ongoing process, [UIApplication beginBackgroundTaskWithExpirationHandler:] can be used to complete the ongoing process. The maximum time allowed by the OS with this handler is 10mins.
Ques 2: Is it possible to send request to download a file using NSUrlConnection and save the file to documents directory, when the application is in background ?
Ans:
Below given information is from Apple documentation. Detail info is found here
In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background,such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app
Apps that supportVoice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
Info about running background process using VOiP type application can be found here
I've read the Apple's documentation about application lifecycle and made some tests to figure out what is the applications life cycle on different devices. (All running iOS 4.x except the 2G)
I've tested "multitasking" capable devices vs some that do not support this feature :
iPhone 2G/3G app lifecycle :
(START)
- didFinishLunchingWithOptions
- applicationDidBecomeActive
(HOME PRESSED)
- applicationDidEnterBackground
- appWillTerminate
iPad / iPhone 4 app lifecycle:
(START)
- didFinishLunchingWithOptions
- applicationDidBecomeActive
(HOME PRESSED)
- appWillResignActive
- appDidEnterBackGround
(RESART app in the "Taskbar")
- appWillEnterForeGround
- appDidBecomeActive
I've tried to kill the App from the "taskbar" but the debugger received a SIGKILL ! What happens when you kill and app in that way ?
When is appWillTerminate called on the "multitasking" capable device ? Are my results correct ?
EDIT:
Quote from apple's doc about appWillTerminate :
For applications that support background execution, this method is generally not called when the user quits the application because the application simply moves to the background in that case. However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason.
What do they mean by "generally not called". " the system needs to terminate it.." means that the method appWillTerminate will be invoked ?
I think you're right. When you kill an app from the taskbar (or when your device is running low on memory and the OS kills the app for you), it just sends a SIGKIL signal. As you note, it never calls any of the callbacks.
According to the documentation:
For applications that support
background execution, this method is
generally not called when the user
quits the application because the
application simply moves to the
background in that case. However, this
method may be called in situations
where the application is running in
the background (not suspended) and the
system needs to terminate it for some
reason.
So, iOS can call the applicationWillTerminate: method but probably won't. (I've never seen it.)
If you want to save any state before your app is killed, you need to do it as it goes into the background.