On 8/13/07, Jeff Andros <[EMAIL PROTECTED]> 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. _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
