I am trying to determine feasibility of certain features required in a (potential) project. I am not (yet) looking for a how-to, just a can-do. I apologize for any vagueness and ignorance: the former due to an NDA that makes Apple's NDA look like GPL, and the latter due to the fact that I have no iPhone or MAC experience.
I do have a solid understanding of objective-c and interface builder (going back to NextStep) and some PDA development experience, so I'll probably understand the answers, even if my questions are naive. I have done a bit of browsing, so I know some buzzwords.
I can't go into detail about the actual project, but I have come up with a lame analogy.
a large number of users in the same room are asked to complete task(s) in the app (say a puzzle)
they are under supervision, but the monitor cannot watch them all closely
they are not allowed to leave the application until done.
they cannot send/receive phone calls or messages during the task.
the monitor receives notification of various steps during the task
the monitor is notified when the task is completed, or the app is exited
the app sends a heartbeat, so the monitor also knows if signal is lost
Jailbreak is not an option.
The app should also work on iPod Touch.
So the things I need to do that seem dicey to me are
can I turn off (or require the user to turn off) phone and sms but still be able send http to my server
can I prevent an app from being switched out (even if, say an alarm app triggers or the phone rings).
failing prevention, can I at least detect any of these events and notify my server.
failing notification, can I record the event for the monitor to check later.
The user will be aware (and in fact welcome) these restrictions. It's a trust issue - the user must not seek help or use a helper app to solve the puzzle, and wants the monitor (and other contestants) to know that he did not. It's feasible for the user to click on an "OK, I understand and approve" screen at the beginning, but not for each communication to the server.
The app would only communicate with a central server (run by my company) - the monitor would not be able to buy the server software, and the url's of the server would not be user (or monitor) modifiable.
Hey! This looks like an app for taking exams. Not what I am doing, but that would be cool too!
EDIT --
I changed the title and am adding a few more parts to the question, based in part on mmc's answer. The App may run in an offline mode that would have to do the following:
So using the exam analogy, the user off line experience would be something like this
Launch App
App download test questions, registers start time, etc.
Turn off phone (if app can't do it by itself)
Disable any app that might interrupt my App (can app do this?)
Resume and Take Test
Indicate test done (or finish last problem).
Turn on phone (if app can't) and restart App (if needed).
App uploads test results and log of any interruptions.
So the question becomes
Am I sure that I at least get to log any interruption I can't prevent
can I know the cause of the interruption (phone answered, alarm launch, user initiated)?
can the user be prevented from modifying the log
can I know what other Apps are running when I start? (to guard against a daemon that occasionally displays a hint or something.
I would still like to run with real time uploads, so a few other ideas come to mind.
If I can reliably detect and record that the phone or another app was used, that might be almost as good as preventing it.
Can the user prevent the phone from ringing even if it's on (eg. call forward + ringer off)
Can my app know if the ringer is off
Same question for sms messaging
If I can't block it, can the user just ignore (silent) call or message and not leave my App. Would my app know that?
Sounds like you might be better off doing away with the phone, and making it exclusive to the iPod Touch.
You've nailed your trouble spots.
There is no way to disable phone functionality, and at the same time maintain network functionality of any type (3G, WiFi, or bluetooth) If you disable the phone operations with Airplane mode, all of them are disabled.
There is no way to prevent the Home button from returning you to Springboard
You can notify a server of a premature app interruption (there is an applicationWillTerminate: method on your app delegate) but is not reliable. If the operation takes too long, your app will be forcibly terminated.
You could write to the local file system that a premature interruption happened, and this would be far more reliable, as this operation would be much faster.
Related
I have a CLLocationManager contained in a singleton and I have added around a dozen regions to monitor. I am successfully notified of boundary crossings when the app is in the foreground/background. However, when I force quit the app, the location icon disappears and I am not getting any callbacks.
As far as I can see, this is intended functionality as of iOS7. Here is a reply I found to a similar question, in this case involving significant location change: https://devforums.apple.com/message/882691#882691:
If a user swipes up in the app switcher then the OS will not launch the app unless explicitly told to do so by the user. So no, SLC will not be launching the app, nor will silent notifications. The only thing that will launch the app at that point is the user tapping the icon. The intention here is that the user has expressed their choice of not having that app running any more for any reason, so we honor that.
In this situation, there's really nothing that you can do. The next time the user launches the app you can let them know that some of the data may be missing, although you really cannot tell whether there's missing data or not (i.e. you might have been killed by the OS in the background and the user may not have moved thereby not triggering any SLC notifications). My suggestion would be to gather the data you can within the policies of the OS and if the user has manually killed the app then respect that wish and don't do anything.
By all means, feel free to file a bug report if this change in behavior winds up causing problems for you or (especially) confusion for your users.
I know this question may be a little bit common and over asked but I cannot find any precise information... so :
Is it possible to have some kind of thread running when the app is in background so I can perform basic sync with my webservice ?
App is in background : I mean the user clicked the Home button, or switched to another app
basic sync : photo upload and download with AFNetworking. I know it has method to continue an HTTPRequest while app is in background, but this is not my point.
My goal would be to make some kind of sync manager, reading a list of photos to update created while the user was on the app, and perform those changes.
I know that the manager could be killed by the OS, but since my server uses atomic transfers it is not a problem. I just need a way to relaunch it... Push ?
I think apps like Google Latitude or Mail and those kind of apps uses what I am looking for but I cannot find any relevant details on it. And using iOS5 is not a problem but waiting for iOS6 would not be a solution.
Thank you for your replies !
PS : well I almost forgot. the app is designed for an enterprise program, so maybe rules are different ? I don't think there is any check for in-house deployment so it might lead to new possibilities...
Apple's Mail client has a background daemon which keeps it running but you can't have that with your own applications. Once an app enters a background state, it must halt it's operations. You can request for a little more time when backgrounded to finish off any transfers or writes to disk (see the Executing a Finite-Length Task in the Background section on Apple's Multitasking Guide)
Google Latitude has events generated based on location. This is a special type of backgrounding introduced by Apple for certain types of applications (see Implementing Long-Running Background Tasks section on Apple's Multitasking Guide) but this can't be used for HTTP syncing. It can only be used for audio, location, voip, newstand content, bluetooth and external hardware attachments.
Push doesn't seem like a solution because it only generates an alert. It doesn't trigger any action until the user triggers the opening of the notification.
You'll want to read Tech Note 2277 Networking and Multitasking.
Basically you have a couple of options:
If you can convince Apple that your app is a VoIP app then you can register a VoIP socket and the OS will resume your background app whenever there is activity on that socket.
Your main option though is to register a background task for any outstanding activity that you have to do when your app is put in the background. You typically get 10 minutes to finish up that work.
Mail is a special app with privileges you don't get.
Apps like Latitude typically register themselves for location updates, specifically to be woken up when there are major geo-position changes. Apps that record GPS tracks do similar things.
Found it !
Using Suhail Patel 's link on Apple's Multitasking Guide I added the voip tag to UIBackgroundModes in Info.plist and use setKeepAliveTimeout:handler: method of UIApplication to relaunch it if needed once the app is going to sleep.
I hope this will help a lot of you !
Of course this app won't be allowed to be on the App Store but for in house development this is in my opinion the best way to do so.
Thanks everyone for showing me the right direction !
Can we interrupt calls/SMSs on iPhone IOS 5? any code samples?
I am looking for some code samples for an application that gets notified when a call is incoming/outgoing to/from the phone, and gets the caller number.
Same thing for SMSs.
I know this seems like spying, but the purpose of this at the end is way far of that.
I'll take this from a non-jailbroken position (because you do not specify it in your question).
Can we interrupt calls/SMSs on iPhone IOS 5?
No. Absolutely not. In doing so, you'd need 3 things:
A Listener For Incoming Calls/SMS's
An Event Called When A Call Or SMS is Incoming.
A Responder Able To Cut Off Said Call
The first is impossible without breaking out of the app sandbox, a clear no-no in iOS development. It also presents a major security risk for the operating system as a whole. If applications could listen to each other and react any way they wanted, it would create chaos! Users wouldn't have any privacy whatsoever. The second would require some kind of listener that was always present and capable of waking/starting your app to interrupt the call, which again, is a clear case of stepping out of the sandbox. In fact, the only way to launch your application to interrupt the call would be to send a URL, which in itself requires an application... Yikes! The third is just plain impractical. If you made even a tiny mistake in the way you determined whether or not to cut off the call or SMS, you could prevent potentially important messages from getting to innocent bystanders.
I know this seems like spying
Because it is! You need a listener in order to evoke some action from your application.
Of course, this isn't to say it's impossible, but it would require a jailbroken device.
I have a requirement in my iPhone app that I know when somebody running the same app is close by.
I'm thinking that GameKit using Bluetooth would let me do that. GPS location is not precise enough in this particular case.
However, if the user closes the app then the function won't work anymore. Even under iOS4, the task switching will close down the BonJour services so I can't have the app run in the background.
Seems to me I can only have this function if the user leaves the app up and running. Would you agree? Or is there a different approach I can take?
People are very concerned with privacy, so they would naturally expect such privacy invading functionality to be switched off when they close down the application.
If they choose to have this feature enabled, then it's a different matter. Then they expect that somebody else may locate them.
You might however consider implementing some sort of opt-in offline service, where the latest gps position is stored on a server including a timestamp. When somebody else (with the app running) moves within a certain distance of this location while it's still "fresh", then you send off a notification to the first device. That way the user would be notified that somebody may be close, and can then switch on their own device.
Ever since the first beta came out I’ve been trying to find out if “real” multitasking is possible — i.e. can you put a program in the background and have it hang on to a network connection indefinitely?
I’m thinking about IM or IRC apps, for example. I’ve compiled an app myself on iOS 4, and without changing a thing it appeared to stay running in the background, but for all I know it was just suspended to memory.
The docs say the best you can do is request up to 10 minutes, but in the developer presentation they showed off Skype sitting in the background and then notifying the user that a call was coming in. Does anyone know for sure how this all works?
It appears the answer is no. The API for Skype is a very special case, called the "voip" mode, and requires special behavior, such as marking the socket in use for VoIP.
You can receive alarm notifications in the background (such as time passed). The amount of time you are in the background running state is severely limited by the OS.
Android's background model is complete and in many ways much nicer.
Apple has a guide named "Supporting Multitasking In Your Applications" which you should be able to locate.
Apple's iOS 4 developer docs outline this all very clearly.
When your app is closed or switched away from, it is almost immediately "suspended", meaning the OS freezes the app's state. When the user switches back to your app, your code keeps running just where it kept off. You don't need to add any code to your app to do this, just compile it against OS 4.
The above is true in most cases. There are two reasons the "suspended" model may not apply:
1) If the device starts to run low on memory, the OS will start terminating suspended apps that haven't been switched to in a while, without warning. This is why it's in your best interest for your app to remember it's state as well, so if your app is terminated, then re-opened, the user doesn't really notice because it still returns to right where they left off.
2) Your app uses one of the "background" APIs. These are for audio playback, VoIP services, or location services. In this case, your app is allowed to continue running in the background but only has access to those APIs. Additionally, your app can designate certain long-running tasks as "background tasks" that need to be completed before the app is suspended or terminated, like uploading pictures to Flickr or rendering a video, etc.
The "background task" method doesn't cover pinging servers indefinitely, as there is a time limit for the task, after which it will be forcibly halted. Apps that need that sort of functionality are expected to implement push notifications, just as before.
That should clear this up. All in all I think it's a pretty elegant solution to multitasking on a mobile device.
iOS 4 applications can either be running or suspended. The operating system will try to keep as many requested applications as possible in memory, while all other applications are suspended.
Applications that run in the background can access features such as navigation, audio, and VOIP (but NOT instant messaging). So it looks like you might be out of luck.
-- PC World Multitasking on Apples iPhone 4
It is possible for apps to request background time. Read the docs. I would say it iOS is "controlled multitasking".
You can create a long running background task, I believe these can include networking features. Just have to set the background task flag on the work block.
https://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
the OS can limit exactly how much time you get though... it will tell you when your time is up giving you a chance to cleanup nicely.
iOS 4 has "real" multitasking to some extend. There are two things to consider:
The UI event loop is single tasking. So only the front app executes on the UI event loop. Not a big deal: detach your main code form the UI event loop (maybe you need to redesign your app).
The OS "may" terminate your app if some criteria are met (e.g. low memory).
Currently one of these criteria is that execution time is limited to 10 minutes (real time not cpu time). However I expect this to change and see better criteria for background app termination (I hope to).
Apart from this you can have timers (event loops) in background.
There is no real multitasking in iOS 4.2 even. because apps will only be allowed to finish the task related to states..for small interval of time and then it will be in suspended state.. If you will set background task for long interval of time then... it will behave unexpectedly like no method will be called when you will try to run the app from anywhere..
You may be interested in this blog post that outlines how "multitasking" works in systems such as iPhone OS 4 and Android.
in fact u can do this, although it's not allowed by Apple. u gotta set up a toolchain in ur mac and use some unofficial SDK...
check http://code.google.com/p/iphone-backgrounder/ for more information
You should use the Push Notifications framework for the feature set you are creating!