[tssg-tech] Re: Parsing BostonEventsList with ROME
- From: Harry Henriques <harry_henriques@xxxxxxxxxxx>
- To: tssg-tech@xxxxxxxxxxxxx
- Date: Sat, 25 Sep 2010 12:10:43 -0700 (PDT)
________________________________
From: Beatrice W. Chaney <bwchaney@xxxxxxxx>
To: tssg-tech@xxxxxxxxxxxxx
Sent: Sat, September 25, 2010 12:54:42 PM
Subject: [tssg-tech] Re: Parsing BostonEventsList with ROME
Hi All,
Good discussion!
Let's keep in mind that performance is a critical concern on mobile platforms.
*************************
I agree that performance is critical. For this reason, a home brewed solution
may not be practical.
*************************
The Android SDK offers full XML parsing capabilities, which are well described
in the following tutorial, posted somewhere on TSSG (by Ron, I believe? I
couldn't find the original reference):
http://www.ibm.com/developerworks/opensource/library/x-android/index.html
Although the Android SDK XML parser supports DOM, the emphasis is on SAX, which
is typically much faster and uses a lot less memory. This is because DOM reads
in an parses the whole document before it lets you traverse it, whereas SAX
only
parses what you tell it to and cherry picks what it hands back to your code.
The
advantage of SAX becomes more pronounced, the larger the document.
We may want to evaluate several approaches, and benchmark them.
*************************
I suppose that it is possible to implement an XML parser in a dozen different
ways, but why would we want to, when ROME is already written. We can write our
own parser to handle the Description tag, but ROME handles everything else very
nicely. ROME also separates the description from the rest of an entry, and
returns it as String text. ROME separates each individual entry from all the
other entries, and puts it into a Collection with the following fields: Title,
PubDate, URL of "details page", and Description. ROME and JDOM are provided in
two separate .JAR files. I don't see any reason why they can't be integrated
into our "app".
*************************
Bea
By the way, Java 6 now allows invoking JavaScript from Java:
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/
Also, the Java Server Pages (JSP) technology allows mixing Java and JavaScript
in the same JSP code page (Java is executed on teh server, whereas JavaScript
embedded in HTML is executed on the client)
**************************
The .../scripting/ link that you provided is very interesting. I am aware of
the fact that JavaScript has been traditionally used in JSP pages. This is not
the same thing as mixing Java and JavaScript into an "app", at least using my
definition of "app." As the Bob Dylan song says, "the times, they are a
changin'". Very Interesting.
**************************
Julie Carwellos wrote:
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 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
>
>--- 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
>>
>>
>
Other related posts:
