Photomania- Stanford Paul Hegarty's class - iphone

is there something wrong with core data for xcode 4.3.2
I'm following the Stanford Paul Hegarty class for ios 5.0
doing the core data walkthrough (Video 14 Core data demo)
I downloaded the file here
I ran it in xcode 4.3.2 but the core data doesn't seem to work because the entries in the tableview do not appear.
I tried to run it in another computer with xcode 4.2 and ios 5.0
it's working perfectly
anybody who encountered the same problem? I'm pretty sure that xcode is at fault.

Interesting. I am having the same problems and I am also using XCode 4.3, but just thought it was because of the Flickr license that you need and which I don't have. (In FlickAPIKey.h, there is a #define FlickrAPIKey #"" and you won't download anything if you don't have that key.)
Update: I got myself a Flickr API key (you can just get one from their website) and tried the Photomania App on XCode 4.3: it works like a charm, so it looks like XCode is not your problem here. (Although on occasion I found that I had to stop and restart XCode to get rid of a strange bug or compiler error.) Anyway, maybe it is an idea to delete the data first before you try again: Just delete the App before you run it and the database file will get deleted as well.

Paul Hegarty after his class, has published an update version of his code which have a call to SAVE the CoreData database! This may be the reason why your CoreData informations doesn't persist.
His update note was:
// should probably saveToURL:forSaveOperation:(UIDocumentSaveForOverwriting)completionHandler: here!
// we could decide to rely on UIManagedDocument's autosaving, but explicit saving would be better
// because if we quit the app before autosave happens, then it'll come up blank next time we run
// this is what it would look like (ADDED AFTER LECTURE) ...
[document saveToURL:document.fileURL forSaveOperation:UIDocumentSaveForOverwriting completionHandler:NULL];
So, you have to Add the 'document saveToURL' line in the 'fetchFlickrDataInDocument' function like this:
- (void)fetchFlickrDataIntoDocument:(UIManagedDocument *)document
{
dispatch_queue_t fetchQ = dispatch_queue_create("Flickr fetcher", NULL);
dispatch_async(fetchQ, ^{
NSArray *photos = [FlickrFetcher recentGeoreferencedPhotos];
[document.managedObjectContext performBlock:^{
// perform in the NSMOC's safe thread (main thread)
for (NSDictionary *flickrInfo in photos) {
[Photo photoWithFlickrInfo:flickrInfo inManagedObjectContext:document.managedObjectContext];
// table will automatically update due to NSFetchedResultsController's observing of the NSMOC
}
// should probably saveToURL:forSaveOperation:(UIDocumentSaveForOverwriting)completionHandler: here!
// we could decide to rely on UIManagedDocument's autosaving, but explicit saving would be better
// because if we quit the app before autosave happens, then it'll come up blank next time we run
// this is what it would look like (ADDED AFTER LECTURE) ...
[document saveToURL:document.fileURL forSaveOperation:UIDocumentSaveForOverwriting completionHandler:NULL];
// note that we don't do anything in the completion handler this time
}];
});
}

If someone is still facing the same issue using Objective-C, there is one more thing you need to do after getting API key: change all http:// to https:// within files in FlickrFetcher folder. This worked for me.

Related

fetchRemindersMatchingPredicate not retrieving new data

I've been using EventKit for years in my app (since macOS 10.10) but it's having an odd problem in Mojave.
Previously once I received an EKEventStoreChangedNotification I could query for changed reminders with this:
NSPredicate *predicate = [self.eventStore predicateForRemindersInCalendars:#[self.taskCalendar]];
[self.eventStore fetchRemindersMatchingPredicate:predicate completion:^(NSArray *reminders) {
self.allFetchedTasks = reminders;
}];
Worked like champ. Setting a breakpoint within that block, I could switch to Reminders, change the task title, instantly pop back in the debugger and the reminders array would have the change (via "po [reminders.firstObject title]").
However, now in Mojave the fetch appears to return old information. I get thrown back in the debugger as soon as I change the task title in Reminders but the reminders array still contains the old info. That is, [reminders.firstObject title] is still showing the original title not the title as it exists currently in Reminders. I can continue to change the title in Reminders and each time I'm brought back into the debugger and I still see the original title.
I also attempted to use calendarItemsWithExternalIdentifier but it also returns the original value.
If I relaunch my app then it grabs the latest info but, again, subsequent fetches due to change notifications return the original value.
It doesn't look like Mojave's EventKit has any new caching I can control. Is there something else I'm missing? Do I need to reconstruct my self.eventStore each time now?
This has been fixed in Apple's macOS 10.14.4 Beta 3 release.

XPC connection interrupted in Xcode 7 for iOS 9

I recently updated to Xcode 7 and upgraded my iPhone to iOS 9. I have developed and released an iOS app that had worked perfectly fine on the latest version of iOS 8 and Xcode 6.
Upon trying to go through the process of updated the app for iOS 9 support, I am getting the most ridiculously strange error that has left me baffled.
I have done all the syntax corrections automatically through Xcode, and now my app builds properly. It even runs fine at first.
I have a button that segues to a view controller with a WebView. This view controller loads a link that will display either an image, website, or video from youtube. The content is loaded perfectly fine as always. However, the program will crash and reboot the simulator (and my iPhone) and send me to the lock screen when I click the Back button (I am on a navigation stack).
In Xcode, I get the following messages:
XPC Connection Interrupted.
Terminating since there is no system app.
I have Flurry analytics integrated in my app by the way, not sure if thats an issue.
How can I fix this issue? My searches for XPC connections do not seem to return problems similar to mine. I do not even have a clue what an XPC connection is, so why is this in my app anyway?
EDIT: I have found a workaround for the issue. I cannot really say it is a fix.
The crashing was occurring during the use of the method self.navigationController?.popViewControllerAnimated, when set to true. I happened to set this to false, and the crashing stops (now the transition looks awful).
I do not know why this works, and just adds to my confusion.
The problem lied in the storyboard for me as well. I created a new project and laid out the views and everything seemed to be working fine. I found these couple lines in the storyboard source (right click on storyboard and select view as -> source code) which weren't common between the working version and the broken version:
<keyCommands>
<keyCommand/>
</keyCommands>
I have no idea what those lines are supposed to do, or how they crept into my storyboard file, but they were what was crashing the app so hard that the phone had to restart. I removed those lines from my main project and everything worked again.
This error can be caused by executing a loop repeatedly. In my case it was a 'for' loop in which I reset the counting variable. As soon as I added an NSLog in the loop it was obvious.
I just faced the same problem. I don't know if that will help you, but I also think it's coming from the Storyboard:
In my case, the problem is coming from a UITextView. Whenever I try to change the default text inside it, I have this error. If I let the default text or leave it empty, the app works fine. Making an IBOutlet and changing the text programmatically works as well.
I tried with other UI elements, but only the UITextView seems to have this issue.
I have struggled with exact same error. Through a process of elimination I established that it had nothing to do with the any class but had to do with the storyboard. Luckily I keep regular backup copies and I tried to compare storyboards to establish what I had done - but could find nothing obvious.
The backup copy worked fine and I was able to copy my controller classes (from the faulty copy with the changes) into the backup copy and they worked fine.
I think there is a bug possibly in storyboards.
I have same error message when I place a subview in -layoutSubviews method:
-(void)layoutSubviews
{
[super layoutSubviews];
[self populateByImageViews];
}
It causes infinite cycle of layout process and crashes app. Don't place subviews in this place!
Deleting UITextView from the one of the view in Storybord removes the error in my case.
In valueChanged: method of a UIControl, I had the same problem
so I made the code inside valueChanged: to run in main thread and it solved the problem.
#IBAction func valueChanged(sender: AnyObject) {
dispatch_async(dispatch_get_main_queue(), {
//code
}
}
For me was some missing constraints with a UISearchBar, but the error was only in the simulator.
I only add some constraints and works better
For me it was xcode live issues caused by IB_DESIGNABLE
If you have any IB_DESIGNABLE in source files, the system's live tracker will check for issues in StoryBoard too. It may leads to unnecessary building.
To disable it-
Open Storyboard file. Editor -> Automatically Refresh Views (Uncheck)
If you needs to Disable Live issue tracking
XCode -> Preferences -> General -> Issues -> Uncheck Live Issues
Reference
My issue probably originated with some storyboard issue, but I cleaned the project, restarted Xcode AND restarted the simulator app and that fixed it.
When using QLPreviewController, I am confronted with this problem. Error messages as follows,
XPC connection interrupted
_BSMachError: (os/kern) invalid capability (20)
_BSMachError: (os/kern) invalid name (15)
Since XPC means OS X interprocess communication, so I think this can solve the problem, especial when updating the UI
dispatch_async(dispatch_get_main_queue(), ^{
// do what you want to do.
});
For Swift 4+, user
DispatchQueue.main.async {
//Your Code
}

What causes "NSScanner: nil string argument"?

I got this message when I save data to core data.
NSScanner: nil string argument
I didn't use any NSScanner method. Where did it come from?
This is a bug? What should I do with it?
Thanks help, please.
From experience, I can say that -[NSDecimalNumber initWithString:] or +[NSDecimalNumber decimalNumberWithString:] with a nil string is one thing that causes that log message.
Set a breakpoint on -[NSScanner initWithString:] to start with; if you don't catch it that way, then break on the other ways you might create a scanner, like +scannerWithString: and -[NSConcreteScanner initWithString:]. That's how I flushed my unwanted log statement out.
FWIW, I had this message come out whilst building a core data app.
It was due to me rebuilding and running the app in the simulator, which effectively kills off your running process without going through any of your exit methods.
Depending on when / where you are saving your managed object context, you could be left with an incomplete managed object somewhere, then scanners which would expect to find values would have nothing when the app was relaunched and the half baked objects were returned from the store.
I have the same crash log NSScanner: nil string argument.
This is my sitution
Everything works fine on device.
Crash at dequeueReusableCellWithIdentifier only on simulator
I solved it by
Product->Clean Then rebuild.Every thing works fine for me. I not sure why this happened.
I had met this problem on iOS 9 and iOS 10 BUT iOS 11 work fine,I solved it by removing observer in dealloc where I had used KVO.
Such as:
- (void)dealloc {
[self.collectionView removeObserver:self forKeyPath:#"contentSize"];
}
I got this crash error but not about nil string issue.
My reason is that I use a cell in storyboard as dynamic but set Static Cells in the Attributes inspector. I changed that attribute to Dynamic Prototypes, solved the problem.

undeclared object but everything implemented

i implemented first three20 (first, with the python scrip) and then restkit (second,manual).
i started adding some stuff to my app delegate, but then i get an error [RKObjectLoaderTTModel undeclared. Other Objects RKClient or RKObjectManager work fine.
// work
[RKClient clientWithBaseURL:APP_BASE_URL username:USER_EMAIL password:USER_PASSWORD];
RKObjectManager* objectManager = [RKObjectManager objectManagerWithBaseURL:APP_BASE_URL];
//fail
[RKObjectLoaderTTModel setDefaultRefreshRate:1];
looking into RestKit/Build/RestKit/Three20 i can see RKObjectLoaderTTModel header.
i added all header search paths, etc , pp.
i think you get a better view, when looking into my project, sohere is it (have nothing done yet, so no problem with sharing): http://dl.dropbox.com/u/80699/project_for_stack.zip
hopefully somebody can help.
#import <RestKit/Three20/Three20.h>
had to import explicit the restkit three20 stuff.
hope this helps somebody. now everything runs fine.

NSFetchedResultsController crashing on performFetch: when using a cache

I make use of NSFetchedResultsController to display a bunch of objects, which are sectioned using dates. On a fresh install, it all works perfectly and the objects are displayed in the table view. However, it seems that when the app is relaunched I get a crash. I specify a cache when initialising the NSFetchedResultsController, and when I don't it works perfectly.
Here is how I create my NSFetchedResultsController:
- (NSFetchedResultsController *)results {
// If we are not nil, stop here
if (results != nil)
return results;
// Create the fetch request, entity and sort descriptors
NSFetchRequest *fetch = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:#"Event" inManagedObjectContext:self.managedObjectContext];
NSSortDescriptor *descriptor = [[NSSortDescriptor alloc] initWithKey:#"utc_start" ascending:YES];
NSArray *descriptors = [[NSArray alloc] initWithObjects:descriptor, nil];
// Set properties on the fetch
[fetch setEntity:entity];
[fetch setSortDescriptors:descriptors];
// Create a fresh fetched results controller
NSFetchedResultsController *fetched = [[NSFetchedResultsController alloc] initWithFetchRequest:fetch managedObjectContext:self.managedObjectContext sectionNameKeyPath:#"day" cacheName:#"Events"];
fetched.delegate = self;
self.results = fetched;
// Release objects and return our controller
[fetched release];
[fetch release];
[descriptor release];
[descriptors release];
return results;
}
These are the messages I get when the app crashes:
FATAL ERROR: The persistent cache of section information does not match the current configuration. You have illegally mutated the NSFetchedResultsController's fetch request, its predicate, or its sort descriptor without either disabling caching or using +deleteCacheWithName:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'FATAL ERROR: The persistent cache of section information does not match the current configuration. You have illegally mutated the NSFetchedResultsController's fetch request, its predicate, or its sort descriptor without either disabling caching or using +deleteCacheWithName:'
I really have no clue as to why it's saying that, as I don't believe I'm doing anything special that would cause this. The only potential issue is the section header (day), which I construct like this when creating a new object:
// Set the new format
[formatter setDateFormat:#"dd MMMM"];
// Set the day of the event
[event setValue:[formatter stringFromDate:[event valueForKey:#"utc_start"]] forKey:#"day"];
Like I mentioned, all of this works fine if there is no cache involved. Any help appreciated!
I had a similar problem with one of my apps, when the Apple released the new iOS 4.0.
Search:
fetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:[self managedObjectContext] sectionNameKeyPath:nil cacheName:nil];
And set the value of the parameter cacheName to nil. It worked for me, hope it will for you. Let me know.
I started getting the same error when I upgraded by MacBook Pro to Snow Leopard 10.6.4 and the latest SDK.
As it turns out, many of us had been using code that wasn't in conformance with the rules, but we didn't know it because CoreData wasn't really behaving in accordance with its own rules.
Specifically, when you fetch things, they get cached, and in 4.0, that cache isn't automatically purged in cases where it was purged in the earlier SDK.
For me, the solution was simple. I just employed the class method that purges the caches. You can specify an individual entity, but I specify nil so it just does them all in this particular piece of start-up code:
[NSFetchedResultsController deleteCacheWithName:nil];
Suddenly, the little app I've worked on only to familiarize myself with CoreData is working again.
Straight from the documentation for NSFetchedResultsController:
Modifying the Fetch Request
You cannot simply change the fetch request
to modify the results. If you want to change the fetch request, you
must:
If you are using a cache, delete it (using deleteCacheWithName:).
Typically you should not use a cache if you are changing the fetch
request.
Change the fetch request.
Invoke performFetch:.
I encountered a similar problem.
When I inspected the Debugger Console, it showed what the cached objects and the fetched objects were so that I could figure out why they are inconsistent.
In my case it was due to a different predicate.
Since the values in my predicate are not dynamic, I could specify a different cache name for each predicate. That will create a cache for each 'type' I specify.
I suppose you will have to assess your need to have the cache. To specify nil, means that a fetch is made in every call.
I figured out that the error occurs only when the fetch request have some changes. If you are creating a new NSFetchRequest OR changing the predicate OR sort descriptor, then you should delete the cache or use a different cache. Otherwise, ensure that you have the same NSFetchRequest or make sure that your NSFetchedResultsController is retained and that should solve your problem.
If you're using the simulator, try resetting it--I'd guess you've changed your entity map and it's getting confused by a leftover cache. If not, you could try doing what the error says:
- (void)applicationWillTerminate:(UIApplication *)application {
[NSFetchedResultsController deleteCacheNamed:#"Events"];
//etc
}
The exception still occurs with Xcode 7 (beta 4):
You have illegally mutated the NSFetchedResultsController's fetch
request, its predicate, or its sort descriptor without either
disabling caching or using +deleteCacheWithName:
NOTE: This is with an unmodified Xcode "Template" Master-Detail iOS app with standard Xcode CoreData "boiler-plate" code created with Xcode 7 and using the latest (iOS 9) deployment target.
I noticed it first when I restarted my app in the simulator. I had been starting and stopping the app several times via Xcode and then it happened; and it kept happening. I decided to do some experiments, and the results:
Every time I stopped the app in the simulator, I would get the exception on a subsequent launch.
Every time I stopped the app using the simulator's Home button, I was able to launch it again successfully.
The issue can still be fixed as follows, using one or the other of the following methods:
In the AppDelegate's application didFinishLaunchingWithOptions method, add the following Swift NSFetchedResultsController.deleteCacheWithName(nil) or Objective-C [NSFetchedResultsController deleteCacheWithName:nil]; code. This clears out the corrupted cache.
In the Simulator, from the Simulator menu, select Reset Content and Settings. This fixes the problem, but you lose your test data.
I also believe that this is an artifact of running via Xcode and stopping the app prior to it being able to clean up. I've not seen this in the actual device.
Are you quitting the Simulator using the home button or by terminating the app in Xcode? Maybe the app isn't getting time to finish writing to the cache. Try using the home button to quit the app.
How many classes implement the same - (NSFetchedResultsController *)results method, do you use a different cache for each one? I was having the same issue and I think I fix it by using a different cache name fore some clases since I have different NSPredicates.
I was having the same problem. To fix, I put the [NSFetchedResultsController deleteCacheWithName:#"cacheName"]; before the init of resultsController. Works for me as he only goes there on the first time.
For those who run into the same problem nowadays, the problem is that somehow Core Data doesn't clean the cache so work fine at first time but doesn't after that. Then just put this line right after init the NSFetchRequest
[NSFetchedResultsController deleteCacheWithName:#"Name"];
I found via the Ray Wenderlich forums that
Note that it only crashes when the fetch request is not created yet when you add something new to the datastore, i.e. when the Locations view isn't loaded yet. If the view is loaded already, then it works fine. Odd, eh?
So, what happened in my case was this:
The normal launch process entails constructing an NSFetchedResultsController.
Because there are thousands of objects being fetched, a fresh fetch takes considerable time. To mitigate this, the fetch a) uses a cache, and b) happens in the background, allowing other activities to continue
Normally, though the UI is responsive and the user can do stuff, the fetch is complete long before the user might express a desire to create a new object.
However, sometimes the app will be launched in the background - say, from a WatchKit event, or a background fetch, etc) - and part of the launch will entail creating a new object in the datastore immediately.
If the new object was created before the fetch was complete, the app would crash.
The solution is to ensure that The fetch is complete before creating an object (which would affect the fetch).
Alternatively you could delete the cache, but that is less performant practically speaking.
Note that the admonition from the debugger that
You have illegally mutated the NSFetchedResultsController's fetch request, its predicate, or its sort descriptor without either disabling caching or using +deleteCacheWithName:
simply does not capture this situation whatsoever, in that what you have changed was not the request, predicate, or sort descriptor, but rather more accurately could be described as having mutated the result set while the fetch was in progress.
It took me forever to track down this tiny piece of trivia. I hope you benefit.
NSFetchedResultsController *fetched = [[NSFetchedResultsController alloc] initWithFetchRequest:fetch managedObjectContext:self.managedObjectContext sectionNameKeyPath:#"day" cacheName:#"Events"];
replace #"Events" with nil.