JDBな人生  専門的なことから日常的なことまで~ まぁ自由きままに書いていきます。
2017年03月 / 10月<< 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>11月

アクセスランキング

[ジャンルランキング]
コンピュータ
364位
アクセスランキングを見る>>

[サブジャンルランキング]
プログラミング
46位
アクセスランキングを見る>>

WEBアプリ vs. ネイティブアプリ論争の決着?

 お久しぶりです。ずいぶん長いこと広告が表示されていました。

 先日、こんな記事(↓)を見かけました。お約束のこの話題ですが、なんと決着がついたとのことです。

HTML5 vs. Native: The Debate Is Over - DZone Mobile
https://dzone.com/articles/html5-vs-native-the-debate-is-over

 大雑把に要約すると、①市場はネイティブ開発を選んでいる②なんだかんだ言ってやっぱりそれが一番良い、という内容です。

 筆者がWEB推しなのは読者の皆さん(?)であればご存知かと思いますが、ここ一年ちょっとiOS/Androidのネイティブアプリの開発に携わってきて、「UXを第一に考えるならやっぱりネイティブ開発じゃないとなあ」と漠然と感じています。

 ブラウザの対応能力の限界という意味もありますし(それこそいわゆる音ゲーをWEBでというのは反応・処理速度から言って厳しいと思います)、iOS/Androidともに見過ごせない新機能がいくつも追加されている中、その端末上で引き出せる最高の使用感というものを実現するためには、ブラウザの中だけでは制限が大きすぎます。WEBベースだと実現しにくい機能はいくつもありますが、その中でも特に通知や連携は重要、重大な要素です。

 記事中では、他にセキュリティはどうか(保存領域の安全性)、通信環境が悪い時はどうか、という点にも触れていますが、これらについてはそんなに大きくとる必要は無いと考えています。
 前者については、まずHTML5のストレージのセキュリティはそんなにざるではないはずですし、WEBアプリはともかくハイブリッドアプリにすれば、トークン類の保存だけはOSの機能を使う、という対応もできることがあります。
 後者については、そもそもネイティブアプリの中にもオフラインではほとんど使えないものがありますし、上手く設定さえすれば、オフラインで全く使えないという事態は避けられます。ただし、この設定自体がややこしいことと、ユーザデータをどう保持しておくか、という点が悩ましく、また工数増加に繋がることは指摘する必要があります。

 じゃあ結局どっちなんだ、という話ですが、やはり「スマホアプリ」というメディアの魅力を最大限引き出すためには、ネイティブでしっかりと作り込んだ方が良いと思います。この点については経験上でも、先ほどの記事を念頭に置いてもはっきりと言えます。
 一方で、OSのサポート・端末の性能向上という意味でも、ライブラリの充実という意味でも、ハイブリッド開発を支援する各種ソリューションの進歩という意味でも、WEBベースのアプリを開発する基盤はかなり整ってきています。そうした点を考慮すれば、多少の妥協の上でWEBアプリやハイブリッドアプリの形を選択するというのも、「今となっては」立派な選択肢の一つだと言えるはずです。Facebookが撤退した頃と比べれば状況はずいぶん改善されています。
 それこそiOS, Androidで動くのは当然のこと、B2B向けにWindows Phoneにも展開したい、でも開発リソースがあまりない、とかいう状況だったら悪くない選択になるかもしれません。そんな状況なら進出するな、という気もしますが…。

 最後に一つ付け加えておくと、

Welcome
http://docs.nativescript.org/

 最近知ったのですが、こんなものも登場しているようです。TypeScriptとAngular(の新しい方)を使って、ネイティブアプリをビルドできるとかいう話です。これはこれで今後の展開が面白そうですね。機会があれば少し使ってみようと思います。そのうちレビューの記事でも書くかもしれません。
スポンサーサイト
   プログラミング/開発全般    TB(0)    CM(0)    EDIT    ページ↑

順列を書き並べる

お久しぶりです。
突然ですが、今日は訳あって任意の要素数の順列を書き並べるコードを考えていました。

せっかくなので関数型プログラミングっぽく。と思っていたのですが、要素の重複があった場合のことを考えると、indexを使って実装せざるを得ないですね。

[1, 2, 3, 4, 5]から[1, 2, 3]を抽出するコードは別で準備するということで。といってもslice(0, 3)するだけです。

//重複があると動かない
var f = function(a, p, c) {
  if (p.length == a.length) return c(p);
  a.forEach(function(i) {
    if (p.indexOf(i) != -1) return;
    f(a, p.concat([i]), c);
  });
};

//重複があってもいい
var f = function(a, p, c) {
  if (a.length == 0) return c(p);
  a.forEach(function(item, index, a) {
    f(
      a.slice(0, index).concat(
        a.slice(index + 1, a.length)
      ),
      p.concat([item]),
      c
    );
  });
}

f([1, 2, 3], [], function(row) {
  console.log(row);
});


階乗の性質上、どんどんどんどん総数が大きくなっていくので、実際にこの関数が使い物になるのはほんの小さな範囲だけです。JSだとせいぜいn=10ちょっとくらいだと思います。

そんな使い物にならないコードをわざわざ載せるのはどうなんだという気もしつつ、せっかく考えたので載せておきます。
   プログラミング/開発全般    TB(0)    CM(0)    EDIT    ページ↑

"Web API: The Good Parts "を読んで

お久しぶりです。
ブログに広告が表示されるのをみるたびに、「ああ、また一ヶ月が過ぎたのか」と思います。バタバタしているとあっという間です。

さて、先週、"Web API: The Good Parts "というオライリー本を読みました。タイトルはいかにも洋書という感じですが、著者は水野貴明さんという日本人です。似たタイトルの本としてJavaScriptやJavaのGood Partsを紹介している本があるので、それと同じような趣旨の本ということですね。

O'Reilly Japan - Web API: The Good Parts
http://www.oreilly.co.jp/books/9784873116860/

picture_large978-4-87311-686-0.jpeg

全体の印象としては、APIを設計する上で知っとくと便利なポイント・ベストプラクティスを広く紹介していて、これからWeb APIを構築・リファクタリングしたいという人(自分がまさにそうなのですが)には、復習・最新の動向の確認という点で、一度読んでおきたい内容だったと思います。

大まかな内容は、APIはどうあるべきかという内容から入り、URIの構造、リクエストの方法、レスポンスの方法、データの構造、HTTPの仕様の活用、セキュリティ対策、といった具合です。

複数の既存のAPIを比較しながら、「ここは〜なので参考にしよう」という紹介をしていた点や、「ProgrammableWebのAPIデータベースを確認して実際どんな感じかよく見るように」という注意書きを何回かしていたところも印象的でした。
常に移り変わるWEBの世界なので、特定の「ベストプラクティス」に固執せずに、周りの様子もよく見ながら改善していこう、ということです。

おすすめ度としては5段階評価で4でしょうか。特別「おすすめします!!必ず読むべきです!!!」という感じでもないのですが、知っておくとまあまあ役立ちそうな豆知識を多く扱っているので、時間がとれればぜひ読んでみてください、というところですね。

「使ってくれるかどうかに関わらず、APIはできるだけ公開してみましょう」という話でしたから、次のリファクタリングでは仕様を公開することにしようと思います。
   プログラミング/開発全般    TB(0)    CM(0)    EDIT    ページ↑

“WEBサイト”と“アプリケーション”の境界線

※この記事でいう「アプリケーション」は、主にメール・SNS等のクライアントプログラムのことを指しています。

先日、スマートフォン向けのWEB技術をベースとしたアプリケーション(以下WEBベースアプリケーションと記します)のフレームワークを開発するという記事を書きました。(JTL WebApp FrameworkとかJLT WebApp Frameworkとか言ってたやつです)

開発はある程度進み、フレームワークと呼べるだけの動作をするようになりました。具体的には、Applpication - Stage - Pageの三層の概念を定義し、それらの各構成部品を切り替えていく形です。
実際に簡単な問題集のアプリケーションを作ってみましたが、一定のテンプレートを作って開発効率を下げる、という点では上手く行ったと思います。

しかし、設計を見直したく、現在は開発を中断しています。この記事はその経緯について記したものです。
技術的に具体的な内容を扱うわけでもなく、特に読んで役立つというものではありませんが、管理者のちょっとした考え事に付き合ってくださる方は、読んでいただければと思います。

先日、「WEBベースアプリケーションとネイティブアプリケーションの違い」についての記事を書きました。(こちらです)
それに関連する話なのですが、そもそも「アプリケーション」とは何か、というところから話は始まります。

研究社 英和コンピューター用語辞典によれば、"application"は、『ユーザーの具体的用途に適合した処理を行なうプログラム』とされています。つまり、WEBであろうがネイティブであろうが、ユーザの具体的な用途(たとえばメール、SNS、メモ、計算などなど)のために作られたプログラムは、“アプリケーション”と呼んで良いということです。また、その「具体的用途」は、「サービス」と読み替えることもできるでしょう。

つまり、この「具体的な用途のための処理をする」という条件を満たしていれば、もちろんWEB技術によって成り立つWEBサイトも含むことができるというわけです。ただし、現在のWEB制作の潮流である、「どんな種類の端末からでも、どんな種類のブラウザからでも快適にコンテンツが利用できる」ということ、一例としてレスポンシブWEBデザインを挙げますが、画面の構成を固定してしまうWEBベースアプリケーション開発は、これに相反するものがあります。まず、こうしたアプリケーションは、PCやタブレットで使用するには少しレイアウト上使用性が低くなります。実際には、PC用もスマートフォン用も用意して対応しているサイトが多くみられます。
では、「WEBベースアプリケーションとレスポンシブデザインWEBデザインは共存できないのか」、というと、そんなことはないと考えています。一例ですが、Google Play Developer Consoleは、PCからでもスマートフォンからでも、同じ要素を違った構成で見せることで、使いやすさや機能を犠牲にすることなく、複数デバイスに対応できています。

異なる例として、あるサービス(どれとは言いませんが)では、ネイティブアプリをわざわざ開発しているのに、中のWebViewを通してWEBサイトを利用できるために、ネイティブアプリの必要性が薄くなっているものもあります。そのとき、ネイティブアプリから操作しなくても十分に使えるサイトなのになぜあえてネイティブアプリから使わなければならないのか?という疑問が生じました。

そろそろ、いったいこの記事では何の話をしているんだ、と感じるかもしれませんが、そこでタイトルに戻ります。ずばり、『WEBサイトとアプリケーションの境界線はどこにあるのか』です。
先ほど二つのサイトの例を挙げましたが、現在さまざまな「サービス」がWEBページから利用できる以上、ほかの携帯端末の利用についてもWEBページから使えても良いはずです。ここで大切なのは、そもそもPCから利用できるようなTwitter, Facebook, Gmailといった「WEBベース」の「サービス」たちが、「アプリケーション」であるということです。その点では、そうしたWEBベースのサービスとそのWEBサイトは、「WEBサイト」であると同時に「アプリケーション」でもあるということですね。すなわちタイトルに対する答えは、「何かのサービスのためのサイトならばどちらにも当てはまる(境界を定義する必要はない)」ということです。

そうしたことがあって、その開発中のフレームワークをレスポンシブ“アプリケーション”デザインとして設計し直したい、と思うようになりました。「ネイティブアプリっぽいWEBサイト」ではなく、近頃の潮流に合わせた、さまざまな端末に対応できる「WEBサイトっぽいアプリケーションっぽいWEBサイト」を目指していくべきなのではないか、ということです。
言い換えれば、世の中の色々な「WEBサービス」から派生した各「アプリケーション」は、いずれはレスポンシブWEBデザインを含めたWEB技術により制作・開発されたWEBサイトに統合されるのではないか、という話です。
まああくまで一説を提唱しているに過ぎません。Facebookの失敗談もありますし、今後実際どうなるかなんてわかりませんけどね。
しかし、世の中チャットアプリのようにリアルタイム性が要求されるサービスばかりではありませんし、それを除いて考えれば、一つに統合してしまっても特に困らないサービスはよく見られるはずです。

また同時に、何かのサービスを開発するとき、そのコンソールとなるWEBサイト・ページをはじめからレスポンシブWEBデザインで設計することで、わざわざ「ネイティブアプリケーション」や「WEBベースアプリケーション」など、どういった手法で開発するのか悩んだり、時間をかけて新たな「アプリケーション」として開発する必要もなくなるのではないか(『「WEBサイト」は「WEBサイト」のままでいいじゃないか』ということです)とも考えています。

とはいっても、しばらくは開発に時間を割く余裕はなさそうなので、こうやって思案するばかりなんですけどね。
   プログラミング/開発全般    TB(0)    CM(0)    EDIT    ページ↑

スマホアプリ開発とWEB技術

近頃、スマートフォン向けのツールを作ることが増えてきました。主にはAndroidがターゲットですが、ものによってはiOSや他の環境をターゲットとすることもあります。
そこで考えたことをいくつか。(まあよく話題になることですが)

一般的に、Android向けの開発には、Java/Android SDKによるネイティブ開発と、HTML/CSS/JSをはじめとしたWEB開発があります。後者はさらにブラウザ上で動作させる場合と、ネイティブアプリ内部でWebViewを用いて表示させる場合(PhoneGapをはじめとしたフレームワークの利用も含む)に分けられます。

AndroidネイティブではなくあえてWEB系の技術を使うメリットとしては、iOSやWindows Phoneなど他の環境への移植がしやすいということ、一般的なWEB制作に関する資源を流用できるということなどがあります。

自分はLAMPをベースにRIA開発を行うことが多いので、WEB系の技術・資産を流用できるというのは大きなメリットですが、その中でいくつかの問題に直面しました。特にブラウザ上での動作を想定したアプリケーションについての問題と、その解決策についての内容です。

  1. WEBブラウザによる違いによる問題
    これは動作の方法にもよりますが、ここでは標準ブラウザだけではなくFirefoxやOperaなど他のブラウザも含めて考えます。
    ブラウザ間の仕様の違いにより、解釈が微妙に変わります。自分の用意できない環境でどう動くかはわからないため、その違いを吸収するだけではなく、その問題を見つけるためにも手間がかかります。

    実際に対応を行ったものとして、Android標準ブラウザのバージョンごとの仕様の違い(SelectBoxのバグ)、HTML5から加わったAudio要素の対応形式の違い(MP3を再生できるブラウザとできないブラウザが存在)、input:button要素の表示の違い(角丸のありなし)、WebStrage対応の違いなどがあります。

    PhoneGapを利用したときにも、標準ブラウザのバージョンによって動作が変わり、対応に追われました。

    ⇒解決策
    できるだけ多くの環境で動作確認を行う

  2. クロスドメイン通信に関する問題
    これもまたよく知られているものですが、リソースを他のドメインから取得しようとする場合、場合によってはそれらのリソースにアクセスすることができません。具体的には、AjaxやAudioのクロスドメイン通信の制限があります。
    PhoneGapなどのフレームワークを用いたものであればそれらの制限にかからずに済みますが、一般的なブラウザ上で動作させる場合には、それらの制限にかからないように開発を行う必要があります。

    ⇒解決策
    リソースを可能な限り同じドメインに配置する
    JSONPなどの回避策を利用する

  3. デバイスの機能の利用に関する問題
    GPSやモーションセンサー、カメラなどについては、一部のブラウザからはアクセスすることができますが、まだ対応は一部のみでしかありありません。これらを利用したいときには、ネイティブで作った方が手間がかからなさそうです。

    ⇒解決策
    ブラウザからアクセスできない機能を使わないで済む設計にする
    必要な機能にアクセスできるブラウザのみを対象に開発を行う
    必要な部分のみネイティブで開発しWebViewを埋め込む/PhoneGapなどのフレームワークを通じて使う

  4. OSの機能の利用に関する問題
    プッシュ通知や戻るボタン・メニューボタンなどOSの機能を利用するものも、ネイティブからでないと利用できないものがあります。また日付時刻の選択やダイアログなどのOSの用意しているUI要素を利用することもできません。ただしこれについては、独自に実装することで環境によるUIの違いを吸収できるという考えかたもできます。
    またスリープ状態への遷移に関する設定・バックグラウンド通信等についても利用することはできません。
    プッシュ通知については、プッシュ通知に関する情報の送受信・表示・対象画面へのアクセスのみを行うサービスを開発・利用することにしました。

    ⇒解決策
    独自UIで統一する
    プッシュ通知は独立させる


主にはこんなところです。
他にも多くの問題がありますが、OSやバージョンの垣根を越えて“大抵は”“大体”同じように動作するWEB技術による開発は、大きな可能性を秘めていると思います。

何かアドバイスや情報などあればぜひコメントをお願いします!
   プログラミング/開発全般    TB(0)    CM(0)    EDIT    ページ↑

プロフィール

JDB Luigi

Author:JDB Luigi
どこにでもいるようなありふれた人間・・・という訳でもなく、かと言って怪しい宗教を信仰する変人という訳でも無い。

基本的に掲載しているコード等は煮ていただいても焼いていただいても結構ですが、利用は自己責任にてお願いいします。
また、バグ・アドバイス等もしあればよろしくお願いします。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。