Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

Restoring the 0.8.x webview way

>Any chance you will make available again the ability to reference an html file in the createWindow method and let us use webviews the 0.8.x way?
Whilst the changes in 1.0 are great for native views etc it makes working with webviews a pain.
>Up until now we have had a report.html file that would setup a basic html skeleton, a native toolbar and grab a reportId from a Titanium.App.Properties.getString call.
Next in a referenced js file we would make a xhr call to our web app and take the resulting html fragment and insert it using jQuery.
I would also update the form action so it referenced the fully qualified domain.
$('#reportForm').attr('action', url + '/' + 'mobile/' + 'mobilereport.aspx?id=' + reportId
At this point all calls back to the server worked fine for drill down and other functionality had a few scrolling issues to sort but it performed and worked well.

  • Where do I start implementing this the 1.0 way?
  • If I need to open reports from 3 different tabs, I imagine I'll need a separate js file that can be opened from anywhere.
  • If the XHR call cant be made in the html file how do we inject the html from the external js file and can jquery even be used?


— asked March 16th 2010 by David McL

2 Answers

  • Accepted Answer

    A few comments on how i'd suggest you handle this in 1.0 forward. WebViews are way more powerful but you'll need to handle them differently.

    Put your logic for handling things like fetching remote content in your app.js and fire events to the webview

    Simple example.


    function getMyStuff()
        var xhr = Titanium.Network.createHTTPClient();
        xhr.onload = function(e)


              // do something we data in e

    The above example is a very simple and very powerful pattern to use. You essentially place any common, global logic in your main controller, app.js. You setup him to listen for app-level events and fire app-level events.

    In webview, you simply fire an event to tell the controller to perform some action. You then listen for any events once completed with your data.

    This is a nice de-composition between MVC whereby your app.js is acting as your main controller and your views are acting as views and handling the model stuff (from XHR).

    If you really wanted to break the MVC model and do some gnarly stuff, you could use the evalJS function on a WebView and just inject Javascript from your controller. So, this would also work … but be a little not so elegant:

    webview.evalJS("$('#my_element_id).html('hello world')");
    — answered March 16th 2010 by Jeff Haynie
  • Thanks Jeff,
    I had it in my head you couldn't gain access to app.js once you were creating new windows with separate .js files.
    Thanks for the heads up - this looks like a much better approach than my current wip…


    — answered March 16th 2010 by David McL
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.