spaghetti code with core data and multiple views
spaghetti code with core data and multiple views
- Subject: spaghetti code with core data and multiple views
- From: Christopher Campbell Jensen <email@hidden>
- Date: Tue, 14 Jul 2009 00:42:32 +0200
Hi,
I am busy writing my first app using objective-c, cocoa, xcode, etc.
It is basically an app that will allow the user to compile meta data
from several sources, select the bits he wants, and then write that
meta data to the movie file. Think MetaX with more sources.
My main overall problem is:
How do I avoid spaghetti code with multiple views who need to interact
with core data and each other?
I am a CS student, so I have been taught a lot of best-practices when
it comes to architecture, and abstracting code. I have been trying my
best to stay true to these principles, and have so far carved up my
app and it's code into several class and views. This is the rough
outline of the architecture at the moment:
*Started with a Core Data Application
*Removed the window from the default MainMenu.xib
*Added a new class called MainWindowController who was a
MainWindow.xib file (main purpose for this was to avoid messing about
with the default AppDelegate as it had so much code in there already)
*The AppDelegate now instantiates the MainWindowController in
awakeFromNib
*MainWindowController holds a toolbar, a bunch of other components,
and an NSTabView which it passes on to two other ViewControllers:
**otherSourcesTagsViewController creates a new tab in the NSTabView
and adds it own view to it. It has a bunch of nspopup button fields
where the user can select from predefined information fetched from the
core data repository
**currentTagsViewController creates a new tab in the NSTabView and
adds it own view to it. It has a bunch of text entry fields where the
user can manually edit the tagged information that was chosen in the
nspopup boxes in the otherSourcesTagsViewController
*sourcesSearchWindowController holds a window that is used as a sheet
from MainWindowController. It is opened when the user uses the search
box in the MainWindowController and allows the user to select which
entries from core data to use to populate the nspopup boxes in the
otherSourcesTagsViewController
Ok, at this point I am sure you are well and truly confused, so I
figured I would explain the way I envision a standard use would be:
*app opens
*user opens a movie file with no metadata (yet)
*he enters the name of the movie the file is a recording off into the
search-box in the toolbar
*the sourcesSearchWindowController pops up its modal window, and
downloads tagging information from online sources in addition to what
is cached in the core data repository and displays that a list of
results to the user
*the user checks off which results he thinks is relevant, then clicks
ok which dismisses the modal window
*the user now uses the NSTabView to go to the view controlled by
otherSourcesTagsViewController where he is presented with a bunch of
NSPopups which have been populated with the information from the
chosen search results. He works his way through the popup boxes,
selecting the most accurate information (these might be from a variety
of sources)
*once that is done, he goes back to the nstabView and selects the view
controlled by currentTagsViewController. This presents him with a
bunch of text fields which are now populated by all the entries he
selected from the nspopup menus, and he can make any fine adjustments
he wishes
*once he is happy with all the metadata, he goes to the save menu and
the changes are written to the movie file
Ok, so this means that we have three different views/windows (all of
which are instantiated by the MainWindow) who all interact with the
core data:
1. the search picks out results and narrows down the number of hits
(by user selecting the ones he likes)
2. the nspopup bar view picks those narrowed down results apart and
pulls out the information for the user to mix and match single entries
he likes
3. the textfield view displays the single selected elements from the
popups and allows the user to make fine adjustments (will not be saved
into core data)
At first I figured this was a nice way of designing things. Each
separate view element/window has it's own controller, and thereby
reducing the amount of different tasks that the MainWindowController
needs to deal with.
I am now reconsidering, as the amount of communication that will now
have to happen between these three views is causing me many headaches,
as I am struggling to see how I can get this all tied together. What I
am hoping for, is that there is a way that the different views can
create subsets of the core data repository (as in the search followed
by the user selecting his desired results) which will be held in the
managedObjectContext (or similar) and can then later be accessed by
the other views.
What I mean, is that one operation of narrowing down the set of data
will be held so that a the next operation executed is now only
executing on that narrowed set. This would mean that each of my views
didn't need to communicate with each other, instead they would perform
their "narrowing down" on the core data set, and then hand control
back to the MainWindow, which would then use only that narrowed down
set for the further activities.
If you have made it this far, congratulations! I know this is a mess,
and I am sure there are plenty of you who are upset with me for going
about this all wrong. I am sure a lot of people will disagree with the
outlined workflow, and be able to suggest better ways, but I am for
now primarily interested in solving this technical challenge, as this
app will mostly be for personal use and it's main purpose is for it to
be a learning experience for me.
This is also my first post to this community, so if I apologize if I
have broken any written or unwritten rules. I hope someone will be
willing to offer some advice, or partial solutions; and please let me
know if parts require further explanation, or perhaps a diagram to
clear things up.
Thanks for your time,
Chris
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden