That's how it shows to do it. So, I'm not sure what I would change those to.

I was simply following the instructions in a book I got on Core Data. However, I'm now beginning to see what the problem is. In doing a FetchRequest, it now shows 69 items in the "defaultSize" attribute of the "Settings" entity. It seems that every time the user makes a change, it simply adds a new record with that "defaultSize", instead of replacing the existing "defaultSize" with the new user selected size. Maybe I'm just not understanding the process here. I'm simply trying to use Core Data to keep all the user preferences (in Objective-C I used NSUserDefaults. But with the switch to Swift, I decided to switch to Core Data (for various reasons other than just the language change)). So, I guess my question is this: I just want to hold a single value in the "defaultSize" attribute of the "Settings" entity in Core Data. It starts with a default value of 5 and I want to change that value to a new user selected value whenever the user chooses to do so. Is the information I provided here enough to be able to show that? I've read in multiple places that I can simply use the "theSettings.defaultSize = 6" code and then save the context, but that doesn't just update the value, it is adding new values to an array within the default size. (as a weird side note - when I delete the App off the simulator and start from scratch - the very first time I run it from Xcode it shows three values in the "defaultSize" attribute. I find that odd since I have yet to select any and it should be the default of 5 listed in the xcdatamodeld file in Xcode)

I've attached the setup for the managed objects. The code that I used to access and update the attributes is above. And I've described the actions I'm trying to get to. If there's anything I need to supply, please let me know.

As I've gone through Apple's documentation. I changed some of my code to follow their examples. This is what I use to try to update the attribute based on the user's input: do { let fetchedSize = try appDelegate.persistentContainer.viewContext.fetch(sizeFetch) for data in fetchedSize as! [NSManagedObject] { data.setValue(Float(collectionSize), forKey: "defaultSize") } } catch { fatalError("Failed to fetch size: \(error)") } do { try appDelegate.persistentContainer.viewContext.save() } catch { fatalError("Failed to save: \(error)") } If I do another fetch after the "setValue" piece, the correct values show up. However, once I leave that view and come back, my update never got saved. It goes back to the original defaultValue. Just to note, I also changed the value of the "defaultSize" attribute to be a Float.

Ok, so, I think I've figured out the problem that was causing my issues. I found some code that I missed from testing. The issues stem from trying out different methods of creating and using core data. I found a line of "init" code that kept creating new instances of the core data model. Each time, it would reset all the data to the default and when I tried to pull the "changed" attributes, it was pulling it from the new instance, which of course would return the defaults. Now, that I've clean out all the core data code and went back to add in just the fetch methods to retrieve and update the attributes, they now update as expected, except for the Bool attributes. They don't seem to save. So, I'm still working on why that is happening. If anyone has any thoughts, it would be greatly appreciated. Thanks for those that have responded. It helped me to start thinking in the right direction.

I actually just figured this out based on a totally different issue I was trying to resolve with the UIButton. I found that the "default" style setting for a UIButton is "Plain". When I changed it to "Default", the background image now works on expected.

So, I have figured this out; however, it can be quite touchy and depending on unknown factors, you may need to delete constraints and put them back. But here's what I found works: Contraints: CenterY on parent view (Priority 1000) CenterX on parent view (Priority 1000) Width = Height of view (Priority 1000) Leading to parent view => the amount you want at minimum (Priority 900) Trailing to parent view = the amount you want at minimum (Priority 700) - I have stuck with same as leading Top to parent view => the amount you want at minimum (Priority 900) Bottom to parent view = the amount you wan at minimum (Priority 700) - I have stuck with same as Top Width = some amount that is less than the parent view size in the smallest device supported (Priority 500) Height = same as Width (Priority 500) I usually start with CenterY and CenterX at the same time, then do the other six at the same time. I've been having good luck with this on a number of Apps recently. It took quite a while to get there, but seems to work well now. Thanks.

https://developer.apple.com/forums/thread/656398 See my other thread for how I ended up resolving this.

I did end up figuring out what was wrong with the BOOL attributes. You have to make sure you set the "Use Scalar Types" in the "Attributes" tab of the Attribute that is a BOOL. When you do that you can set it with a variable in code that is a BOOL. Just wanted to completely close this out.

I did end up figuring this out. I had all the background colors on the different views as 'default' except for the UITextView at the top and that was "clear". So, what was happening was that on the simulators, the background was white as default and on the devices the background was black as default. So, the text was there it was just hidden due to the text and viewed background colors were both black. When I change the background colors to white (as I intended them to be). It now works on both the simulators and the devices. Thanks.

A screenshot of what - the final product or the Storyboard? There really isn't much code to this, but this "cellSize = Int(height * 2 / gridSize)" is in the prepare: function for the Layout class used. "height" = the height of the Left and "gridSize" is a Setting that doesn't change during the game (only in between games). There are no errors in the storyboard about constraints. As I mentioned, I have tracked it down to a timing issue between when the prepare: function is run to calculate the "cellSize" and when the height of the CollectionView is actually modified to match the Board. I'm simply trying to figure out how to get all the sizes in place, then have the Layouts determined. Thanks.

I've attached a screenshot of the view with the collection views and the constraints. However, I don't think that's the issue at all. Since, the views are resizing perfectly. It's the layout that is not readjusting when the views change. I have put breaks in the code where the cell size is set and it does not hit that break after the views are adjusted. It hits it before only. That's why I think it must be a timing issue. But if you see anything here that perhaps leads to this issue, I would be happy to try anything. This is how I have been able to trace the order of occurrence through multiple breaks in the code: Board, Left, Bottom are all inserted into the view and cell sizes are set at the "default" size (aka the one that is in the Storyboard). Board is adjusted to its final size based on the auto layout constraints (aka the biggest square that will fit into the space allotted to it in the setup). The cell sizes are set again for all three (Board, Left, and Bottom). Left is resized to match the height of Board. Bottom is resized to match the width of Board. The view setup is completed. However, now that Left and Bottom are different sizes than when the cell sizes were set for those, the cells for the views don't sync as they are adjusted by the user as they should. Hope that helps.

So, in the end, what was happening was that within the FlowLayout class, the layoutAttributesForItem was using an array of Rects to determine the size of each section and instead of changing to the new sizes, it was simply appending the new sizes to the end of the array, so the UI was always using the same set of rect within the array, regardless of what was happening to the view. The solution was to remove all the items from the array and reset the array with the new size rects each time the view changed size. It now works perfectly well. Thanks for the help on this, the notes above led me to this resulting solution.

In the end, I simply "recreated" a UISegmentedControl by inserting SKLabelNode that had user interaction turned on for a tap. I created a SKNode, inserted four labels for the options and attached an action to tapping each label. I then had this SKNode hidden by default and made it visible only after a user controlled collision occurred. So, in the end, it's functional, even if I needed a little more programming to make it happen than a true UISegmentedControl.

I don't need to keep doing that in SpriteKit. So, what's the difference here? If I turn off Gravity, turn off Friction, then what slows it down. Physics 101: An object in motion remains in motion until acted upon by another force. Shouldn't I be able to have an object that continues to move until acted upon?