Android Bazaar and Conference 2011 winter (#abc2011w)の講演で聞いた内容をまとめてみた
-Android Bazaar and Conference 2011 Winterに行ってきました！
講演のメモをとったので、日記にて公開してしまいます！
docomo
今起きていること
2008-2009
- ケータイに比べて見劣りする。
- ケータイユーザーに受け入れられない。
- 所詮ガジェット
- 評価ポイントで、考えるべきこと。
- ポテンシャル
- 連鎖反応
- 種になりうる存在かどうか。
- 市場のabsorption capacity
- いわゆる、政策決定をする際に、市場社会に受け入れられるか、そのキャパシティがあるか？
- スマートフォンの技術自体は、それほど新しくない。
- 市場だったり、というものが整うことで、条件を満たし、売れていく。
Revolution
- 激しい変化が起きている。
- Rev.1, Rev.2, Rev.3
- Rev.1
- 1980' 1990' デジタル化。
- Rev.2
- 現在
- speed, smartm scalable
- speed: 段違いのスピードで、開発や、発展が早くなっている。
- smart: 今までの使いづらいインターフェースが、使いやすくシンプルに。
- scale: リソースが無限のスケールで、広がっていく。
- ケータイ含め、今までと全く違うルールで進化が進んでいる。
- catastrophe
- 急激な相転移に注意。
- 今まで連続的に続いていたものが、ぐっと、変わってしまう。
- Rev.3
- ?
Androidの役割
Carrierの行く末
- キャリアが端末をどんどん市場に投入している。
- ただ、２つの力に翻弄される。
- 没落しないために、もがいている状況
- Pipe（土管）を超える
- ダムパイプになってはいけない。付加価値を生み出す。
- そのためには、コネクティビティを提供しなければいけない。
- Conduitになる。社会を支える導管ネットワーク。
- 目的を持って、活動を支えるためにネットワークする。
- 例えばLTEのように大量のデータを流す。
- ケータイの終焉
- 主役はスマートデバイスに。
- 順応して、成長して、いかなければ、終焉してしまう。
- Service
- Rev2のルールに則ったサービス開発
- 議論をしていると忘れがれらちなのは、ルールは変わってきている、ということ。
これからの変化
- absortion capacity
- 医療援助のシステムを考えている人から得たこと。
- いろいろな国に医療援助システムをもっていっても、受け入れられない
- absortion capacityが必要
- 社会も、ユーザーも、不足しているとイノベーションが育たない。
- 医療援助のシステムを考えている人から得たこと。
- これから起こることは、めまぐるしい変化。
- それは、absortion capacity が整っている、という証拠。
- 単なるデジタル化は通用しない。
- Rev.1の時期と同じようにサービス化していくだけでは、もはや不十分。
- docomoでも単なるデジタル化の失敗が起きている。
- 全世界的に変化している。そもそもつくり直していかないといけない。
- 事象の地平線。
- これから風景が一変する。
- 電子書籍も、まだまだ単なるデジタル化で終わってしまっている部分がある。
- これからどんどん変わっていくだろう。
2011
- Rev3
- 技術の特異点
- 人の知能を超えるポイント。
- このスタートが2011年かもしれない。
- 技術の特異点
質疑応答
- 囲い込み or オープン化
- Rev.2はオープン。これが必然。
- 囲い込みができないことはないだろうが、いたずらにそれをすると、つながりをたってしまう。
- imodeが囲い込みとみられてしまっていたのは、しょうがないこと。
- これからは、オープンを進めていく。
- 現状の公式CPさんがたくさんいて、危機感を持っていて、試行錯誤していると思う。
- セキュアな環境の中で、ビジネスをしていくようなことはどうなるか？
- 今後成長していける土台を作っていくことが重要。
- そのために、今までの方法論がそぐわないものが多い
- 本質としてお客様が一番使いやすいことであれば全力で継承させていきたい。
- 今のままでは移行できないことが事実。これを乗り越えてほしい。
GREE 開発
スマートフォン版GREE
- 2010.08.09リリース
- HTML5 + CSS3 + Javascript
- 例えばCSSアニメーションを使ったイメージスライドショーでは、Javascriptによるプリロードを使っている。
- 要素技術としては、
- android, iOSともに、webkitベースブラウザ
- 新技術を積極的に採用できる。
- IEがいないからめっちゃ楽。
- Ajax
- 全てAjaxを使った操作
- HTML5
- HTML Formsを有効利用
- フォーム機能の拡張。
- placeholderをサポート
- データ型の明示
- input type="email"...
- type="email"だと、スクリーンキーボードがemailアドレスを打ちやすいレイアウトになる。
- Androidは未対応。
- type="email"を設定すると、パスワードを覚えてもらえなくなる、というバグがある。
- type="number"とか、type="tel"だと、数字のキーボード
- 他には、url、date、searchなど。
- 今後ブラウザが対応していくはずなので、適切に設定しておくべき。
- CSS3（webkit向け）
- android, iOSともに、webkitベースブラウザ
- 困ったこと
- アニメGIF未対応
- CANVASで書く。
- 多くの端末がDevicePixelRatioが1.5
- つまり、普通の1pxが、Deviceでは1.5pxになる
- その関係で、画像がぼんやりして見えてしまう
- 解決策
- 2倍のサイズの画像を縮小させると、ぼんやりしない。
- metaタグを追加。
- アニメGIF未対応
ネイティブアプリとHTMLの連携
- カメラアクセスなどは、アプリをうまく使う。
- Androidアプリの中で、、
- UIは基本的にWebViewを使ってサイトとほぼ同様のページを表示させる。
- カメラアクセスの部分を、WebViewの機能を使ってつくっていく。
- Javascript -> Java（HTML -> アプリの機能）
- WebView.addJavascriptInterfaceを使って、JavascriptからJavaの特定のクラスへアクセスさせるInterfaceを用意しておく。
- Java -> Javascript（アプリ -> HTML（画像））
- WebView.loadUrl(...)を使ってHTMLに画像を読み込ませる
- これらのことは、iOSでも同様のことができる。
- 1つのHTMLで、複数プラットフォームを実現できる。
- アプリ側のクライアントはそのまま、表示変更が可能
-
- iphoneアプリの審査をがんばる必要がない。
-
hatena
- hatena
- perl
- A place for fun & creativity
フォトライフ
- ウェブでは解決できないことを解決する。
- はてなフォトライフの写真を快適に閲覧する
- 写真アップロード、自動アップロード
- スライドショー
- ActivityStackを活用した実装にする。
- Stackに残っているActivityインスタンスは解放されない。
- Androidは、ユーザーが操作しているActivityが属するアプリケーションを自動でkillしない。古すぎるActivityは開放される。
- 大量に保持するとOOMする。
- Androidは、ユーザーが操作しているActivityが属するアプリケーションを自動でkillしない。古すぎるActivityは開放される。
- 端末回転
- 開店時に発生するonRetainNonConfigurationInstanceを真面目に実装して解消。
- メモリ解放は繊細に実装したほうがいい
- 端末回転も真面目に実装したほうがいい
- 写真アップロード
- Serviceを使わなくても実装できるかと思ったが無理だった
- Service == WorkerServer的な物。
- ProgressNoticationに苦労。でも基本に忠実に。
- Service自体は、極力小さくして、あげるとkillされにくくなる。
- 非同期API、同期APIどちらにも対応。
- アップロード情報をとりたい場合には同期APIを使う。
- Serviceの常時起動
- 基本的にServiceは死なないことになっているが、なんらかの形で死ぬと困るので、AlarmManagerで定期的に死活監視をして確認している。
- 起動直後の時間狂い
- TZの設定に遅延がある。
- メモリ消費削減の手
- Memory Analyzer
- どんなオブジェクトがメモリ消費しているのかわかる。
- Eclipseプラグイン
- DDMSで見れるスレッド一覧
- 意図していないスレッドができていないか？
- HttpClientがスレッドを作るので一本化した。
- StaticInstanceにする。
- trace view
- どのスレッドが、どのくらい消費しているかを、グラフィカルに
- profilingは勘でやってはいけない。
- Memory Analyzer
- bug reportのtips
- メールレポートをしてくれるようにした。
- http://subtech.g.hatena.ne.jp/cho45/20100210/1265797885
はてなログイン管理
はてなモノリス
- 最小工数で実装。
- 出来る限りウェブで
- ウェブとのシームレスな連携をしたい！
- AndroidOS自体が、シームレスなのでそれを使いたい！
- zxingを使用。
- 最大限利用したいが、ちょっと無理な部分があった。
- ウェブ連携
- 特定のIntentをで投げると、開発者用設定を出せる。
- adb shell am startを使って手動Intentを投げ設定値を表示してあげる。
はてなココ
- WebViewの組み込み
- 開発者がほぼひとりで、バックエンドからアプリまで作っているので、インターフェースを最小限にできる。
ウェブ開発者側で思っていること
- やっぱりウェブ
- Intentは高級なハイパーリンク
- ウェブとのシームレスな連携がうまくいくと恐ろしく未来的になってくれる。
- refs developer.hatena.ne.jp
GREE ビジネス
background
位置づけ
- iPhone
- closedな感じ、など。
- Andorid
- openな感じ、など。
- 注力したい。
smartphone GREE
- featurephone -> smartphone
- スマートフォンは表現等しやすい。
- 工夫のやりがいもある。
- ユーザーの移行が課題。
- SP版のSNSを構築。
- ソーシャルゲーム、アプリを移植
- featurephoneで築いた基板はしっかりと継承していく必要がある。
- GREE ID を全てで共通化。
- Browser版
- HTML5 + Javascriptで再構築。
- リアルタイムウェブを意識したUserExperienceを構築していく。
- iPhone App
- 新規会員獲得について
- アプリ開発
- キャリア・端末メーカーとの連携
- TVCM
GREE platform for smartphone
- これから進めていく。
- SDKや課金の仕組みをつくっていく。
- パートナーへのビジネスの提供。
- パートナー自身がGREEを使ってビジネスができる。
- featurephone版では月商数億円レベルのものが出てきている。
- スマートフォンも幅広い。
- ウェブアプリ
- iOSアプリ
- Androidアプリ
- マルチOS、マルチデバイスへ対応。
- ウェブアプリ
- featurephoneと同様にゲーム提供できる。
- ネイティブアプリ
- GREEのアプリが提供している仕組みと同等のものを提供できる。
- ウェブアプリ
