NSURLCache cachedresponseforrequest aucune donnée

Question

pourquoi le responseCache est nul? J'exécuterais ce post et obtiendrais vraiment le responseObject du cache. Comment puis-je obtenir le responseCache?

manager.requestSerializer = [AFJSONRequestSerializer serializer]; 
manager.responseSerializer = [AFJSONResponseSerializer serializer]; 

manager.requestSerializer.cachePolicy=NSURLRequestReturnCacheDataElseLoad; 

[manager POST:URL parameters:paramdic progress:^(NSProgress * _Nonnull uploadProgress) { 
} success:^(NSURLSessionDataTask * _Nonnull task, id _Nullable responseObject) { 

    NSData * data=[NSJSONSerialization dataWithJSONObject:responseObject options:NSJSONWritingPrettyPrinted error:nil]; 

    NSURLCache * cache=[NSURLCache sharedURLCache]; 

    NSCachedURLResponse * responseCache=[cache cachedResponseForRequest:task.originalRequest]; 

    NSCachedURLResponse * response=[[NSCachedURLResponse alloc]initWithResponse:task.response data:data userInfo:nil storagePolicy:NSURLCacheStorageAllowed]; 


    [cache storeCachedResponse:response forRequest:task.originalRequest]; 




} failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) { 
    NSLog(@"%@",error); 
}]; 

Answer 1

Il y a trois raisons pour lesquelles il est nil à ce moment:

• requêtes POST ne sont pas mises en cache par un iOS/OS code réseau X parce qu'ils ne sont pas garantis à idempotent (ils peuvent avoir effets secondaires, tels que le stockage des données sur le serveur). La seule façon dont une requête POST sera stockée dans un NSURLCache est si vous l'ajoutez explicitement.
• Les requêtes POST ne sont pas mises en cache car NSURLCache utilise l'URL comme clé de référence. Étant donné que l'URL n'inclut pas (ne peut pas) inclure le corps POST, toutes les opérations POST vers la même URL seront renvoyées pour une requête POST différente, ce qui n'est certainement pas ce que vous souhaiteriez. Donc, si vous l'ajoutez, vous devrez ajouter une réécriture personnalisée de l'URL sur son chemin dans le cache et le code de recherche personnalisée pour rendre les URL assez uniques en fonction de champs de corps POST spécifiques ou autres.
• Le cache étant hautement asynchrone, les données mises en cache ne sont pas nécessairement disponibles lorsque le gestionnaire d'achèvement de la requête est exécuté même s'il s'agit d'une requête GET.

Ceci n'est pas nécessairement un ensemble complet de raisons. :-)

Le cache est destiné à réduire le trafic réseau. Vous ne devriez généralement pas le consulter vous-même. Le chemin de recherche normal utilisé par NSURLSession et autres effectue des vérifications pour certaines politiques de mise en cache de protocole (par exemple expiration de réponse) qui ne seraient pas effectuées en demandant simplement au cache s'il a une réponse pour une clé particulière.

Si vous avez besoin d'un mécanisme général pour stocker une réponse unique pour une utilisation ultérieure par votre application (plutôt que de la garder en mémoire), vous devriez le faire dans votre propre dictionnaire interne (ou, si la réponse est grande une tâche de téléchargement et en déplaçant le fichier dans un dossier temporaire dans le sandbox de votre application que vous purgez à chaque lancement).