What's wrong with this location code?

by Anna PS » Thu, 15 Apr 2010 23:35:23 GMT


Sponsored Links
 oe - I'm still struggling to write some code that can reliably get me
an accurate location fix.

I have written some code that I thought would (i) register with any
available location listener (ii) at onLocationChanged events, check
the location fixes for age and accuracy (iii) once a suitable location
fix was obtained, start an upload, and unregister the location
listeners.

However, it seems to get into a situation sometimes where
onLocationChanged isn't called at all. Yet in my log files, I can
still see the Android NetworkLocationProvider logging
onCellLocationChanged events. Is this a bug in my code?

The code and logs are below. Many thanks for your help.

LocationManager locationmanager = null;
LocationListener[] listener;
Location location;
private Double latitude, longitude;
private String latString = null, lonString = null;
long firstGPSFixTime = 0, latestGPSFixTime = 0;
int locAccuracy;
long locationTimeStored = 0;
public Boolean locationDetermined = false;

@Override
protected void onCreate(Bundle savedInstanceState) {
Log.d(LOG_TAG, "onCreate");
super.onCreate(savedInstanceState);
setContentView(R.layout.interstitial);
extras = getIntent().getExtras();
name = extras.getString("name");
//Check whether the upload is under way already - we don't want
things to upload multiple times...
if (savedInstanceState == null) {
upload_under_way = false;
} else {
upload_under_way =
savedInstanceState.getBoolean("upload_under_way");
}
// if it's not, attempt to get a location fix, and
show a notification
if (!upload_under_way) {
testProviders();
mNotificationManager =

(NotificationManager)getSystemService(NOTIFICATION_SERVICE);
showNotification();
}
}

//
**************************************************************************
// Register with any available provider, and start checking updates
//
**************************************************************************

public boolean testProviders() {
Log.e(LOG_TAG, "testProviders");
String location_context = Context.LOCATION_SERVICE;
locationmanager = (LocationManager)
getSystemService(location_context);
Location lastLocation = null;
providers = locationmanager.getProviders(true);
listener = new LocationListener[10]; //horrible code
int i = 0;
//register with any available provider, and start
checking updates
for (String provider : providers) {
Log.e(LOG_TAG, "registering with provider " + provider);
listener[i] = new LocationListener() {
public void onLocationChanged(Location
location) {
Log.e(LOG_TAG, "onLocationChanged");
if (!locationDetermined) {



What's wrong with this location code?

by JP » Fri, 16 Apr 2010 07:46:08 GMT


 


Without diving into your code. Double check it by using GPS. GPS is
considerably more accurate than base station based triangulation,
which may not result in location changes even if you move a hundred
meters (in my experience, anyway).

--


Sponsored Links


What's wrong with this location code?

by Anna PS » Sat, 17 Apr 2010 06:41:23 GMT


 




The basic issue is this. I don't want to accidentally end up with a
LastKnownLocation that's days out of date, so I have to check the age
of the location fix.

Since the GPS time (from location.getTime()) and the system time can
be quite different (as <a href=" http://www.mail-archive.com/android- 
develop...@googlegroups.com/msg47517.html">discussed here</a>,
comparing the two doesn't work. The only reliable way seems to be:

- get an initial location from getLastKnownLocation
- wait for a location update from onLocationChanged
- compare the age of the two to make sure the latter is newer.

However, I'd also like to write code that handles gracefully the
possibility that the user is (say) indoors, and therefore won't get an
onLocationChanged event at all. (In which case, we should just take
the LastKnownLocation, and never mind if it's out of date.)

I seem to be at a logical impasse. What can I do? I can't wait for an
onLocationChanged event if it's never going to happen - my code will
hang forever! But equally I can't just take getLastKnownLocation every
time - it might be wildly inaccurate.

Maybe I need to run some kind of timer in the code, to check how long
we've been waiting for an onLocationChanged. Does that seem like the
best idea?

--



What's wrong with this location code?

by JP » Sat, 17 Apr 2010 09:06:43 GMT


 What I do.
I never even look at lastKnownLocation; as you state it might be old
like dustballs.
This means I will only process locations received fresh from
onLocationChanged().
As you note, this may never happen. So keep users informed
accordingly! If you couldn't acquire a fix, let the user know.








>



What's wrong with this location code?

by patbenatar » Sat, 17 Apr 2010 14:39:00 GMT


  have solved this problem [with much thanks to the brains on this
group] by running two LocationListeners side-by-side, one fine [GPS]
and one coarse [Network]. The first provider to get a location update
wins and I use that location. This works for me as I don't care about
the location being super accurate at this point [later in my app I
allow the listeners to run their lives and whenever GPS is active and
available I use its updates then if it goes unavailable/disabled I
allow Network to take over [the whole while I'm running the two
listeners side-by-side, and just not handling updates from Network if
GPS is active/available].

You really have no reason to have a LocationListener[10] array...
There are really only two location providers, Network and GPS. So all
you need are two LocationListeners: fineLocationListener and
coarseLocationListener.

Here, this is the thread in which I learned how to do this:
http://groups.google.com/group/android-developers/browse_thread/thread/99ebef7294b094d5/6945dab119f1bf67
.. its a pretty good discussion on LocationListeners.

Hope this helps!

-Nick


On Apr 16, 6:06pm, JP <joachim.pfeif...@gmail.com> wrote:
> >



What's wrong with this location code?

by patbenatar » Sat, 17 Apr 2010 15:22:20 GMT


 h, also... If a GPS fix is all you will accept, firstly your app will
not work in big buildings, under tunnels, dense metro areas [San
Francisco, NYC, etc] or anywhere like that where 3 GPS satellites are
not accessible. Secondly, if you can't get a fix after some sort of
realistic timeout, you'll need to notify the user of this so they're
not waiting around while your app repeatedly fails to get a GPS fix.

To expand on my above post, I would definitely recommend using both
listeners side-by-side but just always giving precedence to GPS
updates. This fixes many problems: 1) You'll pretty much always be
able to get some sort of fix. 2) In cities where GPS may unavailable,
there are likely lots of cell towers so cell triangulation will be
quite accurate [In Los Angeles, I've seen a Network fix be merely tens
of meters off from a GPS fix]. 3) In rural areas where cell towers are
few and far between, GPS is likely accessible [not many tall
buildings] so you'll be able to use that accurate fix.

-Nick



On Apr 16, 11:38pm, patbenatar <patbena...@gmail.com> wrote:
> > >



What's wrong with this location code?

by Michael Thomas » Sun, 18 Apr 2010 06:54:05 GMT


 

You really have no reason to have a LocationListener[10] array... There are really only two location providers, Network and GPS. So all you need are two LocationListeners: fineLocationListener and coarseLocationListener.
Perhaps you are forgetting about the chain and theodolite provider. Mike ;-) --



What's wrong with this location code?

by patbenatar » Sun, 18 Apr 2010 09:56:44 GMT


 > Perhaps you are forgetting about the chain and theodolite provider.

Mike-

What are those? The LocationManager class only has these two provider
constants: GPS_PROVIDER, NETWORK_PROVIDER.

Thanks!
Nick








>



What's wrong with this location code?

by Michael Thomas » Sun, 18 Apr 2010 23:16:35 GMT


 

Perhaps you are forgetting about the chain and theodolite provider.
Mike- What are those? The LocationManager class only has these two provider constants: GPS_PROVIDER, NETWORK_PROVIDER.
I was just making a funny, but the larger point is to not code things as if these are the only two forever more, (think ultimately Galileo as an example), and certainly don't make assumptions about the accuracy of resolution (Galileo is supposed to be quite a bit more accurate once its constellation is up). Mike
Thanks! Nick
You really have no reason to have a LocationListener[10] array... There are really only two location providers, Network and GPS. So all you need are two LocationListeners: fineLocationListener and coarseLocationListener.
Perhaps you are forgetting about the chain and theodolite provider. Mike ;-) --



What's wrong with this location code?

by Maps.Huge.Info (Maps API Guru) » Mon, 19 Apr 2010 00:24:12 GMT


 Personally, I wouldn't be making any coding plans for using the
Galileo system for location handling any time this decade. It will be
amazing if the EU manages to organize it into a working system in any
lifetime of current OS's or apps for that matter. Think of how long it
took to get a working engine for their A400 program, nearly 20 years
and the darn thing still isn't anything but a test program. The
Galileo system currently has no "in operation" date and only two test
satellites have been launched, none of them will be used in an
operational program. A functional system is at least a decade away
optimistically. I think you can safely ignore that possibility as a
means of location detection on current Android devices.

-John Coryat

--



What's wrong with this location code?

by patbenatar » Mon, 19 Apr 2010 16:15:45 GMT


 Mike-

Hahah--Word. I very much respect your position, although I do have to
agree with John here... And as far as other possible location
providers popping up anytime in the near future, new versions of the
OS will have to accompany them, along with new versions of the SDK,
which would prompt me, as an active developer, to update my apps, and
thanks to the Market's auto-update-prompt feature my users will
receive my update. I'd rather launch a current app faster and upgrade
it as new features become available than spend more time on initial
development planning for future features that may never exist. It is
indeed quite legit to plan for the future as you're talking about,
however. For me it's just a balance of pre-release development time
vs. post-release dev time.

-Nick




On Apr 18, 9:23am, "Maps.Huge.Info (Maps API Guru)"


>



Other Threads

1. App Icon and Label bugs with new HTC Hero phones

I originally titled this with the word "quirkiness" instead of "bugs"
but after reading the android reference docs, I believe it's a bug.

I'm having problems with the app icons and labels for the Light Racer
series of games I've released on Hero.  The games seem to run fine but
for whatever reason, they are having problems displaying more than the
package name on the home screen on Hero phones.  The app manager shows
the right name and icon but not the home screen.  It also on some
phones shows a random image as the icon, not even the app icon!

I used a copy of a manifest that I used originally for Light Racer 1.0
from when the Android SDK v1.0 was originally released.  For whatever
reason, I put the words "Light Racer" directly in to the manifest for
the android:label.  I also don't specify that same label for the
launch activity.

I've since changed the label to the default @string/app_name but
people are still reporting problems.  I thought that maybe not setting
the label on the launch activity was causing the problem but then I
read this:

--------------------
http://developer.android.com/guide/topics/manifest/activity-element.html

android:label
    A user-readable label for the activity. The label is displayed on-
screen when the activity must be represented to the user. It's often
displayed along with the activity icon.

    If this attribute is not set, the label set for the application as
a whole is used instead (see the <application> element's label
attribute).

    The activity's label whether set here or by the <application>
element is also the default label for all the activity's intent
filters (see the <intent-filter> element's label attribute).

    The label should be set as a reference to a string resource, so
that it can be localized like other strings in the user interface.
However, as a convenience while you're developing the application, it
can also be set as a raw string.
----------------------

See, it says right there that it's optional and can even be a raw
string.  That leads me to believe there's a bug with the app name
processing on the Hero.  I'm going to update my app to try to fix this
and recommend that you test yours on hero and fix it as well if you
see the issue.

Can others report on this please?  I'd like confirm my suspicion that
the Hero needs a resource string for both the application and launch
activity to work correctly.

I don't have a Hero so I'm relying on the feedback of others to solve
this issue.

Thanks!
--~--~---------~--~----~------------~-------~--~----~

2. Taking Screenshots from Phone using Windows 7?

Are you able to debug your app on the phone or is this broken as well?

Thanks,
Justin

----------------------------------------------------------------------
There are only 10 types of people in the world...
Those who know binary and those who don't.
----------------------------------------------------------------------






--~--~---------~--~----~------------~-------~--~----~

3. ADC 2 rating

4. phone reboot breaks app

5. How do I get a view's height to fill the space in between two other views?

6. Location Update

7. Emulator doesnt start up