I know 2 ways
send KEY and parameters from server to client; generate notification body on client
send notification body from server to client
What approach is better in multilanguage application and why?
The first approach requires a re-deploy of you application if you like to change text or add new notification types but uses less bandwidth. The second approach is more flexible in this regard. Though there is a size limit of the notification body... Not 100% sure but I think 2K for iOS and 4K for Android... but it usually should be enough. Also the benefit is that failing to send language selection after it changes
The second is easier to do, when user language is stored on server side. The language must be send when user is changing language in application, and if server response with failure the language in application should not be changed, because in this case languages in application and server will be unsynchronized.
Related
I am hoping this is not too off topic for a post here.
I have an asp.net webAPI service, which provides a number of routes to get near realtime data (ie within say 10 seconds), which required the client application to poll for changes.
I am investigating on which technology would be best to add an "opt in" push notification service, which just pushes "thin" payloads to tell the client application it is now time to call the existing REST route for an update. This way, the push payload is small, and does not contain any security sensitive data (it still gets this using the existing REST security infrastructure)
Cloud based messaging
Previously, I have been told that, for a Mobile application, I should use something like Firebase cloud messaging, or some other messaging service, however this does not seem like the right solution for "subscription based notifications" I am talking about here. I can certainly see this would be useful, if the client is on either iOS or Android device, and wanted messages/notifications/alarms (etc), which could also work when the application is not running, but this does not seem like the right thing to use of these notifications of changed data (which may be happening all the time, sometimes every 5 seconds). Also, I do not want to only target these mobile devices, but also, for example either a web or desktop application, which may also use the same REST service
Other technologies
I have seen mention of Web sockets, or, in the case of asp.net, the option to use SignalR (which will wrap the web sockets, with fallback). SignalR looks good, but my worry is the availability of client libraries for non web / Windows applications (eg iOS, Android). I am also looking at Rest Hooks. These look interesting, but I can't quite see what the actual "push mechanism" is; it almost looks like they need to POST to the subscriber using HTTP, which means the subscriber has to also act as a "server endpoint".
Just after any thoughts / best practices on this, or what others have used?
In particular, (the verification or otherwise), that for this use case, using cloud based messaging is not the right thing to use due to the frequency of these push notifications (ie something where my server gets to the application via another 3rd party service which pushes to the device/application)
Thanks in advance for any suggestions!
Signalr is an option
There are some libraries which you can use in iOS and android. I suggest you to read once https://visualstudiomagazine.com/articles/2013/11/01/how-to-use-signalr-in-ios-and-android-apps.aspx (its a bit older, but on the point)
Android Client: See How to use signalr in Android
Some alternatives :
Pusher (https://pusher.com/)
Android Client: https://pusher.com/docs/android_quick_start
iOS Client: https://pusher.com/docs/ios_quick_start
Socket.IO (https://socket.io/)
Details iOS Client: https://socket.io/blog/socket-io-on-ios/
Details Andriod Client: https://github.com/socketio/socket.io-client-java
To discuss:
Why you will only send a thin payload whith signalr? I see no benefit for that.
Why "using cloud based messaging is not the right thing"? I do not understand your arguments but I do not know how your application looks like.
I'm designing a database monitoring application. Basically, the database will be hosted in the cloud and record-level access to it will be provided via custom written clients for Windows, iOS, Android etc. The basic scenario can be implemented via web services (ASP.NET WebAPI). For example, the client will make a GET request to the web service to fetch an entry. However, one of the requirements is that the client should automatically refresh UI, in case another user (using a different instance of the client) updates the same record AND the auto-refresh needs to happen under a second of record being updated - so that info is always up-to-date.
Polling could be an option but the active clients could number in hundreds of thousands, so I'm looking for a more robust and lightweight (on server) solution. I'm versed in .NET and C++/Windows and I could roll-out a complete solution in C++/Windows using IO Completion Ports but feel like that would be an overkill and require too much development time. Looked into ASP.NET WebAPI but not being able to send out notifications is its limitation. Are there any frameworks/technologies in Windows ecosystem that can address this scenario and scale easily as well? Any good options outside windows ecosystem e.g. node.js?
You did not specify a database that can be used so if you are able to use MSSQL Server, you may want to lookup SQL Dependency feature. IF configured and used correctly, you will be notified if there are any changes in the database.
Pair this with SignalR or any real-time front-end framework of your choice and you'll have real-time updates as you described.
One catch though is that SQL Dependency only tells you that something changed. Whatever it was, you are responsible to track which record it is. That adds an extra layer of difficulty but is much better than polling.
You may want to search through the sqldependency tag here at SO to go from here to where you want your app to be.
My first thought was to have webservice call that "stays alive" or the html5 protocol called WebSockets. You can maintain lots of connections but hundreds of thousands seems too large. Therefore the webservice needs to have a way to contact the clients with stateless connections. So build a webservice in the client that the webservices server can communicate with. This may be an issue due to firewall issues.
If firewalls are not an issue then you may not need a webservice in the client. You can instead implement a server socket on the client.
For mobile clients, if implementing a server socket is not a possibility then use push notifications. Perhaps look at https://stackoverflow.com/a/6676586/4350148 for a similar issue.
Finally you may want to consider a content delivery network.
One last point is that hopefully you don't need to contact all 100000 users within 1 second. I am assuming that with so many users you have quite a few servers.
Take a look at Maximum concurrent Socket.IO connections regarding the max number of open websocket connections;
Also consider whether your estimate of on the order of 100000 of simultaneous users is accurate.
When I receive a push notification in my j2me application it shows its built-in message at start, what I want to do is to place my own message say "Do You Want to Launch App?" when a notification of invoking application is received! How to change it?
It is unlikely that application developer would be allowed to do stuff like that in the real phone, and here's why.
This functionality is a part of security sensitive features (if you're interested in details, check documentation like The Recommended Security Policy for GSM/UMTS Compliant Devices).
If this would be allowed, malware applications could transform not just wording but the very meaning of a standard system message, thus tricking user into doing something wrong.
For an example, imagine an application doing tracking of user location, or sending paid SMS, or something similarly sensitive to one's privacy or budget, having mentioned message changed to:
Click Yes to win million dollars.
As a phone user, the last thing I would want of my device would be to allow tricks like that.
I'm developing chat application. I use flash as front end and asp.net back-end. My question is: can my asp.net web app send data to flash app in browser without post back ?actually it mean asp.net push data to flash client. I don't know much about flash or siverlight, dose flash support to do that ? or other way help me connect direct from server to browser without using post back or Jabber ? Please give me your advise, thanks so much !
Here is the 100% solution, called Diffusion sever:
http://demo.pushtechnology.com/docs/manual/apis/flash/index.html
This is another option for you written by people at Microsoft:
http://laharsub.codeplex.com/
We use it and so far so good. Very fast.
No, the server cannot push data to the client without postback. It's the client application that needs to fetch it from the server. In fact there's the WebSocket API draft in HTML5 that allows the server to push data to the client but it still has limited browser support and you will need a server that is capable of handling this protocol.
So currently the only reliable way of doing this is by having the client poll the server for data.
Flash has support for socket communication, that can be used to push data to the client without polling.
You mention asp.net, I'm no expert in that area, but maybe the "Active Server Pages" aspect doesn't fit so well with socket communication, but I'm pretty sure you can build the server side of a chat, pushing data via sockets, in .Net.
Suppose I have either an ASP.NET displaying my results, or a Silverlight client. And I'd like to show the current status of my server, or embedded device. (pretend the device reads temperature and humidity stats)
How should I send the status information from my device to the front end? Should I poll the device and save the results to SQL, Azure Table, or the like? (Azure is a technology that fits with this project for other reasons. That's why I mention it)
Or should I create a WCF service that polls the device directly and returns the current status.
What makes more sense?
In either ASP.NET or Silverlight you are going to have to poll from the client (web page or Silverlight app) to the backend to get the current status. In ASP.NET I'd look into doing this via an AJAX poll to a service using Javascipt (look at using Jquery or something similar to make this easier).
In silverlight you will need to have some sort of service configured to return the results and poll it using the Timer control running on a seperate thread.
You can also using a "push" binding within your silverlight app. Basically instead of you manually polling the server, the server will send you a push notification anytime it deems it necessary to let the client know of any change.