Improve working with native configuration when necessary

[Plamen5kov]

Problem
Currently as is described in this issue users some times have a hard time understanding when and if they can use a common place like package.json to change the native configuration of a project.
As is described in the issue:

1. During project creation CLI sets app id directly in app/App_Resources/app.gradle, so any additional changes in package.json will not be respected (for Android only).
2. During every prepare of iOS platform, CLI replaces the bundle identifier in platforms/ios/<project_name>/*.plist with the id in package.json and disregards value in app/App_Resources/ios/Info.plist.

In short we have different behavior on different platforms, which is behavior that needs fixing.

Solution
If it can't be fixed with one common abstraction, we should completely separate the native configuration of iOS and Android projects.

The current example affects only the app_id, but we need to take into account all native configurations when resolving this issue.

[tzraikov]

Do you think it is a bad option to use the same approach as used in iOS in Android projects? We can copy the app.gradle file in platforms/android and do all replacements here on every build. This will allow both newcomers to edit the package.json and power users to do changes in app.gradle. It will also remove the path dependency in android gradle script. I would vote for this option.

[pkoleva]

Related #2187

[maoueh]

Seems also I hit another related problem (I think). I'm trying to have a different id for Android and for iOS (something like com.acme.ios.project and com.acme.android.project).

I updated app/App_Resources/iOS/Info.plist to put specific identifier there. But the identifier from package.json (nativescript.id) was still overriding it.

So, we decided to remove it from there. But then, the tns prepare android version is not working anymore failing with a message:

Preparing project...
Error: sed: invalid replacement string

This is caused by nativescript/lib/services/android-project-service.js:171:19 which is shell.sed('-i', /__PACKAGE__/, this.$projectData.projectId, manifestPath);. I guess it's failing because nativescript.id in package.json is now undefined.

Should I create a new issue specifically for this or it can be part of the issue?

[Plamen5kov]

Hi @maoueh,
Yes, please create a new issue, and we'll figure out the problem.

EDIT: @maoueh please take the time to leave your opinion here. What do you think is best when it comes to providing a way to configure the project. Should we keep, info.plist and AndroidManifest.xml for the native configuration, and should they have the highest priority?

[maoueh]

@Plamen5kov Note that editing comment does not trigger a new GitHub email, so it's possible to miss it.

In my opinion, info.plist and AndroidManifest.xml are mandatory to keep for application id unless there is a way to choose id differently based on the platform.

As I see things now, I would keep them both and they would have precedence over nativescript.id.

So, if nativescript.id is set and no app id is present in native file (AndroidManifest.xml or info.plist, then it should be used).

Otherwise, if a value is set in native file, it should stay as-is and as such, have higher precedence over nativescript.id.

Matt

[maoueh]

@Plamen5kov I've create an independent issue for nativescript.id requierement.

[nicoabie]

Once the platform is added, if the nativescript.id is changed then the app won't be started anymore in the emulator.

[tjvantoll]

As @nicoabie said above, if you have mismatched app ids (which is quite easy to do currently), your app will no longer start on an Android emulator, and you have no obvious idea why. I lost several hours on this problem until @rosen-vladimirov helped me out in #3111.

We’re relying on users to realize that they have to update final application ids in two different places, which is obviously error prone. My vote is to remove the app id from the root package.json entirely, as there’s a chance you might want different app ids on Android and iOS. But I’d be ok with any change that doesn’t require you to hardcode the same string in multiple locations for the same platform.

[gabitoesmiapodo]

I agree.

Or it may be done with something like NativeScript Sidekick, I don't know.

[surdu]

Wouldn't be an acceptable solution to at least document that you also have to modify the gradle file in the docs here ?

[Plamen5kov]

Originally the idea was to consider all native configurations and handle them in a "native configuration file". We've since discussed the topic and we've provided all the native configuration options in the App_Resource folder. Keeping that in mind, we're planing on updating the documentation if necessary.

[manijak]

I don't get it, can we have different app ids for each platform or not? Kinda annoying having to remember to change the app ids in package.json every time I switch platforms

[surdu]

@manijak As far as I understand this is coming soon

[alx741]

I just stumbled upon this, maybe is a good idea to document it as @surdu suggests, at least temporary until a permanent solution comes (?)

[kspearrin]

Still waiting for the ability to have different package ids on iOS vs Android. Is there a workaround other than manually changing it in package.json every time?