search

Redth / ResizetizerNT

Add SVG's and PNG's to your shared Xamarin Project
MIT License
318 stars 31 forks source link

Filename casing and pattern issues with Android #44

Open davidortinau opened 3 years ago

davidortinau commented 3 years ago

I had image filenames like layout-StackLayout.png which generated Android resources without error, however nothing displayed in my app for those. If I remove the dash and rename it all lowercase, it works.

My initial reaction is to throw errors and warn the dev of appropriate conventions, however that feels against he value prop of a xplat solution which should handle such annoyances elegantly. We ought to do the right thing for the platform, but I wonder how that'll bite us later. :)

Redth commented 3 years ago

@davidortinau so this is a tough one to handle elegantly given the restrictions android places on this. We ultimately generate resource drawables, and that pretty much limits us to lowercase alphanumeric characters, no number for the first character, and underscores allowed.

We could try and rename files as we generate them to follow the naming rules, but there are some problems with this:

  1. We'd need to also check and change the filenames referenced at runtime (in the image Source for MAUI, for example, if I put Source="The-Cat.png" we need to map that to the_cat.png instead). Keep in mind, this is just for MAUI, and things like Comet, etc will have to do their own handling as well. Plus any other custom code that somehow works around the touch points we use, would need to account for this.
  2. Debugging these 'automagic' transformations can be confusing. Things like inspecting an APK or looking in your obj/ folders you'll see the transformed filename which in some cases might be frustrating.
  3. We can run into collisions more easily. Let's say I have the-cat.png and the_cat.png, when we fix the first filename to use _ instead of -, we now have two files named the same. This is a simple case and we could add more logic to look for collisions and keep changing it until we're good, but it complicates the code, and validation of it both in fixing the filename at build/generation time, and trying to find the right match at runtime.
  4. On Android we do something like this today and it (still afaik) results in the build tasks doing multiple passes over resources since you can reference the invalid name in your other resources - this has been a pain point for awhile and an area that adds a bit of build time - enough that it's been reviewed/debated a couple times when looking for perf improvements.

I'd like to provide a frustration free experience, but it feels like the better path here might be to go and fail fast letting developers know right away that their filename is invalid. It's a pretty quick fix if we provide a detailed error.

bmacombe commented 3 years ago

+1 to the warning. I just noticed all my icons were gone in Android, because I had a couple of images not named to match Android's convention. I would have been scratching my head if I wasn't watching this repro and remembered this issue.

srqdev commented 3 years ago

As I've always used CamelCase for image names in the past , so I vote +1 for just changing the output filename to lower case. And then if it fails any other of the android naming conventions, throw a warning out. Taking a look at the code I see there is a LinkAttribute to specify a different name. If this could be expanded and made specific to the OS, then the above warning would work as you could then override the name for a particular OS.

BenBtg commented 3 years ago

I've just been bitten by this issue. Took a while to figure out why my svg logo wasn't appearing until I renamed it to lowercase. May be useful just to document this in the readme?

valdetero commented 3 years ago

I agree with @srqdev that it should automatically change the name to lowercase since that doesn't change the filename itself. However, I think that if it can't create the files because of a restriction, then it should fail. Resizetizer has one job and if it can't do it successfully then it should stop and inform the developer. I would rather a build error telling me that "the-cat" is invalid than it silently failing and the image just not showing up. I may have made other code changes at the same time and not even consider that Resizetizer is having an issue.

Handling all of the annoyances gracefully is wonderful but all of the complications that Redth mentioned makes it not worth the trouble if you can just tell the consumer "file xyz's naming convention does not meet android restrictions. Go here to see what they are:".