| I feel like this is an overengineered solution by somebody who is not quite familiar with what the platform has to offer. 1) UIImage already handles choice based on asset name. Apple could use the same asset choice logic server-side for each device, without the developer having to corral his assets into directories. It just needs to be expanded to handle ~ipad and ~iphone (which UIImage does not natively, but if they make this a standard, they could.)
The fallbacks would, of course, be most-specific to least-specific: scale and device before common.
One downside here is that direct path access to an image will not be fixed, but they already do static analysis for message names, you can find calls to bundle methods and keep those assets lying around. 2) JSON?! We have property lists, they're way more Appley and have framework support through-and-through. 3) While this might provide the ability for a developer to choose which resources are used where, Apple is not in the business of giving developers (or users) choices. In other words, I don't think the onus should be on developers. They should be free to do what they do best: innovate about the real problems, not the platform's solvable deficiencies. The above listed can also be applied to all existing app bundles, were Apple feeling adventurous. Parent's method can not. |
Geez, thanks.
UIImage's handling of assets based on file name is a horrible band-aid.
Also, one has to think workflow. And, to make things more interesting, exaggerate. Let's make it 5,000 files in one directory. That's a mess. With device-specific directories an artist could create a workflow leading to easy maintenance and creation of files. No need to engage in funky naming conventions. The per-device files are simply located where they need to be and a mechanism is provided to identify which path serves a particular device type.
Another problem with UIImage is that there is no way to communicate to Apple which files are to be delivered to, say, an iPod touch. So, an external mechanism is required in order to encode that information. Hence the proposal for an external JSON (or whatever) file.
Why JSON. I like it. Supported by iOS 5.0 as well. Easy to maintain and exist externally to Xcode. This also means that I can write scripts or automation tools on a PC or Mac to automate the creation of assets and their placement within the proper structure. The file used within the app to communicate the per-device directory structure would also could also serve external purposes that cannot be covered with plists. In our case, as an example, all of our assets are being produced on PC's, not Macs.
> Apple is not in the business of giving developers (or users) choices.
That's another matter. Although my proposal wasn't about providing choices as much as it is about a mechanism to only deliver the necessary files to a device. Only the developer can make decisions about which files are appropriate, not Apple.
Ultimately, I don't care what technology might be used in order to enable something like this so long as it works and is reasonably open. Right now I'd love to be able to deliver only 1X files to iPods and ~ipad@2X files to the new iPad rather than forcing a huge download of 1,600 files to every device or the current project on our table. That's just silly.