Update WebAPKs even if the WebAPK start URL has no Web Manifest part 1/3

chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java

Index: chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java b/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java
new file mode 100644
index 0000000000000000000000000000000000000000..e3b1ea23e276926889542054d5f4c51166df8be2
--- /dev/null
+++ b/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkMetaData.java
@@ -0,0 +1,24 @@
+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+package org.chromium.chrome.browser.webapps;
+
+/**
+ * Meta data from the WebAPK's Android Manifest.
+ */
+public class WebApkMetaData {
+    public int shellApkVersion;

[dominickn, 2016/10/24 11:34:59]

There are now a lot of very similar classes flying around - WebappInfo,
WebappDataStorage, the FetchedManifestData - as well as the field properties in
a bunch of classes and the Android Manifest and now this class. I'm starting to
get concerned about all of the duplication, particularly since all of these
classes carry some sub/super-set of the other classes' information. It's getting
difficult to keep up with them all.

Lots of classes with very similar pieces of information is a bit of an
anti-pattern. At the very least, can we make the FetchedManifestData use the
same class as this?

[pkotwicz, 2016/10/24 16:03:43]

In a follow up CL, I can merge this class with FetchedManifestData.

We would need to find a good name for this "shared class". WebApkMetaData is a
bad name because ManifestUpgradeDetectorFetcher does not fetch the <meta-data>
from the Android Manifest.

WebApkData perhaps?

[dominickn, 2016/10/25 07:39:16]

What about WebApkInfo? That means it mirrors WebappInfo. We could even go to the
point of having a common subclass which contains the information which is shared
between WebappInfo and WebApkInfo. Then WebappInfo/WebApkInfo extend that class
and add whatever custom fields they need (many more in WebApkInfo!). Thoughts?

[pkotwicz, 2016/10/26 01:53:29]

WebApkInfo sounds good.

I am hesitant to make WebApkInfo extend WebappInfo. I don't foresee a WebApkInfo
implementation for WebApkInfo#setWebappIntentExtras().

Making WebApkInfo extend WebappInfo would be an easier decision if WebappInfo
were not used in WebappLauncherActivity

[dominickn, 2016/10/26 02:04:56]

You misunderstood me. I suggested having:

class WebappCommonInfo

class WebappInfo extends WebappCommonInfo

class WebApkInfo extends WebappCommonInfo

I agree that it doesn't make sense for WebApkInfo to extend WebappInfo. But both
can extend a common base class because so many of the fields are the same.
That's why I suggested making the fields private in this class and using
getters, because that's probably what you should have if you implement a common
base class (the base class will have protected fields).

[pkotwicz, 2016/10/26 03:57:01]

That proposal sounds reasonable. I will do it in a follow up CL though

[dominickn, 2016/10/27 00:42:48]

Great, thanks! It will help clean up a bunch of things.

+    public String manifestUrl;
+    public String startUrl;
+    public String scope;
+    public String name;
+    public String shortName;
+    public int displayMode;
+    public int orientation;
+    public long themeColor;
+    public long backgroundColor;
+    public int iconId;
+    public String iconUrl;
+    public String iconMurmur2Hash;
+}