Well this is an old topic.. simple reason why it's not implemented...
The big question is how to get this number right. GCDroid is NOT the only way to log a cache, or to add a Draft.
What is the findcound? User has 10 caches logged online and 2 find drafts pendig.
Then user logs a draft in GCDroid, then user log a real log in GCDroid. What should be #findcount in both cases? What if the user the logs OUTSIDE of GCDroid? How would I know about it?
Looking for opinions...
The fact that GCDroid does NOT have full control over logging virtually guarantees upset users because they logged in a funny order and the numbers are off...
Even worse: new version of GCDroid will allow editing and deleting of Drafts!
What if you delete a draft? All Drafts that were already uploaded and happened after that delete one will now be off by one! No way for GCDroid to know or even fix that!
While a nice idea I can see more complaints than praise coming my way for this topic....
I also request to add this feature. I have cached exclusively with gdak the last couple of years and use the find count feature from there for each log with minimal issues. I am testing this app and really love the interface, but am not sure I want to give up that find count logging ability. I may switch anyway as it isn't necessarily a deal breaker, but that is my biggest hold up as I play around with this app.
I was using this feature in c:geo and was logging offline, so my foundcounter was still at eg. 1234 in each fieldnote. I changed it then at home adding +1 on each log.
Is there any possibility to have a counter which takes your current number of finds (for example 1000), then adds +1 - so the fieldnote has 1001, and then basing on saved fieldnotes increases the number while logging any other fieldnote? So logging the next cache will give me the possibility to have it automaticaly set to 1002 so I don't have to do it at home later. That would be a really amazing feature.
And btw. a #findcounter same as working c:geo would be fine too. I think GCDroid Support wants to eliminate all possible cases which may interrupt the counter, but that is not needed in my opinion. People using the app and its features are aware of many problems which may occur.
Up to now, I have been using Locus Pro (and I really like it).
The findcount always worked fine for me, and of course I know that it can´ t be correct when I log lab caches in between, or use different apps for logging, for example. But I would really appreciate this log template.
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.
Well, I do like hearing from the 'dark side' hahaha...
I never thought about checking what Cachly does to be honest. I think it is a great app...
So my question to you would be: what does Cachly do with Drafts? I am sure they would count that? At least the ones create in Cachly... otherwise the count would be stuck for people using drafts since the api findcount does not increase for them.
To be honest, I would NOT mind using the exact same logic as Cachly. Is that explained somewhere?
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.
Ideas
Well this is an old topic.. simple reason why it's not implemented...
The big question is how to get this number right. GCDroid is NOT the only way to log a cache, or to add a Draft.
What is the findcound? User has 10 caches logged online and 2 find drafts pendig.
Then user logs a draft in GCDroid, then user log a real log in GCDroid. What should be #findcount in both cases?
What if the user the logs OUTSIDE of GCDroid? How would I know about it?
Looking for opinions...
The fact that GCDroid does NOT have full control over logging virtually guarantees upset users because they logged in a funny order and the numbers are off...
Even worse: new version of GCDroid will allow editing and deleting of Drafts!
What if you delete a draft? All Drafts that were already uploaded and happened after that delete one will now be off by one!
No way for GCDroid to know or even fix that!
While a nice idea I can see more complaints than praise coming my way for this topic....
Well been using cgeo with this feature for quite awhile , 95% of the time i am live logging so it does what it should
the problem does occur when I have bad cell reception and have to save my log to be sent in later
as long as i remember to send them in the order that I did them and before i do any more live logging all is good
the odd time I do get messed up and they do get our of order, not really a big issue unless it's a milestone cache
If you are logging in order of finding the cache you wont have any issues, if you dont you might not want to use this feature
agreed. Except for pending drafts created outside of GCDroid.
just weary to add it in and get more complaints than praise for it.
it's very easy to add. But very hard to do it right.
people have to know if your logging outside the app , then it could throw your count off
same as logging out of order .. if people are doing this then dont use the feature
i would like to see this feature too.
i would also like to see some other tags like cache type, cache owner, log snippets, etc similar to some of the other apps.
There are some tags already.
I also request to add this feature. I have cached exclusively with gdak the last couple of years and use the find count feature from there for each log with minimal issues. I am testing this app and really love the interface, but am not sure I want to give up that find count logging ability. I may switch anyway as it isn't necessarily a deal breaker, but that is my biggest hold up as I play around with this app.
I was using this feature in c:geo and was logging offline, so my foundcounter was still at eg. 1234 in each fieldnote. I changed it then at home adding +1 on each log.
Is there any possibility to have a counter which takes your current number of finds (for example 1000), then adds +1 - so the fieldnote has 1001, and then basing on saved fieldnotes increases the number while logging any other fieldnote? So logging the next cache will give me the possibility to have it automaticaly set to 1002 so I don't have to do it at home later.
That would be a really amazing feature.
And btw. a #findcounter same as working c:geo would be fine too. I think GCDroid Support wants to eliminate all possible cases which may interrupt the counter, but that is not needed in my opinion. People using the app and its features are aware of many problems which may occur.
Is this topic still under review?
Up to now, I have been using Locus Pro (and I really like it).
The findcount always worked fine for me, and of course I know that it can´ t be correct when I log lab caches in between, or use different apps for logging, for example. But I would really appreciate this log template.
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
Well, I do like hearing from the 'dark side' hahaha...
I never thought about checking what Cachly does to be honest. I think it is a great app...
So my question to you would be: what does Cachly do with Drafts? I am sure they would count that? At least the ones create in Cachly... otherwise the count would be stuck for people using drafts since the api findcount does not increase for them.
To be honest, I would NOT mind using the exact same logic as Cachly. Is that explained somewhere?
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 :-)
just here to thank you for moving this topic forward