- 
                Notifications
    You must be signed in to change notification settings 
- Fork 184
Integrate the history tracking and storage components. #40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I love how this is only a couple of lines of code and you get history tracking in your browser. :)
I think we want to create HistoryTrackingFeature earlier independent from the Fragment. But that's not blocking -> ✅
|  | ||
| historyTrackingFeature = HistoryTrackingFeature( | ||
| requireComponents.engine, | ||
| requireComponents.historyStorage) | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this is more like an "application level" feature and we would want to create this in BrowserApplication.onCreate() so that we track history even when there's no fragment/UI around. (cc @grigoryk)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what "tracking history without a browser fragment/ui around" means, but generally I agree, history tracking isn't conceptually tied to the UI, so moving this over to BrowserApplication makes sense.
Separately, we'd want to make that change in the sample-browser as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what "tracking history without a browser fragment/ui around" means
We are able to load URLs while the app is in the background and while there may not be any UI (but we still want to record history). Fragments come and go. There's no reason we want to re-register a new delegate whenever there's a new BrowserFragment getting created.
| This will fix #89. ✨ | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty cool! One more line change, and this is will be backed by places ;)
|  | ||
| historyTrackingFeature = HistoryTrackingFeature( | ||
| requireComponents.engine, | ||
| requireComponents.historyStorage) | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what "tracking history without a browser fragment/ui around" means, but generally I agree, history tracking isn't conceptually tied to the UI, so moving this over to BrowserApplication makes sense.
Separately, we'd want to make that change in the sample-browser as well.
| Now that mozilla-mobile/android-components#1164 landed and released in 0.30, this can be backed by Rust Places instead of an in-memory storage. | 
| To avoid creating a new issue, @linacambridge could you update this to use  | 
| Closing in favor of #184. | 
Cargo-culting @grigoryk's changes for the sample browser in mozilla-mobile/android-components#1155 to use in-memory history storage. 😸