User Interface idea

[Derek Pressnall]

On 8/13/07, Jeff Andros <jeff at bigredtj.com> wrote:

> um, do realize that we are working on a resource constrained system, and
> probably will be for the forseeable future... I don't see this as TOO much
> of a problem, as long as those apps unload most of themselves from memory
> when they're not running, and they spend almost all of their time
> sleeping... but watch out for that.

What I meant was that apps that would be "in use" would be split into
a piece that runs in the background, and a forground part that talks
to the display / input.  And the background part would only be running
when needed.
Now the phone app would always have a module running since it has to
listen for incomming phone calls.  The UI portion of the phone app
that uses the "phone desktop" would be the default / primary app that
is always available on it when nothing else is running (so that when
you switch to the phone desktop, you can start dialing out without
having to launch a "phone app").  This UI would be smaller than the
pda-desktop version of the phone UI, since it doesn't have to worry
about drawing input buttons, etc; it talks to the already running
keypad app taking up the bottom half of the phone-desktop display.
However the UI frontend that is used from the pda-desktop side would
have a bit more code since it is responsible for it's own keypad, and
possibly takes care of more display items.

The Media player app could have a background piece that only run when
it is in use.  Again, it doesn't have any user interface components,
only an API for a frontend to talk to it.  The user can still "exit"
the app for both the frontend and backend to exit memory, but it will
go into pause mode if a higher priority app (such as the phone app)
needs a shared resource (the speaker).

This way, only the modules that are needed to be in memory are taking
up ram, and launching the (small) frontends seperately / in parallel
can give a snappier performance feel.