There are 2 answers to your question.
In the mastermind movie, at that point we see attaching app routines as
being part of a task description. I think we abandoned that idea. At least
I did. I don't think I talked to anyone explicitly but Spencer.
We think a clean way would be to specify a routine call in what I called an
application task, of which description has to do with the method of which
object class to invoke. The task description will also need to be
parameterized, so the actual object (whose method is to be invoked)
is resolved at run-time through parameters. Designers insert application
tasks in the task hierarchy. Certainly, this will make a task hierarchy
bigger. Given that designers maybe able to switch views to look at user
tasks only, app tasks only, or a combination, I think it's okay.
I designed the task model that way. I think it is clean, and will make
applcation calls independent of any particular interface styles.
Designers can also make it so a whole bunch of routines can be called and the
order can be specified just like in tasks. Also, deleting a task from a
hierarchy will not pull out information like app calls without designers
knowing it. (I can imagine myself forgetting that an app routine is embedded
in a task, delete the task and regret later when I look for it.)
Lately (actually 3-4 months ago at least), Pedro has been talking about
expressing an application call as part of task effects. I don't quite
like this approach for the same reason above. Perhaps Pedro didn't
understand what application tasks are for. (Pedro?) I remember mentioning
the above solution at some point to Pedro, but I'm not sure he heard me. :-)
Expressing app calls as task effects might be handy at a lower-level like
interaction techniques (which are also tasks) ...I don't know. I feel
that attaching app routines shouldn't be part of effects because expressing it
there doesn't say anything semantically about the effect. It just says this
routine is to be called. It feels more like a hacked place to put it.
Thinking planning (for help) wise, that will add one more non-semantic item
into the search space. We haven't resolved this issue yet.
Of course we'll also have to worry about how app routine call at the
rubberbanding level will be translated to Amulet implementation. This
might call for a different way to handle app routine at this level.
I can't say that yet since I don't know Amulet real well yet.
I hope I answered your question.
--Noi