Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 9622E200CD4 for ; Sat, 15 Jul 2017 00:23:08 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 92E8A16EA40; Fri, 14 Jul 2017 22:23:08 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id D8DDD16EA3D for ; Sat, 15 Jul 2017 00:23:07 +0200 (CEST) Received: (qmail 31387 invoked by uid 500); 14 Jul 2017 22:23:07 -0000 Mailing-List: contact issues-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@cordova.apache.org Received: (qmail 31376 invoked by uid 99); 14 Jul 2017 22:23:07 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Jul 2017 22:23:07 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 6CF50C008F for ; Fri, 14 Jul 2017 22:23:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 6o-Ku90L3PRQ for ; Fri, 14 Jul 2017 22:23:05 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 6E2E75F6BF for ; Fri, 14 Jul 2017 22:23:05 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 7ECA6E08B4 for ; Fri, 14 Jul 2017 22:23:03 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 6BCD12475C for ; Fri, 14 Jul 2017 22:23:01 +0000 (UTC) Date: Fri, 14 Jul 2017 22:23:01 +0000 (UTC) From: "Filip Maj (JIRA)" To: issues@cordova.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CB-9661) Plugins should be notified after deviceready event has been fired MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 14 Jul 2017 22:23:08 -0000 [ https://issues.apache.org/jira/browse/CB-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16088198#comment-16088198 ] Filip Maj commented on CB-9661: ------------------------------- As a workaround: what about having the plugin javascript wait for the deviceready event in JS land, and then send a message back to native using the regular {{cordova.exec}} channel? > Plugins should be notified after deviceready event has been fired > ----------------------------------------------------------------- > > Key: CB-9661 > URL: https://issues.apache.org/jira/browse/CB-9661 > Project: Apache Cordova > Issue Type: Improvement > Components: AllPlugins > Affects Versions: 5.1.1 > Reporter: Sebastien Lorber > > I use the Intercom plugin. > It is a plugin that shows a little button at the bottom (that we'll call "widget") that permits to show a native chat panel when the user wants to give a feedback for our app. > On startup I run something akin to: > {code} > function deviceReady() { > hideSplashScreen(); > if ( isUserConnected() ) { > intercom.registerIdentifiedUser(userIntercomData); > startApp(); > } > else { > intercom.reset(); > showLoginForm(); > } > } > {code} > The widget is only shawn after calling intercom.registerIdentifiedUser(); > The widget disappear when we call intercom.reset(); > The intercom plugin memoizes the fact that an user is registered over time. > This means that if I kill the app with a registered user, and restart it, Intercom will by default restore that regitered user on next startup. > Unfortunatly, this means that the widget will be shawn at the very beginning of the app initialization, even before the webview is initialized. In my case, it means that the Intercom button will be shawn for a little amount of time above the splash screen, which is a bit weird. > This would make sense for the Intercom team to not show the widget until the webview is initialized, particularly waiting for deviceready event to fire. > After discussing with the Intercom team, it seems they can't implement this because there's no possible way to wait for the deviceready event to fire from the native plugin code. > So I think it could be nice to be able, from the native plugin code, to wait for the deviceready event to be handled, so that native code can be started afterwards. > The original plugin issue: https://github.com/intercom/intercom-cordova/issues/18 -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscribe@cordova.apache.org For additional commands, e-mail: issues-help@cordova.apache.org