Chromium Code Reviews| Index: chrome/browser/enhanced_bookmarks/chrome_bookmark_server_cluster_service.cc |
| diff --git a/chrome/browser/enhanced_bookmarks/chrome_bookmark_server_cluster_service.cc b/chrome/browser/enhanced_bookmarks/chrome_bookmark_server_cluster_service.cc |
| index e270c5356257974be9e464961bf984e4aa209e3e..94d9fa1ad860592f463110aa39ef0ed779a24ed3 100644 |
| --- a/chrome/browser/enhanced_bookmarks/chrome_bookmark_server_cluster_service.cc |
| +++ b/chrome/browser/enhanced_bookmarks/chrome_bookmark_server_cluster_service.cc |
| @@ -37,8 +37,8 @@ void ChromeBookmarkServerClusterService::AddObserver( |
| BookmarkServerServiceObserver* observer) { |
| BookmarkServerClusterService::AddObserver(observer); |
| if (sync_refresh_skipped_) { |
| - sync_refresh_skipped_ = false; |
| TriggerTokenRequest(false); |
| + sync_refresh_skipped_ = false; |
| } |
| } |
| @@ -50,19 +50,48 @@ void ChromeBookmarkServerClusterService::OnSyncCycleCompleted() { |
| // The stars cluster API relies on the information in chrome-sync. Sending a |
| // cluster request immediately after a bookmark is changed from the bookmark |
| // observer notification will yield the wrong results. The request must be |
| - // delayed until the sync cycle has completed. In fact, the ideal signal would |
| - // be "bookmark changed by sync", but we don't have that yet, and this is a |
| - // compromise. |
| + // delayed until the sync cycle has completed. |
| // Note that we will be skipping calling this cluster API if there is no |
| // observer attached, because calling that is meaningless without UI to show. |
| - if (model_->loaded()) { |
| + // We also will avoid requesting for clusters if the bookmark data hasn't |
| + // changed. |
| + if (refreshes_needed_ > 0 && model_->loaded()) { |
| if (observers_.might_have_observers()) { |
| TriggerTokenRequest(false); |
| sync_refresh_skipped_ = false; |
| } else { |
| sync_refresh_skipped_ = true; |
| } |
| + --refreshes_needed_; |
| } |
| } |
| +void ChromeBookmarkServerClusterService::EnhancedBookmarkAdded( |
| + const BookmarkNode* node) { |
| + BookmarkServerClusterService::EnhancedBookmarkAdded(node); |
| + InvalidateCache(); |
| +} |
| + |
| +void ChromeBookmarkServerClusterService::EnhancedBookmarkRemoved( |
| + const BookmarkNode* node) { |
| + BookmarkServerClusterService::EnhancedBookmarkRemoved(node); |
| + InvalidateCache(); |
| +} |
|
Kibeom Kim (inactive)
2014/10/28 17:27:08
Q: Mark, will listening BookmarkAdded and removed
Mark
2014/10/28 18:17:00
IMO, yes. You could listen on deletes too. The k
|
| + |
| +void ChromeBookmarkServerClusterService::InvalidateCache() { |
| + // Bookmark changes can happen locally or via sync. It is difficult to |
| + // determine if a given SyncCycle contains all the local modifications. |
| + // |
| + // Consider the following sequence: |
| + // 1. SyncCycleBeginning (bookmark version:1) |
| + // 2. Bookmarks mutate locally (bookmark version:2) |
| + // 3. SyncCycleCompleted (bookmark version:1) |
| + // |
| + // In this case, the bookmarks modified locally won't be sent to the server |
| + // until the next SyncCycleCompleted. Since we can't accurately determine |
| + // if a bookmark change has been sent on a SyncCycleCompleted, we're always |
| + // assuming that we need to wait for 2 sync cycles. |
| + refreshes_needed_ = 2; |
|
Yaron
2014/10/28 17:48:27
This seems a little too optimistic and tailored to
danduong
2014/10/28 17:50:18
It actually means you'll (at most) fetch twice as
Yaron
2014/10/28 17:52:23
Ugh. Of course. For some reason I assumed it was a
|
| +} |
| + |
| } // namespace enhanced_bookmarks |