AlertProvider

[friedger]

Hi,

I think we should include an alert provider in the release 0.1.5. Is
anybody working on it? To start with I would store the location based
alerts in a table, containing the location uri (e.g.
content://org.openintents.locations/location/1), the picked Intent
consisting of type and action and optionally a uri.

To start with there wouldn't be any logic for in and out.

I might try to get something working on Monday if nobody else has
already done it.

Friedger

[Peli]

Releases 749 to 754 are titled "Alert Framework KISS 0.1", by Zero:
http://code.google.com/p/openintents/source/list

So you should coordinate with him, I guess.

Peli

[Zero]

right, i've got you covered. :)
from the discussions wiht peli,
i designed a "generic" alert framework.
one table holds all kinds of alerts, so they share the _id space.
different types can be accessed thru diffrent uri.
atmthis is only
org.openintents.alert/generic
org.openintents.alert/location
while generic is the main datatype all the others are
derived from.
(actualy it's just a matter of renaming the public fields
to something more convenient.)
atm wheres the follwoing generic fields:
_id|_count| type | condition1 | condition2 | rule | nature | active |
activate_on_boot | intent | intent_category | intent_uri

in the type location this maps to
_id|_count| type | position | distance | rule | nature | active |
activate_on_boot | intent | intent_category | intent_uri

some of these fields are for further expansion at a later point in
time.
rule will be a rule to combine several alert into one complex, the
alert type for this is "combined"
activate_on_boot speaks for it self, i'll hope to make a service that
register all marked alerts on system boot.
nature is one of "user" or "system" (defaults to "user" if not
given).
this is because some apps might not want he user to see tall their
alerts, might not be usefull.
an list of all alerts in the core with type generic would still be
able to show them, all other lists
should only show "user" alerts.

the contentprovider itself should be working already, ill hope to have
a list and an add activity
for generic alerts by tuesday. (lot of work for university right now,
so coding progress is slow :/ )

things still unclear;
-are 2 conditon fields enough?
-how to store time/date alerts? codition1=date conditon2=time ?
-rename intent to intent_action ? cause that's what it realy is, i
guess.

[Peli]

Great concept.

About your last question:
I was just thinking of a more general concept that could hold an
arbitrary number of conditions (like splitting it in 2 tables, where
one table holds the conditions that are linked to an alert by the
alert_id to the alerts in a second table), but then again maybe this
is too much effort without too much gain.

If we ever need a third condition, it would be easy to include a third
field, or store all conditions in the first condition string,
separated by a special delimiter.

So, I'd keep the table as it is, and rather put emphasis on building
something on top of it :-)

Peli

> > > Friedger- Hide quoted text -
>
> - Show quoted text -

[Assim]

Hi All,

I am new to this group. I am having an idea for GSoC which is very
similar to this http://groups.google.com/group/android-challenge/browse_thread/thread/80c39bb645964038?hl=en).

I have a suggestion regarding this. Rather than creating a long
condition table we can club up all the similar looking conditions and
create a template for those conditions.The template would contain
replaceable variables whose value would be replaced accordingly.

e.g. - A condition is such that it is true if an activity is running
else false. So rather than creating a row for each activity ( i.e.
Calender.IS_RUNNING, NotePad.IS_RUNNING etc.. ) we can create a single
row like $ActivityName.IS_RUNNING. In this $ActivityName is a variable
name whose value would be replaced according to the triggering
activity or according to the alert/s mapped to this condition.

I faced a similar problem once and this was the trick I used. I hope I
am making sense here.

Regards
Assim Deodia

[Peli]

Hi Assim,

Thank you for your interest in our project. Regarding your remark, I
don't think I fully understand what you mean. Do you mean, your
suggestion should make the SQL table easier? Or was this a general
suggestion, not necessarily connected to SQL? If you could make your
suggestion more explicit that would be helpful.

Peli

On Mar 24, 3:15 pm, Assim <assim.deo...@gmail.com> wrote:
> Hi All,
>
> I am new to this group. I am having an idea for GSoC which is very

> similar to thishttp://groups.google.com/group/android-challenge/browse_thread/thread...).

[Assim]

Hi Peli,

I have given a very abstract idea as I am not familiar with the actual
implementation. What I suggested is the use of condition templates
instead of actual conditions. It is w.r.t. the SQL tables in which
condition data are be stored. I have implemented this method in one of
my research related work on privacy policy implementation. In that
case all the policies which are to be implemented were decided by some
condition e.g A doctor can view patient profile(this is the policy)
if he is the doctor assigned to patient (this is condition). So rather
then saving all the doctor:patient pair we use the template $docID:
$PatiID and these values were replaced with the actual data on run
time.

I am sorry for being off the topic, but I thought this would be better
way to explain. I have made a small demo of this also. If this method
interests you and can be useful in further development I would be glad
to show you the demo and help you in further.

Regards
Assim Deodia

[Peli]

Hi Assim,

Thanks for your explanation. I still don't get the point completely,
although I would really like to understand what you are doing:
Even if you have a general relation $docID:$PatiID, don't you still
need to store the information that you call "actual data at run time"
somewhere? So where do you store the information and how is it
different to having a sql table "docID, PatiID"? Or could you give a
small more general example where the advantage of your method could be
obvious? (like what are the other "relation templates" that are
possible that are not covered by a simple sql table? and how do you
store information there?)

It is just, you made me curious, and I'd like to know what I don't
understand yet with your method...

Peli

[friedger]

I tried to implement an "add alert" to the location list. Currently,
the pick intent does not always return an URI. Instead it might be a
mime type. So, there should be an INTENT_MIME_TYPE column as well.

If there is a task I can take over please let me know.
Friedger

[Zero]

since you asked.. ;) i do have a little problem with the
AlertList activity. it only gets emtpy (null) cursors, like
the contentresolver does'nt call thru to AlertProvider.query(..).
but i just don't see why this is the case right now.
any hints are appreciated :)

[Zero]

i finaly found it. and despite some simple uri errors,
there is one thing i don't realy understand:
UriMatcher.addURI("my.authority", "", 1);
ain't going to match "content://my.authority" or "content://
my.authority/"

[friedger]

Hi,

UriMatcher.addURI("my.authority", "", 1);

specifies to match 2 tokens (the authority and the empty path)

UriMatcher.addURI("my.authority", null, 1);
specifies to match 1 tokens (the authority)

However, "content://my.auth" and "content://my.auth/" contains just of
one token (authority). There is no way to add an empty path.

So, UriMatcher.addURI("my.authority", null, 1); should do the trick.
Friedger

[friedger]

Looking at the latest revision (793),
is there a specific reason why you have introduced a new action name
for INSERT and EDIT?
Friedger

[Peli]

I noticed also today that we have introduced unnecessarily new mime
types for dir and item:
See issue 61.
http://code.google.com/p/openintents/issues/detail?id=61

Peli

[Zero]

i just wanted to differentiate between generic alerts and location,
time,...
probably should have used the mime type for this.
ah, well. after having some sleep it becomes much clearer.... ;)

On Mar 27, 11:22 am, Peli <peli0...@googlemail.com> wrote:
> I noticed also today that we have introduced unnecessarily new mime
> types for dir and item:

> See issue 61.http://code.google.com/p/openintents/issues/detail?id=61

[Peli]

There seems to be a small typo in the last code you checked in:
AlertList.java, line 199, _id seems not to be known. I replaced it by
"i". Since this seems to work, I'll also incude this in the 0.1.5
release.

Peli

> > > - Show quoted text -- Hide quoted text -

[Zero]

ooops. thanx :)

[Zero]

now we have working proximity alerts. it's still a bit complicated to
use,
but i see the events coming in at the logcat.
easy (?) way to try this: from the alertlist, run the debug service.
copy & paste some of the locations in your logcat into an generic
alert, setting type
to location. wait for intents coming in.
you could do a reboot of the emulator now as well, alerts will be re-
registerd after
boot.
next thing to do is some smooth and easy way to add these alerts. :)
and if anyone has proposals to an nice date/time string format,
please post them.

[Peli]

It seems you have not checked in your latest
org.openintents.provider.Alerts.java

(for example member function init() is missing... )

Peli

[Zero]

gnaa. stupid late-at-night-errors. :/
should be working now.

[Peli]

Ok, now it works. As I wrote in the other post, it would be good to
put final effort into the usability.

As for time, for now you could simply take "time:epoch/123456789"
where the number is the usual number of seconds since 1970. Then there
is no conversion necessary to put this into the alarm controller.

Peli