Added getMetaData function

[swesteme]

I needed a function to read custom properties set in the various configuration files. Implementation for iOS, Android and Windows has been added and tested. I ignored wp8 as it is now deprecated.

[yurik94]

Pretty awesome, now I can put api version directly in config.xml, anyway there's a problem:

<meta-data android:name="API_VERSION" android:value="123" />

Note the numeric value.

"java.lang.Integer cannot be cast to java.lang.String"

if (action.equals("getMetaData")) {
        PackageManager packageManager = this.cordova.getActivity().getPackageManager();
        ApplicationInfo app = packageManager.getApplicationInfo(this.cordova.getActivity().getPackageName(), PackageManager.GET_META_DATA);
        callbackContext.success((String)app.metaData.get(args.getString(0))); //HERE ?!
        return true;
  }

I'll try to merge the pull request to integrate browser platform.

👍 to the PR and happy new year!

UPDATE:
I've just found two solutions (even though they're both not elegant)

Prefix android:value number with "\ " :
http://stackoverflow.com/questions/2154945/how-to-force-a-meta-data-value-to-type-string

OR

editing AppVersion.java this way

if (action.equals("getMetaData")) {
        PackageManager packageManager = this.cordova.getActivity().getPackageManager();
        ApplicationInfo app = packageManager.getApplicationInfo(this.cordova.getActivity().getPackageName(), PackageManager.GET_META_DATA);
        Object metadata = app.metaData.get(args.getString(0));
        
        if (metadata instanceof Integer)
          callbackContext.success((Integer)metadata);
        else
          callbackContext.success((String)metadata);

        return true;
      }

If you can find a better solution I will appreciate a lot 👍

[swesteme]

I will experiment with both versions on monday when I am back in the office. I am actually a Java developer and know next to nothing about JavaScript. I would tend to just leave out the cast and "return" the java.lang.Object.

[swesteme]

As there is no success-method overload taking an Object, I went for a slightly modified version of your second example. Only thing I changed is use metadata.toString() instead of (String) metadata.

[yurik94]

Thanks, hope they'll merge it soon 🥇

[sahyun1]

what's happening with this?

[swesteme]

Nothing, apperently. Submitted a pull request months ago... Cheers, Sebastian

[am]

Too bad that the owners of this project don't have time accept collaboration. I think this relates with the issue found here: #89

[sahyun1]

@am yes, it's unfortunate this plugin is not maintained..

@swesteme I managed to install your pull-request by
cordova plugin add cordova-plugin-app-version@https://github.com/swesteme/cordova-plugin-app-version.git#3e6d4709eb0db3b6c16dd1440fa21d5ea05cd54c --save

But to use getMetaData, it seems @ionic-native/app-version needs to be updated as well.
I know that package is not yours to do but as this PR is not merged, it's difficult to request ionic-native to update.

so in the meantime, I'm trying to update the ionic-native/app-version but having difficulties. This bit of code is from index.js, would you be able to help me?

AppVersion.ctorParameters = function () { return []; }; __decorate([ Cordova(), __metadata("design:type", Function), __metadata("design:paramtypes", []), __metadata("design:returntype", Promise) ], AppVersion.prototype, "getAppName", null); __decorate([ Cordova(), __metadata("design:type", Function), __metadata("design:paramtypes", []), __metadata("design:returntype", Promise) ], AppVersion.prototype, "getPackageName", null); __decorate([ Cordova(), __metadata("design:type", Function), __metadata("design:paramtypes", []), __metadata("design:returntype", Promise) ], AppVersion.prototype, "getVersionCode", null); __decorate([ Cordova(), __metadata("design:type", Function), __metadata("design:paramtypes", []), __metadata("design:returntype", Promise) ], AppVersion.prototype, "getVersionNumber", null);

[swesteme]

I have to admit that I am quite clueless about cordova and ionic. I have been an iOS native developer and copy/paste implemented the getMetaData from the rest of the plugin.

[DennisSmolek]

Give me a little bit to go through the open items and this PR and I'll update everyone

[DennisSmolek]

Ok, so the intent of this is to allow users to pass their own custom meta information using the config.xml files, your use case is for API_VERSION but it could be RANDO_PROP.

I can see the benefit of custom meta/build data, but I wonder if it's necessarily correct for this plugin. I'm not opposed to it but I want to limit feature creep.

Before merging and then having to support the custom meta code forever I'd like to ask feedback on if it's right for this plugin?

I could easily add the same things in .env variables or a few other places and may be a better fit.