I didn't find an explicite description, but I made some tests.

Starting point:

- 1799 caches found / 0 found drafts on GC

Log a DRAFT:

- Write a log

- proposed findcount = 1800

- send it to the GC server as DRAFT

- 1799 caches found / 1 found drafts on GC

Start a new log:

- Write a log

- proposed findcount = 1801

- didn't send it

- still 1799 caches found / 1 found drafts on GC

New draft on GC:

- Create a found DRAFT on GC online

- 1799 caches found / 2 found drafts on GC

Back in Cachly:

- start a log

- proposed findcount = 1802

It seems obvious that the proposed findcout is always directly based on what was found on the server. But I have to correct my first post. It looks like Cachly gets the current number of found caches AND the number of found drafts, resulting in: #findcount = <current finds online> + <found dafts online> + 1.

If I have 10 drafts on my phone and check them they will all show the same #findcount based on the current state on the server. But with each log sent to the server (doesn't matter if it is a draft or a finished log) #findcount will increase according to the new logs and drafts on the server.

I hope this was understandable :-)

Hi,

here comes an opinion from an unexpected side: user of Cachly on iPhone. Right now my opinion might not seem relevant since I am an iPhone user. But recently I was confronted with the question: what will I do when I am foreced to switch to Android?

I had a look at Geooh GO, c:geo and GCDroid. Of the three, I definitely liked GCDroid the best. But what I would really miss is #findcount in my log template. I read the complete thread and fully understand the issues, or perhaps better the concerns of the developers. I am totally aware that it is absolutely impossible for GCDroid to track the correct findcount internally, taking into account drafts and logs from other apps or online.

But I think that this can be explained and I am persuaded that a very simple and streight forward implementation makes sense: #findcount is always 'current finds at API' + 1. This behavior is easy to explain and understand. You might want to throw a warning before first use so the users are aware of the limitations. But as far as I understood it works fine for c:geo users and from my personal experience and what I am reading in the Cachly support forum it seems to work fine for Cachly users too.

In the end you will have two fractions. The ones doing much "out of GCDroind logging" who will ignore #findcount because it doesn't work for them, and the ones primarily logging with GCDroid, for whom it will be a great new feature.

Just the thoughts from a Cachly user 😃

Best,

DrDaffy