Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I finally found the answer for this.</p> <p>The error in the above code (which by the way is the near-exact sample from the <a href="http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/URLLoadingSystem/Tasks/UsingNSURLConnection.html" rel="noreferrer">SDK docs</a>) is not in the memory management code. Autorelease is one option, manual release is another. Regardless of how you handle your NSURLConnection object, you get leaks using NSURLConnection.</p> <p>First up, here is the solution. Just copy these 3 lines of code directly into connectionDidFinishLoading, didFailWithError and anywhere else you release the NSURLConnection object.</p> <pre><code>NSURLCache *sharedCache = [[NSURLCache alloc] initWithMemoryCapacity:0 diskCapacity:0 diskPath:nil]; [NSURLCache setSharedURLCache:sharedCache]; [sharedCache release]; </code></pre> <p>Credit to <em>mpramodjain</em> on <a href="http://forums.macrumors.com/showthread.php?t=573253" rel="noreferrer">http://forums.macrumors.com/showthread.php?t=573253</a> for the code.</p> <p>The problem seems to be this – the SDK caches the requests and replies on the iPhone. Even it seems if your NSMutableURLRequest cachePolicy is set to not load the reply from the cache.</p> <p>The silly thing is that it seems to cache a lot of data by default. I'm transmitting a lot of data (split into multiple connections) and started to get memory warnings, and finally my App died.</p> <p>The docs we need are in NSURLCache (not NSURLConnection), they state:</p> <blockquote> <p>NSURLCache implements the caching of responses to URL load requests by mapping NSURLRequest objects to NSCachedURLResponse objects. It is a composite of an in-memory and an on-disk cache.</p> <p>Methods are provided to manipulate the sizes of each of these caches as well as to control the path on disk to use for persistent storage of cache data.</p> </blockquote> <p>Those three lines have the effect of nuking the cache totally. After adding them to my App (<a href="http://gpslogapp.com" rel="noreferrer">GPS Log</a>), my #living object count remains steady.</p>
    singulars
    1. This table or related slice is empty.
    1. PONSURLConnection leak?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USWilliam Denniss
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COfor the record, I switched to the autorelease'd [NSURLConnection connectionWithRequest:request delegate:self] but I don't think it should matter.
      singulars
      1. PO
      1. USWilliam Denniss
    2. COIf your app makes any other NSURLRequests that _should_ use caching, this solution will disable them. A better solution in that case might be to implement the cached response delegate (which has the same effect): `-(NSCachedURLResponse *)connection:(NSURLConnection *)connection willCacheResponse:(NSCachedURLResponse *)cachedResponse { return nil; }`
      singulars
      1. PO
      1. USRob Rix
    3. COA little further on what’s actually happening: NSURLCache is caching the response to the request, but it’s using the request as the key. Thus, it will hold onto the request as long as the responses are being cached. A 0-byte cache defeats this, at the expense of making all requests made by the app uncached; implementing the delegate method is a more tailored approach. Setting the request’s cache policy to ignore the cache does not suffice.
      singulars
      1. PO
      1. USRob Rix
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload