Can anyone shed any light as to why the following code would crash in the release version of an Xcode 6 build but not in the debug version ?
Can I cast this as something to try and prevent this
// Check if iCloud is enabled
if let currentToken = NSFileManager.defaultManager().ubiquityIdentityToken {
// The following line causes a crash in Release version
FLOG(" currentUbiquityIdentityToken is \(currentToken)")
EDIT:
More digging and the problem was caused by this code when the "DataModel" name had been changed to something else. I would have expected the "let modelURL = NSBundle." line to have thrown an exception but it does not. Seems it was just pure coincidence that the debugger was on the "FLOG(...)" line of code when the bad access exception gets thrown.
lazy var managedObjectModel: NSManagedObjectModel = {
// The managed object model for the application. This property is not optional. It is a fatal error for the application not to be able to find and load its model.
let modelURL = NSBundle.mainBundle().URLForResource("DataModel", withExtension: "momd")!
return NSManagedObjectModel(contentsOfURL: modelURL)!
}()
Related
Project create usinging Xcode macOS Document App template, with Use Core Data checkbox checked.
Add a Book entity to Document.xcdatamodeld
Add FetchRequest warp property to ContentView,
#FetchRequest(entity: Book.entity(), sortDescriptors: []) var books: FetchedResults<Book>
Build and Run, Crash!
Crash log from console is
2020-07-03 23:12:23.597880+0800 DocMacDemo[15236:4376209] [error] error: No NSEntityDescriptions in any model claim the NSManagedObject subclass 'DocMacDemo.Book' so +entity is confused. Have you loaded your NSManagedObjectModel yet ?
CoreData: error: No NSEntityDescriptions in any model claim the NSManagedObject subclass 'DocMacDemo.Book' so +entity is confused. Have you loaded your NSManagedObjectModel yet ?
2020-07-03 23:12:23.598287+0800 DocMacDemo[15236:4376209] [error] error: +[DocMacDemo.Book entity] Failed to find a unique match for an NSEntityDescription to a managed object subclass
CoreData: error: +[DocMacDemo.Book entity] Failed to find a unique match for an NSEntityDescription to a managed object subclass
2020-07-03 23:12:23.644491+0800 DocMacDemo[15236:4376209] executeFetchRequest:error: A fetch request must have an entity.
2020-07-03 23:12:23.653769+0800 DocMacDemo[15236:4376209] [error] error: The fetch request's entity 0x600003500420 'Book' appears to be from a different NSManagedObjectModel than this context's
CoreData: error: The fetch request's entity 0x600003500420 'Book' appears to be from a different NSManagedObjectModel than this context's
(lldb)
I have looking for NSPersistentDocument SwiftUI example several days, but could NOT find one.
Here are some similar or relation questions. Unfortunately, this problem is not solved.
Using #fetchRequest(entity: ) for SwiftUI macOS app crashes
SwiftUI #FetchRequest crashes the app and returns error
https://developer.apple.com/forums/thread/124656?answerId=417869022#417869022
https://developer.apple.com/forums/thread/132624
EDIT:
Upload this issue project to Github, https://github.com/donly/DocMacDemo.
This is due to emptiness of new document. As in any document-based application you have to prepare some default initial data for new document
Here is possible solution. Tested with Xcode 11.4 / iOS 13.4
in Document.swift
class Document: NSPersistentDocument {
// .. other code here
override func makeWindowControllers() {
// in case of new document create new empty book in context
// that will be shown in opened document window
let isNew = self.fileURL == nil
if isNew {
_ = Book(context: self.managedObjectContext!) // << here !!
}
let contentView = ContentView().environment(\.managedObjectContext, self.managedObjectContext!)
// ... other code here
Well, the answer of Asperi is fine but that leaves you with a maybe not needed Book in the object model. Another way is just to save the context at the same place as suggested by Asperi:
if let context = managedObjectContext {
try? context.save()
}
Then there will also be no error message from the FetchRequest.
My code:
let cgpurl = URL(string: "https://api.coingecko.com/api/v3/ping")!
let task = URLSession.shared.dataTask(with: cgpurl) { (Data, URLResponse, Error) in
if let data = Data, let string = String(data: data, encoding: .utf8) {
let CGPing = string } ; resume() }
The problem is with the 2nd use of "cgpurl". I've tried changing case to no effect. The error I'm getting is, "Cannot use instance member 'cgpurl' within property initializer; property initializers run before 'self' is available". Ok... but I can't even replace cgpurl with the actual link? Then I get the error message "Ambiguous reference to member 'dataTask(with:completionHandler:)'" I realize this release of swift was supposed to be "small" & just to "fix errors" but I've not been able to find any current documentation on this release. I'm using swift 4.2.1 with Xcode 10.1
This code was taken directly from a teaching manual for Swift 4.2
No, it wasn't. The code you have was never right, in Swift 4.2 or any other version of Swift. You have blindly copied and pasted perhaps, without looking at the overall context.
The problem is that the code, as you have it, is sitting "loose" at the top of your view controller or other class declaration, perhaps something along these lines:
class MyViewController : UIViewController {
let cgpurl = // ...
let task = // ...
}
That's wrong. The most basic rule of Swift programming is that executable code can exist only in a function. For example:
class MyViewController : UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
let cgpurl = // ...
let task = // ...
}
}
That may not solve all your issues, but at least you'll get past the most basic mistake you're making and the "Cannot use instance member" compile error will go away.
I'm not clear on how to use this properly but had seen other people doing this type of thing:
func application(application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: () -> Void) {
manager.sharedInstance.backgroundCompletionHandler = completionHandler
}
In our similar implementation, at this point completionHandler is partial apply forwarder for reabstraction thunk helper...
Where manager is (despite being a singleton) essentially:
let configuration = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.ourcompany.app")
let manager = Alamofire.Manager(configuration: configuration)
However this causes the following warning to be printed in the console:
Warning: Application delegate received call to -application:handleEventsForBackgroundURLSession:completionHandler: but the completion handler was never called.
I set a breakpoint here and at this point the message is already visible in the console and backgroundCompletionHandler is nil.
We're building against the iOS 9 SDK with Xcode 7.0 and currently using Alamofire 2.0.2
I originally thought this was introduced when we merged our Swift 2.0 branch but I'm also seeing the message with an earlier commit using Xcode 6.4 against the iOS 8 SDK.
Update 1
To address #cnoon's suggestions:
The identifier matches - the configuration and manager are set inside a singleton so there's no way for it to be wrong.
When adding and printing inside of didSet on backgroundCompletionHandler in the Manager class, the message is logged before the warning.
When printing inside of the closure set to sessionDidFinishEventsForBackgroundURLSession on the delegate inside the Manager class, the message is printed after the warning.
When overriding sessionDidFinishEventsForBackgroundURLSession and printing inside of it before calling backgroundCompletionHandler, the message is printed after the warning.
As for verifying I have my Xcode project set up correctly for background sessions, I'm not sure how to do that and couldn't find any documentation on how to do so.
I should note that when trying to upload some screenshots from my phone I was initially unable to reproduce this issue in order to try these suggestions.
It was only after trying to share some photos that I was able to reproduce this again. I'm not sure or the correlation (if any) but it may be related to the photos taking longer to upload.
Update 2
The UIBackgroundModes are set exactly as #Nick described, and calling completionHandler() directly inside of application:handleEventsForBackgroundURLSession:completionHandler: does not display the warning.
Update 3
So, it appears I overlooked an small but important detail. There's a wrapper around Alamofire.Manager that doesn't expose it directly. The relevant part of its implementation looks like this:
private var manager: Manager
public var backgroundCompletionHandler: (() -> Void)? {
get {
return manager.backgroundCompletionHandler
}
set {
manager.backgroundCompletionHandler = backgroundCompletionHandler
}
}
and setting the completion handler in the AppDelegate executes that code path.
func application(application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: () -> Void) {
myManager.sharedInstance.backgroundCompletionHandler = completionHandler
}
I've confirmed that the following change to expose the instance of Alamofire.Manager and access it directly does not produce the warning:
public var manager: Manager
// public var backgroundCompletionHandler: (() -> Void)? {
// get {
// return manager.backgroundCompletionHandler
// }
// set {
// manager.backgroundCompletionHandler = backgroundCompletionHandler
// }
// }
and in the AppDelegate:
func application(application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: () -> Void) {
myManager.sharedInstance.manager.backgroundCompletionHandler = completionHandler
}
Based on this it appears that using a computed property to proxy the completion handler is the cause of the issue.
I'd really prefer not to expose this property and would love to know of any workarounds or alternatives.
It appears as though everything you are doing is correct. I have an example app that does exactly what you've described that works correctly and does not throw the warning you are seeing. I'm guessing you still have some small error somewhere. Here are a few ideas to try out:
Verify the identifier matches the identifier of your background session
Add a didSet log statement on the backgroundSessionHandler in the Manager class temporarily to verify it is getting set
Add a log statement into the sessionDidFinishEventsForBackgroundURLSession to verify it is getting called as expected
Override the sessionDidFinishEventsForBackgroundURLSession on the delegate and manually call the backgroundSessionHandler
Verify you have your Xcode project set up correctly for background sessions
Update 2
Your computed property is wrong. Instead it needs to set the backgroundCompletionHandler to newValue. Otherwise you are never setting it to the new value correctly. See this thread for more info.
I was working through Core Data Stack in Swift - Demystified but when I got to the line
self.context = NSManagedObjectContext()
I got the warning
`init()` was deprecated in iOS 9.0: Use -initWithConcurrencyType: instead
I see that I can do one of the following for self.context =
NSManagedObjectContext(concurrencyType: NSManagedObjectContextConcurrencyType.ConfinementConcurrencyType)
NSManagedObjectContext(concurrencyType: NSManagedObjectContextConcurrencyType.MainQueueConcurrencyType)
NSManagedObjectContext(concurrencyType: NSManagedObjectContextConcurrencyType.PrivateQueueConcurrencyType)
but since ConfinementConcurrencyType is also deprecated now that leaves me MainQueueConcurrencyType and PrivateQueueConcurrencyType. What is the difference between these two and how should I choose which one to use? I read this documentation, but I didn't really understand.
You essentially will always have at least 1 context with NSMainQueueConcurrencyType and many contexts with NSPrivateQueueConcurrencyType. NSPrivateQueueConcurrencyType is used typically for saving or fetching things to core data in the background (like if attempting to sync records with a Web Service).
The NSMainQueueConcurrencyType creates a context associated with the main queue which is perfect for use with NSFetchedResultsController.
The default core data stack uses a single context with NSMainQueueConcurrencyType, but you can create a much better app by leveraging multiple NSPrivateQueueConcurrencyType to do any work that does not affect the UI.
Replace these two function with the following one:
lazy var managedObjectContext: NSManagedObjectContext = {
// Returns the managed object context for the application (which is already bound to the persistent store coordinator for the application.) This property is optional since there are legitimate error conditions that could cause the creation of the context to fail.
let coordinator = self.persistentStoreCoordinator
var managedObjectContext = NSManagedObjectContext(concurrencyType: .MainQueueConcurrencyType)
managedObjectContext.persistentStoreCoordinator = coordinator
return managedObjectContext
}()
// MARK: - Core Data Saving support
func saveContext () {
if managedObjectContext.hasChanges {
do {
try managedObjectContext.save()
} catch {
// Replace this implementation with code to handle the error appropriately.
// abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.
let nserror = error as NSError
NSLog("Unresolved error \(nserror), \(nserror.userInfo)")
abort()
}
}
}
I'm trying to update my project to work with Xcode 7.0 and after updating my Swift projects I'm getting an error that I don't understand on this line.
let jsonData:NSDictionary = NSJSONSerialization.JSONObjectWithData(urlData!, options:NSJSONReadingOptions.MutableContainers ) as! NSDictionary
The error is
"Call can throw, but it is not marked with 'try' and the error is not handled"
I'm also getting these two errors in my project files...
"linker command failed with exit code 1 (use -v to see invocation)"
and
"error: cannot parse the debug map for "/Users/MattFiler/Library/Developer/Xcode/DerivedData/ePlanner-cqwzlxqgpwaloubjgnzdlomjkfea/Build/Intermediates/SwiftMigration/ePlanner/Products/Debug-iphonesimulator/ePlannerTests.xctest/ePlannerTests": No such file or directory"
Try this code:
do {
let jsonData = try NSJSONSerialization.JSONObjectWithData(urlData!, options: .MutableContainers ) as! NSDictionary
// Use jsonData here
} catch {
print("Well something happened: \(error)")
}
You'll need the try keyword as NSJSONSerialization.JSONObjectWithData now throws an error if something failed since Swift 2. Throwing functions need to be marked with try or try!.
Also you'll need the do { ... } catch to catch any errors that may occur. This will catch the error and handle it.
You might want to read up on the changes in Swift 2 to understand why this happened. Also the WWDC videos will be very helpful.
You need to try and catch if it throws an error.
do {
let jsonData:NSDictionary = try NSJSONSerialization.JSONObjectWithData(urlData!, options:NSJSONReadingOptions.MutableContainers ) as! NSDictionary
//...
}
catch {
}