Add placesHistoryStorage as a history provider

[mhammond]

This patch adds places as a history provider to the reference browser. As things stand, this will conflict with #40 - that PR hooks up the "generic" provider while this hooks up the "places" provider - I'm assuming that we want the places one, although I'm not sure if there was some intention to have that be configurable?

Because the geckoview changes necessary to collect history haven't landed yet, (a) I haven't tested that part of this patch actually works, and (b) for the awesomebar to work you will need to have copied in a places.sqlite generated by rust code in the app-services repo - but this seems clean enough to think about landing even before we have that set up.

Other feedback:

• It's also very nice how easy this was to put together - such a small patch for some powerful functionality! Also, the improved awesomebar looks great when there's some history - nice work @pocmo (and whoever helped!)

• @grigoryk landed some awesome code which took our places needs into account even when the work he was directly doing didn't need it - thanks!

• @linacambridge 's #40 made this very easy and IIUC, hopes to shepherd geckoview changes fairly soon, which will make this all come together perfectly!

[pocmo]

Nice :)

It looks like this PR is missing the additions to Dependencies.kt:

No such property: mozilla_concept_storage for class: Deps

[pocmo]

nit: this is redundant here.

[grigoryk]

Easy-peasy! Thanks for the feedback, Mark!

[grigoryk]

I'm assuming that we want the places one, although I'm not sure if there was some intention to have that be configurable?

Yeah, let's just land places for the reference-browser. We use the simpler in-memory store in the android-components sample-browser. Lina's PR used the in-memory store because that's all we had at the time.

Because the geckoview changes necessary to collect history haven't landed yet, (a) I haven't tested that part of this patch actually works

You should be able to test this entirely if you build the reference browser against the SystemEngine, which fully supports history tracking.

(b) for the awesomebar to work you will need to have copied in a places.sqlite generated by rust code in the app-services repo

I'm not sure why you'd need to manually copy stuff if you're using GV? Do you mean to actually see some results, right? Because places.sqlite would have been created regardless.

Also, GV right now will emit title change events, which will be passed on to places via noteObservation. I'm guessing 'places' is just dropping these events on the floor (since there are no associated visits, and the places table needs to have "last visited" timestamps and whatnot).

[grigoryk]

I think this is the change to Dependencies.kt you'll need: https://github.com/mozilla-mobile/reference-browser/pull/40/files#diff-f6dcd12435c476b2cedd79bcd292b929 (except use the different storage).

[mhammond]

It looks like this PR is missing the additions to Dependencies.kt:

doh! That file also had a change so mozilla_android_components pointed at a snapshot - but I reverted the entire file instead of just that -snapshot change.

I'm not sure why you'd need to manually copy stuff if you're using GV? Do you mean to actually see some results, right? Because places.sqlite would have been created regardless.

Yes, that's correct - places.sqlite will be created but will not have visit data, so isn't going to find matches.

Also, GV right now will emit title change events, which will be passed on to places via noteObservation. I'm guessing 'places' is just dropping these events on the floor (since there are no associated visits, and the places table needs to have "last visited" timestamps and whatnot).

Hopefully we will do the right thing there now (it's ok to have a place without visits), but we can tackle issues there on the application-services side.

Thanks!