This has some overlap with design work I'm planning to pick up in the next couple of weeks for the Feed library integration, so it'd be good to coordinate :)
Is this bug intended to capture only the articles list or some of the other NTP content (e.g. tiles, logo view, etc) as well?
Also, do you have a general idea of the new class structure that we're shooting (e.g. which classes get broken up/removed, which new classes get added)?
Yes, let's coordinate :)
I'm definitely planning to start with articles (which is already in a closer state than other stuff), but then see if I can also refactor tiles and/or the currently somewhat monolithic NewTabPageLayout.
The general idea (at least for articles) is to adapt the tree classes to observer/observable (for propagating change notifications to the adapter) and ViewBinder (for delegating bindViewHolder etc. calls). Currently there are a lot of subclasses of InnerNode etc which contain both what we would call model and controller code in the UI architecture -- I want to pull that out into separate classes and make InnerNode a concrete class that just observes the model (essentially a ModelChangeProcessor that forwards events either to its parent or the root RecyclerView adapter). The other goal of this is to make the classes reusable for other RecyclerView-based UIs (e.g. downloads). That's my initial brain dump for now :)
Re #2, great! I'll keep you in the loop on my Feed integration design planning. My primary goal is to get the code refactored in a way that allows for re-use with the Feed lib Stream API, and bringing the NTP architecture closer to our new MVC pattern in the process. There's a lot of code to pick apart and behavior/functionality to figure out a home for (e.g. thumbnail capturing, snap scroll behavior, fake search box to real omnibox transition), so I'm hoping to be able to identify the end architecture in broad strokes then figure out some tactical steps to start moving in that direction.
Comment 1 by twelling...@chromium.org
, May 30 2018