Opened 6 years ago

Last modified 4 years ago

#692 assigned enhancement

Moving hosts.txt to sqlite

Reported by: meeh Owned by: zzz
Priority: minor Milestone:
Component: apps/android Version: 0.9.1
Keywords: Cc:
Parent Tickets:

Description

The android version is going to move host list from plaintext file to sqlite.

quick notes;
01:19:05 <@zzz> sure. Implement net.i2p.client.naming.NamingService? by extending net.i2p.client.naming.DummyNamingService?. Have at it.
01:20:30 <@zzz> once you're done, set the router config property i2p.naming.impl=my.full.class.name and it will use it.
01:21:11 <@zzz> on first instantiation, import from existing hosts.txt file into your db, see BlockfileNamingService? for clues

Subtickets (add)

Change History (8)

comment:1 Changed 6 years ago by meeh

  • Status changed from new to accepted

I've researched a bit on how to do this now. And the solution seems to be a ContentProvider? because i2p is threaded. (database locking etc.)

Status:

  • Finished with the database class & initial creation
  • I'm soon finished with a simple ContentProvider? for getting hosts, inserting, updating, deleting.

TODO:

  • Read more about the classes zzz talk about, and how to implementate them.
  • Testing,Testing,Testing,Testing,Testing
  • Build a NamingService? querying the contentprovider instead of hosts.txt

I will not commit to mtn before this works.

comment:2 Changed 6 years ago by zzz

ref: http://developer.android.com/guide/topics/providers/content-provider-creating.html and http://developer.android.com/guide/topics/data/data-storage.html#db

Everything is threaded. Not just I2P is threaded. Android is threaded. Java is threaded. Threading is not a reason to use a ContentProvider?. You only need a ContentProvider? to allow access to the DB from other apps.

Long-term, it would be great to provide that access to other apps - this is the equivalent of I2P applications outside the router's JVM (i.e. outside of RouterContext?) accessing the NamingService? on a PC platform - something that's problematic today.

But I don't think there is anything requiring you to start out by implementing a ContentProvider?... unless it's needed to get access from both the addressbook edit activity and the router service? Is that why you are doing it?

comment:3 Changed 6 years ago by meeh

I had some problems with database locking problems on the first try, so I gave it a try with ContentProvider? because that solved the locking problem. I see your points, but I'm a bit afraid that it could be a locking problem between the addressbook edit and router service, so I do it to be safe.

If you think it's a bad idea, I'll start over and do it your way, but I think this might be the right way to do it.

Anyway I'm finished with the importer, so when the database is called, it checks for entries, if it's emtpy it importing from hosts.txt.

comment:4 Changed 6 years ago by zzz

I didn't say you shouldn't use a ContentProvider?. I said you did it for the wrong reason.

Doesn't sound like you have fully analyzed the locking requirements / thread safety for your database. That's what you have to get right - whether or not it's a ContentProvider?. Saying you just changed something (i.e. switched to a ContentProvider?) and now it works doesn't inspire confidence.

Where the ContentProvider? yes/no issue _is_ important is whether the DB should be available to other apps.

Where the ContentProvider? yes/no issue _might_ be important is with AddressbookActivity? - should it work when the router isn't running? Should there be multiple instances of the DB? If it's started before the router starts, should the router somehow grab the existing DB instance? See also the rather cheap shortcut I took on that issue at the top of AddressbookActivity?.

comment:5 Changed 6 years ago by meeh

Thanks for the guidelines and correction.

I've been reading a while now, and after some thinking I've changed my mind. I think it should only be instance working with the database. Now I'm looking more into a bound service, since it seems possible to make it threadsafe there. And that also make it possible to extend to a ContentProvider? later if needed for 3rdparty apps.

Also, I've read that when all "client/threads" disconnects from the service, the lifecycle will stop, so I researching if it need to be a service used with both onBind() by clients and onStartCommand(), that's starts & stops at the same time as the router.. The android documentation recommends a bound service when multiple components/threads will use it.

A service runs in the main thread of the application that hosts it, by default, so it would need a own thread too.

If I've got it right this will make it possible for both the router service and the addressbookactivity to access the resource at the same time. Also any other sub-threads, and a ContentProvider? if needed in the future. Do you think this sounds better?

refs:
http://developer.android.com/guide/components/processes-and-threads.html#ThreadSafe
http://developer.android.com/guide/components/bound-services.html#Lifecycle
http://developer.android.com/guide/components/services.html

comment:6 Changed 6 years ago by zzz

Is a Service better? Maybe, maybe not. Like with ContentProvider?, you shouldn't use a Service just to get thread safety.

A service is like a background task, running independently of an Activity. The router, of course, is a Service. But why does the NamingService? need to be a service? Does it need to be doing something all the time? I doubt it - you look up a hostname, it either succeeds or fails... what else is there to do? And BTW, binding an Activity to a Service is a pain.

All you need for thread safety... where you need it... is of course synchronized(someLock) { ... }. That's what I'm getting at. Understand what needs to be protected with a lock, if anything, and then code appropriately. Research whether your database is thread safe. If not, what's the best way?

BlockfileNamingService?, for example, just uses locking where necessary. Ditto with SingleFileNamingService?.

So again, I say: These Android constructions - ContentProvider?, Service, etc. - are there to be used for specific reasons. Not to provide magic thread safety. Maybe you need them. Maybe you don't. Maybe you're almost done implementing one. Maybe not. But I guarantee you that both of them are added complications.

comment:7 Changed 5 years ago by zzz

I briefly started implementing this. Do you still have your code? It would be helpful...

comment:8 Changed 4 years ago by meeh

  • Owner changed from meeh to zzz
  • Status changed from accepted to assigned

Sorry but for now it seems lost. But ask me and I'll do it when I got <time> (probably a while), or help if needed.

Note: See TracTickets for help on using tickets.