Central tagging

[Peli]

We have not worked on Central Tagging for a long time, but wonder if
we could take a fresh start on this:

People are asking for the possibility to put notes into categories, or
to "tag" them.

KISS would be simply to add another field "TAGS" in the notepad
provider which is a comma separated list of all tags, e.g. "work,
important". Quick and easy.

On the other hand, we have central tagging:
* Main advantage: One can manage all tags in a central place, and find
tagged content across application boundaries.
* Main disadvantage: Includes some overhead (each application has to
query central tagging for tags through an URI), and early versions we
had in earlier SDK turned out to be slow :-(

So I wonder whether we should take a hybrid approach:
* Each application could store tags to its data in its own database,
simply as comma separated list of tags.
* The central tagger would collect these tag informations and store
them centrally so it can display all content for a specific tag.

Drawback: Information is stored redundantly (in each application, as
well as in the central tagging app). Then again, tags are really
short, so storing "work, important" does not take more space than
storing "content://org.openintents.tags/tags/13".

Syncing between central tagging and applications could be done through
(soon) existing broadcast intents (RESUMED, INSERTED, MODIFIED,
DELETED).

What do you think?

Then I would simply proceed by adding another field "tags" to notepad
and shopping list, in an upgradable way.

Peli

[Friedger Müffke]

Yes, that sounds like a good plan.

The main problem for central tagger is to display the content. How does the tagger know which information to display for a particular content type? For example for music, pictures, lists and notes?

Currently, it is stored in an xml file of central tagger, i.e. extensions are only possible through updates of central tagger. Do you see any possiblity to do some kind of plugin mechanism?
One idea is:
1) Central Tagger sends a broadcast event: "Give me your display information" when the users says "Search for new apps".
2) All apps that support Central Tagger reply with a service intent(?) to the Central Tagger

Does this make sense?

Friedger

2008/12/2 Peli <peli...@googlemail.com>

[Peli]

Yes, it would make sense if each application is responsible for
providing this.

It could be an intent
GET_DISPLAY_INFORMATION + content URI
which returns in the extras a short description and an icon (generated
bitmap or icon URI), maybe also the list of tags.

(This would be a general intent that could also be used in other
applications: E.g. in an extended Notepad where you want to embed a
content URI -> so an icon and a short description could be displayed
to the user).

I still wonder what the ideal form of intent would be for messages
like these:
The best would be startIntentForResult() because it returns a result -
but I don't know how much overhead all the activity creation involves.
Maybe it is not really so much if onCreate() calls finish() already -
but it has to be tried out.

Next would be sendBroadcast(), but the receiver needs to send a
broadcast back (but this could be directed to a specific package).
Probably this is more lightweight.

I think service is by far the most involved way, so we should avoid it
unless it is really necessary for performance reasons?

Since it is the same issue here and for crypto intents, we should
really research which of these 3 possibilities offers best ease of
implementation for good performance.

Also, we should define new base fields, like "_ID" for the content
provider: For example "_TAGS". Then Central tagger could access and
modify the tags of different content providers in a similar way...
wait, it would need the permission for each application, so still
sending intents for any modifications is probably the safer way.

Peli

On Dec 2, 10:19 am, "Friedger Müffke" <fried...@googlemail.com> wrote:
> Yes, that sounds like a good plan.
>
> The main problem for central tagger is to display the content. How does the
> tagger know which information to display for a particular content type? For
> example for music, pictures, lists and notes?
>
> Currently, it is stored in an xml file of central tagger, i.e. extensions
> are only possible through updates of central tagger. Do you see any
> possiblity to do some kind of plugin mechanism?
> One idea is:
> 1) Central Tagger sends a broadcast event: "Give me your display
> information" when the users says "Search for new apps".
> 2) All apps that support Central Tagger reply with a service intent(?) to
> the Central Tagger
>
> Does this make sense?
>
> Friedger
>

> 2008/12/2 Peli <peli0...@googlemail.com>

[Zero]

there's a (strange ?) idea floating thru my head for a while now.
central tagging could be a killer feature for the platform, but
only if it gains enough support by applications. so i wonder
if we should contribute it to the android framework. that way,
"everybody could enjoy the wonderful world of tagging" ;)
what do you think ?

[Friedger Müffke]

Any ideas where to add what? Should it be an external app? Or part of framework? An external app could also live in OI code. So, how would the framework benefit? Shall we add a CategoryView, ...?

Friedger

[Peli]

Seems like the Android team is going the other way: They have all
their basic applications tied too closely to the base framework, and
now the try to cleanly separate them so that other developers can
replace components by their own versions.

Also, for a central tagger, it could make sense to leave the end user
the choice whether they wanted to use OI Central tagging, or someone
else's Central tagging. All that is necessary for this to happen is to
have a clean interface with well-defined intents.

This would be the route that we also go with encryption: With a
handful of encryption intents, APWS (Android Password Safe) and OI
Notepad will work together, and each of the parts would be replaceable
by an alternative that supports the same intents (e.g. instead of
Notepad there could be shopping list or a picture viewer, and instead
of APWS it could be BioWallet).

So I'd say it is the best that each application can keep their own way
of storing tags (as many applications will already do), and there
should be a few interfaces through open intents that a Central tagging
application (be it OI Central Tagging or any other tagging solution)
may use to collect all existing tags and present them to the user in a
coherent way, with the ability to mass-organize tags (rename, search,
synchronize, etc.)

Peli.

On 28 Dez., 11:57, "Friedger Müffke" <fried...@googlemail.com> wrote:
> Any ideas where to add what? Should it be an external app? Or part of
> framework? An external app could also live in OI code. So, how would the
> framework benefit? Shall we add a CategoryView, ...?
>
> Friedger
>

[Zero]

actually, i think it should be part of the framework,
similiar to the Mediastore. essentially it's the
contentprovider and some code to collect
existing tags from other datasources on the device
thru an interface (like the mediascanner does for audio)
on top a few intents to add, delete, pick a tag.
everything else like the tagbrowser, tag cloud view etc
is an external app that can be replaced by whatever fits
the user best.
the benefit of having the core parts in the framework are
that it enables the developers to use tagging for more
complex solutions (like syncing and such), without
the need to include external librarys in the project.

[Friedger Müffke]

I agree with Peli that even the content provider could be replaced by a different implementation. So, the first step is to define the intents and then start from there a standard implementation. The intents would go into the framework, the implementation in an external app, wouldn't it?


Friedger

[Peli]

Indeed, somewhere I read that third party apps could replace the media
content provider or even the contacts content provider (but I don't
know if the current system allows this already, or whether those
components are still too closely tied to the base framework).

Yes, the intents would go into the framework. Then again, that is only
a class of static strings, so it is also not a big deal to include
them manually in every application for now, and suggest that for
inclusion in the framework later :-)

The big question: How can we start in the easiest possible way with
minimum definitions but maximum benefit?

For crypto, it was just 2 actions and 1 extra:
http://code.google.com/p/openintents/source/browse/trunk/NotePad/src/org/openintents/intents/CryptoIntents.java
http://code.google.com/p/android-passwordsafe/source/browse/branches/service/PasswordSafe/src/org/openintents/intents/CryptoIntents.java

The first step is to collect all tags, and display all content in the
tag browser.

Similar to MediaStore with MediaScanner, it would be good to have an
intent to collect all content.

* org.openintents.action.UPDATE_ALL_TAGS: Broadcast intent sent from
CentralTagging to all listening applications.
* org.openintents.action.TAG_UPDATED: Broadcast intent sent back from
an application to CentralTagging whenever a tag has been updated, or
after UPDATE_ALL_TAGS has been received.
* org.openintents.extra.TAGS: Comma-separated string of tags.

getData() is the URI of the content to be tagged, while getType() is
the MIME-type (which is helpful to display an icon or perform the VIEW
action on the data).

Example:
CentralTagger sends: UPDATE_ALL_TAGS.
Notepad answers:
TAG_UPDATED: content:org.openintents.notepad/note/1 "fun"
TAG_UPDATED: content:org.openintents.notepad/note/2 "fun,home"
Shopping list answers:
TAG_UPDATED: content:org.openintents.shoppinglist/list/1 "important"
TAG_UPDATED: content:org.openintents.shoppinglist/list/2 "fun"

Later, if notepad tags a new note, it just sends
TAG_UPDATED: content:org.openintents.notepad/note/3 "private"

Then tag browser could already display:
"fun": note1, note2, list2
etc.

Depending on performance, we may later introduce an extra limit on
UPDATE_ALL_TAGS (e.g. send back max. 100 entries), or have
TAGS_UPDATED which sends back arrays of content and tags (to be more
efficient).

Passing "" for the tag means that a content does not have a tag, and
passing null may mean that the content has been removed. (Or this
could be a separate action: TAG_CONTENT_DELETED?)

This is so far a quick draft, so suggestions for improvement or
alternative proposals are welcome :-)

Peli

On 29 Dez., 00:07, "Friedger Müffke" <fried...@googlemail.com> wrote:
> I agree with Peli that even the content provider could be replaced by a
> different implementation. So, the first step is to define the intents and
> then start from there a standard implementation. The intents would go into
> the framework, the implementation in an external app, wouldn't it?
>
> Friedger
>

[Peli]

> the benefit of having the core parts in the framework are
> that it enables the developers to use tagging for more
> complex solutions (like syncing and such), without
> the need to include external librarys in the project.

The question is whether it is possible to perform everything using
intents only. If intents are sufficient then there is rather little
overhead in each application necessary.

If the performance is not good enough, and one needs to use services
or include custom libraries in each application, then of course it
would be better to have these parts in the core framework.

So the question is whether it is possible to organize a central
tagging through simple intents only, and whether this can be made
quick enough so that the user does not have to suffer poor performance
when browsing through cross content tags.

Peli

[Zero]

now i see where youre going, thats a cool way to do things.
i think we would need another intent
QUERY_FOR_TAG , with an extra QUERY_TAGS
(csv list of tags)
to get back only data for some tags, otherwise
performance may drop. (this implies
that no information is cached for the tagbrowser,
if there is a content provider it can be asked
directly of course)

[Zero]

on a side note, i'd like to do the exact same thing for ratings (x out
of 5)
could be handled by (almost) the same code.

[Peli]

wow, that is a cool idea :-)

Peli

[Peli]

I also like your comment on the shopping list locations:
http://code.google.com/p/openintents/issues/detail?id=11

Things could be made very expansible and replaceable, if each app
stores the geo: coordinates, and then queries a central location
provider for a fancy name, i.e. home or work or shop, through
intents :-)

Peli