The native apps and Webapk in the app banner can be very different and there is a little more shared code to do tings but it must be delegate.

What i am trying to tell you is that the logic things for the native apps is that they are very delegate and their android is really not working.

Please hold off on too much work on this as I have a huge app banner change coming down the pipeline (conversion from Chrome IPC to Mojo). I'm hopeful of landing the change in the next couple of weeks.

Sounds good. As splitting the c++ class and the java class actually involves many files across the codebase, I'm going to wait until your change lands. Can you please give me the bug number of your task so I can mark it "blocked by" here? Thanks!

The CL is up for review at https://codereview.chromium.org/2393513004/ and tracked at  crbug.com/499704 .

I'm not entirely convinced that splitting AppBannerInfoBarDelegateAndroid is the right move at this time. The resulting Web delegate is still going to have a bunch of WebAPK/non-WebAPK functionality while WebAPKs are in testing, while the Native delegate will still need to replicate the install state changing and so forth.

It may be better to reevaluate the split once we've worked out exactly how WebAPKs will replace the ordinary PWA banner.

Dominick:
Any updates on this as the Mojo CL has landed? Do you think it a good idea to split them? Thanks!

I'm still not convinced we want to do this now. There's not an immediate tangible need or benefit. I think it would be better to wait until we have a clearer idea of the long term plan for WebAPKs and whether they will completely subsume the existing standalone web apps (and / or native apps).

Having thought about this more, I think what actually makes sense is splitting out a new webapk_infobar_delegate.

We want to experiment with app banners displaying the add-to-homescreen dialog instead of the infobar, and seeing how that affects click through rates. This would unify the UI with the existing add to homescreen.

This is really difficult to do right now because of the WebAPK stuff mixed into AppBannerInfoBarDelegate. So I'm going to propose that the WebAPK stuff is broken out into a new WebApkInfoBarDelegate. AppBannerInfoBarDelegate.java will be renamed to WebApkInfoBarDelegate.java, and the app banner specific stuff in there will move to AppBannerManager.java.

I think this is a much more logical separation right now. Replacing existing web apps with WebAPKs down the track would simply mean erasing the web app side of AppBannerInfoBarDelegate (so it's only for native apps), and inserting WebApkInfoBarDelegate in its place.

I will probably take on this splitting up because we'll want it for app banners in M56.

Some problems that this change will solve:

 - when WebAPKs are enabled, the add to homescreen menu item triggers an app banner. That means that app banner stats are polluted by add to homescreen
 - there is a lot of functionality inside AppBannerInfoBarDelegate that should really be handled by the AppBannerManager (installation, recording metrics, asking Java for information on the native app)
 - no more is_webapk / is not webapk logic

By making WebApkInfoBarDelegate inherit from AppBannerInfoBarDelegate and overriding the right methods, we should be able to still use the same underlying AppBannerInfoBar class.

And some further investigation reveals that WebApkInfoBarDelegate doesn't need to inherit from AppBannerInfoBarDelegate at all - AppBannerInfoBar doesn't need anything more specific than a ConfirmInfoBarDelegate.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b84e58a2540e004466d0215a0efe4b42b5c3c298

commit b84e58a2540e004466d0215a0efe4b42b5c3c298
Author: dominickn <dominickn@chromium.org>
Date: Fri Nov 04 02:31:12 2016

Ensure WebAPKs installed from the menu do not pollute banner statistics.

Currently, WebAPKs reuse the AppBannerInfoBarDelegate, even if they are
added via the Add to Homescreen menu item. This means they incorrectly
send app banner metrics when they have not been added from a banner
triggering.

This CL guards all app banner metrics callsites in WebAPK codepaths in
AppBannerInfoBarDelegate to ensure that app banner stats are not
polluted.

BUG= 651894 

Review-Url: https://codereview.chromium.org/2473243002
Cr-Commit-Position: refs/heads/master@{#429770}

[modify] https://crrev.com/b84e58a2540e004466d0215a0efe4b42b5c3c298/chrome/browser/android/banners/app_banner_infobar_delegate_android.cc
[modify] https://crrev.com/b84e58a2540e004466d0215a0efe4b42b5c3c298/chrome/browser/android/banners/app_banner_infobar_delegate_android.h

Dom - is this finished?

WebAPKs not longer reuse the app banner.