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. :-)
Related
I am writing a messaging app in Swift where people can chat similar to how text messages or other popular chat apps work. The supporting API is on AWS, written in C#.
There are some points of interest here:
Hoping to avoid third party stuff like Firebase, etc, but open to listening to advice
Alert notifications are not desired for now - no popups, banners, etc. Simply want to show message bubbles arrive in real time on one viewcontroller - if and only if the person is staring at the message screen. If they're somewhere else on the app, nothing happens.
We don't want to prompt the user to ask them if they're OK with this app sending notifications because we're not sending them banners or anything visual, aside from a new chat arriving. Is that a requirement with APNS? I feel like this means someone can say NO, and then we have no way to update the chat app in real time, which won't fly.
I assume a simple approach would be some sort of timer/loop that runs from the message viewcontroller, where every second or two it hits the API and asks if there are new messages, but that seems inherently wrong to me - the app must be robust, and there could be thousands or hundreds of thousands of people using this - that's a lot of API requests, and in many cases there could be no new messages, thus a wasted call. This is clearly not the way to go, correct?
Question # 1
I was thinking, then, that I should use APNS, however am not sure if it requires you to prompt the user to ask them for permission to receive anything from Apple? Again my concern is the chat bubbles should come in at real time and don't want to give the user the ability to somehow not see these (breaking the app)
If APNS is the way to go, and I must prompt them, then I assume the flow is I will gather my device ids (created in appdelegate, saved in my C# db, and associated to each message thread) and whenever someone types a message, it goes to my API, I save it in the message database table, and then I send out a message to APNS to everyone's device id.
Apple queues this up, and sends to everyone, and if they're on the screen, then the message comes in.
Is this how I should leverage APNS to achieve what I want?
Question # 2 I've seen others recommend using SNS (in conjunction with APNS) however I don't understand why. Doesn't APNS both act as a proper queue, as well as a notification service, thus invalidating the need to use AWS's SNS/SQS at all? It seems redundant to me but maybe I just don't understand the idea behind why you need both technologies.
Appreciate anyone's time in advance if they can shed some light on this for me!
Thanks!
Question 1
Even if you're using WebSockets (As #stevenpcurtis mentioned), you still need to inform user about the fact that user received message when application is in background/suspended. And yes, you must "force" your user to enable notifications for the application and explain why he needs it. Empirically, if user installs messenger, he understands what are notifications used for and why he enables it.
Question 2
From the mobile perspective SNS will still deliver Push notifications when user receives notification while the application is in background or suspended. From the backend perspective you can use SNS.
Conclusion:
From the mobile perspective you have 2 modes:
Application is active - it's generally up to you how to receive messages. (Web Sockets, pushes, e.t.c.)
Application is in the background or is suspended: You need a tool to inform user about changes without having a control on application. This is the job for Push Notification Service. The way you will send pushes from the backend is up to you.
You can also check This question to get some more information.
I am thinking to make my own app like Find My iPhone app . But I am confused that whether apple allow developers to have access to play with the security or is there such Apple API's that can help us to include features as in the above app. Any suggestions?
Well I just can't comment because of low reputation. But people must give a reason to down-grade a question. Its quite a valid question.
Creating an app like this is semi possible. Due to the fact that you are not allowed to keep running in the background, except for certain special cases. Such as Music or a guidance app (navigation apps)
Your app can register to receive updates from the GPS location and process them.
The problem is it will use your gps all the time.
The find my iphone app is a combination of wifi location/sim card location/gps location.
It uses a combination of all these items which it has to keep track of your location as close as possible. Now back to your question, the fact that you cannot keep running in the background, will mean the app needs to stay open all the time (open I mean running, not necessarily onscreen). Not like the application from apple itself, which of course is allowed to go outside these developer restrictions.
The APIs exist for you to create the main functionality of this app. Core Location and APNS
When use A is looking for the location of user B, A would tell a server that it needs user B's location.
A push notification could fire up user B's app, at which point...
User B's location services would kick in, in the background,
Send this information to your server
Then update user A with another push notification.
We are going to create a life saving app. This app is made for those critical and emergency conditions when someone fall ill suddenly.
As this application is for emergency case, we need to make this app accessible even when the phone is locked.
Is there any way including public or private API, we can implement the feature?
Thanks,
iOS isn't designed to be a life saver, it's designed to make income for Apple (to be crude, because many things you think would be possible just is not)
There is also the reason with battery life, memory usage etc that needs to be restricted in a mobile environment where power is not unlimited.
You could however look at things like Push Notifications (read the docs). The app won't be "accessible" in the sense, but you can have a chance users will launch the app when you ask them to - they will actively have to push a "ok open the app" button.
I would suggestnlooking into gestures to perhaps overide the lock for your apps usage. Whether it gets approved by Apple is another story.
I'm writing an iPhone app for a client, and they have requested a feature whereby the app "wakes up" at certain times during the day to display a message to the user.
I'm well aware that I can't have the application run in the background and simply move to the foreground at the appropriate time (short of requiring jailbreaking, which isn't really an option for a commercial app). What I'd ideally like would be to simply have the system schedule the application to be run at a particular time of day.
As far as I can tell, the only way to achieve this seems to be to implement push notifications and have a server send the app a message at the appropriate time of day. But this is really ugly and undesirable for several reasons:
It requires a constant internet connection on the user's phone (something that I can't really assume)
It places a large burden on the server in having to keep track of these times (which may be different for each user)
Its just a generally crappy workaround - that's not what push messages are designed for, a dedicated scheduler seems like a much better option.
Does anyone know of a better alternative?
Currently, this is the only option. File a bug with Apple requesting 'local notifications' (a term I've heard their engineers use in relation to this problem.) Ideally, they would work just as push notifications work now, but not require any net connection. Sorry!
Now you can use local notification instead of push notification. Available in iOS 4.0.
I have an app that I am working on, and part of its main functionality is to alert the user to do something. So even though they aren't in the app, I want to be able to pop up an alert from the app, reminding them to do something. Is that allowed with the iPhone sdk? Maybe it isn't even a big deal at all, but for some reason I was thinking that it would require background processes or something that may or may not be possible. Anyone who has any thoughts about how this would be implemented would be greatly appreciated. Thanks!
Check out the Apple documentation on push notifications. Short of jailbreaking and distributing your app outside the App Store, there is no way to run background processes at this time.
It is allowed through notifications, though you will need a server to actually send the notifications to the user. There is no limit to the number you can send, although the user may very well decide to shut off notifications or delete your app altogether if you are too spastic with them. Make very sure the user understands the notification volume they will receive and agrees to it...
The way the system works is the user gets a notification message (and/or sound) and can decide to open your app or not, as the time of notification.