SOLG System Blog

こんにちは。最近好きなOSがMarshmallowなマツナガです。
今回は、アプリ開発についてのお話です。

そもそも「アプリ」って何だ？

プログラマが作る成果物は多岐に渡っています。社会のインフラ・基盤システム、会社の業務効率化のためのシステム、ネットワークやインフラの基盤システム、オペレーションシステム、プログラミングを支援する様々なライブラリーや開発環境、Webサイト、Webサービスなどなど、プログラマが書いたコードは私たちの生活の様々な場面で動いています。

そんなプログラマが開発するモノの一つに「アプリ」があります。僕の業務経歴はというと、社会インフラのシステム開発、業務システム開発、Webサービスの開発という道を辿ってきて、５年ほど前から「アプリ開発」も行うようになりました。

そもそも「アプリ開発」というプログラマの職種が一般化してきたのはいつからでしょうか。
アプリケーションという言葉は昔からありましたが、今のように「アプリ」という呼称はあまり使われていませんでした。Windowsの世界では90年代後半頃から「窓の杜」というサイトが開設され、アプリケーションが公開されるようになりましたが、当時は、アプリケーションは、フリーウェアとかシェアウェアという名称で呼ばれていました(久しぶりの窓の杜を見てみたら、サイトの説明は「Windowsアプリ・フリーソフトのおすすめ情報」となっていました）。

アプリという言葉が一般的になったのは、やはりiPhoneが普及するようになってからだと思います。Apple が iOS (当時はiPhone OS)向けにアプリケーションを開発する環境を提供して、開発されたアプリケーションを公開するApp Storeを開設したのが2008年7月です。この頃からiPhoneで動くアプリケーションは「アプリ」と呼ばれるようになり、アプリを開発するアプリ開発者と呼ばれるプログラマが増えてきました。

現在のアプリの状況については、先日、弊社の高山がブログエントリーに書いたとおり、
2015年11月24日時点、それぞれ下記のようになっています。

AppStore（iOS）：1,734,110（開発者 386,443）

GooglePlay（Android）：2,055,365（開発者 569,909）

参考：https://www.appannie.com/apps/ios/top/?_ref=header&device=iphone

プログラマがプログラムを書くきっかけが変わった

プログラマがプログラムを作るきっかけは、プログラミングの習得という目的もありますが、一般的にはクライアントからの開発の委託です。職業プログラマであれば大抵はこのパターンです。

しかし、一方で、日曜プログラマと言われるプログラマが開発したアプリケーションをフリーウェアとして窓の杜などで公開するようになったり、Googleなどからが公開されたAPIを使ってWebアプリケーションを作ったりと、「自分が実現したいことを自分で作るプログラマ」が徐々に増えてきました。

これは開発ツールが手に入れやすくなったり、クラウドの普及により開発環境が簡単に使えるようになったりといった要因はもちろんありますが、自分が作ったアプリを全世界の人々に配信できるApp StoreやGoogle Playといったアプリストアの存在はとても大きいと思います。

こういった環境が整っていくことで、全世界で素晴らしいアプリが次々と世に出てくることになりました。アプリ普及の黎明期にこのムーブメントを牽引したのは、誰かに開発を委託されてプログラムを開発するプログラマではなく、「自分が実現したいことを自分で作るプログラマ」にほかなりません。

そして、アプリ開発というスタイルが浸透した今、まわりのみんながアプリ開発をしているので、自分もアプリ開発をしたいのだけど、何を作ったらいいのかわからない、といった声が聞こえるようになってきました。

アプリを開発するのであれば、JavaやSwiftといったプログラミング言語を学ぶことで開発はできます。しかし、当たり前ですが、何を作るかが決まらなければアプリは完成しません。アプリは、業務システムのように大規模で多くの開発者で作るようなものではなく、むしろ１人〜数人で開発されるコンパクトなものが多いので、プログラマがアイデア出しから完成まですべてを担う傾向にあります。
そうなると、やはりアプリを勉強したいけど何を作ったらいいかわからない、作るものが思い浮かばないのでアプリ開発に取り組みたくても、取り組めないとった状況が発生しがちです。

昔話になりますが、今から10年前、Web2.0と呼ばれた時代がありました。GoogleがGoogleマップをリリースし、様々な企業がAPIを公開し、様々なWebサービスが次々と開発されました。当時、Googleマップは凄く新鮮で、地図と何かを組み合わせることによって、新たな価値を生み出す環境をもたらしてくれました。

そのような体験の中でわかったことは、どのようなサービスやアプリを作ろうかと考える時に、何か素材があるとアイデアが出やすいということでした。10年前はGoogleマップが地図という素材を提供し、それを使った様々なアイデアが生まれ、実現されました。

そして現在は、オープンデータがその役目を担っているのかもしれません。政府や全国の自治体がオープンガバメントの流れの中で様々なデータの公開を始めています。

静岡県は2013年に全国に先駆けて「ふじのくにオープンデータカタログ」を開設、静岡市も今年10月、「静岡市オープンデータカタログサイト」を公開しました。

アプリを作りたいけど、どんなアプリを作ったらよいかわからないと迷ったときは、オープンデータカタログサイトに公開されている様々なデータを眺めてみるとよいかもしれません。そのとき注意することは、ひとつのデータを使って何かアプリを作ろうと考えるのではなく、いろいろなデータを掛け合わせてみることをお奨めします。静岡市の場合は、道路保全課、廃棄物処理課、生活安全保全課、観光交流課といった部署が作成したデータが公開されています。
おそらく、この中には、各部署では活用されていたものの、組織をまたいで活用されることはなかったデータがかなりの数含まれているはずです。

こういったデータがオープンデータとして公開されると、これまで決して重ねて使われることがなかったデータを重ねることが可能になります。例えばゴミ収集のデータと観光地のデータを重ねて眺めてみると、何かが見えてくるかもしれません。
このようにいろいろなデータを掛け合わせて見ていくと、今まで見えてこなかった課題が浮き彫りになってきます。そして、それが地域がかかえる課題の解決のきっかけになる可能性が充分にあると思います。僕はそれを見つけるのがプログラマとしてのオープンデータの活用の面白さなのかなと思います。




  

システムエンジニアの高山です。

弊社では、紙媒体に加え、web、アプリの制作を行っています。
そんな中、企画を考える際に必ずと言っていいほど議論に上がるのが、webで作るべきか、アプリで作るべきか、という議論。

そして必ず、言われるのが、「アプリはダウンロードされない」「ゲーム以外で大きな収益を出すのは難しい」といった、ネガティブな意見。
アプリの現状ってどうなっているのかを、ネットから情報をさらってみました。

AppStore、GooglePlayのアプリ登録数

2015年11月24日時点、それぞれ下記のようになっています。
AppStore（iOS）：1,734,110（開発者 386,443）
GooglePlay（Android）：2,055,365（開発者 569,909）
参考：https://www.appannie.com/apps/ios/top/?_ref=header&device=iphone

今年はじめに、多くのメディアで「ついにGooglePlayの登録数が、AppStoreの数を抜いた」と出ましたが、
状況は変わらず、GooglePlayの方が登録数が多い状況となっています。

総計で、2,228,775。
カテゴリ別に見ると、また違ってくると思いますが、ある意味、競合はこれだけの数いることになります。

iOS端末、Android端末のシェア

2015年9月時点の情報ですが、アプリ数と同じく、日本国内のシェアはAndroidの方が多い状況となっています。
iOS端末：38.3%
Android端末：60.7%
参考：http://www.kantarworldpanel.com/global/smartphone-os-market-share/

iOS端末は、2013年6月に1度シェアを奪われてからは、抜きつ抜かれつを繰り返しています。
現時点ではAndroid端末の方が20%以上の大差で勝っています。


ただ、個人的には、電車などで見かけるのはiPhoneばかりで、いまいちAndroidの方がシェアが高いようには感じられません。
もしかすると、社有の携帯やタブレットなどは、安いAndroid端末が多く使われているのかもしれません。

追記：ウチのメンバから、「周りで結構Android見るよ」とのことでした。

一人あたりのアプリダウンロード数

過去2年間でアプリの利用時間は63%増加の一方、月に利用するアプリ数は微増に留まる
http://jp.techcrunch.com/2015/06/12/20150611time-spent-in-apps-up-63-percent-over-past-two-years-but-apps-used-monthly-shows-little-change/

この記事に書かれている通り、アプリの利用時間は、「2012の第4四半期、毎月23時間2分間」だったのが、「2014年の第4四半期には37時間28分」まで増加したが、結局は、26、27個のアプリの利用に留まっているとのことです。

また、かなり古いですが、2014年2月の記事に、こんなデータが出ています。
・アプリはスマホの利用時間の72%を占め、WEBブラウザの2.5倍
・月に1回以上利用するアプリは27個、10回以上利用するアプリは9個
参考：http://www.netratings.co.jp/news_release/2014/10/Newsrelease20141001.html

現在は、これよりさらにアプリの利用時間が増加していると言われていて、1日のスマートフォンの利用時間の80%以上がアプリと言われています。
また、ゲーム以外で利用するアプリは固定化されており、ほとんど入れ替わりがないと言われています。

この状況を打破すべく、appleとgoogleはdeeplinkや、おすすめ機能を強化したりしていますが、なかなか改善していないようです。
実際、自分も昔ほどアプリ検索しなくなったのが実情です。

どういう時にダウンロードされるのか？

では、どういった時にダウンロードされるのか？

参考：http://gamebiz.jp/?p=147620

以前は、アプリランキングや、友人知人からの紹介でダウンロードする人が多かったようですが、現在はTVCM、スマートフォン広告をきっかけにする人が増えているようです。
昔のように、自ら探したり、教え合ったりしてダンロードするのではなく、かなり受身でダウンロードする傾向にあるように思えます。
ダウンロードさせるには、広告費がかなり必要ですね。

まとめ

上記に上げた内容を元に、アプリを作る際の対策を考えて行ければと思うのですが、
やはり広告費をかけて宣伝していかないと、なかなか、固定化されている27個のアプリの中には入り込めなさそうです。
ただ、逆にその中に入ってしまえば、ずっと使われる可能性もあるわけです。

ですから、ダウンロードされないからアプリをは作らない、ではなく、
webサービスで流行らせて、アプリで定着化させるのが良さそうです。

ありきたりの結論ですみません。
今度は、成功するアプリの法則なんかを調べてみたいと思っています。  

マツナガです。

本日、弊社で公開しているしずおかの超ローカルニュースアプリ「まちぽ」のApple Watch対応版をリリースしました。

Apple Watch それって美味しいの

よく聞かれます。正直、Apple Watchを持っている人、まわりに２〜３人しかいません。発売当初は、街で見知らぬ人に「それってApple Watchですか？」と聞かれたこともありましたが、最近は、あまりそんな声も聞こえなくなり、むしろApple Musicの話題の方が・・・。

とはいえ、Apple CEOのティムクックによると、Apple Watchは、具体的な出荷台数は公表されていないものの、「i初代のiPhoneやiPadより順調」とのこと。先日のAppleの開発者向けイベントであるWWDC 2015では、早くもApple Watchの次世代OSである「watchOS 2」が発表され、開発者としてはますます気が抜けない状況ではあります（watchOS 2が出たらまた作り直しなんですけどね）。

Apple Watchは、正直、まだまだ未完成な部分もあります。起動が遅いし、画面は小さくて文字は読みにくい。そして、何よりもiPhoneがそばにないと使えない。そもそもそれって何ができるの？　どうもネガティブな話に行きがちです。

しかしながら、この３ヶ月、Apple Watchを使った感想は「悪くない」です。「凄いよApple Watch、これなしでは生きていけない」的なテンションではなく「悪くない」ー。このくらいの感覚がApple Watchという製品だと思うわけです。

腕時計は、着用している佇まい的な部分と時刻を知る機能的な部分から成り立つ製品です。四六時中いじっているモノではないー。一方で、四六時中いじっている対極的なものといえば、よくも悪くもスマートホン、みんなが大好きiPhoneです。

Apple Watchを使っている人の感想で「iPhoneを触る時間が減った」ということがよく聞かれます。これわかります。Apple Watchはメールやアプリの通知を軽い振動と共に伝えてくれます。これだけで知りたいことがわかればそれでOK、もう少し詳しく知りたければ、ポケットからiPhoneを取り出してアプリを起動して確認。

Apple Watchだけで確認できるのであれば、iPhoneを取り出したついでに、いろんなアプリを起動したり、Youtubeで動画を見始めたり、そういった余分なことが減るわけで、それはスマホ依存症的な社会からすると健康的かなと思います。

まちぽ × Apple Watch

まちぽは、しずおかの超ローカルな情報を配信するサービスです。出版社であるしずおかオンラインが取材したデータ、静岡県や静岡市など自治体が公開しているオープンデータ、店主や生活者からの投稿データをもとに、お店情報や観光情報、生活情報などを配信しています。

今年になってからは、スマホを使った避難誘導実験でのアプリ利用、静岡県認定のエコショップ宣言店の掲載、スマホを使ったウォークラリー「家康公を探せ」でのコンテンツ提供など、静岡の生活者に近い場所でまちぽのデータを使ってもらう試みを展開してきました。

Apple Watchのアプリ開発も、まちぽのデータを使うという試みのひとつです。もちろん、Apple Watchの普及率はまだまだですが、これからApple Watchのようなデバイスは間違いなく普及するはずです。そんな近い未来を少しだけ先取りして、「まちぽのデータをApple Watchで使ったらこうなる」という一例を示してみたいと思いました。

では、Apple Watch版 まちぽアプリでどんなことができるのか、動画にまとめてみましたのでご覧下さい。



動画の40秒くらいのところで、Apple Watchに向かって「パスタ」と話すと、いまいる場所の付近にあるパスタのお店の一覧が表示されます。
数年までは夢物語だったことが、今や現実のものになりました。昔のように何ヶ月もかけてプログラムを書かなくても、わずか数日でこのようなことが実現できる時代がもう来ています。

地域の正確な情報を集めていくこと、情報を整理していろいろなデバイスに配信すること、それがまちぽのコンセプトです。今後のまちぽの進化を期待して下さい。



  

iPhone 6がすっかり手に馴染んできたマツナガです。

このたび、弊社が開発・運営しているWebサービス、みんなで作る街のWebマガジン「まちぽ」のiPhoneアプリを公開いたしました。



「まちぽ」は静岡市を中心に、しずおかオンラインが取材した情報だけでなく、お店の店主や生活者で作っていくメディアです。2014年8月オープン以来、飲食店、雑貨店、アパレルなど様々な業種のお店の方々がまちぽで情報発信していただいています。

まちぽのサイトを訪問してくださるユーザーを分析してみると、53%がスマートフォンからのアクセスでした（その中の約60%がiOSでした）。まちぽ自体、スマートフォン対応はしていますが、まちぽで発信する情報をもっとスマートフォンで見ていただけるよう、まちぽのアプリ化を企画しました。

コンセプトは、「静岡市を中心とした超ローカルニュース」。全国紙や地方紙などでは扱われない「超ローカル」なニュースを発信することで、地域に暮らす人が新しい発見・体験ができる、そんな願いをこめて開発しました。

まずは、アプリの紹介動画をご覧下さい。



まちぽアプリには、大きく分けて、「オススメ」「トピックス」「イベント」「イチオシ」「スポット」の５つの切り口から情報を発信しています。

オススメ
まちぽでお気に入り登録したお店が新しい商品を登録したり、TwitterやFacebookの友達が投稿した口コミ情報が表示されます。まちぽ編集部オススメの情報もここに載ります。


トピックス
まちぽ編集部がまとめたトピックスが表示されます。季節の情報、旬な情報をまとめてお知らせします。


イベント
お店や施設のイベント情報が表示されます。イベントはiPhoneのカレンダーに登録もできます。興味のあるイベントを見つけたらぜひ足を運んでみてください。


イチオシ
まちぽで情報を発信しているお店の商品やメニューの写真が表示されます。気になる商品や食べてみたいメニューがあったらチェック！


スポット
現在地からお店や施設を検索できます。今日のランチ選びなどに。


便利な使い方
気になるお店や商品を見つけたら、お気に入り登録しておきましょう。お気に入りのお店の情報が更新されればオススメに表示されます。
ぜひ、まちぽアプリで静岡の新しい発見をしてみてください。

ダウンロードはもちろん無料です。

  

RubyとSwiftをこよなく愛するマツナガです。

このたび、弊社が出版している静岡女子のためのフリーペーパー「womo」のiPhoneアプリ「womoアプリ（ウーモ）- 静岡・浜松の女性のフリーマガジンがいつでも読める！」をリリースしました。



情報誌のアプリというと、やはり「電子書籍」アプリを想像するでしょう。紙面をスキャンしたり、紙面データを画像化したものをスマートフォンやタブレットでペラペラめくってみるアレです。 iPadが発売されたのが今から5年前の2010年、この年、第？次電子書籍ブームがやってきて、このような電子書籍アプリがいくつも公開されました。

紙面データを画像化した電子書籍は「プリントレプリカ」タイプと呼ばれています。このタイプの電子書籍の特徴は、とにかく低コストで「電子書籍化」が可能なことです。紙面と同じレイアウトで電子書籍化できるので、コミックや雑誌などはプリントレプリカに向いています。最近では、スキャンしたデータからテキストを抽出して内蔵することで、テキスト検索や読み上げができる電子書籍も存在します。

確かにプリントレプリカは、紙面と同じレイアウトで読むことができますが、スマートフォンでは文字が小さくて読むことができません。小さい文字を読むには、２本の指で画面をピンチして画面を拡大する必要があります。スマートフォンやタブレットが発売されて間もない頃は、このピンチして拡大という操作にある種ステイタスを感じていた風潮があったような気がしますが、間違いなく言えるのは、それは快適な読書体験ではありません。

僕は、2010年頃から電子書籍に関する開発に携わってきましたが、電車の中で紙の本と同じ情報をスマートフォンで快適に読むことができる、そんな電子書籍をいつか作ってみたいとずっと考えていました。

そんな折り、「紙面データを紙の本だけに使うのはもったいないよね。せっかくいいコンテンツを持っているのだから、WPS.3からWeb APIで紙面のデータをはき出したら何かおもしろいモノ作れるんじゃない？」とニューキャストのYさんからお話があったのが去年の秋頃。

womoは、ニューキャスト社が開発・販売している、「WPS.3」というオンライン入稿/自動組版システムを使って印刷所に渡すためのデータを制作しています。WPS.3は、取材した記事のテキストや写真をブラウザを使ってインターネットを経由して入力することができます。つまり、WPS.3システムのデータベース紙面を作るために必要な情報として整理され蓄積されているのです。これをWeb APIという形で提供するので、紙面データをWebやアプリに活用できないかというアイデアです。

このアイデアをいただいて思ったのは、「スマートフォンで快適に読めるwomoを作ろう！」ということでした。
プリントレプリカは印刷データをそのまま画像化したものですが、Web APIで記事のテキスト情報を取得できれば、写真とテキストでHTML5で記事を作れます。スマートフォンに最適化したCSSとHTMLによって、スマートフォンで快適に読める記事が作れるわけです。

また、電子書籍を作り配信するには、記事をどれだけ短時間で電子化できるかがポイントです。できるだけ手間をかけずに電子化できて、できれば、発行日には、紙面と同じ記事が電子書籍で読めること、そんなシステムの開発が必要です。

そして、できあがったシステムはこんな感じです。



今回の開発範囲は、青い線で囲まれば部分、（１記事あたり）紙面を1分でウェブにする「paper-web」とwomoアプリ for iOSです。
（paper-webというサービス名は、womoのWEB副編集長の遠山さんが名付けました！）

paper-web自体もブラウザで操作が完結します。操作はとってもシンプルです。

WPS.3側で紙面データが校了状態になると、paper-webの取り込み可能な記事一覧が表示されます。web化したい記事を選んで「取り込み」ボタンをクリック。
これだけで、アプリに記事として配信されるようになります。

paper-webは2月4日から開催される印刷メディアビジネスの総合イベント「page2015」にニューキャスト社と合同で出展します。ぜひ会場に足を運んでいただき、「紙面を１分でWeb化」のデモをご覧になっていただけたらと思います。

また、今回のシステムとアプリ開発ではAWSのEC2やS3を使ったり、iOSアプリはSwiftで開発したりと、テクニカルな面でもいろいろなトライアルを行いました。このあたりの話はまた別の機会にお話しできればと思います。

paper-webで紙面を1分でWeb化したwomoの記事をぜひ、「womoアプリ」で読んでみてください。ダウンロードはもちろん無料です。


  

アプリ開発をしているマツナガです。

弊社では年末から年明けに向けて、新しいiPhoneアプリをいくつか開発しています。iOSのアプリ開発には、Objective-Cという言語を使用します。このObjective-Cという言語、iOSアプリ開発がこんなに盛んになるまでは、Macで動作するアプリケーションを作る言語として存在していましたが（もともとはMac OS XのベースになったNeXTで使われていた言語）、一般的な開発者はふれることのない言語でした。

しかし現在では、iOSの登録開発者数は900万に達しており（WWDC 2014でのTim CookのKeynoteより）、ここに登録されている開発者の大半がObjective-Cを習得して開発を行っています。

そして、WWDC2014では開発者にとって衝撃的な発表がありました。iOS / OS X向けの新しい開発言語「Swift」の発表です。

iOSアプリを開発するために、Objective-Cを学んだ開発者達の悲鳴が聞こえてきそうです。もちろん、Objective-CでのiOSアプリの開発がすぐにできなくなるわけではなく、iOS 8になってもObjective-Cでアプリは開発できます。これまで習得した技術が無駄になるわけではないのですが、ギークな開発者は早々にSwiftに移行していくでしょう(今年WWDCに参加した友人の話では、発表されたばかりのSwiftを使ってプログラムを書き始めた開発者がいっぱいいたとのことです)。

そこで、今後のアプリ開発において、Swiftを採用するかどうかのポイントについて考えてみます。

既存のアプリはどうするか？

すでにObjective-Cで開発されたアプリをSwiftに移行するかどうかという問題です。そもそも、Objective-CのコードをボタンひとつでSwiftに変換する魔法のツールは今現在存在していません。もともと複雑怪奇な文法を持ったObjective-Cのコードをモダンかつシンプルな記述で書けるSwiftに置き換える作業は、結構骨の折れる作業です。一度、数百行程度のコードでトライしてみましたが、とっても辛かったです。すでに公開しているアプリケーションで、大きな改造もなく、保守メンテナンスフェーズにあるアプリに関しては、Swiftに置き換えるメリットはないように思います。また、Swiftで書かれたコードはiOS 7以降しか動作しません。iOS 6での動作保証がマストである場合は、Swiftは選択肢から外れることになります。

新規にアプリを開発する場合どうするか？

まったく新しいアプリを開発する場合、または、すでに公開しているObjective-Cで開発されたアプリを心機一転リニューアルする場合、Swiftを採用するかどうかのチェックポイントです。

1.既存のコードが再利用できるか

まったく新しいアプリを開発する場合でも、これまで開発したObjective-Cのコードを再利用はしたいものです。リニューアルする場合も同様です。これについては、Swiftは、Objective-Cとの互換性を保証していますので、問題ありません。SwiftからObjective-Cのコードを呼ぶこともできますし、Objective-CからSwiftのコードを呼ぶこともできます。
プロジェクト内にSwiftとObjective-Cのコードを共存させる場合には、以下のサイトが参考になります。

F60K - Objective0CとSwiftの組み合わせ方まとめ

また、iOSのライブラリーを管理できるCocoaPodsを使ってインストールできるライブラリーの大半もObctive-Cで書かれていますが、これについても、Swiftのコードから呼び出すことができ、問題なく利用することができました。

Qiita - SwiftでCocoaPodsを使う

2.言語の習得コスト

Swiftは学習しやすい言語かどうかというポイントです。Objective-Cは、C言語をベースにしていると言いながらも、C言語の開発者も戸惑ってしまう括弧[ ]の使い方が独特である点や、そもそも誕生から約30年経過していることもあり、モダンな記法ができるかと言えば、少し無理がある状況ではありました。Swiftはもちろんそういった反省点から生まれた言語ではありますし、今もっとも新しいプログラミング言語であることもあり、他のモダンな言語のいいとこ取りをしているプログラミング言語といっていいでしょう。「Pythonに似てる」、「Rubyに似てる」とか、はたまた「C言語に似ている」とか開発者のつぶやきがTwitterのタイムラインからも見て取れます。そういった意味では、言語としての習得コストは低いと思います。PythonやRubyあたりを使っている開発者であればさほど習得には時間はかからないでしょう。

しかし、言語自体を習得できてもそれだけでは、アプリは開発できません。これはSwiftに限ったことではないですが、アプリを開発するには、そのアプリ専用のフレームワークの使い方を習得することが必要だからです。iOSの場合は、まずは「UIKit」の使い方を覚える必要があります。UIKitは画面を構成するViewやTableViewやボタンなどユーザーインタフェイスに関わる機能を司るフレームワークです。また、画像処理を行うフレームワーク、位置情報を扱うフレームワークなどなど、高機能なアプリを作ろうとすればするほど、覚えなければならないフレームワークは増えていきます。これは、Objective-CでもSwiftであっても覚えなければなりません。ここの習得コストは両者ほぼ同じといえます。逆にいうと、これらフレームワークをObjective-Cを使って覚えた開発者は、この知識をそのままSwiftで使うことができます。これは大きなメリットです。あとは、Swiftの言語を覚えるだけでよいのですから。

では、これからアプリを開発する人は、どちらを選択すればよいでしょうか？ フレームワークについての学習コストは両者同じであるとするならば、学習コストの低いSwiftを選択するのが賢明だと考えます。ただ、現段階では、Objectice-Cに関する参考図書やWebの情報も少ないかもしれません。Swiftをばりばり書いている先輩社員もそう多くはいないと思います。しかしそれは時間の問題です。Objective-Cをバリバリ書いている開発者は、またたく間にSwiftを習得してWebで情報をどんどん発信していくからです。

3.開発効率について

SwiftはObjective-Cよりも、記述を簡略化でき、見通しのよいコードが書ける印象を持ちました。Objective-Cはひとつのクラスを定義するには、ヘッダファイルと実装ファイルの２つのファイル構造になっていましたが、Swiftではひとつのファイルでひとつのクラスを記述することができます。ソースが増えてくると、結構、ヘッダファイルと実装ファイルをいちいち開いて行ったり来たりする時間が無駄だなと思っていたのですが、Swiftではこの作業が軽減できそうです。
言語仕様を習得しさえすれば、記述するコードはかなり減らすことができ、デバッグ工程の作業も減らせそうなので、開発効率は向上すると思います（一方で、iPhone開発は、iPhone 6から画面サイズが増えてしまったのでそのための開発コストといった問題があるのですが、それは別の話）。

いろいろ自問自答した結果、弊社で、年明け頃に公開予定のアプリは、Swiftで書くことに決めました。これまで、いくつもの言語が誕生してきましたが、Swiftは、これまで新たに誕生した言語とは少し違う起源を持ち、違う進化を遂げていく言語なのだと思います。


  

画面サイズが大きくなったiPhone 6 / iPhone 6 Plus

ついに、9月19日に、iPhone 6 とiPhone 6 Plusが発売されました。全世界で、発売から３日間で、1600万台の販売台数を記録しており、相変わらずiPhoneの人気は衰えずといったところです。

今回のiPhone 6 / iPhone 6 Plus、もっとも大きな特徴は何でしょうか。やはり、いちばん目につく点は画面サイズが大きくなったことです。現役の機種の解像度をまとめるとこんな感じになります。

機種	ピクセル解像度(高さ x 幅)
iPhone 4S	960 x 640
iPhone 5 / 5c / 5s	1136 x 640
iPhone 6	1334 x750
iPhone 6 Plus	1920 x 1080

iPhone 6 Plusに至っては、これはフルHDの解像度です。リビングにあるフルハイビジョンテレビの解像度がギュッと手のひらサイズ（よりちょっと大きなサイズ）に収まってしまいました。
ここで注目したいのは、今回のiPhone 6では、画面の高さだけでなく、幅まで大きくなったということです。しかも、高さと幅がそれぞれ違うiPhone 6とiPhone 6 Plusの２機種が同時に発売されたことです。

画面サイズと開発者の苦悩

2年前、iPhone 5が発売されたとき、これまでのiPhone4 / 4Sから画面サイズが縦に伸びたことにより、アプリ開発者はアプリの縦長のサイズ対応を強いられました。ただ、Appleは対応されていないアプリのために、iPhone 5にiPhone 4 / 4Sの画面サイズそのままの大きさで表示するモードを残してくれました。iPhone 5の縦サイズが1136px、iPhone 4 / 4Sの縦サイズが960pxですから、その差分の176pxの半分の88px分を上下に黒い帯を表示した状態で、iPhone 5に対応しないアプリは起動できました。



しかし、これでは、せっかく大きくなった画面を充分に使えなくなってしまいます。ユーザーの利便性を考えるならば、きちんと縦長サイズの対応をすべきです。iPhone 5発売以降、アプリ開発者たちは、いわゆる"縦長対応"に奔走しました（今となってはよい思い出です）。

さて、あれから２年の月日が経ちました。今度は、高さだけでなく、幅まで大きくなったiPhoneの登場です。しかも、２サイズも増えました。アプリ開発者にとっては2年前の悪夢が４倍になってやってきたといったところでしょうか？

まだ、iPhone 6 / iPhone 6 Plusが発売されて1週間も経っていないこともあり、App Storeでも 新しいiPhoneの画面サイズに最適化されたアプリはあまり多くありません。AppleのiPhoneの発表イベントでは、これまでのアプリは手を加えることなく、新しいiPhoneで動作すると、ワールドワイドプロダクトマーケティング担当上級副社長のPhil Schillerが話していました。
iPhone 5の発売の時のように、今回も対応していないアプリも動作するような仕組みが提供されたわけです。やれやれ、一安心、、、でしょうか？

では、新しいiPhoneのサイズに最適化されていないアプリは、実際どのように表示されるのでしょうか。実際に試してみました(左からiPhone 4S、iPhone 5s、iPhone 6 、iPhone 6 Plusです)。

どうでしょうか、ぱっと見、問題なく表示されているように見えますね。しかし、よく見てみると、画面サイズが変わっても、iPhone 4Sをのぞいて、表示されている内容がすべて同じです。新しいサイズに対応していないアプリは、縦と横方向に拡大表示する、というのが、今回の対応されていないアプリへの仕様というわけです。
iPhone 5の時は上下に黒帯を入れればよかったのですが、今回は幅も大きくなったので上下だけでなく、左右にも黒帯を入れるというのはあり得ませんしね。

しかし、これでは、せっかく大きな画面を手に入れたのに、１画面あたりの情報量は変わらないということになってしまいます。しかも、画面をそのまま拡大しているので、文字も大きくなり、文字も画像も全体的にボヤッとした感じに表示されてしまっています（これ、実機で確認するとよくわかります）。

このブログを書いている時点では、facebookもiOSアプリも、新iPhoneの画面サイズに最適化されていません。「iPhone 6でfacebook見てると、文字大きくてお年寄りになった気分だ」と言っている人がいましたが、確かに、大きな画面に大きな文字なので、このユーザー体験はないよなぁと思ってしまうわけです。
特にiPhone 6 Plusの方が画面が大きい分、お年寄り感はより強いと思います。せっかく大きな画面をiPhoneを手に入れても、しばらくは、大きな画面の恩恵を預かれる機会はまだまだ少ないといってよいでしょう。かなり残念感を感じるところです。ここは、開発者さん達の頑張りに期待するしかありません。

では、使っているアプリが新しいiPhoneのサイズに最適化されているかどうかは、どうやって判断すればよいでしょうか？
起動してみて、何となくボヤってしているなと感じれば、まず、対応されていません。また、「iOS 8に対応しました」と書かれていても、iOS 8での動作は大丈夫だけど、新しいサイズに対応しているとは限らないので注意が必要です。

ちなみに、App Storeで確認すると、対応アプリは以下のように記載されています。



このように、「このAppは、iPhone5、iPhone 6 および iPhone 6 Plusに最適化されています」と表示されていれば、新しいサイズに対応したアプリということになります。

画面サイズに最適化したアプリは快適なUIを提供してくれる

では、新しいサイズに対応したアプリはどのような感じになるでしょうか。

文字サイズはすべてのiPhoneで同じ大きさとなり、表示される内容も大きな画面ほど、多くなっているのが一目瞭然ですね。

iPhone 6 Plusで最適化していないものと最適化したものを並べるとこんな感じです。

脱・画面サイズに依存したアプリ開発

これからiPhoneアプリを開発する場合は、4つの画面サイズに適応したものを開発しなければならなくなります。iPhone 6が出る前は、iPhone 4S と iPhone 5の２サイズの対応（縦方向の対応）をしていればよかったのに、これからはさらに２つのサイズに対応しなければなりません（しかも縦方向だけでなく、横方向も）。

これに対する答えは、ただひとつです。
「どんな画面サイズでもきちんど動作するアプリを作る」

言い換えると、画面サイズに依存したアプリは開発しないということです。これについては、実はiOS 6の頃に画面サイズに依存しない開発ができるようAppleが環境を用意してくれていました。「Auto Layout 制約」を定義するというものですが、この仕組みに基づいてアプリを開発すれば、新しいサイズのiPhoneが追加されても比較的スムーズに新しいサイズに適応できるようになります。

Auto Layoutを使うということは、名前から想像できるかもしれませんが、ボタンや入力フィールドの位置を絶対位置として定義してデザインするのではなく、このボタンは画面の右端から○ピクセル、この入力フィールドは、左右○ピクセルの余白があって、幅は可変、といったように定義することになります。Auto Layoutを使った設計をしていない開発者は、今後、Auto Layoutを使った設計が必須となるでしょう。すべからくアプリデザインの手法も変更しなければなりません。

最後に宣伝ですw
今回、例で紹介しました「womoグルメアプリ」は、iPhone 6 / iPhone 6 Plus発売日から、新サイズに適応したバージョンアップ版をApp Storeで公開しています。今なら、500円でランチが楽しめるアプリ限定クーポンもついています。新しいiPhoneを手に入れた方も、ぜひ、womoグルメで静岡のグルメ店を探してみてください。
  

こんにちは。マツナガです。今回は、がっつりとiPhoneアプリを作ってみます。

現在公開されているiPhoneアプリの大半は、インターネット上に公開されたデータにアクセスして、いろいろな情報を表示するものです。弊社で先日リリースした、「womoグルメ」アプリも自社で公開しているデータにインターネット経由でアクセスしてグルメの情報を表示しています。

ざっくりと処理の流れを示すと、アプリから「インターネットにアクセス」 → 「データを受信」→「データを解析」→「表示処理」という感じになります。では、この流れを行うアプリを作ってみることにしましょう。

使うデータを決める
まず、どんなデータにアクセスするかを考えます。そこで、静岡県が公開している「ふじのくにオープンデータカタログ」の中からデータを探してみましょう。オープンデータとは、行政や公的な機関が持っている様々なデータを二次的利用できる形で誰もが自由に利用できるデータのことをいいます。国の「電子行政オープンデータ戦略」を踏まえ、静岡県が公開するオープンデータをまとめた「ふじのくにオープンデータカタログ」が2013年の8月に公開されました。

「ふじのくにオープンデータカタログ」の「公開データ」のページを開くと、公共施設や防災情報、観光情報などたくさんの情報が公開されていることがわかります。このデータは誰もが２次利用して使ってよいことになっています。つまり、これらのデータを使ってWebサービスやアプリを作って公開することも可能なわけです。

とうことで、「観光・みどころ情報」のカテゴリを眺めていくと、「ふじのくにエンゼルパワースポット」というなんとも神秘的なデータが公開されています。"県民から広く募集した「恋愛・結婚・子宝」にまつわる噂のスポットです"とのこと。では、このデータを使うことを前提にアプリを作ってみます。

データを理解する
「ふじのくにエンゼルパワースポット」のデータフォーマットを確認してみます。形式はCSVファイルとあります。実際にダウンロードしてみましょう。中身はこんな感じでした。

番号,名称,説明,住所,電話番号,問い合わせ先,緯度,経度
165,東雲寺の摩利支天,勝負必勝の神様として有名な摩利支天。本来は安産・航海・大漁・勝負の神様として信仰を集めている。,湖西市神座463,053-578-0716,,34.739,137.495
172,はままつフラワーパーク,大温室・クリスタルパレス内にある、「サボテンの花の咲いているところ」を「好きな人」と見ることができたら、「恋がうまくいく」という噂がある。,浜松市西区舘山寺町195,053-487-0511,,34.762,137.634
170,舘山寺の縁結び地蔵,参拝すれば「縁結び」にご利益があるとされる舘山寺。境内に「縁結び地蔵」がいて、参拝したあと願いが叶ったとのうわさが口コミで広がっている。また「縁結びに効く」絵馬やお守りもあり、合わせて授与されていく人も多いそう。「心に鍵」絵馬を奉納し、良縁の願いを忘れな,浜松市西区舘山寺町2231,053-487-0107,,34.768,137.613
:
:

項目としては、番号、名称、説明、住所、電話番号、問い合わせ先、緯度、経度の８項目です。また、文字コードはShift-JISになります。ここを押さえておかないと文字化けを起こしてしまいますので、事前に文字コードを確認しておくことが大切です。

アプリを作る
さて、ここからは、ちょっと専門的になります。
さきほど、このオープンデータは８項目から構成されていることを確認しました。オブジェクト指向をちょっとかじったことがある人であれば、モデル（=クラス）を作ろうと思うでしょう。Spotクラスとでもしましょうか。


そして、クラスをこんな風に書きます。
クラスの定義ができました。でも・・・ちょっと待ってください。クラスのメンバーをいちいちコーディングするのは、面倒くさいですよね。もちろん、これはこれで正しいのですが、この後、データを受信して解析する際に、いちいちメンバー変数（Objective-Cの場合はプロパティ）への代入処理をこつこつ書かなければなりません。また、データの並びが変わったり、データの項目が増えたりした場合の修正が面倒くさそうです。
そこで、こういったデータの処理に便利なクラスを紹介します。
NSArray と NSDictionaryです。NSArrayは配列を扱うクラス、NSDictionaryは辞書クラスです。辞書クラスというのは、Key-Value（キーと値）としてデータを扱うクラスです。JavaでいうところのMap、RubyでいうところのHashです。これの使い方は、のちほど、解析処理のところで説明します。

httpアクセスしてデータを取得する
ともかくデータを受信しましょう。「ふじのくにエンゼルパワースポット」のCSVのダウンロードURLを指定してデータを取得します。データの取得方法はいくつかありますが、NSURLConnectionのsendAsynchronousRequest:queue:completionHandler:　のクラスメソッドが便利です。これは非同期通信を行って受信結果をBlocksとしてcompletionHandlerの中で処理できます。実際の解析処理は、parseData:行っています。

データを解析する
ここで、NSArrayとNSDictionaryを使ってデータを解析していきます。
まず、受信したデータはNSDataとして渡されます。これをShit-JISとしてデコードしてNSStringに変換します。
データはCSVファイルですので、改行で区切ったあとに、１行づつカンマで区切って項目を見つけていく処理になります。
ポイントは、１行目が項目の見出しになっていますので、これをNSDictionaryのキーとして配列に展開することです。

keysの中身は、こうなります。

["番号","名称","説明","住所","電話番号","問い合わせ先","緯度","経度"]

２行目以降は、対応する項目を先ほど保存したキーとともにNSDictionaryを構築し、NSArrayに格納しています。最終的にこのようなデータが作成されます。

要素[0]
{ 番号 : 165 , 名称 : "東雲寺の摩利支天", 説明 : "東雲寺の摩利支天,勝負必勝の神様として有名な摩利支天。本来は安産・航海・大漁・勝負の神様として信仰を集めている。", 住所 : "湖西市神座463", ........ }
要素[1]
{ 番号 : 172 , 名称 : "はままつフラワーパーク", 説明 : "大温室・クリスタルパレス内にある、「サボテンの花の咲いているところ」を「好きな人」と見ることができたら、「恋がうまくいく」という噂がある。", 住所 : "浜松市西区舘山寺町195", ........ }
:
:

このデータにアクセスする場合、例えば２行目のデータの名称を参照したい場合は、と書けばOKです。

これでデータの準備ができました。あとは、これをUITableViewに一覧表示したり、緯度経度があるのでマップ表示したりできます。

最後は、ものすごくはしょりましたが、オープンデータをNSArrayとNSDictionaryをうまく使って表示する方法をご紹介しました。
今回は、CSVファイルの処理についてご紹介しましたが、一般的なWeb APIで取得できるデータ形式は、JSONかXMLです。これらもデータを受信したら、NSArray とNSDictionaryで扱うことでデータを簡単に扱うことができます。

このアプリのソースはGitHubにあげておきましたので、参考にしてみてください（こちらのソースでは、CSVを毎回ダウンロードするのではなく、１度だけダウンロードしてキャッシュするような処理を加えています。
）。また「ふじのくにオープンデータカタログ」をはじめ、今年は、その他自治体でもオープンデータが公開されていくと思いますので、ぜひオープンデータを活用してアプリを作ってみてください。

ふじのくにエンゼルパワースポットは、県のサイトでも公開されています。
ソースコードのハイライトはSyntaxHighlighterを使用しました。


  Read More

こんにちは。２月からiAに入社しました、まつながと申します。特技は、iPhoneアプリ開発です。今年、しずおかオンライングループではアプリをガンガンとリリースしていく予定なのです。

そこで、今回は、使ってもらえるiPhoneアプリのUIについて考えてみようと思います。

iPhoneのアプリ開発者は、Appleが定める「iOSヒューマンインターフェイスガイドライン」に沿って開発することになっています。

iOS 7になってからいわゆる「フラットデザイン」が採用されました。2013年の6月に発表されたこの新しいデザインは、識者の中でも意見が分かれました。

なかでもボタンが平面になってしまったことにより、どこを押したらよいのかわからなくなったとの意見が聞かれました。

フラットになったボタンは画面のコンテンツ中に溶け込んでしまうと、本来押して欲しいところを押してもらえない、つまり、使ってもらいたい機能が使ってもらえないということになります。これは制作者サイドからすると致命的です。


iOS 7のガイドラインでは、全画面表示や、奥行き感を推奨しています。といって、このように写真の上にボタンを乗っけてしまうと、誰も押してくれないUIの出来上がりです。

また、iOSが標準で用意しているシステムボタンも大幅にかわりました。



なかでも、わかりにくくなったと言われるのがこいつです。

「アクションボタン」といわれるやつですね。現在表示されているものに対して、何かしらの操作を行う時に使われます。




こんな場面にもよく使われますよね。このボタンを押すと、TwitterやFacebookなどに共有できたりするあれです。

実は、現在開発中のアプリは、最初、このボタンを配置していました。しかし、何人かの人に触ってみてもらったところ、このボタンを押して、共有できると思った人はいませんでした。

アプリを使って共有してもらいたいんです。Twitter、Facebook、LINEにだってどんどん情報を拡散してもらいたいのです。

ということで、わが社のクリエイティブチームに「とにかく押してもらえるボタンのデザインを」とリクエストです。

そして、翌日、クリエイティブチームからは、こちらのボタンがあがってきました。


見覚えのあるボタンですよね。そう、iOS 6の時代のアクションボタンは、このデザインでした。


うん、こちらの方がしっくりきますね。なじみがあるというか、iOS 6の時のこのデザインの完成度が高かったんでしょうね。
そして、デザイナーさんからもう一言。「ボタンを下に持ってきて、真ん中に配置しましょう!」




ということで、このような感じになりました。どうでしょうか？　最初の右上に配置したボタンよりも、かなり押してくれそう感が高まったのではないでしょうか？

来月から、アプリをガンガンとリリースしていきます。少しでも使ってもらえるアプリを、楽しさや便利さを与えることができるアプリを作っていきたいと思います。

まもなくリリースされるアプリたちの中に、

このボタンを見つけたら、ぜひ、押してみてくださいね。

（さくらの写真は、ばくたそさんから利用させていただきました）


  

androidの開発環境は、いろいろなものが登場しています。
そこでざっとオサライをしたく思いまして、調査しました。

●androidの定番開発環境　Javaで開発(eclipse + Android SDK)

androidでは当初からJAVAの開発環境として、上記の組み合わせが推奨されてきました。
このための関連本もたくさんあります。
androidの開発者はアプリをできるだけたくさん作ってほしかったらしく、エンジニア人口の一番多い開発言語Javaを開発言語として採用したそうです。
考えてみればandroidはLinuxベースなので、別にどの開発言語でも良かったわけですね。


●C/C++で開発(eclipse + Android SDK + C/C++開発ツール + Android NDK)

LinuxベースならばC/C++というのも有りかと思いましたら、やはりありました。
AndroidのアプリケーションはDalvikと呼ばれる仮想マシン(バーチャルマシン)の上で動作しています。
DalvikはJava言語で記述されたプログラムの実行環境です。一般的なJavaで記述されたアプリケーションはDalvikを介して実行されるため、Native(C/C++)で書かれたプログラムよりも実行速度が遅くなってしまいます。
NDKは動作速度を向上するために使われるほか、
C/C++環境で開発された資産をライブラリとして(わざわざJavaへ移植しないでよい)活用できるといった利点もあります。一方でJavaの恩恵（GCなど）が得られない、アーキテクチャに依存するなどデメリットもあります(NDKを使うとアプリケーションの動作環境が限られ、対応外のアーキテクチャでは動きません)。

なお、Android 2.2以降では、JIT(Just in Time)コンパイラが導入されて動作速度は改善されています。
eclipseを使用する形はJavaとあまり変わりはないかもしれません。

詳しい組み込みの手順は以下のサイトに有ります。
http://www.kkaneko.com/rinkou/js/andkwin.html


●Javascriptで開発

1.PhoneGapで開発
http://phonegap.com/

PhoneGapは、アドビシステムズが開発しているオープンソースのモバイルデバイス用フレームワーク「Apache Cordova」のディストリビューションの1つです。もともとはカナダのNitobi社が開発を行っているスマートフォン向けのハイブリッドアプリケーション制作のためのフレームワークでした。2011年にアドビ社が、Nitobi社を買収し、現在はオープンソースであるCordovaをアドビ社が配布する時は、PhoneGapという名前になっているそうです。
JavaやObjective-Cを書かなくても、HTMLやCSS、JavaScriptだけで、iOS（iPhone／iPad／iPod touch）・Androidアプリを作成できます。このフレームワークでは、JavaScriptからネイティブAPIへのブリッジ機能を提供しているので、Webの技術を利用して作成したコンテンツからデバイス固有機能を利用できます。

こちらもeclipseを使用する形はJavaとあまり変わりはないかもしれません。
http://www.atmarkit.co.jp/ait/articles/1107/26/news109.html


1-2.PhoneGapベースの統合開発環境
以下は統合された開発環境をクラウドサービスです。開発者はアプリ開発の一連の作業をすべてWebブラウザを通じて行うことができます。
制限付き無料で開発できます。有料の場合の利用料はどちらも似たようなものです。

「Monaca」
http://monaca.mobi/ja/

「Adobe® PhoneGap™ Build」
https://build.phonegap.com/?locale=ja_JP


2.Titanium Mobileで開発
http://www.appcelerator.com/titanium/
http://faq.titanium-mobile.jp/

Titanium Mobileとは、Appcelerator社によるスマートフォン対応アプリケーションの開発環境です。iOS（iPhone／iPad／iPod touch）・Androidアプリを作成できます。
PhoneGapはHTML5やJavaScriptが「そのまま」アプリ化されますが、Titaniumは、一旦JavaScriptをコンパイルしたものがアプリとなります。

統合開発環境として「Titanium Studio」がリリースされており、これだけでまとめて必要なツール類が一気にインストールできます。
ここで紹介している他の開発環境に比べて組み合わせて複数インストール必要もなく、また、PCの環境変数を設定追加する必要もないため、一番簡単なインストール環境かもしれません。
http://titanium-mobile.jimdo.com/titanium-studio%E3%81%A7%E3%81%AF%E3%81%98%E3%82%81%E3%82%8Bandroid%E3%82%A2%E3%83%97%E3%83%AA%E9%96%8B%E7%99%BA/%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83%E3%82%92%E3%81%A4%E3%81%8F%E3%82%8B%E3%81%B9%E3%81%97/

無料で利用できるのは“Community”プランです。ほかのプランは有料（最初のひと月は無料）ですが，Appcelerator社のサポートが受けられるほか，有料のモジュールが使えるなどさまざまな利点があるようです。


3.Unityで開発
http://japan.unity3d.com/

Unity は、Windows と OS X 上で動作する統合型のゲーム開発環境です。iOS、Android、Windows、Mac OS X、Web、Wii U、PlayStation3、Xbox 360 など様々なプラットフォームへ向けた高度な 3D アプリケーションを制作することが出来ます。

JavaScript、C#、Boo の3つの言語の好きなものを利用して、スクリプトを作成し、オープンソースの .NET プラットフォームである Mono の上でスクリプトが実行されます。
ゲームの舞台となる3Dのシーンの構築ツールなど、はっきり言ってこれは別世界の統合開発ツールです。

UnityとUnity Proの2種類のライセンスがあります。
プロバージョンは1500ドルですが、レギュラーバージョンは無料でダウンロードできます。
プロバージョンではテクスチャーへのレンダリング、オクルージョンカリング、グローバルライトニング、ポストプロセッシングエフェクトといった機能が追加されます。一方無料バージョンではスプラッシュスクリーン（スタンドアロンのゲームにおいて）やウォーターマーク（ウェブゲームにおいて）の表示が絶対に必要です。


●Webサイトをアプリ化
ブラウザアプリのように要はWebサイトをアプリっぽく作ってしまう手法です。
すごく簡単にすぐにでも構築できます。
ただし、Google Playストアには登録できませんけど。


●番外編
よくわかりませんがBasicでも開発できるようです。
下はテトリスのサンプルコードです。Basicで書かれています。
https://code.google.com/p/simple/source/browse/trunk/simple/samples/Tetris/src/com/google/devtools/simple/samples/tetris/Tetris.simple



●それではどれが良いのか
下記のように一長一短があります。

モバイルアプリ開発手法の特徴比較

	Webサイトをアプリ化	ハイブリッド(PhoneGap/Titanium)	ネイティブ開発(Java C/C++)
スキルレベル	◎	○	△
パフォーマンス	△	○	◎
デバイス依存性	◎	○	△
開発時間	◎	○	△
開発ライフサイクル	◎	◎	△
可搬性	◎	○	△
デバイス機能利用	△	○	◎
パッケージング	△	◎	◎
拡張性	△	◎	◎

ハイブリッド(PhoneGap/Titanium)はだんだん改善はされてはいますが、ネイティブで作られたアプリに比べて速度が遅いと感じるケースが多いそうです。
また、PhoneGapは、あくまでHTMLやJavaScriptを使ってアプリを作るためのツールです。
アプリを作る ためのフレームワークやテンプレートが提供されている訳ではありません。
jQuery MobileやSencha Touchといった、ユーザーインターフェースを作るためのツールを組み合わせるのが主流のようです。
(Titanium StudioはOS標準のUIを利用すること前提としています。)

個人的には手のこんだものでなければ、「Titanium Studio」が一番気軽に開発でき、破綻が来たらネイティブ開発(Java)が一番、問題が少ないように感じました。
なんだか当たり前の結論で申し訳ありませんが…

※ところで定番の開発環境は旧公式統合開発環境 Eclipse から 新公式 Android Studioへ移行していますね。
「PhoneGap」も組込みできるようです。
http://www.auraline.co.jp/tech-lab/?p=180