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.
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'm working on a messaging app and I have a dilemma about how to send data from server to client.
I'm using a centralized server design, where clients uses NSURLConnection to send messages to the server, the server doesn't keep and manage open sockets and can't send a message for one of the clients. So clients use a timer and query the server every 2 seconds to see if new data is waiting for them.
The problem with this approach is that polling the server every 2 second seem to kill the battery very fast, so I thought maybe instead of clients polling the server, to use APNS* so when the server has some new information ** for the client, the server will send a push notification *** to the client, then the client will fetch the data from the server.
* use APNS - if client allows it, client can of course disable this option. So I will check if push allowed every time the app enter foreground and if not I'll return to the polling approach.
** New information can be anything from text messages to server admin messages. (and there are a lot of admin messages...)
For example, in my app users can see their friends status (online/offline), so if user1 and user2 are friends, and user2 just change his status from online to offline, then server needs to send this new info (admin message = user2_offline) to user1.
*** The push notifications server sends are empty (with no data/sound), it's just a trigger for the client to fetch the new info, so if a push was sent to the client and the client app was close, he will not notice anything. (if the app is running, then it will fetched the new info from server)
Will this approach work with a massive messaging app requiring massive push notification uses?
To be clearer my main concerns are:
1. Is APNS reliable enough that I can use it as my core server-to-client messaging mechanism?
2. Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?
Is APNS reliable enough that I can use it as my core server-to-client messaging mechanism?
NO. Just for the sake of being complete let me iterate over the reasons.
Apple itself disclaims the reliability read the Programming Guide
Also, APNS, has a QoS component which may increase the reliability at the cost of being realtime (For Eg. I can ask APNS to deliver the notification anytime within 4 weeks and retry if devices are not reachable) which is not useful in your case.
As per your requirement, if you send a silent push (a push with no user visible message), it can not be sent as a HIGH priority push which decreases the reliability even further. Here is a relevant quote
"Silent notifications are not meant as a way to keep your app awake in
the background, nor are they meant for high priority updates. APNs
treats silent notifications as low priority and may throttle their
delivery altogether if the total number becomes excessive. The actual
limits are dynamic and can change based on conditions, but try not to
send more than a few notifications per hour."
Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?
Generally, APNS will not have any issues with this in terms of load, but it has throttling in place and they might throttle your notifications, see point 3 above
IMHO, you should look at XMPP as this protocol is designed just use-cases like yours and they have wide community support on all platforms. I will suggest you look at something like https://github.com/robbiehanson/XMPPFramework and setup an XMPP server at your backend which will handle the messaging and presence messages as well as admin messages.
If you have already evaluated XMPP and do not want to go with it, I would suggest you need to put together an intelligent system in iOS App which employs different strategies based on App State, something like following, you can have following strategies
A Realtime Socket based approach -> Establish a permanant socket connection and keep the data in sync as much as possible (This is when your app is running into foreground or background)
The Polling System You talked about in question, which can be utilised when your app is invoked for background fetch/location updates etc.
Use APNS with user visible messaging + custom data, when your server detects that the device does not have active socket and also have not polled for a very long time
I have worked in this area for a while and from my modest experience I think your approach to solve your problems will reach you nowhere. Allow me first to highlight some important facts on the APN characteristics:
APNs are not reliable, they are not 100% guaranteed to reach the client.
As of Apple's documentation, APNs are best effort, so many times they might not reach.
APNs don't hold data inside them, so even if they reach your client app they hold nothing inside them for the app.
APNs are just notifications for the user that something related to your app has occurred, while there message (the text that appears in the Alert Box of the APN) is handled by the iOS and not your app. This is why devices with iOS 4 will display the APN in a different way than devices with iOS 5, it is OS job not your app.
The badge value that appears on your app icon when notifications come is the responsibility of your server, and not the device OS. Put differently, when an APN reaches the device it should come having the new notification count value for your app. The OS won't do anything for this.
Having said that I would like to explain a bit how usually such applications are designed. First, it is not done by URL Connections and the clients don't check the server every period of time. Usually you have a client/server architecture where your client is the app on the device and the server is a real server program that resides on a server machine. The server could be Microsoft (using C# for example) or MAC (using Objective C). The server has a database that it stores information inside it. Some important information (related to your question) is the APN Count Value, the Message that you want to deliver, the state of the client if online or offline.
When a client likes to send something to another client, or when the server wants to send something to a client (or all the client), a check is made to the recipient client to see if he is online or offline. If he is online the message is sent directly, and usually the communications are done on TCP Sockets. If the user is offline then the server will store the message that needs to be sent to the client, increase the APN Count value, send an APN to that recipient. When that recipient becomes online, the server will notice that (because there is establish connection and handshaking) and therefore will fetch all undelivered messages from the database and send them to him...
It is a long process, I hope I was able to explain things a bit to you. In all cases I don't think your way is practical or enables you to reach real work.
I have an iPhone app that uses ASIHTTPRequest to transmit data input by the user to a remote MySQL database via a PHP webservice layer. This works perfectly.
If the user presses the submit button the data should be sent regardless...the problem arises when there is insufficient bandwidth...rather than displaying some uialert to inform the user, I would like to implement some kind of function that constantly 'sniffs' for an internet connection even when the app isn't running (in main view) that ensures that the user only has to press 'submit' once.
How is this possible? Has anyone come across any tutorials/examples of anything similar?
Check out this example application from Apple: Reachability
It'll help you with some code to detect when the connection has changed.
Here's a link about backgrounding tasks. As you'll read, you can request additional time to complete a task, but it won't wait an infinite amount of time until it's complete. Background Tasks
Use the Reachability API in conjunction with a flag of some sort that will perform the desired action once it detects that a connection is available.
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!
I am trying to determine feasibility of certain features required in a (potential) project. I am not (yet) looking for a how-to, just a can-do. I apologize for any vagueness and ignorance: the former due to an NDA that makes Apple's NDA look like GPL, and the latter due to the fact that I have no iPhone or MAC experience.
I do have a solid understanding of objective-c and interface builder (going back to NextStep) and some PDA development experience, so I'll probably understand the answers, even if my questions are naive. I have done a bit of browsing, so I know some buzzwords.
I can't go into detail about the actual project, but I have come up with a lame analogy.
a large number of users in the same room are asked to complete task(s) in the app (say a puzzle)
they are under supervision, but the monitor cannot watch them all closely
they are not allowed to leave the application until done.
they cannot send/receive phone calls or messages during the task.
the monitor receives notification of various steps during the task
the monitor is notified when the task is completed, or the app is exited
the app sends a heartbeat, so the monitor also knows if signal is lost
Jailbreak is not an option.
The app should also work on iPod Touch.
So the things I need to do that seem dicey to me are
can I turn off (or require the user to turn off) phone and sms but still be able send http to my server
can I prevent an app from being switched out (even if, say an alarm app triggers or the phone rings).
failing prevention, can I at least detect any of these events and notify my server.
failing notification, can I record the event for the monitor to check later.
The user will be aware (and in fact welcome) these restrictions. It's a trust issue - the user must not seek help or use a helper app to solve the puzzle, and wants the monitor (and other contestants) to know that he did not. It's feasible for the user to click on an "OK, I understand and approve" screen at the beginning, but not for each communication to the server.
The app would only communicate with a central server (run by my company) - the monitor would not be able to buy the server software, and the url's of the server would not be user (or monitor) modifiable.
Hey! This looks like an app for taking exams. Not what I am doing, but that would be cool too!
EDIT --
I changed the title and am adding a few more parts to the question, based in part on mmc's answer. The App may run in an offline mode that would have to do the following:
So using the exam analogy, the user off line experience would be something like this
Launch App
App download test questions, registers start time, etc.
Turn off phone (if app can't do it by itself)
Disable any app that might interrupt my App (can app do this?)
Resume and Take Test
Indicate test done (or finish last problem).
Turn on phone (if app can't) and restart App (if needed).
App uploads test results and log of any interruptions.
So the question becomes
Am I sure that I at least get to log any interruption I can't prevent
can I know the cause of the interruption (phone answered, alarm launch, user initiated)?
can the user be prevented from modifying the log
can I know what other Apps are running when I start? (to guard against a daemon that occasionally displays a hint or something.
I would still like to run with real time uploads, so a few other ideas come to mind.
If I can reliably detect and record that the phone or another app was used, that might be almost as good as preventing it.
Can the user prevent the phone from ringing even if it's on (eg. call forward + ringer off)
Can my app know if the ringer is off
Same question for sms messaging
If I can't block it, can the user just ignore (silent) call or message and not leave my App. Would my app know that?
Sounds like you might be better off doing away with the phone, and making it exclusive to the iPod Touch.
You've nailed your trouble spots.
There is no way to disable phone functionality, and at the same time maintain network functionality of any type (3G, WiFi, or bluetooth) If you disable the phone operations with Airplane mode, all of them are disabled.
There is no way to prevent the Home button from returning you to Springboard
You can notify a server of a premature app interruption (there is an applicationWillTerminate: method on your app delegate) but is not reliable. If the operation takes too long, your app will be forcibly terminated.
You could write to the local file system that a premature interruption happened, and this would be far more reliable, as this operation would be much faster.