Closed Lee-Carre closed 2 years ago
@Lee-Carre I no longer have an Android device to test builds much less use this software on a daily basis to assure it is working correctly. It seems from your comments that you are an active user of it. Would you like to take over this project?
I am inclined to try to help, but I do not and won't have anything to do with the play store. From my viewpoint all that matters is f-droid and caylxos integration :-)
I am inclined to try to help, but I do not and won't have anything to do with the play store. From my viewpoint all that matters is f-droid and caylxos integration :-)
Sounds like a kindred spirit. I have spent and continue to spend considerable effort to avoid Google and the only "store" I made any of my Android available through was F-Droid.
If you wish to take over this project and/or the wifi backend, I have no objections.
It seems from your comments that you are an active user of it. Would you like to take over this project?
Firstly, thankyou for the offer. I'm flattered.
However, as much as I appreciate the opportunity, I have major reservations about taking on that kind of responsibility
Having crossed paths with @gdt several times on related projects, he seems a far better candidate to inherit the project & its maintenance. I definitely approve of the anti-Google (more specifically anti-proprietary) & pro-libre sentiments.
If & when my reservations become non-issues, I'll gladly contribute & assist @gdt (or whoever he, or you, nominate), in future.
Semi-related: I've been working a bit on DejaVu in the past weeks, because I noticed things are getting slow if the database is large (50 MB in my case) You might want to have a look at https://github.com/Helium314/DejaVu
What has changed
RfEmitter.setNote
is never called@Helium314
I've been working a bit on DejaVu in the past weeks
What has changed
Sounds promising 👍. Looking forward to seeing those released. I started watching your fork; thanks for citing it.
things are getting slow if the database is large
While I can't comment on code being (in)efficient (though I'm prompted to think of determining the Big-O characteristic of algorithms), I've a little experience with DBs.
SELECT
s doing lookups).SELECT
s are well-crafted (small changes can sometimes make significant reductions to execution-time, also beware SELECT *
), should also help.VACUUM
on the DB would be sensible. Perhaps after every N new / updated entries (instead of time-based).Thanks for the hints! Index on latitude / longitude / emitter type is already in use (for querying nearby emitters), and the primary key for the other queries.
I thought about switching to bounding boxes (storing north, south, east, west) instead of center and N-S / E-W radius. This would allow to properly query all emitters whose bounding boxes insersects with our location, but then queries are considerably slower (even with index)
Thanks for the hints!
Welcome. Added a couple more, since.
I thought about switching to bounding boxes (storing north, south, east, west) instead of center and N-S / E-W radius. This would allow to properly query all emitters whose bounding boxes insersects with our location, but then queries are considerably slower (even with index)
Even if it were faster:
This discussion is now off topic for the PR (I saw with zero authority), which points out that the project really needs a mailinglist, the lack of which is part of github disease. But, as someone who has handled maintenance for projects, I think any restart would need to focus on bringing up to modern API revisions, fixing real bugs, and fixing things that are widely causing real pain. And, I have a very strong leaning to "simpler is better".
discussion is now off topic for the PR (I sa[y] with zero authority)
😄 I was mindful of off-topic-ness, too.
Obligatory citation of Posting And You….
the project really needs a mailinglist, the lack of which is part of github disease.
Mailing lists aren't easily accessible to all. I'd suggest either enabling the Discussions section feature for the repo, or a meta-issue.
Still off-topic, but...
I don't see how storing bounding boxes would be much more complicated in any way than storing center and radii. In both cases we have 4 reals, which SQLite stores using 8 bytes to my knowledge, so no difference in size (radii could be stored as integers, but aren't). [Edit: I did not consider that index on 2 more columns probably increases size]
The bounding box is created from center and radii when the emitter is loaded from database, so there is no difference once the emitter is loaded from database. And in the database it would be good to use whatever is more useful for our queries.
The only queries for the emitter location are for getting emitters we expect to see.
I think checking whether our position is inside the bounding box of an emitter is a good way to check whether we should see it. In my opinion it's better and actually more simple than getting the typical range of an emitter type, and query all emitters of that type in a radius of typical range
around us (repeat for each type).
I think so, because the typical range
query finds "expected" emitters that we should not find because their range is less than typical range
(according to our data). And it doesn't find emitters with more than typical range which we actually would expect.
I've observed several instances of such SSIDs while capturing data with various apps.
In my experience, they're always mobile phones.