Share a WebView between activities?

[Heath]

I've written an iOS app that I want to port to android. This app is a
front-end for a web-based timekeeping system at work. Unfortunately,
the system doesn't have an API, so I'm screen-scraping it using xpath
queries in javascript. In iOS, I only have to load this page once
because I get full control over when instances of my UIWebView get
destroyed.

iOS app only has 3 use cases, each which break into separate Android
activities:
Login
View a list of all reported times
Report a new time.

Using a naive approach, my android views (including the WebView I need
to use to interact with the timekeeping system) will be destroyed and
recreated when I switch between views. If I have to reload the
WebView every time I switch activities, my app will appear very slow.
Is it possible to share a WebView instance between multiple
activities? I know I can set the launchMode to singleInstance, but
ideally, it would be nice to allow separate instances so that the back
button would function normally.

Thanks!

[Heath]

Cross-posted on stackoverflow:
http://stackoverflow.com/questions/4988698/share-a-webview-between-activities

[Eric Burke]

Ideas...

• Write a new web app that exposes a clean API. This new web app performs the screen scraping behind the scenes.
• or...
  
• See if your Android Application can create the WebView. You won't actually display the WebView anywhere, it's just created for interaction with the web site. The WebView instance's lifecycle is then managed by your Application rather than an Activity.

--
Eric M. Burke
636-542-8753 (Google Voice)

[Dale Wilson]

Do you actually need the web view?
If what you want the HTML from the web page -- possibly parsed for you
then something like this might work

import org.apache.http.*;
(you probably need a whole bunch more imports here)

public class MyWebPage
{
static Document dom;

Document instance()
{
if(dom == null)
{
URI uri = URIUtils.createURI("http", host, port, path,
query, fragment);
HttpGet httpGet = new HttpGet(uri);
HttpResponse response = mClient.execute(httpGet);
int statusCode = response.getStatusLine().getStatusCode();
if (statusCode != 200)
{
throw something at someone;
}

HttpEntity entity = response.getEntity();
InputStream is = entity.getContent();
DocumentBuilderFactory factory =
DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document dom = builder.parse(is);
}
return dom;
}
}

In this scheme if Android feels the need to reload your entire app,
then you'll refetch the web page, but otherwise any Activity can get
to the parsed document via: MyWebPage#instance();

Oh, and it's likely that you want to actually fetch the web page in a
background task to avoid nasty timeouts but that's a whole 'nother
topic. See android.os.AsyncTask to get started on that one.

Dale

On Sun, Feb 13, 2011 at 9:34 PM, Heath <heath....@gmail.com> wrote:

--
I get up every morning determined to both change the world and have
one hell of a good time. Sometimes this makes planning my day
difficult.
  -E. B. White

[Heath Borders]

Option 1 isn't really feasible since I'm just trying to get a quick
client together and I anticipate that a proper API will materialize
soon.
Option 2 is exactly what I'm doing on iOS. When you say that the
WebView is managed by my Application, what do you mean? All of the
literature I've read talks about Tasks and Activities, I didn't know
there was an Application metaphor in Android. Do you just mean
putting the web view in a singleton that my Task can reference
somewhere? What Context would I use to create it?

-Heath Borders
heath....@gmail.com
Twitter: heathborders
http://heath-tech.blogspot.com

[Heath Borders]

Thanks for the suggestion. I do actually need a WebView since the
page I'm scraping from does a lot of background updating in javascript
that I don't want to replicate in my client. If I run the page in a
WebView, I can just exercise it in response to user input just like a
user would through the browser.

-Heath Borders
heath....@gmail.com
Twitter: heathborders
http://heath-tech.blogspot.com

[Ben Oberkfell]

There's an Application class to help you maintain global application state.

http://developer.android.com/reference/android/app/Application.html

Application and Activity both inherit from Context, so conceivably you should be able to pass in the application when you create the WebView, and then store the WebView on the Application.

You can declare a class name in the manifest for your application using "android:name" : 

<application android:icon="@drawable/icon" android:label="@string/app_name" android:name="com.foobar.app.YourApp">

Then just define a YourApp class that extends Application.  The rest will be done for you in terms of instantiating that particular class on startup.  

In your Activity, you can call getApplicationContext() to get at the Application and grab your WebView. 

[Heath Borders]

Score! Thanks.

-Heath

On Feb 14, 2011 5:20 PM, "Ben Oberkfell" <bober...@gmail.com> wrote:

There's an Application class to help you maintain global application state.

http://developer.android.com/reference/android/app/Application.html

Application and Activity both inherit from Context, so conceivably you should be able to pass in the application when you create the WebView, and then store the WebView on the Application.

You can declare a class name in the manifest for your application using "android:name" : 

<application android:icon="@drawable/icon" android:label="@string/app_name" android:name="com.foobar.app.YourApp">

Then just define a YourApp class that extends Application.  The rest will be done for you in terms of instantiating that particular class on startup.  

In your Activity, you can call getApplicationContext() to get at the Application and grab your WebView. 

On Monday, February 14, 2011 at 4:36 PM, Heath Borders wrote:
>

> Option 1 isn't really feasible ...

[Heath Borders]

In case you were wondering, the suggestion to use the Application
Context seems to work great. Thanks again!

-Heath Borders
heath....@gmail.com
Twitter: heathborders
http://heath-tech.blogspot.com