Simon Busch wrote:
> 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
Seems to me that some of the functionality you mention of searching for
apps which implement a certain interface is already built into DBus
itself. All that remains is to define the minimum interfaces that a
certain application type must implement. An app is free to augment that
list if if requires but there is a minimum set that a Dialer app must
implement.
I'll try to go through those links but I would also say that the android
method of displaying information on the screen is a very good idea. At
present my shr-u phone just displays the apps I have installed, by
default. I don't really consider that to be useful information. HTC's
overlay stuff for android which lets an app display facebook updates or
weather updates or share price updates is a good mechanism of displaying
actual info. Maybe that's already in the links like I say I'll have a
look at them later today.
_______________________________________________
Smartphones-userland mailing list
Smartphones-userland@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
