About Context Aware Applications
Emanuele Leomanni
emanuele183 at gmail.com
Wed Jul 2 10:50:39 CEST 2008
Thanks Guillaume,
I like the idea to extend the concept of profile manager to a more wide
context environment.
What I think could be better designed is the use of a configuration file per
application, per profile.
That is a good approach, in my opinion, if you have a fixed and low number
of profiles, but if you create a new profile for each context it could
become a bit unusable and not so scalable.
Moreover in 'Intuition' context information about location are taken from
GPS coordinates and not from fixed profiles, so if you are in Paris and you
click on keyword "Tour Eiffel" next time you will be near Tour Eiffel that
keyword will be put at the top of the results even if a profile 'Tour
Eiffel' or 'Paris City' do not exist. I think it is more general.
How to cope with this?
== Intuition ==
About my program, in order to run it you need not only to compile Geoclue
and Spatialite extension for Sqlite3, but for a better test you need also to
create some fake sqlite3 database and fill it with some values (I have used
this approach just to test the engine). You must also change some defines
into 'defines.h' to fit your needs.
Following there are the tables that I have created to test my application
(they are two files 'experiences' and 'input'):
EXPERIENCES
CREATE TABLE experiences (
id integer primary key,
kw text,
position integer,
plugin text,
time text,
location BLOB NOT NULL
);
INPUT
CREATE TABLE contacts (
id integer primary key,
name text,
surname text,
number text,
icon text);
CREATE TABLE extra (
id integer primary key,
place text,
UNIQUE(place));
CREATE TABLE coordinates (
id text primary key,
location text,
latitude text,
longitude text);
CREATE TABLE default_items (
id integer primary key,
name text);
CREATE TABLE calendar (
id integer primary key,
event text,
date text);
CREATE TABLE files (
id integer primary key,
file_name text,
path text,
UNIQUE(file_name,path));
CREATE TABLE apps (
id integer primary key,
app_name text,
exec text,
UNIQUE(app_name,exec));
I have already tested my application on GTA01 but I have first crosscompiled
Geoclue and Spatialite by myself on the device. As it is not something fast
to do you can try to compile it on your desktop first.
Emanuele
2008/7/2 Guillaume Chereau <charlie at openmoko.org>:
> Hello Emanuele.
> First, let me explain the current idea behind the profile system :
>
> Right now I am focusing on a preferences service that is aware of the
> profile. That is, applications don't need to care about the current
> profile, they just access configuration values, and the preferences
> service will return the value corresponding to the current profile.
>
> The way it works is by having one configuration file *per application,
> per profile*.
> For example if you have an application dialer, and an application
> message, and 2 profiles : default and silent. You will have 4
> configuration files :
> conf/dialer/default.conf, conf/dialer/silent.conf,
> conf/message/default.conf, conf/dialer/silent.conf
>
> So the preferences service needs a way to know the current profile (for
> the moment it is just a value you can set) and will chose which file to
> use depending on it (you can also specify that a parameter don't depend
> on profile, and then it is always taken from the default conf file)
>
> == How it can be extended to your context idea : ==
>
> Instead using a single profile value, the preferences service could use
> a list of activated context (and then the profiles would just be special
> cases of contexts)
> Then we store one conf file per context e.g :
> conf/dialer/default.conf, conf/dialer/silent.conf,
> conf/diler/at_home.conf, conf/dialer/near_train_station.conf, ...
>
> And then the preferences service will try to get the parameter from the
> list of activated contexts files.
>
> The context service will be used to provide the list of current
> activated contexts (this is your central manager daemon)
>
> For the roadmap : I think first it is important to have the preferences
> service working correctly, and to have zhone use it.
> Then we can start to implement the context service.
>
> Let me know what you think.
>
> == Intuition ==
>
> Sorry, I didn't try 'intuition' yet. For that I need to see how to
> install geoclue and spatialite on OpenMoko.
> Still I'd like to give a try, Did you run your application on an OM ?
> Or is it possible to test the app on desktop ?
>
> -charlie
>
> On Tue, 2008-07-01 at 17:43 +0200, Emanuele Leomanni wrote:
> > Hi all,
> > I have read some suggestions about context aware applications
> > (
> http://lists.linuxtogo.org/pipermail/smartphones-standards/2008-June/000093.html
> ).
> >
> > I like a lot Steve's proposal on the wiki
> > (http://wiki.openmoko.org/wiki/Proposal_for_context_management) and I
> > think that the right approach to make developers life easier on
> > developing context aware applications is to decouple a signal manager
> > daemon and the application GUI that exploit it.
> >
> > See this image for more details:
> > http://www.bitbakery.org/~lele/daemon-approach.png<http://www.bitbakery.org/%7Elele/daemon-approach.png>
> >
> > A central signal manager daemon, in my opinion, should be able to
> > collect and analyze all the low level context signals sent on D-Bus
> > (like GPS coordinates or signals from the accelerometer) in order to
> > create an higher level context signal set (not only based on profiles)
> > that is more useful from a context developer point of view.
> >
> > Possible examples of High level signals are:
> > * profile changed
> > * position changed
> > * city left
> > * user on movement
> > * user is fix at one point
> > * user in a meeting
> > * bluetooth neighbor detected
> > * wifi connection found
> > * gprs off
> > * low battery
> > * user is calling
> > * call received
> > * etc...
> >
> > Inside this way of thinking come up my effort for the community:
> >
> > I have developped a Context Aware Search Engine application with the
> > intent of making easier local and remote researches on Openmoko
> > device.
> >
> > My application is divided into a daemon (the real core) which loads
> > and manages all the keywords needed into the engine. It takes care of
> > computing a rank value for the keys inserted basing on context
> > information (for the moment just time and gps coordinates).
> > The goal is to retrieve the results on user input ordered by context
> > importance. So, just to give an example, if you are near the main
> > train station and you enter the key 'T' it is more likely to have as
> > first results the keywords "train" or "taxi" rather than "tomorrow
> > meetings".
> >
> > This daemon called "Intuition" comunicates via D-Bus providing the
> > applications a 'lookup' method and some signals in order to retrieve
> > back the results requested.
> >
> > In my implementation I have also developed a simple GUI to test the
> > engine and I have provided a plugin header file to let developers
> > adding their own plugins to improve the capability of the search
> > engine (actual plugins implemented are 'contacts','calendar','default
> > items','file search','application search').
> >
> > It is still a simple prototype but I hope it could be useful as a
> > starting point for further implementations.
> >
> > The sources are available here:
> > https://www.bitbakery.org/svn/intuition/
> >
> > Emanuele
> >
> > _______________________________________________
> > smartphones-standards mailing list
> > smartphones-standards at linuxtogo.org
> >
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
>
> _______________________________________________
> smartphones-standards mailing list
> smartphones-standards at linuxtogo.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxtogo.org/pipermail/smartphones-standards/attachments/20080702/e545e562/attachment-0001.htm>
More information about the smartphones-standards
mailing list