iOS Storing NSStrings

[larswik]

Hey I just wanted to run this past the folks that are more experienced then me about the way I am going to store and approach a problem in my App. I have a UITableView with a UINavigationController and a UITabButton I think it is called. The user clicks the add button, a new page pops up (UIViewController) asking for the Client Name and Job Name which the information is entered into UITextFields. This information then becomes a Cell in the table view. When the user hits OK a new UIViewController is instantiated with all the textFields, lables and so on are created and pushed on by the NavigationController.

Now when the client fills in the information and saves it, I was planning on storing the 10+ textFields as NSStrings objects in an NSMutableDictionary. Then store each Dict inside of an NSMutableArray for each job which I write to my Property list.

Does that sound right?

 

[North Bronson]

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.

 

[larswik]

Fair enough. I have gotten use to Plists so I put off learning Core Data. Sounds like I should start to learn it.

Thanks.

 

[chown33]

Does that sound right?

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.

 

[larswik]

That is true Chown33. The app that I have now it writes to a plist file and it works great for a couple of things it saves.

The reason I asked is because there is always more then one way to do it. Also the Objective-C tool set is so vast perhaps there was a better way of doing it I am unaware of.

North Bronson's idea on Core Data gives me an accuse to learn something new. I remember seeing that you include Core Data when you start a project by checking the box off. Is it something that you can add after the fact if you already have an app started?

Thanks guys!

 

[chown33]

That is true Chown33. The app that I have now it writes to a plist file and it works great for a couple of things it saves.

The reason I asked is because there is always more then one way to do it. Also the Objective-C tool set is so vast perhaps there was a better way of doing it I am unaware of.

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.

 

[larswik]

the original design wasn't sufficiently abstracted from the underlying implementation.

This is probably the hardest thing for me to grasp when breaking down problems. Writing code is pretty easy but thinking abstract is hard. The teacher in my Pascal class last semester talked about abstract and it was hard for me to grasp. If someone on the street stopped me ans asked me to explain abstraction I could not answer him. But if they said write an 'if' statement to make a decision I can see the logical steps involved and could explain that.

On the other side I do write lots of little programs to test things and see how they work. Because the Objective C tool set is so large I like to ask people if there is a better way to do something, in the case of this thread the answer was Core Data. So this gives me an excuse to try out a small project and use Core Data.

Thanks for you help Chown33 and guidance. By the way do you know of any books out there that cover Abstract Practice when it comes to programming?

 

[Sydde]

This is probably the hardest thing for me to grasp when breaking down problems. Writing code is pretty easy but thinking abstract is hard. The teacher in my Pascal class last semester talked about abstract and it was hard for me to grasp. If someone on the street stopped me ans asked me to explain abstraction I could not answer him. But if they said write an 'if' statement to make a decision I can see the logical steps involved and could explain that.

On the other side I do write lots of little programs to test things and see how they work. Because the Objective C tool set is so large I like to ask people if there is a better way to do something, in the case of this thread the answer was Core Data. So this gives me an excuse to try out a small project and use Core Data.

Thanks for you help Chown33 and guidance. By the way do you know of any books out there that cover Abstract Practice when it comes to programming?

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.

 

[North Bronson]

This is probably the hardest thing for me to grasp when breaking down problems. Writing code is pretty easy but thinking abstract is hard. The teacher in my Pascal class last semester talked about abstract and it was hard for me to grasp. If someone on the street stopped me ans asked me to explain abstraction I could not answer him. But if they said write an 'if' statement to make a decision I can see the logical steps involved and could explain that.

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.