06-13-2008, 01:34 PM
Hey all,
A little background... I am a non-developer IT sysadmin by day. I am pretty good with scripting and know my way around several OS's, but have never developed full time... only half hearted attempts at learning C, C++, Java, or whatever the "in-thing" was at the time over the last 15 years of being in the IT industry.
I have always loved Macs, the Mac philosophy and mobile gadgets, so the combination of iPhone & the new SDK pushed me over the edge, and I feel like this was the dev environment I was always meant to learn... *sniff*
Now...
I am able to code things up and see them work with lots of debugging and NSLog statements
but I find myself running into a procedural mindset which runs against OO design principles.
I find myself treating Obj-C messages like function calls, and tracing my program through the details of multiple object instances, instead of seeing the whole picture. That and having only a partial understanding of MVC design principles is tripping me up.
A quick summary of my first app, with some questions later:
1. The app gets the current location
2. The app uses location info in an HTTP POST command against a web server
3. Said web server provides data back to the iPhone filtered for their current location, presented in a UITableView.
[I suspect I am not the only one out there with this type of iPhone app!
]
Now, my assumptions / questions for the pros:
1) I have an NSObject class for the location grabber. Would this be considered part of my "Model"? Or just a "Model-supporting" class? Does this function really need to be in it's own class?
2) Should my HTTP POST "function" have it's own object class? Like DoHTTPPost or something? Or should it be a method of another object class?
3) I wrote a HTML parser for the data coming back from the web server. Should this code have it's own class as well, or be a method in whatever class (2) above should be in? Or perhaps just inline after the POST function.
4) I am starting to think maybe each entry of returned web server data should be it's own object instance, so have an additional class "WebResultEntry", with these put into an NSMutableArray, and then written to the UITableView. Am I on the right track with this?
5) I have RootViewController which interacts with the IB elements. I am making a giant leap and assuming this is the "Controller".
6) Yesterday I think I made a big brain breakthrough in realizing the the NIB file (& it's contents) is actually the "View". So I have the holy triumvirate of MVC now....I think.
7) Out of all the main functions: Get location, Post, Parse Result, Update view... what would be best to keep in AppDelegate and what to segregate out? I suspect that I should just initiate the Get Location in the AppDelegate and then it is off to the object races?
As you can see I am sort of fumbling around here, trying to wrap my head around OO principles and trying to write my app the "right" way instead of a sloppy way, but not making much progress.
Any kind of higher level design guidance would be much appreciated!
A little background... I am a non-developer IT sysadmin by day. I am pretty good with scripting and know my way around several OS's, but have never developed full time... only half hearted attempts at learning C, C++, Java, or whatever the "in-thing" was at the time over the last 15 years of being in the IT industry.
I have always loved Macs, the Mac philosophy and mobile gadgets, so the combination of iPhone & the new SDK pushed me over the edge, and I feel like this was the dev environment I was always meant to learn... *sniff*
Now...
I am able to code things up and see them work with lots of debugging and NSLog statements
but I find myself running into a procedural mindset which runs against OO design principles.I find myself treating Obj-C messages like function calls, and tracing my program through the details of multiple object instances, instead of seeing the whole picture. That and having only a partial understanding of MVC design principles is tripping me up.
A quick summary of my first app, with some questions later:
1. The app gets the current location
2. The app uses location info in an HTTP POST command against a web server
3. Said web server provides data back to the iPhone filtered for their current location, presented in a UITableView.
[I suspect I am not the only one out there with this type of iPhone app!
]Now, my assumptions / questions for the pros:
1) I have an NSObject class for the location grabber. Would this be considered part of my "Model"? Or just a "Model-supporting" class? Does this function really need to be in it's own class?
2) Should my HTTP POST "function" have it's own object class? Like DoHTTPPost or something? Or should it be a method of another object class?
3) I wrote a HTML parser for the data coming back from the web server. Should this code have it's own class as well, or be a method in whatever class (2) above should be in? Or perhaps just inline after the POST function.
4) I am starting to think maybe each entry of returned web server data should be it's own object instance, so have an additional class "WebResultEntry", with these put into an NSMutableArray, and then written to the UITableView. Am I on the right track with this?
5) I have RootViewController which interacts with the IB elements. I am making a giant leap and assuming this is the "Controller".
6) Yesterday I think I made a big brain breakthrough in realizing the the NIB file (& it's contents) is actually the "View". So I have the holy triumvirate of MVC now....I think.
7) Out of all the main functions: Get location, Post, Parse Result, Update view... what would be best to keep in AppDelegate and what to segregate out? I suspect that I should just initiate the Get Location in the AppDelegate and then it is off to the object races?
As you can see I am sort of fumbling around here, trying to wrap my head around OO principles and trying to write my app the "right" way instead of a sloppy way, but not making much progress.
Any kind of higher level design guidance would be much appreciated!