iOS Need some help on a small project

[PriapusZA]

Hi Guys,

I think I am thinking about this all wrong..

Okay, so I have started my small project. First real project without a tutorial at hand and pretty excited by this - however, I am stuck at the "data" part of my app idea.

The idea of this simple app is to list all Apple devices in a table view. That's the easy part, I guess.

So my first though was - no problem, just stick them in an array with NSString objects. But this is not what I want.

This is what I want:

Each Apple device to be an object that contains:

Device name,
Device model,
Device image
Device release year
etc

Then put that object into the array and the do what I like with it.

So what I was going to do is this:

1. Create a new class for the devices (iDevice.h)
2. Add properties to that class of the above attributes

Create a new object like so:

iDevice *device = [[iDevice alloc[init]

device.deviceName = @"iPhone"
device.deviceModel = @"4S"

[deviceArray addObject: device]; 

iDevice *device2 = [[iDevice alloc[init]

device.deviceName = @"iPhone"
device.deviceModel = @"5"

[deviceArray addObject: device2];

However I don't think this is the correct way and if I want to allow the user to add their own iDevice it would require more work than normal, I think.

I also tried NSDictionary - but that got real messy, quick!

I think I am looking to make the iDevice object.. reusable and not create so many objects that do the same thing..

This app will never make it to the store - it's more to help me understand iOS development better - I just need a push in the right direction here.


Any advice or help would be much appreciated

 

[jnoxx]

Basically, your idea isn't wrong.
It's good to make an iDevice object, that was the way to think, but what do you really want? Do you want to make a constant list, and add ones on the fly or remove? You could use PLISTS to keep objects or you could make a database, but don't forget, the data has to be inserted at least once somewhere, if it's a database or PLIST, or XML/JSon, it's still need to be inserted some time

What you could do, is put it in a plist, make a conversion tool to read the dictionary's from the PLIST into your own custom object, so when the user adds their own, you can just write the objects to the plist.

Not sure if I came across right, but you're thinking is good. Keep on!


Gz, Thijs

 

[PriapusZA]

Basically, your idea isn't wrong.
It's good to make an iDevice object, that was the way to think, but what do you really want? Do you want to make a constant list, and add ones on the fly or remove? You could use PLISTS to keep objects or you could make a database, but don't forget, the data has to be inserted at least once somewhere, if it's a database or PLIST, or XML/JSon, it's still need to be inserted some time

What you could do, is put it in a plist, make a conversion tool to read the dictionary's from the PLIST into your own custom object, so when the user adds their own, you can just write the objects to the plist.

Not sure if I came across right, but you're thinking is good. Keep on!


Gz, Thijs

Thanks for your insight - it as helped me.

What I want to do is start off with a pre-defined list of iDevice objects.

So each iDevice object should have some attributes.

Then I want the user to be able to this list should they wish to do so.

Then I would use these iDevice objects in a detailed screen where I give more info on the tapped object.

So requirements:

1. I should be able to access each attribute of an iDevice object.
2. I should be able to insert new objects (in code or via the UI of APP)
3. I need to persist the newly added objects so.

Point three means I can use NSCoding and NSKeyedArchiver to write it out to disk and just load it again when I need it.

The challenge is finding the best way to store this data and how to construct it.

I think starting off with a Plist file and writing it out to disk would be a nice way to do it. With NSDictionary I could access each object using a key-value pair?

Maybe I am going off track here - this is my first step and I thought before I continue with the rest of my project I need to get data storage and management down first.


P.S: For those of you who read my post over at iPhoneDevSDK - sorry for the double post.

 

[dejo]

This is what I want:

Each Apple device to be an object that contains:

Device name,
Device model,
Device image
Device release year
etc

Then put that object into the array and the do what I like with it.

Welcome to object-oriented programming. I think you are definitely on the right track here.

So what I was going to do is this:

1. Create a new class for the devices (iDevice.h)
2. Add properties to that class of the above attributes

Create a new object like so:

iDevice *device = [[iDevice alloc[init]

device.deviceName = @"iPhone"
device.deviceModel = @"4S"

[deviceArray addObject: device]; 

iDevice *device2 = [[iDevice alloc[init]

device.deviceName = @"iPhone"
device.deviceModel = @"5"

[deviceArray addObject: device2];

However I don't think this is the correct way and if I want to allow the user to add their own iDevice it would require more work than normal, I think.

Define "normal". As soon as you allow the user to add their own data, things get complicated. There's no avoiding that. Because now you will have to build an input mechanism to receive their data, validate the data, and then have some mechanism to persist that data so that it's still there the next time they start the app.

I also tried NSDictionary - but that got real messy, quick!

NSDictionary is certainly a viable approach.

I think I am looking to make the iDevice object.. reusable and not create so many objects that do the same thing..

That, to me, is the definition of a reusable object: one that many instances of it do the "same" thing.

This app will never make it to the store - it's more to help me understand iOS development better - I just need a push in the right direction here.


Any advice or help would be much appreciated

Have you gone through any tutorials that touch on the concepts you are exploring here? If so, which tutorials? (Remember to be specific).

Let me add that the overall concept you are dealing with here is sometime referred to as a "data store".

Hope that helps.

 

[Duncan C]

P.S: For those of you who read my post over at iPhoneDevSDK - sorry for the double post.

Grrr. thought I was going crazy. I posted a reply over on iPhone Dev SDK, then I saw this post, forgot which forum I replied to, and drove myself crazy looking for my reply.

Don't double-post. It's annoying. If you post one place, wait a reasonable amount of time, and still don't get an answer, that's one thing, but shotgun-posting questions just ticks off the people most likely to help you.

 

[PriapusZA]

My apologies Duncan. Wasn't sure where to post this topic.

To the other replies I will read them as soon as I am at a computer. Jut posting off my phone as I am leaving the office.

Again I appreciate the help and replies.

 

[ArtOfWarfare]

Two things:
1 - DON'T USE A DICTIONARY! This is clearly a spot where a new class is the way to go.
2 - Don't call your class "iDevice" - class names should always start with a capital letter. I would suggest calling the class either "Device" or "IDevice".

 

[Duncan C]

Two things:
1 - DON'T USE A DICTIONARY! This is clearly a spot where a new class is the way to go.
2 - Don't call your class "iDevice" - class names should always start with a capital letter. I would suggest calling the class either "Device" or "IDevice".

Using a dictionary is another valid way to do it. It's probably not the best choice, but it does work.

 

[ArtOfWarfare]

Using a dictionary is another valid way to do it. It's probably not the best choice, but it does work.

Yes, and structs are another valid way of doing it. There are many ways to do it. Some are definitely better than others, and we should strongly encourage that they do it the right way.

 

[dejo]

Yes, and structs are another valid way of doing it. There are many ways to do it. Some are definitely better than others, and we should strongly encourage that they do it the right way.

Define "right". Depending on the goals, using an NSDictionary might be just the ticket. They are certainly a consideration when wanting to use property-lists to store the data, as an example.

 

[Duncan C]

Yes, and structs are another valid way of doing it. There are many ways to do it. Some are definitely better than others, and we should strongly encourage that they do it the right way.

dejo beat me to it.

I think it's an over-statement to say a data object is always the right way

There are cases where a dictionary might be a better choice.

For example, dictionaries are good when you want to support variable numbers of key/value pairs, or flexible data types.

Dictionaries are also a good choice when your data has lots of fields that are sparsely populated, since only key/value pairs that are populated take up space.

Dictionaries are also really easy to read and write to plists or to user defaults.

 

[ArtOfWarfare]

These are fine hypothetical scenarios where an NSDictionary might be the right choice. None of them relate to the OP's problem, for which making a custom data object is by far the best choice.

NSDictionarys are a great way of being lazy now and suffering later when they cause bugs (IE, because you used string literals as keys that didn't match case on one character... Please remember to use a const NSString to use your keys, at the least.)

Obj-C is ripe with wrong ways of doing things. One of the reasons I (and others) love Python is because it's so hard to do things wrong in the language.

 

[PriapusZA]

Thanks for all the input gents, much appreciated.

I tell you the reason I am going towards a custom data object.

When I first started the project and constructed an array in the TVC with "dummy" objects it just looked out of place and makes the MVC not so clear (to me) so I went with a custom data object.

That's where I ran into my issues - how to group that object up with attributes of iDevices and have them referenced correctly when needed.

For example if I built a single object like this:

IDevice.h (Thanks ArtOfWarfare, corrected the naming convention )

@property(copy, nonatomic) NSString *deviceModel; 
@property(copy, nonatomic) NSString *deviceReleaseYear;

Okay now say in my TVC class I do something like this in viewDidLoad method
TVC.m

-(void)viewDidLoad
{
  IDevice *device = [[IDevice alloc]init]; 

device.deviceModel = @"iPhone 5S";
device.deviceReleaseYear = @"2013" 

//Add this object to an array 

[myArray addObject: device]; 
}

Later on in my TableView DataSource method I can access this object in the array no problem.

I could also use NSCoding and NSKeyedArchiver to write this array out to disk. Along with any other hard coded objects I put in there.

Then if I want the user to add a new object - I can put the new object into the array - write it out to disk. Then load it again when needed.

I guess it will be okay to do it like this?

I am just having trouble visualising how I would access these details in another view controller. For example - user taps a cell in my table view - I would like the detailed screen to show more info on that object - so I need to pass the data to the next screen - and have a way to identify which data object + attributes go together.

Thinking about it now - wouldn't the indexPath.row solve this issue in the UITableViewCell method?

I'll be starting this project on Monday and oping to be finished by the Friday. It's a really small app - shouldn't take too long?

Thanks all.

 

[bridgeyman]

When I first started the project and constructed an array in the TVC with "dummy" objects it just looked out of place and makes the MVC not so clear (to me) so I went with a custom data object.

That's where I ran into my issues - how to group that object up with attributes of iDevices and have them referenced correctly when needed.

Okay now say in my TVC class I do something like this in viewDidLoad method
TVC.m

-(void)viewDidLoad
{
  IDevice *device = [[IDevice alloc]init]; 

device.deviceModel = @"iPhone 5S";
device.deviceReleaseYear = @"2013" 

//Add this object to an array 

[myArray addObject: device]; 
}

Later on in my TableView DataSource method I can access this object in the array no problem.

You should think about which object should create the initial data, load saved data from disk, and save data to disk. For a simple app, I usually use the App Delegate for these tasks.

When the app launches, you check to see if saved data exists. If it does, you load it. If it doesn't, populate the array with some default data. Then you need to get this data to the appropriate view controllers. Perhaps you can expose the property as an NSArray on the App Delegate. The root TVC can be an observer of this property and refresh itself any time the property changes.

I am just having trouble visualising how I would access these details in another view controller. For example - user taps a cell in my table view - I would like the detailed screen to show more info on that object - so I need to pass the data to the next screen - and have a way to identify which data object + attributes go together.

Thinking about it now - wouldn't the indexPath.row solve this issue in the UITableViewCell method?

When a specific device is selected, you can use the indexPath.row to find the specific iDevice instance in the array. Then, create a new view controller for inspecting the properties of an iDevice and set the selected iDevice as a property on the new view controller.

 

[PriapusZA]

Thanks for the input: bridgeyman

I've realised my app data is going to be a lot larger than I originally thought.

There's two important things I want to do in this app:

1. List all Apple devices ever made

So this means a lot of data already. Simply listing these devices in arrays and so forth is just not going to work.

2. I want the user to be able to search a model or product name.

So I believe Plists are out of the question here.

That leaves SQL and Core Data.

Both of which I think will be too much for me to take on at this very moment.

So - maybe I should start simple - start with only a handful of products made over the last two years - store them in an array / NSCoding.

That way I can get comfortable with NSCoding and forming model objects in their own class files.

At a later stage I can research and learn all about Core Data and then maybe upgrade the project to Core Data (Is this easy to do from an existing project? )

Once core data is in place, I can then do search and anything else I would like to do?

I also thought about Plists for now - but I think that is "too small" for my needs here?

If I understand it correctly - when looking at storing data in your app, can start from the smallest and go up in scale.. something like this based on requirements?

NSUserDefaults< Plists < NSCoding < SQL Lite < Core Data

So with that I think my needs will start with NSCoding and eventually will need Core Data?

Looking at all the Apple products (We're talking Desktops, Laptops, iDevices) - there is over 50 or so different models.


Putting that into arrays would make my code look very messy I think?

Appreciate all the input guys.

 

[ArtOfWarfare]

Core Data is definitely a weak point for me, but I believe the way it works, you don't have to handle how the model gets implemented. You draw a graph of your model in the core data editor and it decides how to load, edit, and save your data.

Also, if Everymac.com has an API it might be worth your while to figure it out and just have your app pull data from there instead.

 

[ChristianVirtual]

CoreData is actually "scary easy"; I use it in my recent app; but yet without iCloud. For simple local use it is actually easier compared to SQLite. The big pain point is when you modify the data model; there are some topics to consider if you want the retain data. You just need to clearly separate and follow MVC concept. But your initial thought pointed in that way anyway. If you need interoperability with other platforms (Android, Windows) the SQLite might be better with a good wrapper layer.

 

[PriapusZA]

Also, if Everymac.com has an API it might be worth your while to figure it out and just have your app pull data from there instead.

That's a cool idea and definitely one that would take the load off the app.

However, the goal of the project is to get up to speed with NSCoding and other "Manual" data storage methods.

I might just look at that API much later. However for now I want to try understand the basic first.

I've decided to leave Core Data alone for now. If I am having difficulties with NSCoding - Core Data is definitely going to be a steep learning curve for me.