I want to send messages from an Android handset (and possibly from embedded devices) to the Cloud, and then from the Cloud to an Android app running on a Tablet.
Does anybody have ideas/suggestions for the architecture? Gotchas? Recommendations on what or which cloud services/providers are best? IOW, which Cloud services have both a good API and make it easy/cheap for the end user (MY end user, that is)?
Just replace overhyped word 'Cloud' to 'Server' and you will google tons of answers. I will give you one here: use simple rest over http, once you got this working you can move your app to any cloud you want (depending on the server technology you'll choose of course).
If you want to send messages between two devices all you need to do is have a server to centralize the communication. Server could be anything, but generally a webapp is best. Python, PHP, Ruby, Java. The Android application, on either phone or tablet, would send a message to the server over HTTP. The server would receive the message and store that to some persistence storage (DB, Cassandra, MongoDB, etc). In fact here is an article discussing just that:
http://www.rackspace.com/cloud/blog/2010/05/12/cassandra-by-example/
Then your other Android application would periodically poll for messages from the server by hitting a different URL. On polling the server it would look up in it's topic bucket had it received any messages since the last time it checked. If so the server would reply with the messages it has.
For deployment you can deploy this server to the cloud or regular old web hosting service. By cloud I mean a virtualized hosting server like Amazon EC2, Rackspace, Google App Engine, Slicehost, etc. There are plenty of them. But, you don't have to live in the cloud for this to work. You can just as easily deploy to a traditional web hosting service. Rackspace offers both virtual hosting, and non-virtual hosting with renting models for physical hardware.
Related
I want to develop a system in which data is being shared between DESKTOP app and Android app.
After searching I have found that I need a server in between them. But I can't figure out what the server is? How do I create it? And how will it help me connect my two platform devices?
Desktop App will receive data from android app. And manage data. It will also be used to send notifications/messages to android apps.
Android App will be used to input data and send it to desktop app. It will receive updates/notifications from desktop app.
Now how do I connect these two? I basically need a common database for real-time data sharing and notifications.
Edit: I am building the desktop app using C# and android app using Java.
Edit2: Maybe I can host the database on CPANEL or 000webhost using PHP. And then connect it with both android and C#. Is this the correct way to do it? Is it possible to connect it with C#? I know it can be connected with Android, not sure about C#.
You don't necessarily need a database. You need a common network protocol between two applications.
All network communication is done via sockets. You need a library that allows you send data over sockets. For example, here's an Android guide that is about sockets.
A socket binds to a specific port of a computer, essentially making it a "server". Much like how web servers all expose port 80, and communicate over a protocol called HTTP. Which is important because it is up to you to decide what protocol your applications communicate between each other, because the socket just sends bytes - it doesn't care what you send or how, as long as it travels to a port on a particular server. It also won't parse the data for you, that's up to your application to handle. For example, how would your desktop app know the Android device sent it a text message, or some image to be displayed, or an address to show a map?
All in all, your reason for wanting a desktop application rather than a web application is not entirely clear. Parsing only the body of HTTP payloads from different HTTP paths that are mapped to different methods (which is typically referred to as a REST API) is much simpler than building your own protocol. You might as well build a desktop GUI over top of a web server.
Making the desktop app send updates back to your mobile application is basically impossible using a bi-directional socket architecture. Your Android should not be running an open server socket continuously just for your application, mostly because battery drain, but because its network address is subject to change frequently, and you therefore additionally need a registration server from which your device would reconnect to. Such a service exists as Firebase Cloud Messaging, which is a rebranding of the GCM technology made by Google, and it can be used to send push notifications to devices, but only with small data payloads.
See here about what activities occur on an Android device for notifications. How does push notification technology work on Android?
Back to the question about databases. Suggesting one to use is too broad. And you only need one of those if you want to store and/or query or join datasets. The same computer running the desktop app can install and run whatever flavor of database you prefer, whether it's a relational database or noSQL database, entirely up to you. The only realtime databases I know of are RethinkDB and Firebase.
You could also just hold a SQLite file which is as good as a small scale database (even the SQLite documentation recommends it for low traffic web sites).
Firebase supports web interface, so you can develop html code and integrate in desktop app, something like web integration in windows form application
I'm creating a viber-like application, i.e. android users can make instant messages in their android-powered devices. I've created client-to-server webservices using ASP.NET (ASMX service with JSON response) and it works like a charm, but the other side, i.e. server-to-client requests is just a little headache. Of course I can make my application so that there is no need to server-to-cliend requests (sending dummy requests from client to server in short periods) but in this way server will be overloaded specially when number of users increases. I've found some technologies regarding instant messaging, including GCM and XMPP. What are my other options? or let me ask what is my best option?
Should I use sockets? If so, how can I always have my clients IP (considering that clients are mobile users which may be using WiFi or GPRS/3G/4G internet). I'm thinking of a system in which my clients send their IP each n seconds (n can be around 30), so server always has a (nearly) up-to-date list of client IPs.
Is it possible or even logical to do so?
You should definitely consider using GCM (Google Cloud Messaging for Android)
You need to setup a few things in your server to be able to use it to send via GCM.
Its the built-in way to send data from a server to an android device, hope this can help
Implementing GCM Server
Using the good old strategy of long-polling is always possible, but there are much better ways to do it nowadays. That's perhaps the fastest to implement of the mentioned (not so if you want to implement it correctly and with min amount of load on your server/DB engine). I've seen some projects that start around that architecture with the idea to move to something better in the future .... and the moment to move never comes of course. If you start browsing your Android phone connected to a proxy like Charles you'll see what I mean :)
WebSockets are an option, but I don't see a reason why I'd use them for a Viber-like app, which is event-based (you've received a message) and not "real-time" (monitoring some stock graphics movements for example).
Your best choice here is a Google Cloud Messaging (GCM)! It's easy to implement it both on your backend and on the client, and it's built specifically with the problematic connectivity in mind (switching between wifi/poor 3g/4g/etc). It has some pretty nice features that other methods don't provide "out of the box" - message resending (the common scenario of a client loosing his connection - GCM it'll send the push notification later, when he comes online), automatic syncing between devices (smartphone, tablet, etc) and others.
I recently created an app that sends and receives commands in the form of SMS text messages, being that sending a lot of text messages could become quite costly, i'm now looking for a new method to use to send and receive the data securely over the internet. Obviously one solution would be email, although I do not think this would be ideal due to emails stacking up and accounts etc.
So basically, i'd like some advice on what my other options are....
How would sending a command using TCP work in android and how secure would it be?
How would one go about setting up sending data over TCP?
Any feedback would be great, thanks
What your looking for is Google's Cloud Messaging service. GCM is the standard way to push messages to/from the client. It requires several components to implement, however. One being a database to store GCM ids. Another is a back-end to do this.
It essentially works like this:
User downloads and installs and opens the application
Your application sends a request with your application's unique identifier to google for their GCM id (have to register on google's app center site)
Google responds to the device with their GCM id
Your application then sends (via network services or ajax in a webview) their GCM id to your server, which stores it for future use.
All of these components, however, are good things to have for growth and infrastructure support. Postgresql is a good, open-source relational database.
Other options:
1 - You could use websockets (https://github.com/koush/android-websockets)
Websockets, however, could considerably draw down the user's battery, extremely quickly if the app communicates even if it's not open, like... 'whooosh'
The benefits of using websockets is that it detaches your communication from Google.
Depending on your principals and/or beliefs, you may choose to go 100% independent by using soon-to-emerge web standards for detachment. Google (lol) "Extending the web to support personal network services" written by John Lyle, Claes Nilsson, Anders Isberg, and Shamal Faily. It's a good paper on the mobile communication debate.
I have two android devices that runs a gcm client app. I get the Reg IDs of both the devices. I also have a server API key. Now the thing is, Using a simple php code using cUrl or Zend framework, I'm able to send message from a web server to one of my droids (Of course I can broadcast too). But, with this in hand, is there any way to send a string from one device to another?
Quoting myself from my book:
You might be tempted to use GCM for peer-to-peer messaging, without a server of
your own. In effect, each Android app is its own server, using the same JAR you
might use in a Web app inside your Android app to send messages to some other
party. For example, you could implement a chat system without having a dedicated
chat server.
The danger here is that this would require your API key to be embedded within
your Android application. Anyone with that API key is perfectly capable of forging
messages from you. The IP address restrictions you could place on that API key are
unlikely to help, since your legitimate uses might come from any IP address, not
just some single server. Since finding magic strings in APK files is not that difficult
for those with the inclination, putting your API key in your APK file is a dangerous
move.
Hence, you will want some server of your own as a middleman.
One thing you could do is to make a POST request to your web server with the message and the registration ID of the other Android device, but that would be a little cumbersome as you'd have to figure out a way to retrieve the registration IDs of the other Android devices from your web server.
I would recommend looking into XMPP as this protocol has been built from the ground up to be an extensive messaging protocol. I'm pretty sure you'll find good XMPP server frameworks to implement your functionality.
I've been reading through the GCM developer page and none of it seems too complicated. However, from an overview standpoint, I'm confused on exactly what I want. I have an application on one device that will send some information to another Android device, which then does something with that information. It's just a pair of doubles.
I've never had any experience doing much web communication aside from simple website/router stuff, so I realize this is a very inexperienced question-- but when I set up GCM on my two devices, what device is acting as the "server" and which as the "client"? Are both clients and Google is the server?
Thanks for any help.
I think you Want to Make Two side communication. you can Do One think that Save your RegistrationID of phone on to the Server. what ever the Data you want to communicate you should save it First to server. and whenever the Notification sent by the Server it will give information to perticular Client with using Registration ID.
Both android devices are considered clients. The clients will communicate with a backend server which can be implemented in a variety of ways. The sample that Google provides uses a standard web app written for the Java App Engine. You can find the example here:
Setting Up the Server
You can also write the server using ASP.NET, PHP, etc. What I typically will have on the backend is also a SQL database to manage the devices that are registered with my application. Each device (client) is given a unique ID from Google which the server will use to communicate. The server uses this ID because the messages it will send is not directly to the client but to GCM service. So in essence the Google GCM is a server to your backend server which is a client to GCM.
Hopefully this answers your questions regarding client/server communication. Please look at Googles demo for detailed implementation. Good luck!