Re: flow of control for sequential data processing
Re: flow of control for sequential data processing
- Subject: Re: flow of control for sequential data processing
- From: Ricky Sharp <email@hidden>
- Date: Mon, 18 Feb 2008 15:31:30 -0600
On Feb 18, 2008, at 1:01 PM, Daniel Child wrote:
A while ago, with much help from the community, I set up a test app
with a central controller and various peripheral window controllers.
The central controller kept references to the other window
controllers, and loaded each only when needed. The window
controllers could in turn communicate back to the central controller
using the fact that it was the NSApp's delegate. That worked fine
for that particular application since the flow of work logically
centered around a central location.
But now I have a different scenario.
I want the user to perform a series of tasks on some data in a
particular order, and each task has associated with it a controller
and a model to handle the persistent data. Something like:
[Controller A / Model A / perform step 1 tasks] followed by
[Controller B / Model B / use results of step 1 to perform step 2
tasks] followed by
[Controller C / Model C / use results of step 2 to perform step 3
tasks] etc.
where each controller is associated with its own interface and with
a certain data model layer. The data is being processed in each
step, and is then passed along to the next step for further
processing. Thus, for instance, once you have done the first step,
there is no reason to return to the interface provided by Controller
A.
In each controller, I have been setting up references to the
controller used in the following stage, and then sending data long
with it. But I think this is going to be a problem in terms of
memory. If Controller A has an instance variable of type Controller
B, then if you "load" Controller B for it to do stuff, that loading
is done from within the context of A. How do you release A? If you
load B from A (B being an instance variable of A), then releasing A
is problematic because you are within the context of A.
I feel I'm stuck with a choice between a continual memory buildup or
circular references. And the way I keep passing bits of the model
around from one controlller to the next makes me think that the
design is flawed....something monstrous dish that resembles a cross
between lasagna and spaghetti.
Is there a better way to handle this kind of sequential data
processing from a design standpoint? Thanks.
I would create another (fourth) "master" controller. It's job would
be to manage what step is currently loaded as well as to manage
parameters/results between them. This master controller could even
be your application controller itself. And, if parameters/results
need to be passed around from step to step, consider using a dictionary.
In my kiosk-style app, I do this quite often where my app controller
loads a particular screen for the user to interact with. Some screens
are "pushed" onto a stack and I thus have multiple controllers in
memory. But, for the most part, stack just has a single entry;
allowing me to effectively swap out controllers one at a time. I then
created a single header with extern NSStrings to represent the keys
into the "parameter" dictionary passed from screen to screen.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
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