Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

larswik

macrumors 68000
Original poster
Sep 8, 2006
1,552
11
I am wondering how much information I can store in a plist? I have a video of my Application that I've been working on with much help from this board. It that shows the skills list and how you can create new ones and it saves to a plist. http://sbtraveler.tv/xpCalc/xpCalc_v2.mov

I would like to add one last thing to this program. When the user finishes combat I would like to have a window pop up and they can fill in the details like name, experience points, write details and list what ever items they got (treasure) they had. Maybe 5 or 6 text fields that I would store in a plist.

With an NSMutableDictionary I can store a Key and Object, not enough. Maybe many Dictionaries then stored into a plist but I an guessing there is an easier way to do this. So tonight I am trying research the best way to approach it problem.

Any ideas I should research?

Thanks
 
I am trying to wrap my head around storing many NSDictionarys in the plist? a dictionary has 2 spots, a Key and Object. If I have 6 data entry's like 6 NSTextFields I can then use 3 NSDictionaries to to store the fields It would seem like I would then need to group all those Dict's together to write to a plist file.

That is what I am drawing a blank on? What mechanism do I use to group them together before I write to the file? I read the doc that was posted, it seemed to be for last version of Xcode plus it seemed to only hold 1 item in the tutorial like an NSDictionary.

Thanks
 
The computer science concept of a dictionary is analogous to a real-world dictionary. A simple real-world dictionary has many entries. Each entry has a word and definition. Analogously a computer science dictionary has many entries. Each entry contains a key and a value.
 
Collections Programming Topics.


Here's how I got there.

First, I started at the class reference doc for NSDictionary:
http://developer.apple.com/library/...s/NSDictionary_Class/Reference/Reference.html

On the left is a blue area, the lower part of which lists links to Companion Guides. The first of those is Collections Programming Topics. The second is Property List Programming Guide. The implication is you should read the first guide before the second.


This is a general pattern in all of Apple's programming documentation. The class reference has a section on the left. The upper part is a table of contents for the class doc. The lower part contains links to Companion Guides.

The companion guides often have the inverse relationship: the lower part of their blue left-hand sections (if there is a lower part) are links to class reference docs. You can see this in the Collections guide, but not in the Property Lists guide
 
That part is clear to me, that Dictionaries have multiple entries. But they are in sets of Key and Object, not 1 key representing 6 objects. If I have an NSWindow popup that has 6 NSTextFields on it. I would like that represented by 1 key.

I considered to make a person class with the 6 entries. Then when they click the add button a new class instance is created. They fill out the fields and then that object is saved into an NSMUtableDictionary as a Key representing the person object which I can store to a plist.

But my entire program is written within the AppControler class. I would then create a second class and and then instantiate an object of that class within my AppController.

Would that work that way?

I will read over the documentation Chown33 showed.

Thanks
-Lars
 
But my entire program is written within the AppControler class.

You should fix this before adding any more functionality to your app. It's like hearing someone say they've wired up the entire electrical system for an airplane by snaking a single wire around the plane hooking everything up. Basically, you've managed to make your app procedural by ignoring good object oriented practices. You potentially have many objects there such as: Rounds, Players, Skills, Crit values, Calculations, Preferences, etc. Each of these classes should encapsulate their data and not need to know about the functionality of the others. Your app controller should instantiate these separate model objects tell them to do things and pass up the results to the GUI. MVC.

Also read up on the "Law of Demeter."
 
Last edited:
you've managed to make your app procedural by ignoring good object oriented practices
Yep. that is my Pascal class I took. I would love to move this stuff to their own classes, that's one of the reasons I just bought the book Cocoa Recipes for Mac OS X to help guide me through a large project. Everything I learned about Object - C was console based. There I create the class which I created setters and getters an created objects in main.m. When I started my first Cocoa App I created the AppController.h and .m files which everything linked to and the code was written in. I tried to create different classes and added #import"newClass" into the appController class up top but it would always give me errors when I tried to send a message from a method in object 1, to another method in another object to do something. Through out my program I have code that is like this [self resetSetting];

I will read that link that you provided.

Thanks.
 
...that's one of the reasons I just bought the book Cocoa Recipes for Mac OS X to help guide me through a large project...

Thanks.

Happy to help. I found "Clean Code" to be an excellent book on how to organize my classes and their relationships to each other. The book uses Java, but I was able to figure out how it would apply to Objective-C without really knowing Java.
 
As an Amazon Associate, MacRumors earns a commission from qualifying purchases made through links in this post.
Thanks, I did sign up for a Java class that starts next month at city college.

-Lars
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.