I used three20's photo gallery in my app and it worked really well and looked neat and pretty. And basically I don't need to worry about all the fetch-photos-from-the-server thing since three20 has fetched and managed and cached the data for me, all of which are done behind the scene.
That's when I started to notice this magic caching mechanism implemented in three20, called TTURLCache. In its header file I find the following interface methods:
/**
* Stores a data on disk.
*/
- (void)storeData:(NSData*)data forURL:(NSString*)URL; //method 1
- (void)storeData:(NSData*)data forKey:(NSString*)key;
/**
* Stores an image in the memory cache.
*/
- (void)storeImage:(UIImage*)image forURL:(NSString*)URL; //method 2
/**
* Stores an etag value in the etag cache.
*/
- (void)storeEtag:(NSString*)etag forKey:(NSString*)key; //method 3
My questions:
Method 1 and method 2 in the above code: are they only capable of storing data, or are they capable of both fetching and storing?
What is an etag in method 3?
Method 1 says it will store the data on disk, while method 2 says it will store the image in memory. If I use method 2 to store an image, will it get lost once I kill and restart my app?
Thanks a lot in advance.
Those are the storage methods. The retrieval methods are separate. (See below.)
Etags are a way to optimize network traffic. See Wikipedia for a good intro.
I think that Three20 both stores the image file on disk, and the decoded image itself in memory. Certainly, any in-memory caches would be cleared if the app re-started, but remember that under iOS 4, that probably happens less often that you think.
To get data out of the cache, try one of:
/**
* Gets the data for a URL from the cache if it exists and is newer than a minimum timestamp.
*
* #return nil if hthe URL is not cached or if the cache entry is older than the minimum.
*/
- (NSData*)dataForURL:(NSString*)URL expires:(NSTimeInterval)expirationAge
timestamp:(NSDate**)timestamp;
- (NSData*)dataForKey:(NSString*)key expires:(NSTimeInterval)expirationAge
timestamp:(NSDate**)timestamp;
/**
* Gets an image from the in-memory image cache.
*
* #return nil if the URL is not cached.
*/
- (id)imageForURL:(NSString*)URL;
- (id)imageForURL:(NSString*)URL fromDisk:(BOOL)fromDisk;
I would advise reading through the source, though. If memory serves, TTURLCache isn't all that big a class.
Related
Good afternoon good people,
I'm suddenly experiencing a problem with VS Code:
in a couple of Flutter apps Streamcontroller.sink.add();
suddenly require the argument "push" (before it didn't).
without adding the push argument obviously it return the error
2 required argument(s) expected, but 1 found.dart(not_enough_required_arguments)
Does anyone know what might have happened?
thank you in advance for your help
Francesco
edit: via f12 the definition actually shows the argument push
part of dart.core;
/**
* A generic destination for data.
*
* Multiple data values can be put into a sink, and when no more data is
* available, the sink should be closed.
*
* This is a generic interface that other data receivers can implement.
*/
abstract class Sink<T> {
/**
* Adds [data] to the sink.
*
* Must not be called after a call to [close].
*/
void add(T data, Future push);
/**
* Closes the sink.
*
* The [add] method must not be called after this method.
*
* Calling this method more than once is allowed, but does nothing.
*/
void close();
}
but as pskink reminded the documentation doesn't show this requirement;
I don't have idea how this can have changed,
at this point the question is:
how do I restore it to normality?
TL;DR
what appeared to be bad code,
was instead corrupted dart code;
I followed the instruction provide by Gunter
and everything went back to normal.
Thanks again Gunter
What is browser.ignoreSynchronization?
/**
* If true, Protractor will not attempt to synchronize with the page before
* performing actions. This can be harmful because Protractor will not wait
* until $timeouts and $http calls have been processed, which can cause
* tests to become flaky. This should be used only when necessary, such as
* when a page continuously polls an API using $timeout.
*
* #type {boolean}
*/
&
waitForAngularEnabled
Both looks same. Is there any specific thing that can achieve by one and not by other?
They are the exact same, if you look at the source code ignoreSynchronization actually calls waitForAngularEnabled. The only thing to note is, ignoreSynchronization is being deprecated and eventually will no longer be available. They are switching to waitForAngularEnabled as the main property.
As far as what they do, that has been answered here in good detail.
I'm writing an extension function in TYPO3 CMS 6.2 Extbase that must process every object in a large repository. My function works fine if I have about 10,000 objects, but runs out of memory if I have over about 20,000 objects. How can I handle the larger repository?
$importRecordsCount = $this->importRecordRepository->countAll();
for ($id = 1; $id <= $importRecordsCount; $id++) {
$importRecord = $this->importRecordRepository->findByUid($id);
/* Do things to other models based on properties of $importRecord */
}
The program exceeds memory near ..\GeneralUtility.php:4427 in TYPO3\CMS\Core\Utility\GeneralUtility::instantiateClass( ) after passing through the findByUid() line, above. It took 117 seconds to reach this error during my latest test. The error message is:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4194304 bytes) in ... \typo3\sysext\core\Classes\Utility\GeneralUtility.php on line 4448
If it matters, I do not use #lazy because of some of the processing I do later in the function.
According to official TYPO3 website, it is recommended 256M memory limit instead of 128M:
Source
So my first suggestion would be trying to do that first and it might solve your problem now. Also you should use importRecordRepository->findAll(); instead of fetching each record by iterating uid, since someone might have deleted some records.
In general, Extbase is not really suitable for processing such a large amount of data. An alternative would be to use the DataHandler if a correct history etc. is required. It also has quite some overhead compared to using the TYPO3 Database API (DatabaseConnection, $GLOBALS['TYPO3_DB']) which would be the best-performance approach. See my comments and tutorial in this answer.
If you decide to stay with the Extbase API, the only way that could work would be to persist every X item (try what works in your setup) to free some memory. From your code I cannot really see at which point your manipulation works, but take this as an example:
$importRecords = $this->importRecordRepository->findAll();
$i = 0;
foreach ($importRecords as $importRecord) {
/** #var \My\Package\Domain\Model\ImportRecord $importRecord */
// Manipulate record
$importRecord->setFoo('Test');
$this->importRecordRepository->update($importRecord);
if ($i % 100 === 0) {
// Persist after each 100 items
$this->persistenceManager->persistAll();
}
$i++;
}
// Persist the rest
$this->persistenceManager->persistAll();
There's also the clearState function of Extbase to free some memory:
$this->objectManager->get(\TYPO3\CMS\Extbase\Persistence\Generic\PersistenceManager::class)->clearState();
Question:
I'm trying to find a way to retrieve the dev object for an mdio_bus that has been added to the device tree. I'm sure I'm going to be rapidly applying my palm to my forehead when I get past this, but for the life of me, I can't find the answer anywhere. I've seen how to find objects on the bus itself using bus_find_device_by_name(), but I can't seem to find how to get the bus itself.
Background:
We are providing network access to our host using a Micrel KSZ8863 Ethernet switch attached to the MACB on an at919g20. Rather than using the fixed PHY option, I've spoofed MDIO address 0 to be a "fake" PHY representing the fixed MII link to the switch. I'm writing a driver for the switch to receive its interrupts and monitor the outward facing PHYs and control the link state of the "fake" PHY to the host. In order to configure the switch beyond basic MIIM configuration, you need to use SMI on the MDIO bus to access the full array of registers in the switch. Through further tweaking of the mii_read/write functions in the MACB, adding a header to the reg address, I believe I can use the MACB's MDIO/MII controller to do the right thing for SMI requests. Because the bus no longer gets addressed by PHY:REG, I need to be able to issue raw read/write commands straight to the bus from the switch driver. And that brings me back to my question: How do I request the dev object of the mdio_bus from the device tree by name?
Thanks,
Brian
After hunting around, fruitlessly, for a way to retrieve a device pointer to an mii_bus object, I ended up coming up with the following solution. I'm not sure its the best way to go about it, but it seems pretty clean. I basically ended up adding a helper function to mdio_bus.c that allows another driver to search for a bus by name using class_find_device(). I'm sure there is better way to do this, that doesn't involve adding onto the bus' driver, but it doesn't seem like the worst way either.
-Brian
Here are the functions I added to mdio_bus.c:
/**
* mdiobus_match_name - compares specified string to the device name
* #dev: device object to be examined
* #data: pointer to string to compare device name to
*
* Description: matching function used in call to class_find_device() to find
* a device with the specified name
*/
static int mdiobus_match_name( struct device * dev, void * data )
{
const char * name = data;
return sysfs_streq( name, dev_name( dev ) );
}
/**
* mdiobus_find_by_name - Convenience function for retrieving an mii_bus pointer
* by name
* #name: name of the bus being searched for
*/
struct mii_bus * mdiobus_find_by_name( char * name )
{
struct device * dev;
/* search devices registered for with the mdio_bus_class using the device
name as the matching criteria */
dev = class_find_device( &mdio_bus_class,
NULL,
(void *)name,
mdiobus_match_name );
/* return the mii_bus pointer or NULL if none was found */
return dev ? container_of( dev, struct mii_bus, dev ) : NULL;
}
EXPORT_SYMBOL( mdiobus_find_by_name );
has anyone figured out how to reload data in TTPhotoViewController?
I have done several attempts but never worked out a suitable solution.
Your help is much appreciated.
Vlad
TTPhotoViewController ultimately derives from TTModelViewController so you should be able to call the reload method. From TTModelViewController.h:
/**
* Reloads data from the model.
*/
- (void)reload;
/**
* Reloads data from the model if it has become out of date.
*/
- (void)reloadIfNeeded;
/**
* Refreshes the model state and loads new data if necessary.
*/
- (void)refresh;