Added a way to provide the database files to the DatabasePeerManager module.

[jferlisi]

Created an interface to provide database files at the time of a peer connection. This allows applications that create databases in directories other than the default one to have their data viewable in the Database section.

[jasta]

touché, I didn't know about this API :)

[jasta]

Oh, so I did. Well that's weird, I have no memory of this at all. facepalm

[jasta]

I'm curious for your thoughts at a high level on the API for configuring modules. I believe at present you are writing something like:

new InspectorModulesProvider() {
  public Iterable<> get() {
    HashSet<> modules = new HashSet<>();
    Collections.add(modules, Stetho.defaultInspectorModulesProvider(context).get());
    replaceByType(Database.class, new Database(context, new MyDatabaseProvider(...)));
    return modules;
  }
}

We're doing this internally in FB4A/Messenger, but I'm really unhappy with it. Seems like these use cases should be expressed more conveniently, perhaps with some kind of pattern like:

Stetho.newInspectorModulesBuilder(context)
   .addDefaults()
   .add(new Database(...));
   .build();

Internally addDefaults would be a boolean which operated like:

for (ChromeDevtoolsDomain domain : mCustomModules) {
  modules.add(domain);
  customModuleNames.add(InspectorUtil.getDomainName(domain));
}
if (mAddDefaults) {
  if (!customModuleNames.contains("Database")) {
    modules.add(...);
  }
  ...
}

[jferlisi]

I'm curious for your thoughts at a high level on the API for configuring modules.

I'm still playing around with things so I haven't given it a lot of thought. Right now what I have done is copied the list of modules from the defaults and add each of them individually.

ArrayList<ChromeDevtoolsDomain> modules = new ArrayList<ChromeDevtoolsDomain>();
modules.add(new Console());
modules.add(new CSS());
...
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
  modules.add(new Database(context, myDatabaseFilesProvider));
}
return modules;

I do like your proposed method though.

[jasta]

nit: don't need final

[jferlisi]

Certainly not anymore. I'll remove it.

[jasta]

Looks good, clean up the minor nits then rebase/squash and we can merge.

[jferlisi]

Do you happen to have an Intellij code style file published anywhere?

[jasta]

@jferlisi no, working on it tho :)

[jferlisi]

@jasta Pushed changes.

[jasta]

Looks good, please squash into 1 commit (http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html), then git push -f into your github fork branch.

[jferlisi]

@jasta Done, thanks for the help on this.