I'm having the following scenario:
On the PC i will have a program running: java or .net, haven't decided yet.
When a certain event happens on PC i want to notify the android device.
I want a solution as independent and reliable as possible.
Opening a server on the PC/Android i think is out of the question because the user might be behind a router or on GSM internet (as far as i know it can't open ports as server)
The solution i have at this moment is to have a web server on the internet and have it handle the job, but i'd like not to use this because the delay between checks should be around 5 seconds, and i expect to have about 2-3k users simultaneously, and that will probably know down a regular web server.
So, any ideas how this communication can be made?
You may consider the option of Bluetooth client server application since PC and Android device usually have Bluetooth. You will have a Java server running on the PC and an Android client on the device. Check out this post: Send text through Bluetooth from Java Server to Android Client
You can handle the situation where Bluetooth is not available by creating a failover mechanism using REST API & JSON.
If you're already a web developer, I think creating a light HTTP based REST or JSON service would be a great solution. You've already said you don't want to do that which leaves the option of rolling your own client/server set up.
On the Android side of things, one way to do it would be to use TCP sockets. You can learn more about them here: http://developer.android.com/reference/java/net/Socket.html
Related
Actually i'm going to build an app that should show to the user some requests made by one or more local pc's, the user that will use that app will be able to decline or accept that requests.
Once the request has been declined or accepted by the user the app should "notify" the local pc of the user choice.
A real example would be the following: the app will be used by chain shop or single shop administrator the seller will be able to do just some things on his shop pc and to do other stuff he will need to request the permission to the admin that will accept or decline that request.
Actually i think i will need a server as i can't communicate directly to the local pc's (i won't open the pc's ports to communicate with them directly) but how should the local pc communicate with the app throw the server?
I was thinking about something like this:
LOCAL PC => request => SERVER so now the server have to notify the app and send the request data but how (?) once the request has been accepted or declined the app will send data back to server so APP => response => SERVER and here is another hole how can i notify the local pc about the response? should i check from local pc if there is the response on the server X seconds?
This is quite a complex question so I'm going to give you pointers to solutions rather then solutions themselves.
It seams that you'd need to have 3 programs in total:
A server
PC App
Android app
If you're writing it yourself I'd suggest sticking to one programming language - personally I'd recommend Kotlin since most Android apps are now being written in it, and is 100% compatible with Java.
Server should communicate using some protocol - REST is quite a good one in terms of speed and is very popular, so there should be plenty of tutorials online. Keep in mind that server should be aware that some requests should be done by user with a specific privilege, so that a hacker would not change Android app to mess around.
Both PC and Android app would communicate with the server using REST.
If you're going to write the PC App in Kotlin I'd recommend using TornadoFX as graphics library. Much better then Swing. If you want Java, then use JavaFX. Somewhere in that app there must be a thread that would be working constantly as long as the app is open (personal hint for the thread loop: while(!stopWorking)) and would ask the server if there are any new requests every X seconds. Don't bother with refresh buttons, they in my opinion are just distracting. You could even make a little "ping" noise sometimes when the app has been idle for a long time when a new request comes in so that the user can stop looking at facebook.
As for the Android app it's pretty much the same story. If you want the user to be notified when their request is ready you'd need to have a service running in the background constantly. For that you'd need to decide if you want it to start with the application, or with the phone (should the service be running after phone reboot or only after app is first started after reboot)
That is at least how I would have done it. If you really wanted to you could make it so that each PC application would also be server and when it opens and shuts down it would inform the central server that a new client is there for requests. So instead of PC app asking the main server about new requests often it can just wait until server sends it. That way both PC app and main server program would be client and server at the same time. However doing that with the Android app would be pointless. Also it's on the assumption that the PC app is not something that would be for the general public, but rather workers working in the shop.
Hope you find that helpful
I need some help in terms of choosing a design option for my problem.
I currently managed to implement a RaspberryPi acting as a Server and my local machine to act as the client. This client send JSON-Data to the Server which processes these. Everything is working as expected and I am using TCP-Sockets for the communication.
My problem:
The next step of my project will be, that I will use instead of a PC an Android-Device as client. What I want to achieve is, to send data to the server on the go. What I mean by that is, I do not want to restrict the server to be in a special network neither the client. What can be expected, is that server and client are next to each other, like in the range of a bluetooth connection. My question is, is there a relatively simple way to implement this communication? Is TCP a possible solution for this (even working in mobile networks?) or do I need to use Bluetooth, or is the way to go, to create some kind of network the client/server connects to and communicate here?
Sorry for propably stupid questions, but I am new to all this network stuff.
EDIT:
Since there were no respones, maybe I can do a more precise question. Is there a proper way to scan a network for a device name?
The only way I currently can imagine is to do a bruteforce like check on every IP-Address and resolve the names?
I first tried to let the Pi host an ad-hoc network, but it seems that non-rooted android smartphones do not have the possibility to access ad-hoc networks.
Therefore I made the Pi acting as an access point.
The communication now is very simple realized by a tcp server-client system.
I am working on a project that gives notifications to a web application when some phone sensors change their values rapidly. I am new to android and even though I know how to get the sensors values in my phone, I'm not sure how to transmit them to my pc server. I will look into sockets for network/bluetooth transmitting, but is there any way to send it via the internet ?
Basically, I want my application to work like this: I connect to my android application on phone, I shake the phone a bit and then on my web application on pc I get some notifications. I was looking around and I saw working with a python server?
How should I proceed here? Which method should I use?
Use HTTP/HTTPS on the Android Client to send to your server. As that will be the easiest to program and most reliably way to get data off the phone regardless of network type. See HttpURLConnection for details. Just do a POST with your data to the web address.
If you don't want to just construct a simple PHP, ASPX, or other web service on top of a readily available HTTP server, then you can use a variety of HTTP server modules for Python. SimpleHTTPServer for example.
I want to develop a client server application in which server is on PC having wifi and client application in on android phone. I want to make server application using vc++.Net and client application in android. I am newbie in network programming and i am unable to find any clue about this on internet. And I also don't know is it possible that server is made using vc++.net and client is made using android.
Can anybody please direct me how can i move for this. And if possible please provide me some links related to this.
Any help will be appreciated.
Your question is vague and open to a lot of potentially "correct" answers. First of all, the whole wifi v.s. internet part is irrelevant, you just want to communicate from your Android devices to your pc over the network.
The term to look for is sockets. What you do is listen to particular port on the PC (the "server"). You'll have to open up the relevant ports in the firewall.
You then write an android app that communicates with this server, see here for a proper introduction.
There is no problem using a single socket (ip address + port) to connect with multiple devices, as long as your protocol includes a way for each client to identify itself.
...
That said, you can also do all of this at a higher level, running a SOAP/JSON-based client/server scheme (as opposed to writing your own socket-based protocol). See http://wiebe-elsinga.com/blog/?p=405 for an example.
What is the most appropriate choice depends on your exact requirements (performance, deployment) and your level of experience.
Update
You can use jmDNS to achieve this. It's a really helpful library and once you detect the all devices connected to the same wifi you can get their ip and port so you can establish a connection. You can learn more about how to use it here.
Or you can use Android Wi-Fi Direct API which works only for API Level 14+. Here is more information about the API : Wifi-Direct.
how to achieve transfer file between client and server using java socket
Hope it is what you are looking for! : )
I'm building a multi-OS mirroring system which I would like to implement using a hybrid client-server and p2p communication method (at least that's the best way I have of describing it).
My issue is that at some point I have a central server (appengine, so there are limitations to what I could do because of time and networking capability constraints) that would need to get a message to a host of different devices which are not necessarily running the same OS (Windows, Android, iOS, Linux, etc...).
Android and iOS (or any other mobile platform) are the main problems it looks like I will be having on 2 levels.
1 - They are both limited by battery power (more so than a laptop and desktops shouldn't have that issue at all), so whichever method I use needs to take that into account.
2 - NAT (harder because the user has relatively less control over their firewall than on a network that they are running). My central server will maintain a table of which device has what IP address, but from what I understand if there is NAT or a firewall it won't be able to get to it if the port was not forwarded.
Since I will be writing a specific client for each OS I prefer a solution that is more universal. I have been leaning towards writing an extremely simple HTTP server that sits on each client and takes requests (which appengine is able to send) and treats them as messages that alert the client to perform an action (either with the server or another client). However, I run into the issue of NAT/firewall. For instance if appengine needs to send a message to AndroidDevice1 it would grab its IP address from a table and make a request to it. However this doesn't work if the ports aren't forwarded correctly, and if the user is on 3g/4g the firewall is controlled by the data provider.
Because of this, I started thinking about using Android C2DM but I want a solution I could implement across platforms.
The only other method I could think of is to just have the client poll the server for messages. This has the battery and network consumption issue though.
Would there be any other way to implement this, and if not, which one of the above methods are best in terms of balancing usability, power and data consumption and user input (the less the user has to do to get the client set up (ie port forwarding, etc...) the better)? Please note that I do not intend for this to become a discussion/flame war but a logical presentation of facts.
Thanks in advance!
You can create a persistent TCP connection from the device to the server and then communicate over this open connection. This would be a very simple connection with keepalive packets for the most part.
In theory this would consume some battery through the radio, but in practice I have experienced that the battery is not affected much at all. Key is to keep the communication over this line to a minimum.
If AppEngine does not allow this approach, you can run your own socket server and then communicate between this server and the appengine server using REST. A socket server I have used is Apache MINA and had no issues with scalability.
Another problem you will have with this approach or any other approach is that on iOS (afaik) you cannot keep a tcp socket open when the App goes into background. The only thing to communicate with the iOS device is Apple Push Notification Service
I would prefer rather than having HTTP Connection you should create TCP/IP tunnel and make communication fast and reliable. I have one Chat application which runs perfact for me using TCP/IP. If you use this you will have same logic for multiple platforms. Only thing you need to write is different code for iOS and android.