Site Search: Extract common base classes for mediators
This CL refactors the site search settings mediators to eliminate
significant code duplication across multiple components. Note that this
is a pure refactoring change without new logic introduced.
Changes introduced:
1. Created BaseSiteSearchMediator: Centralizes TemplateUrlService, icons
fetching and standard PropertyModel creation.
2. Created ExpandableSiteSearchMediator: Encapsulates the logic for
"More" button state and expand/collapse actions.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi Tomasz! I was originally hoping to do this in a single CL, but the code diff was getting too large, so I split the logic into two different CLs. Please let me know if you have any questions~
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
stamping to unblock.
refreshList() being called twice is a nice-to-have correction (it's a little wasteful).
mTemplateUrlService.addObserver(this);
mTemplateUrlService.runWhenLoaded(this::refreshList);will this `refreshList()` twice?
protected boolean mIsExpanded;
/**
* The items to display when the list is expanded. Subclasses are responsible for populating
* this list during {@link #refreshList()} or lazy-loading them via {@link
* #prepareHiddenItemsIfNeeded()}.
*/
protected final List<ListItem> mHiddenItems = new ArrayList<>();i think both of these should be `private`.
`protected` members here permit subclasses to override these values which is risky.
for (int i = 0; i < mUrlsToSimulate; i++) {
ListItem item = createListItem(mTemplateUrl);
if (i < DEFAULT_MAX_ROWS) {
mModelList.add(item);
} else {
mHiddenItems.add(item);
}
}this is risky. any tests checking mModelList and mHiddenItems will be testing the testing support code, not the actual mediator.
why is it necessary to track that at all?
the `Expandable.*Mediator` is an abstract class. it should be tested with
```
mock(ExpandableSiteSearchMediator.class,
Mockito.CALLS_REAL_METHODS);
```
or
```
@Mock(answer = Answers.CALLS_REAL_METHODS) ExpandableMediator mMediator'
```
and all the logic below should `verify()` that appropriate methods are called, rather than checking what the test support code does with that.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
stamping to unblock.
- the test should def be reconsidered. i don't think it tests what matters
- i do believe the member variables should be `private` too, as is this is risky.
refreshList() being called twice is a nice-to-have correction (it's a little wasteful).
the test should def be reconsidered. i don't think it tests what matters
todo (crbug.com/492061324) added.
i do believe the member variables should be private too, as is this is risky.
todo (crbug.com/492059926) added.
Thanks for the review Tomasz! these are very valuable comments
mTemplateUrlService.addObserver(this);
mTemplateUrlService.runWhenLoaded(this::refreshList);Kay Linwill this `refreshList()` twice?
No, IMHO when the observer is added, it doesn't trigger onTemplateUrlChanged; instead, runWhenLoaded runs the first time for refreshList(). I also conducted some experiments here and confirmed that refreshList is called only once.
protected boolean mIsExpanded;
/**
* The items to display when the list is expanded. Subclasses are responsible for populating
* this list during {@link #refreshList()} or lazy-loading them via {@link
* #prepareHiddenItemsIfNeeded()}.
*/
protected final List<ListItem> mHiddenItems = new ArrayList<>();i think both of these should be `private`.
`protected` members here permit subclasses to override these values which is risky.
Agreed. I'll add a TODO here to be addressed in a subsequent CL.
for (int i = 0; i < mUrlsToSimulate; i++) {
ListItem item = createListItem(mTemplateUrl);
if (i < DEFAULT_MAX_ROWS) {
mModelList.add(item);
} else {
mHiddenItems.add(item);
}
}this is risky. any tests checking mModelList and mHiddenItems will be testing the testing support code, not the actual mediator.
why is it necessary to track that at all?
the `Expandable.*Mediator` is an abstract class. it should be tested with
```
mock(ExpandableSiteSearchMediator.class,
Mockito.CALLS_REAL_METHODS);
```or
```
@Mock(answer = Answers.CALLS_REAL_METHODS) ExpandableMediator mMediator'
```and all the logic below should `verify()` that appropriate methods are called, rather than checking what the test support code does with that.
After a second look, I totally agree with you. I was so caught up in implementing the tests for the full feature—especially the refactoring from other components. I've added a todo here and will look into it later. Thanks for the pointer!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
4 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: chrome/browser/search_engines/android/junit/src/org/chromium/chrome/browser/search_engines/settings/common/ExpandableSiteSearchMediatorUnitTest.java
Insertions: 2, Deletions: 0.
@@ -38,6 +38,8 @@
/** Unit tests for {@link ExpandableSiteSearchMediator}. */
@RunWith(BaseRobolectricTestRunner.class)
public class ExpandableSiteSearchMediatorUnitTest {
+ // TODO(crbug.com/492059926): This abstract class should be tested with mock and verify the
+ // methods called instead.
@Rule public MockitoRule mMockitoRule = MockitoJUnit.rule();
@Mock private Profile mProfile;
```
```
The name of the file: chrome/browser/search_engines/android/java/src/org/chromium/chrome/browser/search_engines/settings/common/ExpandableSiteSearchMediator.java
Insertions: 1, Deletions: 0.
@@ -24,6 +24,7 @@
/** The default maximum number of items to show before displaying a "More" button. */
protected static final int DEFAULT_MAX_ROWS = 5;
+ // TODO(crbug.com/492061324): Make mIsExpanded and mHiddenItems private.
protected boolean mIsExpanded;
/**
```
Site Search: Extract common base classes for mediators
Part 1/2: This CL introduces the base class for site search to eliminate
significant code duplication across multiple components. Note that this
is a pure refactoring change without new logic introduced.
Changes introduced:
1. Created BaseSiteSearchMediator: Centralizes TemplateUrlService, icons
fetching and standard PropertyModel creation.
2. Created ExpandableSiteSearchMediator: Encapsulates the logic for
"More" button state and expand/collapse actions.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |