Conversation
|
This would be big! |
|
any update? |
|
This would be a nice feature. Hoping it would rollout soon. |
|
I have the same needs! |
|
Hey @rickcasson . What's the purpose of having multiple Info.plist files instead of using variables? |
|
Hi @AngeloAvv, it became necessary to separate the Debug and Release Info.plist files to properly debug and hot reload on iOS14+. Here is the official Flutter documentation: https://docs.flutter.dev/add-to-app/ios/project-setup#local-network-privacy-permissions |
Hi @AngeloAvv, I'm not sure we can use variables in this case: 
And as @rickcasson pointed out, we need to define separate |
|
Hey @rickcasson , are you still interested in developing this feature? |
|
Hi @AngeloAvv, I'm no longer working on the project that needed this, but would still be happy to make any necessary changes so others can use this |
| android: | ||
| flavorDimensions: "flavor-type" | ||
| ios: | ||
| iOSPListFiles: |
There was a problem hiding this comment.
Can we rename it to infoFiles?
| iOSPListFiles: | |
| infoFiles: |
| IOS({Map<String, dynamic> buildSettings = const {}}) { | ||
| IOS( | ||
| {Map<String, dynamic> buildSettings = const {}, | ||
| this.iOSPListFiles = const []}) { |
There was a problem hiding this comment.
I prefer we set the default Info.plist path file here
| } | ||
|
|
||
| @JsonKey(disallowNullValue: true, defaultValue: []) | ||
| final List<String> iOSPListFiles; |
There was a problem hiding this comment.
| final List<String> iOSPListFiles; | |
| final List<String> infoFiles; |
| @@ -30,10 +30,15 @@ part 'ios.g.dart'; | |||
|
|
|||
| @JsonSerializable(anyMap: true, createToJson: false) | |||
| class IOS with BuildSettingsMixin { | |||
There was a problem hiding this comment.
I think we should extend this feature to macos also
| 'ios:plist': () => (flavorizr.app?.ios?.iOSPListFiles != null && | ||
| flavorizr.app!.ios!.iOSPListFiles.isNotEmpty | ||
| ? QueueProcessor( | ||
| flavorizr.app!.ios!.iOSPListFiles | ||
| .map<ExistingFileStringProcessor>( | ||
| (String path) => ExistingFileStringProcessor( | ||
| path, | ||
| IOSPListProcessor(config: flavorizr), | ||
| config: flavorizr, | ||
| )) | ||
| .toList(), | ||
| config: flavorizr, | ||
| ) | ||
| : ExistingFileStringProcessor( | ||
| flavorizr.app?.ios != null && | ||
| flavorizr.app!.ios!.buildSettings | ||
| .containsKey('INFOPLIST_FILE') | ||
| ? flavorizr.app?.ios?.buildSettings['INFOPLIST_FILE'] | ||
| : K.iOSPListPath, | ||
| IOSPListProcessor(config: flavorizr), | ||
| config: flavorizr, | ||
| )) as AbstractProcessor<void>, |
There was a problem hiding this comment.
I honestly don't like putting too much logic here as it makes the processor file unreadable.
I think it would be better to create another processor that extends a QueueProcessor (you can follow this PR to better understand what I mean) and add the logic there.
If the user doesn't define a custom set of info files, the processor should process at least the default one.
Question: Why do we need INFOPLIST_FILE in the buildSettings? You should access infoFiles instead
7 participants
The utility currently is only compatible with projects that use the default Info.plist file name. This PR allows the user to specify a custom list of plist files or specify an individual custom plist using the INFOPLIST_FILE build setting:
or