Notices


Reply
Thread Tools
Posts: 214 | Thanked: 140 times | Joined on Aug 2010
#121
Originally Posted by LaptopU View Post
Couple of questions though please. I would like to switch between other apps and leave this running in the background. I can switch by pressing ctrl-backspace on the keypad, but some other apps (particularly web browser) allow the title bar to appear by tapping the bottom right of the screen, yours doesn't. Would you plan to add that?
Actually, it's (trivially) possible to make a it such that the switcher thingy is still visible in the upper left (together with clock, battery, etc.). I simply opted against it purely for Aesthetic reasons.

I can quite trivially add a switch in the configuration for that, or a keyboard toggle, or whatever.

Originally Posted by LaptopU View Post
Also if I set the daemon to still run after the program exits, it seems to use a 'fast' GPS location which is generally the cell tower nearby. I can see the GPS fire up and shut down but it doesn't get a true lock, whereas if I leave the program running it gives an accurate lock.
It's supposed to give you a lock, but maybe the 15 second timeout I added in a recent release is too short for it to get a good gps.... basically, I turn on the GPS, and give it 15 seconds to give me a good fix, and if I havn't gotten a good fix in 15 seconds I take whatever "bad" fix I got

I should probably increase that a little, 15 seconds is pretty tight... it's okay when you have good signal (like I have out on the countryside where I live) but in a tighter scenario it's probably touch-and-go. I will increase this timeout.


/Z
 

The Following User Says Thank You to MasterZap For This Useful Post:
ndi's Avatar
Posts: 2,050 | Thanked: 1,425 times | Joined on Dec 2009 @ Bucharest
#122
15 seconds is plenty with a-GPS.

Configuration of timeout could be nice, but if it's not locked in 15 secs you probably don't have a-GPS or haven't locked before, meaning the next timeout is the full GPS cycle of 90 seconds plus in perfect conditions, 4-5 minutes under less than ideal. It's a bit on the large side?
__________________
N900 dead and Nokia no longer replaces them. Thanks for all the fish.

Keep the forums clean: use "Thanks" button instead of the thank you post.
 
Posts: 214 | Thanked: 140 times | Joined on Aug 2010
#123
Originally Posted by ndi View Post
15 seconds is plenty with a-GPS.

Configuration of timeout could be nice, but if it's not locked in 15 secs you probably don't have a-GPS or haven't locked before, meaning the next timeout is the full GPS cycle of 90 seconds plus in perfect conditions, 4-5 minutes under less than ideal. It's a bit on the large side?
Yes, 15 seconds is plenty with good reception, I "normally" get a fix within about 5 seconds (or as little as 3). But since my code does have a 15 second timeout (where it then reverts to the cell tower location), and I've found that, sometimes, I still get cell-towers (maybe when the phone is in my pocket or whatnot), clearly 15 seconds isn't quite enough.

I will probably be adding a third mode that is "Always use GPS", which has the same logic and timeouts, but simply will *never* use a cell location, simply not posting any update at all if it didn't get a "gps quality" fix within the timeout. Then you, as a user, have the choice suitable for your environment, i..e

- very urban (New York city-canyons and offices): Cell only
- medium (smaller city with some open spaces): Cell+GPS
- rural (nearly always good gps fixes): GPS only

Should be a trivial change.

/Z
 
Posts: 214 | Thanked: 140 times | Joined on Aug 2010
#124
Hi Guys, a question:

I think I may have been a bit too paranoid with the Daemon settings in the UI of ZapLoc.

I'm starting to think of changing it like this:

- default "Background Updates" to off (I still think I need to have somethign like this off by default so people are always aware when they turn it on... or do you think people is smart enough to realize this anyway? I don't want to get liable for my app sharing stuff people didn't want....)

- remove the settings of "when to start" and "when to stop" the daemon.

The new logic would be:

- if "background updates" is on, daemon starts at boot and never stops
- If "background updates" is off, daemon either a) doesn't run at all, or b) just runs while the main program is visible.


My questions to you:

#1 Does this change make sense?
#2 Should it do a) or b) for "background updates"=Off mode?


I just realized I was being overzealous here: For example, "auto checkins" and "latitude updates" are ALSO both off by default. Lots of stuff to turn on before it actually works


/Z

Last edited by MasterZap; 2011-05-24 at 06:56.
 
Posts: 210 | Thanked: 37 times | Joined on Nov 2010
#125
how can I add a new place?
 
Posts: 214 | Thanked: 140 times | Joined on Aug 2010
#126
Originally Posted by amadeukaos View Post
how can I add a new place?
You can't... this is a consumption app, not a creation app.

For Gowalla, I suggest m.gowalla.com

For FourSquare I suggest www.cotchin.com/m

For Facebook Places I don't know what to suggest any more, in the past touch.facebook.com worked on the N900, but Facebook has removed that site in favour of a crappy mobile site

Maybe someone has a tip how to add facebook places on the N900?

/Z
 
Gusse's Avatar
Posts: 168 | Thanked: 206 times | Joined on Apr 2010 @ Finland
#127
Thanks for the great application!

Should I have several zaploc-daemon.py running parallel? After 1st start I have.
~ $ ps -w|grep zap*
18575 user 125m S /usr/bin/python /opt/zaploc/zaploc.py
18609 user 50072 S /usr/bin/python /opt/zaploc/zaploc-daemon.py -d
19116 user 50072 S /usr/bin/python /opt/zaploc/zaploc-daemon.py -d
19150 user 50072 S /usr/bin/python /opt/zaploc/zaploc-daemon.py -d
After each start of ZapLoc there will be a new zaploc-daemon.py running in addition to old ones. Does not matter if background updating is set to stop when app closes or not. Battery drain is also quite huge after enabling Zaplog even updates should happen in every 30min. Drain remains also after disabling background updates.

Last edited by Gusse; 2011-05-24 at 07:23.
 
Posts: 650 | Thanked: 497 times | Joined on Oct 2008 @ Ghent, Belgium
#128
Originally Posted by MasterZap View Post
The new logic would be:

- if "background updates" is on, daemon starts at boot and never stops
- If "background updates" is off, daemon either a) doesn't run at all, or b) just runs while the main program is visible.


My questions to you:

#1 Does this change make sense?
#2 Should it do a) or b) for "background updates"=Off mode?
For me, enable/disable daemon is more than enough, and in that context in OFF mode it should do b) - only update while the program is active....

I understand you're looking for new stuff to work on, but for me ZapLoc is good as it is

Or maybe.... you could add an option to let it behave like Android. On Android, latitude is updated more frequent and using GPS when you are moving. But I'd probably never use this anyway
__________________
Affordable mobile internet in Belgium: Try Mobile Vikings
2 GB, 1000 SMS and 15 euro of talk time for.... 15 euro
 
Posts: 13 | Thanked: 1 time | Joined on Feb 2010
#129
Originally Posted by MasterZap View Post
- if "background updates" is on, daemon starts at boot and never stops
- If "background updates" is off, daemon either a) doesn't run at all, or b) just runs while the main program is visible.
Short answer:

Makes perfect sense in my opinion, this is how I would expect it to work and I bet everyone already has it configured this way.
I would go with mode b).

Long answer:

There are two separate cases in mode b):

- If you don't have the background daemon running, you are probably starting the main program in order to update your position and to see the map/check in - daemon should be on while the main program is running.

- If you already have the daemon running, you are probably starting the main program to see the map and/or check in - in this case the daemon should either:
b1) keep the same settings it had in background mode, or
b2) restart with the default settings

My humble (and possibly too laborious) suggestion is:
Keep the background daemon and the main program daemon separate from each other. When the user starts the main program, you could suspend the background daemon until the main program is closed. The settings should be separate as well, as the use cases for using the background daemon and running the main program are typically rather different.
 
Posts: 214 | Thanked: 140 times | Joined on Aug 2010
#130
Originally Posted by Gusse View Post
Thanks for the great application!

Should I have several zaploc-daemon.py running parallel? After 1st start I have.


After each start of ZapLoc there will be a new zaploc-daemon.py running in addition to old ones. Does not matter if background updating is set to stop when app closes or not. Battery drain is also quite huge after enabling Zaplog even updates should happen in every 30min. Drain remains also after disabling background updates.
No, this should not happen. Which build are you running? Are you starting it from the icon or command line? And if from the command line, are you "user" or "root" when doing so?

/Z
 
Reply


 
Forum Jump


All times are GMT. The time now is 14:18.