[TIMOB-19295] iOS9: Titanium CLI automatically converts existing images to assets catalog
GitHub Issue | n/a |
Type | Technical task |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2015-09-30T02:34:16.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 5.1.0 |
Components | iOS, Tooling |
Labels | appthinning |
Reporter | Chee Kiat Ng |
Assignee | Feon Sua Xin Miao |
Created | 2015-07-31T03:06:57.000+0000 |
Updated | 2015-10-30T21:11:22.000+0000 |
Description
*Need titanium CLI to be able to *
1. generate a default Media.xcassets folder in xcode project
2. transfer existing image files in titanium project into this folder
3. generate corresponding Contents.json file
*Note*
- Details in the Contents.json and folder naming and structure will be based on existing titanium naming convention i.e. image@2x.png, image@3x.png etc.
- Ignore Android specific images. only consider iOS specific, and common platform images.
Attachments
[~cbarber], can we consider this? Tell our Ti developers that if you want to enjoy App thinning on images, they have to do the following naming conventions: A. pic.png, pic@2x.png, pic@3x.png B. No 2 images should share the same name even if it's in different folders On the Tooling side: A. Only process images with suffix *@*, and put them into assets catalogs B. Ignore image files with suffix *@*, and leave them where they are C. If there's a way to check if there's a conflict in names , throw a warning that there's conflicting names. On the SDK side: any image-related loading, we'll check if it's in any assets catalog and load it, otherwise, we will load it from URL.
[~fokkezb], [~ingo], opinions appreciated.
If we ignore images without suffix @, then I assume you mean apart from those who also have a @2x and/or @3x counterpart? This will break apps since I think it's fairly common for some to have:
Maybe we should introduce a new
catalog
folder? Then our logic on that folder can be more simple and strict and it won't break stuff.Can we include the path as part of the image name? Or some other way to make the names distinct?
That's... brilliant! Just hash the filepaths (since there's probably restricted chars)!
Yeah, I like that idea too. So
images/red-theme/go.png
would becomef55a327854b54c63e04d0a1a3694636dc0403aa5_go.png
. You'd just SHA1 the entire resolved path and possibly append the filename. Resolving images from the runtime would be easy. Generating the asset catalogs at build time would be easy too. This still doesn't solve the problem of app thinning. How do we flag which images are meant for certain devices?Well, you know which devices support @2x or @3x and people could use ~ipad etc?
I dunno about that. Maybe it's best to punt this ticket until we build a real catalog system and move away from file naming conventions.
Well, the image asset catalog support by default universal - 1x, 2x, 3x. Then the user is allowed to assign device idioms when they specifically want total control over the images. See attached. !Screen Shot 2015-09-12 at 8.06.45 am.png|thumbnail!
Agree with [~cng] that we can cover first two rows of that screenshot with existing @nx and ~idiom naming schemes and since we don't support watch in Titanium we can go with that without any developer changes
Agreed. We should proceed with option #1.
PR: https://github.com/appcelerator/titanium_mobile/pull/7231 eg. given these images: {quote} images/red/logo/logo.png images/red/logo/logo@2x.png images/red/logo/logo@3x.png images/red/logo/logo@2x~ipad.png {quote} The *image set* name for the group of images will be *SHA1(images/red/logo/logo.png).imageset*.
-[~fmiao] Let me know when you have the backport ready. Thanks!- Nevermind, no backport necessary!
Verified implemented, using: MacOS 10.11.2 (15C27e) Studio 4.4.0.201510290507 Ti SDK 5.1.0.v20151028190028 Appc NPM 4.2.1 Appc CLI 5.1.0-38 Ti CLI 5.0.5 Alloy 1.7.16 Arrow 1.3.13 Xcode 7.2 (7C46l) Node v0.12.7 Java 1.7.0_80 production Existing images are included in the xcode asset catalog and an appropriate contents.json file is generated. Used sample app from parent ticket as well as default projects built/packaged to different targets to test.