Flash Pro discards AIR icon information.

[hhhhhhhhhhhhhh5]

In Flash Pro, when switching between AIR for Android and iOS, the IDE discards icon information. This is especially frustrating since there are 16 or so icon sizes for iOS. Am I overlooking something or is it really this bad?

[Colin Holgate]

I requested that as an improvement a long time ago. It still hasn't been fixed.

There are 19 iOS icon sizes now, and five supported Android ones (there should be more). I keep a list of the icons from the xml, and when I change from iOS to Android I just edit the xml file to set all the icons in one go.

The supported Android sizes are 36, 48, 72, 96, and 144. The iOS sizes are 29, 36, 40, 48, 50, 57, 58, 72, 76, 80, 96, 100, 114, 120, 144, 152, 180, 512, and 1024. I'm not certain yet whether the 180 one survives, but at least Flash Pro doesn't delete it.

[hhhhhhhhhhhhhh5]

I can't believe this has not been fixed. This should take a couple of hours to coding.

Why not dispense with the idea of manually opening each icon file? How about just pointing to a folder with all the icon files following some naming convention? Even better, create one icon in vector format and let Flash Pro automatically rasterize it to all the required resolutions.

Is there any hope that Adobe fixes this?

[itlancer]

We are suffering from this issue for a long time. Adobe, please fix it!

[Colin Holgate]

It would be nice if it was fixed, but in the meantime it's pretty easy to keep a list of your iOS and Android icons, and paste the list into the xml. I generally go all the way with iOS, then switch to Android to publish there. It's not often that I'm frequently switching between the two.

One complication by the way is that there are two sets of issues. The AIR compiler would need to be changed so that it can ignore the Android icons when doing iOS, and vice versa, and Flash Pro has to be changed to not delete icons that it doesn't know. I'm not sure how closely the two teams work together, maybe they don't, and is why it can take quite some time for fixes in AIR to lead to improvements in Flash Pro.

[hhhhhhhhhhhhhh5]

Colin, I remember reading about your idea of keeping a separate list of icons and pasting it into the xml a few years ago. I liked it and started using it too. But honestly, I don't like messing with the xml file because of a chance to introduce errors. Some people, including myself, switch between iOS and Android all the time. Changing icons manually is a major pain.

You are saying that not deleting the icons will require changes in AIR compiler. How about my suggestion to enter a folder with all the icon files following some naming convention? That won't require any changes in AIR and would be straightforward to code and test. If not, I hope that somebody from Flash Pro team tells us why and I'm sure that another simple solution can be found.

[Colin Holgate]

I find following naming conventions to be stressful, especially the Apple names. I just name the files 20.png, 36.png, and so on. There could be a folder to choose, but that might still require editing the xml to point to the other folder.

The idea of having all the different icons is so that you could in theory give small screen users an easy to read icon, and bigger screen users could be given a fancier designed icon. In practice though I'm sure we all just resize the one icon. Some tools do that for you, you just give it one icon and it creates all the others for you. That would solve part of the problem, the AIR compiler would make Android sizes when building for Android and iOS sizes when building for iOS. But, we would still have to wait for AIR to be updated each time there are new icon size requirements.

Another issue is that iOS icons need to be square, the rounded corners are done by iOS. When I make the Android version I use a rounded corner version of the same icon, using the typical iOS 7 shape.

So, the easiest way I could see it working would be that in Flash you would select one icon file, 1024x1024 let's say, and click a checkbox if you want the corners to be rounded or not. AIR would then make all of the icons for you while it builds the app.

[hhhhhhhhhhhhhh5]

Colin, you are making valid points and your solution would be perfect. What I'm suggesting is a simple addition to the current scheme that is easy to implement and doesn't require any changes in AIR.

Sorry if I didn't clearly explain my proposal. By "naming convention" I meant N.png, where N=resolution. In other words, exactly what you are using right now. There could be different folders for iOS and Android icons if that's what the user needs.

All what is required is one extra button and a function to open the folder, read file names and verify image resolutions. This will not take anything from the flexibility we already have, but will save us a lot of time and frustration.

Before:

After:

[Colin Holgate]

Here's a variation of what you suggest, before I tell about problem! With Flash if you import an image anim001.png, it will notice that there is an anim002.png, anim003.png, etc, and will ask you if you want to import the sequence as an animation. The icon import could do something similar. As soon as you connect any size to a file in a folder, Flash should be able to say "do you want load the other sizes?". That way there isn't a new button or folder import feature, it would just save you time. You would however still have to do that every time you change from iOS to Android.

So, the bigger problem is that iOS does use particular names for icon files. These are the files that AIR makes inside your IPA file:

Icon-Ipad-76.png

Icon-Ipad-152.png

Icon-Iphone-120.png

Icon-Large.png

Icon-Small-40.png

Icon-Small-50.png

Icon-Small-50@2x.png

Icon-Small-80.png

Icon-Small.png

Icon-Small@2x.png

Icon.png

Icon@2x-Large.png

Icon@2x.png

I don't know why it only uses 13 of the 18 or 19 I give it. You can see why I don't like that naming scheme! Anyway, regardless of how easy they make it in Flash Pro to choose your icons, AIR still has to know about that size, and to create the official Apple name version of the file.

[hhhhhhhhhhhhhh5]

That's a great idea! It should be easy to implement and users like us will love it.

As far as icon file names inside IPA files, I don't see how it makes any difference for us. Correct me if I'm wrong, but this is already handled by AIR, so I don't think we should worry about.

[Colin Holgate]

The difficulty is when iOS has new required icons, those have a particular name, and we have to wait for AIR to be updated to know about those names.

[hhhhhhhhhhhhhh5]

I see. Thank you for the explanation. Does this make any difference in regards to the issue of having to select all the icons every time we switch between iOS and Android?

[Colin Holgate]

No, that could be fixed/improved independently of the problem of supporting new icon sizes. If there was an XML file somewhere that gave a list of the sizes and the Apple names, that we could edit, we could add the new icon size support ourselves. But I don't think it works that way.

[hhhhhhhhhhhhhh5]

Yes, that makes sense and would be a great improvement compared to the current situation. Do you think Adobe will do that in the foreseeable future?

[hhhhhhhhhhhhhh5]

Colin, do you know how we can go about requesting this change from Adobe?

[Colin Holgate]

Saturday will be the second anniversary of me logging the bug (#3342605). It's still marked as "deferred". You could start a new feature request here: https://bugbase.adobe.com/

[hhhhhhhhhhhhhh5]

Time to celebrate!

Sorry, I couldn't find that bug at bugbase.adobe.com. Could you post a direct link?

[Colin Holgate]

It's in a pre-release bug system, not the public one.

[hhhhhhhhhhhhhh5]

Is it possible to see that bug record? Could you post it here? I'm particularly interested in Adobe's response. They must have some really good reasons for not fixing this annoyance in two years.

[hhhhhhhhhhhhhh5]

Did they fix it in the latest update? Doesn't look like they did, but perhaps I missed that?

[Umber Funk]

I tried it with AIR 18 beta. Still same...

I think one workaround could be to package manually with ADT.

Second could be to embed the icons in general tab's "included files".

Have not time now to test it.

[Colin Holgate]

I think the problem of losing icons when switching platforms won't go away, and in some ways it doesn't matter. Mainly because the icons for iOS are going to be different to Android. All iOS icons need to be a square, whereas the Android ones are likely to have rounded transparent corners built into them

When you're getting near the end of development it's worth having two FLAs, and different app descriptor files too. Then you can get rid of the iOS splash screens in the Android FLA, and not have to worry anymore about losing icons in the app descriptor files.

[Umber Funk]

Its too bad for me to have 2 fla's of one project. Then I should copy-paste all the fixes or changes I make and if I forget any.... Then find the bug game again.

The packing process should not be so bad. It looks like Adobe spent only a couple of minutes on the AIR packaging interface or newbie made it.

Would be great if they fix it.

[Colin Holgate]

I'm at that end stage in one app, and in my case I have to make an iOS FLA (with all the splash screens in it), one for Amazon FreeTime (that needs to not have any external links in it), one for Google, because it needs to have an expansion pack (it's 100 MB), and another Android FLA that will do for both Amazon and Samsung.

So, you've got it easy!

[hhhhhhhhhhhhhh5]

+1 that