株式会社LIFULLのブログ - TECH PLAY

TECH PLAY

株式会社LIFULL

株式会社LIFULL の技術ブログ

664

Apple原理主義者ですが、今日書く内容にその事実は関係ない大坪です。 「新しいアイディアを出そう!」(意訳) というときにブレーンストーミング-略称ブレストってよくやりますよね。真面目な誰かが「質より量」とか「他人の意見を批判しない」とか「ブレストの原則」を述べ出すと「そんなのもう聞いたよ」感が会議室に満ち溢れるくらい世の中に普及しているわけです。 個人的にこの「ブレスト」というのはよほど注意しないと有意義な結果を残せないといつも注意しています。私はバラエティ番組にでている能年某嬢くらい考えるテンポが遅いので、元気良い人が多いブレストでは発言できない。いや、それはお前がそもそも新しいアイディアを持っていないからだろう、という真っ当な指摘は無視してじゃあブレストで「すごいアイディア」がでてきたことがあるかというとあまりそういう記憶もない。 自分では「なぜそう考えるのか」説明できなかったのですが、最近見つけた記事がその理由になるかもしれない、と考え始めました。そもそもの問題意識から Meetings want to suck. Two of their favorite suckiness tactics are group brainstorming and group negotiation. 引用元: Note and vote: how to avoid groupthink in meetings | Google Ventures いいかげんな訳:会議は退屈さを欲している。会議が大好きな「退屈にする方法」はグループでのブレストとブループでの交渉だ なるほど。では彼らはどのような方法を提案しているのか?前述のページから少しはしょって引用すると (以下引用&要約しつつ和訳) 1.Note 5分か10分で個々人がアイディアを書き出す。その後2分かけて1個か2個の「これがいい」というアイディアを選ぶ。 2.Share and Capture 順番に自分がよいと思ったアイディアを発表する。「売り込み」はなし。それをホワイトボードに書き出す。 3.Vote 5分で、書き出されたアイディアのうちどれがよいと思うが決め、ノートに書く。そのあと順番に自分がよいと思ったものを発表する。(ノートに書いた内容を変えてはダメ)ホワイトボード上にどのアイディアが何票得たかを書いていく。 4.Decide 責任者がどのアイディアでいくか決定する。その際投票結果を尊重しても、尊重しなくてもよい。仮に投票結果と違う結果になっても「すべての人間の意見をちゃんと聞いた」ことになる。 以下この方法がうまく行く理由について述べられています。 個人に静かに考える時間が与えられる すべての人が並行して考えているので、「一度に一人しか発言できない」通常のブレストに比べて時間の効率がよい 投票する際に、他人の意見を聞く前に自分の意見を書き出している。つまり「他の人の意見に安易に同調する」ことがない。 最後の項目は「集合知がうまく働くための条件」とも合致している。すなわち集団での決断が「衆愚」に陥らないためには、他人に影響されない独立性を持っていないければならない、といわれています。ここで自分の判断を頭の中にだけ止めておくと 「Bがいいと思ってたけど、あの人がAと言ったからA」 的な判断に堕してしまう。あらかじめ自分の判断を書いておくことでそうした事態が防げるわけです。 また4.Decideを読んで「マキャベリ語録」のある一節を思い出しました。 あなたは、すべての事柄について質問しなければならない。そうしておいて彼らの自由率直な意見を求めるのだ。そしてそのあとで、あなた自身の判断で決定を下す マキアヴェッリ語録 P98 塩野七生著 新潮文庫  グループの各員は自由に自分の意見を表明できなくてはならない。責任者は自らの責任において決断を下さなくてはならない。一見両立が難しいように思えるこの二つの命題は実はそれほど離れていないのかもしれません。 さて このNote & Voteが提起しているもう一つの問いは 「優れたアイディアは一人の頭での深い思考からしか生まれないのではないか」 という点。こちらのページ The Design Sprint — Google Ventures The Design Sprint — Google Ventures では、彼らが実行している一週間のデザインスプリントについて述べられています。このプロセスでは、火曜日(つまり二日目)がSKETCHに当てられており、 During Sketch day, your team will work individually to draw detailed solutions on paper. As you sketch, everyone works separately to ensure maximum detail and depth with minimum groupthink. 引用元: The Design Sprint — Google Ventures 訳:Sketchの日に、チームメンバーは個々に詳細な解決案を紙に書く。個人ごとに作業するのは、グループでの思考を最小限にし、かつ(アイディアの)詳しさと深さを最大にするためだ。 ここで提案されている方法も伝統的なブレストとは異なったものです。 ここでもう一つ引用します。先日紫綬褒章を受賞した佐藤雅彦氏のインタビューで、私の世代だと佐藤氏はすごいCMを作る人、というイメージなのですが最近では「ピタゴラスイッチ生みの親」と認識されているかもしれません。 でもジャンプっていうのは非常に難しくて、どこで見つけるかっていう質問だったんですけど、それはすごく難しくて、いろんなところに隠れているんですよ。 僕は「うまく待つ」って言っているんですけど、そういうものを見出す自分でいるように、うまく待っている。見過ごさないように。当たり前だと思っていることが実は当たり前じゃない、ということがとってもあるんですよね。 それと、これは鍛錬なのかもしれないですけど、いろんな場合の数、無数の場合の数を頭の中でやる訓練というか。全部「この場合、この場合、この場合……」全部「つまんない、つまんない、つまんない……」って頭の中でガシガシやっているうちに、セレンディピティというんですかね、たまたま何かのものが見えたりしたときに、それがガーンと来るジャンプの映像だったりしますね。 だからやっぱり「うまく待つ」ということと、「ものすごく追求する」ということだと思いますね。 引用元: 新しいものは"つくり方"から生まれる--「ピタゴラスイッチ」生みの親・佐藤雅彦氏インタビュー | ログミー[o_O] ここで佐藤氏が強調している「うまく待つ」と「ものすごく追求する」は「質より量」といったブレーンストーミングの原則とは相反している。会議室で決められた時間内にアイディアを出し合うのではなく、個人の頭の中で膨大な組み合わせ、評価サイクルを回すことを会議中でなくても延々と続ける。そうしていると思わぬときにアイディアがやってくる。会社から帰ろうと電車に乗ろうとした瞬間「おわっ」とアイディアが閃いた経験を持つのは私だけではないと信じたい。 あるいは私は「新しいアイディアといってもいろいろ程度がある」事実を無視した意見を書いているのかもしれません。仮にそうだとしても 「アイディア出し会議をしよう!さあ、ブレストだ」 と直結してしまうのは見直すべきではないかと最近考え始めています。
こんにちは、上津原です。 最近はpepperを触っています。少しずつpepperのアプリケーションを開発するにあたって気づいた点などを紹介していこうと思います。 pepperとは? pepperは、ソフトバンクロボティクスから出ているロボットです。TVCMなどで見たことがある人も多いと思います。 pepperはChoregraphという統合環境を使ってアプリケーションの開発ができます。Choregraph内ではpythonを使ってより詳細なロジックの作成ができます。 pepperにおけるDialogとは? Dialogと言うのは、pepperとの会話のやりとりを作成する部分です。 「こんにちは」と声をかけられたらpepperは何と返すか?などを記述するものです。 詳しいやり方は こちらのページ を見てもらうとわかりやすいと思います。 注意するべき点って? コレは自分がハマったことなのですが Dialogが一番下まで完了すれば勝手に次の処理に進むと思っていたが、そうではないということ。 例えば、「はい」「いいえ」でそれぞれ違う回答をさせたい場合は u:(はい) そうですよね〜 u:(いいえ) まじですか というふうに書くわけですが、コレでは この受け答えをループしてしまうだけ になってしまいます。 これらを次のアクションへ繋げたい場合は、後ろにoutputの名前を記述し、1を代入します。 (ex:onStoppedを動かしたい場合) u:(はい) そうですよね〜 $onStopped=1 u:(いいえ) まじですか $onStopped=1 こうすることで、次の処理へつなぐことが出来ます。 任意でoutputを作成した場合は、同じようにその名前を書いてやればOKです。 ここでもう一つ注意なのですが、onStoppedを使わなかった場合、Dialogの聞き取りモードが継続して動き続けてしまう状態に陥ります。 そうなると、他の処理中に音声を拾ってしまい動作がおかしくなってしまうので、そういった場合は聞き取り後にonStopにもラインをつなげておくと安心です。 こんなかんじ pepperは意外と自分でいろんなことをしてくれない。 ロボットなんだから結構気が利いて、色々といい感じにやってくれるんだろうな〜とか最初思ってたんですが、全くそんなことはなく、きっちりこっちがロジックを書いてあげないと訳の分からない動きをしたりします。 ロボットだということで妙な期待を寄せていると、ロジック周りでいろんな落とし穴があるので色々と気をつけていきたいですね。
こんにちは。クリエイターの日運営委員の松尾です。第3四半期に実施してから年も明けてしまいましたが、今回も『 クリエイターの日 』について紹介します。 クリエイターの日制度 改めておさらいすると、ネクストでは「既存サービス・技術の枠組みを飛び越えた自由な発想からイノベーションの創造」と「各メンバーの興味あるサービス・技術へのチャレンジを通しての個人の成長とネクストの創出力向上」を目的として、四半期の最大7日間を研究・開発にあてることができます。 毎四半期の最後には各チームの成果報告会を行いますが、今回は趣向を変えて「デモセッション with ビアバッシュ」というかたちで実施しました。 デモセッションの風景 デモセッションでは、決められた時間の中で各チームが同時にシステムのデモンストレーションを行います。今回はクリエイターの日に活動した5チームと、有志として参加した1チームの計6チームが参加しました。 特に注目度が高かったのは、AndroidWearのデモを行っていたチーム。実装方法やデザインのこだわりなど、多くの質問が飛び交っていました。 HOMES(ホームズ)-住まい探し-賃貸・不動産賃貸検索 - Google Play の Android アプリ 参考: スマートウォッチで内覧時のチェックポイントを確認 こちらはSwiftで実装したアプリで社内システムの改善を目指すチーム。クリエイターの日を利用して勉強、実装をしたそうです。 参考: 手元のスマホで来客の受付ができるアプリ ソフトだけではなく、ハードを扱うチームもいます。こちらでは脳波を入力として、PCなどの操作をしてました。 こちらはSiriとIRKitを利用して家電の遠隔操作を実現したもの。しゃべるだけで家電が操作できます。 発表者だけではなく、聴講者としても多くの社員が参加しました。職種を問わず、最新技術に興味を示す社員が多数です。 ビアバッシュも兼ねているので、飲食物も準備。 今回は以前までの報告会とは違い、発表者と聴講者が話しやすい雰囲気を作ることに注力しました。発表と質疑応答のような形式に比べて、建設的な議論が盛り上がっていたようです。 結果発表 聴講者による投票で決定した優勝チームは「泡(Android Wear Appの頭文字らしい)」チーム。 本家Android Appのウェアラブルデバイス対応を業界初を目指して提案、実装したアプリです。まだまだこれからのデバイスですので、今後の発展も期待されます。 また、弊社役員からの特別賞には、有志として参加した新卒1年目の社員を選出。 IoTをテーマに出展していた彼には、その感性をさらに磨くべく、新しいガジェットが贈られたようです。 今後もネクストのものづくりを活性化し、発信して参ります。次回の記事にもご期待ください。
池田です。 今回は、iPhoneアプリの視覚障がい者向けユーザビリティ、アプリを使いやすくする3つのポイントについて書きたいと思います。 ユーザビリティのお話をする前に、視覚障がい者がどうやってiPhoneを使われているか、について少し触れます。 視覚障がい者の多くは、iOS付属のスクリーンリーダー「VoiceOver」を活用し、iPhoneの利用をされています。 初めて「スクリーンリーダー」という言葉を耳にした方もおられるかもしれませんので、少し解説しますと、スクリーンリーダーは、画面上の内容を、音声にして読み上げてくれるソフトウェアです。 画面上の項目にカーソルが当たり、そのカーソルが当たっている項目の内容を音声で読み上げてくれます。 カーソルが当たってるのがテキストなら、そのテキストの内容を。 リンクなら、リンクの文言と、それが「リンク」であるという情報を読み上げます。 視覚障がい者の多くはこのスクリーンリーダー、iPhoneではVoiceOverを活用して、音声で画面の情報を把握し、使われています。 それでは、VoiceOver利用時のユーザビリティ、アプリが使いやすくなる大切なポイントについて、書いていきたいと思います。 「HOME'Sアクセシビリティ対応版」で気をつけている大切なポイントは、大きく分けて3つです。 VoiceOverに合わせた操作性の考慮 画面操作時の迷いをできるだけ軽減する 必要な情報を漏れなく音声で伝える この3つについて、解説していきます。 VoiceOverに合わせた操作性の考慮 VoiceOverが有効の環境下では、無効の場合と大きく操作が異なってきます。 VoiceOver有効時には基本的な操作として、カーソルの移動と、項目の選択があります。 カーソルの移動は、画面上を上下左右にスワイプする、または、画面上の項目をタッチすることで行います。 項目の選択は、画面上をダブルタップすることで行います。 この操作性を考慮し、画面上の項目の配置、項目の読み上げ設定などをすることが大切です。 「HOME'Sアクセシビリティ対応版」の画面画像を示しながら、ご説明していきたいと思います。 VoiceOver利用環境下では、画像上の番号で示すように、まず画面の左上の要素が選択、そこから左から右、右端まで行ったら一つ下の行の左端の要素が選択。 のような動きで、カーソルを移動していきます。 つまり、左上から順々に一つ一つの要素の内容を音声で聞き、理解しながら画面操作を進めていきます。 こういった操作を考慮し、この画面では、画面の機能として配置されている「検索トップに戻る」ボタンの配置を画面上部にしています。 なぜ上部かと言いますと、画面上部にボタンを配置することで、画面の内容に入る前にボタンにカーソルが合うため、画面内にどんな機能があるか、事前に把握することができるためです。 また、画面上部にある方が、VoiceOver環境下の特殊な操作(二本指で上にスワイプすると最初の項目にフォーカスが合う)を用いることでアクセスしやすくなるという利点もあります。 画面操作時の迷いをできるだけ軽減する VoiceOver利用時の操作は、画面上を触ることにより触った位置にある項目が選択されることもあり、画面上の操作をしている際、ちょっと触れた位置にカーソルが行ってしまうなど、意図しない動作が起こる場合があります。 意図しない動作が起こると、画面上の理解に迷いが生じます。 そこで、迷いが生じないように、また、生じた場合の迷いの軽減をすることが大切です。 こちらの画面では、画面右上に画面の使い方を調べるボタンを設置しています。 こういったボタンを設置することで、今何をする画面にいるんだ?どんな操作をすればいいんだ? といった迷いが生じた際、ここを見ることで少しでも迷いを軽減できるようになります。 必要な情報を漏れなく音声で伝える VoiceOver利用時には、画面上の音声読み上げが重要となってきます。 まずは画面上の各要素をテキスト情報で伝える必要がありますが、それだけではなく、「画面上の状態」を伝えることも大切です。 この画面は、データを取得中の読み込み画面です。 開かれたタイミングで読み込みが行われ、その後、読み込みが完了すると内容が表示されます。 画面の状態の変化は、ユーザの操作によって行われる訳ではなく、自動で行われます。 こうした自動的な画面の変化を音声で伝えていくことも大切です。 「HOME'Sアクセシビリティ対応版」では読み込みが開始したタイミング、読み込みが完了したタイミングで、音声で「読み込み中」「読み込み完了」と状況を伝えるようにしています。 このように、VoiceOverの操作性、ユーザの迷いの軽減、適切な音声フィードバックを行っていくとアプリは視覚障がいを持たれた方にとってとても使いやすいものとなります。 VoiceOverは視覚障がい者をサポートする素晴らしい機能ですし、VoiceOver利用を考慮したアプリが増えていくことで、視覚障がいを持たれた方の生活もどんどん便利になっていくと思います。 今回は、VoiceOverの詳細、実際の開発など、詳しい部分をお伝えできていませんが、今後より詳しい部分についてもお伝えしていこうと思います。
こんにちは、上津原です。 先日Pepperの購入者、または購入予定者が参加できるというPepper Pioneer Club Meetupに参加してきました。 会場は、FreakOutさんのイベントスペースでした。 私はエンジニアというところで、エンジニア目線での今回のイベントで感じたことをお伝えしたいと思います。 乾杯は主役のPepperが まず最初に、恒例らしい(?)Pepperによる乾杯の音頭で始まりました。ちなみに前回はPepperによる乾杯は失敗したとのことで、今回はうまくいき、乾杯の後に拍手がわきあがりました。乾杯ができただけで拍手を受けられるPepper。しかし妙に新鮮でした。 展示されていたPepperや話を聞いて感じた事 Pepperの基本としてはもちろん「会話」が中心になります。なので、会話をしながら記念撮影をしたり、ラジコンのように操縦するスマホアプリが展示されていたり、関西弁でしゃべるPepperなどがありました。 全体を眺めながら感じた点は、まだ柔軟な会話に対応できるPepperアプリケーションを作るノウハウはそりゃあるわけないよねー、という感じでした。「はい」「いいえ」を基本にした会話だったり、数字を選ばせたり、胸元のタブレットで操作したりというかんじで。 いわゆるソフトバンクの発表会で見たようなスムーズな会話を成り立たせるというよりは、Pepper側から選択肢を人間に用意をしてあげて、思った通りのフローを踏ませるといったものが基本だし、ロジックを作る以上はそうなってしまうのはしょうがないのかなと感じます。 CMなどのおかげで、Pepper君は話しかければ大体なんか返事してくれると思っている人が大多数なので、結構その辺で開発者とユーザの間でギャップが起きたりするのでその辺をどう埋めるかというのも課題になりそうです。 まあ、Pepperくんはかわいいので、できなくても大概許してもらえちゃうんですけどね笑 次は開発者イベントがあるといいなあ 今回は「こんな風に使ってます」「作ってみました」というものが多かったので、次開催あたりではもっと開発側に突っ込んだものなどの話があるとうれしいですね。 ロボットを喋らせて、人と会話をするというのは今までソフトウェア開発をしてきてやることはなかった身としては、どうしても普通のソフトウェアに考えが偏りがちで「どうやったら話したくなるか?」「スムーズに会話が進むか?」「違和感のない生きてる感を出せるか?」などいろんなところでつまづく場面があるので、その辺をみんなで共有しあえればもっといいPepper開発につながるんじゃないかなーと思います。 しかし、MeetUpはご飯もおいしく、会場も広く非常に楽しめました。 今後の展開が楽しみです。
こんにちはAndroid開発グループ橋本です。 今回はAndroidStudioで使うlintについて調査する機会があったので内容を記事にします。(lint自体の解説は省略します。) まずは実行をしてみる。 Androidのlintの実行について調べてみると、Android/sdk/tools/の下にあるlintが使用できるようです。 参考: http://developer.android.com/intl/ja/tools/help/lint.html この方法だといちからlintのオプション設定を行わなければいけないため、とても手軽に使えるとは言い難いものです。ではどうしたらいいのか?そもそも開発はAndroid Studioを使う事を前提としていたのでそちらで実行したいところです。 Android Studioから実行 AndroidStudioから実行する場合、実はとても簡単で、メニューからAnalyze→Inspection Scopeで実行できました。 gradleをコマンドラインから実行 Android Studioで作成したprojectフォルダの下にあるgradlewを使用して、以下のコマンドでlintを実行できます。 ./gradlew (モジュール名):lint こちらの方法で実行した場合デフォルトではhtmlとxmlで出力され、実行後に成功していれば出力パスが表示されます。 lintの設定をする。 設定と実行方法はAndroid StudioのGUIに任せるか、手動で行うかのパターンがありますが。GUI上からの設定方法は他文献でいくつかあるようなので、ここでは手動設定の方法を記述します。 build.gradleの設定 作成したprojectファイルにあるbuild.gradleにlintOptionsを追記し必要な項目のオプションを必要に応じて追加する形です。 以下公式から抜粋。 android { lintOptions { // set to true to turn off analysis progress reporting by lint quiet true // if true, stop the gradle build if errors are found abortOnError false // if true, only report errors ignoreWarnings true // if true, emit full/absolute paths to files with errors (true by default) //absolutePaths true // if true, check all issues, including those that are off by default checkAllWarnings true // if true, treat all warnings as errors warningsAsErrors true // turn off checking the given issue id's disable 'TypographyFractions','TypographyQuotes' // turn on the given issue id's enable 'RtlHardcoded','RtlCompat', 'RtlEnabled' // check *only* the given issue id's check 'NewApi', 'InlinedApi' // if true, don't include source code lines in the error output noLines true // if true, show all locations for an error, do not truncate lists, etc. showAll true // Fallback lint configuration (default severities, etc.) lintConfig file("default-lint.xml") // if true, generate a text report of issues (false by default) textReport true // location to write the output; can be a file or 'stdout' textOutput 'stdout' // if true, generate an XML report for use by for example Jenkins xmlReport false // file to write report to (if not specified, defaults to lint-results.xml) xmlOutput file("lint-report.xml") // if true, generate an HTML report (with issue explanations, sourcecode, etc) htmlReport true // optional path to report (default will be lint-results.html in the builddir) htmlOutput file("lint-report.html") // set to true to have all release builds run lint on issues with severity=fatal // and abort the build (controlled by abortOnError above) if fatal issues are found checkReleaseBuilds true // Set the severity of the given issues to fatal (which means they will be // checked during release builds (even if the lint target is not included) fatal 'NewApi', 'InlineApi' // Set the severity of the given issues to error error 'Wakelock', 'TextViewEdits' // Set the severity of the given issues to warning warning 'ResourceAsColor' // Set the severity of the given issues to ignore (same as disabling the check) ignore 'TypographyQuotes' } } 一部よく使うであろうオプションについて解説します。 abortOnError falseを設定することで、build中にlintのエラーが出てもbuild自体に影響を及ぼさない(途中で停止しない)設定に出来ます。コンパイルが通るはずのソースコードをbuild中に止められてしまう可能性があるのでfalseにする事が殆どになると思います。 disable issue IDを設定することで、設定したissue IDを無視できます。実行するモジュールによってはlintが過度の検出をしてしまう為、明示的に設定しlintの検知から除外します。 lintConfig lintの設定ファイルを指定できます。パス設定はgradlewのあるフォルダと同じところからみた相対パスになります。 lintの設定ファイルの記述 基本的には.gradleで設定できる内容と同じ内容が設定できますが、lintConfigで設定したフィアルでは詳細な設定も記述できます。 参考: http://tools.android.com/tips/lint/suppressing-lint-warnings 記述方法:ファイルの個別除外とフォルダ以下全て除外の例です。 <?xml version="1.0" encoding="UTF-8"?> <lint> <issue id="all"> ① <ignore path="src/test/androidtest.java" /> ② <ignore path="src/test/**/*" /> ③ </issue> </lint> issue idを設定します。"all"を設定することで全issue idを対象に出来ます。 ignoreで除外とし、optionのpathで対象ファイルの条件を記述します。(絶対パスの記述例) 2.の相対パスの記述例 調査してみて 今回lintの調査をしてみて、まだまだ調べ切れていない感じがします。 実際に調べ設定してみて設定方法もGUIからがいいのか手動設定がいいのかの判断まではついていませんが、lintの設定だけ考えると個人的には手動がわかりやすかった印象です。 ただ、実際に運用するにあたっては、lintに検知と対応する事を考えるとAndroid StudioのGUI上から設定し修正・運用する方が良さそうでした。 おまけ Android/sdk/toolsのlintコマンドで、オプションに--listをつけ実行する事で検知できるissue idが全て見れます。予想はしていましたが種類が多いのでlint実行時に検知されたissue idの内容を調べ随時対応していくのが効率的だと思いました。
こんにちは。Android 衛藤です。 12/21(日)に Android Bazaar and Conference 2014 Winter に参加してきましたので、今回はその報告を書かせて頂きます。 私が見た講演は下記の通りです。 [開会宣言] Android Link to Next Generation! ~次なる世界を目指して~ [基調講演] 「Project Araと新しいものづくりエコシステム」 [招待講演] Android 5.0とAndroid Wearで広がる最新アプリ開発技法 [招待講演] Microsoft <3 Android [招待講演] ウェアラブルコンピューティングとAndroidの未来 loT時代における開発手法の提案~スマホの次を見据えて~ Material Designの勘所 日本から海外、そして海外から日本、アプリビジネスの海外展開の今後。 歴史は繰り返す+トレンド 裏読みで2015年のモバイルを予測する これらの中で、いくつかピックアップして内容を記したいと思います。 講演内容 Android 5.0とAndroid Wearで広がる最新アプリ開発技法 マテリアルデザイン マテリアルデザインとは異なるデバイス間で一貫した表現をするためのデザイン思想 elevation / ripple / interpolator等の効果により自然に見せる ToolBarを使用する(ActionBarよりも柔軟なカスタマイズが可能) Android Wear 新しくなったNotification。通知をスタックできたりする Watch Face API が公開された Wearアプリを公開する際はGoogle Playのアプリの [価格と販売 / 配布地域] ページで、Google Play の Android Wear コレクションに追加されるように設定することができる Notificationを出しすぎるとアンインストールされるので、本当に必要なときにのみ出すようにする これからアプリを開発するにあたって オレオレUIではなくAndroidらしいものを作る(NavigationDrawerとかActionBar/ToolBarなど) Webのコピーのようなアプリは必要ない サクサク動き、見た目が美しく、電池持ちが良いアプリを作る Android5.0についてなので、当然ながらマテリアルデザインやWearについての話題でした。 この後のマテリアルデザイン講演で詳しく聞いてきたので、詳細はそちらで記載したいと思います。 AndroidらしいUIというところも重要で、やろうと思えばいくらでもUIはカスタマイズ出来ますが、 凝りすぎると返って使いづらいものになる場合もあるので、ユーザが使い慣れたUIがよいですね。 Microsoft <3 Android タイトルの"<3"ですが、ハートを表しているようです。 内容としては Microsoftでは常に1〜3年先のものを開発している(エンジニアの部門) Researchの部門で3年以上先に出るようなものを開発している 開発体制の変更 いままではWindowsを3年単位で開発・リリースしてきたが、アジャイル開発に変えて日〜月単位での開発・リリースをするようにした Visual Studio Communityを発表。C#/C++でAndroid開発をすることができる エミュレータで加速度をエミュレート、バッテリー残量を意図的に減らしたりする事が可能 エミュレータで加速度やバッテリーをいじったりするのはgenymotionのプレミアム会員で出来るみたいですが、 無料で使えるのは魅力的かと思います。 ウェアラブルコンピューティングとAndroidの未来 神戸大学大学院 塚本昌彦教授による講演で、非常に興味深かったです。 Singularity(シンギュラリティ)についての話が冒頭に出てきており、このSingularityは日本語に訳すと特異点というらしいです。 宇宙に関する話でよく出てくるようですがICTの分野だと「技術的特異点」などと訳されます。 Singularityはすぐ近くに来る、と言われていますが、具体的には2045年問題とも呼ばれているようですね。 人工知能が人間の知能を超える時がくる・・・SFの世界のような話で少し怖いですがどうなるのでしょう。 ウェアラブルの未来はというと、 ウェアラブルは単なるバズワードでは終わらない。特に春以降大きく変化していくと思われる SmartWatch3ではWifiもハード的に搭載している スマホが大きくなりすぎたため、スマホに変わる常時身に付けているデバイスになり、単独利用が増える 企業のウェアラブル参入が増加 マルチウォッチ対応してほしい(そもそも二つもWearつける人がいるのか分からない・・・) 最初はどうしても使いづらいのが特徴だが、実世界サービスやビジネス用としてのポテンシャルを膨大に持っている 今のところは通知連携やスマホの補助的ツールとしての使い方がメインかと思いますが、 今後はWear単独での利用が予想されたり、便利なツールが出てきそうですね。 これからどの程度成長してくるかは分かりませんが、HOME'Sでいち早くWear対応出来たのは良かったかな、と思っています。 Material Designの勘所 先ほど少し触れましたが、マテリアルデザインについても聞いてみました。 マテリアルデザインは、ガイドラインというよりは異なるデバイス間でも統一した体験が出来るためのデザイン思想のことです。 少しまとめると Visual Language(視覚的言語)である 紙とインクをコンピュータの世界へ当てはめる あらゆる物体がLayer構造で表現される(Shadowなど) タッチ、ジェスチャーにおいても自然な表現を(Ripple効果など) 要するに、活版印刷の時代に築き上げられた古き良きものをデジタルの世界にも導入しようという思想のようです。 マテリアルデザインを導入するにあたっての3つの原則 1. メタファー 実際の素材のメタファーである 素材との関係を考える 紙やボタンが重なった時の影など 2. Bold, Graphic&Intentional 大胆に活き活きと、意図的に 大きめのボタン等にすることで、ユーザアクションを強調する 3. Motionで意味を提供 モーションに意味を持たせることで、ユーザ体験の継続性を持たせる また、マテリアルデザインを考える上での3つのキーワードは 1. 環境 Z軸を考える フラットデザインが主流になっているが、配置が分かりづらい そのため、光源や環境光などを取り入れ、情報同士の関係性、分かりやすさを強調する 2. 素材の属性 物質としての高さを考える 紙であれば実質的にフラットに見えるが物質として高さが0のものは存在しない 3. 3D空間でのObject配置 http://www.google.com/design/spec/what-is-material/objects-in-3d-space.html 高さが2dpの物体があり、その上に高さ6dpの物体があるなら全体で8dpの高さとなる ActionBar / Floating Action Button / Card UI全てに3D空間として配置する ここに記載したことは、全て Googleのデザインガイドライン に入っています。 とりあえず全部読んだ方が良さそうですね。(私もこれからですが・・・) 最近マテリアルデザインを導入したアプリが増えているようなので、HOME'Sでも導入してみたいです。 歴史は繰り返す+トレンド 裏読みで2015年のモバイルを予測する 携帯コレクター小暮さん&アスキーの遠藤さんによるトークセッション。 タイトル通り、これまでの変遷をもとに今後のトレンドを予測する話でした。 歴史は繰り返す これまでを見る限り、5〜10年サイクルで課金体系が変わってきている 1989年:モバイルインターネットの試行錯誤の時期 ダイヤルQ2による課金が主流 1999年:iモードの出現により課金体系がほぼ確率 2008年:iPhone, Androidの出現によりアプリ内課金が主流に これからはIoTの時代になり、いろんなモノがつながるようになってくる スマホは安定期に入ったのか? これまでもいろんな異形な端末(セッションでは変態端末と言われてました・・・)が出てはすぐに消えていった スマホも実は異形な端末の部類だが、爆発的に普及した異例かもしれない ウェアラブルの今後 ウェアラブル端末にsimが差せ、それだけで通話できるようになる。となるとガラケーの再来では? 心拍数などの身体計測系の機能はこれから欠かせなくなる。ヘルスケア機能が充実し、医療に役立つようになる。 テレビについてはどうなるのか? 現状と変わらず? または最近出てきているスマートテレビにシフト? それともただ表示するだけのモニターとなり、テレビそのものが衰退? テレビなど家電系の今後は気になりますね。 韓国でAndroid冷蔵庫が前に出たらしいですが、1年でなくなったらしいです。結構便利そうですが・・・ 話を聞いていると確かに歴史が繰り返されていると言える部分があると感じました。 これからどうなるのかは誰にも分かりませんが、このような視点での予測も面白いですね。 バザール バザールにも多数出店されていました。 サーバサイドのサービス紹介やMicrosoftのVisual Studioの紹介、Googleの秘密本配布など多数ありましたが、 その中で一点気になったのが、スマホアプリ開発技術検定試験というものがありました。 https://spkentei.jp 受講費用無料でiOS, Android, html5 CSS3などに対応しているとのことです。 学校等でも採用されているらしく、力試し受けてみてもいいかもしれません。 また会社の開発チームで受けることで技術力計測/向上にも使えそうです。 全体的に 初めてABCに参加したのですが、インターネットでの最新ニュースだけでは仕入れられないような話も聞けて、参加した価値があったと思います。 今回は、Android5.0およびAndroid Wearが発表された後に開催されただけあって、 内容もそれに関することが多かったようですね。 Android HOME'Sでも先日 Android Wear対応版 をリリースしましたが、 ウェアラブルが盛り上がって行っているようで、安心しています。 今後も最先端の技術を取り入れつつ、使い勝手の良いアプリを作っていければと思います。 また、最後の懇談会では多数の方とお名刺交換させて頂き、ありがとうございました。 じゃんけん大会でもみごと景品ゲットできたので、大満足です。 次回のABCは、2015/7/20(月・祝) 川崎振興会館にて開催とのことなので、 これからも参加していきたいと思います。
Apple原理主義者であり、Paper原理主義者でもある大坪です。 FacebookのPaperを起動してまず気がつくのがトップ画面のアニメーションでしょう。↓のビデオで親指を下から上に動かすとそれに合わせて、長方形型の写真やら文章がが「ぶわっ」と大きくなるところです。 このように特徴的なUIをもったアプリの発表から、それを再現するコードの公開までの速さには驚かされます。CocoaControlsには同じアニメーションを再現しようとしているプログラムが二つ公開されています。 HAPaperViewController MMPaper 両方とも希望をあたえてくれると共に、Facebook Paperまでの距離の遠さを思い知らされることにもなる。なぜそう考えるのか、そして私の試みがどの程度進んだのかについて書きます。 最近発表されたMMPaperの方を実際に動かしてみましょう。Facebook paperに比べていくつかの部分が気になります。 ズームするときの動きがスムーズではない(To doにもあげられていますが) 指を離した後、自動的にズームしている間、およびそのあと少しの間はジェスチャを受け付けない。つまりジェスチャが時々空振りする。 (他にもありますが、ひとまずここまで) これらの問題を できるだけ 解消することを目指しました。 ーーー コードは GitHub に置きました。実行する前に"Podfile"のあるディレクトリで"pods install"とするのを忘れないでください。 アプリを起動するとこんな風に動きます 起動すると二つボタンが並んだ画面がでてきます。"Responsive"が今回あれこれ工夫した つもり のバージョン、"Standard"が「普通に」実装したバージョンです。"Responsive"のほうが何かとスムーズに動きますよね。ね?ね?(血走った目で懇願) このデモを見てもなお読み続けてくれる心の広い方がいると信じて細かい説明をします。 ーーー Paperトップ画面の動きをみると 「これはUICollectionViewを使ったCustom Transitionだ」 と思う。さて、どのような方式で実装するか?方法は私が思いつくところでは二つあり Layout-to-layout transition(例: taktamur/PAMTransitionSample ) UICollectionViewController-to-UICollectionViewController transition(例: timarnold/UICollectionView-Transition-Demo ) ちなみに先ほど挙げたMMPaperは後者の方式で実装されています。厳密に比較したわけではないのですが、普通に実装すると UICollectionViewController-to-UICollectionViewControllerのほうがスムーズに動くようです。 私も最初UICollectionViewController-to-UICollectionViewControllerで実装したのですが、後述する理由によりLayout-to-layout を使っています。とはいえ普通に実装したのでは"Standard"を選択した時のような動きにしかならない。ではどうするか。 デモプログラムの"Standard"と"Responsive"の違いは二つで "Standard"ではイメージ表示にUIImageViewを、"Responsive"ではASImageNode(in AsyncDisplayKit )を使っている。 UIPanGestureRecognizerがUIGestureRecognizerState.Endedを返してきた後(つまりユーザがスワイプジェスチャを終了した後)"Standard"ではfinishInteractiveTransition()を呼んでいる。"Responsive"ではFacebook Popを使って終了位置までのアニメーションを制御し、その間に新たにタッチが始まった場合にはアニメーションを中断するようにしている。 他の処理は全て同一。ではどのような狙いでこのような「変更」を加えたか。 一点目、レスポンスをあげるため、ジェスチャに対応したセルの変形処理が少しでも軽くなるように、ASImageNodeを用いました。しかし正直に言えば今回のような使い方でどれだけ効果があるのかは今ひとつわかりません。触っていると、確かに少しレスポンスが良いような気がしますが、製作者の贔屓目からもしれません。 ASyncDisplayKitのページ に単にUIImageViewをASImageNodeに置き換えただけでも一部の処理がバックグラウンドで処理されるため効果がある、と記載されていますが... 二点目。"Standard"ではUIPanGestureRecognizerのコールバック関数で、UIGestureRecognizerのstateがUIGestureRecognizerState.Endedだった時にこんな処理を行っています。 if success {  self.collectionView?.finishInteractiveTransition()  self.toBeExpandedFlag = !self.toBeExpandedFlag } else{  self.collectionView?.cancelInteractiveTransition() } 遷移を完了させたければfinishInteractiveTransition()を呼び、キャンセルならばcancelInteractiveTransition()を呼ぶ。コードは簡単明瞭ですがここに問題がある。前掲のサンプルを解説しているページから引用します。 ここで注意するのは、ジェスチャーの終了からアニメーションの完了までに隙間時間(A)がある事です。progressが0.6等の半端な場合にfinishInteractiveTransitionやcancelInteractiveTransitionを呼び出すと、progress1.0になるまでアニメーションして(体感1秒程度かかるときがある)、その後にcompletionブロックが呼び出されます。 この隙間時間に次のtransitionを開始しようとするとクラッシュします。 引用元: UICollectionViewをジェスチャーで拡大縮小したい(iOS7〜) - Qiita このサンプルに習い、クラッシュを避けるため"Standard"ではジェスチャーの終了後UIGestureRecognizerを停止しています。こうすると確かにクラッシュしないのですが、その間ユーザの操作を受け付けることができない。そして時としてこのfinishInteractiveTransition()を呼んだことによるアニメーションは見かけより長くかかる。反応しない画面上をひたすらスワイプするのはどう考えても楽しくない。 というわけで"Responsive"では、ジェスチャーを終了した後のアニメーションを自前で実装しています。(参考にしたのは このサイト ) UIKitDynamicsを使っても いいとは思うのですが、ここは同じくFacebookから公開されているPopを使いました。 *1 今のプログラムは指を離してから拡大または縮小が確定するまでのわずかな時間に再度スワイプを始めた場合、進行中のアニメーションをキャンセルし、ユーザのタッチに反応します。 (わずかな例外を除いて) 正直に書きますが、まだ「不感帯」が残っておりswipeが空振りになることがある。しかし"Standard"より「マシ」になっている、というのはある程度の自信を持って言えます。いや、素直にUICollectionViewController-to-UICollectionViewControllerで実装したの(例えばMMPaper)に比べてどうなんだ、と問われると下を向いてしまいますが.. ーーー Facebook paperチームのエンジニアはプレゼンでこう述べています。 最初にiPhoneに触った時、まるで魔法のように感じた。Appleは表示するコンテンツとユーザの間にあるバリアを取り除き、ユーザが直接コンテンツを操作することを可能にしたからだ。しかしユーザのジェスチャが認識されなかったり、アニメーションが滑らかでないとそうした魔法は消え去ってしまう。 そうして作られたPaperではすべての動きが軽く、そして連続的に動く。それは初めてIPhoneの慣性スクロールに触った時と同じ驚きを与えてくれる。 今回の試みには「不感帯」の他にも大きな問題が存在しています。Paperでは縦方向の拡大ジェスチャと横方向のスクロールジェスチャを両方同時に行うことができる。今のところこれを実現させる方法がわかりません。未だ撲滅できない「不感帯」があることも考えると、ゴールははるか彼方に霞んでいるとしか思えない。 そもそもFacebookが公開したライブラリを使いながら、依然として存在しているこの距離は一体どういうことか、という根源的な問題からは目をそらし、もう少ししつこく 「魔法」 の再現に努力したいと思っています。 *1 : ちなみにUICollectionViewController-to-UICollectionViewControllerで実装すると、指を離した後のアニメーション時にUIGestureRecognizerがそもそも反応してくれません。クラッシュしないのはいいのですが、工夫のしようもない。というわけでLayout-to-layout を使っています。
大坪と申します。先日面白い記事を見つけたので紹介しつつ、つらつらと。 記事の題名は "Design Courage" 。さて、DesignといえばApple。(異論は認めません。私は視野の狭いApple原理主義者なのです)Appleが新しい製品を出すたび(あるいは出さないたび)聞こえてくる "Steve JobsがいなくなったからAppleはもうだめだ” "Steve Jobsが生きていればこんな製品は出さなかった” という声の多さには驚きます。 *1 さて、そうした人たちが言うようにSteve Jobsの存在自体がAppleを他の企業から際立たせていたものなのか?この記事の筆者は違う、と主張します。ではそれは何なのか。 The difference between Apple and many other companies comes down to one word: courage. Everyone thinks they have great ideas. Everyone thinks they’re smart. Everyone thinks they have great designers and engineers. So why is there so much difference between the best and the average? Courage. Not lip service courage, actual courage. It’s rare in software. 引用元: Design Courage — Medium 適当な訳:Appleと他の数多くの企業との違いは一語で表すことができる。「勇気」だ。誰もが自分たちはすごいアイディアを持っていると思っている。誰もが自分たちは賢いと思っている。誰もが自社にはすごいエンジニアとデザイナーがいると思っている。では「最高」と「凡庸」の差異はなんなのか。それは「勇気」だ。ただ口で言っているのではなく本当の「勇気」これはソフトウェア業界では稀なものだ。 では具体的にそれはどのような「行為」に現れてくるのか。例を考えました 未だにApple Watchの発売日は明らかにされません。例えば発売日を決めるにあたり、Appleはこんな考え方もできたはずです。 「他の企業がスマートウォッチを発売する前に売り出し、市場シェアをとってしまおう」 「今年のホリデーシーズンを逃すことはありえない。必ずその前に出荷するべきだ」 しかし彼らはそうしなかった。発売時期を遅らせても完成度を高めることを選択したのです *2 。企業に勤めている人であれば、↑のような声に逆らうことがどれだけ勇気が必要なことが想像できるのではないでしょうか。 とかなんとか考えていて別の記事を思い出しました。 Every aspect of the company's production cycle, from conception to ship date, is calculated. But--and this is a big "but"--what makes Apple different is that it is a company that is willing to move those deadlines. If a product in development isn't ready to be released, the deadline is pushed back. If an idea isn't perfect, or isn't considered truly magical and delightful internally, it's held back, revised, and the product given an entirely new launch date. 引用元: The Biggest Lesson I Learned as an Apple Designer | Inc.com 適当な訳:(Appleの)全ての製品開発サイクル-コンセプト作成から出荷まで-は計算されて設定される。しかし-この「しかし」が大きいのだが-Appleが他の企業と違うのは、そうして設定されたデッドラインを進んで変更することにある。開発中の製品がリリースされるだけの完成度になければ、期限は遅らされる。アイディアが完璧ではなかったり、真に魔法のようだったり楽しくないと考えられれば期限は伸ばされ、スケジュールは改定され、製品の発売日は全く新しく設定される。 なるほどなるほど。話しとしては面白いねえ。でも「期限を決めずに納得のいくまでがんばって!」などといっても怠けて結局何もでてこないのではないか? こうした「当然の疑問」に対して本記事はこう述べます。 That doesn’t mean your design team is always right, or deserves unchecked power. A company needs balance across all disciplines. But the reality of software development today is we put design on a pedestal right up until the moment it threatens to affect our deadline. Then design turns into an unaffordable and unreasonable luxury 引用元: Design Courage — Medium 適ry)訳:これはデザインチームがいつも正しい、とか誰もチェックできないくらいの力を持つべきだ、という意味ではない。企業は全ての面に渡ってバランスを保たなければならない。しかし昨今のソフトウェア開発現場では、デザインをありがたく奉っておき、期限が迫ってきた途端「デザインは理不尽で度を越した贅沢」扱いする。   いやいや、ビジネスなんだから期限が第一。というわけで例えば、プロダクトの開発に関して 「設定したリリース日より1ヶ月前倒しで完成した!グリフィンドールに50点 *3 」 とか 「面白いプロダクトだけど、リリースが2週間おくれちゃったね。スリザリンに-30点」 といったような評価があっても驚きません。こうした「期日を守ったか守れなかったか」を元に判断することは確かに「わかりやすい」し「定量的」でもある。しかしそうした評価方法で「真に素晴らしい製品」を作りあげることができるのか? 「リリースを2週間遅らせたことによる完成度の向上と、ビジネスへのインパクトを秤にかける」 のは難しいし、そのように考えることは確かに「勇気が要る」ことだなと考えたりします。 そんなのは自分でリリースデートを決められる立場にいるからできることだよ、という議論もあるでしょう *4 。 しかしながら、私見ではここで言われている「勇気」は開発における期限に限定されるものではない。 話が膨らみすぎたので、身の丈に戻しましょう。先日iPhone版「 へやくる! 」をリリースしました。 物件一覧画面を見ていただくとナビゲーションバーがないことに気がつくと思います。ここから左右にスワイプすれば条件設定画面、あるいは物件詳細画面がでてくるのですが、果たしてユーザがそれに気がついてくれるか?(初回起動時にインストラクションを出してはいるのですが) ここは社内でも議論になりました *5 。あれやこれやの検討の末現在の形でリリースしたわけですが、リリース後しばらく 「最初の画面から誰も移動できず、アプリがろくに使われないのではないか」 という悪夢に悩まされ続けたのも事実。素直にナビゲーションバーをつけておけばよかったか、あるいは画面遷移を示すボタンだけでもあったほうがよかったのか、とかあれこれ考えました。アプリの利用状況を見てそうした結果になっていないことを知り、最近ようやく安眠できるようになったというのは嘘です(最後の部分だけ)。 これは「Apple Watchのリリースを翌年春まで伸ばす」ことに比べれば、測定限界以下の小さな「勇気」です。しかし製品やサービスのデザイン/設計はこうした「勇気」の積み重ねでもある。小さなステップであっても「勇気」の持ちようによって最終的に表にでてくる製品/サービスは大きく変わってくるのかもしれない、と最近考えています。 *1 : 私のような人間からすると、そうやって自分の頭の中にSteve Jobsを住まわせておくことができる、というのはとてもすごいことだなあと思うのですが *2 : 実際にでてきた製品がひどい出来で「発売伸ばした挙句にこの出来かよ」と思う危険性の存在は無視します *3 : 最近子供がハリーポッターを読む年頃になったのです *4 : 皮肉なことですが、Appleはサプライヤーに対して、 非常に過酷なDeadlineを課す契約 をしていることが明らかになっています *5 : ちなみに私が愛するFacebook Paperはもっと大胆で、最初の画面を上から下にスワイプしない限り設定はおろか新たな投稿も行えないデザインになっています
こんにちは、リッテルラボラトリーの清田です。 11月19日(水)、20日(木)の2日間にわたって芝浦工業大学豊洲キャンパスで開催される WebDB Forum 2014 にて、リッテルラボラトリーのプロダクトの展示・発表を行います! WebDB Forumは、Webおよびデータベースに関する研究発表の場としては国内唯一の査読付き会議で、例年高いレベルの発表が多数行われます。 学生の方は1000円(聴講のみ)で参加できます ので、お近くの方はぜひお越しください。 常設展示ブースおよびポスターレセプションでは、リッテルラボラトリーが新たに開発した 部屋作りシミュレーション『GRID VRICK』 のデモを展示します。 LEGO(R)のブロックを組み替えるだけで、仮想3D空間内に自分好みの部屋を楽しみながら作れるというシステムです。 また、Oculus Riftを着用して、自分で作った部屋の中を自由に歩き回ることができます。ぜひ体験してみてください! 20日(木)午前中の技術報告セッションでは、『不動産・住宅情報サイトHOME’Sにおけるユーザーの「理解」と「支援」の技術』と題して、 2014年5月にリリースした『ホームズくんのこれからシアター』 の運用で得られた知見について発表します。 多数の方のご参加をお待ちしています!
こんにちは。 池田と申します。 本日は、部屋作りシミュレーションシステム「GRID VRICK(グリッドブリック)」についてご紹介しようと思います。 このシステムは、楽しみながら部屋作りを体験できるシミュレーションシステムです。 お部屋を住み替える際には、費用の問題であったり、検討の時間の問題であったり、いろいろな問題があり、結構ハードルが高いものだと思います。 ですが、部屋を住み替えるということは、新しい環境に身を置き、新しい気持ちを持ち、新しい生活を築いていく、とても楽しく素晴らしいことだと思います。 この「GRID VRICK(グリッドブリック)」ではその「楽しい!」という気持ちをより多くの人に感じてもらいたく、作成するに至りました。 今回ここで紹介するのは、LEGO(R)のブロックと組み合わせた体験の例をお伝えしたいと思います。 実際できることは以下です。 ブロックを配置し、間取り作成、家具の配置 ブロックを組み替えることで、リアルタイムに間取り、家具の更新 PC画面上で、部屋の壁紙、扉、窓、家具の種類を変更 「Oculus Rift」を着用し、部屋のウォークスルー体験 実際その流れを実際の利用風景を交えながら、ご紹介していきたいと思います。 間取り作成、家具の配置 ここでは、壁は赤いブロック、扉は薄緑のブロック、窓は青のブロックという設定がされており、このブロックの位置、大きさにより、3Dの部屋空間がPC上に再現されます。 こちらがブロックを配置しているところ。 そしてそれで再現された、3Dの部屋空間。 家具を配置したところ。 間取り、家具の更新 作成した間取り、家具は、ブロックの付け替えにより、リアルタイムで更新ができます。 左下の部屋の窓を増やしてみました。 PC上の画面はこんな感じ。 壁紙、扉、窓、家具の変更 PCの画面上で操作することで、壁紙、扉、窓、家具などを変更できます。 壁紙を変えてみました。 家具(ソファ)を変えてみました。 ウォークスルー体験 「Oculus Rift」を着用することで、 自分が作成した部屋に実際入り込んで、ウォークスルーするような体験をすることができます。 部屋の入口から入るところ。 作ったリビングルーム。 作ったトイレ。 以上が、部屋作りの体験ができるシミュレーションシステム「GRID VRICK(グリッドブリック)」です。 動作している様子は以下の動画でご覧いただけます。 LEGO(R)のブロックで作った室内をOculus Riftでウォークスルー!「GRID VRICK ... 詳細は以下からご覧ください。 「GRID VRICK」(グリッドブリック)おもちゃのブロック等で楽しみながらお部屋作り 株式会社ネクスト リッテルラボラトリー 11月23日(日)、11月24日(月)で開催されるMaker Faireに出展(東京国際展示場・西3ホール 21-6)しますので、気になった方はぜひぜひ遊びに来てください! Maker Faire Tokyo 2014 | Maker Faire Tokyo 2014 | Make: Japan Maker Faire Tokyo 2014 | Maker Faire Tokyo 2014 | Make: Japan
こんにちは。iOS開発Gの石田です。 iPhone6とiOS8が出てしばらく経ちますが、もうすでに入手されたかたも多いかと思います。 iOS8の新機能で僕が注目しているのが、Homekitです。家電をiOSデバイス経由で操作することができる機能で 寒い冬は家に帰る前にエアコンをつけておいてあったかくしておくとか、Siriに「電気消して!」と頼んだら消してくれるようになりそうです。 しかしこのHomeKitなのですが、家電がHomeKitに対応していないと使うことができません。 現状で対応している家電としては こんな室温調節器や http://lyric.honeywell.com/ こんな電球がありますが http://www2.meethue.com/ja-jp/ 海外メーカーしかなく、家電量販店などで我々が目にするメーカーはまだ対応していません。 今後対応機種が発表されていくと思いますが、現在はシミュレータで開発するしかない状況です。 そこでSiriとIRKitという赤外線学習を使えば、HomeKitなしで似たようなことができるのでは・・・と思い立ち 作ってみました。 IRKitについて IRKitとは、Wifi機能がついた赤外線リモコンで、外部からアプリを通してリモコンの信号を送ることができます。 このIRKitはAPIが公開されており、簡単に自分でアプリなどに組み込めるため、様々な方が開発を行っています。 http://getirkit.com/ これを用いれば、赤外線リモコンで操作ができる家電であれば遠隔操作することができます。また赤外線で操作できない家電でもこのようなキットをを使うことで、 家電を赤外線に対応することができます。 http://hitoriblog.com/?p=24191 iOS8でのSiriの新機能 iOS8の新機能として、「Hey! Siri」と呼びかけるとSiriが起動する機能が追加されました。 そこから質問を投げかければ、Siriが質問に答えてくれるようになっています。 ここで重要なのが、画面がロックされていても電源に繋がっている状態であればSiriが起動することです。 しかしながら現在、Siriからサードパーティ製のアプリを操作するといったことはできません。SiriのAPIは公開されていないので appleのアプリであるタイマー、アラーム、天気、メモなどの操作しかできません。 ただアプリ名を言うと、そのアプリを起動することができます。 つまり電源に繋がっているiPhoneに「Hey,Siri アプリ名」と呼びかければ、待機状態のiPhoneのアプリを起動することができるということです。 実現方法 iOS8のSiriとIRKitを組み合わせて、Siriに家電を操作してもらうようにします。 方法以下の通りです。 「電気つけて」など命令形の名前のアプリを作り、そのアプリが起動したらIRKit経由で家の電気がつくようにする。 そのアプリを「Hey Siri」で起動することにより、疑似的にSiriが家電を操作しているようになる! つまり命令の数だけアプリを作り、Siriに命令しているかのように話すと、Siriはアプリを立ち上げるのです。 ここで注意点としては、命令文のアプリを作っても起動してくれないことがあります。 例えば「テレビつけて」という名前のアプリを作って、「Hey,Siri テレビつけて」と言っても 「いいえ、それはできません」と断られてしまいます笑。これは、Siriが「テレビつけて」という言葉をちゃんと命令として 認識してしまうことが原因です。現状でこの現象が起きたのはテレビだけで、「電気つけて」や「電気消して」は大丈夫でした。 いわばSiriの認識の甘さを利用しているだけなので、Siriがもっと賢くなって命令として認識されてしまうとこの手法は使えません。 現状で命令と認識されてしまうものについては、別の言葉にするしかありません。例えば今回は、「テレビ電源」という言葉に置き換えています。 アプリについて Siriで起動して、家電を操作するアプリですが、非常にシンプルなものになります。 初回起動時のみ、家電の赤外線情報を登録する画面が出て、使いたい家電のリモコンをIRKitに向かって押し、登録します。 それ以降の起動では、Wifiに繋がっているIRKitを探し、登録されている赤外線信号を送信、その後すぐにアプリを終了します。 もちろん1アプリ1命令になるため、命令の数だけアプリを作ってiPhoneにインストールします。 IRKitの検索、信号の送信などの機能の組み込みは、SDKが公開されているので非常に簡単に行うことができました。 作って実際にやってみた https://www.youtube.com/watch?v=3df-6wTeDZY Siriで家電を操作してみた 動画では、間接照明のON・OFF、テレビON、チャンネルの変更を行っています。 割と正しく認識して、家電を操作してくれます。Siriの認識、アプリの起動、IRKitの検索、信号の受信という過程があるため、 命令してから実際に操作が完了するまでに少しラグがあります。 またテレビを付けたあとの命令の認識に特に時間がかかっています。 これはテレビの音声をSiriが拾ってしまうことが原因です。なのでチャンネル替えや音量調節といったテレビの操作は 現状では難しそうです。 最近では、テレビに音声認識機能がついたものが相次いで発売されています。リモコンに向かって、 ボタンを押している間だけ認識されるものが多いので、そういったものであれば認識は素早くできそうです。 (リモコンに向かって話しかけるくらいなら、リモコンのボタンを押した方が早いとは思いますが・・) 認識できる距離ですが、iPhoneにある程度の声量が届けば認識してくれるので、隣の部屋くらいであれば大丈夫そうです。 使い方としては、帰宅後に暗くて電気のスイッチがどこにあるのか分からないときに、暗闇に向かって命令すると 電気をつけてくれるのが便利です。 また家を出るときや帰宅後に着換えながら、テレビを消すといった使い方も便利です。手を使えない状況では重宝します。 最後に なんとか使えるレベルにはなりましたが、まだまだSiriが認識してくれるように意識して丁寧に話さないとうまくいきません。 今回作った似非HomeKitでは、「電気つけといて」「電気オン」「ライトつけて」という別名アプリをたくさん作らないと 別の言い回しには対応してくれません。 本物のHomeKitでは、もっと適当に話しても読み取ってくれる高い認識精度を期待します。 とりあえず似非HomeKitの次の機能追加としては、iBeaconを連携させることを考えています。 また本アプリは、名前だけ変えて同じアプリを複数インストールする必要があるため、iOS Developer Programの登録が必要です。 App Storeへの審査・配布は機能的に難しいと思いますので Homekitが待ち遠しい方は、ぜひIRKitを使って開発してみてください。
秋晴れがすがすがしい今日この頃ですが、いかがお過ごしでしょうか。鈴木です。 ネクストのiOS開発Gでは、9月より不定期にて外部の方を交えて 「iOS開発者向けもくもく会」を開催・運営しています。 もくもく会とは 定義は特に決まっていませんが、名前の通り、 エンジニアが集まって、プログラミングを行う、という趣旨のイベントです。 「iOS開発者向けもくもく会」の特徴 もくもくしながらも開発をもっと良くするためにみんなが行っている手法について、 プログラミングで詰まっているところなどを聞き合える雰囲気があることです。 すでに4回行い、それぞれ任意参加の懇親会も実施しています。 運営してみて 本当にいろいろなバックグラウンドのある方々とお話できる機会があり、 技術力向上はもちろん、さまざまなキャリアに触れることができます。 (例) * 普段からiOS開発をしている人 * 普段の業務とは異なる言語としてiOS開発をしている人 * 趣味でiOS開発をしている人 * 会社に属して働いている人 * フリーランスで働いている人 私は文系出身のエンジニアで、マーケティング・営業などを経験していたものの 昔からバリバリ実装型のエンジニアではありません。 似た境遇の方は、どのように学び、キャッチアップしていったのか。 逆に、学生時代からずっと開発をしていた方は何を考えているのか。 そのようなギャップを知ることで、チームの中の一員として貢献するために、 自分が埋めるべきこと、協調するべきことは何か。を自問自答するヒントになっています。 やはり、人と面と向かって話すことは学びがあり、 今の業務を幅広い視野から捉えるための活力になると思います。 告知 今後も不定期ではありますが、ネクストでは 「iOS開発者向けもくもく会」を実施していきたいと考えています。 参加条件など詳細は下記イベント告知サイトにてご確認ください。 もくもくiOS勉強会@ネクスト もくもくiOS勉強会@ネクスト 皆様の参加を心よりお待ちしています。
藤原と申します。 10/18にYahoo!さんで開催された 「iOS8/Swift エンジニア勉強会」 に参加してきました。 この勉強会の内容に関しては、既にいろんな方が書かれていたり、 スライドが公開されたりしていますので、 違った視点からこの勉強会について感じたことを書かせていただこうと思います。 知識の蓄積と適切な選択 今回の勉強会で、iOS8対応に関する様々なTipsを共有していただきましたが、これまで対応してきた中で「あるある!」と思えるようなものばかりで、やはり先行して物事を進めている印象を受けました。 特に印象に残ったのが「iOS8対応の対応方針で適切な優先順位を付けている」と感じた点です。 今回iOS7からiOS8にバージョンが上がる際に必要な対応としては、 「iOS8でアプリが動作する(落ちない)ための対応」 「iPhone6, iPhone6 Plus対応(画面サイズ変更)」 「iOS8での新機能導入」 の3つがあげられ、私達も弊社のアプリである「HOME'S」の対応を、1→2の順でやっていましたが、2.の作業に大きく時間がかかり、3.「iOS8での新機能導入」になかなかチャレンジ出来ない状態でした。 一方Yahoo!さんでは、1→3の順番で対応されていて、まず新機能を優先的に進めており、かつそれまで蓄積していた知識・見識で、短い工数で新機能の導入まで行っていました。 今後は私達も、アプリの効果を出すこと、たくさんの方に使ってもらうことを考えると、最新知識だけではなく、日々の業務におけるノウハウの蓄積を行うだけではなく、そして、適切な優先順位を付けて対応していかなければいけないと感じました。  チャレンジのスピードとモチベーション LTにおいて、正式版が出る前に1ヶ月半前にSwiftでの開発を決め、iOS8正式版リリース日に間に合わせてアプリをリリースされたお話を聞いたり、カスタムキーボードを使用した新たな試みなどの話を伺いました。 あのベータ版の状態でその決心や試みをするのは、ものすごくチャレンジングで勇気のいることだったんだろうな・・・と感じるとともに、自分達も負けていられないという印象を受けました。 日々の業務との兼ね合いというのもありますが、むしろ言ったもん勝ち、言ったからにはやります、というチャレンジ精神を常に持たなければいけないと感じました。 また、セッションをされた新卒エンジニアの方から、ベテランエンジニアの方まですごく楽しそうに話をされていて、本当に日々の業務を楽しく、ポジティブにされているんだろうな、と感じました。 これはYahoo!さんの社員の方だけではなく、社外から参加されている方にも同じ印象・熱意を受けました。   まとめ 今後、自分達が成長するために「知識の蓄積と適切な選択」「チャレンジのスピードとモチベーション」を常に意識し、「物を生み出す、手を動かすところからスタート」を実践しなければいけない、という教訓を得ることが出来ました。 エンジニアである以上、スピード感を持ってものづくりを見せていくことで、この勉強会で得た内容をフィードバック出来るよう心がけたいと思います。 今回このような貴重な機会を提供していただいた、Yahoo!様と刺激的な話をしてくださった、スピーカーの方に感謝を述べて、締めくくらせていただこうと思います。
Apple原理主義者であり、Paper原理主義者とも名乗ろうかと考えている大坪です。 Facebook paperの開発舞台裏の記事を読み「 がびーん 」となったのがほぼ半年前。アニメーションエンジンのpopにも感動したのですが、一番重要な非同期UI部品がなかなか公開されない。最初は是非使いたいと思っていたけどこれ以上待ちきれない、と見切りをつけて開発し始めたアプリが表にでた頃いきなりニュースが飛び込んできました。 The case for AsyncDisplayKit 引用元: Introducing AsyncDisplayKit: For smooth and responsive apps on iOS | Engineering Blog | Facebook Code Facebook paperを触るとすぐに気がつくことですがあの動きの滑らかさは普通ではない。裏で大量の画像をダウンロードし、デコードを行っている。であればCPUは忙しくなり、ユーザは反応の悪さにいらいらしてしまう。 For an app to maintain the gold standard of 60 frames per second, it can only use the main thread for milliseconds at a time. But main-thread-only UIKit views like UIImageView and UITextView can take tens to hundreds of milliseconds to size and display themselves. And while the main thread is decoding an image or rendering text, it can’t respond to user input or keep up with scrolling. 引用元: Introducing AsyncDisplayKit: For smooth and responsive apps on iOS | Engineering Blog | Facebook Code 適当な訳:秒間60フレームという黄金律を守ろうと思えば、メインスレッドを一度に数ミリ秒しか使うことができない。しかしメインスレッドでしか動かないUIImageViewやUITextViewなどのUIKit部品はサイズを変更し表示するのに数百ミリ秒を使ってしまう。メインスレッドが画像をデコードしたり文字を描画している間、アプリはユーザの入力を受け付けたりスクロールしたりすることができない。 しかしFacebook paperはほとんどの場合ユーザ操作に即座に反応する。なぜそういうことが可能なのか? AsyncDisplayKitはメインスレッドでしか操作できないUIViewの代わりにNodeを導入しました。 If you know how to use views, you know how to use nodes. ASImageNode and the Text Kit-powered ASTextNode can be used just like their UIKit counterparts. Unlike UIKit view hierarchies, node hierarchies for entire screenfuls of content can be initialized and laid out on background threads — and nodes make it easy to take advantage of the multicore CPUs in all current iOS devices. 引用元: Introducing AsyncDisplayKit: For smooth and responsive apps on iOS | Engineering Blog | Facebook Code 適ry)訳:Viewの使い方がわかっていれば、Nodeを使うことができる。ASImageNodeやText Kitを使ったASTextNodeはUIKitの同等部品(訳注:UIImageViewとUILabel)と同じように使うことができる。UIKitの階層と違って、Nodeの階層はバックグラウンドスレッドで作成、配置することができる。そのためNodeは最近のiOSデバイスのマルチコアCPUの利点を生かすことができる。 なるほど、わからん。 実際に動かしてみないことにはなにがなんだか、というわけでさっそくサンプルプログラムを作ったわけです。参考にしたのは 本家 のExampleプロジェクトと Startガイド です。 ーーー 最初に言い訳をいくつか。今回文字通り泡食って作ったサンプルなので正しい使い方をしているという保証はありません。おまけにSwiftを使うのも初めて、とあっていろいろおかしなところもあるかもしれませんが私はこの記事を読んでくれる方の心の広さを信じています。 さて今回作ったのはこんなアプリです。 立ち上げると二つのボタンが置かれた画面がでてくる。それぞれ押すと似たような画面に遷移する。それがどうした、と言いたくなるのをぐっと堪えましょう。遷移先の画面には子猫の写真とテキストがずらっと並んでいます。個数はそれぞれ100個。 ソースは Github におきました。Cocoapodsを使っているので、実行前に"pod install"を実行してください。 このプログラムを例えばiPhone4Sで動かすとレスポンスの違いがわかると思います。UIViewと書かれたボタンを押すと、遷移まで「ぐっ」と一呼吸間があります。AsyncNodeを押すと一瞬で遷移する。なぜこのような違いが生じているのか。 ーーー UIViewとかかれたボタンを押すと、普通のUIViewを使った画面へ遷移します。遷移先のUIViewControllerであるところのStdViewControllerを見てもらうと、loadView()の中で必要なビューを作成し、UIScrollView上にずらずら並べ、addSubviewしている。これらの処理は全てメインスレッドで行われるので、ここで時間をとってしまい画面遷移のアニメーションが「もっさり」になるわけです。 AsyncNodeと書かれたボタンを押すと、AsyncDisplayKitを使ったAsyncViewControllerに遷移する。ソースを見てみるとloadViewはこんな風になっています。 ベースとなるUIScrollViewをつけた後にGCDを使い、バックグラウンドスレッドで画面部品の作成、配置を行い、その後にメインスレッドでそれらをUIScrollViewにaddSubviewする。これによって重たい処理をメインスレッドで行うことなく画面遷移のアニメーションがスムーズに動くわけです。 StdViewControllerとAsyncViewControllerを比べてもらうとわかるのですが、処理の流れはほとんど同一です。(GCDを使っているところを除けば)しかし神とか悪魔は常に細部に宿っている。というわけで「細かいところ」を見ていきましょう。 違いその1 UIImageView,UILabelの代わりにASImageNode,ASTextNodeが使われている。 違いその2 文字列を画面幅に収める時、高さがどれだけになるかを計算する必要が有ります。 StdViewControllerでは let tSize = textView.sizeThatFits(vSize) としていますがAsyncViewControllerでは let tSize = textNode.measure(vSize) としています。このmeasureという関数は、sizeThatFitsと似ていますが、計算したサイズの値をASTextNodeのプロパティとして保存してくれる、といううれしさがあります。後で参照するのが簡単ですね。 違いその3 SDWebImageDownloaderを使って画像をダウンロードしています。そのcompletionBlockがAsyncViewControllerのほうが複雑になっています。 データが返ってきたときに、対象となるASImageNodeがロードされていた場合には、メインスレッドでイメージをセットする必要が有ります。これを抜かすとクラッシュです(何度もやったので確信を持って断言できます) 逆に言えば、これだけの修正で時間のかかる処理をバックグラウンドで行うことができる。やれありがたや。 というわけでなんとかこのライブラリをあちこちで使っていきたいと思っている今日この頃。ちょっと待て、UIControlはどうしてくれるとかStoryboardはどうするんだとかAutolayoutはこれとどう共存するのか、とかあれこれ面白い話があるのですが今回はここまで。
こんにちは、上津原です。 UE4.5が来ましたね(リリースされたと思ったらプレビューになったりしましたが) 4.4では正式機能ではなかったUMG(Unreal Motion Graphics)が正式機能として乗っかってきました。 UMGはGUIデザイナーみたいなもので、今までHUDに書いていたものをこっちに書くことでグラフィカルでお手軽にGUIを作成できるようになります。 せっかくなので以下をやって動かしてみました。 Unreal Engine | Unreal Motion Graphics (UMG)のクイック スタート ガイド ※上リンクの内容は4.4の内容なので、2のEditor Preferencesの設定は必要ないです。 上記のやつをやって初歩的な使い方がわかったので、今回はとりあえず適当な場所にボタンを置いて押せるようにしてみたいと思います。 Widgetブループリントを作る コンテンツブラウザの「新規」から「ユーザーインターフェース > Widgetブループリント」を選びます。名前は適当に(今回はButtonUIとつけました) そしてそれを開くとこんな感じに。 真ん中の青色の部分が画面サイズを示していて、これに対応するようにUIを置いていくという感じになります。 ボタンを配置して表示する 左の方にあるパレットから「Common > Button」を選び、画面にドロップします。この辺はレベル作成とおんなじですね。 ボタン配置ができたら保存して、レベルブループリントを開きます。 そしたらUserWidgetの変数を追加して以下のようにBluePrintを組みます。 まとめると、「Create Widget」をして「Add to Viewport」をするだけ。簡単です。今回はボタンなのでクリックできるようにマウスポインタを表示しています。 ここで実行すると画面にこんな感じでボタンが表示されます。 ボタンにアクションを付ける さて、これで表示はできました。 ここからボタンにアクションを付けたいわけですが、先ほど作成したWidgetブループリントに戻ってボタンを選択し、右の詳細を見ると「イベント」という項目があります。 そこの「AddOnClicked」を押すとブループリントにイベントが追加されアクションを付けられるようになります。 そしたらアクションを付けて実行してみれば動作するはずです。 一連やってみて思ったこと HUDと比べてみながらGUIの作成ができるのはとても楽だしわかりやすくていい感じです。 画面サイズを変更すると、それに応じてGUIの位置を変更してくれたりなどスマホや様々な画面サイズへの対応ができるようにもできているし、表示非表示も手軽にできているので使い勝手はとても良いと思います。 ただ、ButtonはClickしかなくてDownとReleaseを分けてアクションを付けられなかったりなどあるので今後のアップデートに期待です。 とっても簡単に伝えてきましたが、上の方で紹介した公式のURLではもっとちゃんとした説明があるのでやってみてもらえればと思います。
クリエイターの日運営委員の松尾です。 前回 と 前々回 に引き続き、第2四半期にあたる7~9月にも様々なチームが クリエイターの日を利用して、ものづくりを行いました。 今回は新卒1年目の社員が2人で進めているものづくりを紹介します。 お二人の名前と、今回の活動について教えて下さい。 東  デザインとフロントエンドのコーディングを担当した東です。普段は駆け出しのデザイナーとして、HOME'SのバナーやLPを作っています。 まずモチベーションとして、普段業務を進める上で、HOME'Sに関わる社内の皆さんが共有して追いかけられる数字が見られると、チームとしての一体感が生まれるのではないかと思いました。そこで、HOME'SのKPIの変化をリアルタイムにブラウザで見られるWebアプリを作りました。 石田  バックエンドを担当した石田です。普段の業務ではHOME'SのiOSアプリを作っています。今回はGoogle Analytics APIを使ってHOME'SのKPIの数値を10分おきに取得する仕組みを作りました。 数値がグラフで表示され、更新時にはエフェクトがかかる ※モックのため、数値は仮のものです 初挑戦ということで、苦労した部分はありますか? 東  フロントエンドでのグラフの描画や動きについて、D3.jsというライブラリを使いました。 ですが、Javascriptをまともに書いたことがなく、教本を読み進めながら作ることになりました。 集中的にがっつり時間を割けるクリエイターの日の制度がなければ出来なかったと思います。 石田  APIにアクセスする処理はPHPで記述しています。 ですが、PHPでGoogle AnalyticsのAPIを扱う情報が少なく、自身のPHPの経験も少なかったため データの取得部分にはとても苦労しました。 苦労しながらも ニヤニヤ もくもくと開発する石田 苦労しつつも成果が出ました。今後も活動しますか? 東  はい。続けます。まだ荒削りなので、次のクリエイターの日では 取れるデータを正確にして、社内で見ても違和感のないものにしたいです。 また、iPhoneやAndroidのウィジェットとして社内で見られるように、改良していきたいです。 (主に姿勢に)苦労する東 他にも感想があれば教えて下さい。 東  ほぼ知識ゼロの状態から新しいことに挑戦できたので、とても良い経験になりました。 この経験を活かして、貪欲にもっと面白いものを追求していきたいです。 石田  始める前は社内の事情も技術的なことも全然分からない状態で焦りましたが 積極的に他部署の人に聞きに行くと、大変丁寧に教えて下さり、実現できました。 社内の人たちの「利他主義」を強く感じたクリエイターの日でした。 報告会で社内でのアピールもバッチリ 2人が語ってくれたように、クリエイターの日には 参加者のキャリア(新卒やベテラン)に関わらず 普段の業務とは直接関連のないものでも 7営業日内で集中して 取り組むことができます。 ものづくりをより活発にするべく、今後もクリエイターの日を盛り上げます。
こんにちは。菊地です。 前回の記事( Android Studio でのメモリ解析の方法 - 株式会社ネクスト エンジニアBlog )で、AndroidStudioにおけるメモリ解析についてまとめましたが、今回はその補足のような記事になります。 AndroidStudio でメモリ関連の調査を行う際に便利だなと思った機能がありましたので、そちらのご紹介になります。 今回は AndroidStudio (Android DDMSかもしれませんが)にある Graphics Acceleration の情報を確認するための Graphics States ActivityManagerの状態を確認するための Activity Manager State という2つの機能について記事にさせていただきます。 ※ここからは、サンプルとして Navigation Drawer Activity を新規プロジェクトとして作成しています Graphics State どうやって使うの? AndroidStudio > Android DDMS で左側のウィンドウに表示されているパッケージ名から調べたいパッケージ名を指定します。 パッケージを指定したあと Android DDMS > System Information > Graphics States で使えます 何がみれるの? Graphics State という名前のとおり、現在のアプリにおける描画の状態が確認できます どのような描画命令が行われたのか? 描画時に使われたメモリ量(現在/最大) 描画されたViewの数、メモリおよび描画フレーム数 Applications Graphics Acceleration Info: Uptime: 610094 Realtime: 610094 ** Graphics info for pid 2096 [jp.nextgroup.myapplication] ** Recent DisplayList operations どのような描画命令が行われたかを一覧で見ることができます Recent DisplayList operations DrawDisplayList DrawPatch DrawRect DrawRect DrawRect DrawPatch DrawPatch SetupShader DrawRect ResetShader DrawDisplayList DrawDisplayList DrawDisplayList Save ClipRect DrawDisplayList DrawDisplayList RestoreToCount DrawRect Save DrawDisplayList DrawRect DrawDisplayList DrawPatch Save ClipRect Translate DrawText RestoreToCount DrawDisplayList Save ClipRect Translate DrawText RestoreToCount DrawDisplayList Save ClipRect Translate DrawText RestoreToCount RestoreToCount DrawPatch DrawDisplayList DrawPatch DrawRect DrawRect DrawRect DrawPatch DrawPatch Caches 描画命令における 現在のメモリ使用量 描画に使用された合計メモリ量 を確認することができます Caches: Current memory usage / total memory usage (bytes): TextureCache 167952 / 25165824 LayerCache 0 / 16777216 RenderBufferCache 0 / 2097152 GradientCache 0 / 524288 PathCache 0 / 10485760 TextDropShadowCache 0 / 2097152 PatchCache 1472 / 131072 FontRenderer 0 A8 524288 / 524288 FontRenderer 0 RGBA 0 / 0 FontRenderer 0 total 524288 / 524288 Other: FboCache 0 / 16 Total memory usage: 693712 bytes, 0.66 MB View Hierarchy Viewの描画に関する 描画されたViewの数 Viewの描画に使われているメモリ使用量 Viewの描画にかかったフレーム数 といった情報を見ることができます Profile data in ms: jp.nextgroup.myapplication/jp.nextgroup.myapplication.MyActivity/android.view.ViewRootImpl@52876bc0 View hierarchy: jp.nextgroup.myapplication/jp.nextgroup.myapplication.MyActivity/android.view.ViewRootImpl@52876bc0 24 views, 2.55 kB of display lists, 19 frames rendered Total ViewRootImpl: 1 Total Views: 24 Total DisplayList: 2.55 kB Activity Manager State どうやって使うの? AndroidStudio > Android DDMS で左側のウィンドウに表示されているパッケージ名から調べたいパッケージ名を指定します。 パッケージを指定したあと Android DDMS > System Information > Graphics States で使えます 何が見れるの? 現在のアプリにおける ActivityManagerの状態を見る事が出来ます Activity の情報 Activity に Attach されている Fragment Fragment の情報 Viewの階層構造 などなど Fragmentの状態なども視覚的に確認することができ、Fragmentが破棄されているのかどうか?といったことも確認することができて、とても便利でした。 TASK jp.nextgroup.myapplication id=4 ACTIVITY jp.nextgroup.myapplication/.MyActivity 52a1a528 pid=2096 Local Activity 52852ee4 State: mResumed=true mStopped=false mFinished=false mLoadersStarted=true mChangingConfigurations=false mCurrentConfig={1.0 ?mcc?mnc en_US ldltr sw360dp w360dp h567dp 480dpi nrml port finger qwerty/v/v dpad/v s.5} Active Fragments in 52852f64: #0: NavigationDrawerFragment{5287b3b8 #0 id=0x7f080002} mFragmentId=#7f080002 mContainerId=#7f080000 mTag=null mState=5 mIndex=0 mWho=android:fragment:0 mBackStackNesting=0 mAdded=true mRemoving=false mResumed=true mFromLayout=true mInLayout=true mHidden=false mDetached=false mMenuVisible=true mHasMenu=true mRetainInstance=false mRetaining=false mUserVisibleHint=true mFragmentManager=FragmentManager{52852f64 in MyActivity{52852ee4}} mActivity=jp.nextgroup.myapplication.MyActivity@52852ee4 mView=android.widget.ListView{528798c8 VFED.VC. ........ 0,0-720,1557 #7f080002 app:id/navigation_drawer} #1: PlaceholderFragment{52862068 #1 id=0x7f080001} mFragmentId=#7f080001 mContainerId=#7f080001 mTag=null mState=5 mIndex=1 mWho=android:fragment:1 mBackStackNesting=0 mAdded=true mRemoving=false mResumed=true mFromLayout=false mInLayout=false mHidden=false mDetached=false mMenuVisible=true mHasMenu=false mRetainInstance=false mRetaining=false mUserVisibleHint=true mFragmentManager=FragmentManager{52852f64 in MyActivity{52852ee4}} mActivity=jp.nextgroup.myapplication.MyActivity@52852ee4 mArguments=Bundle[{section_number=1}] mContainer=android.widget.FrameLayout{5287ad2c V.E..... ........ 0,0-1080,1557 #7f080001 app:id/container} mView=android.widget.RelativeLayout{5285b990 V.E..... ........ 0,0-1080,1557} Added Fragments: #0: NavigationDrawerFragment{5287b3b8 #0 id=0x7f080002} #1: PlaceholderFragment{52862068 #1 id=0x7f080001} Fragments Created Menus: #0: NavigationDrawerFragment{5287b3b8 #0 id=0x7f080002} FragmentManager misc state: mActivity=jp.nextgroup.myapplication.MyActivity@52852ee4 mContainer=android.app.Activity$1@52852fa0 mCurState=5 mStateSaved=false mDestroyed=false ViewRoot: mAdded=true mRemoved=false mConsumeBatchedInputScheduled=false mPendingInputEventCount=0 mProcessInputEventsScheduled=false mTraversalScheduled=false android.view.ViewRootImpl$NativePreImeInputStage: mQueueLength=0 android.view.ViewRootImpl$ImeInputStage: mQueueLength=0 android.view.ViewRootImpl$NativePostImeInputStage: mQueueLength=0 Choreographer: mFrameScheduled=false mLastFrameTime=592749 (15996 ms ago) View Hierarchy: com.android.internal.policy.impl.PhoneWindow$DecorView{52853760 V.E..... R....... 0,0-1080,1776} com.android.internal.widget.ActionBarOverlayLayout{52853f34 V.ED.... ........ 0,0-1080,1776 #1020313 android:id/action_bar_overlay_layout} android.widget.FrameLayout{52855914 V.E..... ........ 0,219-1080,1776 #1020002 android:id/content} android.support.v4.widget.DrawerLayout{528758b8 VFE..... .F...... 0,0-1080,1557 #7f080000 app:id/drawer_layout} android.widget.FrameLayout{5287ad2c V.E..... ........ 0,0-1080,1557 #7f080001 app:id/container} android.widget.RelativeLayout{5285b990 V.E..... ........ 0,0-1080,1557} android.widget.TextView{52875bc0 V.ED.... ......ID 48,48-48,105 #7f080003 app:id/section_label} android.widget.ListView{528798c8 VFED.VC. ........ 0,0-720,1557 #7f080002 app:id/navigation_drawer} android.widget.TextView{52852058 V.ED.... .....A.. 0,0-720,144 #1020014 android:id/text1} android.widget.TextView{52876384 V.ED.... ........ 0,143-720,287 #1020014 android:id/text1} android.widget.TextView{528794ac V.ED.... ........ 0,286-720,430 #1020014 android:id/text1} com.android.internal.widget.ActionBarContainer{52855b94 V.ED.... ........ 0,75-1080,219 #1020314 android:id/action_bar_container} com.android.internal.widget.ActionBarView{5285b218 V.E..... ........ 0,0-1080,144 #1020315 android:id/action_bar} android.widget.LinearLayout{5285b5b0 VFE...C. ........ 0,0-531,144} com.android.internal.widget.ActionBarView$HomeView{5285fb5c V.E..... ........ 0,0-145,144} android.widget.ImageView{5285fdb4 V.ED.... ........ 0,48-48,96 #102025a android:id/up} android.widget.ImageView{528614a4 V.ED.... ........ 37,24-133,120 #102002c android:id/home} android.widget.LinearLayout{52861ee4 V.E..... ........ 145,35-531,108} android.widget.TextView{52862120 V.ED.... ........ 0,0-362,73 #1020265 android:id/action_bar_title} android.widget.TextView{52862790 G.ED.... ......I. 0,0-0,0 #1020266 android:id/action_bar_subtitle} com.android.internal.view.menu.ActionMenuView{5284cd88 V.ED.... ........ 912,0-1080,144} com.android.internal.view.menu.ActionMenuPresenter$OverflowMenuButton{52848a78 VFED..C. ........ 0,0-168,144} com.android.internal.widget.ActionBarContextView{52862afc G.E..... ......ID 0,0-0,0 #1020316 android:id/action_context_bar} com.android.internal.widget.ActionBarContainer{528680e8 G.ED.... ......ID 0,0-0,0 #1020317 android:id/split_action_bar} Looper (main, tid 1) {5284fff0} (Total messages: 0, idling=false, quitting=false) まとめ Graphics Manager は描画命令を視覚的に確認できるほか、メモリ使用量のほか描画にかかったフレームなども見る事ができます。 そのため、 描画が遅い? と思ったときや、 なんか重くなった! 描画重い!? と嘆く前にこれを使い、実際にどういったことが行われて、どの程度の時間がかかっているのかを確認することで、少しでも操作を快適にできるかもしれません。 Activity Manager State もライフサイクルが複雑なFragmentについて、実際の状態を確認することができますし、実は裏でFragmentが生き残っていた!!なんてことも防げるようになると思います。 こういったツールも使いながら少しでもいいアプリを提供できるようにしていけたらと思います。
こんにちは、上津原です。 今回はタイトル通り、UE4にあるDynamic Global Illuminationを試してみたので、そのやり方とどんなふうに変わるかを書きたいと思います。 ※この機能は開発段階のものなので、本番環境での利用準備はできていないものです。 Global Illuminationってなんじゃ? グローバルイルミネーションとは グローバル・イルミネーション(global illumination,大域照明)は、 拡散光を正確に扱うレンダリング技法のことで、 ローカル・イルミネーション(local illumination,局所照明)の対義語。 非常に写実的、つまり物理的に正しい表現が可能である。 レンダリング方程式が考え出された時点で、理論自体は存在していたともいえるが、 当時の貧弱な計算能力や複雑な確率計算に用いるアルゴリズムの不備により、 近年になるまで注目されなかった方法である。 Wikipediaより( グローバル・イルミネーション - Wikipedia ) 僕も詳しくは言えませんが、反射光や拡散光を現実に近い感じでレンダリングしてくれるんですね。 じゃあDynamic Global Illuminationってどういうこと? グローバルイルミネーションに、ダイナミックが付きました。つまり、動的にそれらが計算されるという事です。 通常であれば、ライティングをビルドするときにライトマッピングされてそれぞれにベイクされる感じになるわけですが、これはその処理の必要なく、動的にその処理が行われるというわけです。 わー、なんかスゴそう。そして重そう。 やり方は? ① C:\Program Files\Unreal Engine\4.4\Engine\ConfigのConsoleVariables.iniを開きます。 ② [Startup]の下に「r.LightPropagationVolume=1」を書き足し、保存 ③ Unreal Edirotを開き、プロジェクトのワールド設定内の「Force No Precomputed Lighting」のチェックを外す ④ Directional LightをMovableにし、「Affect Dynamic Indirect Lighting」のチェックを入れる ⑤ おしまい! 動かすとどんな感じになる? Before After かなり違いますね~。反射光があるから中の方まで明るくなってくれて、かなり自然な表現になっています。 右の方にあるCubeのそこには、床になっている芝生の緑色が反射しているのもわかりますね。 FPSはどんなもんか? デフォルトのBP FPSプロジェクトに屋根を追加し、 エディターのビューポートでプレイした結果 Dynamic GI あり:110前後 Dynamic GI なし:115前後 という感じでした。5前後変わってきますね。 ムービーもいくつかあったので載せておきます。 ・チュートリアルムービー ・動かしてみたムービー 開発中のものなので実用性云々を言えるものではありませんが、動かしてみるのは楽しいですね。
こんにちは。Android 衛藤です。 ネクストには クリエイターの日 というものがあり、通常業務から外れて新しい技術等に取り組む機会が与えられます。 非常に魅力的なこの制度、今回初参加させていただくことになりました。 デザイナー1名とエンジニア2名、計3人での取り組みとなります。 取り組む内容 Android Wearアプリの開発 です。 新しい技術は早いうちに学びたい、と思っていたので ちょうどよい機会になりそうです。 様々なメーカーからAndroid Wearが出てきていますが、 どんな使い方が本当に便利なのか? まだ出てきたばかりなだけに、いろんな可能性を秘めているウェアラブルの世界。 今後どんな風に便利になっていくか楽しみです。 Android Wearアプリを開発するときの注意 本家のDocumentはしっかりと書かれていました。 https://developer.android.com/design/wear/index.html こちらに、開発する際のアドバイスがたくさんあります。 また、スマホやタブレットとまったく違うため、デザインに関する注意もあります。 ユーザが操作する際に他の作業を止めるようなことをしない 料理、食事、歩きながら、走りながら等、時計型デバイスは何かをしながら扱うのに最適なので、 デバイス操作のたびに他の作業を止めてしまうのはナンセンス。 たとえば、メールが来てアーカイブする、スケジュールの通知が来てスケジューラにセットする、 などの一連の操作は"5秒以内"に収める。 大き目のジェスチャーに 上記のとおり、何かをしながら操作することが多いウェアラブルデバイス。 少しでも大き目のボタンやリストを作りましょう。 カードを表示する時を第一に考える ウェアラブルは「必要なときに、必要なコンテンツを」が大切。 必要と思われるシチュエーションを整理し、どんなときに見せれば便利かを考えましょう。 あまり必要じゃない時にコンテンツを出しすぎると、ユーザにミュートされてしまいます。 一つの情報で、簡潔に できるだけ見せたい情報に絞っていきましょう。 多いと感じたら、本当にすべての情報が必要か?または複数ページに分離してしまうことを検討しましょう。 視覚的にデザインする どうすれば、ユーザがアプリから素早く情報を得て、作業にすぐに戻れるかを意識してデザインしましょう。 バックグラウンドのイメージが、見せたいメッセージを後押ししているか、など。 肩たたきしない ウェアラブルは常にユーザに触れています。 人と会話しているときに、いきなり後ろから肩を叩かれるとどう思いますか? デバイスのバイブレーションや音で同じようなことをしすぎないようにしましょう。 今回やること 機能は二つ、 通知の連携 道案内(Navigation) 二つだけなのですが、UI考えたり、実際のデバイスとの連携がどんな感じになるのか全くわからなかったため、 思い通りにいかないことが最初はほとんどでした。 何か情報がないか検索してもあまり記事が多くないため、試行錯誤しながらの開発・・・ たぶんAndroidが出たばかりの頃もこんな感じだったんでしょう。 特にUIに関してはどんな見せ方がよいのか、また実装として実現可能かの判断があまりつかず、 UIや画面遷移を考え直すこともしばしばありました。 Handheld(スマホ)とWearの連携 Handheldとペアリングさえしておけば、自動的にWearにも通知が出ます。 Wear側でボタンアクション等追加する場合は、基本的にはHandheld側でPendingIntentを発行します。 これまで通り PendingIntent.getActivity() で画面を開く、 PendingIntent.getBroadcast() でBroadcastすることが可能です。 ただし、WearアプリのActivityを開く場合はWear側からstartActivityさせる必要があります。 この辺りを最初知らないと戸惑いますが、DataApiやMessageApiを使うことで実現が可能になります。 今回実現した内容は 1. PendingIntentを仕込んだNotificationを発行(Handheld) 2. Wear側でのActionを受け取ってWearableとコネクションを張る(Handheld) 3. コネクション確立後にMessageApiを使ってWearableに送信(Handheld) 4. Wear側でメッセージ受け取ったらstartActivity()させる(Wear) 少し面倒くさい方法ですが、これくらいしか方法はなさそうです。 以下、一応サンプルコードです。 Handheld側 Handheld側からWearへ任意のパスを指定してメッセージを送る for (String node : nodes) { PendingResult<MessageApi.SendMessageResult> result = Wearable.MessageApi.sendMessage(mGoogleApiClient, node, "/start/SampleActivity" , null ); result.setResultCallback( new ResultCallback<MessageApi.SendMessageResult>() { @Override public void onResult( final MessageApi.SendMessageResult sendMessageResult) { if (!sendMessageResult.getStatus().isSuccess()) { Log.d(LOG_TAG, "send message failed" ); } else { Log.d(LOG_TAG, "send message success" ); } } }); } いろんなサンプルだと sendMessage().await() してるのが多いですが、await使えないときはsetRersultCallbackで実装しているonResultで結果を受け取ります。 Wearable側 Wear側ではパスで判別して処理を行います。 サービスかリスナーで実装しますが、ここではWearableListenerServiceを継承したクラス内でメッセージを受け取ります。 @Override public void onMessageReceived( final MessageEvent messageEvent) { Log.d(LOG_TAG, "onMessageReceived" ); if (messageEvent.getPath().equals( "start/SampleActivity" )) { Intent intent = new Intent( this , SampleActivity. class ); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); startActivity(intent); } else if (messageEvent.getPath().equals( "start/OtherPath" )) { // 他の処理 // ここからWear自身にNotification発行したり } } ちなみに、Handheld側とWearable側で同じkeystoreで署名しないとメッセージが届かないようで、少しはまりました。 それぞれのbuild.gradleで同じkeystoreを指定してしまえばOKです。 signingConfigs { debug { storeFile fle( ' キーストアのパス ' ) } } MessageApiではパスと一緒にbyte配列のデータを送信することができますが、 DataApiを使うとMapの形式で任意のデータの送信が可能です。 Wear側で出来ること onMessageReceived()やonDataChanged()で受け取ったデータをWearのActivity側に通知する場合、 受け取ったServiceからBroadcastを投げることで実現しました。 ほかにも方法はありそうです。 今回はとある場所までの道案内をカードでWear側で見せる機能があるのですが、 Activty側ではFragmentGridPagerAdapterを使用して、道案内のカードを表示させています。 また、SensorManagerも今まで通り使えるのでコンパス作ったり、自由にViewをカスタマイズすることも可能です。 ただあまり複雑なことをWearでやりすぎると、シンプルさが失われたり電池の消費が激しくなったりと、 よろしくないことがたくさんあるので、出来るだけ複雑な処理はHandheld側で行わせるようにしています。 全体を振り返り Android Wearで何ができるのかを模索しながら活動をしてきましたが、 なかなか良いものが出来上がりました。 やはり今までのAndroidとは使い勝手が違うため、 制約にはまったり、どういう見せ方がよいのか悩みどころがたくさんありましたが、 Android Wearがどんなものなのかがざっと理解できた気がします。 最初の方に書いた注意事項にもありますが、思ったより画面が小さいため見せたい情報を欲張りすぎると見づらくなるし、 複雑な操作をさせるとユーザは離れて行ってしまいます。 シンプル・簡単な操作でユーザの興味を引く、Android Wearを開発する上で一番重要になりそうだと感じました。 Android Wearはまだ新しい技術、これからどんな便利なアプリが出てくるのか楽しみです。 同時に、これからも便利なアプリをいち早く世の中に送り出していきたいと再認識させられた活動でした。