前回はAndroidに関する設定をした。
今回は引き続き、iOS版の準備。 Androidの準備はちょっと長く、複雑なところもあったのでハマることもあったと思うけど、iOSに関しては簡単で時間もかからないのでご安心を。 これを一つの記事にするには忍びないくらい・・・
AppStoreから最新版をインストール。
下のXcodeのアイコンからインストール可能！
iOS版特有の環境設定は以上。
それ以外で必要な設定は共通の設定になるので次回。
Android版の開発準備が整っていない方は、共通の項目に行く前に以下のページを参照。
次回、6章-3 Cordovaでハイブリッドアプリ開発環境を整える【共通】- 【連載】ハイブリッドアプリの最新情報とその動向【Corodva】
AndroidStudioの日本語化はかなり簡単なので、以下の手順に沿って進めれば5分で終わる。
以下のページにいって、「DOWNROAD ZIP」をクリック。
https://github.com/yuuna/IDEA_resources_jp9 
リソースファイルの「resources_jp.jar]」を「Applications/AndroidStudio.app/Contents/lib」の下に置く。
コマンドラインからの実行は以下のとおり
$ cp ~/Downloads/IDEA_resources_jp-master/resources_jp.jar /Applications/"Android Studio.app"/Contents/lib/
Android Studioを再起動すれば日本語化されているはず。
CordovaではAndroid、Blackberry10、iOS、OS X、Windowsなどに向けてのアプリ開発できるが、今回はAndroid版とiOS版に限っている。
AndroidやiOS向けに開発を行うには、それぞれ独自の設定が必要で、かつ共通の設定もある。それを一つの記事にすると少し長くなってしまうので、Android版の設定とiOS版の設定と共通の設定の3つに分けて解説をしていく。また今回はMacOS上での環境構築。Windowsについては時間があれば後日。
今回はAndroid独自の設定。ちょっと複雑で、時間もかかるので1時間〜1時間半程度、集中できる時間にやった方がいい。iOSは簡単なのに・・・
1.JDKのインストール
2.Android SDKのインストール
3.Android SDKパッケージの追加
4.環境設定変更
以下のサイトからJDK7、もしくはそれ以降をインストール。現状、JDK8は推奨されていないので、JDK7の方を（画像はJDK8でやっているが手順は同じなので気にせず）
→JDK7のインストール
上記リンクに飛ぶと、以下の画面が表示される。
矢印で示した部分「Accept License Agreement」にチェックを入れて、Mac OS X用をダウンロード。
ダウンロードしたものを開くと以下の画像のようになるので、ダブルクリック。するとインストーラが立ち上げるので、特に変更を加えることなく「続ける」を押してインストールを進める。
インストールが終わったら、正しくインストールされているかバージョンの確認。
コマンドラインから
java -version
上記のコマンドを実行すると、「java version "1.8.x_xx"」のように表示される。
されない場合は正しくインストールされていない。
Android用プラグインを作成しない場合は Android Stand-alone SDK Toolsからのインストールで十分だけど、今回は開発に幅を持たせるという意味からAndroid Studioをインストール。
詳細なインストール手順は以下の通り。
Android Studio と SDK Tools のダウンロード | Android Developers
上記リンクから。
まずはダウンロード
左下にある「DOWNLOAD ANDROID STUDIO FOR MAC」という緑色の部分をクリック（赤い矢印）
そうすると同意を求める文章が出てくるので、該当箇所にチェックを入れてダウンロードを開始。
次にアプリケーションフォルダへの移動
ダウンロードしたもの（.dmg)を立ち上げると、以下の画面が立ち上がるのでAndroid StudioをApplicationsへドラッグ&ドロップ。
続いて、AndroidStudioの起動
Android Studioが正常に起動すれば完了。 その他設定については次の「Android SDKパッケージの追加」で行う。
※Android Studioの日本語化について。
Android Studioを開発で利用することはあまりないので、不要かと思うが実施する方は以下のページを参照。
Android SDK をセットアップする場合、少なくとも最新の SDK Tools と Android プラットフォームのダウンロードが必要。今回は必要最低限のものだけダウンロード。
まず、AndroidStudio SDK Managerの起動
Android Studioを起動すると画像の左側の画面が表示される。ここで「Configure」を選択し、「SDK Manager」をクリック。
SDK Tools、Platformの入手
画像のように、「Android SDK」を選択し、ページ下部の「launch Standalone SDK Manager」をクリック。 すると以下の画面が立ち上がる。
Toolsディレクトリ直下にある以下のものにチェックをつける（最後にまとめてインストールするので今はチェックをつけるだけ)
・Android SDK Tools
・Android SDK Platform-tools
・Android SDK Build-tools（最新バージョン）
また、少し下に移動するとAndroid x.x.x のようにバージョンごとのディレクトリがあるので、開発対象バージョンのディレクトリを開く。例ではAndroid 6.0。
ディレクトリのなかの、SDK Platformにチェックをいれる。また以下の画像で「Installed」となっているものはチェックをつけておく。自分の画面で既に「Installed」と表記されているものはそのままで大丈夫。 「Update」という表記されているものはチェックをつける必要がある。
追加API用のサポートライブラリを取得する
続いて、追加API用のサポートライブラリやその他のAPI用の「Google Play」サービスを入手する。
画面の下の方に「Extras」ディレクトリがあるので、そこで以下のものを選択。
・Local Maven repository for Support Libraries
・Android Support Library
・Google Repository
・Google Play Service
・Intel x86 Emulator Accelerator (HAXM installer)
パッケージをインストールする
必要なパッケージをすべて選択したら、インストール。
右下の[Install ? packages] をクリック。
次のウィンドウで、左側のパッケージ名を1つずつダブルクリックし、各パッケージの使用許諾契約に同意する。最後に[Install] をクリック。
SDK Manager のウィンドウの1番下に、ダウンロードの進捗状況が表示されるので、ダウンロードが終わるまでSDK Managerを終了しないこと。SDK Managerを終了すると、ダウンロードはキャンセルされてしまう。
Androidのビルド用にantが必要なのでインストール。
コマンドラインから以下のコマンドを実行する。
$ brew install ant
成功すれば、以下のような表示がでる。
==> Downloading https://archive.apache.org/dist/ant/binaries/apache-ant-1.9.4-bi
######################################################################## 100.0%
以上で必要なものは揃ったので、用意したものを使えるように環境変数の設定を行う。
CordovaCLIツールを正しく機能させるために環境変数の設定する必要がある。 ダウンロードした、Android SDKの「tools」と「platform-tools」にパスを通す。
まずは現状のPATHを確認
$ echo $PATH
現在の状態が表示されます。
/usr/local/sbin:/usr/local/sbin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
ここは人によって違うので、上記と同じでなくても気にしない。
以下のコマンドでPATHを通す。
「**USER名**」の部分は環境に合わせて変える。
$ export PATH=/Users/**USER名**/Library/Android/sdk/tools:$PATH
$ export PATH=/Users/**USER名**/Library/Android/sdk/platform-tools:$PATH
変更を適用。
$ source ~/.bash_profile
変更が適応されたかの確認。
$ echo $PATH
以下のように太青文字部分が追加されていれば完了。
/Users/USER名/Library/Android/sdk/platform-tools:/Users/USER名/Library/Android/sdk/tools:/usr/local/sbin:/usr/local/sbin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
以上でAndroid開発の事前準備は終了。
その他にも設定が必要だけど、共通の設定なので続きは以下の記事を。
上記の記事に入る前にiOSの設定が必要なので、次回はiOSの環境を整える。Androidは結構複雑だけど、iOSは簡単なので！
6章-2 Cordovaでハイブリッドアプリ開発環境を整える【iOS】 - 【連載】ハイブリッドアプリの最新情報とその動向【Corodva】
今回は過去の2つの記事を総合的にまとめたもの。
それぞれハイブリッドアプリに適している状況について書いたが、観点が異なるので、別々に読むと分かりにくかった。なのでそれらを合わせて紹介する。
一つ目の記事はハイブリッドアプリ開発について対外的な観点から評価した。
二つ目に記事は業務的な観点での評価。
以下にハイブリッドアプリ開発を使うのに最適なのはどのような状況なのかをまとめた。
ハイブリッドアプリとして開発した場合に、ユーザーに満足してもらう操作性を実現するという大前提をクリアしないとだめ。それを満たすことができないのならネイティブで作るべき。開発コストが低いからと言って、高速処理が必要なアプリをハイブリッドアプリとして作っても、ユーザーに満足してもらえずに、アプリを使ってもらえなくなる。ネイティブでなくても心地よい操作性を実現できるなら、ハイブリッドアプリとして開発しても問題はない。
これらは比較的再訪問率の低いジャンルのアプリ。なので、アクティブユーザーをより多く獲得するためには複数のプラットフォームに対応する必要が出てくる。でも複数のプラットフォームに対応するため時間とお金をたっぷりかけると、売上が良くても利益が出ないなんて事も・・・ できるだけそういったことをなくすためにもハイブリッドアプリのスピーディーな開発と優れたメンテナンス性を有効活用したいところ。
ゲームのように全体的にパフォーマンスを求められるアプリは厳しい。 でも一部にはパフォーマンスが求められるけど、他の部分ではそのような心配はないアプリであればハイブリッドアプリが最適。パフォーマンスが求められる部分だけをネイティブで書いて高速化を実現し、それ以外の部分では開発コストが低く、メンテナンスもしやすいHTMLやJavaScriptで記述していく。そうすることで必要なパフォーマンスと健全なアプリ運営が実現できる。
プロジェクトに参加する人数が少なかったり、開発期間が十分でない場合はハイブリッドアプリが最適。
開発だけでなく、メンテナンスも少人数で進めていくとなればハイブリッドアプリのクロスプラットフォーム性が後々の作業を楽にしてくれる。
逆に、プロジェクトに十分な時間と、人数を動員できるならネイティブで開発すればいいと思う。
アプリが成功するかどうかはリリースしてみないとわからない。市場調査などを行ってから、自信を持ってリリースしても実際はどうなるか・・・
時間とお金をかけて作成したアプリが無駄になってしまうのはもったいないし、場合によっては利益が出ないだけでなく、損失につながる場合もある。そうなったときの損失や無駄を減らすためにできるだけリスクの低いアプリ開発、つまりハイブリッドアプリがおすすめ！
■パフォーマンスと開発コスト削減を両立したい場合
■再訪問率の低いジャンルのアプリ
■開発・メンテナンスコストの高いアプリ
■あまりリスクを負いたくないアプリ
以上がハイブリッドアプリに最適な状況のまとめ。
次回はハイブリッドアプリ開発用フレームワーク「Cordova」の開発環境を整える！
以下の記事の中でハイブリッドアプリ開発のエキスパートたちが、ハイブリッドアプリについて語っている。これを簡単にまとめた。詳細はリンク先を！！
デザイナーとエンジニアの分担作業がしやすい。
ハイブリッドアプリはUIのデザインはコーディングも含めてデザイナーに任せやすい。 エンジニアはロジックに集中できる。 早い・安いだけではなく、エンジニアのモチベーションに寄与することも多い。
設計書通りに作ってみても、触ってみたら「やっぱりこうしよう！」といった修正点がでてくるはず。ハイブリッドアプリ開発では、UI側作成のスピード感が際立っているので、プロトタイプをスピーディーに作成し、実装とUIのテスト・修正などを並行して進めることができる。これは社内プロダクトよりも、外注の案件で効果を発揮する点だと思う。もちろん社内の案件でも十分活躍するが。
素早くリリースして、ユーザーの反応を見る。 開発コストの低いハイブリッドアプリでリリースして、ユーザーの様子を見る。状況に応じてネイティブシフトしてもいいし、そのままの形で続けるのもいい。はじめからAndroidとiPhone用のネイティブアプリを両方開発するより、リスクが少ない。
今回の内容はリンク先をじっくり見てもらえたらと思って簡単にまとめたが、業務的な観点からハイブリッドアプリを評価してみた。前回の記事は業務的というよりは対外的な観点での評価。
もともと、開発する方法（ハイブリッドかネイティブかWebか）の選定の手助けとなればと思ってまとめたが、やはり難しい。どの開発手法を使うのか、今回の記事と前回の記事をまとめてみたので、興味のある方は是非。
【連載】ハイブリッドアプリの最新情報とその動向【Corodva】- 5.5章 ハイブリッドアプリ開発に適したアプリとは？
今までハイブリッドアプリの概要や、動向についてまとめてきた。
次回からはハイブリッドアプリを開発するための環境を構築していく。使うのは Cordova。Mac上での開発を想定して準備をしていく。Monacaについても軽く触れる予定。お楽しみに！！
次回、「【連載】ハイブリッドアプリの最新情報とその動向【Corodva】- 6章 Cordovaの開発環境を整える【iOS、Android】」
前回まででハイブリッドアプリの概要、ハイブリッドアプリを使うに当たってのメリット・デメリットなどをまとめてきた。 その中で出てきた課題の一つに、ハイブリッドアプリとして開発するのか、ネイティブとして開発するのか、Webアプリとして開発するのかを決めるのが難しいという点を挙げたが、実際にかなり難しくて、あとになって「こっちにしておけばよかった！」と思うことも多々ある。
だけど、それは”後悔”だけで済まない話で、結果的にアクティブユーザーの獲得やアプリの動作状況などにも影響を与えてくるため、アプリの存続にかかわってくる、なんてことにもなりうる。
そうならないように、現状のアプリ業界とアプリ開発の動向を探ってみたので、ここでまとめる。
まずはアプリ業界の全体像を。
日本国内でのスマホOSにシェアは
1位がiOSの50%程度
2位がAndroidの49%程度
+その他
といった感じ。(2016年1月時点)
AndroidとiOSが全体の99%以上を占めている。ちなみに2015年8月時点ではこのようになっている。
参考：Smartphone OS sales market share – Kantar Worldpanel ComTech
近年Android勢が多くなってきているという情報もあったが、どうやらiOSが勢力を回復してきたらしい。国外のスマホOSのシェアもこちらのサイトで見ることができるので、きになる方はどうぞ。
要するに、世界的にAndroidがトップシェアを維持している、ということ。
複数のプラットフォームに対応したアプリの開発を考えているとしたら、Android版とiOS版に絞って、他のプラットフォームは避けるのが現実的だと思う。
スマホOSのシェア(国内)
アプリの登録数についても同様で、AppStore(iOS),GooglePlay(Android)の2強状態。
参考：App Stores Growth Accelerates In 2014 | App store Intelligence from appFigures
AppStoreへの登録アプリ数をGooglePlayが追い越したのもわかる。Amazonも結構頑張っている印象。これは2014年の情報なので、現在はAppStoreとGooglePlayの差が広がっていると思う。たぶん。
AndroidとiOSではライバルが多く、作成したアプリが埋もれてしまうという見方もある・・・ そういった考えの中では、ライバルが少ない他のプラットフォーム向けのアプリもいいかもしれないがリスクは高い。なのでやはりAndroidとiOSに絞るべきかと思う。
アプリストアへのアプリ登録数
■GooglePlayがAppStoreを追い抜きトップに
■GooglePlayとAppStoreの2強状態
続いて、ユーザーのアプリに関する動向をまとめた。
参考：Apps Solidify Leadership Six Years into the Mobile... | Flurry Insights Blog
これをみるとネイティブの利用時間割合が86%、それに対してWebアプリが14%となっている。この理由のひとつとして、インストールして使うかどうかというの点がある。
インストールして使うネイティブアプリは画面上にアイコンがあって、そのアイコンをタップすればアプリが起動できるため、ユーザーへの負担が少ない。 逆に、Webアプリはブックマークやブラウザ検索を経ての利用になるのが、ユーザーにとっては不便で、再訪問率が著しく低下するといわれている。
単にネイティブやハイブリッドアプリの割合が高いからということもできる。
(※ハイブリッドアプリはユーザー側からみるとネイティブアプリと同じ）
ユーザーが使うアプリの種類
■圧倒的にネイティブアプリを使う時間が長い
参考：Pull back the curtain on mobile with the first-ever Mobile Benchmark report
このグラフが表しているのは、アプリのダウンロードから一週間後に再訪問してくれるユーザー割合。これをみると、ユーザーの15%（平均）くらいしかアプリを起動してくれない。 ジャンルによっては5%程度というのもある。アクティブユーザーの獲得がかなり困難であることがわかる。
以下のジャンルについては比較的、再訪問率が高い。
■ゲーム
■ソーシャル
■ビジネス
一方で、以下のジャンルは低くなっている。
■飲食
■旅行
■エンタメ
アプリの継続利用ユーザー
■ダウンロードから一週間後の再訪問ユーザーの割合は15％程度
■ジャンルによっても再訪問率が異なる。
米国、調査会社Gartnerによると2016年、企業向けアプリのうち約50%がハイブリッドアプリになるといわれている。
また、2017年には90%程度がHTML5化になるという予測
ただし、これはネイティブが廃れることを意味しているわけではなく、現在よりも棲み分けが進行するという意味。たとえばゲーム業界（DeNA、Gree、サイバーエージェントなど）ではネイティブシフトの動きが顕著になっている。
ハイブリッドアプリの台頭
■ハイブリッドアプリは今後のアプリ開発の主流に
■ゲームなど複雑なサービスはネイティブ
■簡潔なアプリはハイブリッドアプリorWebアプリ
ハイブリッドアプリの開発フレームワークにもさまざまなものがあるが、今はCordovaがハイブリッドアプリ開発で最も使われてる。
ハイブリッドアプリのデファクトスタンダード
■ハイブリッドアプリ開発ではCordovaが最も使われている
ここまでのまとめ
スマホOSのシェアやアプリ登録数などを見てみるとAndroidとiOSの2つがほとんどの割合を占めているので、複数のプラットフォームに対応するアプリを作成する場合、費用対効果を考えるとiOS版とAndroid版に絞ったほうが良い。
特にAndroidはOSシェア、ダウンロード数などがiOSよりも多いので、技術的にAndroidアプリとiOSアプリを作ることができて、どっちかだけの開発を考えている場合はAndroidの方がおすすめ。
ユーザーがネイティブアプリに消費する時間は、Webアプリよりも圧倒的に多い。アプリの起動が楽であることが一つの要因だと思う。
またアプリダウンロードの一週間後に再訪問してくれるユーザーの割合は平均して15%程度で、アプリのジャンルによってその数値も異なる。
アプリを成功させるにはアクティブユーザーの獲得が必須。
上記のことを参考に考えると、アクティブユーザーを増やす方法は２つ。・ユーザーの絶対数が多いプラットフォームでの配布(Android、iOS)
・比較的、再訪問率の高いジャンルのアプリを作成する
ハイブリッドアプリ開発の割合は年々増加してきている。そのため、開発環境も充実してきているとともに、以前から言われていたハイブリッドアプリの欠点についても克服されつつある。
そのハイブリッドアプリ開発のなかで最も使われているのがCordovaであり、多くの企業が開発のためのツールを提供している。
■理想は両方、どちらかを選ぶならAndroid！技術的な観点から考えて決めるといい！
■アクティブユーザーを獲得するにはネイティブアプリかハイブリッドアプリがおすすめ！
■ハイブリッドアプリ開発なら、環境が充実しているCordova！
次回は今回の内容と関連付けて、ハイブリッドアプリ開発の事例などを紹介する。「【連載】ハイブリッドアプリの最新情報とその動向【Corodva】- 5章 ハイブリッドアプリ開発はどのように使われているのか」というタイトルで書いていく。
前回はハイブリッドアプリがネイティブアプリ・Webアプリと比較してどのように違うのかをまとめた。
今回は、前回の記事をもとにハイブリッドアプリのメリットとデメリットを紹介。
若干前回と被るけど、前回の内容を分かりやすくまとめるのに加えて、他にも伝えたいことを。
表には書いてないけど、ハイブリッドアプリのメリットの一つに
パフォーマンスを求めるところはネイティブでの実装！！
というものがある。これが「ハイブリッド」と呼ばれる所以であり、開発にかかる時間的・技術的コストの低いWeb開発と、パフォーマンスの高いネイティブ開発、それぞれの良いところを組み合わせて開発ができる。 基本的には開発に時間のかからないWeb技術での開発。アプリ内の速度を求める部分に関してはネイティブでの記述で対応する。これはハイブリッドアプリにしかできない。
■開発コストを抑えることができる
■クロスプラットフォーム開発が可能
■Web技術の再利用ができる
■メンテナンス性に優れている
■オフラインでの利用が可能
■公式ストアでの配信が可能で、信頼性と集客性に優れてる
■デバイス機能の利用
クロスプラットフォーム開発が可能であり、またWeb開発技術の再利用ができるので開発コストを低く抑えることが可能。
メンテナンス性に優れている点や、アプリストア経由でなくても機能のアップデートができることが大きな強みになっている。
公式ストアからの配信が可能で、集客性や信頼性という点でもメリットがあり、ユーザーはアプリをインストールして使うため、基本的にはオフラインでもアプリが利用できる。
Webアプリでは不可能だったネイティブ機能へのアクセスも可能になっており、開発の幅も広がってきている。
■動作速度がネイティブに比べて遅い
■開発制約が多くなることがある
■公式ストアの審査を通りにくい
■デバイス機能の利用範囲が開発ツールに依存する
■ネイティブUIが使えない
動作速度はネイティブと比較して遅く、高速処理を必要とするアプリなどには向かない。
公式ストアを経ての配信となるため、開発に際しての制約が多くなる場合があり、ネイティブアプリと比較して公式ストアの審査を通りにくいという点も開発者としては意識しておく必要がある。
またネイティブ機能へのアクセスが可能だが、全ての機能にアクセスできるわけではなく、使用する開発ツールに依存することになる。
ネイティブUIを利用できないので、UI・UXに問題を抱えることが多々ある。（ハイブリッドアプリ用、Webアプリ用のUIフレームワークを使用するのが主流)
ここまでハイブリッドアプリのメリット・デメリットについてまとめてきた。前回の記事ではネイティブアプリ、Webアプリについてもまとめてきたが、それぞれの開発手法には特徴があり、一概にどれがいい！というのは難しい。作成するアプリによってどれを選択すべきなのかが変わってくる。
しかし、それを決めるのがまた難しい。そこで次回以降の記事では、世の中的にはどんな時にハイブリッドアプリが使われているのか、ハイブリッドアプリの動向はどうなっているのかをまとめていく。
個人的にはハイブリッドアプリでの開発が今後の主流になってくると思っている。もちろんゲームなどはネイティブでの開発にはなるが。
ということで次回は「【連載】ハイブリッドアプリの最新情報とその動向【Corodva】- 4章 ハイブリッドアプリの最新動向」というタイトルで書いていく。
以上
今回はハイブリッドアプリがネイティブアプリ・WEbアプリとそれぞれどのように違うのかを詳しくみていく。
まずはハイブリッドアプリとの比較の前に、ネイティブアプリとWebアプリの特徴を以下の観点でまとめる。 ネイティブアプリ、Webアプリの知識が十分だという方はページ下部の「ハイブリッドアプリについて」からみてもらえればいいと思う。
＜開発者視点＞
開発にあたってプラットフォームごとの開発言語を使用するため、開発コストは比較的高い。 Android版ならJava, iOS版ならObjective-CやSwiftを使う。
開発言語だけでなく、開発環境や各OSの知識なども必要になる。
上記のように各プラットフォームごとの開発なので、修正を加える場合にはそれぞれのソースを修正する必要があり、メンテナンスする際の労力が大きくなってしまう。また修正内容をすぐにアプリに反映することができない。公式ストアを介しているので、配信のための審査が入り、その修正内容がアプリに反映されるためには時間が必要。
公式ストアの審査を通るためには、開発に制約をかけなければならない場合もある。
例えばAndroid、iOSはそれぞれの公式ストアに配信する開発者向けのガイドラインを用意しているが、 それに則って、開発を進める必要がある。
＜ユーザー視点＞
ネイティブアプリは動作が速い。
なので、高速処理を必要とするゲームや、グラフィックにこだわったアプリなどではネイティブアプリが使われることが多い。
ネイティブアプリは実機にインストールして使われるため、基本的にはオフラインでも利用可能。
＜共通＞
ネイティブアプリは公式ストアでの配信が可能であり、開発側としてはユーザーに見つけてもらいやすいという大きなメリットがある。ユーザーとしても公式ストアに配信されている方が検索しやすく、また信頼性が高い。なので公式ストアで配信できるネイティブアプリは開発側、ユーザー双方にメリットがある。 集客性は公式ストア経由が圧倒的に強い！
ネイティブアプリではデバイスの機能を最大限に生かしたアプリの作成が可能。
機能の利用に制限がないこと、機能を利用する際の速度も速いことがネイティブアプリの強み。
基本的にはデバイスにあるネイティブUIがそのデバイスに最適化されているため、使いやすく(UX)、スタイリッシュ(UI)に見えることが多い。ネイティブアプリではこのネイティブUIを利用できるので、開発者にとってもユーザーにとってもメリットが大きい。
＜開発者視点＞
ブラウザで表示を行うため、プラットフォームごとに開発言語を分ける必要がないWebアプリは開発コストが低いといえる。HTML,CSS,javascriptでの実装ができるので、Web開発技術の流用ができ、学習コストもかからない。
上記のように基本的には開発言語を分割する必要がないのでメンテナンスの労力が少しで済む。また修正内容をすぐに反映させることができ、バグが発生した時などは迅速な対応が可能。
公式ストアの審査を経るネイティブアプリと比較すると制約は少ない。
＜利用者観点＞
Webアプリはネイティブアプリと比較するとは動作が遅い。
なので、高速処理を必要とするゲームや、グラフィックにこだわったアプリなどには向いていない。以前よりはWebアプリの動作速度は向上しており、複雑な処理が少ないアプリであればネイティブとあまり変わらない。
ブラウザでの表示を行うためオンライン環境が必要。HTML5ではブラウザ内のキャッシュが利用可能だが、それにも制限があるのでオフラインでユーザーに満足してもらうことは難しい。
＜共通＞
Webアプリは公式アプリからの配信ができない。そのため、ユーザーが目に入れる機会は、ネイティブアプリに比べると少なくなる。また公式アプリからインストールして使うアプリに比べて、信頼度はガクッと落ちる。
ブックマークやブラウザ検索からの利用者が多いWebアプリは、インストールして画面上にアイコンが表示されるネイティブアプリに比べて再訪問率が低い。
Webアプリではデバイスの機能を最大限に生かしたアプリの作成は難しい。
現状では、この点に関してネイティブアプリに太刀打ちできない。
一方で、近年はデバイス側がこの点を改善する方向で(Webアプリからもデバイス機能にアクセス可能にするという)動いている。
近い将来は、このような憂いが無くなる可能性も？？
WebアプリではネイティブUIを使えないため、使いやすさ(UX)や見た目(UI)の問題を抱えることが多い。 しかし、この問題を解決するためにWebアプリ用のUI専用フレームワークも出ているので、そこまで気にしなくてもいいかもしれない。
ネイティブアプリとWebアプリの特徴については以上。
ではハイブリッドアプリとはどのように違うのか、比較形式でみていく。
＜開発者視点＞
Webアプリと同様。ネイティブアプリと比較すれば開発コストを低く抑えることが可能。
Webアプリと同様。ネイティブアプリと比較すればメンテナンスの労力を低く抑えることが可能。またアプリストア経由でなくても機能のアップデートができるのは強み。
ネイティブアプリ同様、公式ストアの審査を通るためには、開発に制約をかけなければならない場合もある。また、ネイティブアプリと比べて審査を通りにくいという点も注意しなければならない。（最近はかなり改善されてきている)
＜ユーザー視点＞
Webアプリと同様、動作速度はネイティブに劣る。
なので、高速処理を必要とするゲームや、グラフィックにこだわったアプリなどには向かない。一方でWebアプリよりは動作速度は優れている。
ネイティブアプリ同様に、実機にインストールして使われるため、基本的にはオフラインでも利用可能。
＜共通＞
ネイティブアプリ同様に、公式ストアでの配信が可能であり、開発側としてはユーザーに見つけてもらいやすく、ユーザーとしても公式ストアに配信されている方が検索しやすく、また信頼性が高い。
ネイティブアプリ同様に、デバイスの機能を生かしたアプリの作成が可能。
でも実装可能な機能は、開発に使うツール（フレームワーク）に依存するというデメリットもある。
Webアプリ同様に、ネイティブUIを使えないため、使いやすさ(UX)や見た目(UI)の問題を抱えることが多い。 しかし、この問題を解決するためにハイブリッドアプリ用のUI専用フレームワークも出ているので、そこまで気にしなくてもいいかもしれない。
以上が、ハイブリットアプリとネイティブアプリ、Webアプリそれぞれの違い。
次回は今回と似ている内容だが、「【連載】ハイブリッドアプリの最新情報とその動向【Corodva】- 3章 ハイブリッドアプリのメリット・デメリット」というタイトルで書いていく。
以上
「ハイブリッドアプリとは？」という説明のなかでよく使われる画像がこれ。
これはハイブリッドアプリの構造を説明しているもので、アプリの画面にWebViewというネイティブのコンポーネントを使っており、このWebViewの中でHTMLの画面を表示している。つまり、
ネイティブとWebの性質を併せ持ったもの！
ということ。
もう少しわかりやすい画像があったので拝借。
画像元：http://www.mdn.co.jp/di/articles/2685/?page=4
このように、
一つの画面上にネイティブの部分とWebの部分が同時に表示される
これがハイブリッドアプリ！
でも、ネイティブの部分とWebの部分が同時に表示される メリットってあるの？と考える人がいると思う。これに関してはメリット・デメリットがあるが、ハイブリッドアプリが注目される点はそこ（同時に表示される点）ではない。詳細は「3章 ハイブリッドアプリのメリット・デメリット」で説明するので、ここでは大まかな部分を。
＜ハイブリッドアプリが注目されている理由＞
・公式ストアでの配信が可能
・クロスプラットフォーム開発が可能
■公式ストアでの配信が可能
ネイティブアプリは公式ストアでの配信が可能。Webアプリは不可能。ハイブリッドアプリはこれが可能になっている！
公式ストアは集客性に優れているだけでなく、ユーザーからの信頼をとても得やすい。つまり
公式ストアでの配信がユーザー獲得のために必要
ということ。
そこで「 だったら最初から公式ストアで配信できるネイティブアプリで作ればいいのに」という声が聞こえてくる。
その通りだけど、ハイブリッドアプリにはそれ以外の利点もあり、それはネイティブアプリでは実現が難しいとされている。
■クロスプラットフォーム開発が可能
これがネイティブアプリでは難しい。ネイティブアプリ開発では、Android版の開発にJava、iOS版の開発にObjective-C（Swift）といった開発言語を使用しなければならない。つまり
開発やメンテナンスに時間的・技術的なコストがかかる
単に開発言語だけでなく、開発環境や各OSの知識なども知っておかなければならない場合が多い。
そこをハイブリッドアプリは解決してくれる。
WebViewを用いることで、HTMLやJavaScript、CSSで記述したアプリが様々なOSで動作するようになっている。
（※全てを共通化できるわけではないので注意！）
他にもハイブリッドアプリが注目されている理由はあるが、ハイブリッドアプリがどのようなものかを理解してもらうには十分だろう。
次回は、「【連載】ハイブリッドアプリの最新情報とその動向【Corodva】- 2章 ネイティブアプリ、Webアプリとの違いは？」というタイトルで書いていく。
以上
本日は、連載の最初ということで今後の連載内容について記載。
＜連載内容＞
ハイブリッドアプリに関する連載は、上記のようなメニューで記事を書いていく。
「1章 ハイブリッドアプリとは何か？」をご覧になる方は以下のページから。
以上。
最近の学習のなかで思ったこと
まず、AngularJSについて勉強してると、わからないことがかなりあって、
何をどうやって学習すべきか
ということを意識しないと、訳が分からなくなる。
また、
本来の目的がハイブリッドアプリ開発であることを忘れてしまいがち
ということもあって、もう少し体系的な学習方法を模索していこうと思っている。
具体的には、
①アプリ開発と並行して、開発に必要な知識を得る
ハイブリッドアプリで作りたいものを決める
↓
それを実現するために必要な知識を学習する
②AngularJSについては初心者なので、学習計画に沿って勉強する
学習計画の作成
↓
それに沿った学習
↓
学習した内容をどこかにまとめる
①についてはブログの最初の方で実践していたので、それを継続する形で実施。
アプリの詳細についてはリリースしてから紹介するが、ブログのエントリーは
実装したい機能ごと
の投稿を心がける！たとえば、
「OnsenUIでリスト表示」のようなタイトルで、その実装方法について書いていく。
② => 以下ように進める
1.AngularJSのチュートリアルを行う
2.用語の理解
3.ToDoアプリを作成
4.その後、ソースをいじってみて挙動を確認。
もう一度、情報の整理をしながら進んでいく。
焦らないでじっくりと。
以上
上記の記事でも書いたが、
AngularJS 2系では$scopeが廃止される
$scopeを使わないでも実装が可能
ということもあって、基本的には$scopeを使わない方針。
$scopeを使った場合、使わなかった場合の比較を行う。
赤文字の部分が変わったところ。
$scopeを使った場合
index.html
<!doctype html> <html> <head> <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.4/angular.min.js"></script> <script src="js/HelloWorld.js"></script> </head> <body> <div ng-app="myApp"> <div ng-controller="myController"> {{message}} </div> </div> </body> </html>
HelloWorld.js
var app = angular.module('myApp', []); app.controller('myController', function($scope) { $scope.message = 'Hello Tom!'; });
$scopeを使わない場合
index.html
<!doctype html> <html> <head> <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.4/angular.min.js"></script> <script src="js/HelloWorld.js"></script> </head> <body> <div ng-app="myApp"> <div ng-controller="myController as mycon"> {{mycon.message}} </div> </div> </body> </html>
HelloWorld.js
var app = angular.module('myApp', []); app.controller('myController', function() { this.message = 'Hello Tom!'; });
変わった部分
index.html
$scopeを使う場合
ng-controller = "myController"
$scopeを使わない場合
ng-controller = "myController as mycon"
$scopeはindex.htmlへの記述がなくても、データモデルをビューへ渡せる。$scopeを使わない場合はその代わりに、「as」を使う。
HelloWorld.js
$scopeを使う場合
function($scope){
$scope.message = 'Hello Tom!';
}
$scopeを使わない場合
function(){
this.message = 'Hello Tom!';
}
$scopeの代わりに、「this」が使われている。また、引数も無くなっている。
このように、$scopeを使わない実装もできるので、覚えておく価値はある。
今後、当ブログでは$scopeを使わない実装をしていく。
以上！
リファレンスで調べてみたけど、分かりにくかったので簡単に言うと、
ビューとコントローラの橋渡し
具体的には、
モデルをビューにバインディングするためのオブジェクト
ビューでのイベントを受けて、何かしらの振る舞いをするためのオブジェクト
さて、スコープの使い方について学ぼうか！と思っていた矢先にこんな情報を得た。
AngularJS 2系では$scopeが廃止される
そして、現在でも
$scopeを使わないでも実装が可能
らしい。
なので、基本的には$scopeを使わない方針でいく。
$scopeを使った場合、使わなかった場合の比較を以下のページで解説している。
以上！
リファレンスで調べてみた！
サービス・インスタンスを返すために呼び出されるservice factoryを実装するためのもの。 これは、factoryに与えられているgetプロパティのみで構成されるproviderの実装を省略するためのもの。 providerにサービスを設定する必要がない場合は、$ provide.factory （）を使用する必要がある。
さっぱりわからない。 provider,injectorなどの用語も出てきて、理解できず。
ちなみにproviderについてもリファレンスを見てみると
$injectorを使用してプロバイダの機能を実装するためのもの。
providerメソッドは、サービスのためのfactoryの提供を担当しているコンストラクターです。
$injectionってなに???
こうなった。
これでは進まないので、もっといい解釈はないかと調べた結果が以下の通り。
コンポーネント化を行うために「Service」というものがあるが、factoryはその作成方法の一つ。
factoryを含めて、Serviceの作成方法には以下の3つがある。
値の定義に使用する。定数とかを扱う場合に使うことが多い。
関数などの定義に使用する。値だけでなく、関数やオブジェクトを返すことができる。
前述した「Service」と名称は一緒だが、別物。
コンポーネント化するためのServiceを作成する方法の一つに「Service」がある。
オブジェクトをインスタンス化したうえで、それを扱うためのもの。
簡単にいえば、上記のような感じ。
どんな時にそれぞれを使うのかはまだ調査中だが、現状の認識は以下の通り
■定数など値の定義・・・Value()
■関数、配列などの定義・・・Factory()
■クラスの定義・・・Service()
調査して違うようであれば修正する。
話を戻すと、Factoryとは・・・
値や関数などを定義するためのServiceを作るための一つの方法であり、そのうち関数や配列などを扱うもの
以上！
