[Question] MemoryWarning in 2.0 about tmcache HOT 11 CLOSED

There are many occurrences that can cause TMMemoryCache to release memory, such as setting a costLimit or calling any of the following methods (or their asynchronous counterparts). But yes, UIApplicationDidReceiveMemoryWarning will no longer have any effect on TMMemoryCache by default. If you want this behavior in 2.0, you will need to add it yourself using the lines of code you pasted above.

/**
 Removes the object for the specified key. This method blocks the calling thread until the object
 has been removed.

 @param key The key associated with the object to be removed.
 */
- (void)removeObjectForKey:(NSString *)key;

/**
 Removes all objects from the cache that have not been used since the specified date.
 This method blocks the calling thread until the cache has been trimmed.

 @param date Objects that haven't been accessed since this date are removed from the cache.
 */
- (void)trimToDate:(NSDate *)date;

/**
 Removes objects from the cache, costliest objects first, until the <totalCost> is below the specified
 value. This method blocks the calling thread until the cache has been trimmed.

 @param cost The total accumulation allowed to remain after the cache has been trimmed.
 */
- (void)trimToCost:(NSUInteger)cost;

/**
 Removes objects from the cache, ordered by date (least recently used first), until the <totalCost> is below
 the specified value. This method blocks the calling thread until the cache has been trimmed.
 @param cost The total accumulation allowed to remain after the cache has been trimmed.
 */
- (void)trimToCostByDate:(NSUInteger)cost;

/**
 Removes all objects from the cache. This method blocks the calling thread until the cache has been cleared.
 */
- (void)removeAllObjects;

from tmcache.

Thanks for quick reply. I think handle memory warnings is the default behaviour for Cache which is 1.0 before. The 2.0 strategy is a bit unusual. I think it would be better if it is noticed in README.md, not only in release change log.

from tmcache.

The reason it no longer does this is because TMCache can be used in extensions which cannot refer to the shared application.

I will update the README tomorrow.

from tmcache.

@irace you can still listen for the notification without referencing the shared application?

from tmcache.

Yeah, that's true actually. Not sure why I didn't think of that.

I can put out a new version that adds this back tomorrow. Unfortunately, I guess by semver rules this would mean bumping the library to 3.0 😞

from tmcache.

Nah it's a feature, so 2.1 should be sufficient

-Samuel E. Giddins

On May 7, 2015, at 8:53 PM, Bryan Irace [email protected] wrote:

Reopened #85.

—
Reply to this email directly or view it on GitHub.

from tmcache.

Breaks API compatibility though?

from tmcache.

How?

-Samuel E. Giddins
segiddins.me

On May 7, 2015, at 9:11 PM, Bryan Irace [email protected] wrote:

Breaks API compatibility though?

—
Reply to this email directly or view it on GitHub.

from tmcache.

I would remove the two new public methods I added in 2.0 for telling the cache that the app was backgrounds or that a memory warning occurred.

from tmcache.

No need to remove them, you can just deprecate them.

-Samuel E. Giddins

On May 7, 2015, at 9:24 PM, Bryan Irace [email protected] wrote:

I would remove the two new public methods I added in 2.0 for telling the cache that the app was backgrounds or that a memory warning occurred.

—
Reply to this email directly or view it on GitHub.

from tmcache.

Fixed in version 2.1.0

from tmcache.