I need to get triggered eventos from pusher, and when the app go the background I don't get them (only the first one).
I have this:
#property(strong, nonatomic) PTPusherPresenceChannel *taxi_channel;
PTPusherPresenceChannel *taxi = [PusherController sharedApp].taxi_channel;
- (void)viewDidLoad
#weakify(self);
[taxi bindToEventNamed:#"client-driver-cancel-service" handleWithBlock:^(PTPusherEvent *event)
{
DDLogDebug(#"%#: %#", event.name, event.data);
#strongify(self);
[self cancelServiceAcepted];
}];
The problem is that I get a single event when get into the background, but after the first I don't get them anymore.
I have implemented the code at https://github.com/pusher/pusher-test-iOS/blob/master/Diagnostics/Code/ClientDisconnectionHandler.h
If the app go the foreground it work fine.
I'm the author of libPusher. I answered your question on Github but I thought I'd post it here as it might be helpful for others.
Unfortunately its not really possible to use Pusher in the background and its not really what it is designed for. Pusher works great for receiving events in realtime while your app is running but to get background notifications, you really need to be looking at using Apple push notifications OR period fetch, depending on whether you'd prefer push or pull.
My suggestion would be:
Use Pusher while your app is in the foreground to receive real-time updates
Use push notifications to send significant events to your app while it is in the background (these should be less frequent) AND/OR
Possibly use background fetch to pull the latest changes/events from your server
Restart listening to events from Pusher when your app resumes in the foreground
Related
I'm working on an internal app that requires to check the server every 10 mins or so when the application enters background. Normally, I can use APNS when new record arrives.
However, this app will completely skip Apple's garden, so no APN and yes private API.
So the question, is there any way for me to set the background fetch interval directly instead of calling the normal application setMinimumBackgroundFetchInterval:
I also welcome other ideas for the same result.
I recommend implement VOIP background mode, because is simply and provide app wakeup every few minutes. Just set Voice over IP in Background Modes and register handler;
Example:
[[UIApplication sharedApplication] setKeepAliveTimeout:600 handler:^{
NSLog(#"Here I do something every 600 seconds");
}];
This method more preferable because can work on old iOS, and timeout is fixed vs background fetch where timeout is calculated by user activity and app usage.
I have a timer related app,that lets the user set timer to different objects.
What I am doing right now -
Right now.I am scheduling a local notification when the timer gets to it's end, and then when the user gets the notification, he needs to open the app so it could process the changes related to this timer.
What I want to achieve -
I have looked on the new iOS7 background modes but could not determine if I can use that to perform those updates to the core data, without opening the app.
So the flow will be:
a timer is coming to it's end.
The user gets a local notification where he needs to permit the operation.
Get the user answer and perform the update while the app is still in the background.
Is that possible with the new API ? Or is it limited to data fetches only ?
If you are you are using Push Notification Using ios 7 new background fetcher api is useful,
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult result))handler
{
}
When a push notification arrives, the system displays the notification
to the user and launches the app in the background (if needed)so that it can call this method. Use this method
to download any data related and store to core data to the push notification. When your method is done, call the block in the handler
parameter.
I'm creating an app that needs to check for data once a day (midnight). I know there is a background fetch mode in iOS7, but from what I know there is no way to force it to update in given time interval. Is there any way to do this and still pass the Appstore review?
Thank you for any suggestions.
There is not real way to do this, since it requires you app to be running in background. background running modes are restricted to audio, VOIP, location and accessory type apps.
What you could do is just check when you last update data in the app when the user launches the app. This way you will only update data when the user starts your app and also only use data when the user is really using the app.
The background fetching will only work if the user is start your app often and iOS will allow you app to do background fetching. iOS will decide when you app is allowed to do a background refresh and you have little influence over the interval.
UIApplicationBackgroundFetchIntervalMinimum
The smallest fetchinterval supported by the system.
Maybe it's not exactly answer you expect but in iOS 7 there is a functionality which allow you to fetch the data every some period of time.
In this scenario iOS intelligently schedules the background fetch events based on your app usage and it helps you save battery life. So this not going to work every 24h but I think you can read the data and if it has been updated refresh the app if not ignore it.
In your Xcode 5 -> Target -> Capabilities turn on Background modes (background fetch).
And in application:didFinishLaunchingWithOptions add:
[[UIApplication sharedApplication] setMinimumBackgroundFetchInterval:UIApplicationBackgroundFetchIntervalMinimum];
This is a method which will be called:
- (void)application:(UIApplication *)application performFetchWithCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
{
}
I'm using both NSWorkspaceDidActivateApplicationNotification and NSWorkspaceDidLaunchApplicationNotification notifications to know which app the user is interacting with.
The problem is that, if an application is just opened and still launching, I first receive a activate notification, and soon afterwards a launch notification.
Is there any way to know within the activate method that the app is still launching and not yet ready for use? (Still bouncing in the dock)
I see that the ichat sample project by apple does not use the above approach and instead only listens to launch notifications. It then uses kAXApplicationActivatedNotification to add an AXObserver to the app. Is this the preferred way? (And also NSRunningApplications to add an observer to all already loaded apps).
I wanted to keep using just plain simple NSNotifications because I think it may be less memory intensive. (No need to keep an observer around for each and every app loaded).
check the NSRunningApplication object passed in the userinfo of the NSWorkspaceDidActivateApplicationNotification
NSRunningApplication *app = [note.userInfo objectForKey:NSWorkspaceApplicationKey];
if(app.isFinishedLaunching)
NSLog(#"up");
I'm using Apple's view controllers quite alot in my app (like MFMessageComposeViewController and ABPeoplePickerNavigationController). So when I receive a notification (Local or Remote notification) how would I deal with it the most elegant way since I can not interact (send messages) to Apple's view controllers.
My assumption is that if the user is actively using the app and in i.e MFMessageComposeViewController he does not want to get disturbed/interrupted with what he is doing. But if it was me I would get a bit confused if I was doing something and I would hear boing sound (from the notification) and then nothing more happened.
So would a reasonable way to handle this do let the user finish doing his task in whatever Apple view controller he is inside and then display the notification for the user?
Or dismiss the Apple view controller and handle the notifaction and then put the user back in the Apple view controller?
I'm not quite sure I understood you exactly correct, but to me it sound like you want to do something like this:
If the user is composing a message in your app and there is an incoming notification, lets say a push notification from the facebook app, you want to handle this event somehow in your app by letting your MFMessageComposerViewController do something.
As answer to this request I would like to state the following:
You should be able to send messages to your MFMessageComposerViewController if you extend this class (i.e. create a class called MyMessageComposerController and let it extend the standard controller, and do whatever you need there)
However, you can't really do anything about the push notification, it comes from another app and this functionality is built into iOS, you can not make the push arrive later when the user is finished typing, it will always arrive and the user will always be the one to decide if he/she should keep typing or look at the notification. The only thing you can do is to make sure that your app saves everything that the user has typed so that he/she can continue typing when returning to your app.
Assuming you don't just want to display an AlertView or something similarly modal over the message composer, I would do something like the following:
assign a MFMessageComposeViewControllerDelegate to the composer.
show the composer as usual.
queue/remember the notifications received while the composer is in play (through the normal application:didReceive{Local|Remote}Notification: messages)
when the composer is closed, the delegate receives its messageComposeViewController:didFinishWithResult: message.
Do... whatever... with the stored/queued notifications.
Whether you delay responding to the notification until the user is finished with the composition or interrupt them is a trickier situation. If it's a relatively unimportant notification or notifications that are frequent, I'd tend towards the queue/delay approach. But for "important" notifications, I'd have no problems in interrupting the user. Of course, that just moves the question to what determines importance. And that is very much dependent on the app.