3 quick comments on this:
I completely agree that a web view should be used for the "full" page,
and the fact that the URL can come from the ROME code really makes our
life so much easier!
http://developer.android.com/resources/articles/using-webviews.html
has some interesting information on using webviews with JavaScript
within an Android Java app (that rascal Dalvik!), and I'm currently
thinking that the "summary" item within the (expandable) list should
be a web view of the <description> tag content (it's all HTML) . This
will automagically create a DOM and JavaScript can be executed against
it to get our information for search and filter requirements.
I looked at the source again, and styling is wrapped in all those >
and < strings - so now that I know where it happens, I'm good - (I
can't stand loose ends!!! ;-) ).
Good discussion, Harry.
-julie
------------------------------------------------------------------------
Julie (Dingee) Carwellos
Web and IT Project Analyst, User Experience and Interaction Designer
LinkedIn <http://www.linkedin.com/in/jdingeecarwellos> -
http://www.linkedin.com/in/jdingeecarwellos
--- On Sat, 9/25/10, Harry Henriques <harry_henriques@xxxxxxxxxxx> wrote:
From: Harry Henriques <harry_henriques@xxxxxxxxxxx>
Subject: [tssg-tech] Re: Parsing BostonEventsList with ROME
To: tssg-tech@xxxxxxxxxxxxx
Date: Saturday, September 25, 2010, 12:07 AM
Please see my comments that are embedded in Julie's message, below.
Best regards,
Harry Henriques
Java Developer
------------------------------------------------------------------------
From: Julie Carwellos <jcarwellos@xxxxxxxxx>
To: tssg-tech@xxxxxxxxxxxxx
Sent: Fri, September 24, 2010 2:13:01 PM
Subject: [tssg-tech] Re: Parsing BostonEventsList with ROME
Harry, you're right. We have an n-tiered app here - lots and lots
of capabilities to be included (Java, JavaScript, XML, HTML, and
we'll come across more, I'm sure). So it's important to be clear.
The following might help, and anyone should jump in if I don't get
it quite right:
****************************
I hope everyone is clear on the fact that Java and JavaScript are
as different as Java and C++. JavaScript is a unique language,
and Java is another unique language. I don't believe that it is
possible to mix the two languages into one executable bytecode file.
*****************************
JDOM - Java's document object model for loading XML files so that
app code can then traverse the model and pick and choose and
change the information as it wants.
DOM - X/DHTML's document object model, for the same reason, but
it's with Javascript. In this case, the incoming file needs to be
HTML (Xtended or Dynamic, hence the XHTML or DHTML). PHP and Perl
I think can access the DOM, too. But Android gives you hooks to
use Javascript in apps.
Namespace is actually an XML thing, and the WWW Consortium has you
put all kinds of special casing into your own namespace. That way,
anyone could define something like a "book.xml" file in any way
they wanted to, and as long as the xml referenced it's own
namespace there'd be no confusion. In our case, if BEL had it's
own namespace for RSS extensions, it could break down the XML tags
into a much more granular level than the RSS standard defines (aka
Extensions).
If we're planning on displaying each event separately in an
Android Web View, then each event has to become a valid HTML file,
most of which is in the Description tag, and we can wrap it with
the required HEAD and BODY tags.
***************************
Because we have the URL of the "details page" thanks to ROME and
JDOM, I thought that it would be a good idea to invoke the Adroid
Web View (browser?) using the URL as a hyperlink. The cell phone
user would get an un-massaged view of the "details page", and this
"details page" has all the info that the cell phone user is
interested in.
Because we have the URL of the "details page", we could use
HttpClient to retrieve this "details page" from the BEL server,
and the BEL server would return an HTML page (completely intact)
as a Java readable file. The Java file then could be parsed in
the background to facilitate the "search" functionality and
database functionality.
As Julie has suggested, it may be easier to work directly with the
info in the Description tag, provided by ROME / JDOM. The
"details page" returned by the server is very involved.
**************************
This brings up another issue - where's the CSS? I would think we'd
need to develop a mobile.css, much as BEL probably already has
files for print.css and for other devices.
**************************
I'm not sure, but I don't think you would have to worry about
Style Sheets.
**************************
-julie
