> On 27. Sep 2017, at 12:32, Karl Wagner via swift-evolution > <swift-evolut...@swift.org> wrote: > > > >> On 25. Sep 2017, at 18:54, Rick Ballard via swift-evolution >> <swift-evolut...@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
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
