You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Aided generation of platform-specific app icons #10387
It would be nice to be able to generate platform-specific resources (e.g. application icons) for each platform based on some given resource.
As an example could be ionic cordova resources command (documentation) that based on some single image can automatically generate all necessary icons of iOS and Android and place to folders, where they should be.
It can also analyse if source image is good enough (resolution), and optionally make some post-processing (e.g. rounded corners for iOS icons).
Our current system uses a unified resources model. Although we've been considering switching away from that model to using the per-platform resource systems: #9900
@eseidelGoogle are not but application icons currently stored in per-platform location (for iOS it's ios/Runner/Assets.xcassets/AppIcon.appiconset/)?
I know that other assets (specified in pubspec.yaml) are unified for both platforms, but I was not able to find unified application icon from which platform-specific icons generated (it would be perfect solution)
@mit-mit would be nice to have generated splash screen (or "Static Launch Screen" as it is in iOS, I don't know if there is something same for Android).
Flutter startup time is blazing fast, but... may be with it we can void small dark-screen blink during application startup...
The code will be same as for icons (just resize/crop image to specific sizes and change config), but will give some benefit :)
@olostan we should probably track the "static launch screen" desire in a separate bug. Would you be willing to file? You may also be interested in #8127.
We discussed this in the triage meeting, and we believe that the actual task of generating platform-specific icons from assets is not something we want to do as part of stock Flutter. However, we do think we should make it possible to hook our build system into such a tool if one was available.
Well a build script would only run when the files needed updating (builds in general should be incremental). But if all you want is a local shell script to do this, I don't think you need the flutter tool at all. Just have a bash script in the directory that you run directly. That's essentially all that a flutter subcommand would do anyway.
@Hixie I completely agree with your points. However generation of platform specific application icons is so common task in mobile application development process, especially for cross-platform tools, so it would be really usefull to have this possibility boundled in flutter tool (same as Ionic, for example).
But, ofcourse, it's not critical - there are several side-tools and scripts to achieve this. Having possibility to create an mobile app with only Flutter can just decrease on-boarding process. So please consider this request as a wish
This is a valid use case, but we want to look at solving this in a generic way. Ideally, there's a developer-accessible build system which Flutter either provides or can take part of. Something like make, gradle, maven, etc, etc. If such an extensible system for Flutter existed, we'd see a rich ecosystem of "tasks" be submitted to pub.dartlang.org in order to fill out the esoteric or even common build tasks (shrink this, reformat that, code generate this, download a thing, etc, etc).
Today, Flutter's CLI isn't built to support user extensibility. I'd like to close this issue and point to a more generic issue for allowing our developers the ability to extend the build process.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
eseidelGoogle commentedon May 30, 2017
Our current system uses a unified resources model. Although we've been considering switching away from that model to using the per-platform resource systems: #9900
olostan commentedon May 30, 2017
@eseidelGoogle are not but application icons currently stored in per-platform location (for iOS it's
ios/Runner/Assets.xcassets/AppIcon.appiconset/)?I know that other assets (specified in
pubspec.yaml) are unified for both platforms, but I was not able to find unified application icon from which platform-specific icons generated (it would be perfect solution)mit-mit commentedon May 30, 2017
Adjusting title to be specific to icons as per gitter discussion
[-]Generating of platform-specific resources[/-][+]Aided generation of platform-specific app icons[/+]olostan commentedon May 30, 2017
@mit-mit would be nice to have generated splash screen (or "Static Launch Screen" as it is in iOS, I don't know if there is something same for Android).
Flutter startup time is blazing fast, but... may be with it we can void small dark-screen blink during application startup...
The code will be same as for icons (just resize/crop image to specific sizes and change config), but will give some benefit :)
eseidelGoogle commentedon May 30, 2017
@olostan we should probably track the "static launch screen" desire in a separate bug. Would you be willing to file? You may also be interested in #8127.
eseidelGoogle commentedon May 30, 2017
Possibly related to #9870.
Hixie commentedon May 30, 2017
We discussed this in the triage meeting, and we believe that the actual task of generating platform-specific icons from assets is not something we want to do as part of stock Flutter. However, we do think we should make it possible to hook our build system into such a tool if one was available.
Hixie commentedon May 30, 2017
@sethladd, can you see if we have an open bug for build script integration?
olostan commentedon May 31, 2017
@Hixie please take into account couple of things from typical usages:
That's why I thought it would be more convinient to have it as one of flutter subcommand and not "build scripts"/transformers
Hixie commentedon May 31, 2017
Well a build script would only run when the files needed updating (builds in general should be incremental). But if all you want is a local shell script to do this, I don't think you need the flutter tool at all. Just have a bash script in the directory that you run directly. That's essentially all that a flutter subcommand would do anyway.
olostan commentedon Jun 1, 2017
@Hixie I completely agree with your points. However generation of platform specific application icons is so common task in mobile application development process, especially for cross-platform tools, so it would be really usefull to have this possibility boundled in flutter tool (same as Ionic, for example).
But, ofcourse, it's not critical - there are several side-tools and scripts to achieve this. Having possibility to create an mobile app with only Flutter can just decrease on-boarding process. So please consider this request as a wish
sethladd commentedon Jun 20, 2017
This is a valid use case, but we want to look at solving this in a generic way. Ideally, there's a developer-accessible build system which Flutter either provides or can take part of. Something like make, gradle, maven, etc, etc. If such an extensible system for Flutter existed, we'd see a rich ecosystem of "tasks" be submitted to pub.dartlang.org in order to fill out the esoteric or even common build tasks (shrink this, reformat that, code generate this, download a thing, etc, etc).
Today, Flutter's CLI isn't built to support user extensibility. I'd like to close this issue and point to a more generic issue for allowing our developers the ability to extend the build process.
For example: #9870
github-actions commentedon Sep 4, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.