Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future for this framework - drop SDWebImage naming #88

Open
dreampiggy opened this issue Mar 29, 2020 · 2 comments
Open

Future for this framework - drop SDWebImage naming #88

dreampiggy opened this issue Mar 29, 2020 · 2 comments
Labels
API API changes

Comments

@dreampiggy
Copy link
Collaborator

dreampiggy commented Mar 29, 2020

Currently this framework named "SDWebImageSwiftUI"

However, the SDWebImage part is only the dependency, most of common usage code does not related to SDWebImage itself. The only Public API now can touch SDWebImage:

  • WebImage.options
  • WebImage.context
  • AnimatedImage.context
  • AnimatedImage.context
  • AnimatedImage.transition
  • AnimatedImage.indicator
  • ImageManager.options
  • ImageManager.context

If we can build a own wrapper, we can totally eliminate any symbols from SDWebImage exported to user.

This may help, in the future, to totally remove the dependency to SDWebImage Core.

Reason

SDWebImage itself seems has many histroical code which may not suitable in the future of iOS develoipment and new SwiftUI developer learning. We want to make it alive, one way it's to totally rewrite it using Swift.

This need some huge task, not just translate Objc to Swift line by line. Because many design and API should be updated to use Swifty Syntax.

Make the SDWebImageSwiftUI hide the symbols, can make it more easy during the transition.

Suggest Naming

  • SwiftUIWebImage <-- May be OK
  • WebImageSwiftUI <-- Suffix one
  • SwiftUIImage <-- Not about Web, may not suitable
  • Any team name. "SD" reference to Simple Design company in SDWebImage's history. We can also find one. Like AFNetworking -> Alamofire
@dreampiggy dreampiggy added animated image AnimatedImage struct API API changes and removed animated image AnimatedImage struct labels Mar 29, 2020
@TysonParks
Copy link

This sounds great and would likely be incredibly useful.

I have already been struggling to figure out how to access useful attributes locked into the SDWebImage dependency in a way that complements my usage of SDWebImageSwiftUI within SwiftUI and it gets a bit messy. Especially getting direct access to things like frame count, durations, and individual frames from an initialized SDWebImageSwiftUI AnimatedImage View would be helpful to me. Of course SDWebImage is dense with so many features that would be useful to access in a Swifty/SwiftUI way.

I'm not sure what your approach will be to this but I just started learning Combine and it seems very well suited to rewriting an async/timing framework such as this. Combine + SwiftUI is a powerful combination and it's nice to have a high saturation of declarative language usage.

@dreampiggy
Copy link
Collaborator Author

dreampiggy commented Apr 12, 2020

@TysonParks @perteraul Hi.

I've write a proposal for SDWebImage the upstream framework as well. The SDWebImage 6.0 will have a true pure Swift overlay framework. Which means it use all of the Swift Syntax (not just the Objective-C exported symbols), works just as the Dispatch Framework and its C implementation.

See: SDWebImage/SDWebImage#2980

Which means, if upstream framework does not have any SD prefix, the SDWebImageSwiftUI don't need either. For example, like the code:

import SwiftWebImage // The SDWebImage 6.0 wrapper framework, you can still use SDWebImage if you use Objective-C/Swift mixed project
import SwiftUIWebImage // The SDWebImageSwiftUI 2.0 renaming framework

ImageCache.config.maxMemoryCost = 512 * 1024 * 1024
ImageDownloader.config.downloadTimeout = 30

// See the Swifty syntax, including enum associated object, default params, custom operator << (which create a pipeline transformer)
AnimatedImage(url: url, options: [.queryCacheType: .disk, .transformer: .roundCorner(5) << .blur(0.5)])
.transition(.activity) // See this naming
.onSuccess { result
    let image = result.image
    let data = result.data
    let cacheType = result.cacheType
    let object = result.extendedObject // extended object, Any conforms Codable
    let metrics = result.response?.metrics // URL metrics, such as DNS lookup time
}

old one:

import SDWebImage
import SDWebImageSwiftUI

SDImageCache.config.maxMemoryCost = 512 * 1024 * 1024
SDWebImageDownloader.config.downloadTimeout = 30

AnimatedImage(url: url, options: [.queryCacheType: SDImageCacheType.disk.rawValue, .transformer: SDImagePipelineTransformer(transformers: SDImageRoundCornerTransformer(cornerRadius: 5, corners: .all, borderWidth: 0, borderColor: nil), SDImageBlurTransformer(radius: 0.5)])
.transition(SDWebImageIndicator.activity) // See this naming
.onSuccess { image, cacheType
    let data = nil // currently we don't provide one...Need complicated code
    let object = image.sd_extendedObject // 5.0's extended object, NSObject<NSCoding>
}
.onReceive(NotificationCenter.default
    .publisher(for: Notification.Name.SDWebImageDownloadFinish, object: nil)
    .compactMap({ ($0.object as! SDWebImageDownloaderOperation).metrics })) {
    // some complicated code to get. Because the metrcis is under `SDWebImageDownloadToken`, you need to grab that token
    // token is passed via NotificationCenter or using the `sd_latestOperation` method on the UIView, however, you don't touch UIView
    if metrics.url == url {
        // Get the metrics, like DNS lookup time
    }
}

You can leave feedback on that proposal GitHub issue comment as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API API changes
Projects
None yet
Development

No branches or pull requests

2 participants