iOS iPhone plist

[larswik]

I am doing a test tonight as I am learning the iPhone. Is the saving system the same as creating an application on the OS X platform?

I have 3 columns and many rows in the photo shown. I would save each colums as an NSArray containing NSStrings. Then take the 3 NSArrays and save them into an NSDictionary which I then write to a plist file which I save in the Documents Directory in my Sandbox on the iPhone. Is my understanding correct?

 

[jiminaus]

Forget about the technique of parallel arrays. We only ever did them back in the day because the languages we were using either didn't have complex user-defined types or couldn't support arrays of those types.

Spin this around and treat your data as an array of rows, each with 3 columns.

Aim, perhaps, for a plist like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
                    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
  <dict>
    <key>item</key>
    <string>item 1</string>
    <key>monthly</key>
    <real>12.34</real>
    <key>total</key>
    <real>1234.56</real>
  </dict>
  <dict>
    <key>item</key>
    <string>item 2</string>
    <key>monthly</key>
    <real>98.76</real>
    <key>total</key>
    <real>98765.43</real>
  </dict>
  <!-- etc. -->
</array>
</plist>

 

[North Bronson]

You might also want to look at Core Data for this kind of work.

 

[larswik]

I have not yest started to look at Core Data. I am working on little programs every evening and better understanding what I am doing so far Practice, practice, practice.

Jim, Lets see if I understand you. I should create an NSMutableArray filled with NSDictionarys. Each dict has a Key Object pair for the 3 values?

 

[jiminaus]

Jim, Lets see if I understand you. I should create an NSMutableArray filled with NSDictionarys. Each dict has a Key Object pair for the 3 values?

Yes, in the serialised form of the plist. At runtime and in code, you'd have an array of Item objects. Each item object would have a name, monthly, and total properties.

At first you might want to translate between dictionaries an Item objects manually. For writing each item, create a new dictionary with item key being the item's name, the monthly key being the item's monthly, set the total key to the item's total; then add the new dictionary to an array, and finally serialize the array. You would do the reverse for reading.

Later you could move on to using NSKeyedArchiver and NSKeyedUnarchiver. The Archives and Serializations Programming Guide has the details on this.

Taking this approach will move nicely into Core Data once you have learnt that.

 

[larswik]

Thanks for the tid-bit of information. I am having fun with with simple project. Instead of dragging in these UITextFields in IB I just did my first programmatic UITextFields. Instead of having all those empty UITextFields on the screen I created a new Class that had 3 UITextFields

@implementation makeNewLine

-(UITextField *)makeItem{
    UITextField *itemField = [[[UITextField alloc] initWithFrame:CGRectMake(10.0f, 40.0f, 130.f, 25.0f)]autorelease];
    itemField.borderStyle = UITextBorderStyleRoundedRect;
    return itemField;
}

-(UITextField *)makeMonthly{
    UITextField *itemField = [[[UITextField alloc] initWithFrame:CGRectMake(160.0f, 40.0f, 50.f, 25.0f)]autorelease];
    itemField.borderStyle = UITextBorderStyleRoundedRect;
    return itemField;

    
}
-(UITextField *)makeTotal{
    UITextField *itemField = [[[UITextField alloc] initWithFrame:CGRectMake(230.0f, 40.0f, 70.f, 25.0f)]autorelease];
    itemField.borderStyle = UITextBorderStyleRoundedRect;
    return itemField;

}

@end

In the appDelegate I have this so far

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    makeNewLine *firstRow = [[makeNewLine alloc] init];
    
    UIImageView *openingView = [[[UIImageView alloc] initWithFrame:CGRectMake(0.0f, 0.0f, 320.0f, 480.0f) ]autorelease]; //create imageview to screen size
    openingView.backgroundColor = [UIColor redColor]; //sets the back ground color

    [_window addSubview: openingView]; //adds the view to the window
    [_window addSubview:[firstRow makeItem]];
    [_window addSubview:[firstRow makeMonthly]];
    [_window addSubview:[firstRow makeTotal]];
    
    [self.window makeKeyAndVisible];
    [firstRow release];
    return YES;
}

And it is working so far! Now to implement the NSMutableArray and NSMutableDictionary. I think I can figure this out so no answer on this one.

Thanks again! Seeing this stuff work makes programming fun.

 

[jiminaus]

Classes don't do things, classes are things. The names of classes should be noun phrases. If your naming classes as verb phrases, you're think of classes as glorified methods; that's procedural thinking, not object-oriented thinking.

And PLEASE name your classes with an initial capital letter. It's rather disconcerting reading your code with an initial lower case letter. The brain thinks it's a method, and that's compounded by it also being a verb phrase.

 

[larswik]

Ahhh, I knew that about the upper case but it slipped past me. It's 2:30am and I am getting tiered. I will fix the Class name if I can just rename everything.

I know you, Chown33 and other people have mentioned about the naming convention for Classes, it's tough to sink in for some reason. So instead of MakeNewLine it should be something like TextFieldRow or EntryFields?

I keep falling back on procedural coding even in Objective C. Instead of creating a Dice Class to roll a random number I tend to create a dice Method and when I need to roll the dice I would just call that Method [self Dice]; from within another Method or IBAction for example. This current project I am trying to break that habit and learn to add objects via programming instead on IB. Trying to figure out how to dismiss the keyboard from a programmaticly created UITextField has me scratching my head.

Thanks for your help Jim

 

[North Bronson]

I keep falling back on procedural coding even in Objective C. Instead of creating a Dice Class to roll a random number I tend to create a dice Method and when I need to roll the dice I would just call that Method [self Dice]; from within another Method or IBAction for example. This current project I am trying to break that habit and learn to add objects via programming instead on IB. Trying to figure out how to dismiss the keyboard from a programmaticly created UITextField has me scratching my head.

[1]
Core Data should help reinforce the MVC separation in your mind. Core Data looks intimidating, but you only have to implement a very thin subset of the framework to gain big functionality like persistency.

[2]
Build a project entirely in code; do not use Interface Builder. The UI might look a little Spartan, but you will focus on the MVC separation and focus on how these different object interact with each other. IB can abstract all of that away. IB is a great tool, but it does not always encourage great design patterns or habits. I have found that it helps if you bring the great design patterns and habits to IB instead of expecting it to happen the other way around.

 

[larswik]

When you bypass IB can you still access all the properties that you get in the inspector? For instance I wanted my fonts that were entered into the UITextField to be bold. I did not see a method in the UITextField docs except for font. But making the text bold might not be something found in UITextField but instead the fonts.

I will look at the project tonight again. I think I am failing with the MVC design I have a model that I made that creates a new row of UITextFields but I added all the code in the appDelegate. I believe I am supposed to create a controller Class and then push a subview onto the mainWindow.xib. I have written the code in this Method

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

I will rework it tonight.

Thanks for your help.

 

[dejo]

When you bypass IB can you still access all the properties that you get in the inspector?

Yes, though not always as directly.

For instance I wanted my fonts that were entered into the UITextField to be bold. I did not see a method in the UITextField docs except for font. But making the text bold might not be something found in UITextField but instead the fonts.

UITextField has a property called font. So, for example, you could:

textField.font = [UIFont boldSystemFontOfSize:17.0];

 

[North Bronson]

When you bypass IB can you still access all the properties that you get in the inspector? For instance I wanted my fonts that were entered into the UITextField to be bold. I did not see a method in the UITextField docs except for font. But making the text bold might not be something found in UITextField but instead the fonts.

It is even better: editing the view in code will give you access to lots of customization that cannot be done exclusively with IB.

You are absolutely right about bold fonts. Using the code will help reveal the structure of objects and design patterns that might have been abstracted away while relying on IB. IB can be a great tool, but I seriously recommend learning MVC and trying to build the project by code and then using IB once you understand why certain design patterns are preferable over others.

 

[larswik]

I can already see some of the benefits. I am able to make one sytle of my UITextfield thinner while keeping that inset look. With IB I could only resize it horizontally, not vertically.

I think you are totally write about skipping IB. I have been somewhat lost with the MVC this will take a little longer but seems to educate me more.

Thanks!!!