Al Johnson wrote:
> 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.
On my desktop Ubuntu, and when I had a HTC Hero Android phone, that was
dealt with by asking the user which of the options should be used to
complete the action, and giving a toggle button to make the chosen
option the default. You'll then need a gui to edit the defaults, of course.
Just out of interest how many apps are we talking about? There is a core
of framework DBus interfaces already spec'd more or less. I say more or
less as I'm sure that they will be changing. (I'd have thought that
maybe opimd would be augmented with calendar entries, but I maybe wrong)
This core framework interface definitions need to be added to with a
number of *Interesting apps* and then there are a million apps which
we're probably not interested in at all. I'm thinking about games and
the like. Maybe when the framework receives a call a game could handle
the DBus signal and pause the game but that's down to the app handling a
broadcast signal.
Apps we're interest in I would think are the:
Calendar app
email client
music player
Having said that if I received an SMS with an email address in it I'd
like to be able to click on the address and get the option to send an
email to that address but is that perhaps not a part of the apps out
there already. Apps are already integrated in the linux desktop to a
pretty good level. Click on a web link in an email and the browser does
it's magic. And vice versa click on an email address in a web page and
get the email composer window.
>
>> 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
