2016-03-13 2 views
11

NOTA: Questo problema viene segnalato da multiple parties on the official GitHub repository for Cordova Browser-Sync Plugin as well. Pubblicando questo qui per attirare maggiormente l'attenzione sul problema e per vedere se qualcuno ha qualche intuizione o una soluzione pratica a questo.Perché il plug-in Cordova Browser-Sync non funziona su una nuova app Apache Cordova nuova e pulita?


Sono nuovo al mondo di Apache Cordova, ma fluente in full-stack di sviluppo LAMP. Detto questo, sono sconcertato da questo problema: quando creo un'applicazione di test semplice/semplice Apache Cordova e aggiungo Cordova Browser-Sync Plugin al mix, posso apportare modifiche alla mia directory www/ e vederle immediatamente riflesse in platforms/browser/www/ ma la mia finestra aperta del browser non live reload. Devo forzare una ricarica per far sì che le modifiche si riflettano nel browser.

Sto eseguendo tutto questo su Mac OS X 10.10.5 (Yosemite), NodeJS è 4.4.0, NPM è 2.14.20, Cordova è 6.0.0 e il plug-in Cordova Browser-Sync è 0.1.1.

I miei passaggi per impostare le cose sono i seguenti; prima creare una nuova applicazione in questo modo:

cordova create MyApp 

Poi vado nella directory in questo modo:

cd MyApp 

E impostare il mio semplice “browser” Cordova app come questo:

cordova platform add browser 

Un test finale è quello di eseguire l'app in questo modo:

cordova run browser 

Ok, quindi sappiamo che il semplice test "Hello world." Funziona. Ora io aggiungo il Browser Sync-Plugin Cordova in questo modo:

cordova plugin add cordova-plugin-browsersync 

Tutto bene e ora voglio provare l'applicazione in questo modo:

cordova run browser -- --live-reload 

E se faccio un cambiamento in un file, il browser semplicemente non "live reload" come descritto; a meno che mi manchi qualcosa? L'output di questo comando è:

Running command: /Users/jakegould/Desktop/MyApp/platforms/browser/cordova/run --live-reload 
Static file server running on port 8000 (i.e. http://localhost:8000) 
CTRL + C to shut down 
Static file server running @ http://localhost:8000/index.html 
CTRL + C to shut down 
Executing command: open -n -a "Google Chrome" --args --user-data-dir=/tmp/temp_chrome_user_data_dir_for_cordova http://localhost:8000/index.html 
[BS] Access URLs: 
-------------------------------------- 
     Local: http://localhost:3000 
    External: http://192.168.1.20:3000 
-------------------------------------- 
      UI: http://localhost:3001 
UI External: http://192.168.1.20:3001 
-------------------------------------- 
[BS] Serving files from: platforms/android/assets/www 
[BS] Serving files from: platforms/ios/www 
[BS] Watching files... 
gzip 
200 /index.html (/Users/jakegould/Desktop/MyApp/platforms/browser/www/index.html) 
gzip 
200 /css/index.css (/Users/jakegould/Desktop/MyApp/platforms/browser/www/css/index.css) 
gzip 
200 /cordova.js (/Users/jakegould/Desktop/MyApp/platforms/browser/www/cordova.js) 
gzip 
200 /img/logo.png (/Users/jakegould/Desktop/MyApp/platforms/browser/www/img/logo.png) 
gzip 
200 /js/index.js (/Users/jakegould/Desktop/MyApp/platforms/browser/www/js/index.js) 
gzip 
200 /cordova_plugins.js (/Users/jakegould/Desktop/MyApp/platforms/browser/www/cordova_plugins.js) 
[BS] Reloading Browsers... 

Nota come si dice “Browser Ricaricamento ...” alla fine della lista? Ti assicuro che al 100% non è stato ricaricato un solo browser. E qui è il codice HTML www/index.html dalla radice dell'applicazione che sto cercando di modificare per attivare una ricarica dal vivo:

<!DOCTYPE html> 
<!-- 
    Licensed to the Apache Software Foundation (ASF) under one 
    or more contributor license agreements. See the NOTICE file 
    distributed with this work for additional information 
    regarding copyright ownership. The ASF licenses this file 
    to you under the Apache License, Version 2.0 (the 
    "License"); you may not use this file except in compliance 
    with the License. You may obtain a copy of the License at 

    http://www.apache.org/licenses/LICENSE-2.0 

    Unless required by applicable law or agreed to in writing, 
    software distributed under the License is distributed on an 
    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 
    KIND, either express or implied. See the License for the 
    specific language governing permissions and limitations 
    under the License. 
--> 
<html> 
    <head> 
     <!-- 
     Customize this policy to fit your own app's needs. For more guidance, see: 
      https://github.com/apache/cordova-plugin-whitelist/blob/master/README.md#content-security-policy 
     Some notes: 
      * gap: is required only on iOS (when using UIWebView) and is needed for JS->native communication 
      * https://ssl.gstatic.com is required only on Android and is needed for TalkBack to function properly 
      * Disables use of inline scripts in order to mitigate risk of XSS vulnerabilities. To change this: 
       * Enable inline JS: add 'unsafe-inline' to default-src 
     --> 
     <meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *"> 
     <meta name="format-detection" content="telephone=no"> 
     <meta name="msapplication-tap-highlight" content="no"> 
     <meta name="viewport" content="user-scalable=no, initial-scale=1, maximum-scale=1, minimum-scale=1, width=device-width"> 
     <link rel="stylesheet" type="text/css" href="css/index.css"> 
     <title>Hello World</title> 
    </head> 
    <body> 
     <div class="app"> 
      <h1>Apache Cordova</h1> 
      <div id="deviceready" class="blink"> 
       <p class="event listening">Connecting to Device</p> 
       <p class="event received">Device is Fucking Ready</p> 
      </div> 
     </div> 
     <script type="text/javascript" src="cordova.js"></script> 
     <script type="text/javascript" src="js/index.js"></script> 
    </body> 
</html> 

ho capito che la funzionalità di ricarica dal vivo spesso si basa su codice inline JavaScript che viene in qualche modo iniettato nel DOM di l'HTML per comunicare con il server live reload. E tutto ciò che ho letto online dice che questi tipi di problemi - dove la ricarica live fallisce - spesso provengono dai tag <body></body> non impostati su una pagina. Ma chiaramente ci sono. Voglio quasi pensare che si tratti di un problema correlato a Content-Security-Policy, ma sarebbe davvero un fattore se il JavaScript venisse iniettato nella pagina per cominciare.

Quindi, perché esattamente la funzionalità di ricarica live non funziona in una configurazione iniziale incredibilmente semplice come questa?

risposta

7

Codice-saggio, non sembra che ci sia una soluzione/fix che funziona. Perché? Chissà. Ma il plug-in così com'è ora è rotto.

E oltre le specifiche tecniche, according to this issue ticket sulla GitHub repository connected to the official plug-in -E proveniente direttamente da parte dello sviluppatore del progetto stesso, il progetto è “in pensione”.

Sto progettando di andare in pensione questo progetto a favore della Taco-livereload . Anche questo si basa praticamente sullo stesso codice, e ora sono un PM su tale progetto. Questo progetto avrà anche più sviluppatori che lavorano su di esso, quindi avrà molto più supporto come progetto ufficiale.

Vorresti soddisfare le tue esigenze? C'è qualcosa che questo progetto ha, che il taco-fegato non ha?

Dal Taco è un Microsoft project, non ho intenzione di toccare che con un palo di 10 piedi, anche se non stanno usando una licenza MIT. La filosofia Microsoft di “embrace, extend, and extinguish” sembra troppo rischiosa per uno sforzo open source come questo.

Quindi, invece, ho intenzione di virare verso lo Ionic come framework poiché ha una funzionalità di ricarica live pronta all'uso ed è più ampiamente adottata e abbracciata dal mondo di sviluppo Cordova in questo momento.

PS: Il Content-Security-Policy solution discussed on the plug-in author’s blog che suggerisce di impostare ws: 'unsafe-inline' sarebbe un fattore solo se il codice JavaScript di ricarica live è stato iniettato correttamente nella pagina per cominciare. Il codice JavaScript di una fonte non attendibile è ciò che farebbe fallire il processo nei casi in cui il plug-in avrebbe effettivamente funzionato. E la prova sarebbe vedere un tale errore nella console del browser Web dopo il caricamento della pagina.

Ma in questo caso, il codice di iniezione non avviene più e di avviare l'applicazione con cordova run browser -- --live-reload avvia il server di sviluppo di default su localhost:8000 ma poi dopo i server di sincronizzazione del browser vengono avviati per localhost:3000 e localhost:3001. Se questa configurazione funzionasse correttamente, funzionerebbe solo su localhost:3000; e non le porte 8000 e 3000.

4

Penso che manchi ws: 'in-safe' in-linea ' nella definizione di Content-Security-Policy.

Il plug-in richiede questo CSP affinché websocket funzioni.

Dai un'occhiata al video http://blog.nparashuram.com/2015/08/using-browser-sync-with-cordova.html (collegato nel file readme.md del plugin) per le spiegazioni dettagliate sull'utilizzo del plugin.

dovrebbe essere:

<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: ws: 'unsafe-inline' https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *"> 
+0

Siamo spiacenti, ma questo non ha nulla a che fare con questo. Il tuo problema verrebbe visualizzato solo se il JavaScript di ricarica live fosse stato effettivamente inserito nella pagina. Ciò non accade affatto; guarda il mio esempio HTML per vedere. Se fosse correttamente iniettato, si troverebbe in fondo al DOM vicino (dopo?) Al tag di chiusura ''. E nota quando eseguo 'cordova run browser - --live-reload' avvia il server di sviluppo predefinito su' localhost: 8000', ma in seguito i server di sincronizzazione del browser vengono avviati per 'localhost: 3000' e' localhost: 3001 '. Se questa installazione funzionasse correttamente sarebbe solo 'localhost: 3000'. – JakeGould