twitter / ios-twitter-image-pipeline Goto Github PK

There seems to be an issue when using the unpublished 2.11 tag with CocoaPods:

pod 'TwitterImagePipeline', :git => 'https://github.com/twitter/ios-twitter-image-pipeline.git', :tag => '2.11.0'

Produces:

warning: duplicate output file '/Users/test/Library/Developer/Xcode/DerivedData/testapp-ewynxhezdlpikvcpvyepzrthcgds/Build/Products/Debug-iphonesimulator/TwitterImagePipeline/TwitterImagePipeline.framework/Info.plist' on task: ProcessInfoPlistFile /Users/test/Library/Developer/Xcode/DerivedData/testapp-ewynxhezdlpikvcpvyepzrthcgds/Build/Products/Debug-iphonesimulator/TwitterImagePipeline/TwitterImagePipeline.framework/Info.plist /Users/test/Documents/testapp_ios/Pods/Target Support Files/TwitterImagePipeline/Info.plist (in target 'TwitterImagePipeline')

info.plist is included in the compiled sources list for the TwitterImagePipeline. Was this intentional?

Likely due to a "fix" in Clang in the newest beta released today, building TIP in Xcode 11b1 results in the following build error:

Comparison of integers of different signs: 'TIPImageLoadSource' (aka 'enum TIPImageLoadSource') and 'const size_t' (aka 'const unsigned long')

I will admit I have only used TIP and not familiarized myself with the codebase, but a potential solution is changing TIPImageLoadSource to be an NSUInteger.

Hi. Thank you for sharing the library with us. :) Is there any chance we have a compatible Mac version?

Can you guys give some usage sample in Swift? Thanks.

Acctually the images from the rendered cached are similar to the ones from memory cached, So I want to know if this will cost lots of memory.

"Pipline" misspell in the readme title.

2.11 does not seem to be published to the CocoaPods master repo

Is it possible to change imageIdentifier later somehow?

Use case: the user uploads an image to the server. Before sending the image to the server, the app stores it into the cache. After the image is uploaded, it retrieves an url of the image and updates imageIdentifier.

Or may be there's a better way to handle such use case?

We will be dropping our paid Travis CI plan at the end of 2021. We do not expect there to be any visible changes to this repo, but wanted to give some notice just in case. We recommend migrating CI jobs to GitHub Actions.

Travis CI provides free testing for open source projects. In addition, Twitter has paid for a small number of additional concurrent builds which were available for open source as well as private repositories. Many Twitter projects have already moved to GitHub Actions for CI, and we have no private repos left using Travis, so we will be discontinuing our plan at the end of 2021.

Since this repo is open source, we do not expect this change to impact Travis CI builds for this project. However, we still recommend most Twitter projects to migrate to GitHub Actions for CI at your convenience.

In our project there are not many different sizes of images，just one kind of size，weather the image pipeline is still suitable for our project ?

Describe the bug
Even though there exists code in TIP to decode the image on the background thread, apple is still decoding the image again on the main thread. Seems some recent change caused the decoding in TIP to not function.

To Reproduce
Load remote images under profiler and do a filter for jpeg.

Expected behavior
Images are decompressed only on background thread.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment
iOS 14 (coworker claims it happens on iOS 13 as well)

Additional context
So there are 2 weird things:

1. As a part of decoding the image that is returned from the background render is never used, only the original UIImage instance is used. Also this does result in 2 different UIImage instances. Seems the original maintains unmodified, it's possible this was a more recent iOS change.
2. The image is rendered to 1x1. I assume this was a memory optimization, but it means the rendered image can't just be swapped in place of the original one.

I'll create a PR soon, need to get more familiar with the code and what is best practice for decoding images off the main thread. Wanted to create the issue now to increase awareness for those that are more familiar with this code.

I'm a little lost regarding the intended use of @property (nullable, nonatomic, copy, readonly) TIPImageFetchHydrationBlock imageRequestHydrationBlock; on a TIPImageFetchRequest to modify an NSURLRequest. I would expect this block to have a return type of NSURLRequest, to allow us to process the request that is passed into the block and return the modified output. For example, I am currently trying to insert an authentication entry into the header for OAuth2.

Any tips?

ld: '/Users/cc/Library/.../TwitterImagePipeline.framework/TwitterImagePipeline' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. file '/Users/cc/Library/.../TwitterImagePipeline.framework/TwitterImagePipeline' for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This framework was built by carthage and embedded manually.

Xcode 9.1 beta 2.
iOS 11.1 beta 5.
macOS High Sierra 10.13.1 beta

I am wondering if there is a built in, but undocumented, means of setting a maximum file size beyond which images will not be downloaded and/or cached. Is this possible?

iOS 15's new first party image decoding APIs appear to be faster and more memory efficient that the classic "draw image in context" method of image decoding. Would be nice to leverage this in TIP.

https://twitter.com/timonus/status/1450866353137618949

I plan to put up a PR for this at some point, haven't had time yet. I chatted with @NSProgrammer about this earlier today and he recommended opening a task tracking it!

What kind of crash would be triggered when concurrently access to CGContext

Hi guys! You published this library very conveniently since we just yesterday started seeing problems with our image caching over at Forza Football. Reading your description, they are similar to yours, and everything this library does seems to fit us very well, so we are evaluating it right now.

However, there is one problem that pretty much every image caching library on iOS suffers from - how to handle updated/outdated images. I would like to ask you if it's possible (or how you would solve) an updated image residing on the same URL as before.

For example, if our servers set a max-age of 3 days - will the library discard the image after 3 days and request a whole new one, even if it's the same image? We sometimes need to update an image on the same URL, so we can't set a too high max age. But we still would like the HTTP-caching functionalities. Ideally, after 3 days, the library would request the image, and if it gets a 304, it just keeps the same image in the cache and refreshes the TTL.

Looking at the process you describe in your README, it seems to me that the library will never attempt to refresh an image if it's already in the cache. Is this true?

in general, images decode in Background use CGContextDrawImage or CGDataProviderCopyData method. I read the source code , and find webp use CGDataProviderCopyData, but I don't know other format images how to decodes in Background

Thanks for sharing TIP!
Looks very very impressive!

Currently, I use PINRemoteImage in my app (and enjoy it very much!). If I may, I wanted to ask the following:

1. What were the reasons you felt that PINRemoteImage would not be good for the Twitter iOS app?
2. What are the key differences to consider when choosing between both?

Thanks again for sharing this library!

Can you point me in the right direction regarding how to control the animations on a TIPImageView that encapsulates an animated GIF? UIImageView property isAnimating, and methods startAnimating, stopAnimating don't seem to function out of the box. Ideally, I need to be able to pause / resume the animation.

Thanks for sharing the awesome library!

https://github.com/webmproject/libwebp/releases/tag/v0.6.0

Hey! Hope you don't mind me bugging you about WebP related stuff even more? 😬

I was looking at using TIPDetectImageTypeFromFile for convenience in my project (usage not directly related to the rest of TIP) and I noticed that prior to iOS 14, these methods aren't able to detect when a file or data is WebP.

It's because these methods first attempt to use CGImageSourceRef to detect the type before falling back to magic number checks of the data however CoreGraphics in the iOS 13SDK doesn't recognise WebP as it wasn't added until the iOS 14 SDK (I've verified that it works when building with the 14SDK) and the TIPDetectImageTypeViaMagicNumbers magic number fallback only detects BPM, JPEG, GIF and PNG.

Do you think it's worth updating this check to look for the WebP header/signature/magic numbers?

I can relatively easily wrap and extend in my own code but I wasn't sure if other parts of the TIP project were expecting these methods to detect WebP or not?

It's a little trickier to add support since the header also includes the file size (https://developers.google.com/speed/webp/docs/riff_container) so I'm not sure of the best way to adjust the existing code to support this but am happy to help and dig into it a little more if you think it's worth it?

Let me know your thoughts, thanks!

While debugging an issue with an particular image not storing in the pipeline (generally no entry in all cache levels) I stumbled over a possible bug in the code.

In the TIPImageStoreOperation main method the cache entries for the different caches are created by deciding which source of data should be held by the entry.
In the method the memoryEntry is created and it holds the imageContainer, if it exists, in the completeImage property. After that, when the diskEntry is created and the imageFilePath as well as the imageData does not exist, the imageContainer should be stored in the diskEntry. Currently the imageContainer will then be stored in the memoryEntry.

// Create Disk Entry
    TIPImageCacheEntry *diskEntry = nil;
    if (_pipeline.diskCache) {
        diskEntry = [[TIPImageCacheEntry alloc] init];
        if (imageFilePath && ([[NSFileManager defaultManager] fileExistsAtPath:imageFilePath] || (!imageData && !imageContainer))) {
            diskEntry.completeImageFilePath = imageFilePath;
        } else if (imageData) {
            diskEntry.completeImageData = imageData;
        } else {
            TIPAssert(imageContainer);
            memoryEntry.completeImage = imageContainer;
            TIPAssert(memoryEntry.completeImage);
        }
    }

I don't know if I'm overlooking something which is definitely possible but it looks like a copy and paste error?

Either way I think it doesn't solve my issue but it's worth looking into 😄

Hi all, I've successfully integrated the current pod into a tvOS project by manually overriding the supported platforms in my local master repo. Is there any reason the podspec couldn't be updated to include s.tvos.deployment_target = '9.0'?

In our project, we don't want a disk cache so we set [TIPGlobalConfiguration sharedInstance].maxBytesForAllDiskCaches = 0. However, that doesn't seem to be working. I DM'd with @NSProgrammer and he confirmed there are some places where 0 == off and others where 0 == unlimited (ex:

We just submitted our app to the App Store, but they rejected our package due to they think we used Apple private APIs:
ITMS-90338: Non-public API usage - imageDimensions, imageFilePath.
Maybe the names match the private Apple APIs listed above.
I have send email to Apple, that they flagged in error, and they approved our app later.
But i think maybe alter the names will help prevent app being flagged in future?

👋

It looks like #62 introduced version 2.25.0 (the PR is titled incorrectly as 2.50.0) but this was never pushed to CocoaPods. Please could you tag master and push the release to CocoaPods 🙏

Let me know if you need help fixing anything with the cocoapods release project. I can try to help.