Heyho,
as we talked already with some people about application management in
FSO we should now start discussing this in the public and define some
spec with all features we want in the end.
I will start here with explaining my ideas. First of all we need a
daemon doing all the application management. I think we should call it
simply fsoappd. The daemon manages all things we have in mind with
applications (btw. we should define what an application exactly is!).
There is the lifecycle management of applications. An application has
always a state which identifies the application as running, inactive or
whatever. To come from one state into another one there are possible
events (pause, hide, destroy, ...) which let the application change its
state (for example, the wm choose another app to become visible, so the
current app will get paused). We should define some rules an common
agreements all application should share so we can keep our application
management simple.
Furthermore we need a way applications can communicate between each
other. My idea here is to define common interfaces an application can
implement. For example the org.freesmartphone.Dialer interface. The
interface describes which DBus methods/signals should be implemented by
the app. If one app needs the dialer, it requests the dialer via the
fsoappd by a method called Request("org.freesmartphone.Dialer"). Each
application has a file appinfo.config file where it defines which
interfaces it implements. The fsoappd now searches through all
appinfo.config files (they should be stored by each application in one
common place) and tries to get one which implements the requested
interface. If there is more than one fsoappd looks in a priority list
which defines priorities for each interfaces (e.g. there are two
dialers, one provided by SHR and one by a independent developer. The
priority file now defines that the SHR dialer should be choose with
higher priority than the other one ...). Finaly fsoappd starts the app
for the requested interface in a not visible state. The app which
requested the other app to start can now chose what it wants to do with
the recent started app. Maybe it calles org.freesmartphone.Dialer.Show()
to show the dialer application so the user can enter a number and call
somebody.
The application interface should be defined as xml spec somewhere. If an
app does not implement any interface it should define at lest its name
in the format like org.mycompany.mygreatapplicationname. The
Request(...) method now looks even for an app called like the interface
name is set.
As the application interface implementation is available as xml we
should even provide a lib called libfso-app which implements all the
interface in vala or your favourite language so you can easily use it.
So far from my side. I have some more ideas, but will need some time to
write them down.
regards,
morphis
Btw. there is already a brainstorming page in the FSO wiki about
application lifecycle management:
http://wiki.freesmartphone.org/index.php/Brainstorm/LifeCycle and
http://wiki.freesmartphone.org/index.php/Brainstorm/Launcher
_______________________________________________
Smartphones-userland mailing list
Smartphones-userland@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
