Tworzenie aplikacji za pomocą AngularJS

Ważne: Chrome wycofa obsługę Aplikacji Chrome na wszystkich platformach. Przeglądarka Chrome Chrome Web Store będzie nadal obsługiwać rozszerzenia. Przeczytaj zapowiedź i dowiedz się więcej dowiedz się więcej o przenoszeniu aplikacji.

Ten przewodnik pomoże Ci zacząć tworzyć aplikacje Chrome przy użyciu platformy MVC AngularJS. Do użyjemy narzędzia Angular w praktyce. Będziemy odnosić się do rzeczywistej aplikacji utworzonej za pomocą platformy, Narzędzie do przesyłania plików na Dysk Google. Kod źródłowy jest dostępny na GitHubie.

Informacje o aplikacji

Program do przesyłania plików na Dysk Google umożliwia użytkownikom szybkie przeglądanie plików przechowywanych w konto Dysku Google oraz przesyłać nowe pliki za pomocą interfejsów API przeciągania i upuszczania HTML. To świetny przykład budowania aplikacji, która komunikuje się z jednym z interfejsów API Google; w tym przypadku Google API Dysku.

Uwaga: możesz też tworzyć aplikacje korzystające z interfejsów API lub usług innych firm, które obsługują protokół OAuth2. Zobacz uwierzytelnianie inne niż konto Google.

Program do przesyłania używa protokołu OAuth2 do uzyskiwania dostępu do danych użytkownika. Interfejs chrome.identity API obsługuje pobieranie danych Token OAuth dla zalogowanego użytkownika, dzięki czemu nasza ciężka praca jest wykonana! Gdy mamy już od dawna token dostępu, aplikacje uzyskują dostęp do danych użytkownika za pomocą interfejsu Google Drive API.

Najważniejsze funkcje tej aplikacji:

• Automatyczne wykrywanie przez AngularJS dla CSP
• Renderowanie listy plików pobranych z interfejsu Google Drive API.
• HTML5 Filesystem API do przechowywania ikon plików offline.
• Przeciąganie i upuszczanie HTML5 – do importowania/przesyłania nowych plików z pulpitu
• XHR2 do ładowania obrazów, między domenami
• chrome.identity API do autoryzacji OAuth.
• Ramki bez Chrome określające wygląd i sposób działania aplikacji

Tworzę plik manifestu

Wszystkie aplikacje Chrome wymagają pliku manifest.json zawierającego informacje potrzebne do uruchomienia Chrome aplikację. Plik manifestu zawiera odpowiednie metadane i listę wszelkich specjalnych uprawnień wymaganych przez aplikację. bieganie.

Skrócona wersja pliku manifestu programu przesyłającego wygląda tak:

{
  "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/"
  ]
}

Najważniejsze części tego pliku manifestu to „oauth2” i „uprawnienia” sekcji.

Metoda „oauth2” definiuje parametry wymagane przez OAuth2. Aby utworzyć „client_id”, wykonaj czynności opisane w artykule Uzyskiwanie identyfikatora klienta. „Zakresy” Wymień zakresów autoryzacji, dla których token OAuth będzie prawidłowy (np. do interfejsów API, z których aplikacja chce korzystać dostęp).

Uprawnienia zawiera URL-e, do których aplikacja będzie uzyskiwać dostęp za pośrednictwem XHR2. Prefiksy adresu URL to wymagane, aby przeglądarka Chrome mogła określić, na które żądania między domenami zezwala.

Tworzenie strony wydarzenia

Wszystkie aplikacje Chrome wymagają skryptu lub strony w tle do uruchamiania aplikacji i reagowania na zdarzenia systemowe.

W skrypcie background.js program Drive przesyłający otwiera na stronie głównej okno o wymiarach 500 x 600 pikseli. Dodatkowo określa minimalną wysokość i szerokość okna, by zawartość nie była zbyt obcięta:

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'
  });
});

Okno zostanie utworzone jako okno chromeless (ramka: „none”). Domyślnie okna są renderowane za pomocą Domyślny pasek zamykania/rozwijania/minimalizacji w systemie operacyjnym:

Przesyłający używa frame: 'none' do renderowania okna jako „pustej planszy” i tworzy niestandardowe zamknięcie przycisk w aplikacji main.html:

Cały obszar nawigacyjny jest otoczony

(patrz następna sekcja). Aby nieco uporządkować aplikację, niestandardowy przycisk zamknięcia jest ukryty, dopóki użytkownik nie wejdzie w interakcję z tym obszarem:

<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>

W app.js ten przycisk jest podłączony do window.close().

Projektowanie aplikacji w sposób Angular

Angular to platforma MVC, dlatego trzeba zdefiniować aplikację w taki sposób, aby model, widok jeśli kontroler logicznie go z niej nie wyjdzie. Na szczęście przy korzystaniu z Angular jest to banalne.

Widok jest najłatwiejszy, więc zacznijmy od niego.

Tworzenie widoku

main.html to „V” w MVC; w którym definiujemy szablony HTML. W Angular to proste bloki kodu HTML z kilkoma specjalnymi składnikami.

Chcemy wyświetlić listę plików użytkownika. Do tego celu

jest sensowna. Fragmenty kodu Angular są wyróżnione pogrubieniem:

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

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

Wygląda to dokładnie tak: znacznik

• dla każdego dokumentu w „dokumentach” naszego modelu danych. Każdy element zawiera ikonę pliku, link do pliku w internecie oraz datę ostatniej aktualizacji.
  Uwaga: aby szablon kodu HTML był prawidłowy, używane są atrybuty data-* dla tagu Angular ngRepeat, ale nie musisz. Możesz z łatwością zapisać powtarzający się <li ng-repeat="doc in docs">.

  Następnie musimy poinformować Angular, który kontroler będzie nadzorować renderowanie tego szablonu. W tym celu użyj dyrektywy ngController, aby nakazać DocsController przejęcie kontroli nad szablonem

  <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>
  

  Pamiętaj, że tutaj podłączymy detektory zdarzeń lub właściwości danych. i powiązania. Angular wykonuje ciężką pracę za nas.

  Ostatnim krokiem jest dodanie Angular do szablonów. Zazwyczaj jest to możliwe dzięki ngApp do końca :

  <html data-ng-app="gDriveApp">
  

  Możesz też ograniczyć zakres aplikacji do mniejszej części strony. Mamy tylko jeden kontroler w tej aplikacji, ale gdybym mógł dodać ich później, umieść ngApp w pierwszej sprawia, że cała strona jest gotowa do użycia w Angular.

  Ostateczna wersja produktu (main.html) wygląda tak:

  <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>
  

  Uwaga na temat Content Security Policy

  W przeciwieństwie do wielu innych platform JS MVC, Angular w wersji 1.1.0 lub nowszej nie wymaga wprowadzania poprawek, aby działać w ścisłej CSP. To po prostu działa.

  Jeśli jednak używasz starszej wersji Angular w wersjach od 1.0.1 do 1.1.0, musisz Angular, aby działać w „trybie zabezpieczeń treści”. W tym celu dodaj dyrektywę ngCsp wraz z parametrem ngApp:

  <html data-ng-app data-ng-csp>
  

  Autoryzacja obsługi

  Model danych nie jest generowany przez samą aplikację. Jest ono wypełniane przez zewnętrzny interfejs API (parametr Google Drive API). Dlatego musisz wykonać pewną pracę, aby wypełnić dane aplikacji.

  Przed wysłaniem żądania do interfejsu API musimy pobrać token OAuth konta Google użytkownika. W tym celu utworzyliśmy metodę pakowania wywołania do funkcji chrome.identity.getAuthToken() i przechowywania accessToken, który możemy wykorzystać ponownie w przyszłych wywołaniach interfejsu Drive API.

  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);
    }
  };
  

  Uwaga: przekazanie opcjonalnego wywołania zwrotnego pozwala nam dowiedzieć się, kiedy token OAuth wszystko gotowe.
  Uwaga: aby nieco uprościć ten proces, utworzyliśmy bibliotekę gdocs.js, która służy do obsługi zadań interfejsu API.

  Gdy otrzymamy token, czas wysłać żądania do interfejsu Drive API i wypełnić model.

  Kontroler do szkieletu

  Model dla narzędzia do przesyłania to prosta tablica (nazywana dokumentami) obiektów, które będą renderowane jako tamte

• w szablonie:

  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();
    });
  
  }
  

  Zwróć uwagę, że funkcja gdocs.auth() jest wywoływana jako część konstruktora DocumentController. Kiedy Angular kontrolerów tworzą wewnętrzne firmy, możemy zapewnić, że na użytkownika czeka nowy token OAuth.

  Pobieram dane

  Szablon rozłożony. Kontroler jest rusztowany. Token OAuth. Co dalej?

  Czas zdefiniować główną metodę kontrolera fetchDocs(). To koń roboczy kontrolera, odpowiada za żądania plików użytkownika i wypełnianie tablicy dokumentów danymi z odpowiedzi interfejsu 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() używa usługi $http Angular do pobierania głównego kanału przez XHR. Dostęp przy użyciu protokołu OAuth jest umieszczany w nagłówku Authorization wraz z innymi niestandardowymi nagłówkami i parametrami.

  successCallback przetwarza odpowiedź interfejsu API i tworzy nowy obiekt dokumentu dla każdego wpisu w kanału.

  Jeśli uruchomisz teraz fetchDocs(), wszystko działa i pojawi się lista plików:

  

  Hurra!

  Chwila...brakuje nam tych pięknych ikon dla plików. Dlaczego? Szybkie sprawdzenie konsoli pokazuje kilka błędów związanych z CSP:

  

  Powodem jest to, że próbujemy ustawić ikony img.src na zewnętrzne adresy URL. Jest to naruszenie zasad CSP. Dla: przykład: https://ssl.gstatic.com/docs/doclist/images/icon_10_document_list.png. Aby to naprawić, które trzeba pobrać lokalnie do aplikacji.

  Importuję zdalne komponenty z obrazem

  Aby CSP przestał na nas krzyczeć, używamy XHR2 do „importowania” ustaw ikony plików jako obiekty blob, a następnie ustaw img.src na konto blob: URL utworzone przez aplikację.

  Oto zaktualizowany kod successCallback z dodanym kodem XHR:

  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);
        }
      });
    });
  };
  

  Teraz, gdy CSP znów jest z nami zadowolony, mamy ładne ikony plików:

  

  Przejście w tryb offline: buforowanie zasobów zewnętrznych w pamięci podręcznej

  Oczywista optymalizacja, którą należy wprowadzić: nie wysyłaj setek żądań XHR dla każdej ikony pliku za każde połączenie z numerem fetchDocs(). Sprawdź to w konsoli Narzędzi dla programistów, klikając „Odśwież” kilka razy. Za każdym razem, gdy pobieranych jest n obrazów:

  

  Zmodyfikujmy usługę successCallback, aby dodać warstwę buforowania. Dodatki są wyróżnione pogrubieniem:

  $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);
  };
  

  Zwróć uwagę, że w wywołaniu zwrotnym webkitResolveLocalFileSystemURL() wywołujemy $scope.$apply(), gdy ostatni wpis. Normalnie dzwonienie pod numer $apply() nie jest konieczne. Angular wykrywa zmiany w danych automagicznie. W naszym przypadku jest jednak dodatkowa warstwa asynchronicznego wywołania zwrotnego, Angular nic nie wie. Musimy wyraźnie poinformować Angular o aktualizacji modelu.

  Przy pierwszym uruchomieniu ikony nie będą znajdować się w systemie plików HTML5, a wywołania funkcji Funkcja window.webkitResolveLocalFileSystemURL() spowoduje wywołanie jej wywołania zwrotnego. Do tego celu możemy użyć tej techniki i pobrać zdjęcia. Tym razem różni się tylko tym, że: aby każdy obiekt blob był zapisany w systemie plików (patrz writeFile()). Konsola to zweryfikuje zachowanie:

  

  Po następnym uruchomieniu (lub po naciśnięciu przycisku „Odśwież”) adres URL przekazany do Plik webkitResolveLocalFileSystemURL() istnieje, ponieważ został on wcześniej umieszczony w pamięci podręcznej. Aplikacja doc.icon do filesystem: URL pliku i uniknie tworzenia kosztownego XHR dla ikony.

  Przesyłanie metodą „przeciągnij i upuść”

  Aplikacja przesyłająca reklamuje się, jeśli nie może przesyłać plików.

  Plik app.js obsługuje tę funkcję, implementując małą bibliotekę opartą na technologii „Przeciągnij i upuść” HTML5 o nazwie DnDFileController Umożliwia przeciąganie plików z komputera i przesyłanie ich na Dysku Google.

  Samo dodanie tego kodu do usługi gdocs załatwia sprawę:

  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;
  });