Skip to content

Plugin variables #882

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Fatme opened this issue Sep 7, 2015 · 3 comments
Closed

Plugin variables #882

Fatme opened this issue Sep 7, 2015 · 3 comments
Assignees
Labels
Milestone

Comments

@Fatme
Copy link
Contributor

Fatme commented Sep 7, 2015

myPlugin's package.json:

"nativescript": {
    "platforms": {
      "android": "1.1.3",
      "ios": "1.2.3"
    },
    "variables": {
        "APP_ID": {
             "defaultValue": "myAppId"
        },
        "APP_NAME": {
        }
    }
  }

Plugin add

{N} CLI will store all plugin variables and their values into project's package.json file:

"nativescript": {
    "id": "org.nativescript.androidTest3",
        "tns-android": {
        "version": "1.3.0"
    },
        "myPlugin-variables": {
            "APP_ID": "myAppId",
            "APP_NAME": "myAppName"
        }
}

Valid plugin commands:

  • `tns plugin add myPlugin --var.APP_ID myNewAppId --var.APP_NAME myAppName
  • tns plugin add myPlugin --var.APP_NAME myAppName

Invalid plugin commands:

  • tns plugin add myPlugin
  • tns plugin add myPlugin --var.APP_ID myNewAppId

Prepare

On prepare {N} CLI will replace all references of plugin variable with the specified value by plugin add command.
It seems that it will be enough to respect only AndroidManifest.xml and Info.plist file. But maybe in some cases {N} CLI should respect .java files as well.

@Fatme Fatme added the feature label Sep 7, 2015
@Fatme Fatme added this to the 1.4.0 milestone Sep 7, 2015
@Fatme Fatme self-assigned this Sep 14, 2015
@Fatme Fatme mentioned this issue Sep 29, 2015
@Fatme Fatme modified the milestones: 1.5.0 (under consideration), 1.4.0 Sep 30, 2015
@Fatme Fatme modified the milestones: 1.4.1, 1.5.0 Oct 5, 2015
@PanayotCankov
Copy link
Contributor

We have a plugin that needs the app's id.

Currently its manifest contains something like:

<Manifest>
    <Service id="SERVICE_NAME" />
</Manifest>

Registering an intent service exposed through JavaScript API.

If the service name is provided as plug-in variable, the app package.json will look like:

{
    "nativescript": {
        "id": "com.nativescript.MyPlayground",
        "UploadPlugin": {
            "SERVICE_NAME": "com.nativescript.MyPlayground.UploadPluginService"
        }
    }
}

Currently the plug-in is so designed that the service name is always expected to be the app id suffixed with the plugin name. It would be nice if I could simply use an expression like {{nativescript.id}}.UploadPluginService in the plug-in's manifest.

@Fatme
Copy link
Contributor Author

Fatme commented Oct 8, 2015

@PanayotCankov I've logged your case as separate issue #1026 for next release.

@hdeshev
Copy link
Contributor

hdeshev commented Oct 9, 2015

This feature has so much potential 😁 I hope I'm not too late to the party!

What if:

  1. We could either replace variable occurrences in the source code, or provide an API to get variable values at run time? This could be used by JS/TS code to read usernames, keys, all sorts of configuration data and modify behavior according to some flag. That makes feature flags easy too.
  2. Why store the variables in the app package.json file? This limits us to having a single "environment". What if we design this similarly to Rails environments and store variables in different files, possibly named according to some convention. This way we could allow for easy switching between a dev/qa build of an app and a real production one. Users could use that to hit different API endpoints, enable instrumentation, detect when running in a simulator. With some build time tricks, you can even use this to ship a different version of an app to different customers and implement a multi-tenant solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants