Passing application options during task execution instead of hardcoding in the case of sandboxed application

Hello,

I am considering a use case where one of the application property (e.g.,an ip address) changes for each device (usually defined as system property).

Is it possible for me to pass the property as a gradle task option (which can be done in a CI/CD pipe), so that I can dynamically change it during execution of task ‘localDeploy’ (for sandboxed application), without changing the source?

Hello Siji,

There are different things here, so I would like to clarify first to make sure we are both aligned on what you are asking for.

  • First, the :localDeploy Gradle task can be configured to depend on a property (that can be set by CI/CD) to affect where the application is deployed (on which device).
  • Second, in a multi-sandbox environment, the System Properties are provided by the Kernel.
    Instead, for example, Sandboxed Applications can package application-specific properties as an internal resource and load the resource at runtime using Properties.load().
    • For the Kernel build, using SDK 6, the CI/CD can provide Gradle System Properties to set Kernel System Properties using the following pattern microej.option.microej.java.property.myKey=myValue.
    • For the Application build, using Gradle, you could define some logic to automatically generate an application resource file based on some property passed to the build.
  • Finally, the previous step is about configuring the Application build that produces the Application binary, (.fo). If you want to configure a property accessed at runtime by the application but not rebuild the Application, I don’t think we provide a tool that can safely override the .fo and override/inject an internal resource. What I would recommend instead is to have this property external to the .fo. This could be from different sources:
    • The Kernel you are using may provide a mechanism to package Application metadata as part of the app installation process.
    • The property could then be fetched from the File System, an external resource, or any other API exposed by the Kernel.
    • This could also be an API provided by the Kernel to access some device properties natively, like reading from some EEPROM (e.g. for a MAC address).

If you can clarify your use case, we can provide more details.

Best regards,
Rémy

2 Likes

Thanks for the reply @rlouedec. Currently we are just exploring what are all our available options (aptly listed by you)

Siji,

Great!

That was just a list of what I could think of based on what I understood from your question.
If the different solutions & links do not fit your needs, or if you would like to elaborate on one of those, do not hesitate to come back to us!

Best regards,
Rémy