[swift-corelibs-dev] [swift-evolution] [Discussion] Resources
razielim at gmail.com
Wed Sep 27 05:32:10 CDT 2017
> 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.
> - 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  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.
>> On Sep 22, 2017, at 9:41 AM, Keith Smiley via swift-evolution <swift-evolution at swift.org> wrote:
>> This is one of the big blockers for our iOS team in moving to SwiftPM. Not all of our internal libraries have resources, but at the very least our UI libraries contain xibs and some images, and more commonly our libraries at least have a Localizable.strings file.
>> We've started moving over to resource bundles to make working with static libraries simpler, which also obviously aren't currently supporting with SwiftPM / cross platform.
>> I think it would be great if SwiftPM could solve this use case!
>> Keith Smiley
>> On 09/22, Taylor Swift via swift-evolution wrote:
>>> I have never once felt a need to distribute a library with an icon
>>> On Fri, Sep 22, 2017 at 10:43 AM, Karl Wagner via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>>> On 21. Sep 2017, at 18:51, Karl Wagner via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>> Hi everybody!
>>>>> I’m really happy that Swift 4 is out, and it’s great that there’s
>>>> already so much active discussion about Swift 5 (concurrency, etc). I find
>>>> I’m running in to language roadblocks less and less, and the improvements
>>>> to the generics system have really improved a lot of my code. It’s really
>>>> enjoyable to program in Swift, so thanks to everybody who made it possible.
>>>>> When I think about what’s missing from Swift, I think of modules. We all
>>>> like to write modular code, and aside from the entire discussion about
>>>> submodules, the way that you glue separate modules together in to an
>>>> application is supposed to be via the package manager. For Swift 5, I would
>>>> personally really like it if we could flesh out the package manager a bit
>>>> more so that it can really be the basis of a thriving Swift developer
>>>> community in production environments.
>>>>> The thing that hits me the most with SwiftPM currently is that it
>>>> doesn’t support resources, and it has very limited support for
>>>> cross-platform modules (the type of thing you’re likely to have as a Model
>>>> or Model Controller layer). Without support for bundled application
>>>> resources, there’s no way for the package manager to support GUI apps or
>>>> frameworks and unit-tests can’t reliably point to bundled test resources.
>>>>> I have some ideas about ways we could improve the situation, but first I
>>>> thought I’d send this out for some community feedback. Do you think SwiftPM
>>>> is as important as I do for v5? Which improvements would give you the most
>>>>> - Karl
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>> Title is rubbish (copy/paste error). Should be “SwiftPM in Swift5”.
>>>> But seriously, one of the themes from the discussions in the past release
>>>> was that “there’s no good library for X” or “when will people use Swift for
>>>> Y?”. I believe the package manager is a big hurdle to getting more, great
>>>> libraries in wider use. CocoaPods is far from sufficient. Thinking about
>>>> this hypothetical future Xcode integration; how is that even supposed to
>>>> happen when the package manager doesn’t support Apps with bundled resources
>>>> (like icons)?
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-corelibs-dev