Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of anis.kadri@gmail.com designates
 209.85.161.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOBL_k4JBvmqqK3D7fdALCBkjbfmoi4k++jT__wS3A0+pEBcSQ@mail.gmail.com>
References: 
 <CAOBL_k4JBvmqqK3D7fdALCBkjbfmoi4k++jT__wS3A0+pEBcSQ@mail.gmail.com>
Date: Thu, 26 Jul 2012 16:06:23 -0700
Message-ID: 
 <CANpVHHyJEE4BYBm7zByG2YOG0xLdOEDZejjtyMAGhdnxYVerqQ@mail.gmail.com>
Subject: Re: [Android] loadUrl,
 input methods and making the web a thread-safe place
From: Anis KADRI <anis.kadri@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=20cf300513bcf1ca6d04c5c3a4be

--20cf300513bcf1ca6d04c5c3a4be
Content-Type: text/plain; charset=ISO-8859-1

Just one thought:

If google thinks it's a bad idea to use loadUrl to execute javascript they
should probably start by removing that exact thing from their docs [1].

[1]
http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,
java.lang.String)

On Thu, Jul 26, 2012 at 3:44 PM, Joe Bowser <bowserj@gmail.com> wrote:

> Hey
>
> So, on ICS and greater, it turns out that the routing table is
> fragile, so fragile in fact that you can't connect to localhost if you
> don't have an internet connection of some sort.  This is a problem for
> us on Android because we need to connect to localhost to use the
> bridge and communicate with the Callback Server so that we can get the
> callbacks.  In my opinion, this is the straw that broke the camel's
> back, and this bug is far worse than the reason we moved to the
> CallbackServer to begin with.
>
> First, some history:
>
> Back in OSCON 2010, we talked to Justin at Google about how they could
> help PhoneGap, and he mentioned that we shouldn't be using loadUrl for
> sending Javascript over because it is linked to the Handler and can
> interrupt the UI thread.  He suggested a callback server, which Bryce
> implemented.  The callback server and sending commands over the prompt
> happened at roughly the same six months, when Gingerbread was being
> rolled out.
>
> Now, in 2012, we are starting to have issues with the Callback Server
> approach, and we should examine why we did this in the first place.
> The test case for it is simple:
>
> 1. Put an input field on the accelerometer page on Mobile-Spec
> 2. Turn on Accelerometer
> 3. Try to type something
>
> What it will do is it will update the accelerometer values as you type
> text. This is awesome, but I'm wondering if anyone is actually going
> to use this use case, and if it's OK to break this functionality in
> exchange for performance and stability.  We currently have the ability
> to use loadUrl("javascript:foo()") again by checking whether we have
> focus on a text field, which we can use with HitTestResult, which
> inspect's webkit's cursor.  This would fix the bug that I call
> "Airplane, Airplane Crash" where you can crash our bridge by switching
> your phone in and out of airplane mode over and over again.  I have a
> test repository here, and it passes most of Mobile Spec.  It would be
> nice to be able to have this as a configurable option to start.
>
> https://github.com/infil00p/callback-android/tree/testbridge
>
> Any thoughts?
>
> Joe
>

--20cf300513bcf1ca6d04c5c3a4be--