[tssg-tech] Re: Parsing BostonEventsList with ROME
- From: Harry Henriques <harry_henriques@xxxxxxxxxxx>
- To: tssg-tech@xxxxxxxxxxxxx
- Date: Sat, 25 Sep 2010 11:37:50 -0700 (PDT)
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: Sat, September 25, 2010 11:32:21 AM
Subject: [tssg-tech] Re: Parsing BostonEventsList with ROME
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 am incorrect in my statement that Java and JavaScript cannot be mixed. The
following file is an example of a file where Java and JavaScript are mixed, and
was referenced in the URL provided by Julie. This code isn't JavaScript. It
appears that Google has merged the two languages. In effect, they have created
a third language, which is neither Java nor JavaScript.
package com.google.android.webviewdemo;
import android.app.Activity;
import android.os.Bundle;
import android.os.Handler;
import android.util.Log;
import android.webkit.JsResult;
import android.webkit.WebChromeClient;
import android.webkit.WebSettings;
import android.webkit.WebView;
/**
* Demonstrates how to embed a WebView in your activity. Also demonstrates how
* to have javascript in the WebView call into the activity, and how the
activity
* can invoke javascript.
* <p>
* In this example, clicking on the android in the WebView will result in a
call
into
* the activities code in {@link DemoJavaScriptInterface#clickOnAndroid()}.
This
code
* will turn around and invoke javascript using the {@link
WebView#loadUrl(String)}
* method.
* <p>
* Obviously all of this could have been accomplished without calling into the
activity
* and then back into javascript, but this code is intended to show how to set
up the
* code paths for this sort of communication.
*
*/
public class WebViewDemo extends Activity {
private static final String LOG_TAG = "WebViewDemo";
private WebView mWebView;
private Handler mHandler = new Handler();
@Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
setContentView(R.layout.main);
mWebView = (WebView) findViewById(R.id.webview);
WebSettings webSettings = mWebView.getSettings();
webSettings.setSavePassword(false);
webSettings.setSaveFormData(false);
webSettings.setJavaScriptEnabled(true);
webSettings.setSupportZoom(false);
mWebView.setWebChromeClient(new MyWebChromeClient());
mWebView.addJavascriptInterface(new DemoJavaScriptInterface(), "demo");
mWebView.loadUrl("file:///android_asset/demo.html");
}
final class DemoJavaScriptInterface {
DemoJavaScriptInterface() {
}
/**
* This is not called on the UI thread. Post a runnable to invoke
* loadUrl on the UI thread.
*/
public void clickOnAndroid() {
mHandler.post(new Runnable() {
public void run() {
mWebView.loadUrl("javascript:wave()");
}
});
}
}
/**
* Provides a hook for calling "alert" from javascript. Useful for
* debugging your javascript.
*/
final class MyWebChromeClient extends WebChromeClient {
@Override
public boolean onJsAlert(WebView view, String url, String message,
JsResult result) {
Log.d(LOG_TAG, message);
result.confirm();
return true;
}
}
}
*****************************************
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:
