I need to implement push notification to our Android App using Xamarin. Here is the process. We have web version which used by the Manager. The Manager creates and assign job to the driver. The App version is used by the Driver where it shows the list of jobs and processes of job until its complete. So, when the Manager assigned the Job to the Driver in the Web version, it will then notified to the Driver in the App version that "new job is assigned". Basically, both the web and app uses same database then we created an api(REST API in MVC C#) to connect and get data from the db to be used in the mobile app.
Can someone recommend to me which Push notification plugin(a plugin or nuget) should I use to do this? Currently, I have set up Push Notifications through App center & Firebase but not sure how this work.
Thank you.
I need to implement push notification to our Android App using Xamarin.
I would suggest you use Firebase for mobile push notifications for Android as it is a product by Google, and was made for mobile applications. For push notifications, you will be using Firebase Cloud Messaging also known as FCM. See to it that you are well versed on how it works before you start coding anything read the documents it answers most of your questions there itself.
The Manager creates and assign job to the driver. The App version is used by the Driver where it shows the list of jobs and processes of a job until its complete. So, when the Manager assigned the Job to the Driver in the Web version, it will then notified to the Driver in the App version that "new job is assigned". Basically, both the web and app use the same database then we created an API(REST API in MVC C#) to connect and get data from the DB to be used in the mobile app.
For this, you will have to check on how to work with Firebase using Rest-API. Once you configure the Rest-API and then apply your business logic to it things will be quite easier than you might have imagined.
Can someone recommend to me which Push notification plugin(a plugin or NuGet) should I use to do this?
My recommendation is quite simple, Do not use any sort of a firebase push notifications plugin!. I have had a very bad past with plugins and ever since then I never recommend fellow developers to use plugins until it is a well-maintained one. I would rather ask you to simply configure Firebase on the basis of the guides that are available online. Like the following Xamarin.Android guide for FCM. It is detailed contains everything that you are looking for and what else I would suggest is you check firebase related answers on SO and you will find that almost everything that is not available in docs is covered around here and in detail. Like the following:
How to handle Firebase Notification i.e. Notification Messages and Data Messages
Push Notification in android with firebase get token
How to send device to device messages using Firebase Cloud Messaging?
Receive push notifications on one android app from two Firebase projects
Looking for additional products similar to www.nylas.com which provide an API to sync my web application with my microsoft exchange email and calendar.
Most email services are aimed at marketing and hosting, whereas I just want a simple connection between exchange and my app, without building an API from the ground up.
Any suggestions?
Why not using Exchange EWS?
Calendars and EWS in Exchange
Working with calendar items by using the EWS Managed API 2.0
I do not know your App so a simple cronjob would do it...
P.S.
By the way I personally think the best way is to access the calendar via the App directly on the device. The reason is that a user normally have ActiveSync configured so that he get all the content on his device. If he change his password he do that on the device. So your app might use a old password and will no longer work. Additional your app try to access content with the old password and might block the user account then. The user got upset and will no longer use it. Accessing the calendar now directly on the device eliminate the need to get the user password and also eleminite the need that the user need to change it in your app...
As per this link, FCM is the new version of GCM under the Firebase brand. In Codename One, which is supported? GCM or FCM?
We currently use GCM internally. We can switch to FCM but there is no real reason. Google has no intention of removing GCM as FCM (and a lot of apps) depend on it.
They are pushing FCM to push firebase. This provides no advantage to Codename One users as the easier API isnt' relevant (we abstract away the pains of GCM).
Bottom line is that you don't need to worry, if there is a need to switch to FCM we will do it for you and it will be seamless.
I'm not too familiar with Codename One so I decided to go ahead and look into their site. I found this Codename One page that guides about Push Notifications, but noticed that it's an old guide since this was still using the Developer Console when generating the Server Key (used for GCM/FCM).
With that, I went ahead and asked the Codename One chat support (lower-right side of the page). Chat history below:
Me:
Hey guys. I was wondering what Push Notification Services do you Support?
I've seen this link -- https://www.codenameone.com/how-do-i---use-push-notification-send-server-push-messages.html
Do you have your own Push Notification Service? Or are you guys using GCM? Is it already integrated with FCM too?
Lianna (Chat Support):
Hi,
we use the native push notifications for the respective platforms GCM, Firefox, Chrome, Microsoft and ipns.
Currently we use GCM and not FCM as the advantages given by FCM are mostly for API usage (which isn't applicable) and not very portable (available only for Android). When/if we switch to FCM this would be seamless thanks to our abstraction of the service.
FYI that video is a bit out of date, there is more up to date coverage in our developer guide.
Credit goes to Lianna (Kudos! :)). I think this here is the developer guide she was referring to.
TLDR:
Does Google check the validity of an iOS app's bundle identifier when restricting the API key to a specific iOS app?
Or is it possible for anyone to mimic the bundle ID in order to launch an attack?
If the latter is false, why not include the API key in the iOS app?
UPDATE 1:
I'm guessing Google doesn't check for Team ID?
Apple Glossary
App ID A string that identifies one or more apps from a single team. An App ID consists of a bundle ID search string preceded by the Team ID, a 10-character string generated by Apple to uniquely identify a team.
I need some directions... (pun intended)
Say I'm building an iOS app that needs to consume the Google Directions API.
Google suggests to "proxy the web service via your server when you're using the API in a mobile app, to protect your API key".
In my project settings in Google Console (API Manager -> Credentials etc) I can restrict the API key to only iOS apps with my bundle identifier (com.example.MyApp).
Since I don't need a server, what's the worse that can happen if I include the key in the app?
The only thing I can think of right now is someone steals the API key and builds an app faking my bundle ID (or even fake the iOS host itself) and fires "unlimited requests" to bring down my service/make me pay a lot of money.
Is this possible?
And if it is, couldn't he do the same even if I hid the API key in the server? Just call my server instead of the API directly.
So what's the gain of having a server in that case?
And would the only solution to prevent this abuse be to require authentication and rate limit each user?
But couldn't then someone create "unlimited" random accounts?!
Do I use captcha?
By then the UX has become pretty awful, especially since authorisation is not even required for my app...
Is there a solution to this, or do I just choose the simplest solution (include the key in the app) and hope for the best?
Once created does the push notification device token ever change?
Example when the app is updated? or in any other case it can change??
Apple's official documentation is unclear on this point. What I have observed is this: the token is invariant for a given device, application, and domain (production vs. sandbox). I believe that this must remain true in order for the system to work reliably. Consider the situation where an application update triggers a new APN token; if I were using the greatest new Twitter-like app, with notifications enabled, what would happen when I update my app from iTunes? Should I have the expectation that it will continue to be sent notifications even though I have not run the applications since I "sync" the update onto me device? The act of changing the application cannot affect the APN system since the OS can receive notifications on your behalf even though you haven't run the updated app.
To be clear, Apple states "An application should register [with APN servers] every time it launches and give its provider the current token". I wholeheartedly agree; doing so will protect your application from bad assumptions or unusual situations.
One of the answers to Are push notification tokens unique across all apps for a single device? indicates that device tokens are unique per "operating system install"; and that restoring from backup to a device would maintain the token but wiping a device will cause it to get a new token. This would be entirely consistent with Apple's intentions of seamless operation and privacy: wiping a device is severe enough that perhaps it warrants a new association, but a user restoring an image after an OS update would want to preserve their existing notifications. If I recall the recent iOS5 update on my iPad, I restored the most recent backup after upgrading, so this would have maintained my notification token's consistency. [Edit: restoring a backup to a different device will NOT duplicate the token.]
caveat:
I do not have definitive knowledge on the subject, just some reasonable experience working with APN (as a third-party developer). As always, it is best to verify your assumptions.
Update (June 2012):
I recently had a chance to a> talk to Apple engineers and b> run some real world tests, and I wanted to present the results:
To be complete, when I talk about returning an APN token, I am assuming the context of a single bundle identifier/application.
First, the Apple engineers said that it should not be possible for two devices to return the same APN. Notwithstanding the comments below, I have not been able to identify a circumstance where this fails.
Second, here is the upgrade test sequence and results:
Start with iOS4 installed on iPhone4; backup device in iTunes
Upgrade to iOS5
From a previous test, I know that the APN token is now different
Restore the backup to the device
The APN token is now the same as step 1.
Reset iOS (clean device)
The APN Token changes
Backup a different phone to iTunes and restore that backup to test device; basically, I'm restoring the "wrong" backup, as if I were switching phones.
The APN token changes again; further it is distinct and does not match the tokens either the original token or the "cloned" token.
Restore the "correct" backup to the device.
The APN token is now the same as step 1.
Lastly, I upgraded the phone to iOS6 (beta2), restored my backup, and re-tested. As expected, the token continued to match the token in step 1.
At this point, I'm pretty confident that APN tokens can't be duplicated between different devices; perhaps this may have happened as a bug in earlier versions of iOS, but I'm confident that iOS5 (and presumably iOS6) are handling APN tokens correctly.
Update (August 2012)
I just realized I had not added this: device tokens will change. One of the Apple devs shared with me that tokens do actually expire (after 2 years, I think). For many purposes, this is long enough that can be thought of as invariant.
[I'm not worried if I have to update my test scripts with new tokens every two years, especially since I change phones every year.]
From [Apple Documentation ApplePushService]2
The form of this phase of token trust ensures that only APNs generates
the token which it will later honor, and it can assure itself that a
token handed to it by a device is the same token that it previously
provisioned for that particular device—and only for that device.
If the user restores backup data to a new device or reinstalls the
operating system, the device token changes.
I've just tested it with iOS9 and APN Push token changes if I reinstall an app.
YES, device tokens can change.
Anytime your app receives a token, it should store it. Then, whenever a new token is received (which will happen, eventually), compare the new token to the stored token and, if they are different:
Update the device's local storage, (including possibly to nil)
Update anything on the device which uses the token to be aware of the new token
Update any APIs which are aware of this token to the new token.
As a practical matter, the last step is the most likely to be non-trivial. For example, if you have a service which is sending weather alerts to a device token based on what zip code that device has subscribed to, then you need to pass the old_token and the new_token to said service so it can update delivery.
Ergo, generally speaking 100% of APIs accepting a "device token" must also have some kind of UPDATE facility for that token. To not build for this is to build for mis-delivered and non-delivered notifications.
Device token does change from iOS 8 and later
Please see text below from Apple website. Registering, Scheduling, and Handling User Notifications
The device token is your key to sending push notifications to your app on a specific device. Device tokens can change, so your app needs to reregister every time it is launched and pass the received token back to your server. If you fail to update the device token, remote notifications might not make their way to the user’s device. Device tokens always change when the user restores backup data to a new device or computer or reinstalls the operating system. When migrating data to a new device or computer, the user must launch your app once before remote notifications can be delivered to that device.
I think it is worth mentioning as nobody did it that the token changes after you have called unregisterForRemoteNotifications. When you call registerForRemoteNotifications next time the token is different. I failed to find any confirmation of this in the Apple docs but I witnessed such a behavior myself. Please keep this in mind
Links quickly become obsolete with apple! so i'm quoting what seems to be quite clear now :
Never cache device tokens in your app; instead, get them from the system when you need them. APNs issues a new device token to your app when certain events happen. The device token is guaranteed to be different, for example, when a user restores a device from a backup, when the user installs your app on a new device, and when the user reinstalls the operating system. Fetching the token, rather than relying on a cache, ensures that you have the current device token needed for your provider to communicate with APNs. When you attempt to fetch a device token but it has not changed, the fetch method returns quickly.
From this guide
It shouldn't change, unless your app is restored onto a new device (at which point it won't be asked to accept push notifications again, and will simply send you the registered call at which point you should accept the new token).
But Apple doesn't guarantee that it never changes (hence the documentation never mentions it). You better program for the worst and assume it may change one day. Also, sending a token to your server regularly enables you to remove tokens that haven't registered for a while, and have probably deinstalled your app or lost interest a while ago (and the documentation does specify this as wanted behavior!).
From - Apple Docs
APNs can issue a new device token for a variety of reasons:
User installs your app on a new device
User restores device from a backup
User reinstalls the operating system
Other system-defined events
As a result, apps must request the device token at launch time.
Additionally:
I M P O R T A N T
APNs device tokens are of variable length. Do not hard-code their
size.
As reference to
Apple push notification stuff
The device token is your key to sending push notifications to your app on a specific device. Device tokens can change, so your app needs to reregister every time it is launched and pass the received token back to your server. If you fail to update the device token, remote notifications might not make their way to the user’s device. Device tokens always change when the user restores backup data to a new device or computer or reinstalls the operating system. When migrating data to a new device or computer, the user must launch your app once before remote notifications can be delivered to that device.
Never cache a device token; always get the token from the system whenever you need it. If your app previously registered for remote notifications, calling the registerForRemoteNotifications method again does not incur any additional overhead, and iOS returns the existing device token to your app delegate immediately. In addition, iOS calls your delegate method any time the device token changes, not just in response to your app registering or re-registering.
According to this link the device token
The device token included in each request represents the identity of
the device receiving the notification. APNs uses device tokens to
identify each unique app and device combination. It also uses them to
authenticate the routing of remote notifications sent to a device.
Each time your app runs on a device, it fetches this token from APNs
and forwards it to your provider. Your provider stores the token and
uses it when sending notifications to that particular app and device.
The token itself is opaque and persistent, changing only when a
device’s data and settings are erased. Only APNs can decode and read a
device token.
Yes it can change.
Ideally when ever we receive a token via the callback method
(void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken
The app should register / refresh the token on the remote server. This will ensure that the token on the APNS and your server is kept in sync.
As per Apple documentation,
Obtaining and handling an app-specific device token works as follows:
Your app registers with APNs for remote notifications When a new
device token is needed, APNs generates one using information contained
in the device’s certificate. It encrypts the token using a token key
and returns it to the device, as shown in the middle, right-pointing
arrow. The system delivers the device token back to your app by
calling your
application:didRegisterForRemoteNotificationsWithDeviceToken: delegate
method. Upon receiving the token, your app (within the delegate
method) must forward it to your provider in either binary or
hexadecimal format. Your provider cannot send notifications to the
device without this token. For details, see Registering to Receive
Remote Notifications in Configuring Remote Notification Support.
The device token relay on the installation of the app.
It means that if you reinstall the application, it changes; it doesn't metter if you do it from a backup, an iOS upgrade ecc..
The right way to use it, to avoid any problem, is to get the one given on the NSPAppDelegate at each application launch, in the method didRegisterForRemoteNotificationsWithDeviceToken