[Android] Add support for Partner bookmarks to Chrome bookmark widget

[Android] Add support for Partner bookmarks to Chrome bookmark widget

Before this CL, the current folder of the widget is stored as a long in
the shared preferences. Now it will be stored as a String that can be
serialized directly into a BookmarkId object. The advantage of storing
strings is that it carries sufficient info about whether a bookmark is a
partner bookmark.

BUG=613171
Committed: https://crrev.com/41dd21f931b7f87a57e97efe7d9930316ad7310a
Cr-Commit-Position: refs/heads/master@{#397539}

[Ian Wen, 2016-06-01 23:47:55]

ianwen@chromium.org changed reviewers:
+ tedchoc@chromium.org

[Ian Wen, 2016-06-01 23:47:56]

PTAL this change about bookmark widget. Thanks! :)

[Ian Wen, 2016-06-02 20:23:54]

ianwen@chromium.org changed reviewers:
+ dfalcantara@chromium.org

[Ian Wen, 2016-06-02 20:23:54]

Talked to TPM and he wished to land this tomorrow and merge to M51.

[Ian Wen, 2016-06-02 20:37:02]

renamed.

[Ian Wen, 2016-06-02 20:54:26]

Done

[gone, 2016-06-02 21:04:13]

lgtm

[Ian Wen, 2016-06-02 21:18:07]

The CQ bit was checked by ianwen@chromium.org

[Ian Wen, 2016-06-02 21:18:07]

The patchset sent to the CQ was uploaded after l-g-t-m from
dfalcantara@chromium.org
Link to the patchset: https://codereview.chromium.org/2031893002/#ps60001
(title: " ")

[commit-bot: I haz the power, 2016-06-02 21:19:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2031893002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2031893002/60001

[commit-bot: I haz the power, 2016-06-02 23:27:05]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-06-02 23:28:44]

Description was changed from

==========
[Android] Add support for Partner bookmarks to Chrome bookmark widget

Before this CL, the current folder of the widget is stored as a long in
the shared preferences. Now it will be stored as a String that can be
serialized directly into a BookmarkId object. The advantage of storing
strings is that it carries sufficient info about whether a bookmark is a
partner bookmark.

BUG=613171
==========

to

==========
[Android] Add support for Partner bookmarks to Chrome bookmark widget

Before this CL, the current folder of the widget is stored as a long in
the shared preferences. Now it will be stored as a String that can be
serialized directly into a BookmarkId object. The advantage of storing
strings is that it carries sufficient info about whether a bookmark is a
partner bookmark.

BUG=613171

Committed: https://crrev.com/41dd21f931b7f87a57e97efe7d9930316ad7310a
Cr-Commit-Position: refs/heads/master@{#397539}
==========

[commit-bot: I haz the power, 2016-06-02 23:28:45]

Patchset 4 (id:??) landed as
https://crrev.com/41dd21f931b7f87a57e97efe7d9930316ad7310a
Cr-Commit-Position: refs/heads/master@{#397539}

[Ted C, 2016-06-03 03:16:39]

https://codereview.chromium.org/2031893002/diff/60001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/bookmarkswidget/BookmarkWidgetService.java
(right):

https://codereview.chromium.org/2031893002/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/bookmarkswidget/BookmarkWidgetService.java:65:
private static final String PREF_CURRENT_FOLDER =
"bookmarkswidget.current_folder";
has this pref ever changed?  did it change when we switched over to the new
widget design? 

if the pref didn't change then, it would be sad to have this be the change that
causes users of this widget to lose their folder state.

I'm wondering if we should change the places where we were getting the previous
"current_folder" and first attempt to get the new one as a string and if it's
null fall back to getting the old one as a long.

[gone, 2016-06-03 17:11:27]

On 2016/06/03 03:16:39, Ted C wrote:
>
https://codereview.chromium.org/2031893002/diff/60001/chrome/android/java/src...
> File
>
chrome/android/java/src/org/chromium/chrome/browser/bookmarkswidget/BookmarkWidgetService.java
> (right):
> 
>
https://codereview.chromium.org/2031893002/diff/60001/chrome/android/java/src...
>
chrome/android/java/src/org/chromium/chrome/browser/bookmarkswidget/BookmarkWidgetService.java:65:
> private static final String PREF_CURRENT_FOLDER =
> "bookmarkswidget.current_folder";
> has this pref ever changed?  did it change when we switched over to the new
> widget design? 
> 
> if the pref didn't change then, it would be sad to have this be the change
that
> causes users of this widget to lose their folder state.
> 
> I'm wondering if we should change the places where we were getting the
previous
> "current_folder" and first attempt to get the new one as a string and if it's
> null fall back to getting the old one as a long.

Trying to pull the wrong type out of the same named preference results in a
ClassCastException:
https://developer.android.com/reference/android/content/SharedPreferences.htm...,
java.lang.String)

Don't know if that's something you want to try catch over.

[Ted C, 2016-06-03 17:15:29]

On 2016/06/03 17:11:27, dfalcantara wrote:
> On 2016/06/03 03:16:39, Ted C wrote:
> >
>
https://codereview.chromium.org/2031893002/diff/60001/chrome/android/java/src...
> > File
> >
>
chrome/android/java/src/org/chromium/chrome/browser/bookmarkswidget/BookmarkWidgetService.java
> > (right):
> > 
> >
>
https://codereview.chromium.org/2031893002/diff/60001/chrome/android/java/src...
> >
>
chrome/android/java/src/org/chromium/chrome/browser/bookmarkswidget/BookmarkWidgetService.java:65:
> > private static final String PREF_CURRENT_FOLDER =
> > "bookmarkswidget.current_folder";
> > has this pref ever changed?  did it change when we switched over to the new
> > widget design? 
> > 
> > if the pref didn't change then, it would be sad to have this be the change
> that
> > causes users of this widget to lose their folder state.
> > 
> > I'm wondering if we should change the places where we were getting the
> previous
> > "current_folder" and first attempt to get the new one as a string and if
it's
> > null fall back to getting the old one as a long.
> 
> Trying to pull the wrong type out of the same named preference results in a
> ClassCastException:
>
https://developer.android.com/reference/android/content/SharedPreferences.htm...,
> java.lang.String)
> 
> Don't know if that's something you want to try catch over.

Oh, I'm saying that we keep the renamed pref.  But in the event it is null,
we pull from the old one as a Long and create a NORMAL BookmarkId out of
it (like it was doing before).