Storing NSStrings

This is the sort of thing that Core Data eats for breakfast. PLISTs are not the best choice if your user will be editing and writing new data.

 

Instead of asking us that question, you could write a test program, along with the code you described that does the reads & writes of plists, and thereby ask the computer itself. After all, the computer's going to be the ultimate arbiter of whether your description is right: does it logical sense, has it been coded correctly, is its performance acceptable.

Implement the class that does your store and retrieve. Then write a test program to exercise it. Use printf() or NSLog() to show the data that goes into cells. Then run the program and you can answer your question yourself, and even end up with a working class and its test.

 

But you should still start with The Simplest Thing That Could Possibly Work.

In the process of making the simple thing, and making it work, you will end up with an interface (an API), which defines the visible behavior of the thing: the classes, methods, properties, events, etc. that comprise overall behaviot. The fact that it's implementation is simple should be irrelevant. The API is the important thing.

Once it's working, as demonstrated by writing test programs, then you can think about other ways of implementing the same thing, while keeping the same interface (API). In the process of doing that, you may find you need to add a few things to the visible interface. But if you find that you have to rip out and replace huge swathes of interface, then it's likely that the original design wasn't sufficiently abstracted from the underlying implementation.

Also, when you spend time thinking about The Simplest Thing That Could Possibly Work, it means you're thinking about exactly what work needs to be done. That is, you're thinking about capability, instead of implementation details. It also means you're thinking about the limits of whatever implementation you're starting with, because exceeding a limit is often what separates Could Possibly Work from Can't Possibly Work.

So again, start with The Simplest Thing That Could Possibly Work, develop and test the API, and only then think about different ways to implement it. Even if you end up using a new implementation, you'll have the working simple one as a reference. That can be important in testing correctness, evaluating performance, and other things. If you start right away with The Complex Thing, especially if you're not familiar with the technology itself, then correctness, performance, and so on depend entirely on you mastering the technology. There's no simpler known-working version to compare against.

 

I think of abstraction in terms of the difference between arithmetic and algebra. Imagine you are writing a controller for a robot that does something with a bucket of sand. Its arm picks up the bucket, swings around and dumps it into a tray, then sets the bucket on a return line. Pretty easy, like adding two numbers. Now add in code for dealing with half a bucket of sand, or an empty bucket. Finally, design the robot to determine what is in the bucket (water, rocks, soap, oil, whatever), how much there is, and what to do with it.

Abstraction is a matter of dealing with unknown, arbitrary values instead of reliable constants. You have the right idea: write and test small programs, but make them as flexible as possible, then put the little parts together into a larger, more complex application. Each routine should be, as chown33 said, the simplest thing that works, ready to work with whatever it gets (within reason). Properly designed, the working core of your finished app will operate behind whatever UI you build for it, and the components can be reused in other applications, where they make useful sense.

There may be books on abstraction, but you may well find the most effective way to learn it is practice.

 

You might not have to worry so much about defining what abstraction is or learning what abstraction is in some (abstract) academic context. Start by just learning to recognize it when you work.

Your original question was about strings. Strings are actually pretty tough things to deal with when you leave the ASCII-world. NSStrings are opaque containers. You do not have to worry about the implementation details. You do not have to worry if the system choose to represent that character with an 8-bit integer or a 16-bit integer or two 8-bit integers stuck together. You don't care. The objects that work with NSStrings don't care. It is abstracted away from you. The object becomes an opaque container. You do not have to work directly with the data being contained; the object gives you API and that is what you work with.

Look at NSUserDefaults. The class gives you a lot of methods that look like you are accessing a dictionary. Apple might be using the class as a wrapper around a dictionary and saving that to a PLIST. Apple might be loading the data from Core Data and saving it to SQLite. Apple might decide to upgrade the OS and implement some fancy new technology that is ten-times faster. You don't care. You care about the API. The API does not change. The implementation changes, but the class is an opaque container. You do not work directly on the data, you work with the API that the class gives to you.