I have an Android App development for story Maker.
The very first time Registered user logged in our app and create the story and download an apk .
He now uploaded the apk file in play store
The end user download the story now.
When the Registered user logged again updating his App with one more story.
This time he will not upload the app into play store Google.
I want how to update the new contents to the end user from registered user without uploading the App?
If we are going to save the content in server and serve to the end user then what is the process to do this and what are the possible way to do this ?
What you need is a combination of real time messaging, and notifications. Create a server(node or php) that maintains a state listener ,this state listener as hook to any connected device(android or ios). Whenever user performs a subscribed action such as (When the Registered user logged again updating his App) use real time communication to relay this to the server that watches your changes.(Use socket.io or lightStreamer even crossbar.io is perfect). Then intercept those changes with static notifications for every update received, Use fcm(fire-base cloud messaging) this way every data will be always be delivered and synced between clients accordingly.
This is light Streamer.
Optimized data streaming for web and mobile.
Lightstreamer enables several forms of real-time messaging. It is flexible enough to be used in any scenario, including mission critical applications.
► Real-time Data Push and WebSockets
► In-App Messaging and Push Notifications
► Pub-sub with fan-out broadcasting and one-to-one messaging
► Firewall and proxy friendly
► Adaptive bandwidth throttling
This is socket.io
Socket.IO enables real-time bidirectional event-based communication. It works on every platform, browser or device, focusing equally on reliability and speed. Socket.IO is built on top of the WebSockets API(Client side) and Node.js.
This is crossbar.io
Crossbar.io is a networking platform for distributed and microservice applications, implementing the open Web Application Messaging Protocol (WAMP). It is feature rich, scalable, robust and secure. Let Crossbar.io take care of the hard parts of messaging so you can focus on your app's features.
This is firebase cloud Messaging.
Using FCM, you can notify a client app that new email or other data is available to sync. You can send notification messages to drive user reengagement and retention. For use cases such as instant messaging.
All the aforementioned is primarily based on javascript.For php consider this library instead.
This PHP Ratchet.
Ratchet is a loosely coupled PHP library providing developers with tools to create real time, bi-directional applications between clients and servers over WebSockets.
In gerneral, WebSockets is an advanced technology that makes it possible to open an interactive communication session between client and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.
Happy Coding #.
Related
I am working on a project that went open source. The project is a GPS based strategy game where players attack eachother using missiles.
The app is supposed to send notifications to the user's phone when they are under attack. The problem is, right now the app uses workmanager to send a request to the game server once every 15 minutes (the limitation imposed by android) to check whether their player is under attack, which completely misses the attack most of the time. Truly an unreliable method.
I notice that apps like Discord, Facebook Messenger, etc, are able to send notifications the instant a new message is sent without fail. How do they do this? Is this something I can use for my app?
You use push messaging (like Firebase Cloud Messaging) to push alerts from the server to the client when one occurs.
I'm some kind of backend developer and don't know how mobile applications work. But I need to provide architecture for mobile chat application server.
I know that android apps using google services to receive push notifications from firebase, so we don't need run own application in endless loop and poll for new data at server.
That is prefect for push notifications, but firebase notification body limited by 4KB and don't fit for big messages.
So I can see only one realization:
Google services polling for FCM (ex-GCM) notifications
Receive some signal-like notification
According this notification my app go to server and download new message
Update local chat data
Show generated locally notification for new message
This way is looking pretty complicated, so I don't believe that this is only possible (and correct) way.
Another way is to keep websocket session opened every time or poll server manually. But these two operations should drain battery to much.
So how modern chat apps stay in sync even if they closed and device screen off?
if you really want to make modern chat app then do some research on XMPP
These can be some best practices you can follow
setup XMPP server on backend with offline storage support
use client XMPP SDKS for apps to connect XMPP server.
use push notification in case of server connection lost to wake app
and reconnect to XMPP
try to save large files on different server and send only url with
body if you want to keep your files urls private then use any
client SDK that support implementation of uploading and downloading
private file like AWSS3
I am currently building a messaging application that allows users to send and receive messages on their Android mobile phones over an internet connection to each other. I have decided that I do not want to use polling because it means that a user may not receive another user's messages as instant as possible. I have my own server available for use.
I am currently tied between using Google's Cloud Messaging for Android platform in order to send the notifications from the server to the Android device. The other option is to keep a live TCP connection between my server and the Android device via a service, and send 'keep alive' messages every 5 minutes for example.
From your best opinion, what is the best way to do this - or is there a better way? I don't want to use third parties apart from Google to do this. There are similar answers available, but they don't address this specifically.
Alex
using Google's Cloud Messaging for Android platform in order to send the notifications from the server to the Android device.
This is not a realtime notification either; the notifications may be delayed longer than you experienced with polling. Also GCM is meant for broadcasting messages to a number of users, not for targeting a message to one specific user.
The other option is to keep a live TCP connection between my server and the Android device via a service
I don't know how many users you are expecting, but this may not scale. You are limited in the number of TCP connections to one server.
No need to re-invent the wheel here, use an existing implementation such as XMPP.
Take a look at this:
https://pusher.com/docs/client_libraries
https://github.com/pusher/pusher-test-android
It may be what you're looking for
I am building a mobile app, for both Android and iPhone. I outsourced the mobile end to an app company, while I myself develop the back end and web service part with asp.net and hosted them on Azure. The web service is developed with Web API 2.0, and it is deployed to Azure as a web site. The back-end is developed with asp.net web forms and deployed in to Azure as a web site.
There are 2 cases when a mobile user will receive some messages:
(1) When some mobile users post some messages, other mobile users will receive them.
(2) In the back end, if an administrator publishes a message, all mobile users will receive it.
Currently in my back end and web service, when mobile user post message or an administrator publishes a message, I just update database table to save that message. I thought the mobile end will keep pulling database table and get the latest message - until today. Today the app company told me I need to PUSH those messages to phones. He suggested some third party service to achieve this.
I then checked Azure documents, it seems they have built-in push function in their service so that I don't need go for a third party service. But I am confused, I saw there is "Cloud Services", there is "Mobile Services", and there is "Service Bus-Notification Hub". Which one should I use to make my back end and web service be able to send push notification to mobile devices? How should I modify my existing back end and web service projects in Visual Studio Express 2013? Do I still deploy them to Azure as web sites?
by message, I don't mean SMS, I mean some text data.
Given that you've already invested some reasonable development time in both the Android Application and your back-end services, it sounds like you're looking for Notification Hubs. Notification Hubs are designed specifically for sending push notifications to both individual users and groups of users across one or more mobile platforms.
As suggested in my comment, Cloud Services is a means of hosting your application on Azure (for your purposes it would offer a heavier-weight alternative to Azure Websites with an improved SLA), and Mobile Services provides a set of libraries and APIs to abstract interacting with your application's server-side data.
To use a Notification Hub to send push notifications you'll need to do a few things (described in detail in the linked documentation):
Go to the portal and create yourself a new Notification Hub
Create a Google Cloud Messaging Project via the Google Cloud Console (Azure will use this to transport your message to the relevant Android devices)
Update your back-end service to use Notification Hub to send messages
Modify your android application to use the the associated Azure messaging libraries to receive your push notifications
I hate to link directly to documentation, but the best way to get started with this functionality is via the following tutorial from the Azure documentation:
http://azure.microsoft.com/en-us/documentation/articles/notification-hubs-android-get-started/. This covers the basic changes you'll need to make to both your Android application to handle push notifications, and to your back-end service in order to send them.
You'll still be able to deploy your server-side components to Azure Websites.
Note that sending messages via Notification Hub comes with a price tag, though there is a free tier that limits you to 500 devices and 100,000 push notifications per month, as described in http://azure.microsoft.com/en-us/pricing/details/notification-hubs/.
EDIT: Here's an example of using Notification Hub to send messages to individual users:
http://azure.microsoft.com/en-us/documentation/articles/notification-hubs-aspnet-notify-users/
Is it true that if a user does not have Cloud to Device Messaging (C2DM) in his account the C2DM will not work?
If so, how can I do push notifications without a Google account?
The different techniques to send push notifications can be listed as follows
Android Cloud to Device Messaging (C2DM) on OS2.2+
Other techniques for pre OS2.2 Devices.
Cloud to Device Messaging (C2DM) OS2.2+: The standard push notification method used in the android platform is called Android Cloud to Device Messaging (C2DM). The service provides a simple, lightweight mechanism that a server can use to tell an app to contact the server directly, to fetch updated data.
C2DM allows to send lightweight messages to android apps. The messaging service is not designed for sending a lot of user content via the messages. Rather, it should be used to tell the apps that there is new alert on the server, so that the application can fetch it.
C2DM limitations:
The message size limit is 1024 bytes.
Google limits the number of messages a sender sends in aggregate, and the number of messages a sender sends to a specific device
C2DM makes no guarantees about delivery or the order of messages
C2DM requires users to set up their Google account on their mobile devices.
C2DM requires devices running Android 2.2 or higher that also have the Market application installed
Server should be
Able to use HTTPS to communicate with C2DM Server.
Able to communicate with our client.
Able to fire off HTTP requests to the C2DM server.
Able to handle requests and queue data as needed. For example, it should be able to perform exponential back off.
Able to store the ClientLogin Auth token and client registration IDs. The ClientLogin Auth token is included in the header of POST requests that send messages. For more discussion of this topic, see ClientLogin for Installed Applications. The server should store the token and have a policy to refresh it periodically.
Other techniques for pre OS2.2 Devices:
Poll rather than push
SMS
Persistent TCP/IP
Third-party offerings
Poll rather than push: Android app can periodically poll the server for new messages from a background local service. The more often you poll the closer you get to the real-time push.
Adv: Easy to implement.
Disadv: Not real-time.Will kill the battery.
SMS: Android apps can intercept text messages in the android phone.So if a server can send an sms when there is a notification, the android app can receive the sms and then check for new data at server.
Adv: easy to implement. Fully real-time updates.
Disadv: Can be costly to do.
Ericsson labs provide a hosted service which allows upto 2000Sms's to be sent.
Persistent TCP/IP: The android app initiates a long-lived mostly idle TCP/IP connection with the server and maintains it by occasionally sending keepalive messages. Whenever there is something new on the server, it sends a messages to the phone over the TCP connection.
Adv: Fully real-time updates.
Disadv: Hard to implement a reliable service on both the phone and the server side. The Android OS is known to be able to kill services when it’s running low on memory, so our notifications service can easily disappear. What happens when our phone goes to sleep? Imagine if all the apps use the same technique . there will be plenty of open connetions which will drain the battery.
Third-party offerings
Urban Airship Push : The big disadvantage is that it requires the user install the AirMail app onto their device.
The deacon project
xtify
pushdroid.org