We need the break the task into the following steps:
1. Have the new MediaSessionObserver side-by-side with the old WebContentsObserver. Make MediaSessionObserver and MediaSession in content/public/browser, and MediaSessionImpl in content/browser.
2. Let chromecast/ CastMediaBlocker use the new pipeline.
3. Change on the Java side and remove the old pipeline (maybe possible to split into two CLs).
Ah, yes. Done!
The new layout should have cleaner ownership, since Java observers are now owned by Java ChromeMediaSession, and don't have native counterparts anymore.
the doc doesn't have a content api boundary
fwiw, content java code doesn't really have a public API similar to how native content/public works, but there really should be one. don't abuse that fact too much..
> the doc doesn't have a content api boundary
>
> fwiw, content java code doesn't really have a public API similar to how native content/public works, but there really should be one. don't abuse that fact too much..
Thanks. Just updated the doc. I've already seen this issue with chromecast/ (https://codereview.chromium.org/2450433002/),
so I'm splitting MediaSession interface & MediaSessionObserver into content/public.
I didn't see how the doc changed. And still don't see where the content api boundary lies in the diagram. Or is everything in the diagram supposed to live in content?
Comment 1 by zqzh...@chromium.org
, Oct 24 2016