myApplication info. Where is the good place?

Hi,

I am stuck with the followings:

Let's say I would like to show some application informations (like
application name, version...) both in the starting splash and in the
about (sounds familiar, doesn't it...).

Now: In my world these infos belong to the application (perhaps a
myApplicationInfo instance variable in the application model). It can
be a LookUpTable, or an Array, it is not the problem.

The problem is: If I put it into the model, then I haven't found a way
to reach it from the runtime sessionmanager for the deployed
myApplication (you can imagine, I tried such horrors like for ex. in
the runtime manager:
(self mainShellClass) model  myApplicationInfo
brrrr....

OK. I can put it as an instance variable into the Shell, which is then
the mainShellClass in the runtime manager, but again I cannot reach the
instance variables from there at the start of the deployed exe.

I tried lots of things, among others the most promising

self mainShellClass myApplicationInfo

complains that there is no such class side methods of myApplication...
and of course it has right: the myApplicationInfo is an instance side
accessor. No success.

Now: I can tell: OK. Forget it. The applicationInfo is not an
application info, but it belongs instead to the runtime manager.

I can put it into the runtime sessionmanager, and then the starting
splash shows it beautifully, only... I cannot reach it from the
application instance with my poor myAbout screen.
Not to speak about during the development, where the 'SessionManager
current' is far from the mySessionManager.

The bottom line is: It seems I must duplicate it: put one into the
runtime session manager, and put the other same one into the
apllicationShell (or model) so that I can reach them: one from the
runtime manager showSplash and the other from the application About.

Is there a way out of this?
i.e: is there a way to put my poor myApplicationInfo to a safe place in
the Universe, what I can reach form my runtime sessionmanager and from
my application instance?

Thank you,
Janos
P.S.: I have found one comlicated place which I do not like: I could
store it in a class variable in myAppShell, then I can reach it from
runtime manager as
self mainShellClass cMyApplInfo
(cMyApplInfo just returns the MyApplInfo class variable)
and from the myAppShell itself too.
But then you can imagine: after each change I have to save/load the
package, so that it will be re-initialized. And if I subclass the
myAppShell, then I think a class instance variable would be even
better, but this is already far above my present horizont.
Is there a better way to do this?

"Janos" <[hidden email]> wrote in message
news:[hidden email]...
>
> I am stuck with the followings:
>
> Let's say I would like to show some application informations (like
> application name, version...) both in the starting splash and in the
> about (sounds familiar, doesn't it...).
...
> Is there a way out of this?
> i.e: is there a way to put my poor myApplicationInfo to a safe place in
> the Universe, what I can reach form my runtime sessionmanager and from
> my application instance?

What I do, and have done for many years, is to have a class method on my
SessionManager.

For example, if my session manager class is called MyAppSessionManager, I
can add a class side method called versionString.  Then this version string
can be retrieved from anywhere in the program during development or runtime
with the following code:

========
MyAppSessionManager versionString.
========

It has worked well for me so far.

Chris

Hi Janos

> i.e: is there a way to put my poor myApplicationInfo to a safe place in
> the Universe, what I can reach form my runtime sessionmanager and from
> my application instance?

I am not sure if it is the best way, but I put all that kind of
information in the class side of my SessionManagers. IMO, that is where
it belongs. How I access it from a presenter depends on whether the
presenter is specific to that application or used by other
applications.

In general, to solve the runtime/development problem, I use a test
like:

^SessionManager current isRuntime ifTrue: [self findStuffHere] ifFalse:
[self findStuffThere].

Typically I use this test for security code (which is disabled during
development), or to find resources/files etc.

In your example, If the Shell is designed to only be used by one
application, I would just take the easy way out and add an instance
method like:

====
myApplicationInfo

^MyAppSessionManager myApplicationInfo
====

If the Shell is being used by more than one application, I would ask
the model for its sessonManagerClass. So in the Shell I would have:

====
myApplicationInfo

^self model sessionManagerClass myApplicationInfo
====

Exactly how the model knows its session manager class depends. It could
be hard coded in a method, or it could be set in an instance variable,
or it could use a "ConfigurationMap" object/pattern (that is not an
official name, it is just the way I think of it) which answers an
object that can answer the session manager class.

Personally I always just go with easy way out at the start. Down the
track, if I decide that I want to use the same Shell in another
application (and therefore need different captions and icons and text
etc), I then look into ways to make the model aware of what application
it is in.

Hope this helps!
Steve

Janos wrote:

> Is there a way out of this?
> i.e: is there a way to put my poor myApplicationInfo to a safe place in
> the Universe, what I can reach form my runtime sessionmanager and from
> my application instance?

Interesting that both Chris and Steve feel that this belongs in the
SessionManager.  They are both skilled and knowledable Dolphin programmers, but
I disagree with both of them :-(

Personally I'd put this functionality into a class-side method of my main
shell.  The session manager can then post the splash screen by doing something
like:

    self mainShellClass showInfoScreen.

and the (instance-side) implementation of #about in my shell would be just:

    self class showInfoScreen.

You might want to add complications, for instance #showInfoScreen might take an
optional timeout (which would be used for the splash screen but not for
help=>about), and so on.  But that's the basic idea.

A completely different approach would be to split this functionality out into a
separate class.  So the session manager and the #about method would both just
say:

    MySplashScreen show.

On the whole, I think that's cleaner.

    -- chris

Thank you all

for the helpful answers. The solutions are clear and simple. Now I can
find (more than) a safe place in the univers for my myApplicationInfo.

Thanks again,
Janos

"Chris Uppal" <[hidden email]> wrote in message
news:44587b76$2$656$[hidden email]... ...

I always enjoy different view points. ;)  Let me expand my own: One reason I
like to store version information in my SessionManager sub-class is that the
same technique works well for both GUI and headless applications.  Also, I
tend to feel that the version information is more tied to the application
than the GUI.  Just to be clear I am _not_ talking about code that opens a
splash screen, but just returns the version object.  To each his own. ;)

Chris

I agree with the points Chris (Demers) makes. I assumed Janos was
talking about things like the version string, copyright string,
product/company name etc etc.

Placing this information in the SessionManager is now a pattern I use
without thinking about. However, some use cases for why I find it
natural to put this information with the sessionManager would be:

 - You might want to access the information from multiple shells/top
level views ... a splash, your app's main shell and/or a specialized
about shell.
 - Your sessionManager might choose between two or more shells to open
... all needing access to that information. (for example a product's
trial is over).
 - You might expand on Dolphin's error handling (for example asking the
user to send you an error report). You would be doing this in or close
to the sessionManager and you probably would want to include version
information.
 - You might encrypt most of the compiled method's bytes in the app,
but you probably don't want to encrypt your sessionManager! If
something goes wrong early on, it is nice to be able to access the
version information and know it is not encrypted.
 - I also add a class side method to my SessionManagers, and
automatically update the stub's versionResource during stripping. This
could be done via my shell's class global, but the SessionManager seems
a more logical place to me.

FWIW: I also tend to show my splash from my sessionManager. Again this
is a pattern I use without thinking about, but it is handy in cases
where you need to load or initialize models before showing your shell.
You can put a valueModel into the splash and update it with progress ie
"Loading foo...", "Initializing foo..." etc.

Steve