I am using LocationManager's requestLocationUpdates() to get the user's coordinates on opening the app, and it takes longer to get the coordinates than in other apps.
Getting location takes a while, however while my app is still loading and waiting for location (I am using LocationManager's requestLocationUpdates()) for much longer than other apps.
Here is a screenshot of my notification panel when I launch my application:
Notice it says Finding Location... when I open my app, because my app calls LocationManager's requestLocationUpdates() as soon as the app is opened.
Here's the meat of the question:
Even while this notification is in my presence, if I navigate to an app like google maps, it is able to pinpoint my exact location in a matter of seconds. Is that because google maps uses getLastLocation?
How come other apps are able to fetch location much faster than mine?
So there are two ways of getting location- fine (gps) and coarse (network). Google Play Services provides a 3rd method, but it uses a combo of those two. GPS takes a long time- it literally has to talk to 7 out of 2 dozen or so satellites to get a location for the first time. Network is fast, it just needs 1 network request (or less if data is cached).
A lot of apps will use both simultaneously, using the network to get a fast answer, and then improving to GPS when it gets that data. I know maps does this. This will get you a fast inaccurate answer, and allow you to improve the accuracy later.
You can use getLastKnownLoacation to go even quicker, but you have to be able to deal with it returning null. Generally network is fast enough.
Related
I want to write an application that it can record the wifi hotspot's location we are accessing and display them in map. But the problem is - how do I get wifi hotspot's location?
I think I can use the wifi signal to get the wifi hotspot's location, but it may not be very accuracy at first time. And if there is no other solution, I could record the location of GPS when access wifi hotspot at the first time.
You'll not be able to find the hotspots location and you'll not be able to determine the direction and distance from your current position to the actual hotspot.
The hotspots don't report their coordinates (my wifi box doesn't even know it's own geographical coordinates). Google captured hotspots during their streetview missions and used the results to triangulate the positions of wifi hotspots and other companies did the same to build up databases.
So to get the information, you'll need access to a database that knows the coordinates of hotspots.
TL;DR
Such services (1, 2) and apps exist and you can just be downloaded and/or readily used.
Technical possibilities of localization
A very rough localization is possible via the IP address. This technically (and not always) only allows you to find the location of the ISP through which the internet is accessed, not the AP/hotspot itself (since a certain IP address pool is assigned to a given ISP). However, unless a VPN is used, that will usually at least tell you the country and often be even accurate to less than 50km (since ISPs are usually somewhat close to the internet access node). Many readily avaiable services are available for this, simply searching for something along the lines of "ip to location API free" should yield good results.
As you thought yourself, and as other answers already mentioned (in vague terms), there is however a better (or at least additional) option. You could just use the many devices out there to record the received WiFi signals and associate the strength of the signal with locations. With such a database, you could then in turn located devices, based on the received signals. Actually there are several such services, most prominently the one created by google and used (and fed with data by) pretty much any android phone out there. Fortunately, some of these are open and free to use (and contribute to), such as the one provided by mozilla, and another one.
Cell towers (and according databases) often allows localization down to tens or hundreds of meters.
In some places dedicated bluetooth APs are used to increase localization accuracy, especially indoors.
If you have a lot of time (several hours to days) and a more-or-less accurate time, you can also use the light (from sun and moon) to get a location. Even with the simplest means you can get down to a few dozen kilometers.
Watching the inclination of geomagnetic field against center of gravity in combination with an according dataset (very inaccurate, but cheap).
Of course dedicated satellite navigation systems such as GPS (~5m), BeiDou (10m~10cm), Galileo (1m~1cm), GLONASS (7~3m), where the lower numbers in the brackets are commercial/military only-systems. However, each of these require dedicated receivers.
These satellite navigation systems are often augmented by Ground Based Augmentation Systems (GBAS), which require additional receivers.
So now you can pick and chose for your application, which of these are most useful to you.
I don't think so. I use iPod touch maps and Samsung Galaxy Wonder as hotspot. iPod could tell my location! My guess is Samsung stealthily follow Apple's doing of communicate geo info through wi-fi.
I am working on an android application and I want to make this app be able to tell me how many devices are connected to the current access point I am attached to. What is the best possible solution for this. I don't want the details of devices instead I just need the number of devices connected to a particular access point. I want to use this data for my web GUI which will show the utilization trend for each access point. Please suggest the way how to do this.
I'm writing an Android app that I would like to eventually port to iOS and Windows Mobile (though I know absolutely nothing about them right now). I'd like my app to be able to find other phones within a certain radius (maybe 20-30 feet) that also have the game installed so that the users can interact with others in their current physical space. Is this possible and, if so, how?
I plan on the app requiring an internet connection so my first thought was to use GPS like described at iOS Find Other Nearby Devices (GPS locations), but that would require continually transmitting data to the server to update the user's location using both bandwidth and battery (not to mention the server resources). GPS also seems to take a while to get any sort of accurate fix, and even though I wouldn't store historical data I wouldn't expect users to trust me with that sort of private information (as well they shouldn't!)
I know there are proprietary technologies, such as Sony's NFC, but that's far too narrow a focus to use for an app that I'd like to be device and OS agnostic. What other options are there? Assuming the user is willing to give the app the appropriate permissions, what other methods could allow one device to find another nearby one, within a 10-15 meter range, that is practical for a large (million+) userbase? Is HTML5 Geolocation a better path? Or is GPS my only real option?
I did find Use Android GPS to detect and connect with other phones, but was hoping the past few years have opened up further options.
UPDATE
Thank you for all the responses so far. To answer some questions posed in the comments and answers, I thought I'd describe how I expect the apps/devices to interact.
All users who install this app will have an agent running in the background to update their current geolocation and to listen for pings. Any user may open the full program and send a quick request for all other users nearby. If I go the central server route, then the server responds to that request with a list of nearby usernames. The user can then pick one of those to initiate a connection, in which case the target device makes a sound to notify of a request to connect.
From there it's easy enough to handle the interaction between two devices. Finding those nearby users is the sticking point for me.
Options I can see
Bluetooth (BT). I don't know, if I'm not too skeptical about it, but I see couple of problems. Short range. The biggest energy consumption. Maximum 7 peers connected at the same time (but maybe it's enough...). The big advantage is that a lot of devices support BT.
BT LE (low energy). Ok, it helps energy consumption problem. But, requires Android 4.3.
WiFi Direct (aka P2P). I gave it a shot, I'm a bit disappointed. The problem is that it needs Android 4.0 or higher. Even worse, some devices don't have required hardware. I launched WiFiDirectDemo from Android samples on Samsung Xperia Miro ST23i. Clicked on "search" and the only thing I got was a toast "enable WiFi P2P - in your settings". I clicked on everything in that settings, there is just normal WiFi and other stuff, no mention about Direct or P2P. Xperio Miro just doesn't support WiFi Direct.
WiFi connection with a server through internet + device geolocation. Server keeps positions of users and answers questions like "who is 20 feet in my range?". The problem can be the precision of geolocation. If the walls are thick or you are in a place on earth with few satellites - it can be very inaccurate.
To sum up
There is greater probability that somebody will have WiFi turned on all the time than BT. BT also have some time limits after which it is turned off (they make it this way to probably save battery). So, WiFi seems a better choice than BT.
If WiFi Direct is popular enough for you - I would give it a try. If not, option number 4 seems the best. It's not ideal, I know, but at this point it's hard to come with something better (we still need technology development, WiFi Direct looks promising).
I would use the central server approach. Each phone sends position data to the server. The server notifies the other users when they are in range. To limit used data, only send positions when the device reports movement more then X meters.
Also, consider using a Ping button. The user presses it to send the position when they wish to find someone nearby. Position data would only be sent on this ping. This would use very little power and provide good privacy.
It might be possible to detect details about the connected Wifi access point. If you could get the AP or Gateway's MAC address, you could send that as a kind of position. All the players on the same Gateway would be close by.
We want to implement a back end server [Java EE] for mobile application that sends notification to mobile on some events, I'm asking about the best/simplest approach whether Pushing or Pulling notifications, here you are my ideas/questions
1- The requirement is to send instantly the notifications to the mobile as long as the application is running no need to send if it's not running
2- I read that to push notifications to IOS or Android, I will need to connect to apple/google notifications servers, I felt that this is complicated especially that it requires low level socket programming, but based on number 1 and the project has limited time and budget, do we really need pushing ? and is it really complex
3- I read that pulling date may drain battery and consume data, but what if implementing a simple job on the mobile that runs only 3 or 4 times a day, invoking a simple web service on back end server asking for the notifications
P.S will be much appreciated if you can provide some tutorials for similar cases :)
1) If you're application is already running, is it connecting to the same location anyways? If so you might as well pull for the notifications at that point. However, if the app isn't actively connecting, i would attempt to avoid pulling.
2) Interacting with Notification servers on google and apple site directly, can indeed be a cumbersome task. However there are companies that have made this much easier for you. The advantage of using companies like urbanairship, xtify and mblox will get you started with sending push messages in minutes. (for an example take a look at http://developer.mblox.com/docs/ in the tutorial section).
3) depending on the data you try to present, end users now a days are used to instant data. I can't imagine a service whereby pulling 3 to 4 times a day is sufficient, however if your use case is truly limited to 4 times a day, and there is no other activity going on in the background process you create for this, you might as well have the background process running. But do think this through carefully... If at any point in time you want to increase the number of times a day you read, you might soon get to the point where a rewrite is needed to ensure end user satisfaction.
I'm in the process of starting a new Android project that will:
Display a Google map
Track and record users movements
Display the route on the map
Show local points on interest on the map
My question is what extra tools will I need to accomplish this? I can already get a basic Google Map working with zoom controls and place overlays etc. but my main concern is how I will track the users movements. I was thinking there maybe some sort of fleet management API but I really have no idea.
A link to some sort of tutorial would be great or even just to possible tools.
Use the class http://developer.android.com/reference/android/location/LocationManager.html to obtain the device geographical location
A Caltrans planning grant went towards creating an Android app called CycleTracks that does all of your bulleted items except the last one about points of interest.
You can download the source code here: http://www.sfcta.org/downloads/cycletracks/CycleTracks-android.zip
I haven't looked at the license to see how free you are to use it as a starting point, but I have to imagine it might be helpful just to be able to look at it even if the license is restrictive.
You can read more about it at http://www.sfcta.org/content/view/666/375.
You don't need any extra tools. Use the GPS or radio cells to get the location of the phone. This thread explains how you can get the location:
How do I get the current GPS location programmatically in Android?
If you want to Track the users movement you'll need to run a webservice on a server and have the app report the location of a user at regular intervals.
Be careful though, if you don't tell the user this is what you are doing, and provide an opt out, you could be pulled from the market pretty quickly.
Be sure you aren't recording any sensitive information as well. Usually position, phone type and OS type is allowed but much more could get you in trouble.