Performing cleanup (specifically, calling -cleanupFiles) in +load can delay on-device app launch time noticeably. Let’s try moving this work to +initialize instead.
* Add support for in-url base64 encoded images
* Added GIF support
* Solution simplified a lot after reading PR comments
* Fix some problems
* Add test and fix compilation error
* Commented memory caching of data urls for now
* Fix issues appeared after rebase
* Fixed bug under OSX
* Used memory cache for data scheme and simplified solution a lot
* Don't bother archiving / unarchiving data.
This change upgrades to PINCache 3.0.1-beta which supports
custom archiving and unarchiving.
This allows us to avoid using NSArchiver/Archiver which adds a
small amount of disk space overhead and between .5 and 10 ms (on an iPhone 4)
for each encode / decode.
To support this, we *do* have to add versioning for the cache and
destroy it for the old versions. I considered adding a process to migrate
the images, but because that would have to occur on startup and process
all existing images, it could cause issues for very large image cache
databases, so I decided against that.
* Fix warnings
* Fix invalid object test
* Cleanup, thanks @chrisdanford!
* Add support for retrying and reduce default timeout.
* Return HTTP error codes >= 400. Don't retry when failure is sure to occur again.
* Add missing nullability
* Use NSInteger
* Add support for varying pixel lengths.
On some devices the pixel length returned from CGImageCreate
sadly isn't 4 bytes per pixel.
Might be a good idea to support differing lengths.
Encoding this into the format would be a good
thing for sure.
Anyway, that's what this does.
* Add in methods for reading out bitsPerPixel too.
In order to avoid blocking on the main thread, PINRemoteImage creates
a UUID but does not immediately start a task instead putting it on an
operation queue. This means that a client can request cancelation for
a UUID before its task is created.
Previously, we attempted to handle this by maintaining a set of canceled
UUIDs. This was being done incorrectly however. The logic was to check if,
before creating a task, a UUID was in canceledTasks. If it was, don't
create the task. If it wasn't clear out the canceledTasks list. This
example illustrates why that was erroneous:
1. Request starting a task with UUID #1
2. Request starting a task with UUID #2
3. Request canceling UUID #2
4. Task creation starts for UUID #1
5. UUID one is not in canceledTasks so it is cleared
6. Task creation starts for UUID #2, it is not in canceledTasks
so the task is created and is not canceled.
This patch changes canceledTasks to a weak hash table and removes
the line which cleared out canceledTasks. As long as there are blocks
(for task creation) referencing the UUID, they will not be removed
from canceledTasks. When no one is referencing the UUIDs any longer,
they will be cleared out.
* Fix runaway NSData
Previously we were generating all the frames of the GIF and dispatching
to write the data to the disk. This presents a problem if the disk backs
up though and it can end up with theoretically every frame in memory. Instead,
generate a frame and write it one frame at a time. Slower, but prevents
this runaway memory situation.
* Early return on error, thans @rahul-malik & @timonus!
* Have PINProgressiveImage pass back the quality of the current progressive image
* fix
* Check for nil for imageProgress pointer
* Rename some variables
* Rename a bunch of things
* Update comment
* Modify estimatedRemainingTimeThreshhold behavior to match documentation
* Update documentation on maxProgressiveRenderSize property
* Update the behavior, not the docs
First, prevents a memory leak if users reference self in their PINAnimatedImage completions.
Second, this deletes decoded files when there are no more references to an animated image.
Previously we deleted on app open and exit.
I wasn't going to do this in case you closed a GIF and then reopened, but the more I
thought about it the cost is too high: A user can see their disk size balloon if they view
a bunch of GIFs and then check usage. They could also fill up their space enough while using
the app by viewing GIF after GIF that instability could result.
