On Monday 18 October 2010, Arigead wrote:
> 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.
That's what I was thinking, though IIRC tiy have to walk the tree looking for
the method rather than simply asking "what implements X?"
> 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.
There is also the matter of preference when multiple apps implement the
method/profile.
> 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
