apache / cordova-discuss

Discussions on features and the future
19 stars 28 forks source link

Proposal: Add New Image Element to config.xml #6

Closed ktop closed 7 years ago

ktop commented 9 years ago

Discussion started here: http://markmail.org/message/yx3pvydgyxpssgas

At present, there are only an icon element and splashscreen element that handles copying images from a source to destination in the config.xml. These elements also only handle copying 1 image for a specific icon/splash size.

I would like to propose a new tag that would simply handle copying images that wouldn't be used as the app icon or splash image.

The reason to make this new tag is because my users are already using the icon and splash tag in the config.xml, so why not let them specify other images as well in the same place?

I'm open to other ideas, but my architect wanted the user to be able to specify other images in the config.xml, so maybe we can come to a better solution if it can't be done in the config.xml.

cfjedimaster commented 9 years ago

I'm sorry - what? What is the purpose of this? I can ship images by just putting them under the www folder.

On Mon, May 11, 2015 at 2:33 PM, Karen Tran notifications@github.com wrote:

Discussion started here: http://markmail.org/message/yx3pvydgyxpssgas

At present, there are only an icon element and splashscreen element that handles copying images from a source to destination in the config.xml. These elements also only handle copying 1 image for a specific icon/splash size.

I would like to propose a new tag that would simply handle copying images that wouldn't be used as the app icon or splash image.

Example: http://res/android/notification.png http://res/android/notification-mdpi.png

The reason to make this new tag is because my users are already using the icon and splash tag in the config.xml, so why not let them specify other images as well in the same place?

I'm open to other ideas, but my architect wanted the user to be able to specify other images in the config.xml, so maybe we can come to a better solution if it can't be done in the config.xml.

— Reply to this email directly or view it on GitHub https://github.com/cordova/cordova-discuss/issues/6.

Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden

ktop commented 9 years ago

In Android, images are placed in res/drawables (or the other density folders) and in iOS, they go in Resources.

I want the user to be able to specify an image in the config.xml and have it be placed in the respective resource folder, so I'm proposing a new tag in the config.xml to do so since the existing icon and splashscreen tag are only for icon and splash images respectively.

cfjedimaster commented 9 years ago

Ok, but what is the point though? If it is something that will be used by the app itself, why wouldn't you put it under www?

On Mon, May 11, 2015 at 2:44 PM, Karen Tran notifications@github.com wrote:

In Android, images are placed in res/drawables (or the other density folders) and in iOS, they go in Resources.

I want the user to be able to specify an image in the config.xml and have it be placed in the respective resource folder, so I'm proposing a new tag in the config.xml to do so since the existing icon and splashscreen tag are only for icon and splash images respectively.

— Reply to this email directly or view it on GitHub https://github.com/cordova/cordova-discuss/issues/6#issuecomment-101028404 .

Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden

csantanapr commented 9 years ago

Hi we (IBM) are interested on this feature to be able to give opportunity for a developer to provide default images that are used in native side of the plugin not in web view. For example a plugin that shows some type of native UI with a default image. Then developer can overwrite that default image using a tag in config.xml. These are images that don't do into the www/ directory they go into the Android res/ folder.

Hope this helps clarify @cfjedimaster

cfjedimaster commented 9 years ago

Yep, thanks Carlos!

On Mon, May 11, 2015 at 3:04 PM, Carlos Santana notifications@github.com wrote:

Hi we (IBM) are interested on this feature to be able to give opportunity for a developer to provide default images that are used in native side of the plugin not in web view. For example a plugin that shows some type of native UI with a default image. Then developer can overwrite that default image using a tag in config.xml. These are images that don't do into the www/ directory they go into the Android res/ folder.

Hope this helps clarify @cfjedimaster https://github.com/cfjedimaster

— Reply to this email directly or view it on GitHub https://github.com/cordova/cordova-discuss/issues/6#issuecomment-101032436 .

Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden

Chuxel commented 9 years ago

So, one of the things we added in as a VS feature is something called "res/native" and it has turned out to be hugely useful such that we want to be sure it works from the command line as we've improved our CLI interoperability story and released things like Visual Studio Code.

The idea is this: We don't want developers to have to check in the platforms folder both because it is large and because you can run into problems when switching operating systems (in our world Windows / OSX interop is a central need). The problem is there are a number of use cases that you simply cannot predict well that drive you into needing to check in the platforms folder as you need to tweak small things in the native project. What we've seen has been: images as Carlos mentioned, signing requirements, native build settings, things forced by plugins, etc. We can do our best to adapt to all of these, but we cannot completely eliminate them particularly given native platforms change quickly.

So - The thought was we extend what was already done with res/icon and res/splash in the cordova project root to also allow you to overlay arbitrary native project files "before prepare" in a folder called "res/native." Not much to it at the end of the day... it's a simple hook.

Perhaps a more generalized mechanism like this is something we should consider for situations like this in the future?

ktop commented 9 years ago

Thanks for clarifying Carlos. Sorry for not being clear that these images were for native.

@Chuxel I think a more generalized mechanism is definitely possible.

I know that the plugin.xml has the tag "resource-file" that copies a file from src to target, but problem is that the plugin.xml only runs once and that's during plugin install.

Perhaps we could leverage what is already being done in the plugin.xml and use it in the config.xml?

csantanapr commented 9 years ago

I agree with @Chuxel that the idea is to have a generic way to copy files that are outside the www directory.

So using "resource-file" in config.xml makes sense for this specific use case, where a plugin author ships with a default file, and the user has the option to override this file with a user provided file. And this tag needs to be process in after prepare, so it overrides the file provided by the plugin author during the prepare phase.

But I want to be very clear that people should not abuse this tag in config.xml for generic copying files.

The best practice and standard way to do it is to create a cordova plugin with your files and use the "resource-file" in the plugin.xml this way is something easier to manage by tooling and their own organization.

The idea of using config.xml is a last resources where the user can't override a file with a plugin.xml

nikhilkh commented 9 years ago

Where do we stand on this? @ktop What are the next steps?

ktop commented 9 years ago

I don't think there is a decisive conclusion on whether this is a good idea or not. At least with the two people so far who commented are okay with adding this feature. More can be discussed with design and implementation

dpogue commented 8 years ago

I would like to see <resource-file> supported in config.xml for cases like providing notification icons for Android.

Starting with Android Lollipop, notification icons are treated as an alpha mask, so reusing the app icon results in a white square. Currently I have to use a custom hook to copy files around, it would be much preferred for config.xml to handle this for me.

infil00p commented 8 years ago

OK, has anyone actually created a PoC for this feature? Right now, we're just talking about an XML tag, and without seeing how it would impact the CLI, I'm pretty ambivalent to the whole thing.

On Thu, Nov 26, 2015 at 11:14 AM, Darryl Pogue notifications@github.com wrote:

I would like to see supported in config.xml for cases like providing notification icons for Android.

Starting with Android Lollipop, notification icons are treated as an alpha mask, so reusing the app icon results in a white square. Currently I have to use a custom hook to copy files around, it would be much preferred for config.xml to handle this for me.

— Reply to this email directly or view it on GitHub https://github.com/cordova/cordova-discuss/issues/6#issuecomment-159978841 .

macdonst commented 8 years ago

I too would love to see this feature as well. Mostly for the same reasons that @dpogue listed.

zwacky commented 8 years ago

have same use case as @dpogue, really would love to see this.

SolveSoul commented 8 years ago

I also need this for the same reason as @dpogue, I'm currently struggling with the notification icons because of this.

LufoX11 commented 8 years ago

Same here, same reason as @dpogue. I'm using PGB for building so I'm in the worst scenario possible since, for now, I must use my app icon with transparencies (which makes it look like ugly in the device) to use the new android's notification layout.

dpogue commented 8 years ago

For now, I'm using a before_build hook to copy the icons around: https://gist.github.com/dpogue/a382e9f048b09d490d4e

neffnet commented 8 years ago

I ended up here because I'm trying to have a custom notification sound play when my app receives a push notification when it's in a background state. We build with PhoneGap Build, and can't place the sound files in the app bundle correctly for the operating system to access them. We were actually able to get custom notification sounds working on Android by using localization translation support, as files placed in locales/android are packaged by pgBuild into /res/ and our sound file needed to be in /res/raw/ (https://github.com/phonegap/build/issues/401#issuecomment-156277041). But we don't have a solution yet for custom notification sounds for an iOS app built with PhoneGap Build.

nikhilkh commented 8 years ago

Anyone wants to drive this issue to "proposal" stage. Also, there has been talk of adding support to manipulate manifests in config.xml - would that proposal allow us to achieve the same end result?

rdesimone commented 8 years ago

We use a hook to copy the necessary resources for Android push notifications. But IMO this should be made possible in config.xml as proposed. There are also the value resources which are needed in order Google Play displays the supported languages. Maybe this could be done the same way.

jcesarmobile commented 8 years ago

I think we should have a resource-file tag on config.xml as the one on plugin.xml and use it to add an image, sound, json, plist, etc. to the project (same way it works on plugin.xml)

shazron commented 8 years ago

Sounds like a great feature. @ktop I think we can push this as a proposal/pr since I think we have consensus

dpogue commented 8 years ago

I definitely think we should target this as a generic <resource-file> tag rather than specifically images. Ideally we'd be able to reuse the resource-file handling code from plugin installs, but that seems buried quite deep in plugin handlers at the Platform API level :(

dpogue commented 7 years ago

I think this issue can be closed, now that <resource-file> support is in config.xml (and supports more than just images!)