“SwiftData inheritance relationship”

Thank you for replying.I notice that the SKView is inherited from UIView, therefore it should support focus. Right?

I am having a similar issue with the Xcode 7.0 general release. I wan't having a problem until udpating from Xcode 6. Xcode 7 crashes when I try to open a particular project. This doesn't happen on all my development machines, just one, which implies that it is a machine setup issue rather than a project issue - or a combination of the two. The crash report lists the exception below as the culprit. It looks like there is perhaps some issue with old setting lying around somewhere on this particular machine, but I don't know where that might be. I opened the project in Xcode 6 to verify that I don't see these settings in the project itself. Any ideas?Thanks!Exception Type: EXC_CRASH (SIGABRT)Exception Codes: 0x0000000000000000, 0x0000000000000000Application Specific Information:ProductBuildVersion: 7A220ASSERTION FAILURE in /Library/Caches/com.apple.xbs/Sources/IDEXcode3ProjectSupport/IDEXcode3ProjectSupport-8184/Xcode3Core/LegacyProjects/Frameworks/DevToolsCore/DevToolsCore/BuildSystem/Runtime/XCPropertyInfoCo

I solved the issue like this:import UIKit extension UIScreen { func isPortrait() -> Bool { return self.bounds.width < self.bounds.height } } class BaseViewController: UIViewController { private lazy var _isPortrait: Bool = UIScreen.mainScreen().isPortrait() func isPortrait() -> Bool { if let parentViewController = self.parentViewController as? BaseViewController { return parentViewController.isPortrait() } return _isPortrait } override func viewWillTransitionToSize(size: CGSize, withTransitionCoordinator coordinator: UIViewControllerTransitionCoordinator) { if let superView = self.view.superview { if superView.isKindOfClass(UIWindow.self) && self.parentViewController == nil { _isPortrait = size.width < size.height } } super.viewWillTransitionToSize(size, withTransitionCoordinator: coordinator) } }At least I assume that the child viewController will never touch inherited private _isPortrait, because it is lazy. Only the top level view can of the rootViewController is allowed to set

Yes, BaseScene handles enforcing what sprites represent buttons and which should get the next focus. Also, GameViewController inherits from GCEventViewController and uses the controllerUserInteractionEnabled property to control whether or not you want to get game-like events or UIEvent-type events -- it uses the UIEvent model for the home and end screens, where there are buttons shown, and game-like events when actually playing the game.

I do like the idea of yielding, but I feel like this version is too complicated, and as someone mentioned above, exposes too many implimentation details to the caller.Yeild is similar to return, except instead of ending the execution of the function, it pauses it in place. Then the function resumes from where it was when it is called again. For example: I would like to be able to run through a list of items, and yeild to return the first item meeting some criteria. Then at some later point, I would like to resume running through that list (picking up where I left off). This would make building a packrat-style parser much easier.Perhaps a simpler way to approach this would be to have a rule that once it returns, it forever returns that same value when called (as opposed to having live and dead states). That way, if I want it to make it optional and have it return nil after it is dead, I can do that. Or I can throw an error if I prefer. Or I could just have it return an empty string if I want.The trickiest bit

I tried again and now it seems to work. I don't know what was wrong previously. Only problem is Interface Builder does not recognize the class as UIViewController subclass if I inherit it from generic UIViewController subclass like I said earlier.

You can check out using prefetching.Prefetching allows Core Data to obtain related objects in a single fetch (per entity), rather than incurring subsequent access to the store for each individual record as their faults are tripped. For example, given an Employee entity with a relationship to a Department entity, if you fetch all the employees then for each print out their name and the name of the department to which they belong, it may be that a fault has to be fired for each individual Department object (for more details, see Core Data Performance in Core Data Programming Guide). This can represent a significant overhead. You could avoid this by prefetching the department relationship in the Employee fetch, as illustrated in the following example:NSEntityDescription *employeeEntity = [NSEntityDescription entityForName:@Employee inManagedObjectContext:context]; NSFetchRequest *request = [[NSFetchRequest alloc] init]; request.entity = employeeEntity; request.relationshipKeyPathsForPrefetching

TommieC thanks for the reply.I appologise that I forgot to get back on this post but the problem was not fault not being fired. The problem was I was reseting the context at a wrong place in my code (after fetching entries!) and so the main entitiy objects stayed in memory only because i had a pointer to them (an nsarray which was used to load the table view).As soon as I removed the reset, everything worked as expected.In anycase, I have flagged the email I got from your response for future response in a related scenario.Even if you were to get your current solution to work correctly, the approach would not be correct. You are creating an NSPredicate each time through the loop. The performance and memory build up is not going to be good. Apple has some great guidelines on solving these kinds of issues. Among them is the idea that one should get all the data you need, before entering loops.I already have the main entity with me in prefetched. would that still make a difference in case of relationship

This worked for me (from the release notes):The Xcode build system no longer automatically inherits the environment used to launch the app when running in the IDE. This prevents unnecessary rebuilds when Xcode.app is opened from the command line.If necessary, users can opt in to the old behavior by entering this command in Terminal:$defaults write com.apple.dt.Xcode UseSanitizedBuildSystemEnvironment -bool NOhttps://developer.apple.com/library/prerelease/watchos/releasenotes/DeveloperTools/RN-Xcode/Chapters/xc7_release_notes.htmlBart

There's a trick to it, using the gesture recognizers exposed on the UITextView.Your text view has two gesture recognizers, the panGestureRecognizer and the directionalPressGestureRecognizer, which are inherited from UIScrollView. A little-known trick with those gesture recognizers is that you can actually add them to a view other than the scroll view that they're attached to, which is what you want to do here. Whatever view that contains both your text view and your buttons is the best view to use for this:[myParentView addGestureRecognizer:myTextView.panGestureRecognizer];[myParentView addGestureRecognizer:myTextView.directionalPressGestureRecognizer];Then, you need to enable the directionalPressGestureRecognizer (it's disabled by default) and add UITouchTypeIndirect to the panGestureRecognizer's allowedTouchTypes, and you should be good to go.You won't need to make the text view focusable: only your buttons will need to accept focus.The reason this works is because the touch and press events are go

I already have the main entity with me in prefetched. would that still make a difference in case of relationship end objects?It would, prefetching explicitly will pull the appropriate object graph in one call rather than for each object. I would still recommend calling the data that you need into a predicate before you enter the loop. This will very likely reduce you memory overhead. You could then manipulate the loop collecting your objects to be updated and then saving them as a batch rather than singly. Overall you will want to take a long look at the performance material mentioned earlier in order to have the solution scale appropriately.