[APP] - version 2.7.0 - BETA TESTING

[gynta]

• fixed issue with not working "Add quick point" feature

Ahh - and I've been wondering and edit some things yesterday :roll:
Well, now i just copied my old .quick_add_point.dat to Locus/data/ but if i use it - the points are stored in "Favorites" now.
If i change the category (eg to myquickpois) the poi icon itself also changes and i have to search the right poi icon again..
can i set my default category in an easier way than this?
eg with a (hex)editor in a dat file?

[Menion]

ah damn, you're correct. In definition of quick points is defined ID of category. Not name but some integer value that define category. But new categories have different id :/. So editing by hex editor is possible, anyway I just created also conversion of these id's during first conversion into new version. So please, when there will be new version for testing, start conversion again (just delete "locus/data/database" directory and MOVE content of "locus/data/_pre270" directly into "locus/data" directory). Locus will then convert all databases and now as well with all "Quick add point" definitions

I also added two more options, {t} and {text}. {t} is time (definition will be probably placed into config file), {text} is value for which you'll be asked before placing new point on map

[stebu]

Slow geocache GPX file loading!

I tested with two files and two Locus versions (test = 2.6.3.7, pro = 2.6.2).
Both files had 208 geocaches (no images, only text descriptions and logs). Logs file has about 10 separate logs per geocahce, Onelog file has the 10 logs combined into one long log (see below). The files were on my SD-card. ZTE-Blade, android 2.2
The timing results:

Code Select Expand

test    pro
102s    24s   Onelog
161s    42s   Logs
I have two suggestions:
1) make loading faster (   )
2) Load {groundspeak:logs}...{groundspeak:logs} as single item. Only when user opens the Logs tab, the separate logs (for that geocache) are parsed (temporarily or permanently).

LOGS file
{groundspeak:logs}
 {groundspeak:log id="xxx"}{....}
 {/groundspeak:log}
 {groundspeak:log id="xxx"}{....}
 {/groundspeak:log}
 {groundspeak:log id="xxx"}{....}
 ...
 {/groundspeak:log}
 {groundspeak:log id="xxx"}{....}
 {/groundspeak:log}
{/groundspeak:logs}

ONELOG file
{groundspeak:logs}
 {groundspeak:log id="xxx"}{about 10 logtexts in one log}
 {/groundspeak:log}
{/groundspeak:logs}

[Menion]

by loading you mean direct loading on map or import into database? Because 208 cache loaded just into memory if quite risky (due to memory consumption). Long listing usually take really a lot of memory ...

anyway if this is just loading on map, I'm quite surprised that new version is 4 times slower, damn. Mainly because there is no difference in parsing itself

[stebu]

I imported local .GPX files into database. I created the points category before importing, so it was empty. I had "empty selected category" and "show on the map after import" enabled.

I import ~1400 caches (50 km radius several times a week, so that is VERY slow! But it works well and causes no problems.

Edit:
I just checked, in the old version you had one .sqll for each category. Now it seems that all categories are stored into one large .db
(I have currently 43.5Mb). (80 minutes conversion,   )

If that is the cause, then:
I have only a few (2..4) categories that need to be updated often. Could there be two databases, one for "static" points and one for changing points?

[Menion]

no it couldn't . Number of points is still too low to affect speed ...

I'll try to do some testing. Expect that I'll probably today release new version and will next days work on speed improvements.

EDIT:
 - complete import of one PQ (1000 caches) - 90s
 - commented line where locus generate content for database and store it's data to database (completely new one) - 60s

so this mean, that new part with storing points cause 33% of import time. It's not a low, but seems there exists more critical places where to do some improvements. These 33% also have very low chance to improve. They contain just some serialization and one insert into database, which is very fast no matter how many points is already in database

EDIT2:
 - during waiting till gynta translate missing translations to German, I reduced import time from 90s to 75s. Good start

[Menion]

topic closed because new version is just uploading on Google Play and AndroidPIT

discussion may continue in version topic. Thanks all for help with testing. It was very useful. I believe that most features will work as expected. Only issue I know about it, is a quite slow deleting of part of track. It's TODO task on next week ... nice weekend to all