I am writing an alarm clock app for iphone, and I want it to turn on the phone(from standby mode) approx 1hr before the alarm is supposed to go off.
Then I want the app to be active, so I can stream content live without the user having to put the phone in an active-mode.
Any way for an app to switch out of standby?
Without using private api an application can only present alertview (via local or push notification).
And only when user taps "view" button this application can be activated. You can see that in the link you provided - (second to last screenshot)
True, you can always add sound to this notifications - so alarm app can work (and there are many out there) but it can't send itself in the foreground.
Nope that cant be done, once the app went to the background state you lose control on it, and cannot bring it back
There might be a way using notifications. Check this SO question for more info:
Alarm Even Application Closed in iPhone
Related
I've been trying to find something about this problem for a few days, but without any useful results. I'm working on a VoIP app for iOS (using an iPhone 4 running iOS 6.0) in Objective-c which uses remote notifications to notify the user about calls when the client is in background.
My issue is quite strange: When the app is in background and the screen is locked, notifications arrive and work perfectly - they ring, and open the app when opened. But when the application is in background, and the screen is unlocked - for example, we're on the home screen - notifications simply fail to appear, not giving any sign that something happened.
Anybody got any ideas where to look around? The app code handles push notifications correctly when they appear, so that shouldn't be an issue. The notifications get out of our server, so I'm starting to think that there is something about the device's settings. The app is set to a "banner" alert style, and its notifications are enabled.
When the app is running in the background, the notification does not appear. You need to catch it in the App Delegate application:didReceiveRemoteNotification:.
Implement this method and put a UIAlert to see when the notification arrives.
I have an idea for a unique alarm application on the iPhone. But at the moment the only way I can see of initiating the alarm is by leaving the app running all night getting it to poll for the current time. Is there anyway to make an app "wake up" or initiate at a certain time. I know I can use push or local notifications but they require user input before loading my app. Thinking about it I could leave my app on all night, but literally doing nothing (saving battery if not being charged) and then subscribe to a local notification for the alarm itself.
Alternatively, can I make the iPhone run my app when an alarm sounds so I don't have to deal with alarm settings at all?
No, your only option is to use either Local or Push notifications.
I think using event kit framework add event in default iPhone calender.
I have requirement for an application which work in background only.
When first time application install on device then after installation that will be go to background. And after two minutes a view will popup on screen.
Now problem is that after installation how to redirect application into background?
i get answer for this that if we want to send our app into background then we have to open another app like as safari. so i get this solution.
Now problem is that how show a view after two minutes from background. I have to create as a demo not for app store. So if anyone have any solution then suggest me.
Thanks
It is not possible to do so in iOS. You can't send an app into the background
If you want your app to get displayed, the only way to do so is through push (from server) or local (from phone) notifications, and the user has to explicitly accept it.
Unfortunately, you can't make it open automatically.
iOS is not designed to run code in the background. There are a few exceptions, for example a music streaming app, or a GPS navigation app, but in general it cannot be done.
Instead, you should run your app on a server in the cloud, and send a push notification to the phone when you want something to happen on the phone. You may also be able to achieve this with "local notifications", depending on what you're trying to do.
Is it possible to keep a socket connection alive in background, to be able to push new data and alert users at all times?
The answer to this question is a definitive yes. If you are in the background state, then you can keep a connection open and process messages from a server.
Unfortunately the complexity here is that you don't have a lot of control over the state your application is in:
foreground - The user has tapped your icon and the app is running with the UI visible.
suspended - The user was previously running your app in the foreground, but suspended it by hitting the home button or receiving a call. Basically your app is 'freeze dried' and will remain inactive until it is resumed by the user (starting where it left off) or it is terminated by the OS (see below).
background - The app was previously running in the foreground but has moved to the background state as a result of something the user has done. Normally your app will move to the suspended state in this case, but there are things you can do as the developer to prevent the instant 'freeze dry' and go into the background instead (see below). Your app will also be in the background state if it is woken up for a significant change event.
terminated - Your app has been unloaded from memory and the next time it starts will be from scratch. This is what happens when you double click the home button and then tap the x next to your app icon. It moves the app from the suspended state into the terminated state. This will also happen if the OS decides it needs room for more recently running apps and your app has been suspended for a long time.
So obviously the trick here is how do I stay in the background state as a long as possible. There are a couple of ways to do this:
Beg for more time - You can get up to 10 minutes of additional background processing when your app is closed if you ask for it.
Use UIBackgroundMode - You can declare youself a voip, audio or location app by adding the corresponding UIBackgroundMode value to the pList. There are special requirements for these types of apps which you can check out here.
So these approaches are not without their own problems (getting approved on the store being one of them) and as such I tend to agree with the other answers that using push notifications is probably your best approach for notifying your users. With the notification improvements in iOS5 this is going to be the best user experience going forward.
You can keep a socket connection alive (or do whatever else you want) in the background for about 15 minutes after your app closes. There are also more specialized background processing modes (specifically, audio, voip, and location) which Apple supports if your app fits into one of their supported categories. See here.
If you want to keep sending the user notifications indefinitely, you want to use the Apple Push Notification Service. This allows your app to continue to receive notifications when it's not running, and it conserves resources since there's only one connection to the APN service at a time.
You can definitely alert users with local and push notifications.
And as far as I know, you can keep a connection open only for limited time.
Look here for more details.
I'm diving into iOS development and am building my own alarm clock app to become familiar with the platform and SDK. One of the API's I'm currently learning is the Local Notifications API, which I assume is the same API Apple uses to implement their alarms in their Clock app.
What I don't understand is how they implement their "Snooze" functionality. As I understand it, Local Notifications allow you to present to the user an alert box that has at most two buttons when your app isn't running in the foreground, one button for dismissing the alert and one button for taking the user to your app. In Apple's Clock app, however, it appears the user is presented with an alert box with two buttons, one button to dismiss the alarm and one button to "Snooze" and reschedule the alarm without launching the Clock app. My questions are...
When the user clicks the "Snooze" button, how do you think Apple is rescheduling the Local Notification for the alarm without launching the Clock app? Do you think they're using their own private APIs that circumvent the limitations of the Local Notifications that only allow for two options? Or do you think they're launching the Clock app to reschedule the Local Notification, they just don't show the app launching and quitting?
The documentation says the "alertAction" property of the Local Notification is the text to be displayed on the right button of the alert box and the slider bar of the lock screen. In Apple's Clock app, however, the "Snooze" text is the left button in the alert box, nor is it the Slider bar text. Why is this backwards?
Thanks so much in advance for your thoughts!
The local notification API does not have any mechanism to do what you want. The alarm clock app is almost certainly not using any of the infrastructure for local notifications, it predates them. Even if it is factored onto some of the infrastructure provided by local notifications, it is certainly not using the public APIs.
You should file a bug requesting that this functionality be added.