SWXMLHash EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) - swift

I just converted my project to swift 4, but I having error when I emulate my app with SWXMLHash:
var code: Int! = nil
var message: String! = nil
var paramsContent: String! = nil
let xmlStrData = SWXMLHash.lazy(strData)
let dateFormatter = DateFormatter()
dateFormatter.dateFormat = "yyyy-MM-dd"
let appDel: AppDelegate = UIApplication.shared.delegate as! AppDelegate
let context: NSManagedObjectContext = appDel.managedObjectContext
let simulationParamsDescription = NSEntityDescription.entity(forEntityName: "SimulationParams", in: context)
let simulationParams = NSManagedObject(entity: simulationParamsDescription!, insertInto: context)
code = Int((xmlStrData["SOAP-ENV:Envelope"]["SOAP-ENV:Body"]["ns1:GetSimulationParamsResponse"]["GetSimulationParamsReturn"]["code"].element?.text)!)!
message = xmlStrData["SOAP-ENV:Envelope"]["SOAP-ENV:Body"]["ns1:GetSimulationParamsResponse"]["GetSimulationParamsReturn"]["message"].element?.text
When i'm trying to get the code node value, I get this error:
EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)

It seems likely something is going wrong with the parsing here - most probably the structure of the XML response is not exactly what you think it is.
In general in Swift it's a good idea to steer away from force unwrapping optionals with ! because if there isn't anything there you are guaranteeing that the app will crash. It's better to use if lets and guard statements, even if it makes the code uglier, just because it's safer.
To debug this, I'd rewrite your the last two lines as a series of guards (not sure what the types involved are, so you'll have to fill in $DICT_TYPE_HERE appropriately). You may not need to do it for every level, but I'd definitely avoid accessing 4-5 levels on one line - it's just asking for trouble.
guard let envelope = xmlStrData["SOAP-ENV:Envelope"] else as? $DICT_TYPE_HERE {
//handle failure
return
}
guard let body = envelope["SOAP-ENV:Body"] else as? $DICT_TYPE_HERE {
//handle failure
return
}
.
.
until you find the problem
Ideally you should be using an XML object mapper, which allows you to declare Swift objects that can be translated back and forth to XML, but unfortunately I can't find an obvious one for Swift (there are loads for JSON, including the shiny new Codable protocol made by Apple itself).

Related

Fetching data from Core Data on application launch

I need to check for items in my Core Data when the app launches. this is what I wrote so far, but I don't think this is the best practice (although it is seems to be working) is there any other way? better way to acheive what I need?
func getMealsFromCoreData() -> [Meal]{
var retrivedMeals = [Meal]()
let appDelegate = UIApplication.shared.delegate as? AppDelegate
let managedContext = appDelegate?.persistentContainer.viewContext
let fetchRequest = NSFetchRequest<NSFetchRequestResult>(entityName: "Meal")
do {
let result = try managedContext?.fetch(fetchRequest)
for data in result as! [NSManagedObject]{
retrivedMeals.append(data as! Meal)
}
}catch{
print("Failed to fetch.")
}
return retrivedMeals
}
func uploadMeals(){
var mealsToUpload = [Meal]()
let dispatchQueue = DispatchQueue(label: "mealQueue", qos: .background)
dispatchQueue.async {
mealsToUpload = self.getMealsFromCoreData()
for meal in mealsToUpload {
print(meal)
}
}
}
Upload meal should upload to meals to the screen after fetching everything (maybe not the best function name).
This is what I wrote in the AppDelegate in didFinishLaunchingWithOptions:
DataManager.manager.uploadReports()
I get in getMealsFromCoreData a purple warnning that says appDelegate should run on the main queue.
I'm really confused with this CoreData + Moving CoreData fetch from the main thread to the background.
Would really appericiate your help guys.
Am I doing something wrong? What is the best practice for this?
Well, the warning says what you are doing wrong.
The best practice depends on the use case. But it is certainly not fetching all data on application start. Fetch the data when you need it, as much data as you need (to display).
Maybe have a NSFetchedResultsController to maintain the data for your view if that is an option for you.

performBackgroundTask Fault Error when fetching data in Core Data

I am encoutering a strange issue:
I am using a backgroundFetch to fetch the data from Core Data.
func fetchDataFromCoreData(completion:#escaping()->Void)
{
let appdel = UIApplication.shared.delegate as! AppDelegate
let context = appdel.persistentContainer.viewContext
appdel.persistentContainer.performBackgroundTask { (context) in
let fetchReq = NSFetchRequest<NSFetchRequestResult>(entityName: "FreeApps")
do
{
let data = try context.fetch(fetchReq) as? [NSManagedObject]
self.resultData = data
print(self.resultData ?? "data is empty")
DispatchQueue.main.async{
completion()
}
}
catch
{
print("fetch error")
}
}
}
Now in my view Controller, in my table cell:
let myDict = itunesViewModelObj.resultData?[indexPath.row] as? NSManagedObject
print(myDict?.value(forKey: "name") as? String ?? "no name")myDict shows as fault but valefor key comes nil
Now if I comment the performBackgroundTask line data comes properly.
Please help as what can be the issue with backgroundTask.
Any suggestions will be highly appreciated!
Thanks in advance!
The PersistentContainer operates on the main queue. As the name of the property implies, this managed object context is designed to be used in combination with the application's user interface. Maybe you need to dispatch back to the main queue to interact with UIApplicationDelegate and PersistentContainer.
PerformBackgroundTask is generally used for updates to core data. If you are doing fetches you should use the main viewContext.
Maybe using...
DispatchQueue.main.async {
// your code
}

Swift type casting / downcasting

Why does the Sprite Kit Game template project created by Xcode use as!:
if let sceneNode = scene.rootNode as! GameScene? {...}
Wouldn't the following be equally good?
if let sceneNode = scene.rootNode as? GameScene {...}
Note, this isn't the standard "what is the difference between as? and as!" question. And Downcasting optionals in Swift: as? Type, or as! Type? is very close, but isn't quite the same thing, either. The question is that the two above patterns seems functionally similar (they both downcast and unwrap), but it's unclear why the author used if let ... as! GameScene? { ... } instead of the more common and more natural if let ... as? GameScene { ... }.
These two patterns are very close, but are not technically the same:
The if let ... as! GameScene? {...} does the forced cast to GameScene? and the if let then safely unwraps the resulting optional.
The if let ... as? GameScene { ... } will gracefully downcast and unwrap the result.
Functionally these two are almost equivalent. The question is why the template would use the former syntax. One could argue that the as? pattern is little ambiguous because glancing at the code you cannot tell whether you're merely testing the success of a downcast or whether you're dealing with an optional, too. The template's code makes this more explicit.
All of that having been said, I would use if let ... as? GameScene { ... } pattern. It is customary.
I'd say it's a mistake. In any case, the pattern if let x = y as! Type? is unnecessary and you should not imitate it. The pattern if let x = y as? Type is equivalent and usual.

How to use Guard when the function expect return value

I am a fan of the guard statements using Swift.
One thing I haven't fully understand is how (or even if) to use it inside a function that expect return value.
Simple example:
func refreshAudioMix() -> AVPlayerItem? {
guard let originalAsset = rootNC.lastAssetLoaded else {
return nil
}
let asset = originalAsset.copy() as! AVAsset
..... return AVPlayerItem ....
}
The issue with this approach is that I need to check the returned value each time. I am trying to understand if am I approaching this correctly or maybe even guard not needed here at all.
Thank you!
I'd say the use of guard isn't wrong. When the objects you're manipulating have a probability of being nil, it seems fair that you return an optional value.
There's one other way (at least, but I don't see others right now) to handle that: write that your function can throw an error and throw it when you find nil in an optional value in a guard statement. You can even create errors so it's easily readable. You can read more about it here
sample :
enum CustomError: Error {
case errorOne
case errorTwo
case errorThree
}
func refreshAudioMix() throws -> AVPlayerItem {
guard let originalAsset = rootNC.lastAssetLoaded else {
throw CustomError.errorOne
}
let asset = originalAsset.copy() as! AVAsset
..... return AVPlayerItem ....
}

Core Data stack implementation for iCloud sync in a UITabBarController app (Swift 1.2)

I've spent the last 4 days trying to implement a proper Core Data stack with iCloud sync for my Swift 1.2 app, but I can really use some help.
Before, I was using a global Managed Context accessed from everywhere in the app; knowing that it was a bad implementation, now that I'm adding iCloud sync I decided to get rid of it, even though the app was working fine.
So far, I've implemented a new, working Core Data stack with decent - but not perfect - cloud sync between devices.
Now I face two issues:
Sometimes, a few objects don't sync.
Given the particular structure of my app, which I'll explain in a moment, I have no idea how and where in my code I should handle the notifications that Core Data sends when the user logs in or out of iCloud.
But, before tackling those problems, I'd really appreciate - if appropriate - some validation of the work I've done so far and it is mainly for some confirmations that I'm writing this: since I've already spent a lot of time changing my Core Data stack, before going forward I'd like to know if I'm propagating the context properly (the structure of my app doesn't conform to any tutorial I found online, so I had to improvise a bit), or if I made some basic mistakes that will compromise reliable syncing or the future development.
My app is structured as follow:
UITabBarViewController as initial ViewController
1st tab: UIViewController (shown when the app starts)
2nd tab: a UITableViewController embedded in a UINavigationController
3rd tab: another UITableViewController embedded in another UINavigationController
I have a CoreDataStack.swift class with the following code:
import CoreData
#objc class CoreDataStack : Printable {
let context : NSManagedObjectContext
let psc : NSPersistentStoreCoordinator
let model : NSManagedObjectModel
let store : NSPersistentStore?
var description : String {
return "context: \(context)\n" + "model: \(model)"
}
var applicationDocumentsDirectory : NSURL = {
let fileManager = NSFileManager.defaultManager()
let urls = fileManager.URLsForDirectory(.DocumentDirectory, inDomains: .UserDomainMask) as! [NSURL]
return urls[0]
}()
init() {
let modelURL = NSBundle.mainBundle().URLForResource("MyDataModel", withExtension:"momd")
model = NSManagedObjectModel(contentsOfURL: modelURL!)!
psc = NSPersistentStoreCoordinator(managedObjectModel: model)
context = NSManagedObjectContext(concurrencyType: NSManagedObjectContextConcurrencyType.MainQueueConcurrencyType)
context.persistentStoreCoordinator = psc
let documentsURL = applicationDocumentsDirectory
let storeURL = documentsURL.URLByAppendingPathComponent("MyApp.sqlite")
let options = [NSPersistentStoreUbiquitousContentNameKey: "MyApp", NSMigratePersistentStoresAutomaticallyOption: true, NSInferMappingModelAutomaticallyOption: true]
var error: NSError? = nil
var failureReason = "There was an error creating or loading the application's saved data."
store = psc.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: storeURL, options: options, error:&error)
if store == nil {
let dict = NSMutableDictionary()
dict[NSLocalizedDescriptionKey] = "Failed to initialize the application's saved data"
dict[NSLocalizedFailureReasonErrorKey] = failureReason
dict[NSUnderlyingErrorKey] = error
error = NSError(domain: "YOUR_ERROR_DOMAIN", code: 9999, userInfo: dict as [NSObject : AnyObject])
println("Error adding persistent store: \(error), \(error!.userInfo)")
abort()
}
}
func saveContext() {
var error: NSError? = nil
if context.hasChanges && !context.save(&error) {
println("Could not save: \(error), \(error!.userInfo)")
}
}
var updateContextWithUbiquitousContentUpdates: Bool = false {
willSet {
ubiquitousChangesObserver = newValue ? NSNotificationCenter.defaultCenter() : nil
}
}
private var ubiquitousChangesObserver : NSNotificationCenter? {
didSet {
oldValue?.removeObserver(self, name: NSPersistentStoreDidImportUbiquitousContentChangesNotification, object: psc)
ubiquitousChangesObserver?.addObserver(self, selector: "persistentStoreDidImportUbiquitousContentChanges:", name: NSPersistentStoreDidImportUbiquitousContentChangesNotification, object: psc)
}
}
func persistentStoreDidImportUbiquitousContentChanges(notification: NSNotification) {
println("Merging ubiquitous content changes")
context.performBlock {
self.context.mergeChangesFromContextDidSaveNotification(notification)
}
}
}
In my AppDelegate.swift I added the following code just under var window: UIWindow?:
lazy var coreDataStack = CoreDataStack()
coreDataStack.updateContextWithUbiquitousContentUpdates = true
// The following code is the way I found to propagate the managed context of the stack instantiated above in all the ViewControllers of the UITabBarController, including those embedded in the two NavigationControllers;
// since in the future I'll probably need some flexibility in term of adding / rearranging the VCs in the TabBar, I kind of like this way to pass around the context.
// I could have also passed the context to the CustomTabBarViewController and from there do the same thing, but I figured I could just pass the context from AppDelegate, since I already can access all the ViewControllers from here with the following code.
var tabBarController = self.window!.rootViewController as! CustomTabBarViewController
for eachViewController in tabBarController.viewControllers! {
if eachViewController.isKindOfClass(CustomViewController){
(eachViewController as! CustomViewController).passedManagedContext = coreDataStack.context // Context is passed to the VC of 1st tab
}
if eachViewController.isKindOfClass(UINavigationController){
var firstNavController = tabBarController.viewControllers![1] as! UINavigationController
for tvc in firstNavController.viewControllers! {
if tvc.isKindOfClass(FirstCustomTableViewController) {
(tvc as! FirstCustomTableViewController).passedManagedContext = coreDataStack.context // Context is passed to the TableVC inside the NavigationController in tab 2
}
}
var secondNavController = tabBarController.viewControllers![2] as! UINavigationController
for tvc in secondNavController.viewControllers! {
if tvc.isKindOfClass(SecondCustomTableViewController) {
(tvc as! SecondCustomTableViewController).passedManagedContext = coreDataStack.context // Context is passed to the TableVC inside the NavigationController in tab 3
}
}
}
}
// Of course, in applicationDidEnterBackground: and applicationWillTerminate: I save the context; obviously, I also save the context, when appropriate, from the other ViewControllers.
With this structure in place, I instantiate my stack in AppDelegate and from there I propagate it to the 3 elements of the TabBar; from those, I again propagate the context to every other ViewController I present. I logged to the console the context everywhere and I can confirm that it is always the same.
As a matter of fact, the app with this code works.
I can't say it is perfect because, as I said, sometimes a few objects don't sync, but I suspect the cause of those objects not syncing is another (briefly, I have 2 NSManagedObject subclasses; the objects of subclass1 have an object of subclass2 as property; if I create a new subclass1 object using an existing subclass2 object as property, sync is fine; if I also create a new subclass2 object, save it and immediately set it as property of subclass1, sometimes the subclass2 object doesn't sync on the other device, while the subclass1 does and then misses that property... I can work on that later).
Before digging into this sync issue, I'd really love to know if the work I've done so far with the stack makes sense, or if it is horrible and needs to be canned.
Then, if all the code above is not horrible and if the reason of the occasional missed sync of objects would turn out to be the one I suspect, comes the other issue, and it is a big one: where do I put the code to handle the notifications that occurr when the user logs in or out from iCloud (NSPersistentStoreCoordinatorStoresWillChangeNotification and NSPersistentStoreCoordinatorStoresDidChangeNotification)?
I tried to put methods I've written (without actual functionality, at the moment I only log something to the console to know that I got there) based on Core Data by Tutorials book in both my AppDelegate and my CoreDataStack class, but in both cases when I log in or out from iCloud while the app is running, the app crashes without a single line in the console, so I have no idea of the issue.
Maybe I should put the methods to handle these notifications in all the ViewControllers, since the fetch requests happen there and UI is updated from those classes, but I'm not passing the entire coreDataStack objects around, only the context... so I'm missing something. Should I pass the entire stack, not only the context? Is it okay to handle those notifications from my CoreDataStack, or should I do it from AppDelegate?
Any help would really be appreciated...
Thanks in advance and, please, excuse if my question is not clear (I'm quite a beginner and english is not my main language...).
Also, thank you for your time reading this long question!
#cdf1982
I think the problem is that iCloud + CD never worked properly. It's not a developer code issue, the problem is the Apple implementation of iCloud + CD that simply fails.