quellish

Los Angeles, CA

58s
answered Is it possible for Xcode 6 to display errors for iOS 7 compatibility?
12h
comment Objective C - Error loading bundle
That path is a resource inside the bundle, not the bundle itself. Use the bundle methods to get paths to the resources in the bundle.
12h
comment How to unit test NSCoding?
attributeKeys is part of NSClassDescription, which does not exist on iOS.
13h
comment Objective C - Error loading bundle
Again, you have no code to load. These are resource bundles. After you instantiate the NSBundle using bundleWithPath, just start using resources from the bundle.
13h
comment Background thread with Core Data and NSFetchedResultsController
Yes. An insert should be an insertRowsAtIndexPaths:withRowAnimation:, a move should be a moveRowAtIndexPath:toIndexPath:, an update should be a reloadRowsAtIndexPaths:withRowAnimation:, etc. Use the appropriate table view methods, do not try to outsmart it. The examples provided by some of the Core Data templates have bugs. Very bad bugs. Breaking the internal state of the table by returning 0 for the number of sections, etc.
13h
comment Objective C - Error loading bundle
"GooglePlus.bundle" is a resource bundle. It contains no executable. Calling -loadAndReturnError: is for loading executable binaries inside a bundle, not resources.
13h
comment Background thread with Core Data and NSFetchedResultsController
If you use notifications with nested contexts, you will have difficult to troubleshoot bugs. You are using two conflicting methods of communicating changes between contexts. Were you actually able to measure a performance issue using Instruments?
20h
comment Background thread with Core Data and NSFetchedResultsController
"You should insert at newIndexPath, and delete from indexPath. And likewise for moves" That will actually stimulate bugs. oleb.net/blog/2013/02/…
20h
comment Background thread with Core Data and NSFetchedResultsController
Your solution uses queue confinement, but does not uses nested contexts to communicate changes? Your NSManagedObjectContextDidSaveNotification is going to arrive on the background context's queue. Your merge will be happening on the wrong queue. For this (and many other!) reasons, when using queue confinement it's best to use nested contexts to communicate changes.
20h
comment Background thread with Core Data and NSFetchedResultsController
Uh, why do you want the NSFetchedResultsController to use the main thread? This would seem to be very much counter to your other stated goals.
1d
revised Objective C - Error loading bundle
added 242 characters in body
1d
answered Objective C - Error loading bundle
2d
comment NSFetchedResultsController update every minute with observable NSDate of today?
Fogmeiser is absolutely correct. Once a fetch is performed the fetched results controller observes the context for changes. There is no need to refetch or poll on some time interval. When something changes, the fetched results controller will tell you.
Nov
22
awarded Yearling
Nov
22
awarded Yearling
Nov
22
answered How to send an OPTIONS HTTP Method in iOS?
Nov
21
comment Background thread with Core Data and NSFetchedResultsController
Not related to your crash, but... "but I must be missing something else." Yes. You are using queue confinement. Do not use merge notifications with queue confinement to communicate changes between contexts, use context nesting instead. Merge notifications are appropriate for thread confinement, but for many reasons do not work correctly with queue confinement. Also see: quellish.tumblr.com/post/93190211147/… and quellish.tumblr.com/post/97430076027/…
Nov
21
comment Why does a line that used to compile now report an error (Property 'code' not found on object of type 'NSError *')?
Have you looked at your machine's copy of the header NSError.h?
Nov
21
answered Why is a HTTPS NSURLSession connection only challenged once per domain?
Nov
21
comment Make NSURLCredential forTrust permanent in the keychain
It sounds like what you really want here is to use a task delegate. The session, which can encompass many tasks (i.e. connections), is being authenticated. When you pass the credential to the session the session manages it in-memory, which is why you're only seeing it happen "for the first request". The session gets the credential the first time, and uses it for subsequent requests but does not persist it.
1 2 3 4 5