I am working on a iOS app for food delivery service. And I want to send events from shopkeeper end to customer end and vice-versa.
My app is an iOS app. It is running on iPad 3 at shop end and a user can use iPhone for placing the order. So what is the appropriate method for communication and listening events? For example:
Customer performs a food request. Shopkeeper should be notified immediately.
When shopkeeper accepts it, an acknowledgment should be sent customer side.
Thanks
Related
I'm developing an app for our security company, that needs to receive alarm events in a matter of seconds. So this is the main event flow:
An alarm goes on in one of the buildings
Our server gets that alarm info immediately
Server distributes the alarm message straight to the app of
responsible person
app starts beeping, until the responsible person doesn't interact
with the app and sends a "message received" status back to the server
location tracking of the person is triggered, and data being sent to the server.
I tried using APNs, but the delivery time there $uck$. Since this data should be delivered ASAP, I'm wondering if someone has any clue, how to deliver some data to the iPhone in realtime?
I see PushKit is available, but only for VoIP applications, which this isn't. And the app wont pass the approval in the AppStore if I use that.
Any pointer will be welcome!
Thanks!
Please note that all Push Notification services must go through APNS, and APNS is the fastest method since it is socket-based, for any other way without push notifications, you need to setup a socket listener on your server and handle the socket on the client using SocketIO for example, this is the fastest method for real time interactions.
And you can use a cron job to fetch data by API each X seconds for example, but it is not fast or real-time as socket-based platform.
Currently I have an IOS chat app that runs with firebase. The app is working fine and sending and receiving messages when two users are online. I am using real-time database, however when one of the user is offline (i.e application is killed or even the app is running in background) and the other user is sending a message the messages are not received. Is there is a way where can I know the current state of the user and instead of sending the message I send a notification to notify him that there is a new message.
In some apps like QuizUp, there is a section in Settings (in the app), Push Notifications and the user can tell if he wants to receive APNS for, lets say new friend request, but to turn off for new challenge. How can I achieve that within the app?
For that you can achieved with your back end team. You need to call a web services for stop notification for the particular activity.
You can arrange its screen like setting as you mention and based on your each activity functionality you can stop and active Notification for user.
I don't think that you can be handle from Application side. As par my thinking you just need to call web-services.
I need to update my users for things that happened around their current location while the app is in the background.
To my understanding:
If my server sends a Push Notification to a client, the client would immediately show that message.
I can set up the app so that there is a specific location, with a given radius could fire a message.
So what I want to understand if it is even possible to update my users about things that are new in their locations.
I was thinking of two possible solutions, I am not sure they are possible.
One, I guess if the Push Notifications would allow a function to run prior to its display,
deciding if the message should appear.
For example: something happened in area x,y - The server initiates a message to all devices. Only the devices within range of x,y and a radius z, would show the message to the users.
Maybe the Regional Monitoring service can send a message to my server and my server can then decide if to send a Push Notification back to the client...
For example
The user has entered a defined location, determined by the app. The app sends a message to the server. The server decides if a message is due.
Any ideas? is that even possible?
Filtering push notifications by topic is something you need to do on the server side, not the client side. Apple specifically states not to send messages to users that aren't relevant and you won't be able to block them when the app isn't running. Additionally, if you are using a service to manage your push notifications you don't want to pay for messages that aren't relevant.
So when you register a device into your database, you should register what topics that person is subscribing to (ie. save a list of topics that user is eligible to receive). Then when the event is triggered that generates the push notification only send to devices that are registered to that topic. I believe a number of push platforms have this capability already built in. On UrbanAirship and Azure Notification Hubs you can use their tags feature. Or you can develop it yourself if you do your own push server.
Take a look at Parse. They have this kind of functionality baked right in, just send the push to clients that match a geoPoint query.
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?