I'm trying to mimic a pager with my app by sending push notifications to the user until he or she responds. My thought was to send a push every few seconds and play the default sound on arrival. Not perfect, but better than nothing.
It's working all right. However, I am finding that the sound starts to stutter/interrupt a bit after a few notifications have been sent -- as if it's trying to play the sound more than once. This happens even if I only send the push every 10 seconds. I just tested it at 20 second intervals and even then it starts to sound interrupted after about 10 times.
Any idea how to resolve this so each message plays the sound crisply?
p.s. Testing performed on an iPad.
This is an answer, in the sense I'm going to advise you don't do this. I'm pretty sure sending push notifications every few seconds until the user responds violates section 2 of the Apple Push Notification guidelines (it's appendix A of you Apple developer agreement). You probably won't find a satisfactory answer here for two reasons:
Nobody will have done it before, because it probably breaks the developer agreement
Apple don't guarantee order or delivery of push notifications, and the speed at which they are delivered depends upon the device's network and connection speed.
I got it working. Turns out in my attempt to keep the connection open per Apple's guideline I was mistakenly reusing my MemoryStream object.
The retry interval will be user definable so I hope this won't break any of Apple's rules.
Thanks for your input!
Related
I need that my app will send some data to server every six hours for example. Purpose is that it will send request to server even when app in background. As I know only thinks GPS, Music, Push Notifications work on background. Also, as I know UIApplication method beginBackgroundTaskWithExpirationHandler: works not for a long time after app goes on background. Guys, anybody have idea how to implement this? Thanks a lot!
It's simply not possible within the limits of the current iOS SDK. The only kind of apps that can update their content regularly from the background are Newsstand apps and for them, the interval is 24 hours AFAIK and the entire updating process is largely triggered by Apple.
Unless your app falls into one of the categories you mention, the short answer is you can't. The only exception is for Newsstand apps.
But: what data would you be sending to the server if your app isn't running? If you send data to the server when something happens then the server will always be up-to-date. If the user isn't running the app then, by definition, nothing has happened and the server is still "in sync" with the client. (Yes, this potentially makes the server harder to code.)
I have followed an example tutorial online for integrating in-app purchases in to my app. It is all working fine purchasing and unlocking the extra content. However, the notification that gets posted for confirming the purchase can take from 4-9 seconds to appear. This does not make for a very consistent user experience and makes the app appear slow.
Has anyone else had the same problem as this or know of a fix for it?
The long length of time and inconsistency is probably originating from the following:
When the user makes a purchase network messages will be sent to apples server - the length of time this will take will be inconsistent depending on the distance from the server, the amount of nodes the message passes through and the quality of the connections you are using.
When the message reaches apples server it will need to be processed and a response generated - the length of this time will be inconsistent depending on the load currently affecting the server.
A confirmation then will be transmitted back over the network - same rules apply as for the outgoing message.
The device upon receiving the confirmation will display the alert to the user.
Unless you are able to make changes to the network which the message travels upon or can improve apples servers response times you will not be able to reduce the time or inconsistency.
A "solution" would be to display an activity indicator with a helpful message to the user explaining what is happening, if you plan on doing this recommend the following utility DSActivityView. Its easy to use and quick to hook up and has been useful for me when faced with similar problems.
I'm looking for some way to let my app play a sound at a specific time while it's in the background (IOS4 multitasking). Currently, I use local notifications for that which works quite well, except for:
the sound will not be played if the phone is muted
the 30 second playback limit
I saw there's setKeepAliveTimeout:handler: but it's only available for voip-apps and since that's not the purpose of my app, I guess Apple would reject it because of this. I also saw a solution where an "empty" sound is being played until it's time has been reached, but - ignoring that this is not a very elegant way, anyways - I read that this, too, might get the app rejected.
Since there are a few alarm clock apps that do just what I'm looking for, I wonder how they implemented this functionality.
Thanks for any hints in advance!
If you seek a solution that will be approved by Apple, you're right you can't use the setKeepAliveTimeout:handler and even if you could - you can't set the timeout to something that's smaller than 600 seconds, so I guess it won't be of a great use anyway (besides that It's not guaranteed to fire the event even remotely close to the timeout you specified. For example, I set it to 600 seconds and some event fired as early as 360 seconds..).
About playing the silent sound, except the waste of battery, if you're app has legitimate use for background audio (if you're implementing an alarm clock, that's pretty obvious), I don't see a reason for your app to be rejected, as long as you don't try to use other background features (GPS signal, VoIP handlers, etc).
Here's one example app that used this "feature" for their benefit:
http://tapbots.com/blog/pastebot/pastebot-music-in-background
About other methods, you can look in this thread:
How do I start playing audio when in silent mode & locked in iOS 6?
On a personal note, it's not very easy to cope with background policies of Apple. Me and my company had (have?) a hard time just to maintain a simple VoIP connection due to all the limitations. My best advice is try to do as less as possible in the background as you can. If the UILocalNotificaion solution suits you, you'll probably should stick to it and live with the limitations.
I need to develop an enterprise app that monitors the network traffic. Basically it detects if the user is in wi-fi or cellular data and save the amount of bytes was sent and received in a period of time.
I saw an App at the AppStore that do exactly this job.
Detecting wi-fi or cellular data is quite simple using the Reachability Sample provided by Apple.
My problem is to keep monitoring the bytes sent and received while the app is in background.
As it is an enterprise App, I used UIBackgroundModes "voip" to avoid the app to be terminated.
I also installed the setKeepAliveTimeout method and I'm able to see the logs each 10 minutes, BUT only for 10 seconds after the method runs. I mean, setKeepAliveTimeout brings my App to run a Timer for 10 seconds each 1o minutes.
I'm thinking wether or not a task in background is the best solution for my problem.
I'll appreciate any comments.
EDIT: Ok guys. Thats the perfect way to do it.
First of all you must read this:
http://www.christian-fries.de/blog/files/tag-ios.html
I tried this and it works really fine.
All we need to do is to create a second thread detached from the main one. This way we have a continuos threading running forever. You must see the GCD docs at Apple's website also.
Second thing you should consider for an enterprise App is to set it up as a voip App, this way iOS will put your App running even after a reboot. It's a special behavior iOS has to keep voip Apps running.
Thats it guys.
I hope it can help you.
We dont have access to this data. There is no way to measure traffic.
The app you saw made an estimation (eg. 1mb/min) and after applicationWillEnterForeground. then you calc time x estimated-traffic and there we go.
Unfortunately there is no way to measure,
so I did a traffic-reset in settings and then i streamed exactly 1 min music. after a few repetitions I had my results. The problem is, that this works only fine with static traffic-processes like audio or video.
hope could help
endo
EDIT: look answer below!
I'm seeing some very strange behaviour from the Apple Push Notification Servers when the recipient iPhone is off. Here is my scenario:
-Send push notification A to Apple. Within a few seconds a push notification popup gets displayed as expected on the iPhone.
-Send blank notification to Apple to cancel previous one (the previous notification is pointless after about 10 seconds, that's why I want to get rid of it). Nothing displayed on the iPhone.
-Turn OFF iPhone completely (not asleep, it is powered down).
-Send push notification B to Apple. Wait 10 seconds.
-Send blank notification to Apple to cancel previous one. Wait 10 seconds.
-Send push notification C to Apple. Wait 10 seconds.
-Send blank notification to Apple to cancel previous one. Wait 30 seconds.
-Turn ON iPhone.
-After about 60 seconds a push notification popup is displayed for notification B on the iPhone.
-Notification C never seems to arrive.
This is very strange! From reading the Apple docs I was expecting only the latest push notification to be sent. I was hoping my blank notification would be sent, I certainly wasn't expecting the oldest unsent push notification to be sent!
The Apple docs say:
Apple Push Notification Service includes a default Quality of Service (QoS) component that performs a store-and-forward function. If APNS attempts to deliver a notification but the device is offline, the QoS stores the notification. It retains only one notification per application on a device: the last notification received from a provider for that application. When the offline device later reconnects, the QoS forwards the stored notification to the device. The QoS retains a notification for a limited period before deleting it.
Has anybody seen this behaviour? Am I just hitting some sort of timing window bug? What should happen?
Updates:
-If I turn the phone off and wait 5 to 15 minutes before sending any push notifications then this problem doesn't occur. In this case when I turn the phone on I don't see any notification popup, although I'm not sure if this is a result of Apple dropping the notification, or their 'queue' working correctly (i.e. holding the newest blank notification instead of the first one with the popup).
-I will investigate further by putting an APNsLogging.mobileconfig onto the iPhone to see what notifications it got.
-Turning wifi off doesn't seem to change the results.
-I have raised a bug report with Apple for this scenario.
You may want to check for this behavior across both the cellular and WiFi networks. There's a lot of strange behavior when the phone is on WiFi, especially if there are multiple NAT router involved, i.e. in a large corporation where there's a main router and per-floor WiFi routers, or in a home where you have multiple routers used to extend the range. But on cell it's been pretty solid.
Also, the 10-second cancellation delay may be cutting it too close. They don't guarantee timely delivery and I've gotten lags of as much as 3 minutes on the production server after queuing off a push request. You may want to plan for system congestion.
Either way, it sounds like it might be worthy of a bugreporter report.
For the record, I raised this as bug ID #7349660 with Apple on 29th Oct (https://bugreport.apple.com), then gave them the additional diagnostics they wanted on 30th Oct.
No response from Apple since then, so I am assuming this is probably just low on their priority list, which is fair enough as it is quite a small timing window where the problem can occur (which I didn't realize when I first opened this question).
In apple's document it is said that it can cache the push notification up to 30 days.so u may get push once you switch on your iphone (provided you are having interconnection)
How soon was C sent after B? It seems like it may be a bug where there's some kind of timeout server side, and they accidentally keep B if C was sent too soon after...
If you have a good test example (and this seems like a good test) I would file a Radar report on this.