Add status indicator while refreshing caches

for one I will check about the speed even though I know the new API is way slower than the old one.
but I will also add a progress counter. since new API has me do batches of 50 at a time I should know the count.

Will come in one of the next versions. I guess sooner than later :-)

So my update today would have been 94 requests of 50 each.
Is the API rate-limited (requests per minute)?

Rate limiting is enforced on all methods of the Geocaching API. The methods are limited on the calling IP, end user, and by partner consumer key. The current limits are set to:

• 60 calls per minute for user per method
• 1200 calls per minute for partner consumer key
• 6000 calls per minute for IP address

The API is slow enough that 1 call should last at least 1s ;-) So the limit should NOT kick in...

Can you queue up the API calls at once and run them asynchronously instead of in sequence? 

I suppose I could ;-) Working on some other stuff but will look at that. Makes no difference for small number but for a few thousand it does.

Would definitely be a lot faster!

it would but I also would have to consider the API quota and pause all calls...

sure more complicated :-)

I'm a web developer, not an Android developer.
I would probably handle the problem something like this in a web app

* Track the number of API calls made within the previous minute. Let this be numAPICalls
* When a user refreshes a database, build all the API calls necessary and drop them in a queue
* Send as many requests as you can (60 - numAPICalls) from the queue
* As requests complete, grab more requests from the queue and send them
* Continue until all the requests are completed.

My example of 4681 caches should be able to process in under 2 minutes. (60 calls per minute, 50 caches per call).

The only issue with your math is that you assume instant response from HQ :-) If I bombard them with 60 calls at ONCE I will not get all 60 responses right away....

BUT, I agree, 45min is way too slow in any case...

Your 4681 caches are 94 API calls. Spread over 45min is about 30s per call....

I would say that sounds like an API HQ issue. This assumes sequential calls on my end.

I know I do not need 30s for 1 call!

I just tested at home... and the average API call time was under 2s!

So even without any change I will pump out 30+ calls a minute.

Which in your case would result in about 3 minutes update time.

I will see what is going on. Don't even think I need to add the effort since refresh rate of about 25caches/s would be 1500/min which I think is decent enough.

Now I know this is not what you got and I will check why...

This would be a HUGE improvement over the 45+ minutes it took this morning.

I would happily beta test this for you - but not until June 10 as I need to use the app heavily between now and then! 

You don't need to get the responses right away if you use an asynchronous model with callbacks or promises. At least that's what I'd use in the Javascript world. Not sure what you can or can't do in an Android app.

I just tweaked things and refreshed 350 caches in 12s.... so at a rate of about 30/s or just a tad over 2.5 minutes for 4700 caches.

Will measure what it was before my tweaks....

shaved down to 10s

Sweet! Looking forward to trying it out... 
Even more so if it's stable by the end of the day tomorrow!!! I'm going on a #GeocacheRoadTrip Friday morning. Should be up to 500 finds for a 3-day weekend

email me at support at gcdroid.com

I will send you dropbox link to the version I have. should be very stable and is working great.

auto retry on rate limit without any extra counting.

in case you are unhappy with the version I will also send you second link to load the current release back on.

348 caches in 9.7s or about 36 caches per second. All your caches should refresh in about 2.5 mminutes.

All depending on your phone of course! Saving the data is a big chunk of time. So older phones WILL be slower.

I tested on Galaxy S10, kinda as fast as it gets these days.

currently ignore the rate limit, need to handle that on each call since I would also need to handle someone refresh a list and then another list. so only relying on the actual requests won't be enough. each request needs to be tracked and retried in case rate limit is hit...

that aside it is stable. was only like 50 lines of code change ;-)

heads up, write performance of external sd had big impact and roughly doubling the time for me.

but that's beyond my control.

just know that it will make things slower

A  better  quality  SD  can  improve  read/write.

all true... simply stated that users need to be aware of the fact the best performance will always be achieved when using internal memory and that when comparing apps this important factor needs to be considered. One should not compare app A writing to internal memory to app B writing to SD card.

I have a high speed SD card suitable for recording 4K video and recommended for use in cameras.

The ability to refresh 4681 caches in 2-3 minutes while I had cell phone data in a remote location before going back into the wilderness was awesome. I was able to get logs posted between the time I left home, and the time we found some of the caches we attempted.

I had NO issues with the app version I tested over the weekend.