I want to build a data sharing application on android using wi-fi like "SHAREit" but I did not get where I start from.
So if any clear me the technical concept of "SHAREit" it was very much efficient to understand.
When we want to send a file we saw the available receiver device with name.
Is the name displayed as SSID or other?
How we broadcast name and other info to display on sender device?
When I select a device to send a file then what happens?
What API actually I can use to and what for please explain me simply.
Please all resources and links that I could run to test.
I've made an attempt to write a library called SHAREthem to simulate how SHAREit works.
Library facilitates P2P file sharing and transfers between devices using WiFi Hotspot. It also supports app to web sharing if receiver has no app installed. Hope it helps to you understand technicals involved in file sharing using WiFi Hotspot.
Since there are many moving parts to this library, i made a blog with implementation details. Will try to cover a few components here:
HotspotController
HC uses Java Reflection since there are NO APIs available on Android for enabling/disabling Hotspots. Functionalities include:
Controller creates an OPEN Wifi hotspot configuration with an SSID which can intercepted by Receivers to recognize SHAREthem senders including port and sender names.
Restores user Hotspot-Configuration when Share mode is disabled
Provides a list of connected WiFi clients.
SHAREthem Server
A tiny HTTP server extended from NanoHttpd, serves the sender data to receivers using IP address as hostname and works on port assigned by user or system by default.
SHAREthem Service
Android service which manages lifecycle of SHAREthem-server and also handles foreground notification with stop action.
UI (Activities)
Android activities to handle share/receive actions
Receiver - provides UI to list the files available to download. Posts
a download request to Android Download Manager to start file
downloads.
Sender - displays IP, Port & connected clients info along with file
transfer status for each connected client(Receiver).
Use the Android Wi-Fi P2P libaries, and start with the doc on this page. It tells you how use Wi-Fi P2P for service discovery, which takes care of item 1 in your requirements. Basically, you have each device transmit a DNS-SD TXT that can contain user ID info, etc. Devices can see its contents without having to establish a socket, which is what you will later do to accomplish item 2 in your requirements.
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.
I want to make an application is via WiFi would send and receive data without sending them to a specific recipient. I explained to the example of a simple chat: The user sends a message via WiFi, but without a specific destination. As a result, his report available to all users nearby. Similarly other users can receive and send messages. I also want to realize the function of repeater, where each user's device not only receives a message from the other devices, and retransmits them to others allowing increase the coverage area of WiFi connection.
But at the moment it is not possible to send data without a specific recipient. The same WiFi Direct necessarily require pairing before data transfer. Can not specify that the recipient is unknown.
Recently I heard the news about the technology WiFi Aware, which involves greater interaction between WiFI devices. Please reply, WiFi Aware allows to do what I described above? Namely - the transfer of data and we will without a clear indication of the recipient and the need to do additional work (eg preliminary pairing between devices).
If WiFi Aware allows to do what I described - when it is expected to release its API? In particular, for Android devices. And if not - you can tell me how to implement what I need? And in general - it is technically possible?
Thank you for your time and sorry for my bad English.
You should try to look into nsd via wifi-direct. This Network Service discovery via Wifi-Direct. What this helps you to achieve is broadcast information to all listening devices.
On the device which wants to convey the information you addLocalService and on the other devices you should discoverServices. In the ServiceInfo object you can the pass the information you want to communicate to the other devices who are listening for services. Please try to study from the link attached above.
I am not very sure about how repeater will work with this.
I'm implementing the wifi p2P (direct wifi) in my android application, in order to share small files between clients.
I'm following these pretty good tutorials:
http://developer.android.com/guide/topics/connectivity/wifip2p.html
http://developer.android.com/training/connect-devices-wirelessly/wifi-direct.html
I can now discover peers and connect to them.
I'd like to know if there is a way to filter the discovered peers. The first thing I'd like is to show only the peers who are using the same application. Indeed, currently my application show me all peers (phones, tablets, printers with direct wifi). I think it would be easier for the user to only have the compatible peers (peers also using the application).
If this work, I'd like to improve this and only show peers who ave accepted to share their files (a client can receive files or/and share their own files if he had activated it)
So, is it possible to do these types of peer filtering?
Thank you.
There is a way to achieve this ...
Adding Network Service Discovery (NSD) to your app allows your users to identify other devices on the local network that support the services your app requests. This is useful for a variety of peer-to-peer applications such as file sharing or multi-player gaming.
first you need to do
1.Register Your Service on the Network
2.Discover Services on the Network
3.Connect to Services on the Network
4.Unregister Your Service on Application Close
Take a look here.
So using NSD your app will only see devices that supports the services your app requests, cool isn't it..?
I will get back to you if I come up with some intelligent logic for the second part.
I have an Android device that has a WIFI adapter but no screen and no input devices. I want to use it as a silent server in my local network that runs / offers some services and will eventually be configurable via the internet. The service app will be pre-installed and launch upon boot. The problem is the initial configuration (mainly join the local WIFI network).
My idea is: Develop a Java GUI app that is used for the initial setup via USB.
Let's assume I get the desktop app to find and communicate with the Android service via the ADK (I will be happy to share here once I succeed). That way I will be able to use my screen & keyboard to configure it. Now the problem is:
How can I (on the Android device) obtain a list of WIFI netorks that the Android device finds and how can I tell it to connect to a selected network (with a provided password)?
Is there maybe a better way to achieve what I am trying to?
The WifiManager class should be helpful:
This class provides the primary API for managing all aspects of Wi-Fi connectivity. Get an instance of this class by calling Context.getSystemService(Context.WIFI_SERVICE). It deals with several categories of items:
The list of configured networks. The list can be viewed and updated, and attributes of individual entries can be modified.
The currently active Wi-Fi network, if any. Connectivity can be established or torn down, and dynamic information about the state of the network can be queried.
Results of access point scans, containing enough information to make decisions about what access point to connect to.
It defines the names of various Intent actions that are broadcast upon any sort of change in Wi-Fi state.
This is the API to use when performing Wi-Fi specific operations. To perform operations that pertain to network connectivity at an abstract level, use ConnectivityManager.
I am a little stumped. I've been trying to find a way for a wireless device (i.e. Android/ios/Windows mobile devices) to receive a message from a central server and then launch the device web browser.
The Scenario: a server on a WLAN network monitors a certain system. when something on the system goes wrong, the system stops what it is doing and sends an error message to the server and wait for the user to enter a response on the server before it resumes what it was doing.
Now, I want to send a message from the server(when the system it is monitoring crashes) to the wireless devices, so the user does not have to go to the server all the time to continue the system but can just do it over the wireless device (in the web browser).
Just to clarify, I know how to send a message out from the server to everybody connected to the wireless network, i just don't know what to do with that message on the devices...
Any ideas or solutions would be HIGHLY appreciated...
Thanks in advance
You can do this a few different ways:
1) Using commercially available Push Notifications (Google & Apple for example). The advantage is your application will work outside of your wireless LAN, but the disadvantage is you're using their platform, which is restricted in its ability and functionality (having designed and built a couple of these platforms myself I can attest to their limitations - they were going for "least common denominator" when they designed and implemented theirs).
2) If your app is only going to run on a LAN (you control the network) you can put your own system together. The advantage here is there is almost nothing that cannot be done (except on iOS which has several limitations related to the topic). The disadvantage, though, is this is a lot of work.
3) Leveraging an existing platform that might have been designed for a different purpose but can easily be used with minimal changes for your own purposes, and offers a nice compromise between options #1 and #2 (this will require some additional backend/middleware servers to add to your mix). Look at XMPP and Jabber as an example.
Once you have this piece of your architecture in place - receiving pushed data - the only missing item is invoking the handset's browser (or browser type component in your own native application) in response to the received payload.
** As possible alternatives it's worth noting that most mobile platforms allow your native application to directly interact with the handset's IMs or e-mails. For example, you can write code that intercepts a specifically formatted IM, with a small payload, and use that as a "poor man's push engine." I have put together little POCs (proof of concepts) for clients using this technique on Windows Mobile, BlackBerry, and Android (not sure what's possible with iOS in this regard) as it's quick and easy.
The hard part is the pushed data (but several available options on how to handle this requirement), the easy part is invoking the browser.