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.
>
>> 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.
>
Just looking through the links provided in the original email and not
sure I like or agree with the use case on the bottom of the lifecycle page:
Trucker Joe is on the road and gets a phone call, but he's lost in
$(TOWN) without navit, and navit supports answering calls. instead of
bringing navit to background, it show OSD buttons to answer the call.
That's expecting navit to start implementing functionality which it
really should have no interest in. Navit should do what it does well and
leave phone calls to apps that do that well. Given that there is a
window manager in the phone could the incoming call not provide a small
popup to accept or decline if the screen is in use by another app.
Once the call is accepted we have a problem of does the call take
control of the screen or not. Actually there is no reason for the call
to need the screen at all, apart from if the user wants to inject dtmf
digits on the call using the keypad, in which case the screen is
required. I suppose given that volumes and speaker phone are options
that could be selected as well there's more options but ultimately I
think the user has to be able to select. It's a pity that the FreeRunner
don't have a few more dedicated buttons like the android phone where you
can press and hold the home button to select the active app you want to
look at, and switch between the windows. All that's really required is a
simple and effective way of switching between active apps. At present on
SHR that's the <x> on the top menu. I've not tried it but I assume if I
launch an app at present and answer a call I can still use <X> to go
look at the screen I want to. I must try that out.
_______________________________________________
Smartphones-userland mailing list
Smartphones-userland@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
