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.
Related
Yes I know that this has been asked on StackOverflow before but I just can't find exactly what I am looking for. So what I would like is when a user (user1) send a message to another user (user2) , for user2 to get a notification saying they have a new message from user1. So far I have set my app up so that I can send a push notification from the Firebase Console, but not so that the app does it automatically. I think I need an observe function but I am not quite sure what to do or the code for it?
Thank you so much for all the help! This is my first time with Firebase.
You can just use Cloud Functions.
It simply triggers a Function when an Event occurs.
For example whenever a new message added to a node you can run a function that sends a Notification to the user
Check the Documentation
Also check this sample which matches what you need
I have asked same question some time ago. The thing that was bothering me was why should I use Cloud Functions and write and deploy functions for it in javascript if I just wanted to send Notifications just between two users?
So I checked out other options and setup everything in just about few minutes without writing any javascript functions in the Firebase Cloud Functions.
Well it depends on what you will exactly need but in my case using Cloud Functions just to handle that was nonsense. If you are in the same situation as I was you can use OneSignal like I did. There is also my question on this and you can check it out here.
you can try this it can worked for me sending notification through fire base cloud
https://github.com/firebase/quickstart-ios
https://github.com/firebase/quickstart-ios/issues/286#issuecomment-304992090
I am working on an ionic project. It is based on medication managing.And I want to remind the user about their medications. I am new to this and can some one give me a sample code, link or something to create reminders.
I would recommend taking a look at Local Notifications, they are notifications that can be scheduled on the device without the need for a server. It is commonly used for things like reminders. You can also choose to do this using a server with Push Notifications, but that doesn't seem necessary in your situation.
For starters, take a look at the documentation for Local Notifications, see if it works for your use case.
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 would like to create a service that parses data from a feed and then sends notifications to subscribed units.
And I'm note sure how to approach this problem. Would be thankful for any advice.
If you're going to be sending less than 1,000,000 push messages per month (greater than that amount you would have to pay), I'd look into UrbanAirship . They have something called a feed feature that does this:
Urban Airship has a feature where we
will monitor an RSS or Atom feed and
send a push notification when a new
entry is published. We allow you to
set up a template to extract items
from the feed to dynamically generate
push notifications with content from
the new entry. You can easily set this
up from the interface at
https://go.urbanairship.com/ , but
this API allows you to
programmatically create them.
So, that might work for you. Or, you can look into setting up your own server that runs a script, parsing your feeds. Then you can use Easy APNs to send the messages yourself. I'm using it and it works perfectly for my needs. For me the learning cure was steep because I'd never done anything besides Obj-C, but it ended up being quite easy to learn.
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.