So I am working with trying to transfer data between two phones with Google Nearby Connections.
For example, say I want to transfer a variable from each phone to another and then show a toast containing the text from the other phone.
I have been looking into the Connections API but I can't seem to limit it to when two phones are really close to each other. I have seen that the Nearby Messages API has an Earshot distance option.
But there isn't an option for earshot distance in the Nearby Connections API since the Nearby messages API doesn't seem to contain what I need to make something like the example above work.
Hope you can help me :)
There hadn't been a feature request for it until now, which is why there's no support in Nearby Connections.
I believe Nearby Messages would support your use case, though. It can exchange a few KB of data to other devices nearby. It's not a live bi-directional channel, like Nearby Connections is, but it doesn't sound like you need that.
Nearby connections uses bluetooth, BLE (Bluetooth Low Emissions) and WiFi. This signals can't be adjusted to reach a certain distance.
Nearby messages, on the other hand, also uses ultrasounds which can limit the phone's reach to a much shorter distance. See this video. It's also stated in the documentation of messages.
So your options are either fully offline connections without distance setting, or online messages with distance setting. Note that messages is not fully online, it only publishes the message to be shared in a google server. The key necessary to retrieve that message is sent offline between users.
I believe that your precise requirement for distance is what is being addressed in this Bluetooth Core Specification 5.1. Therefore, the solution is pending on:
Bluetooth hardware chips 5.1 will happen
Smartphone manufacturer will use these chips
Android Bluetooth library is updated to exploit the new feature of this chip
I'm working on an app at the moment for Android and iOS that uses Nearby Connections to communicate small amounts of data (like a string, character, or int) to other devices. I was originally looking into Nearby Messages but noticed that it needed an internet connection at all times to be able to send the messages to the google server and then to the targeted devices(s). That was not the functionality I wanted and saw that Nearby Connections was more appropriate.
However, unlike Nearby Messages, I could not find a way to limit the range at which the data can be sent like using DISTANCE_TYPE_EARSHOT. Currently, I believe it is always 100m which is ridiculously large and want to reduce it down to possibly a couple feet (maybe 5-10ft). Is this possible somehow with Nearby Connections or would I have to just work with Nearby Messages?
Thank you.
There is no way to limit the range.
Nearby Messages uses ultrasonic to exchange IDs in EARSHOT mode and there is a physical limitation of this kind of exchange.
But Nearby Connections uses radio and only way (very inaccurate) to limit is by signal strength, but Nearby Connection does not expose signal strength via its API.
But don't rely on ~100 meters you see in Nearby docs. As far as I know Nearby Connections only use Bluetooth for initial discovery, and this type of radio is often limited by ~30 meters.
I'm building a app to test Google Nearby Messages API. For that test, I'm using DISTANCE_TYPE_EARSHOT.
According to this thread Nearby API's Strategy.DISTANCE _TYPE_ EARSHOT doesn't seem to restrict message proximity , after the initial link between devices, they can receive messages for 10 minutes regardless of distance. I would like to know if this 10 minute limit can be interrupted (in order to prevent that a device can receive a message when its distance to another device is more than ~5ft - EARSHOT).
Alternatively, is there a way to get the distance between devices?
Thank you.
(I work on the Nearby API)
Today, Nearby doesn't expose distance directly nor does it provide a way to force "un-pairing" of devices programmatically. We've heard folks want both of these things, the features are on our radar, but we can't comment or commit beyond that.
As a manual hack, you can clear data on "Google Play Services" to un-pair devices.
You can get a rough approximation of distance by measuring BLE RSSI if one of the devices is capable of BLE advertising. This will be sensitive to how the device is held, antenna gain and environmental factors but better than random.
There's not a straight-forward "tape measure" API, though.
I'm trying to make a mobile application and I found ionic framework which seems cool.
It seems that REST is a common way to do things and I don't understand one thing with this protocol. How does the server notify that he has data to send. If we have a text application, how does the server notify the application (without push notification, or maybe they're mandatory ?) that another client sent you a message ?
It seems like REST is only good for the requests coming from the client. Does it means that I have to send request for update every X milliseconds to have a responsive application ? Do I have to use websockets for such purpose ? I also saw Comet, is it a good way to use rest ?
The REST architecture doesn't really address "Publication/Subscription" (pub/sub) paradigms. It's much more coarse than that.
The major issues with pub/sub are technical, especially today. In a fully connected internet where everything is online at known locations all the time, then the basic REST architecture just works. Simply, the roles of Client and Server swap back and forth (i.e. the Server becomes a Client when it needs to send an notification).
But that's not the real world.
The real world is while we have a lot of connected devices, we do not have a lot of known locations. Your phone moves around all the time, and who knows what IP address it's at at any one time. DNS doesn't help because your phone is likely not registered under any particular known name. Then there's infrastructure issues where the vast majority of clients are locked away to where they can send messages, but can not receive them, even if we did know who and where they were.
So, REST doesn't explore that area simply because it typically violates a few key attributes.
One is that the URL goes away. Since we don't know where or who you are, we can't get to you by name. So, one way folks get around it is through long lived connections. Your client hooks up to the server and retains its connection so that the server can talk back. But this is an implicitly stateful connection. REST drives towards statelessness, and is effectively connectionless at the architecture level.
So, in that environment, REST is not an appropriate architecture, since the mechanics can not support some of the fundamental precepts.
So I asked something similar yesterday and did receive an answer to my question, however I don't really think I asked it correctly and therefore didn't receive the exact information I needed.
I'm in search of an API, some open source code, or even just a way that someone else has achieved this on the Android. I'm making an app that needs to find all other Android devices within a specified radius. For example, when you open your Android Google Maps App, and you search for say "Restaurants [ZipCode]", it uses a radius modified from your zip code and finds all of those places. The GPS gets YOUR location, and maps uses that information to find restaurants within an address close to that passed in location.
Instead, I want to be able to use the GPS to find my location (as it can now easily), but instead of finding things on a map (which is already built in), I want to be able to find other GPS enabled Android phones. I get that they will have to be broadcasting their GPS signal at the same time as well (since they don't have their data stored with some sort of central database as a restaurant would). However, I don't just want to FIND these phones, I want to send/receive data from these phones (with correct permissions obviously).
Now, I've found things like the Bump API. However, BUMP uses the phones sensors to spark this search. So basically, if you "bump" your phone with another and have the app running, it will THEN go ahead and use GPS to find the location of the other phone you just bumped with and exchange data between them. This is like EXACTLY what I want to do however in their API, they do not provide the functionality to just say, "Hey, give me all phones within a mile from me."
I've also found API's that can do exactly what I need but they have to be on the same Bluetooth range or on the same Wi-Fi network, which doesn't suit what I need at all.
Do you guys know of anything that can fit exactly what I need that already exists? Or a way to maybe modify Bump API (if you've done it), to not have to use the phone sensors and find phone information directly through GPS for phones around you? Or is there something that exists over a 3g/4g network instead of only wi-fi/Bluetooth?
Thanks guys.
Instead of frequently posting locations to an external server, couldn't the GPS realize other things broadcasting a GPS signal at a very specific time and send/receive data from them?
The only things that are "broadcasting a GPS signal" are satellites.
We would like to accomplish this without the use of an external server.
You have no choice but to use an external server, whether you like it or not, both for discovery and for later communication.
Do you guys know of anything that can fit exactly what I need that already exists?
Foursquare, Google Latitude, Yahoo Fire Eagle, and so on.
To do this via GPS, you would have to have all the phones frequently posting their locations to a network server, which could then inform them of others nearby.
Needless to say this would be opt-in only!
And it may have negative consequences for battery life, unless you make it update infrequently, which may limit its usability.
The advantage of having an explicit trigger action to both phones is that they only need to query the GPS and inform the server to find each other by location when they've both been triggered.
You would probably have to author your own application - then you could do this server-side and push things. If you're trying to push data to random Android phones - you're out of luck. Most people aren't going to want this, and probably aren't going to have the apps necessary to receive and understand it. With Bluetooth networking you'd need authorization, and most Androids don't have a capability to transfer random data by Bluetooth out of the box (though you certainly can get software to do it).
Honestly, malware and tracking are the reasons this really isn't possible, but even if they weren't, you would still need an application on the receiving devices that understand what you're sending them. And if you're widely spread enough, you'd probably want to send it to a server to disseminate anyway (for the transmitting phones bandwidth costs at least).
Develop a server application that your android app logs into. Send the GPS location every time the phone moves over a present distance. Either send a query request to the server to ask it if any other phones are in range, or get the server to inform the phone of a new device in range.
You may run into server scalability problems, so thats something to think about.
Also, this would be a big battery drain, and so your users may not be too keen to run it, not to mention the privacy element.
You need to rethink what you're trying to do. Android devices don't "transmit" any GPS signal, they are simply receivers, with signals from satellites. So the phone can easily get a location for itself, but the location of other devices is very, very private information. To get access to location for other phones, you either need to be on the same network as them (bluetooth, wifi), or you need them to use a server-based service to send locations to, like Google Latitude.
I'd be highly unlikely to sign up to a service like that. My location is very private, I share it with some people, but I cannot seem myself openly sharing it with an app, without a very, very good reason.
It seems to me that you need to build a server-based application, e.g. on Google App Engine, have people sign up, and agree to their location being sent to that server, so other phones running your app can access that information from the central store.
The question now has a very simple solution to it. All you have to do is set up a Geofence and monitor it for entry and exit of users. Geofence allows you to choose a geolocation and set a circle of desired radius around it. When someone enters or exits the location you can get notified and perform desired action.
Visit this link for further details on how to use this in Android.
All the comments from other folks about not being able to pick up the signal from others phones are correct. There is a completely different alternative system however in the network based location services. This is a model where you ask a carrier network for the location of a handset, which the carrier network needs to track for enhanced 911 service in the US (I'm unaware of how widely deployed this is in other areas, and how many different services you would need to use to cover other areas).
It's potentially a very expensive route however. And it won't just automatically work for all handsets, I believe the users will have to be opted into sharing location with your service. This is how services like Loopt had initially setup their location info so that it could be passively collected without negatively impacting handset battery life. There are some third party services that front for a cross-carrier service such as Location Labs:
http://locationlabs.com/
As well as third party location services like Skyhook Wireless, who might be able to get you some info of the sort (though I don't think what you're looking for maps to any of their existing APIs)