cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: MessageQueue seems to stop sending messages to the webView
Date Mon, 24 Feb 2014 19:14:23 GMT
On Mon, Feb 24, 2014 at 2:14 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> James - have so far been unable to come up with a repro case for this. If
> there's a chance you could create one, that would be really helpful.
>
>
> On Tue, Feb 18, 2014 at 2:16 PM, Andrew Grieve <agrieve@chromium.org>wrote:
>
>> Hmm, might be same problem as
>> https://issues.apache.org/jira/browse/CB-6047. Let's move this
>> conversation to that bug.
>>
>>
>> On Tue, Feb 18, 2014 at 2:10 AM, James Rivett-Carnac <
>> james.rivett.carnac@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I'm uisng an embedded cordova webview and am seeing something where by
>>> the
>>> webview doesn't receive messages sent to it from my plugin.
>>>
>>> I've seen this with:
>>>
>>> android 4.3, 4.4.2, (Moto G, Nexus 7 2012)
>>> cordova 3.3.0-rc1, 3.3.0-0.1.1, 3.3.1-0.4.2
>>>
>>> The application is receiveing informatiion from a USB device (the
>>> phone/tablet runs in accessory mode), reading this information in its own
>>> thread.  These call callbacks, and change the state in the webview
>>> (lavaca
>>> app).
>>>
>>> Generally this works without issues.  Sometimes, the screen doesn't
>>> update.  If I profile the threads running, the webview is not showing any
>>> activity (except maybe a call to uptime).  If I unplug and plug back in
>>> the
>>> USB, the screen goes through all the pending updates (quickly flashes
>>> through them).  The app does *not* return to normal opperations at this
>>> point: I have to unplug/plug back in for every message that is sent.  If
>>> I
>>> do this while monitoring the threads, I see calls to the android message
>>> handler happening at this point.
>>>
>>> When it is working correctly, these calls happen when the event is
>>> triggered.
>>>
>>> My questions - what could be causing this?  Is there a way to force the
>>> message queue to trigger, other than unpluggin/pluggin back in?
>>>
>>> James
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message