Skip to content
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

feat(Android): Refactoring configuration #3778

Merged
merged 35 commits into from
Dec 15, 2020
Merged

feat(Android): Refactoring configuration #3778

merged 35 commits into from
Dec 15, 2020

Conversation

carlpoole
Copy link
Member

@carlpoole carlpoole commented Nov 8, 2020

This branch seeks to improve the config use in Android similar to #3759.

  • Config can now be initialized from capacitor.config.json and programmatically via ConfigBuilder for embedded use case
  • The existing config getters like getInt and getString are deprecated.
    • For plugins, use getPluginInt and getPluginString.
    • For core config values, use the new direct accessor like getServerUrl and getBackgroundColor
  • Added tests for the Builder and JSON Reading use cases.

@imhoffd imhoffd added this to the 3.0.0 milestone Nov 19, 2020
@carlpoole carlpoole marked this pull request as ready for review December 1, 2020 18:44
carlpoole and others added 2 commits December 1, 2020 16:44
Conflicts:
	android/capacitor/src/main/java/com/getcapacitor/Bridge.java
	android/capacitor/src/main/java/com/getcapacitor/BridgeActivity.java
	android/capacitor/src/main/java/com/getcapacitor/WebViewLocalServer.java
Comment on lines 57 to 58
loadConfig(assetManager);
deserializeConfig();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should all this be happening in the constructor? Maybe we can take this opportunity to practice some separation of concerns. The iOS side now has a few different classes that separate "loading from a JSON file" and "containing the configuration".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback. I have removed the public constructor for CapConfig and replaced it with a method fromFile that can be used to create an instance of CapConfig from the JSON config file.

I moved the JSON file loading to the FileUtils class since it involved reading a file and seemed appropriate there (and its also reused elsewhere in the core).

@ionic-team ionic-team deleted a comment from imhoffd Dec 8, 2020
Copy link
Member

@jcesarmobile jcesarmobile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CapConfig was created to avoid a breaking change as we had the Config class and users were using it on plugins. Used CapConfig as the name to also match iOS name.
Since this PR changes the constructor, that's also a breaking change.
Not sure if instead of changing the constructor, we rename the class to InstanceConfiguration as Ian did on the iOS equivalent #3759

@carlpoole
Copy link
Member Author

CapConfig was created to avoid a breaking change as we had the Config class and users were using it on plugins. Used CapConfig as the name to also match iOS name.
Since this PR changes the constructor, that's also a breaking change.
Not sure if instead of changing the constructor, we rename the class to InstanceConfiguration as Ian did on the iOS equivalent #3759

It is a breaking change, but is it expected that 3rd parties would be creating new instances of CapConfig? I updated the code in the core to use the new constructor. If it's not an expected use-case or an embedded/edge case, it might be an acceptable breaking change.

I can see the appeal in naming things similarly to iOS, but I don't think it should be the rule. Java has instances of classes so the name "InstanceConfiguration" feels unnecesarily verbose, but we are likely introducing a new class here to contain the plugin config, so we do need some name work.

Copy link
Member

@jcesarmobile jcesarmobile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think both platforms should be as close as possible, specially when two classes do the exact same thing. If not, when somebody not familiar with one of the two platforms needs to do some change in the other platform will have a hard time finding things.
But if you don't agree I'm ok with it.

@@ -39,7 +39,7 @@ protected void init(Bundle savedInstanceState, List<Class<? extends Plugin>> plu
* use {@link BridgeActivity#bridgeBuilder}.
*/
@Deprecated
protected void init(Bundle savedInstanceState, List<Class<? extends Plugin>> plugins, JSONObject config) {
protected void init(Bundle savedInstanceState, List<Class<? extends Plugin>> plugins, CapConfig config) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is already a breaking change, we should just remove it. init() is the deprecated way of initializing the Android bridge.

@carlpoole carlpoole merged commit 9820a30 into main Dec 15, 2020
@carlpoole carlpoole deleted the android-config branch December 15, 2020 00:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants