I want to develop an app, but before I actually start developing, I've been doing some research so that i can be sure it's going to work in the way I'd like to do this.
You can imagine the app as a kind of news app, where the user can indicate whether he wants to receive push notifications, and may also indicate that he only wants to receive a push notification if it is in X distance from his current location.
And this is probally a problem on IOS, On android it would be no problem if a push notification came in to read the current position of the user and settings and then show the push notification or not.
As far as I've read this is a problem on iOS, the system receives the push and the app can not respond to it unless the user clicks on it.
Theres also another problem about closing an app on IOS, ideally a app should not be closed (swiped out) by the user because this would be a force close on IOS.
From ive seen most users still swipe out apps, and this would mean that my app cannot run background tasks anymore.
This is what i thougt about:
Send Silent push, app download data on the background -> Check if this meets the user settings, if so show a local notification. (30 sec time to handle, but do not know if it is possible to throw a local push here too.)
The app sends data on the background over the user's current position before sending a push, the server checks for which apps it should be sent (actually no solution, too much data usage as it may be that the user is only one Specific location, need a good server if the app is used on thousands of devices.).
Does anyone have any idea how to handle this problem?
Related
Since push notifications may not be delivered sometimes (you can lose a few of them), you can not run code after the iPhone is turned on to check if there is new information available from the server, and you can not run code if your iOS App is closed... What can you do if you want to be as more accurate as possible in for example a Chat App in iOS?
I mean, inform the user as faster as possible that he has new info available. Comparisons: WhatsApp is updated without any delay.
You can do background fetch if your App is in background. But if the App is closed and you miss a push, it's not going to be up to date until the next push arrives or user opens the App. The same with silent notifications. If the app is terminated by the user, you are not going to receive it. Is there any way to solve it? It must be because other Apps do it... If there is any "private and secret" API that they are using (I read about this answer when no one know how to do that)... Is there any way to apply to use it?
UPDATE:
I'm using push notifications. The goal is to fix when a push doesn't arrive. Example: User A send chat message to user B. User B doesn't have the App open. The system lose the push. User B is not going to receive the message until he open the App.
Push notifications seems to be your only way even if you do loose a few of them, which I don't know how you would since they are pushed to apples secure server... but what do I know. As long as the user turns on the push notifications you should be fine. They may be delayed due to apples way of handling them. Honestly push seems to be the future, having your app constantly every minute or two check for new messages is a huge battery water in conjunction with normal texting apps. Your app should provide the best live data but since apple restricts to push notifications when the app is off or not running just stick to push notifications and only push major events to the user. I believe you can set up a job scheduler using quartz or schedulator to setup your server to push notifications to your app.
I'm trying to make an App that's exactly like WhatsApp, so far the biggest limitation is that when a user re-opens the App after a while, and goes to a Conversation View, new Messages that were sent during the time the App was in Background/Suspended or Terminated states have to be recovered from a Server (API), and this causes a potential delay for new messages showing up in the Conversation View.
How can I achieve permanent Sync of an App with a server API? I'm kind of sure apps like WhatsApp manage to do this, because Messages never appear to be downloaded whenever you re-open the App after a while, right?
What is the right way to sort of Mimic this type of behavior? I really want to learn how to perform this kind of "advanced" synching and I don't know where to get started. Again, my goal is to try to avoid server-downloads of new Messages when a user re-enters a Conversation Viewfor example (because that would be bad UX)
Thanks in advance!
Your app will need push notifications. This is a must have for apps like this.
On the server, when you know that there are new messages, send a push notification to the app. This will let the app know that there are messages to read. At this point the app can badge the app icon, pop an alert and show on the notification screen. The user controls how notifications appear.
Details about notifications here:
https://developer.apple.com/notifications/
Your app can load all messages when it gets the notification.
iOS apps do have some limited options for background processes: https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
a simple question: is it possible to get a message, notification or similar when the internet connection is available when app is killed or not running?
For my purpose, I need a way to synchronize all my notifications because APNs can send only the last message.
EDIT:
I'm wondering how some apps (e.g. whatsapp) are able to sync their notifications when the internet connection is up. If I kill whatsapp, I can receive multiple notification when internet connection is reachable, but the APNS server provides only last message and, for this case, I'm not able to send silent notification. If I should develop a chat application, what are the best practices to work with Apple notifications?
If you send a push notification with a title, text, sound and/or badge property while the app is suspended (was killed / force closed), the device will still receive it, e.g. will show the text as a notification, play a sound and/or change the badge count.
However, your app won't be launched or woken up in the background in this case, so you have no way to handle the notification before the user taps on it. (See this question:
Will iOS launch my app into the background if it was force-quit by the user?)
So if the app was force closed by the user, your only option is to send a notification to be displayed as it is and if the device is offline, only the last notification will be received and displayed by the device.
For more control, you could use silent push notifications to implement "push-to-sync". In this case, the push notification only signals that there is new data to be fetched. The app (if not force closed) loads the data from the server then and triggers local notifications with the right data in the right order. But this won't work, if the app was force closed.
Apple push notifications have a lot of restrictions, so you won't be able to implement a perfect solution. In my opinion, it's fine if the user gets only the last notification when the device gets online after being offline for a while. At least he is informed that there is a new message and after opening the app, he can see the other new messages too. For the "push-to-sync" scenario, I would say that the user has no right to expect that the app works as desired, if he force-quits it.
Push notifications were never intended to be used in the way they are used by a lot of apps by now. E.g. they shouldn't contain sensitive data such as a chat message. They were intended to inform the user that there is new data for the app, so he can launch it to see the new data. E.g. instead of sending the actual chat message text a push notification should just contain the text "You have a new message". Then, you don't have the problem you described. Of course this is a terrible solution in terms of usability.
I would like to know whether there is an alternative different than what I am thinking so far. I have an ios app, which gets data from my server, when the user clicks refresh button or so.
Now, I want to send data from server to the app - for example when an event started so as to update the label on that event.
I have thought of the following :
Use background fetch from my IOS app and connect to the server every an interval
Send a push notification and make the user open the app, and the app calls refresh
Is there any other way? Is it possible that server will send the data (just like a push notification) but without the notification to be visible, without firing the app, I just want to change some of its data - an approach similar to the Google Cloud Messaging for Android.
To visualise what I am saying, if you have used LiveScores app, it updates for example the minute of a live match - I want something similar.
I guess I need to follow approach 1, with background fetch (which became more effective in ios7) but just out of curiosity if there is any other solution out there.
Thanks
Under ios7+ you can do silent pushes (which aren't displayed) [see a nice tutorial — hayageek.com: iOS Silent Push notifications]
Under ios6 and below you are of of luck
A very simple task that took me 30 minutes to implement on an android.
A web server sends a message to device. Without user interaction a receipt is sent back. User understands that this is a desired behavior. When user opens the app he/she can send additional acknowledgement.
My understanding is that as long as I am not using location service I cannot run app in background continuously (or periodically). Push notifications will require user interaction, otherwise it's just a badge and a message.
This seems like a trivial problem but makes my head hurt and want me to give up.
Is Enterprise subscription the only way for me to get the app to our company users?
First you need to ask user permission to send PUSH notifications. Once the user agrees for you to send PUSH notifications to his device, you need to get the device ID and store it in your servers. This is the FIRST phase of PUSH-NOTIFICATION
In the next phase (SECOND phase), lets say you want to notify the user about something, what you do is get all deviceIDs for that user (he might have registered more than 1 iOS device) and send some X message to his device(s) leveraging apple's PUSH infrastructure. You need to pass the deviceID's to Apple (along with a bunch of other stuff) as this is how it identifies which device gets this X message.
Also initially while registering for PUSH, you need to write a little code to configure how your PUSH notification will look like. Would it have SOUND, BADGE, MESSAGE etc.
For all this to happen you as a app developer do not need to concern whether you app is ACTIVE or not. iOS takes care of it. After the initial PUSH registration the user too is not involved. You dont need to run your app in the background nor do you need to register for continuous location updates.
Have I understood your question correctly?