rename packageName to unambiguous name in app objects

RESOLVED FIXED in Firefox 29

Status

()

P1
normal
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: myk, Assigned: myk)

Tracking

unspecified
Firefox 29
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

5 years ago
Over in bug 934756, Fabrice suggested we rename the "packageName" property of app objects to "apkName" to avoid confusion over the meaning of the word "package", since packaged apps have both a "webapp package" and an "APK package".

We didn't end up making that change in the patch that landed in that bug, but I think we should do so before we enable the feature, since the potential for confusion is high.

We need to be careful about where we replace "package" with "apk", since it's appropriate to use the word "package" in Fennec's Java code, where "packageName" is the conventional term for an APK's class name.

So we should only make the change in the JavaScript app object itself, any JSON representations of it, and any messages that the DOMApplicationRegistry sends or receives regarding apps.
(Assignee)

Updated

5 years ago
Assignee: nobody → myk
Priority: -- → P1
(Assignee)

Comment 1

5 years ago
Created attachment 8360695 [details] [diff] [review]
apk-name.diff

This patch changes "packageName" to "apkName" and "packages" to "apks" in the following places:

1. The app objects created and stored by Webapps.jsm and AppsUtils.jsm.
2. The messages passed between those modules, WebappManager.jsm, and Java classes in Fennec.

It doesn't touch the names of variables in the Java classes, nor does it change the use of "packageName" in Intent objects that are exchanged between Fennec and webapp APKs.

Thus it carefully distinguishes between Open Web App contexts, where the word "package" could mean either Open Web App package or Native Android Package and Native Android App contexts, where "package" always means Native Android Package.

No fix will absolutely prevent us from ever making a mistake, but this seems like the best way to maximize clarity and minimize the risk of error.

Requesting review from Fabrice for the (one-line!) AppsUtils.jsm change and from WesJ for the other changes.
Attachment #8360695 - Flags: review?(wjohnston)
Attachment #8360695 - Flags: review?(fabrice)
Attachment #8360695 - Flags: feedback?(jhugman)
(Assignee)

Comment 2

5 years ago
Created attachment 8361217 [details] [diff] [review]
apk-package-name.diff

jhugman pointed out this morning that apkName is used elsewhere to mean something different, so this patch changes the name to apkPackageName instead.
Attachment #8360695 - Attachment is obsolete: true
Attachment #8360695 - Flags: review?(wjohnston)
Attachment #8360695 - Flags: review?(fabrice)
Attachment #8360695 - Flags: feedback?(jhugman)
Attachment #8361217 - Flags: review?(wjohnston)
Attachment #8361217 - Flags: review?(fabrice)
(Assignee)

Updated

5 years ago
Summary: rename packageName to apkName in app objects → rename packageName to unambiguous name in app objects
Attachment #8361217 - Flags: review?(fabrice) → review+
(Assignee)

Updated

5 years ago
Status: NEW → ASSIGNED
Comment on attachment 8361217 [details] [diff] [review]
apk-package-name.diff

Review of attachment 8361217 [details] [diff] [review]:
-----------------------------------------------------------------

TBH, I would rather that we used apkPackageName everywhere, including Java, to keep things consistent, but I'm happy to let that slide. One little nit though:

::: mobile/android/base/webapp/UninstallListener.java
@@ +46,5 @@
>              JSONObject message = new JSONObject();
>              JSONArray packageNames = new JSONArray();
>              try {
>                  packageNames.put(packageName);
> +                message.put("apks", packageNames);

This seems a little odd. I was thinking in the earlier cases that maybe we'd be better to just use "apk" instead of "apkPackageName", but I'd understand if you thought that was deceptive (they're not apks, the the names of apks). Here you do use "apks" though. Maybe this should be "apkPackageNames" (tbh, I'd rather we just used "apk" everywhere I think... because my brain is too small for such big words)
Attachment #8361217 - Flags: review?(wjohnston) → review+
I agree with wesj on this one re keeping apkPackageName consistent throughout the codebase, including Java.

A variable called apk may conceivably be referring to the apk's filename, which should probably be called apkFilename.
(Assignee)

Comment 5

5 years ago
Created attachment 8363906 [details] [diff] [review]
patch v1: fixes nit

(In reply to Wesley Johnston (:wesj) from comment #3)

> TBH, I would rather that we used apkPackageName everywhere, including Java,
> to keep things consistent, but I'm happy to let that slide.

There are a bunch of references to packageName in the Java code, and not just in webapp-related code: packageName is the canonical name for such values in Android APIs.  So it seems preferable to use it whenever possible in the synthetic APK code, for consistency with Android and other Fennec Java code.

For that matter, we could also use it in the messages passed between Java code and Fennec JavaScript code (i.e. WebappManager.jsm).

The only place where it's really important to distinguish between Open Web App package and Android package is in the app records stored in DOMApplicationRegistry, which we won't be able to change easily after we enable synthetic APKs, since they're stored on-disk in persistent JSON data structures.

But there are comparatively few references to that property in those records (specifically: three), so we wouldn't lose much consistency if they were the odd men out.


> ::: mobile/android/base/webapp/UninstallListener.java
> @@ +46,5 @@
> >              JSONObject message = new JSONObject();
> >              JSONArray packageNames = new JSONArray();
> >              try {
> >                  packageNames.put(packageName);
> > +                message.put("apks", packageNames);
> 
> This seems a little odd. I was thinking in the earlier cases that maybe we'd
> be better to just use "apk" instead of "apkPackageName", but I'd understand
> if you thought that was deceptive (they're not apks, the the names of apks).
> Here you do use "apks" though. Maybe this should be "apkPackageNames" (tbh,
> I'd rather we just used "apk" everywhere I think... because my brain is too
> small for such big words)

I hear ya, and I like smaller and simpler too, even at the cost of some accuracy.  I opted to address this nit by changing the three "apks" references to "apkPackageNames" for now, because it's a smaller change from the existing patch.  But we can revisit and change these later, since they aren't stored persistently.

Here's the patch with the nit addressed.  This is the version I'll commit.
Attachment #8361217 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/d9ab1a467525
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
(Assignee)

Updated

5 years ago
Depends on: 970300
You need to log in before you can comment on or make changes to this bug.