Idea: Central News provider

[Zero]

Hi folks

actualy, this just comes from the project i'm working on. I decided to
code a newsreader app, cause it combines several different tasks like
displayin & networking etc, so I can get a feeling for the new
platform. A Contenprovider is the next step, and after stumbling
across this project, me thinks i could as well do it properly.
so i suggest the following urls:

(where $somthing is a placeholder for a value/variable)
org.openintent.news/rss?tag=$tagname/$channelname
org.openintent.news/rss?tag=$tagname/$channelname/items/$uid/
org.openintent.news/rss?tag=$tagname/$channelname/items/$uid/
[description|author|title|...]

org.openintent.news/atom <- as I understand it, this is the datatype,
so these should be different. also, there might be other formats in
the future.

what u think abou it?


Zero

[friedger]

Good Idea!
So an application can request feeds by using the provider or delegate
the viewing, etc. to another activitiy.

Indeed the path after org.openintent.news/ describes the type.
Usinging a query string make perferctly sense here.

However the list/item issue is usually solved by adding an ID after
the path, e.g.
content://contacts/ for list of contacts and
content://contacts/19 for contact with id = 19

So the equivalent would be
org.openintent.news/rss/$uid?tag=$tagname/$channelname

I think this solution is better as the query string always queries the
same feed.
Alternatively, you could add a &id=$uid to the query string.

I don't like the long query string with items you suggested because
the provider would have to analyse the querystring first before it can
decide which content to provide (i.e. list or item)

Friedger

[friedger]

Rethink about the urls.
There is a already a feed: URI scheme. http://en.wikipedia.org/wiki/Feed:_URI_scheme
Why don't using that?

If doing that a content provider is not the right think. Can you
insert/delete/query a feed? These are the methods of a content
provider.

Or, did I misunderstand. Do you want to store the urls of the feeds in
a data base so other applications can reuse the information, e.g.
which feeds the user is using?

Friedger

On 15 Dez., 16:10, Zero <r...@everymail.net> wrote:

[Zero]

there's two things i wanted to store:
- the feed url, combined with a name and some user specified settings
(like how often to check for it, etc..)
- the data that comes from the feed (a complete history or only the
last n items,depending on user settings)
with that, there would be a service querying the feeds and storing the
data. now other applications can do
something with that data, search it for keywords, display, redirect...
it will save a lot bandwith that way

rethinking about the urls, it seems more naturally to store the items
directly like you suggested, problem is
the $uid are only unique to channel. maybe the link of the item will
do the trick, that has a high propability
of beeing unique all the time even if the newsitems share the same
topic or even description.
so it would be
org.openintent.news/rss/$linkUri?tag=$tagname/$channelname

On Dec 15, 10:31 pm, friedger <fried...@googlemail.com> wrote:
> Rethink about the urls.

> There is a already a feed: URI scheme.http://en.wikipedia.org/wiki/Feed:_URI_scheme

[Peli]

I agree with Friedger that the content-URI should contain a link to a
list of items, that the ContentProvider stores separately (in a SQLite
database).

So the links look like:
content://org.openintents.news/rss/ (gives you a list of all feeds
in your phone)
content://org.openintents.news/rss/1 (gives you feed #1)
content://org.openintents.news/rss/2
...

In your database you store:
id | feed link | channelname
1 | feed://example.com/rss.xml | Example channel
2 | feed://otherexample.com/rss.xml | The newest examples

(To tag them, you just use the CentralTagger).

Now you need a second table, that links to the content or contains the
content
id | feed_id | uid | content | date updated | ...
....

They may be accessed via
content://org.openintents.news/feedcontents/2345
or something similar.

Would you think such a structure could be useful, or do you have other
ways of usage in mind?

Peli

[Zero]

this looks much like my first aproach, i propbably got a bit carried
away with these urls thingies on the way.
using a [..].news/feedcontents url for accessing items is nice, but
i'm still looking for a way to access a specific item directly
content://org.openintents.news/feedcontents/$channel/uid
or is it possible to mix queryitems here, using
content://org.openintents.news/feedcontents/$feed_id for all items of
a feed
content://org.openintents.news/feedcontents/$feed_id?$uri for a
specific item.
(but then i will have to parse the url again)

[Peli]

I think, the cleanest way to look for a specific item is to query
first for the feed id, using a managedQuery with a WHERE
feed_link="feed://example.com/rss.xml". (see
http://code.google.com/android/devel/data/contentproviders.html )

Then you obtain the feed_id. Using this feed_id, you can perform a
second query to look for a specific item: something like a query WHERE
feed_id = rss.feed_id AND uid = '[desireduid]'
then you obtain the unique id for a specific content.

e.g. content table
id | feed_id | uid
1 | 1 | 345
2 | 1 | 346
3 | 2 | 128
4 | 1 | 347
5 | 1 | 348
6 | 2 | 129
...

and so on. Once you have the content_id, there is no more ambiguity,
since this corresponds to exactly one content in your content list.

Of course, later one may add a convenience function that can perform
the two steps at once, so that you immediately receive the content_id
from feed_link and uid. What do you think?

Peli

[Zero]

I added a short page to the wiki describing the table layout. Code-
wise I'm stuck, trying to get an Instance of the contentprovider in my
sample app. I stronly dislike committing unstable code, so I stay out
of the repsitory for a while longer.

[Peli]

Zero,

Great! Thanks!
One possibility to work on the main trunk is to do a personal branch
and to merge things back to the main trunk when things seem working.

I noticed that NumBeast started working on a MapView for locations, so
it could apply to him to.

The advantage if you work in your own branch is that you don't need to
worry about submitting unstable code. You can code by yourself and
commit as often as you like (even unstable code), and if a feature
works, just merge it back to the main trunk.

I did the same when developing the shopping application. Have a look
here:
http://openintents.googlecode.com/svn/branches/developers/
You can create your own branch(es) in your own directory there.

Branches are cheap: You can branch the complete trunk into your
developers branch (including all samples and testing directories), and
it will take no additional space on the repository, and only those
files you change will get stored. You can create as many branches as
you like to try out different things.

Have a look into the subversion book:
http://svnbook.red-bean.com/en/1.4/svn.branchmerge.html
What we want is a "feature branch", i.e. a branch for developing new
features, that are then merged back into the main branch - either by
you or by anyone else.

Keeping things in a separate branch makes it possible that others can
look into your intermediate work, and help with problems or point out
things that could be solved better from the beginning to avoid a lot
of correction afterwards...

I'm really excited how this project seems to take off now on different
fronts :-)

Peli

[Zero]

I'm starting to hate subversion much more then i hated visual source
safe before. tried out different clients, only one i got working atm
is rapidsvn - and that comitted to the trunk instead of the branch.
(and the branch i created looks quite messy too)*sigh*
one day someone will come up with a version control system that just
works.

[Peli]

Hi Zero,

Don't panic... the good thing about a versioning system is that one
can not do anything wrong. :-) I reverted your edit to the main trunk
to the last stable one by NumBeast (by SVN copy-ing from an old
version and re-committing), and cleaned up your personal branch with
your new files.

I could not find the file provider/RSSFeed.java in the repository, so
I hope they did not get lost. Just copy it to your working directory
and commit if you have stored them anywhere.

Do you use Windows? (Probably, since you used Visual Source Safe).
Then I can only recommend TortoiseSVN:
http://tortoisesvn.tigris.org/
which I also use and which I used to clean things up. It is quite
good.

They have a good help file as well, but if you have any questions
don't hesitate to ask. It is quite possible that something that would
take you hours to try to find out yourself could be answered quickly
by someone who already had a similar problem.

Cheers,
Peli

[NumBeast]

While the topic of source control is up. I've heard some great things about git. I've never been able to use it with more than.. myself so I don't know how effective it is for a group like ours. but if Linus coded it I'm all for it. (and yes, it can commit to svn)

And off topic: Currently I'm very busy with school, but I'm working on openIntents as much as I can. Hopefully soon I'll be able to give it more time though. Just wanted to tell you in case somebody suggested I'm not commited ;)

[Peli]

NumBeast,

I have also used git in a group. The definite advantage is that
merging is all automatic. With SVN you have to remember yourself (or
write it into the commit notes) which revision numbers from which
branch have already been merged into the main trunk, and only merge
the remaining revisions. With git you just merge, and it does
everything automatically. (of course, one still has to resolve
conflicts manually).

I have never used git and svn in combination, so I don't know how well
they would work together. We would have to set up a separate host for
git though, so since we already have the free svn host over here, I'd
say we stick to it. (if you see any advantage in using git by yourself
and submit to svn here, that's also fine).

Got your second point about your interest in the project. That's ok,
and thanks for the notification.

Peli

On Jan 14, 1:46 am, NumBeast <numbe...@gmail.com> wrote:
> While the topic of source control is up. I've heard some great things about
> git. I've never been able to use it with more than.. myself so I don't know
> how effective it is for a group like ours. but if Linus coded it I'm all for
> it. (and yes, it can commit to svn)
>
> And off topic: Currently I'm very busy with school, but I'm working on
> openIntents as much as I can. Hopefully soon I'll be able to give it more
> time though. Just wanted to tell you in case somebody suggested I'm not
> commited ;)
>

[Arkadiusz Bicz]

Peli,

Take a look at http://www.orcaware.com/svn/wiki/Svnmerge.py.

It is very useful tool which remembers all last merges, that you don't have to remember what you already merged.
I'm using it already for my projects, it's quite good.

Regards,

Arkadiusz

[Zero]

OK, a bit more on topic ;)
I re-factored the existing code, we now have a single NewsProvider
Class that also supports basic atom feeds.
There are some design issues for more complex atom support, maybe we
need an extra table for author and similiar things as atom format is
pretty complex. (more on this later).


On Jan 15, 12:18 am, "Arkadiusz Bicz" <arkadiusz.b...@gmail.com>
wrote:
> Peli,
>
> Take a look athttp://www.orcaware.com/svn/wiki/Svnmerge.py.

>
> It is very useful tool which remembers all last merges, that you don't have
> to remember what you already merged.
> I'm using it already for my projects, it's quite good.
>
> Regards,
>
> Arkadiusz
>

[Zero]

Right!
Newsreader 0.1 is here!
You can check out the code from trunk/applications/newsreader and
build it yourself,
or you can wait until tomorrow and try an apk.
(0200 MET, I need some sleep now. )

[Muthu Ramadoss]

Great news.. I have a requirement to read RSS feeds (media) and probably
news reader can help me. I'll check it out. Thanks zero.

Zero wrote:
> Right!
> Newsreader 0.1 is here!
> You can check out the code from trunk/applications/newsreader and
> build it yourself,
> or you can wait until tomorrow and try an apk.
> (0200 MET, I need some sleep now. )
>
>

--
Thanks.

Muthu Ramadoss
http://www.intellibitz.com
http://groups.google.com/group/android-chennai
http://www.slideshare.net/intellibitz
+91 44 22476750

We develop innovative solutions for mobile handsets, using Android.

[Peli]

Hi Zero!

Thanks for your great work! Unfortunately, I could not launch your
application yet, as I ran into a couple of issues, but today I will
not have time to look into that, and on Saturday I'm also not
available, so I will only get a chance to look into it on Sunday
again..

But, a couple of issues that I noticed:
I tried to include openintents-lib.jar into your newsreader
application, but this is not enough:
Your application explicitely requires for example access to the
classes org.openintents.news.views.* or
org.openintents.tags.MagnoliaTaggig.

But the only classes currently contained in openintents-lib.jar are
defined in OpenIntents/build-lib-content.txt:

org/openintents/provider/*.class
org/openintents/OpenIntents.class
org/openintents/hardware/Sensors.class
org/openintents/hardware/SensorsPlus.class
org/openintents/hardware/SensorSimulatorClient.class

In principle this should ONLY be the first two lines, i.e. everything
in provider and the OpenIntents.class itself. The last three lines are
included explicitely for performance reasons.

Note that openintents-lib.jar is included in every application. This
does not make sense for views for example: We don't need the same code
several times on the phone, but you want newsreader to call the code
that exists in OpenIntents. The correct way to do it is to call the
intent not by its explicit class, but by a string that specifies the
intent that you want to call, and this string should be put into the
provider/xxx.class.

Try to use the openintents-lib.jar from the last distribution (or from
any of the samples/xxx/lib folders) and you will see what I mean...

If you have any questions, I am available by email until tonight. If
you run into problems with these changes, I can help on the code again
Saturday evening / Sunday.

I hope you can see what I mean. Too bad I can't try out your
application now, as I would really like to see how it looks :-) (The
automatic build did not work, because Friedger has included the new
positron acceptance tests that do not compile yet properly with the
ant scripts... so some time is necessary to fix that, but, as
mentioned, right now I am simply not able to do it here...)

Peli

On 29 Feb., 05:29, Muthu Ramadoss <muthu.ramad...@gmail.com> wrote:
> Great news.. I have a requirement to read RSS feeds (media) and probably
> news reader can help me. I'll check it out. Thanks zero.
>
> Zero wrote:
> > Right!
> > Newsreader 0.1 is here!
> > You can check out the code from trunk/applications/newsreader and
> > build it yourself,
> > or you can wait until tomorrow and try an apk.
> > (0200 MET, I need some sleep now. )
>
> --
> Thanks.
>

> Muthu Ramadosshttp://www.intellibitz.comhttp://groups.google.com/group/android-chennaihttp://www.slideshare.net/intellibitz

[Zero]

this is propably there the domain stack Muthu proposed
comes in handy.
There's alot more to the .news package then just the contenprovider.
in news.services are threads and a service class that allows you
to read data from channels automatically.
news.views includes some View classes and matching ListAdapters
to quickly build activities displaying news items or channels.
I had two options:
1)moving these things to applications.newsreader
- but then the news package isn't as usefull as it could be.
2)move all activities to the .news packages - but i think
that is realy overboard, not everyone will need thoose.
so now i see option
3) compile an openintents-news.jar that holds the
news package and it's subpackages. Then people can
choose if they want openintents-base or the fully fleged
newsreader , or develop their own news app with some additional
tools.

as for the tagging classes, this is -as they say - an
"undocumented feature" i.e. bug.

> > Muthu Ramadosshttp://www.intellibitz.comhttp://groups.google.com/group/android-chen...

[Zero]

apk file now in /trunk/applications/newsreader/release/
added some bug issues.

[Peli]

Hi Zero,

release folder is still empty?

Ok, so if you have some classes that can be useful to various
applications, probably you are in a similar situation as the
SensorSimulator:
It would be best if they could be put into a "shared library". But
since this is not available yet on Android, those few classes (as few
as possible) can be included into openintents-lib.jar. They are then
duplicated, but since they should be small classes, that is bearable.

Just include the necessary files in the OpenIntents/build-lib-
content.txt file, and they are included automtically when one performs
the ant script build-release.xml into the new openintents-lib.jar
file.

I think this is the easiest solution for now (at least until truly
shared libraries become available on Android).

(This inclusion should not be necessary for activities that can be
called through intents).

Peli

> > > > We develop innovative solutions for mobile handsets, using Android.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

[Peli]

PS: A "cleaner" path to copy the apk file to would be

* svn/downloads/releasecandidates/Release_0.1.4/newsreader.apk

or similar,
so that the main trunk could be kept free of binary apk files.

Peli

> > - Zitierten Text anzeigen -- Zitierten Text ausblenden -

[Peli]

PS:

> 3) compile an openintents-news.jar that holds the
> news package and it's subpackages.  Then people can
> choose if they want openintents-base or the fully fleged
> newsreader , or develop their own news app with some additional
> tools.

This will also not solve the real problem - that is duplicate code on
the phone: If another application wants to use parts of the
newsreader, they would have to include the full openintents-news.jar
in their application?

Again, the aim is to try to separate parts that can be used by other
programs as cleanly as possible from application-specific parts, and
keep the common parts as small as possible. Then it should not matter
whether the common parts sit in openintents-lib.jar or openintents-
news-lib.jar - which actually is also possible... Just *some*
separation is necessary - the end user does not want to include the
whole application in whatever they want to do.

Ok, but I agree that we can think about a better separation later. For
now, let's concentrate on functionality :-) So, I'm still eager to try
out your application :-) If you check in before 18:00 today, I can try
it tomorrow in the train (I have an 8 hours trip tomorrow back home..)

Peli

[Zero]

"make it so" as capt picard says ;)
i'll keep it low, theres just one more threading class to come.

not sure if there are now two binary files...
*scratches his head* rapidsvn sometimes behaves...strange.
I added again using the folder you suggested - or so rapidsvn says.
i've got a train to catch, so pls send me an email if it's still not
working.
i'll check back here tonight.

[Muthu Ramadoss]

Ah Ah.. finally someone is able to see my longterm vision ;) Peli also
agrees with me, but i can see he's a little cautious in going with the
change. Come on Peli, you need to move this OpenIntents towards the
community and the time to do it is now.

The separation of concerns is going to come back and bite us often.. so
folks fasten your seat belts!

--
Thanks.

Muthu Ramadoss
http://www.intellibitz.com
http://groups.google.com/group/android-chennai
http://www.slideshare.net/intellibitz

[Peli]

Please, what I want you to understand is there is no need to split
openintents-lib.jar into many small lib-jars. Each of them would be
only a few kb big, and anyway, when you compile it, the linker just
picks those classes that are actually used in your program.

Look at android.jar: It contains everything from graphics to sound to
database, etc. etc. in one single file that you include in your
project.

Of course they have a shared library, that we don't have (yet). But
the idea would be similar.

Another thing is splitting into OpenIntents.apk and applications.apk,
which is very useful. This is now just a question of what to put into
applications and what to put into the common lib-jar (which - again -
is NOT identical to OpenIntents.apk... OpenIntents.apk (the thing that
everyone installs) is NOT openintents-lib.apk (what every developer
includes in their project).

Peli

> Muthu Ramadosshttp://www.intellibitz.comhttp://groups.google.com/group/android-chennaihttp://www.slideshare.net/intellibitz
> +91 44 22476750
>

[Peli]

Congratulations! Your news reader really looks promising!

I just added the ant scripts and Eclipse project files to the
newsreader application.

In building, I noticed that probably one file is still missing:

In FeedMessages.java:
MessageCursorTreeAdapter is missing (for now I simply commented that
out).

Also, I changed the following:
* afeedsettings.xml:
replaced EditText android:text by android:hint
(I guess you really wanted a "hint", not a "text" for "enter feed url
here")

* AndroidManifest.xml:
Changed application name to News Reader (so that it wraps to 2 lines),
and added it to the OpenIntents category (so that it appears also in
OpenIntents directly).

Two more things that come to my mind:
* regarding capitalization, "NewsReader" appears sometimes as
"Newsreader" (Newsreader.java) and sometimes as
"NewsReader" (fdNewsReaderService). Some consistent scheme may not be
bad.

* The lists you display are still in the old m3 sizes - the new m5 SDK
defines much larger list items. Since it seems m5 targets at touch
display, one should keep in mind that it would be good to increase the
sizes in NewsReader (as well as in Tagging).

I like the service that starts and runs in the background! Well done!
I subscribed to 2 feeds already. This is addictive :-)

Peli

[Zero]

i committed the missing file. that's experimental code, I tried to use
the new Expendable List for Messages so i could get click-events
thru to the textview displaying the link, but man that thing is buggy.
I'll see to make the lists a bit bigger. expendable lists would
resolve this
as well make for an more touch-screen driven gui instead of relying to
the controll buttons, but that seems to be a improvement i have to
save for later.

thanx for the hint. ;)

You're absolutly right about the capitalisation, thats just something
i never realy think about while coding - as you can see ;)
the right term would be "Newsreader" i think.

at some point in the future one could at an aidl interface to the
service, then it would behave like a unix daemon. If anyone has use
for this
and proposals for what methods this could include, let me know.