iOS Proper way to query a view used to store app settings

[VTPete]

Hi Everyone,

Hey, this is my first post! Woo hoo.

I'm a long-time C++ / XWindows programmer getting into programming my iPhone. I have a question regarding the proper paradigm for designing a view to set application settings.

I chose a "utility" app that has a nice front side and flip side view.

I then added some switches, sliders, etc. to the flipside view controller. I didn't have a problem querying their values when the MainViewController's flipsideViewControllerDidFinish message was sent...

But, the way the utility app is designed, the flipside's view seems to be "reclaimed" when you hit the done button... and then recreated as necessary. So, the previous values of my switches, sliders, etc. get set back to their default values instead of remembering what they were.

That's when I said, "No problem, I'll just store their values in my mainViewController's object definition when the done button is hit and then restore their values to the last settings when the little "i" button is pushed.

Something tells me that my implementation isn't a very good paradigm and that I'm doing something stupid.

Thoughts?

P.S. I just tried creating the flipside controller as a static variable and then alloc and initing it only once... and then not releasing it. IE, keeping it around. And, that seems to work, but again, I get this feeling I'm not doing things right.

 

[teek]

I'm afraid I can't help but I would very much like to know this too.

 

[dejo]

Thoughts?

Basically, you are looking for some kind of data persistence. Your "settings" can be stored in a model object of some sort and the flipside view controller references that model to bring those settings to the view as well as store changes. There are a variety of approaches you could take to achieve what you're looking for: appDelegate properties, NSUserDefaults, a singleton, CoreData, etc. Since these are 'settings', you probably will need to access them in other places and thus do not want to restrict these settings to the flipside view controller (so don't store them with it). Hope that helps with my high-level perspective.

 

[VTPete]

Thanks Dejo,
I'll probably try coredata as I need to learn how it works anyway.

But, is the idea that the flipside gets created only when you hit the "i" button the preferred paradigm? (As opposed to what I tried, creating it once and letting it hang around in memory.)

-Pete

 

[dejo]

But, is the idea that the flipside gets created only when you hit the "i" button the preferred paradigm? (As opposed to what I tried, creating it once and letting it hang around in memory.

It's not always the preferred approach, especially if it is being done frequently, but you need to think of it this way: can you guarantee that the flipside already exists when the "i" button is hit? There may be reasons it isn't: first time accessing the view, was unloaded from memory due to a shortage, etc. So, with that in mind, you built it in a way that it is easily recreated, if necessary, and able to retrieve any needed supporting model data from elsewhere that probably does have more persistence.

 

[PhoneyDeveloper]

You're violating the Model-View-Controller design. You are storing your model values in your views. You need to store them in your Model. First, you need to have a data model.

For a small number of app prefs like this I would use NSUserDefaults. You can write the values either when they change in the settings view, or every time that the settings view goes away. That would probably be in viewWillDisappear or in the view controller's dealloc method.

I recommend that you build the view controller every time that it's needed and dealloc it when it's done.

 

[VTPete]

Phoney,

Excellent advice... and you've given me the response I was looking for when I intuitively knew that storing attribution with the view wasn't a good idea. I just wasn't sure why.

-VTPete