According to the APNS Reference at Apple.com, an iOS device cannot receive notifications while it's offline / not connection to 3G or WiFi or similar. Yesterday I found an application (Pillboxie) that claims to be able to notify users even though they're offline. I quote:
"In order to use reminder technology that doesn't requre a network connection, Pillboxie will only run on devices running iOS 4.0 or later."
and
"No network connection required!"
Both quotes are copied from the App Description in the App Store.
I have not succeeded to find out how this works and whether it is as reliable as APNS. Does anyone know anything about the offline noficiation service mentioned in the quote above?
Pillboxie uses UILocalNotification to do that.
It is totally implemented on the app itself, without the need of a server side notification or even the internet connection.
You will not be able to use that for sending push notification, from a server to the user device, which is the one that requires the internet connection (wi-fi or 3G).
You can read more about it in Apple's Local and Push Notification Programming Guide
I believe they refer to local notifications and not remote notifications.
Loacl notification are stored locally in the user device. And shot by the iOS itself.
From UIlocalnotification reference:
The operating system is responsible for delivering the notification at the proper time; the application does not have to be running for this to happen. Although local notifications are similar to remote notifications in that they are used for displaying alerts, playing sounds, and badging application icons, they are composed and delivered locally and do not require connection with remote servers.
I'm the developer of Pillboxie. Felipe is correct: Pillboxie uses UILocalNotifications to schedule its reminders. I chose local notifications over push for several reasons. There are pros and cons to either kind. I chose UILocalNotification because it made more sense with the serious medical nature of Pillboxie:
LOCAL NOTIFICATIONS
PROS: Don't need to manage your own server to interface with the APNS. Very reliable, always on time; Works for people who don't have a network connection often (iPod Touch and iPad users); Works when traveling overseas; Automatically adjusts to the current wall-clock time in the current system time zone (if you've set a reference time zone in the time zone property in the UILocalNotification).
CONS: Max of 64 notifications per app; Can only repeat in whole units of either 1 minute, 1 hour, 1 day, 1 week, etc. If repeating, can't set a stop date.
There are actually 2 types of notifications.
Push - generated by APNS require internet connection
Local - generated on device by the application
So the app you are reffering to might be using local notifications. Check docs for more
Related
I currently sell a Mac-only productivity tool that uses visual and audio notifications to remind the user of certain events taking place.
I've started planning the iPhone and iPad versions of that Mac program and would like to be able to provide notification services from the Mac to the iPhone, e.g. instead of the Mac playing an audio cue, the iPhone could vibrate, etc.
I have so far done very little iPhone development and I'm not really sure how the various push notification services work. Is this easy enough to do? or is a "challenge".
A few more potentially relevant pieces of information:
there will be a Dropbox-based sync between the iPhone and the Mac versions, so there is also the possibility of "sharing" a file that would prompt some action
it might be acceptable as a first step to not have "background" notifications and require that the iPhone client is running
What authentication issues should I expect to deal with?
You'll need to implement APNs (Apple Push Notification Service) in both your app and your server.
To clarify a few things:
You'll need a server doing those transferring messages job between the user's Mac/PC and their iDevices.
Your server will decide when to push what kind of notification to which user's device.
After that, your server sends a message to Apple's APNs server, which will push that message on your behalf.
It's absolutely OK that your app can be in the background or even closed when the APNs message arrives at the user's device. The user will be guided by the OS to open your app.
If the user has explicitly disabled your app's APNs function in her/his device, or, if the user cancels the APNs alert when it arrives, your app won't be launched if it originally stays in the background or if it hasn't been open yet.
The user will be asked to enable (as you put it, authenticate) your app's APNs function by the OS in her or his device when your app is launched for the first time.
It's not a challenging task for an experienced iOS developer or an experienced PHP developer, since Apple's documents and APIs are pretty straightforward. However, configuration on the server side can be a little tricky.
I believe Stack Overflow already has tons of information on how to enable APNs in iOS apps. All you need to do is be specific in your question and do the search work beforehand.
Hope that helps.
How does Apple do polling of a phone's location remotely? Is there any API that allows an app developer to do the same with the SDK?
My guess is that they are private, undocumented and probably un-callable api's.
I couldn't imagine the huge security implications of having an external party/app be about to poll a phone location without the users consent.
An iOS device already maintains a connection to one of Apple's push servers if push is enabled, and the server has to know the device on the end of the connection (to determine the push notifications to deliver to it). The easiest way to build on this is to have the server say "tell me where you are!" as a push notification.
The device also hits Apple's servers for other reasons (App Store updates, captive login page detection), but it's less likely that the server can identify the device in these cases.
That said, you can do this with the user's consent:
Make your app a background "voip" app (<key>UIBackgroundModes</key><array><string>voip</string></array> I think)
At app launch, check that you can retrieve the current location (I'm not sure what happens if you do this while your app is backgrounded).
Maintain a "voip" connection to your server.
When the server asks the device for its location, ask Core Location for the location again and send it to the server. (I think you also need either "location" in UIBackgroundModes or you need to keep the connection active, possibly in both directions; the former may be easier.)
You won't be able to stop the "location services" icon from appearing in the status bar. The usual multitasking caveats also apply (your app can be killed if the phone runs out of memory; "voip" causes your app to be relaunched sometime later though).
I'm pretty sure if you do the "voip trick" your app will be refused from the store. It is only allowed if your app is actually a VOIP app, not just using it as a technique to circumvent background processing restrictions.
How are push notification better than pull notification on iPhones?
Are there any links with more information about this?
Any help would be appreciated.
Pull notification requires the user to be running your app, and your app to be wasting battery power constantly polling some server (or waiting on some network socket in another thread , or using the new background services).
Push notifications, when enabled by the user, and if the phone has a network connection, allows a message to be sent to a phone even when it's not running your app, prompting the user that your app wants some attention. It uses a much lower power network connection than any frequent polling method.
If you want to know about push notifications, I'm guessing you are interested in the Apple Push Notification Service.
You can read about its architecture here:
http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
There is no such thing as a "pull" notification, but using APNs gives you the advantage that you don't have to manually poll a server every so often within an app, which usually saves you a lot of battery life in the long run if you are interested in telling the user about sporadic, infrequent events. Using push notifications also allows you to interrupt the user if they are not currently running your app, which of course can be very useful in certain use cases.
You should think about what kind of message flow you expect to see between your app and any server components in your system. Push notifications make the most sense where some event external to your app is going on which requires the app to be updated in some way, and where the frequency of those updates is low or highly variable.
I'm having trouble keeping wifi from disconnecting after 30 mins in an iphone app that needs to function when locked by the user.
The app normally does not sleep, but if the user so chooses they may lock the display. I'm adding a new feature to the app that sends data out over the network at 1 second intervals. prior to this there has been no network requirement for the app, and it has functioned as desired (music, timer-based processes) while user-locked.
The answer seemed to be here:
Wifi connection doesn't stay alive when asleep, with iOS4
But adding UIRequiresPersistentWifi boolean to info.plist doesn't keep it from timing out the wifi (i'm testing on Touch, iOS4.02) after 30 mins, even while the app is busy sending data out over the connetion. Maybe this only applies if the display sleeps itself, rather than user locks?
Related, I think there is no way to "stir" the display at any interval? User pressing the home button is sufficient to bring back the wifi; unlocking is not necessary.
Also, I've read on the interwebs that it was stated in a WWDC that UIRequiresPersistentWifi applies to keeping alive 3G as well. Can anyone verify?
thanks
Your app may be getting suspended by the OS after a long enough period of user inactivity.
Under iOS 4.x there are certain types of apps that aren't suspended when the display is locked (music player, VOIP, etc.) Apps that register as a VOIP type app might be allowed to keep a persistant network connection over a longer period. However Apple may require that an app actually provide some VOIP functionality in order to register for that type in any app submitted for review.
Is there some activity that you need to perform network activity? From iOS5 onwards, we have noted that even if we send network packets (heartbeat timers), then also iOS 5 blocks it after locking device.
It is to be noted that services which requires VoIP continue to receive calls, and notifications do come when your phone is on sleep mode or locked. This means that WiFi is not totally closed. I dont know how this happens.
As an alternative you can use data carrier of your network provider as an alternative to WiFi in case WiFi has gone down. With UIRequiresPersistentWiFi, you just inform iOS5 that you would require WiFi to run your application, nothing else signifies whether it keeps your screen ON or OFF. For keeping your phone from autolock you can however use disableTimer = YES flag, in lieu of your battery charge.
I am developing an iPhone App that uses Apple Push Notifications. On the iPhone side everything is fine, on the server side I have a problem. Notifications are sent correctly however when I try to query the feedback service to obtain a list of devices from which the App has been uninstalled, I always get zero results. I know that I should obtain one result as the App has been uninstalled from one of my test devices. After 24 hours and more I still have no results from the feedback service..
Any ideas? Does anybody know how long it takes for the feedback service to recognize that my App has been uninstalled from my test device? Could it be due to the sandbox environment?
I have just had exactly the same problem:
int bytesReceived = 0;
byte[] feedbackPacket = new byte[38]; // Each feedback should always be 38 bytes long
bytesReceived = stream.Read(feedbackPacket, 0, feedbackPacket.Length);
while(bytesReceived > 0)
{
ProcessFeedback(feedbackPacket);
Array.Clear(feedbackPacket, 0, feedbackPacket.Length);
bytesReceived = stream.Read(feedbackPacket, 0, feedbackPacket.Length);
}
On the sandbox, the above always returned 0 bytesReceived. I ran this on the live host, sending a single notification to a device, removing the app and sending a second. The feedback service work within a second of sending the second request.
One thing I haven't found is how often to call the feedback service however. I'll calling every 10 mins at the moment.
I had the same problem with sandbox environment. Zero tuples return by the feedback service.
I switched to production environment to test my code and everything worked fine. As soon as I uninstalled the app from the device and sent a pair of push notification, this device appeared in the feedback list.
Although I can't say definetly it does not work in sandbox environment, i'm pretty sure about it. In production environment, after uninstalling my application, I sent a few (i guess 3) push notifications. Then feedback service returned results other than zero tuples. (about in ten minutes)
It is not related with this case, but also in order to get notifications and also get feedback results, your network should allow ports that APNS use.
As Zakum said in a comment, the device will not get added to the list if you delete the last push-enabled app.
(And make sure to give it enough time - maybe 10 to 20 minutes.)
From Apple Documentation:
If you remove your app from your device or computer and then send a push notification to it, you would expect to have the device token rejected, and the invalidated device token should appear on the feedback service. However, if this was the last push-enabled app on the device or computer, it will not show up in the feedback service. This is because deleting the last app tears down the persistent connection to the push service before the notice of the deletion can be sent.
You can work around this by leaving at least one push-enabled app on the device or computer in order to keep the persistent connection up. To keep the persistent connection to the production environment up, just install any free push-enabled app from the App Store and you should then be able to delete your app and see it appear in the feedback service.
Recall that each push environment has its own persistent connection. So to keep the persistent connection to the sandbox environment up, install another development push-enabled app.