I think I must be missing something. I have an app that loads table reservations on an iPad and in order to stay up to date, I refresh the main-page-ist every 15 seconds.
Instead I want to refresh the page only when there is a change. I want it to work like a push notification that tells my app that there has to be a change and that it needs to connect to the server and update, but some users are turning push notification off and i have no control over that. There must be a better solution I'm missing right here.
How are messaging apps doing this. How do viber, whatsApp facebook messengers know that there is a new message and show it immediately. I don't think they connect to the server every seconds... or do they?
I think, Silent Push Notification is the best solution for your case.
You can still catch the information in the background even user does not permit push notifications.
What you are doing is common but not advisable these days. You want to push, not pull. What do I mean? How often someone reserves a new table is random, so it could be 5 seconds or every 5 hours. In your case, if you refresh every 15 seconds it could be killing the battery and gobbling up data unnecessarily.
The better way is for you to set up a push server that, when a table is booked, your push server sends a push notification to your app. This way, whether instead of asking all the time "hey, any reservations?" your server tells you when a booking event happens.
Of course this requires more work on your part, but you will run into the same issue over and over again, so it's worth looking into how to do this.
If you're at a larger company, and only doing front end, you need to have the backend engineers build a push server for you.
This is how What's app and other apps notify you when you have a message.
Related
I have a cool flutter app which is used to track staff attendance. A user can check-in and check out when they start/stop working and the app record that event, calculate the number of hours worked and send a weekly summary to the manager of the staff expected wages. The current problem is that some staff members forget to check out (everyone is ok with check-in) so we don’t have good numbers and we need to manually change the attendance. I would like to add something to remember them to check out, and I am looking for creative ideas to do so. My objective is to make something very affordable.
So far I thought about two options:
to use geolocation and track when staff get in/out of a certain location and log it as check-in and check out
to set a timer when they start the shift and send a local notification if after xx hours they have not done the checkout
Geolocation seems to be the best because I can even automate the checkin/check out and do it in the backend but it will consme lots of resources in the client because I would need to check their location every while even when their at at home or on holiday...
The timer has some limits and still, I would need to manage background tasks that are complex as well as imprecise checkout depengin on when the notification goes out.
Do you have any suggestions on anything simple to implement?
I would suggest the second option.
A simple scheduler which would look for all the employees who are checked in for more than x number of hours and then throw a clickable notification to checkout. It would be an easy and clean solution. However, it has several limitations as an employee might leave early but checkout later.
In my opinion, Your most clean solution would be to have an RFID/NFC check which automatically registers as a user checks out from the building.
Another thing that can be done if your employees are working mostly on their computers. There can be a browser extension or a web app which will clock in the time they are working on their laptops. Once they close it they will be automatically checked out.
I'm currently creating an iOS application in Swift that fetches data from a third party API and then displaying it on the screen.
One of the features includes enabling push notification so that the user gets a push notification if there's a change in the API data.
However, I'm struggling to figure out how to implement the push notification side of it so that I can constantly monitor the API data and then send out a push notification when there's a change in the data.
Can someone point me in the right direction on how to do this? I've previously used Firebase to implement push notifications but the push was triggered from a user action. I was wondering whether there's something similar I can utilise in Firebase or if there's any other recommendations?
Thank you!
You may be able to use cloud functions. If you're monitoring the data client side you can perhaps make a call to a cloud function to send a push notification.
Or you may want to look into local notifications. I'm not sure exactly what you're trying to accomplish so it's tough to really say, but as far as a direction goes I would recommend checking out cloud functions and local notifications to see if either one solves your needs.
Edit:
Now that I know more what you're looking for I would check out this article here. It will explain about Background App Refresh. Here's an excerpt from the article.
When the system calls your app delegate’s application(_:performFetchWithCompletionHandler:) method, configure a URLSession object to download any new data. The system waits until network and power conditions are good, so you should be able to retrieve adequate amounts of data quickly. When you finish updating your app, call the completion handler and provide an accurate result of your outcome, which can include saying that no new data was available.
So in the application(_:performFetchWithCompletionHandler:) method you would want to:
Download the new data
Compare it to old data and see if there's been a change
And then probably I would just display a Local Notification to the user.
I think that would be the easiest way with your current architecture and without having to write any server side code.
I have a lobby in which I want the users to be in sync. So when a user turns off his internet while the app is running, he should be removed. I know Firebase does not support server side coding, so the coding needs to be client side. The answers from How to delete firebase data after "n" days and Delete firebase data older than 2 hours do not answer this question since they expect that the user is online and they have an internet connection. So my question is if is possible to delete users when they got no internet? I thought maybe it is an idea to let the users update a value every 5 seconds, and when that update is not done, the other users in that lobby remove the player. This way is not good, since every player needs to retrieve and upload alot of data every 5 seconds. What is the best way to solve this?
Edit: to make it short, lets say each user has an image. The image should be green when the user is connected, and grey when disconnected.
Edit 2: after thinking it over, it is really hard to accurate present the connected users on a client-side server. That is why, if nobody has a different solution, I should add another server which can execute server-side codes. Because of the larges amount of servers, I would like to know which server I should use. The server should run a simple function which only checks if the users are connected or disconnected and can communicate with Firebase. If I am correct it should look like this:
But the server also needs to communicate with the users directly. I have absoluty no idea where to start.
If I'm not completely wrong, you should be able to use onDisconnect.
From the Firebase, documentation:
How onDisconnect:Works:
When an onDisconnect() operation is established, it lives on the Firebase Realtime Database server. The server checks security to make sure the user can perform the write event requested, and informs the client if it is invalid. The server then monitors the connection. If at any point it times out, or is actively closed by the client, the server checks security a second time (to make sure the operation is still valid) and then invokes the event.
In app in production I'm using onDisconnectRemoveValue, and when I close the app, the user removes himself from the lobby. Not sure how it works when you turn the device in airplane mode, but from the documentation it seems there should be no problem.
One thing: when you test it better do it on real device, the simulator have issues with turning it off and on, at least the on I have installed.
Edit: So i checked the onDisconnect when you put the device on airplane mode and it works! The question is, that it removes the user in about a 1:30 min, approximately, so if you read the documentation or ask the support, you may be (and only may be) able to find a way to set the time you want.
This will be my first iOS app with any bit of complexity. I'd like to outline the components and structure to get some feedback before I dive into attempting it.
From the user's perspective, the app monitors the water level of a local lake and receives push notifications when the water level changes a user-specified amount. I think using Parse will be easiest to manage user data and I will attempt a Node.js server-side component on Nodester (I know some basic JS and figure its an good up and coming language to get familiar with). Here's how I see it working...
The user creates an account on the device and specifies a lakeLevelChange amount in which they will receive a push notification. The user's data is pushed to Parse's data mgt.
The server side component will run this program 3-6 times a day:
Pulls a currentLakeLevel via HTTP request
Pulls user data from Parse
Compares the currentLakeLevel to the user specified lakeLevelChange
If the difference is => lakeLevelChange, a push notification HTTP Post request is sent, per user which their specified condition is met
Parse receives POST request and sends a push notification to APNS server
Client receives push notification
It actually doesn't sound terribly complex when its typed out. Is this the proper way of structuring this functionality? Am I missing anything? Suggestions are greatly appreciated!
Bit of a logic problem:
The server side component will run this program 3-6 times a day:
Pulls a currentLakeLevel via HTTP request.
Pulls user data from Parse
Compares the currentLakeLevel to the user specified lakeLevelChange
If the difference is => lakeLevelChange, a push notification HTTP Post request is sent, per user which their specified condition is met
You actually need to store the level at last alert for each user, too. Otherwise incremental changes could creep over your users' threshhold and never trigger an alert.
Imagine if I said I want to be alerted when the level has changed by 6 inches. You then record seven events in which the level rises by an inch each time. At no point did you observe more than 6 inches of change, but the total change is over my threshold for notification, and I probably meant to have you notify me about that.
So when you fire an alert, you need to store the current level, and then on each change event, you compare that to the last level you notified them about.
You're missing the unhappy path. It's the path programmers never travel while programs always travel. Nothing goes the way we plan it so we have to plan for failures. Ask yourself questions like, "What happens when the server powers down for maintenance or outages and misses one or all of its 3-6 scheduled runs?" "Should the missed executions queue up and send out a bunch of missed notifications?" "What happens when the user changes what they specified as lakeLevelChange but the radio is out and/or the server request cannot complete?" "What happens when Parse gets garbage data in or produces garbage date?" Asking just a few of these will steer you towards an optimal design.
I'd like to have something in my app that is just like Twitter but not Twitter. Basically it will be a place people can submit messages and do not need an account. They only way they can submit is through the app. I want other app users to see the submitted messages nearly immediate. I believe push notification can do that sort of work but do I need push notification for this? How does Twitter do it?
-- EDIT --
After reading some of the responses, push might be what I need. People will be submitting messages to my server often. If someone is watching the feed, they might see one new message per minute depending on the query they are using. I'm thinking to go with a MySQL database, (which allows switching to cheaper non Windows servers w/o much hassle) and push notification. Are there any reasons those won't work for my scenario?
You only need push notification if you want the app to be able to receive new messages while closed.
Here's a rough description of one way to do this:
Your app sends a message via HTTP Post to your server.
Your server stores the message in a database, using the iPhones unique ID as an identifier.
Your app connects to the server frequently, asking for new messages.
If there are any new ones, the server hands the message to the app, which displays it.
This is approximately what twitter/iphone twitter apps do.
Your choices are fairly binary:
Use push notification
Use Polling
With Push Notification:
You control when you contact your users... Heavy Load means you can slow updates down to avoid taxing your infrastructure
Contrariwise, you have to push to clients that may not even be there anymore (And thus may need some sort of register model), high load may mean that clients don't get immediate update
You can leverage things like Amazon's EC2 to give you more processing power
Unless you're out of capacity, users are almost certain to be receiving updates as they happen
To pick up messages missed while offline, the SERVER needs to know what message was last successfully received, store older messages and forward many all at once
If you choose to use polling:
You must have a stable address to be polled
You need the ability to have lots of quick query connections checking for new data, then returning that data if required.
If your application becomes popular enough you may find you don't have enough resources
If your resources are taxed your application will go down, rather then just slow down
You don't need to register clients and keep track of their on/offline state
Parallelizing on the fly is a bit trickier
To pick up older messages, the CLIENT needs to know when they last received a message and then request the server send any message since that time
Both can be fast, but they come with different bandwidth and processing profiles. I prefer push for everything that's real-time.
Might want to take a look at XMPP.
Twitter doesn't really push events out to the iPhone in realtime. It's more like polling by the various clients.
If you really want instantaneous for the last mile you'll want to use push.
Twitter uses lots of servers and raid arrays to handle the load of millions of people posting 140 character messages. Twitter clients log in and request a list of updates for all of the people the user is following within a certain time frame.
Push wouldn't be a good candidate for this because it does not persist the "tweets". It is simply a notification mechanism. There is a text messaging app on the App Store (called Ping!) that relies completely on push notification for sending text messages. This seems to work fine, but if the developers are keeping track of the messages, it is all done on their servers. In their case push makes sense as you want to alert the user of a new message. In the case of a twitter clone, however, it would probably just annoy users if they got a new notification every time someone tweeted.
In the end you're better off just implementing it server side and then developing an iPhone client that logs in and retrieves the latest tweets for the people the user is following.