I'm currently searching for a way to transfer a String array from one android to another through the internet (assuming both devices are connected to the internet).
There's the possibility that one (or both) of the devices is connected to a network which is provided by a router, therefore using the IP address isn't practical (as far as I know).
I've stumbled upon an idea which suggests using Email to transfer the data. but, if I'm not wrong, that will force me to translate the array to an Email, send it, and undo the translation (to get it back to a string array form).
I would prefer a solution that will transfer the String array as it is.
Is it possible? Is there a better way to executed this process?
(I'm developing in Java on the Eclipse IDE)
I'd be glad to hear your Ideas! (:
Several options:
Device A sends an HTTP Request to the web server, Device B regularly gets data( using timer ) by sending request to fetch message sent to him. But this is not really real-time.
Device A sends an HTTP Request to the web server, The Server Pushs to Device B. You need to implement Push using Comet or GWT.Comet wiki
Implement XMPP Messaging. Device A send an XMPP Request, Server push to Device B. XMPP wiki
If I were you, I will do no 3. Since your explanation sounds more related to real-time messaging case. Please forget thinking about using email.
Related
I currently am developing a semi-simple chat app. I want the user to be able to communicate with one other person in a private chat. Just plain text will be sent. Currently my system calls php scripts from a webpage, passes in parameters and then parses the data returned. I have it so that the client sends the message, which calls a send message script on my webserver, the script then makes a message file on the webserver and then returns a success or failure back to the client. Then for the client to view this message, it would have to call a script that checks the server for a message file with a message for him. If it finds one, it sends the message back, if not, it sends a response about not having messages.
This technique works perfectly besides the fact that the client either would have to manually refresh to check to see if he had messages, or a background thread would have to refresh every few seconds. That would be fine, however that would use data if the user was on a mobile network. Not to mention the kind of resources a background loop would pull if it was refreshing at a speed that would be convenient.
So, I decided on a second idea, this would be a server programmed in Java, which would communicate over sockets. The user would send the message as a packet over the socket and the server would check to see who it was meant to go to. If the person is online, it passes the message along to that user. However this method requires a constant connection between the client and the server and that is unreliable because what if the user is in the car and data cuts out. Or some other situation where the connection gets severed. Then it would throw errors and have to reconnect.
Anyhow, my question is which technique is better. Or are they both terrible? If so, what is the correct way of doing this? Thanks in advance.
AngularJs and Ajax will be the perfect solution for you , try to learn
for actually real time messaging Use AngularJs
If the amount of data is very less ..say 20-25 messages per day...you can REST APIs on your server to transfer actual text messages and Google Cloud messaging for pushing notifications..Recently I followed this approach to develop private chat for one of my friend.
I currently have an small application that I have been using to learn java/android programming. Right now I have a setup were the app on one phone sends a request (via sms) to another phone running the same app. The remote phone receives the request and sends back some info. Next I would like to try this from the web. Is there an established "best" way to to this?
I was thinking I would have a web server send requests to the device via google cloud messaging and then have the device return the data directly to the web server. (Not that I really know how to do any of that just yet).
I see that there is a google cloud messaging return path (send messages from the device to the google cloud server, but it seems very new, do I need something like that? The main thing I want is to be able to ask the phone to do something when I want, not have it poll to see if there is a request, or just periodically update some status.
UPDATE:
Thanks to the answers below for confirming to me that I was on the right track.
I now have some basic functionality.
I started out using this gcm android demo code
https://code.google.com/p/gcm/source/browse/#git%2Fgcm-client%2Fsrc%2Fcom%2Fgoogle%2Fandroid%2Fgcm%2Fdemo%2Fapp%253Fstate%253Dclosed
and this ruby gem
https://github.com/spacialdb/gcm/blob/master/README.md
between the above two I was able to send a message to my phone pretty easily.
To get the round trip working, I setup a very simple rails app on heroku.
I included a modified version of the sample code in the gcm gem in a controller and then used
HttpPatch (needed for rails 4) to send a post/patch from my phone to my web app, the controller then echoes the message back to my phone.
I guess it would be nice to get the two way gcm stuff to work, but I am not sure there are any gems that handle that, and I am not qualified to handle a task like that :)
I would say it's the right call: Google Cloud Messaging for Android
From the site Android Developer:
This could be a lightweight message telling your app there is new data
to be fetched from the server (for instance, a movie uploaded by a
friend), or it could be a message containing up to 4kb of payload data
(so apps like instant messaging can consume the message directly).
In this case you don't want to fetch data from the server but you want to send them.
You can send them in different ways. I would suggest, since you are learning, to try a RESTful solution using one of the implementation of JAX-RS.
As a short and direct answer for beginner : GCM (Google Cloud Messaging) would solve your issue. However, if your app turned out to be something bigger, other more technical and complicated solutions are present too.
see this link.
I'd greatly appreciate some help on this question. So, I have a device that is going to push some data in XML format using the http protocol. I give the device a URL and it pushes data to my program. I apologize for being vague but I am curious as to how to start?
I want to implement the server side of this equation, the device being the client!
There are many approach, here is a leak of info a bit and confused desire.
XML aren't optimized for mobile communication, use JSON, because has less overhead.
If the device want to send data to server, than I like to use HTTP POST and implement a something on server side to receive it, aka web service, or just a java servlet , or a simple php file...
If the server want to send something to device, than the server should use Push notification, but the payload isn't there ( the xml) , just a notification and the device will pull the xml from server, for eg via HTTP GET.
There are many other cases and imlementations: RMI, SOAP, ...sockets,... alot
I am developing an Android App that communicates with a server.
How can I send a notification from my server to my Android App without the use of C2DM?
Are Sockets a good solution? What are other alternatives?
I'd suggest you to develop a webservice preferably with JSON which is easy to handle. This server client architecture will hellp you to send and receive any kind of data (ranges from raw text to images or even video)
Check out C# webservices. That are very easy to start than the PHP services IMHO.
Depends on what you want to do.
have you thought on how does the server identifies the client to send the message ? In this case the android phone ?
With http you would need the client to "request" this notification.
The closest thing to an actual notification would be to have a socket connection, which the client would connect to the server. But then would require an existent connection between the two. If this is ok for what you are doing, then go ahead if you really want to avoid C2DM.
But, using C2DM allows your server to send notification to devices without a need for a request or direct connection from the client. The only thing you need to do is pass the identification of the device to your third-party server given when you authenticate with google's C2DM. After that, you just push notification data to C2DM and google delivers the notification for you.
I've used MQTT for providing push notifications on Android and it's proved to be a good, reliable, low power solution.
Some links to support my case / get you started:
http://mqtt.org/
Power Profiling: MQTT on Android
Basic Steps for Using MQTT in android
Do you need to use some kind of provider?
Can you setup your own SMS server?
Does any open source solutions exist?
I am an SMS newbie so any insight on how this is accomplished would be great. I am partial to Java but any language is fine.
This is easy. Yes, you need a "sms gateway" provider. There are a lot out there. These companies provide APIs for you to send/receive SMS.
e.g. the German company Mobilant provides an easy API. If you want to receive a SMS just program a simple PHP / JSP / s.th.else dynamic web page and let Mobilant call it.
e.g.
Mobilant receives a SMS for you
Mobilant calls your web page http://yourpage.com/receive.php?message=...
You do what you need to do
You really don't want to setup your own SMS Server or Center ;-) This is really expensive, takes months to setup and costs some nice ferraris.
Use a provider and pay per SMS. It's the cheapest and fastest way.
I used kannel on a linux box with an old mobile phone connected via a serial cable to the box. Got a pre-paid card in the phone as I was using it for private use only. Worked like a charm!
You might take a look at Gammu if you're running on a Linux box:
http://www.gammu.org
Using Gammu, you can configure it to periodically poll a mobile phone for new SMS messages. When Gammu finds new messages, it can store them in an SQL database. You can then write another program to periodically poll the database and take action on new messages.
Using this general setup I successfully deployed a homemade 2-way SMS application. I configured Gammu to pull messages off of the phone over Bluetooth. Gammu placed them in a MySQL database, which I had a Tomcat web application periodically poll for new messages. When a new message was found, the system processed the message.
This is a somewhat "duct-tape and bailing wire" setup, but it worked quite well and was more reliable than many of the "professional" SMS gateways I tested beforehand. YMMV.
We've used mBlox (http://www.mblox) in the past, as they provide comprehensive international coverage, premium SMS, various levels of Quality of Service vs Price, and a solid Java-based API for both inbound and outbound SMS.
You will need an SMS gateway, googling "SMS gateway" will reveal many. I have used http://www.clickatell.com/products/sms_gateway.php with great success.
I do not know of any open source implementations, but will be monitoring this thread in case someone else does!
First, you need an SMS gateway. Take a look at Kannel SMS Gateway.
Agreed with Kannel. You can set it up on a LAMP server with a GSM modem too.
I'm not up with Java, so here's a nice guide on how to do it in Ruby on Rails: http://www.lukeredpath.co.uk/2007/8/29/sending-sms-messages-from-your-rails-application
If you want to send 'true' SMS you'll need to use an SMS gateway, (use of one is outlined in the above guide).
You can use MMS to send messages, to an email address that looks something like 1234567890# messages.whatever.com. You can use mail functions to do this. There's some information about that here: http://contentdeveloper.com/2006/06/open-source-sms-text-messaging-application/
TextMarks provides a service where they map an incoming SMS to them to an HTTP GET to a URL you provide and then send the response back as another SMS. They don't charge you if you let them add some advertising to the reply SMS. The problem is they don't provide this for free anymore for T-Mobile due to T-Mobile charging them. I'd be willing to pay per message, but they charge $0.20 per user-month, which is rather steep. Anyone know of anyone who provides this service?
You actually don't need an SMS gateway; nearly every cell phone can send/receive SMS messages to/from any email address. I built an SMS service (http://www.txtreg.net) using Nearly Free Speech's ability to forward email to a URL as a POST request. User sends a text to an email address, PHP script processes it, and sends an email right back to their phone.
Try SMS Enabler software. To receive SMS messages it uses a 3G/4G/GSM USB modem connected to a pc. It can forward incoming messages to a URL over HTTP, or store them in a database table, or write them to a CSV file, in real-time.