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.
Related
Hey, I am about to start working on an app. I am a beginner, so I am starting out with a pretty basic concept. But, I was wondering if it was possible to send texts from an app. For example, if the person using my app sets a new high score, could they hit a publish button and my app could then send a text to his buddy bragging about the new high score.
Also, what if someone is using my app and they receive a text, does the OS take over, or do I have to handle the reception of text/calls. Is it possible to alter the way the phone behaves when my app is disrupted by calls/texts.
Thanks for any advice you can give. Have a good Monday everyone!
Apple's iOS documentation has a section that roughly covers how to incorporate in-app SMS.
Basically, your application displays an MFMessageComposeViewController as a modal view controller. It won't cause your app to terminate or background — it just lets your user send a text message, and when done, return to your app and continue.
When a phone call, text message or another notification comes in, your application delegate's applicationWillResignActive: method is called. It's up to you what you want your app to do while the user is dealing with the call, message or notification. If the call is declined or the alert dismissed, your application delegate's applicationDidBecomeActive: method is called and your application can resume as if nothing happened. Otherwise, the app either exits or backgrounds (depending on whether you want it to support multitasking), and you'll also have to handle it from there.
Also bear in mind what Toastor says about
Controlling whether messages can display to your user or not
Bills related to texting plans
There is no way to change the way the phone responds to calls. The only way to prevent your app from being interrupted by an incoming call is by activating the airplane mode on the device - which you cannot enforce from within the app.
Same goes for incoming texts - there is no way to notify your app if a message has been received. How would the system know if the message is meant for your app anyway?
The only thing you can actually do is send a text message from within your app. But if I were you I'd go either with established leaderboards or the new GameKit (have not checked this out yet myself, though).
Or, at least, use mail instead of text messages, since texts are not free in every country.
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!
Some of our application is already in AppStore...
But suddenly one thing comes into my mind, that I want to clear before submitting my next application.
The thing is : As a programmer's point of view, should we require to handle if iPhone Device is jailbreaked ? If yes, then how we can tackle with this ?
Thanks in advance....
On a general note, jail-breaking the device is an issue between the user, Apple and potentially the carrier. You are not a side in this relationship, and the user has no contractual obligations to you with regards to their device.
You could choose to attempt detecting jail-broken devices in an attempt to prevent piracy of your app. However:
If the device is jail-broken, there's nothing you can do to reliably verify it's not jail-broken, since none of the OS APIs (including networking) is guaranteed to function as you expect. Your code could be running in a non-jail-broken simulation on top of jail-broken device.
Of course, you could check by attempting to do one of the things you currently know Apple actively prevents apps from doing. However, there's no guarantee that Apple is not going to allow that particular action in future. And, there's the chance that your app might get rejected because you are attempting to do something prohibited by Apple.
There is no official criteria from Apple on what constitutes a jail-broken device and what does not. And even if there was, you are not guaranteed to be notified in a timely manner (or at all) by Apple if they decide to change any such criteria. But even assuming you do get notified somehow, you can't update your app quick enough to avoid falsely detected jail-broken devices, thus potentially denying access to your app to legitimate users.
If you would like to cut off a large group of users, then sure, go ahead and require it.
Unless your application specifically requires it, there should be no reason to force users to have a jailbroken iPhone or a non-jailbroken iPhone.
If you program is legitimate (no private API calls etc), then you should not concern yourself with JB. You don't need to handle anything differently if the users phone has been JB'd. If it has, and your software doesn't run (say memory issues because they are using backgrounder to run 2 other things) then that's their problem not yours. Make your code well behaved, not leak memory, dump cache's etc with memory warnings, and you should be fine.
As you asked for the "programmer's point of view", I'd say: make sure your app runs on as many devices as possible.
Meaning: as long as you app is safe to run on an iPhone whether it's JB or not, I wouldn't care.
One thing I have found, at least early on (not seen it for a while) is that most reports I got of strange behaviour with my app (vConqr) turned out to be from people with jailbroken phones.
That's not to say I think that's good reason to block them. But if you do any sort of custom crash reporting, or other diagnostics it could be useful to log the fact to save time on troubleshooting.
Do a search on the Internet. You'll find several articles that shows some ways you can detect a pirated app. I make no claim on their effectiveness, but I do use some of these in my own apps. These techniques do not try to detect if a phone is jailbroken; they focus on detecting if your app has been tampered with.
What are the key concepts that a developer should know when building an iPhone application that takes advantage of push notifications?
Number one most important thing, I think, is that your app can't depend on them. It's probably best to regard them as a nice thing for your user, rather than a part of your app's infrastructure. In particular:
Apple doesn't guarantee delivery of the notices. Yes, their infrastructure is pretty good, but there's no promise.
Only one alert can be up on the device at a time, and there's no log. So if the user has a bunch of push-enabled apps, you can't depend on them seeing your alerts.
The only way that your app knows about a notice is if the user chooses to run it in response to an alert.
The user can always turn push notices off, for your app, or for the whole device.
All of that also means: you can't cheat the "no background processes" restriction with the Push Notification Service. :-)
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.