Questa pagina fa parte della documentazione relativa alla piattaforma App di Chrome, che è stata ritirata nel 2020. Rimane supportato per i clienti Enterprise ed Education su ChromeOS almeno fino a gennaio 2025. Scopri di più sulla migrazione dell'app.

Questa pagina è stata tradotta dall'API Cloud Translation.

Crea app con AngularJS

Questa guida spiega come iniziare a creare app di Chrome con il framework MVC AngularJS. A illustrare Angular in azione, faremo riferimento a un'app effettiva creata utilizzando il framework, Caricamento di Google Drive. Il codice sorgente è disponibile su GitHub.

Informazioni sull'app

Caricamento di Google Drive

L'Uploader di Google Drive consente agli utenti di visualizzare e interagire rapidamente con i file archiviati nel loro Google Drive e caricare nuovi file utilizzando le API di trascinamento dell'HTML. È una ottimo esempio di creazione di un'app che comunica con una delle API di Google; In questo caso, il team API Drive.

L'Uploader utilizza OAuth2 per accedere ai dati dell'utente. L'API chrome.identity gestisce il recupero di un token OAuth per l'utente che ha eseguito l'accesso, per questo il lavoro più impegnativo viene fatto. Una volta che avremo il token di accesso, le app utilizzano l'API Google Drive per accedere ai dati dell'utente.

Funzionalità principali utilizzate da questa app:

Rilevamento automatico di AngularJS per CSP
Visualizzare un elenco di file recuperati dall'API Google Drive
API HTML5 Filesystem per archiviare le icone dei file offline
Trascinamento di HTML5 per l'importazione/il caricamento di nuovi file dal desktop
XHR2 per caricare immagini, interdominio
API chrome.identity per l'autorizzazione OAuth
Frame senza chrome per definire l'aspetto e il design della barra di navigazione dell'app

Creazione del manifest

Tutte le app di Chrome richiedono un file manifest.json contenente le informazioni necessarie per l'avvio di Chrome l'app. Il file manifest contiene metadati pertinenti ed elenca le eventuali autorizzazioni speciali necessarie all'app vengono eseguiti tutti i test delle unità.

Una versione ridotta del file manifest dell'utente che carica il video ha il seguente aspetto:

{
  "name": "Google Drive Uploader",
  "version": "0.0.1",
  "manifest_version": 2,
  "oauth2": {
    "client_id": "665859454684.apps.googleusercontent.com",
    "scopes": [
      "https://www.googleapis.com/auth/drive"
    ]
  },
 ...
  "permissions": [
    "https://docs.google.com/feeds/",
    "https://docs.googleusercontent.com/",
    "https://spreadsheets.google.com/feeds/",
    "https://ssl.gstatic.com/",
    "https://www.googleapis.com/"
  ]
}

Le parti più importanti di questo manifest sono "oauth2" e "autorizzazioni" sezioni.

Il comando "oauth2" definisce i parametri richiesti da OAuth2 per fare la sua cosa. Per creare un "client_id", segui le istruzioni in Ottenere il tuo ID cliente. Gli "ambiti" elenca i gli ambiti di autorizzazione per i quali il token OAuth sarà valido (ad esempio, le API .

Le "autorizzazioni" include gli URL a cui l'app accederà tramite XHR2. I prefissi URL sono necessaria per consentire a Chrome di sapere quali richieste interdominio consentire.

Creazione della pagina dell'evento

Tutte le app di Chrome richiedono uno script o una pagina in background per avviare l'app e rispondere agli eventi di sistema.

Nello script background.js, l'Uploader di Drive apre una finestra di 500 x 600 px sulla pagina principale. Inoltre, specifica un'altezza e una larghezza minime per la finestra in modo che i contenuti non diventino troppo elaborati:

chrome.app.runtime.onLaunched.addListener(function(launchData) {
  chrome.app.window.create('../main.html', {
    id: "GDriveExample",
    bounds: {
      width: 500,
      height: 600
    },
    minWidth: 500,
    minHeight: 600,
    frame: 'none'
  });
});

La finestra viene creata come finestra chromeless (frame: "nessuna"). Per impostazione predefinita, il rendering delle finestre viene eseguito con Barra predefinita di chiusura, espansione e riduzione a icona del sistema operativo:

Uploader di Google Drive senza frame

L'utente che ha caricato il video utilizza frame: 'none' per eseguire il rendering della finestra come "slate vuoto" e crea una chiusura personalizzata Pulsante in main.html:

Uploader di Google Drive con frame personalizzato

L'intera area di navigazione è racchiusa in una

(vedi la sezione successiva). Per riordinare un po' l'app, il pulsante di chiusura personalizzato rimane nascosto finché l'utente non interagisce con quest'area:

<style>
nav:hover #close-button {
  opacity: 1;
}

#close-button {
  float: right;
  padding: 0 5px 2px 5px;
  font-weight: bold;
  opacity: 0;
  transition: all 0.3s ease-in-out;
}
</style>

<button class="btn" id="close-button" title="Close">x</button>

In app.js, questo pulsante è collegato a window.close().

Progetta l'app in modo Angular

Angular è un framework MVC, quindi dobbiamo definire l'app in modo che un controller di rete, ne uscirà logicamente. Fortunatamente, questo approccio è banale quando si utilizza Angular.

La visualizzazione è la più semplice, quindi iniziamo da lì.

Creazione della vista

main.html è la "V" in MVC; in cui definiamo i modelli HTML in cui eseguire il rendering dei dati. In Angular, sono semplici blocchi di HTML con una salsa speciale.

In definitiva, vogliamo visualizzare l'elenco di file dell'utente. Per questo, una semplice

<ul>
  <li data-ng-repeat="doc in docs">
    <img data-ng-src=""> <a href=""></a>

    <span class="date"></span>
  </li>
</ul>

Qui si legge esattamente come sembra: apporta una

per ogni documento nel nostro modello dei dati "docs". Ogni elemento contiene l'icona di un file, un link per aprire il file sul web e la data dell'ultimo aggiornamento.

Nota: per rendere valido un codice HTML del modello, utilizziamo gli attributi data-* per lo script di Angular ngRepeat, ma tu non è necessario. Puoi facilmente scrivere il ripetitore come <li ng-repeat="doc in docs">.

Ora dobbiamo indicare ad Angular il controller che supervisionerà il rendering di questo modello. A questo scopo, utilizza l'istruzione ngController per indicare a DocsController di regnare sul modello
```
<body data-ng-controller="DocsController">
<section id="main">
  <ul>
    <li data-ng-repeat="doc in docs">
      <img data-ng-src=""> <a href=""></a> 
      <span class="date"></span>
    </li>
  </ul>
</section>
</body>
```
Tieni presente che qui non vedi il collegamento tra proprietà o listener di eventi per i dati. associazione. Angular sta facendo questo lavoro pesante per noi!

L'ultimo passaggio consiste nel fare in modo che Angular illumini i nostri modelli. Il modo tipico per farlo è includere ngApp fino a tutte le versioni :
```
<html data-ng-app="gDriveApp">
```
Se vuoi, puoi anche limitare l'ambito dell'app a una parte più piccola della pagina. Abbiamo solo un controller in questa app, ma se dovessimo aggiungerne altri in seguito, mettendo ngApp sul primo rende l'intera pagina pronta per Angular.

Il prodotto finale di main.html ha un aspetto simile al seguente:
```
<html data-ng-app="gDriveApp">
<head>
  …

  <base target="_blank">
</head>
<body data-ng-controller="DocsController">
<section id="main">
  <nav>
    <h2>Google Drive Uploader</h2>
    <button class="btn" data-ng-click="fetchDocs()">Refresh</button>
    <button class="btn" id="close-button" title="Close"></button>
  </nav>
  <ul>
    <li data-ng-repeat="doc in docs">
      <img data-ng-src=""> <a href=""></a>  
      <span class="date"></span>
    </li>
  </ul>
</section>
```
Una parola sui criteri di sicurezza del contenuto

A differenza di molti altri framework JS MVC, Angular v1.1.0+ non richiede modifiche per funzionare in un ambiente CSP. Funziona senza bisogno di ulteriori configurazioni.

Tuttavia, se utilizzi una versione precedente di Angular tra la v1.0.1 e la v1.1.0, dovrai indicare Angular per l'esecuzione in "modalità di sicurezza del contenuto". Per farlo, devi includere la direttiva ngCsp. insieme a ngApp:
```
<html data-ng-app data-ng-csp>
```
Gestione delle autorizzazioni

Il modello dei dati non viene generato dall'app stessa. Viene invece compilato da un'API esterna (il API Google Drive). Pertanto, è necessario un po' di lavoro per completare i dati dell'app.

Prima di poter effettuare una richiesta API, dobbiamo recuperare un token OAuth per l'Account Google dell'utente. A questo scopo, abbiamo creato un metodo per aggregare la chiamata a chrome.identity.getAuthToken() e archiviare accessToken, che possiamo riutilizzare per chiamate future all'API Drive.
```
GDocs.prototype.auth = function(opt_callback) {
  try {
    chrome.identity.getAuthToken({interactive: false}, function(token) {
      if (token) {
        this.accessToken = token;
        opt_callback && opt_callback();
      }
    }.bind(this));
  } catch(e) {
    console.log(e);
  }
};
```
Nota: il passaggio del callback facoltativo ci permette di sapere quando il token OAuth viene pronto per l'uso.

Nota: per semplificare un po' le cose, abbiamo creato una libreria, gdocs.js, per gestire le attività dell'API.

Una volta ottenuto il token, è il momento di effettuare richieste all'API Drive e compilare il modello.

Controller Skeleton

Il "modello" per l'Uploader è un semplice array (chiamato documenti) di oggetti il cui rendering quelli

nel modello:

var gDriveApp = angular.module('gDriveApp', []);

gDriveApp.factory('gdocs', function() {
  var gdocs = new GDocs();
  return gdocs;
});

function DocsController($scope, $http, gdocs) {
  $scope.docs = [];

  $scope.fetchDocs = function() {
     ...
  };

  // Invoke on ctor call. Fetch docs after we have the oauth token.
  gdocs.auth(function() {
    $scope.fetchDocs();
  });

}

Nota che gdocs.auth() viene chiamato come parte del costruttore DocsController. Quando il cluster di Angular che creano il controller, ci assicuriamo di avere un nuovo token OAuth in attesa dell'utente.

Recupero dati

Modello presentato. Controller strutturata. Token OAuth a portata di mano. Ti chiedi cosa fare adesso?

È il momento di definire il metodo del controller principale, fetchDocs(). È il cavallo di battaglia del controller, responsabile di richiedere i file dell'utente e di presentare l'array di documenti con i dati delle risposte dell'API.

$scope.fetchDocs = function() {
  $scope.docs = []; // First, clear out any old results

  // Response handler that doesn't cache file icons.
  var successCallback = function(resp, status, headers, config) {
    var docs = [];
    var totalEntries = resp.feed.entry.length;

    resp.feed.entry.forEach(function(entry, i) {
      var doc = {
        title: entry.title.$t,
        updatedDate: Util.formatDate(entry.updated.$t),
        updatedDateFull: entry.updated.$t,
        icon: gdocs.getLink(entry.link,
                            'http://schemas.google.com/docs/2007#icon').href,
        alternateLink: gdocs.getLink(entry.link, 'alternate').href,
        size: entry.docs$size ? '( ' + entry.docs$size.$t + ' bytes)' : null
      };

      $scope.docs.push(doc);

      // Only sort when last entry is seen.
      if (totalEntries - 1 == i) {
        $scope.docs.sort(Util.sortByDate);
      }
    });
  };

  var config = {
    params: {'alt': 'json'},
    headers: {
      'Authorization': 'Bearer ' + gdocs.accessToken,
      'GData-Version': '3.0'
    }
  };

  $http.get(gdocs.DOCLIST_FEED, config).success(successCallback);
};

fetchDocs() utilizza il servizio $http di Angular per recuperare il feed principale tramite XHR. L'accesso OAuth è incluso nell'intestazione Authorization insieme ad altri parametri e intestazioni personalizzati.

successCallback elabora la risposta dell'API e crea un nuovo oggetto doc per ogni voce in feed.

Se al momento esegui fetchDocs(), tutto funziona e viene visualizzato l'elenco dei file:

Recupero dell'elenco di file nell'Uploader di Google Drive

Evviva!

Aspetta,...ci mancano queste fantastiche icone di file. What gives? Un rapido controllo della console mostra di errori relativi a CSP:

Errori CSP nella console per gli sviluppatori

Il motivo è che stiamo cercando di impostare le icone img.src su URL esterni. Ciò costituisce una violazione di CSP. Per esempio: https://ssl.gstatic.com/docs/doclist/images/icon_10_document_list.png. Per risolvere il problema, devi estrarre questi asset remoti a livello locale nell'app.

Importazione degli asset immagine remoti

Affinché CSP smetta di urlarci contro, usiamo XHR2 per "importare" le icone dei file come Blob, quindi imposta img.src a un blob: URL creato dall'app.

Ecco l'aggiornamento successCallback con il codice XHR aggiunto:

var successCallback = function(resp, status, headers, config) {
  var docs = [];
  var totalEntries = resp.feed.entry.length;

  resp.feed.entry.forEach(function(entry, i) {
    var doc = {
      ...
    };

    $http.get(doc.icon, {responseType: 'blob'}).success(function(blob) {
      console.log('Fetched icon via XHR');

      blob.name = doc.iconFilename; // Add icon filename to blob.

      writeFile(blob); // Write is async, but that's ok.

      doc.icon = window.URL.createObjectURL(blob);

      $scope.docs.push(doc);

      // Only sort when last entry is seen.
      if (totalEntries - 1 == i) {
        $scope.docs.sort(Util.sortByDate);
      }
    });
  });
};

Ora che CSP è di nuovo soddisfatto di noi, abbiamo delle utili icone dei file:

Google Drive Uploader con icone di file

Modalità offline: memorizzazione nella cache di risorse esterne

L'ottimizzazione ovvia da fare: non effettuare centinaia di richieste XHR per ogni icona del file ogni chiamata a fetchDocs(). Verifica nella console Strumenti per sviluppatori premendo il pulsante "Aggiorna" il pulsante più volte. Ogni volta, vengono recuperate n immagini:

Modifica successCallback per aggiungere un livello di memorizzazione nella cache. Le aggiunte sono evidenziate in grassetto:

$scope.fetchDocs = function() {
  ...

  // Response handler that caches file icons in the filesystem API.
  var successCallbackWithFsCaching = function(resp, status, headers, config) {
    var docs = [];
    var totalEntries = resp.feed.entry.length;

    resp.feed.entry.forEach(function(entry, i) {
      var doc = {
        ...
      };

      // 'https://ssl.gstatic.com/doc_icon_128.png' -> 'doc_icon_128.png'
      doc.iconFilename = doc.icon.substring(doc.icon.lastIndexOf('/') + 1);

      // If file exists, it we'll get back a FileEntry for the filesystem URL.
      // Otherwise, the error callback will fire and we need to XHR it in and
      // write it to the FS.
      var fsURL = fs.root.toURL() + FOLDERNAME + '/' + doc.iconFilename;
      window.webkitResolveLocalFileSystemURL(fsURL, function(entry) {
        doc.icon = entry.toURL(); // should be === to fsURL, but whatevs.

        $scope.docs.push(doc); // add doc to model.

        // Only want to sort and call $apply() when we have all entries.
        if (totalEntries - 1 == i) {
          $scope.docs.sort(Util.sortByDate);
          $scope.$apply(function($scope) {}); // Inform angular that we made changes.
        }

      }, function(e) {
        // Error: file doesn't exist yet. XHR it in and write it to the FS.

        $http.get(doc.icon, {responseType: 'blob'}).success(function(blob) {
          console.log('Fetched icon via XHR');

          blob.name = doc.iconFilename; // Add icon filename to blob.

          writeFile(blob); // Write is async, but that's ok.

          doc.icon = window.URL.createObjectURL(blob);

          $scope.docs.push(doc);

          // Only sort when last entry is seen.
          if (totalEntries - 1 == i) {
            $scope.docs.sort(Util.sortByDate);
          }
        });

      });
    });
  };

  var config = {
    ...
  };

  $http.get(gdocs.DOCLIST_FEED, config).success(successCallbackWithFsCaching);
};

Nota che nel callback webkitResolveLocalFileSystemURL() chiamiamo $scope.$apply() quando viene visualizzata l'ultima voce. Normalmente non è necessario chiamare $apply(). Angular rileva le modifiche ai dati di automagicamente. Tuttavia, nel nostro caso, abbiamo un ulteriore livello di callback asincrono che Angular non ne è a conoscenza. Dobbiamo indicare esplicitamente ad Angular quando il modello è stato aggiornato.

Alla prima esecuzione, le icone non si troveranno nel file system HTML5 e le chiamate window.webkitResolveLocalFileSystemURL() comporterà il richiamo del callback di errore. Per questo in questo caso, possiamo riutilizzare la tecnica precedente e recuperare le immagini. L'unica differenza questa volta è che ogni blob sia scritto nel file system (vedi writeFile()). La console verifica comportamento:

Alla successiva esecuzione (o quando premi il pulsante "Aggiorna"), l'URL passato a webkitResolveLocalFileSystemURL() esiste perché il file è stato precedentemente memorizzato nella cache. L'app imposta doc.icon al filesystem: URL del file ed evita di dover creare il costoso XHR per l'icona.

Caricamento mediante trascinamento

Un'app di caricamento fa pubblicità falsa se non può caricare file.

app.js gestisce questa funzionalità implementando una piccola libreria dedicata al trascinamento HTML5, chiamata DnDFileController. Consente di trascinare i file dal desktop e caricarli su Google Drive.

Per farlo, basta aggiungere questo codice al servizio gdocs:

gDriveApp.factory('gdocs', function() {
  var gdocs = new GDocs();

  var dnd = new DnDFileController('body', function(files) {
    var $scope = angular.element(this).scope();
    Util.toArray(files).forEach(function(file, i) {
      gdocs.upload(file, function() {
        $scope.fetchDocs();
      });
    });
  });

  return gdocs;
});