All push notifications with reciever with less counts sends properly but large audience push notifications get stuck at Sending and count also does not get updated.Since it is live application i am not able to send push notification with such large audience..Any idea how to debug and why is it stucked ??? All other notifications are sending and recieveing normally but large audience isnt. Its just stuck at Sending
After Debugging found out that when i call other query results are returned properly but this specific query does not returns anything...
RestQuery.prototype.runFind in RestQuery.js
does not call function with results..
And it is always stuck there.
Running the same query in mongo shell does not take more than 0.4 seconds but is always stuck in parse-server
Plus Sometimes other queries also show lost connection to mongo.
Shouldnt Parse-server handle indexing itself.
Thanks in advance.
Not sure if this is your issue, but as far as Parse Server 2.2.17 goes, there is a bug with the cloud code. Cloud code is having trouble working properly and they advise to roll back to 2.2.16.
Related
I'm using React and Firebase, and when I check the usage on Firestore, I see a lot of request being made. The problem is that I'm not the only one using it, so I don't know if most of them are mine or not. Is there anyway (using console maybe?) to know how many request I'm doing?
There is currently no way to track the source of reads and write happening in Firestore. You can only see the total volume of those requests in the console.
I was to send a notification to my flutter app when a certain table is updated.
the find that I can connect it to firebase and it will be solved but my tables are already made and the app is about to finish I can't waste more time.
I came up with a solution that I send an HTTP request and check if there is anything new every minute, but it would cost a lot of Bytes so I wont to try something else.
is there a way to get the information when it is added or within a small time frame.
You can try the socket io which will help to detect onUpdate
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 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.
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.