[swift-evolution] [Discussion] Resources

[Karl Wagner]

> On 27. Sep 2017, at 12:32, Karl Wagner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On 25. Sep 2017, at 18:54, Rick Ballard via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Hi Karl and Keith,
>> 
>> (+ swift-build-dev and swift-corelibs-dev)
>> 
>> The SwiftPM core team has had some preliminary discussions already with the swift-corelibs team about the best way to support resources; whatever we do here will likely be a collaboration between SwiftPM and Foundation. We're currently defining our roadmap for SwiftPM in Swift 5, and it's not clear yet whether resource support will fit into this year or not, but either way it's clearly something we'll want to do. We're looking to encourage a thriving developer community around the Swift package manager, and we know that this will be important for many uses. If there are other limitations that are currently holding people back, we'd welcome feedback (and contributions!).
>> 
>> While we're not actively working on a proposal for resource support at the moment, if you have particular thoughts, please feel free to share them, possibly cross-posted between swift-build-dev, swift-corelibs-dev, and swift-evolution.
>> 
>> Cheers,
>> 
>> 	- Rick
>> 
> 
> Thanks Rick, that’s very interesting.
> 
> I have been bouncing some ideas around my head about how to incorporate external resource files as first-class “source” elements of a Swift application (similar to the “resource literals” and “image literals” that we have for Xcode integration).
> 
> Android has the “R” system, which generates resource-ids for things like image and layout-xml resources. I don’t know if that’s a common system used by a lot of platforms, but I first encountered it with Android and it has some features I really like (like compile-time checking that resources exist). I’ve recently been using the “R.Swift” library [1] after a colleague's recommendation, which generates a similar-style interface for Swift projects, and I think that’s also pretty nifty. It improves on the Android system by properly-typing things like image and layout resources (Android reduces them all to integer IDs). I could imagine something like that either built-in to Swift itself, or as a component of SwiftPM.
> 
> We would also need some substantial runtime support. Apple’s platforms introduce resource variations for different devices, localisations, screen densities, colour profiles, etc - and that’s why they have their own “asset catalog” format; to manage all of that complexity. A good cross-platform resources abstraction would need to match that and include some way for each platform to resolve its ideal variation of the resource.
> 
> There are times when rich assets belong below the UI layer. For example, I’m creating a cross-platform SDK for a large company with multiple subsidiary brands. The branding assets are specific in contracts between us and third-parties, and we want our cross-platform SDK to be able to vend the appropriate image resources. So the model object for Brand X could have an ‘icon’ property and the existence of the icon would be verified when we compile the SDK. That SDK could then be used on an iOS device, where the icon is bound to a UIImageView, or on a server, which might render the icon as part of a web-page, or on a cheap linux-based kiosk with a GTK+ UI. That’s my dream.

Just to clarify: I mean that the SDK vends multiple “Brand” objects, each of which *must* be displayed with a particular icon. So we can’t just build a different SDK for each brand - each build must include resources for all brands.

- Karl


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170927/9e76b50e/attachment.html>