can anyone in simple words explain me the need of UUID in android bluetooth example. I have read some articles about it but it is still not getting clear the exact need of UUID.
And now let me explain you the scenario of what I want to develop:
I want to develop an android application to transfer data for example a "FILE with .xyz extension"
from my phone to the other phone over bluetooth. IT IS NOT AT ALL NECESSARY THAT THE RECEIVING PHONE SHOULD ALSO HAVE THE APPLICATION THAT I AM USING. I just want to transfer data from my application to other phone and thats it. I don't care what the receiver does with the data.
I just want to connect to a device within range and transfer that file using my application
Now how should I do this? Where does the the role of UUID come here? I have read that UUID is for my application , and both the server and the receiver should be aware of this UUID to form a connection . But what if the receiver does not have the my application? It will surely not know my Applications UUID ? then how the data transfer will be possible? I simply want to use Bluetooth without concerning a specific application.
In here, what my application should be doing? Should it be creating a server socket / a client socket or what? and Why.
An explanation in simple words is appreciated(some articles if possible). I dont want regular answers having BluetoothChat suggestions. If you don't understand the question please let me know, I will try to be more specific and elaborate it for you.
The basic goal of this question is to clarify the use of UUID and transfer data between two DEVICES (and not an application) using bluetooth from an application running on one android phone.
Even with bluetooth you can create a client-server application.. there is a BluetoothSocket
read here http://developer.android.com/reference/android/bluetooth/BluetoothSocket.html
Now, lets say you have two devices:
device A
device B
and assume that device A sending data to device B, You didn't say if device B is also sending data to device A, so I'll just describe the first scenario when A send to B.
So in that case, since all the data is stored in device A and you want to send it to device B, it will be more reasonable to create device A as a BluetoothServer and device B as BluetoothClient which listening to the server.
But.. If you want both of devices will exchange data.. you can make one of them as a server
and for each one of them create 2 threads:
Thread that sends data
thread that listening to data
so both of them can exchange data..
Another thing.. if you ever programmed a regular client server you noticed the accept() method which is blocking until there is a client which connected to server.. the same is with Bluetooth client-server application.
Summarize:
One device will act as a server - so you'll need to write a server project and install
it on the first device
Second device will act as a client - so you'll need to write a client project and
install it on the second device
Don't forget to add the bluetooth permission in the manifest file for both
projects.
Both of the projects need the same UUID as you mentioned in your question.
in simple words both of the sides need the UUID so they each know with who they're
communicate
I think it's more like a port in a regular client-server..
I read somewhere that is used for RFC communication.. as you probably know there are
some protocols for Bluetooth like RFC,SDP and etc..
EDIT:
In most of the phones there is a pairing process when you want to send data through
bluethooth. so if you don't want to use the client-server version, I think you can
do this:
Your application will search for devices to connect to. (pairing process)
After pairing you are connected to the other device and just send the data
EDIT 2:
You want to send data from A to B right?
I'll explain more clearly..
You're right when you said the client should know who is the server and need insert the port and
the IP of the server this is correct and works in this way.
Now, look..
The server listen to connection from clients, when a connection established the communication
begins.
Client ask for data
The server processing the client request and send him the related data
So any data like: Files, Databases should be stored on the server side..
Now in your case, the files you want to send are located in device A and not in device B,
So if device A is the server he will listen for connections.. when device B connects to the server
(device A) the communication begins.. Device B can request for files from Device A..
Also, since device A is the server, he can even broadcast a message.. means send the same message
for all clients which are connected to him.
But what you're want to do is to send file even if device b didn't ask for it, right?
I don't understand if you want that device B will also send file to device A, so lets divide it
into scenarios:
just device A send to B:
In this case, since the files are located in device A, means device A have the data,
device A is the server and device B is the client.
So when connection established you can send from A to B.
Both devices exchange data:
In this case, both devices should listen to each other, but just one of the should act
as a server and the other as a client. means that you need to install the serverApp on
one of them and the clientApp on the other.
But each of them can send and listen to other. so for each of the you need to create
thread that handle with the sending data and another thread that handles the receiving data
UUID is the Universal Unique Identifier. When you want to connect to any of the service that bluetooth is exposing then you should have the UUID to tell to the bluetooth software module that it has to inititae connection to this particular service. In your case in order to send file from DevA to DevB it has to use File Transfer Profile and there is specific uuid which is associated with this and this is defined by Bluetooth SIG which is the authority which qualifies bluetooth products and works on the technology. This is known by all the devices which uses bluetooth.
Tu cut the story in short when DevB receives the incoming connection request with the uuid which is unique it comes to know to which particular service of DevB the device is trying to connect to and it connects to that service. Hence if you want to send file from DevA to DevB then you need not have the same application at DevB. But you need to make sure that you use the UUID which is specified for File Transfer profile by Bluetooth SIG.
Regards,
Shripathi
Related
just want to know is there any methods to allow 2 different apps to communicate. Both of the apps are installed on different devices as well. I had gone throught quite a lot of research, but seem that INTENT, BROADCAST RECEIVER failed to meet my scenario. INTENT, BROADCAST RECEIVER can be work if both of the apps installed on the same device.
Here i can say you can use to make your things work :-
Sockets are typically used to accomplish this between Android devices (or between any peer devices).
When two devices desire to interact, you configure one or both of them to "listen" for connections on a socket and accept a connection from the other when that happens (or you can have a dedicated client and server and the client always initiates the connections).
You can exchange messages after the link has been made.
Android client server socket applications come in a variety of forms, but one that I found handy was:
Example of Android Server/Client using Socket on the client side (and its companion server side blog article - link included in the client blog)
It should be noted that you might need to add your own "protocol" on top of this. For instance, if you are sending a file that is unknown in length without a special "end" character, you might want to add a byte (or several bytes to represent an int, long, etc.) at the beginning to indicate the length of the transmission so the receiving side can tell when it has received everything (or that it has not received everything in case of an error).
connecting via networks (such as most 3G/4G) that forbid inbound connections
Even though there is nothing theoretically blocking sockets from functioning in these situations, many mobile operators will not permit inbound socket connections in practise. You would also need to determine the mobile's public IP address, which is doable but adds complexity. Whether your solution will only ever operate on a single operator's network, you can test it out to see if it works; but, if it doesn't, you could discover that using a server in the "middle" is preferable and easier: Devices A and B establish connections with servers Device A "discovers" device B after requesting the addresses of connected devices from the server. Device A sends device B a message.
Actually, it indicates that the messages should be forwarded to device B while sending them to the server. Device B is informed by the server that a message is available for it (using some sort of message notification like Google Cloud Messaging for example, or simply by the devices polling regularly to see if they have any messages). Device B accesses the server and downloads the messages. The aforementioned will function on pretty much any network that permits internet connectivity. It does have the drawback of having a server, but for the majority of mobile networks, it is probably a necessary approach.
You make one app a server using ServerSocket.
You make the other app a client using a Socket.
With both devices in the same network the client can connect to the server knowing its local ip.
After connection established they can communicate.
Let's say we have 2 bluetooth devices, 1 is some device that emits data and the other one is an Android device. Now in the android device, there will be more than 1 app that may run at the same time and would like to listen to that bluetooth connection and process the data received. Is this possible? Or any restriction?
Assuming you're talking about official, non root android firmwares: no you cannot share memory locations assigned to your application variables(in your case a bluetooth socket inputstream) with other applications.
You can however create one bluetooth client connection in one app, receive the data and then share the data with other applications or services using network sockets or named pipes or files...;
when a certain condition is true, I need to send a message to a certain device that has my app installed.
How can I realize it? E.g. A klicks on the name B, B shall get an AlertDialog that A clicked on his name. I know that I will need something like a deviceID. But what else?
You don't need a device ID, you need a server that handles the communiation between the two devices.
In order for a device (A) to communicate directly to another device (B) without a server, A needs to know who B is and how to reach it.
You could do that either with an SMS and the only thing you need to know about B is its phone number, but I guess this is not what you want to hear.
The other options is through a TCP/IP network. A would need to know B's IP address, which is something almost unfeasible, unless both devices are connected to the same network, probably via WiFi, and even so, there's no direct way to know B's address.
The usual solution is that both devices connect to a server through the network, using a particular protocol. When A want's to send a message to B, it does it through the server, which forward the request to B (since B is also connected to the server). In order to identify the devices you can use any information bit you want (it can be a user name, such as in chat systems, it can be the device ID which is not very reliable...)
If the recipient device currently has your app running and is connected, then the app you would presumably maintain a connection to a server or implement polling by the app.
For a non-running recipient app, you'll either have to utilize a standard messaging protocol (SMS, email, etc.). Or you will have to implement a background service in your app that periodically wakes up and polls a server that maintains the messages. This is how Twitter, Facebook, etc. work.
Just to be clear, opening or maintaining direct network connections between multiple devices not on the same local network is not really doable.
You need to poll the app you want to send something to.
As the topic name suggests, what I am looking for is to add my android app the option to send data to a different phone running the same application so the receiving phone will process it accordingly.
The obvious option for me was to use app engine and use push notification with the phone number acting as the identifier.
Does a simpler solution exist?
Thanks ahead :)
The best and most robust solution is to have something like your messaging clients, in which Device A sends data to the server, which pushes it to Device B. Device B sends a reply to the server, which pushes it to Device A.
This process has the advantage of retrying the sending without requiring your users to stay connected, as may be required if Device B is offline when A sends a message.
A less foolproof solution is to have a server work as a middle man, and get each device's IP Address, and then open up a direct socket between them. In this solution, you'll lose any data that doesn't make it through.
If the devices are on the same network or in Bluetooth range, you could try Bluetooth or WiFi direct.
I am into a project for my college purpose. For that purpose i have to create 2 applications (1 ACTIVITY app and another SERVICE app) which will be installed in 2 different mobiles. I want to create communication b/w those 2 apps, i.e when i request data from the activity app the service app in other mobile should respond and reply the data i require...
This is only possible if you pass and receive the data through some form of communication channel, like Bluetooh or WiFi.
The best idea I feel would be to have a server that acts as a middleman. One device sends data to the server, and the server sends the data to the other device via Push Notifications. Or you could use the server as a middleman to open a socket directly between both the devices, but this has the disadvantage of not being able to resend messages easily if the first send fails.