Sebastian Witalec Aug 23

Today we’re happy to announce an exciting new way to build web and mobile apps with Angular and NativeScript.

Angular と NativeScript を使ってウェブ版とモバイル（ネイティブ）版をビルドするワクワクするような新しい方法を本日アナウンスすることができて私たちはハッピーです。

First, some background: since the beginning of Angular, you could use NativeScript with Angular to build mobile apps.

まずはじめに、Angular は初期の頃から NativeScript を使ってモバイルアプリをビルドができたということを言っておきます。

NativeScript is an open source framework for building truly native mobile apps with JavaScript. It lets you use your existing Angular skills, and as a result you get a native UI & performance on iOS and Android.

NativeScript は、JavaScript でネイティブのモバイルアプリを作るためのオープンソースフレームワークです。既存の Angular の技術を使うことで、iOS や Android のネイティブな UI やパフォーマンスを実現します。

However, when you needed to build both a web and a native mobile app, you had to create, develop and maintain two separate projects. Although this got the job done, it quickly became apparent that we could do better than that.

しかし、ウェブとネイティブモバイルアプリの両方を作る必要がある時、2つの別々なプロジェクトを作成、開発、維持していかなくてはいけません。この方法でもできないことはないですが、もっと良い方法でできるはずということが急速に明らかになりました。

コードをシェアしたいという夢

This challenge led to a dream of a Code-Sharing Project. One that would allow you to keep the code for the web and mobile apps in one place. One that would allow us to share the business logic between web, iOS and Android, but still be flexible enough to include platform-specific code where necessary.

この課題は、Code-Sharing Project（コードシェアリングプロジェクト）という夢をもたらしました。ひとつは、ウェブとモバイルアプリのコードをひとつの場所でキープできるようにすることでした。もうひとつは、ビジネスロジックをウェブ、iOS、Android 間で共有できるようにしつつ、さらに必要に応じてプラットフォーム専用のコードを含めるために柔軟的にすることでした。

With the dawn of Schematics and ng add we now had a whole new set of possibilities.

Schematics や ng add の登場により、われわれはまったく新しい可能性の固まりを持つことになりました。

To realise the Code-Sharing Dream the Angular and NativeScript teams teamed up to create nativescript-schematics, a schematic that enables you to build both web and mobile apps from a single project.

Code-Sharing Dream を実現するために、Angular と NativeScript のチームは、ひとつのプロジェクトからウェブとモバイルアプリの両方をビルドすることができる schematic「nativescript-schematics」を開発するために連携しました。

Please note that @nativescript/schematics works with @angular/cli 6.1.0 or newer.

@nativescript/schematics は、@angular/cli 6.1.0 以降で動くということに注意してください。

We are looking at a scenario where you can use the Angular CLI with the {N} Schematics to, either:

われわれは、みなさんがどこで Angular CLI と {N} Schematic を使うことができるのかというシナリオを検討しています。

・create a new project with a code-sharing structure, or
・convert an existing web project to a code-sharing structure.

• code-sharing　の構造で新しいプロジェクトを作成するために使えるか、
• または既存のウェブのプロジェクトをcode-sharingの構造に変換するために使えるか。

Then:

それから

・convert existing components and modules to a code-sharing format, and
・generate new components and modules in a code-sharing format.

• 既存のコンポーネントとモジュールを code-sharing のフォーマットに変換し、
• 新しいコンポーネントとモジュールを code-sharing のフォーマット内に生成するために使えるか。

To share or not to share – シェアすること、シェアいないこと

The objective is to share as much code as possible, and break the platform-specific code into separate files.

目標は、できるだけ多くのコードをシェすることと、それぞれのプラットフォーム用のコードを別々のファイルに分離することです。

This usually means that we can share the code for:

これは通常、以下のコードをシェアできるということを意味します。

・the Routes for the navigation
・the Services for the common business logic
・the Component Class definition for the common behaviour of each component

• ナビゲーションのための Routes
• 共通のビジネスロジックのための Services
• それぞれのコンポーネントでの共通的な振る舞いのための Component のクラス定義

While, separating the code for:

一方、コードを分離することの目的は、

・the UI Layer (stylesheets and html) — as you need to use different user interface components in web and NativeScript-built native apps ・the NgModules — so that we can import platform-specific modules, without creating conflicts (i.e. Angular Material Design — which is web only) between web and mobile

• UI Layer（スタイルシートと HTML）のため – ウェブと NativeScript でビルドされたネイティブアプリで異なったユーザーインタフェースコンポーネントを使う必要があるので。
• NgModules のため – そうすることで、ウェブとモバイル間のコンフリクトを発生させることなく（例えば、Angular Material Design はウェブ版のみとなります）、それぞれのプラットフォーム用のモジュールをインポートできるようになります。

Here’s a diagram to show you what that looks like at a high level.

以下は、高レベルでどのように見えるかを示す図です。

Getting started – 始め方

To get started you could either create a new project with a code-sharing structure. Just run ng new with @nativescript/schematics as the collection.

始めるには、まずひとつの方法として、code-sharing 構造で新しいプロジェクトを作成する方法があります。その場合は、@nativescript/schematics を collection として ng new を実行してください。

Just like this:

以下のようにコマンドを実行します。

Note, you may need to install @nativescript/schematics first:

まず、@nativescript/schematics をインストールしておく必要があるということに気をつけてください。

Or we could extend an existing web projects with the capability to build mobile apps with NativeScript, by calling:

もうひとつの方法として、以下を呼び出すことで、既存のウェブプロジェクトを NativeScript を使ってモバイルアプリを作成ための機能を持つように拡張することもできます。

This command adds the NativeScript-specific:

このコマンドは、NativeScript 用の以下のものを追加します。

• npm modules
• AppModule definition
• AppComponent definition
• tsconfig

Build Process – ビルド処理

To complete the story, we need a build process that is capable of using the shared files and the platform-specific ones, and provide a web or mobile app as a result.

ストーリーを完成させるために、共有ファイルとそれぞれのプラットフォーム用のファイルを使用できるようにするビルド処理が必要で、採取的にウェブとモバイルアプリを提供します。

Building for Web – ウェブ版をビルドする

To build a web app, it is “Business as usual”, just use the Angular CLI to do the job.

ウェブアプリをビルドするには、「いつも通り」で、Angular CLI を使ってビルドを行います。

When you call ng serve or ng build, the Angular CLI ignores all NativeScript-specific files — as none of the web files would directly reference any .tns files.

ng serve または ng build を呼び出した時、Angular CLI はすべての NativeScript 用のファイルを無視します。つまり、ウェブのファイルは、.tns ファイルを直接参照することがないためです。

ng serve -> serves a web app from a code-sharing project

ng serve -> code-sharingプロジェクトからウェブアプリを serve します。

"exclude": [
  "**/*.ns.ts",
  "**/*.tns.ts",
  "**/*.android.ts",
  "**/*.ios.ts"
]

Building for Mobile – モバイルアプリをビルドする

In order to build an iOS or an Android app with NativeScript, we need to use the NativeScript CLI with the NativeScript Webpack plugin.

iOS または Android アプリを NativeScript を使ってビルドするために、NativeScript CLI と NativeScript Webpack plugin を使う必要があります。

Call:

以下を呼んでください。

・tns run ios –bundle — to build an iOS app from the code-sharing project
・tns run androind –bundle — to build an Android app from the code-sharing project

• tns run ios --bundle – code-sharing プロジェクトから iOS アプリをビルドします。
• tns run androind --bundle – code-sharing プロジェクトから Android アプリをビルドします。

During the build process, Webpack takes care of providing the .tns files whenever they are available, and as a result hiding the web versions of the same files (virtually, files like home.component.tns.html become home.component.html). While the NativeScript CLI is responsible for building a native mobile app.

ビルド処理中に、Webpack は、.tns ファイルを、それらが利用可能な時であればいつでも提供できるようにする役割を担っていて、結果としてウェブ版の同じファイルを隠すようにしています（実際に、home.component.tns.html というファイルであれば、home.component.html になります）。一方、NativeScript CLI はネイティブモバイルアプリのビルドを担当します。

Code Separation – コードの分離

Before you can start code sharing, we need to know how to separate the web code from the mobile code. This is important, so that we could easily create platform-specific code without creating conflicts.

コードシェアリングを可能とするために、ウェブ版のコードとモバイル版のコードを切り離す方法を見つける必要がありました。これは重要なことで、結果としてコンフリクトを発生させることなく、それぞれのプラットフォームごとのコードを簡単に作ることができるようになりました。

To do that we can use a simple naming convention. By adding a .tns before the file extension, you can indicate that this file is NativeScript-specific, while the same file without the .tns extension is marked as web-specific. If we have just one file without the .tns extension, then this makes it a shared file.

これを行うには、シンプルな命名規則（naming convention）を使います。ファイルの拡張子の前に .tns を追加することによって、このファイルは NativeScript 用のものだと示すことができ、同時に同じファイルで .tns がないものはウェブ用としてマークされます。もし .tns のないファイルしかない場合、このファイルは両方でシェアされるファイルとみなされます。

コンポーネント – Code-Sharing フォーマット

The most common scenario is a component code. Usually we would have:

最も一般的なシナリオは、コンポーネントのコードです。通常は以下のようなファイルを準備することになります。

・name.component.ts — a shared file for the Component Class definition
・name.component.html — a web-specific template
・name.component.tns.html — a mobile-specific template
・name.component.css — a web-specific stylesheet
・name.component.tns.css — a mobile-specific stylesheet

• name.component.ts — コンポーネントのクラスを定義したシェアされるファイル
• name.component.html — ウェブ用のテンプレート
• name.component.tns.html — モバイル用のテンプレート
• name.component.css — ウェブ用のスタイルシート
• name.component.tns.css — モバイル用のスタイルシート

It is also worth noting that in your @Component Decorator the templateUrl and styleUrls point to files without including the .tns extension, as this is handled by the build process.

@Component デコレータ内で、templateUrl と styleUrls には .tns 拡張子を含まないファイルを指定しているというという点にも注目してください。この部分はビルド処理によってハンドリングされます。

@Component({
  selector: 'app-name',
  templateUrl: './name.component.html',
  styleUrls: ['./name.component.css'],
})

Code Separation for NgModules – NgModuleのコードの分離: HttpClient

Code separation is useful when working with NgModules, as often you need to import web- or NativeScript-specific modules.

ウェブ用または NativeScript 用のモジュールを頻繁にインポートする必要があるので、コードの分離は、NgModule を使用する時に役立ちます。

A very good example is when you need to make an HTTP call. In a web app you need to import the HttpClientModule, which provides you with the implementation for the HttpClient.

良い例となるのが、HTTP の呼び出しを行う必要がある時です。ウェブアプリに、HttpClient の実装を提供してくれる HttpClientModule をインポートする必要があります。

However, the way http calls are executed in a browser is different to how they work in iOS and Android. In NativeScript you should use the NativeScriptHttpClientModule, which provides us with the equivalent implementation for the HttpClient.

しかし、http の呼び出しはブラウザで実行され、これは iOS や Android での呼び出し方とは異なります。NativeScript では、HttpClient の実装と同等のものを提供してくれるNativeScriptHttpClientModule を使はなくてはいけません。

Now, you can use the code separation technique to create two versions of the @NgModule — each using a different version of the HttpClientModule — and then with the help of Dependency Injection provide the right implementation of the HttpClient into your service.

（それぞれ HttpClientModule の異なるバージョンを使用している）@NgModule の2つのバージョンを作成し、Dependency Injection（依存性注入）の助けを借りて、適切な HttpClient の実装を service に提供するためのコード分離テクニックがあります。

・my.module.ts — a web module file that imports the HttpClientModule

• my.module.ts — HttpClientModule をインポートするウェブのモジュールファイル

import { HttpClientModule } from '@angular/common/http';
@NgModule({
  imports: [
    HttpClientModule,
    …
  ]
  …
})
export class MyModule { }

・my.module.tns.ts — a mobile module file that imports the NativeScriptHttpClientModule

• my.module.tns.ts — NativeScriptHttpClientModule をインポートするモバイルのモジュールファイル

import { NativeScriptHttpClientModule } from 'nativescript-angular/http-client';
@NgModule({
  imports: [
    NativeScriptHttpClientModule,
    …
  ]
  …
})
export class MyModule { }

・my.service.ts — a shared service file that injects the HttpClient

• my.service.ts — HttpClient をインジェクトする service の共有ファイル

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
@Injectable()
export class MyService {
  constructor(private http: HttpClient) { }
  …
}

Code separation for modules makes up for a simple and a quite elegant solution. It enables you to bring in functionality that has different implementation (for the web and mobile apps) under one hood and as a result maximise the shared code.

モジュールのコード分離はシンプルで非常に洗練された解決策の埋め合わせをします。それにより（ウェブとモバイルアプリの）異なる実装を持った機能をひとつのフードの下に取り込み、結果としてシェアされるコードの価値を大きくすることができます。

Example Project – プロジェクトの事例

If are you curious to see an example of a code-sharing project, with:

以下のような特徴を持った code-sharing project の事例を見たいのであれば、

・shared navigation
・lazy loading
・an auth guard
・code separation on an NgModule with Angular Material components and NativeScript UI plugins
・a single shared user service
・shared components and the separation on component UI
・cute pets to adopt

• 共有ナビゲーション
• 遅延ローディング
• Auth 認証
• Angular Material コンポーネントと NativeScript UI プラグインを使った NgModule の分離
• ひとつの共有されるユーザーサービス
• 共有コンポーネントとコンポーネント UI の分離
• キュートなペットの取り込み

Well then check out our sample project pet-bros-lite, which shows all these code-sharing concepts in action!

サンプルプロジェクト「pet-bros-lite」をチェックしてみてください。実際にこれらのすべてのコードシェアリングのコンセプトが使われています！

Summary – まとめ

As you can see, building for both the web and mobile from a single project is fairly straightforward. You can either start with a fresh project (using ng new), or add mobile to an existing project (using ng add). There is also a simple naming convention to enable code separation, which allows you to cover many scenarios.

見てきたように、ひとつのプロジェクトからウェブとモバイルの両方をビルドすることは、非常に簡単です。（ng new を使った）新しいプロジェクトで始めるか、または既存のプロジェクトに（ng add を使って）モバイルを追加するか、どちらでも可能です。さらに、様々なケースをカバーしてくれるコードの分離を可能にするシンプルな命名規則もあります。

Go ahead and give code sharing a try, as it really is that simple. You are one simple ng add or ng new way from the wonders of code sharing in Angular.

先に進んで、コードシェアリングを試してみてください。それは非常にシンプルです。Angularのコードシェアリングという奇跡によるシンプルなng add または ng new のどちらかひとつの方法を選ぶだけです。

We would love to hear from you, let us know what works for you, what doesn’t, and how things could be improved. Any constructive feedback is always welcome. Please, send feedback here.

みなさんからのご意見をお待ちしています。何が動いて、何か動かなかったか、そしてどうしたら改善されるのかなどお知らせください。建設的なフィードバックであればどんなものでも常に大歓迎です。フィードバックはこちらにお送りください。

Learn more – さらに学ぶには

This article covers the core functionality around sharing code between the web and mobile apps with Angular and NativeScript. There is still more that you might be interested in:

この記事では、Angular と NativeScript を使ってウェブとモバイルアプリ間でコードをシェアすることを中心にコア機能について説明してきました。他にもみなさんが興味を持つであろう以下の内容があります。

・how to develop in a code-sharing project
・the migration process — with migrate-component and migrate-module commands
・the NativeScript-specific generators
・handling libraries with mismatched APIs — that is when we have two similar libraries with a different API interface for web and mobile

• code-sharing project での開発方法
• migrate-component や migrate-module コマンドを使った — マイグレーション処理
• NativeScript 用のジェネレータ
• ミスマッチした API を持つライブラリのハンドリング — ウェブとモバイルの異なった API のインタフェースを持つ ２ つの類似のライブラリを扱う時

To learn more, see our documentation at docs.nativescript.org/angular/code-sharing/intro.

さらに学ぶためには、docs.nativescript.org/angular/code-sharing/intro にあるドキュメントを見てください。

訳者まとめ

ついにAngularもネイティブに対応したということで、Angularの技術者にとってはアウトプットの幅が広がることになり、ネイティブの技術者にとっては開発ツールの選択肢が増えることになりました。これまでもNativeScriptでネイティブアプリにビルドできましたが、NativeScriptは小難しいというイメージがあり、なかなか手が出しにくかったのが現状です。今回の発表で、その難しさを意識することなく、NativeScriptによるネイティブアプリへのビルドができるようになったことは、Angularにとってもプラスになるでしょうし、大変喜ばしいことです。

普段からAngularを書いている方であれば、気軽に試すこともできるのではないかと思います。なお、テンプレート部分に関しては、HTMLのタグではなく、ネイティブアプリに特有のタグを書く必要があるので若干敷居は高くなるかもしれません…（Angular Materialのようなものと思うしかないですね）。あと、今回の記事からは、ネイティブアプリ版の画面を確認する方法がわかりませんでした。いずれにせよ私もまだ記事を読んだだけで何も試していないので、実際にネイティブアプリとして動くまで試したら、またこちらのブログで内容をまとめてみる予定です。