I'll explain it clearly. I have an app that utilized Google Map v2. Now, when the user is using the app, even if it is on the background, the app must identify the current location of the user, and the app must push a notification if the user is near a landmark,or restaurant,or hotel (etc etc). I think this can be done using the notification builder, but the tricky part is we have an admin panel(web-based) that will enable potential clients to add, update, delete Merchant and Sponsored Promotions relevant for specific Historical or Landmark Site. Since potential types of notifications will increase, the app must fetch the currently added data on the admin pane. I don't know if using the notification builder or this is the best choice. I hope you can give me a detailed explanation or advice about this. Thanks.
Since the app must run in the background in order to maintain the current location of the user, and deliver notifications based on that location, you don't have to use GCM. The background process can access the server periodically to load the updates in notification types.
However, if you wish your app to update its notification types even when it's not running at all, you'll need to use GCM. GCM will also be useful if you prefer to reduce access of your app to the server (in order to save battery life) - it will allow your server to notify the app when an update is available in the notification types, and then your app can load the update from the server (assuming the data is too big to be sent in the GCM notification).
You should estimate how often you expect the server to have updated notification types, and decide what the app's response time should be to such changes (how much time you allow to pass from the server update time to the time the client gets the update). If you require quick response time, GCM would be preferable to polling the server by your background process (to save battery).
Related
There are 2 situation where i need to implement best and efficient way to push the notification to the end users:
specific users which are in 10mi radius from a business offering discount will get notified about expiring coupon or any other new offer.
All of the Users get notified for next upgrade feature available to install.
Please let me know if I should save all of the device token downloading my app in my DB along with their lat, lng, So that I can search them for specific distance before sending notification. Or shall I just save registered users only for notification?
I am writing backend api for this app and need best solution for this.
Thanks
Push notifications need device token, so if you need to send the Notification to every user in the app, even if the user is not registered, you will need the device token in order to make the push notification work.
Also keep in mind that device token could change so you need to save it every time you can, for example, every time the app is launched.
For the notifications in the geofence I think you can use a local notification.
I'm currently working on an android app where I want users to receive notifications based on their distance from certain locations.
I'm using Firebase Cloud Messaging for notifications, but I cannot figure out how to do this.
I figure there are two possibilities:
Save user location on database and calculate before sending notification, but this requires lots of work and requires the user to make an account in the app to save data to the database. And how would you know whom to send to? Since a topic sends to all.
Send notification to all and filter out notificaion on phone before showing it. I found the onMessageReceived() function, but I cannot figure out how to stop the notification from showing here.
Any suggestions?
I am not sure you will achieve what you want with FCM, but I would advise to go with Google Play Services GeoFencing API that might be what you are looking for, and works very well!
Once entered in one of the regions you are monitoring (based on the radius-distance to each location) your app will be woken up, and you will be able to do whatever you want, like firing a notification, reach your backend, etc…
I have a cross platform application and i want to send notification to sign in users about their messages.
Now I confused about uses of push, local notifications.
What I think of Push notifications is that it is for sending Announcements to users which is not specifically related to their account only.
Can anyone help me out with what should I use? I already used Local notifications in one of my applications with such requirement.
It mainly depends on; is the data coming from local or remote?
You cannot control when your users open the app, and only when they open the app (with a few exceptions) you are able to fetch data. Then with that data you would be able to schedule a local notification. But in most cases that doesn't make much sense, because they have already loaded and probably seen the data. It only makes sense when you schedule an alarm clock for instance.
When you want the data to come from remote, like when they receive a message, you will have to use push notifications. The user is then alerted that new data is available without having to go look for it themselves. It is pushed to them.
However, for push notifications you will need infrastructure which you did not when using local notifications. You will need a server to handle the push notifications (Azure has some awesome functionalities for this) and some trigger to send push notifications. This can be an insert on a database, or a scheduled task. Also, the user has to enable push notifications and your app has to register itself to be able to receive them. It can be a pain to implement it the first time.
It depends on for what reason you're sending the notification.
A local notification is sent locally on the device, so it doesn't need an internet connection. Examples could be:
Send a birthday message when the user has birthday
In a harvesting game, send a local notification when the store is full
A Push Notification is sent from a server and it requires internet on your device to receive it. Examples:
You get a message in a chat while the app is not open (if I understand your question right, this is your case)
In a game: realtime events which are triggered by a server
So in your case, if guess you want to notify the user about new messages if he does not have the app opened. This notification comes from a server and is a Push Notification.
As you describe you want to send notification about sign in users about their messages. so it would be the real time notification about when there is message for user you need to notify the user. so apple having PushNotification is the best approach you need to apply for this. using that you can directly notify user about the new messages.
Why LocalNotification is not useful in this scenario?
I think messaging is the realtime stuff. local notification is not for that. its for only managing local notify stuff. like reminder OR to do added task.. and many more
I'm planning to send push notification to targeted users. I understand that this can be achieved by targeting by the player ids. But going for this approach would require my database to introduce dependency with OneSignal which is something that I'm trying to avoid.
I'm thinking is it possible to target players by username. What I mean when the app initializes it would update OneSignal saying that 'my username is user1' and when the server sends out notification it can target 'user1' (again, without using the player id approach).
The closest way that I could think of is tagging where the user could register themselves with username as the tag and server could target the user by using the tags. But from the documentation it seems like with this approach we can only target 200 users at once which is not feasible to me as well - I might be sending to thousands of users.
Any advice?
As you suggested, tags are the best way to achieve this without storing OneSignal IDs.
Although this is limited to 200 at a time, you can make multiple API calls to deliver to a larger number of total users. OneSignal's average API response time for this method is below 50 milliseconds, so this method will allow you to reach 4,000 users per second if you make the API calls in sequence.
OneSignal is a wrapper to Firebase Cloud Messaging or FCM (previously Google Cloud Messaging or GCM) on Android. If you don't want to rely on OneSignal internal device ID (or Player ID), you could still use FCM/GCM Registration IDs directly (also called push tokens) to target users with notifications. But in that case, you still have to store new IDs on your servers (instead of using your owns) and more importantly, you'll have to deal with FCM/GCM tokens complexity by yourself (managing errors, canonicals etc.)..
A better solution would be to use a third party like Batch.com (disclosure: I'm a co-founder). We allow developers to provide their own User ID (it's called a Custom User ID, you can set it from the app code) and then use it with our Transactional API to send push notification to one or more users (recipients can be push tokens, Batch installation IDs or your own User/Custom ID).
After discovering that WhatsApp probably updates notifications about every second I began to wonder what the best combination of battery life and keeping users up to date by notifications is.
The company where I work right now is really afraid of sucking the battery life. So they want the fastest sync to be around a quarter. Meanwhile WhatsApp updates every second. So is what our company doing the right thing? Or can we just like WhatsApp check for new updates every second because it doesn't suck that much battery life?
That extensive network usage will surely be very expensive for battery and even for data usage. If you need frequently updated data in your app, in most of the cases it's a bad practice to send HTTP request once per 1 (2 or even 5) seconds.
A good way to receive and update any kind of notification (wether it's Android system notification or some notification badge inside your app) is using Google Cloud Messaging. You'll have to implement it on both server and client side. You will need to register your app package name in Google Developer Console and retrieve an API key. After you do that, your app will be able to receive push notification from GCM server. The flow of receiving a push notification looks like this:
You register current device to GCM system using provided SDK and it generates you GCM unique identifier of current device
You upload this key to your server (if you have user profiles in your app architecture, it's a good idea to store it in current user profile)
Once something important happens on server, say, user gets a new unread message, your server takes the GCM unique identifier from user profile and sends a notification to GCM server
GCM server sends this data to user's device by using this identifier and delivers the notification to your implementation of a BroadcastReciever. After that it's up to you what to do with this data: create a system notification or/and use this information to update UI of your app.
It is just an overview of how does Google Cloud Messaging work, there are tons of articles about how to set it up and implement into your project, for example, this one. This solution might look way more complicated than just sending HTTP request every second, but your potential users will be thankful for saved battery and data limit.
Also, if you want to make Android system notifications, you may want to use Parse library which wraps GCM and makes implementation a bit easier.