タグ:android ( 45 ) タグの人気記事

表題のとおりです。本日は台風で早期の帰宅許可が出たこともあり、代わりにこの記事を書いています。

ちなみに当日は余裕をもって現地に到着して資料を修正しようと思ったら乗るバスを間違えてしまい、最終的にやや遅刻で到着するハメになりました。バス1本遅れることになっても、ちゃんと確認、しよう!

Androidエンジニア デザイン部 #2 - connpass

話した内容に関しては、すごいちゃんと噛み砕いてまとめてくださった記事があるので発表資料とともに紹介しつつ、この記事では当日話さなかった補足部分などについて書きます。

ありがたいUIをもっと大事にしたい - Speaker Deck

Androidエンジニア デザイン部 #2に行ってきました | achanBlog


Getting Over It with Bennett Foddy
左からPC、iOS、Android版の周回数です。最近ベストタイムを見直したらまだ8分切れてませんでした。悔しい。いつか5分切れる男になりたい。

ちなみに作者のBennett FoddyはGoogle Designのインタビューにも呼ばれています。

Design Notes, Episode 7 - Library - Google Design


AndroidとiOSのデザインは合わせなくていいという主張
第三回で話す機会が出るかもしれないのでここでも割愛しますが、最終的に言いたいことは「Androidアプリを使うのはAndroid端末を触るiPhoneユーザーではないぞ」ということです。


「かっこいい」「美しい」「クール」なデザインについて
こうしたデザインを批判するわけではなくて、あまりにも酷いデザインは使うだけで苦痛を伴うことがあるので、決して無視していい要素ではありません。

この「苦痛を伴うレベル」というのは各ユーザーの主観によって決まる要素でもあるため、どこまで作り込めばいいかという難しさがあるのも事実です。


「※アイコンを除く」について
「ホーム画面を自分好みにカスタマイズしたい(整えたい)」という層は一定数いて、その層にとって見た目の良いアイコンというのは大きな価値を持つからです。

とはいっても、本当にホーム画面を整えるために配置している「だけ」ということもあり、その場合は本来私達が望んでる使われ方と全く異なってしまいます。それを許容すべきかというかという新たな悩みどころです。


Youtubeとマルチウィンドウ対応
これはYoutube側に大きな問題を感じるのですが、Youtubeはバックグラウンド再生をしてくれません。バックグラウンドになった瞬間に再生が止まります。

これは地味に辛い問題で、音だけでも聞こえればCMやら小休止が入ったタイミングでさっとメールやSlackやTwitterを確認するといった作業ができますが、音が聞こえないと気づかないうちに再開する怖さがあって、他のアプリが開けません。

ただこうしてマルチウィンドウ対応していることで、片方をながら観しながらもう一方の作業ができるようになるため、実はいままで利用時間帯で競合していた他のアプリと共存できる可能性すら出てきます。

ということでマルチウィンドウ対応に完全サポートしてくれとまでは(いまはまだ)言いませんが、せめて拒絶しない実装になって欲しいなあと最近思うようになりました。ちなみにニコニコ動画は拒絶されてしまうので、ここ数ヶ月でグンと利用率が減っています。

最後に
正直なところ、自分自身がデザインに関しては一定のルール(それこそノンデザイナーズ・デザインブックで書かれているような内容)や統一感が出ていれば、あまりデザインへのこだわりがないタイプという自覚はあります。

ただデザインというのは経験則として、どんどん世界観とかブランドイメージとか広い範囲に意識が行きがちで、状況によってはもっともユーザーファーストからかけ離れたところで議論が始まる可能性のある部分だという認識があります。

そういった中で、本来アプリは誰のために作っているものかという部分に立ち返るために、たまに「自分たちが触っているアプリには(直接コンテンツと紐付かない部分で)ありがたいと感じるところはあるだろうか」という部分にも目を向けてもらえると、多くのデベロッパーが求めているはずの継続率につながるんじゃないだろうかと感じました。
[PR]
by yamacraft | 2018-08-08 19:30 | 勉強会
この記事は、メルカリアッテ終了に関するブログ記事に触発されて書いたものになります。

http://mercan.mercari.com/entry/2018/03/19/121649

前書き
先月の某日、社内における業務(?)改善の一環として開発と運用をしていたプロダクトを終了しました。
今回はそのプロダクトで得た知見を共有します。

結論
* NFCわかんない…でもおもしろい…
* Androidビーム搭載しているかを調べるのが難しい…
* Androidビームを利用する非タブレット端末の設置ってどうすればよいんだろう…
* Android Things(Raspberry Pi)だといろいろ解決できたかもしれない

どんなプロダクトを作ったのか
現在働いている会社のオフィスでは、入室に某社のスマートロックを利用しています。
d0252816_16552848.png

スマートロックの解錠には、各個人のスマートフォンにインストールした専用のアプリを使います。このアプリが曲者で、一部の端末で正しく動作しなかったり、そもそもスマホにアプリがインストールできない方もいました。

この「アプリが正常に動作しない」社員がほかの手段を使って解決できるようにするために始めたプロダクトです。
社員のスマホに代わり、解錠を行う専用アプリがインストールされた端末を、入り口に設置して運用します。
d0252816_16555456.png

(自分を擁護するために突然書きますが、事前にこのシステム導入の検討を聞いていれば絶対に賛成しません。)

ちなみにこのプロダクトの簡単な説明は、以前にFirebase勉強会でも発表したことがあります

社内用アプリでFirebaseを使っている話 // Speaker Deck
https://speakerdeck.com/yamacraft/she-nei-yong-apuridefirebasewoshi-tuteiruhua

プロダクトを通して感じた問題点
あまりコード部分の技術的な話は書いていません。

NFCの何を一意の情報として取得すべきか判断しきれなかった
詳くないのであんまり解説っぽく書くとマサカリ飛んできそうなので詳細は書きません。NFCにも種類があり、本当に一意となる情報をどうやって取得すべきか正しく判断できませんでした。解錠のログはスタックさせていたので、とりあえず実装最優先でserialIdの値を使って識別するようにしました。

Androidビーム対応している端末がわからない
すべてのAndroid端末はNFCの読み込みに対応しているわけではなく、「Androidビーム対応機種」から今回のシステムに使う端末を選定する必要があります。

ここがとてもやっかいで、各端末の公式サイトを見てもAndroidビームが対応しているの判断できないケースが多くありました。結局今回はNexus5を利用することにしましたが、たとえば受付システムをタブレットにした場合、どれを選べばよいのか私は選定できる自身がありません…。

(実際に先日のDroidKaigiでKIOSK端末に関する発表をしたスピーカーの方もAndroidビーム付きの端末を対応したことがないと言っていました。廉価版ほど非対応な気がします)

スマートフォン端末を受付機として設置しづらい(NFC読み込みを使う場合)
スマートフォンのNFCリーダーは端末の背面に設置されています。そして、カードを認識させるためにはカードを接触させるぐらいには近付ける必要があります。

これがとても曲者で、多くのスマホスタンドはスマホの背面部がスタンドの支点となるように設置されています。つまりカードがタッチしづらくなります。

マイクスタンド的なものもいちおうあるのですが、これは大半がiPad用です。Androidタブレットに対応しているのかは、試しに買ってみないことにはわかりません。おそらくハンドセットサイズのスマホでは使えないでしょう。

Nexus5のBluetoothが頻繁に死ぬ
これは自分が使っていた端末固有の問題かもしれません。Nexus5を点けっぱなしで放置すると、Bluetoothの機能が死んでしまい、その都度端末を再起動する必要がありました。キオスク端末化しておけば、多少は再起動の対応も楽にできたのかもしれません。

プロダクトを通して感じたこと

Raspberry Pi+AndroidThingsだといけるのでは?
今回は既存のスマートフォン端末を利用する形で運用を行っていました。これをAndroid Thingsで動かしているRaspberry PiとUSBのNFCカードリーダーを使えば、もろもろの問題は解決できたかもしれません。これならすべて新規でそろえても10,000円から15,000円程度で用意できますし、何よりOSも常に最新で開発者のモチベーション維持にもつながります。

ただしこの場合、NFCカードリーダーの読み取りをちゃんとアプリ側で認識できるのか、ケース等をどうするかといった部分の課題は残ります。後者に関しては、みんな簡単にレゴとかで作っているケースがあるんですけど、幼少期にレゴとの触れあいがほとんどなかった自分にはまったくわからない世界です…。

ちなみにプロダクトを終了した理由は、上記の実運用を考える上で実験費用がどんどん掛かりそうなこと(注)。あとは諸々の理由です(ここには書きません)。

以上です。

(注)…自分が勝手に始めたので経費はポケットマネー
[PR]
by yamacraft | 2018-03-25 23:30 | いろいろ
d0252816_22330503.jpg


3月9日〜10日と2日間にわたって開催された、国内のAndroid開発者向け大型カンファレンス「DroidKaigi 2017」の二日目にて、『いまからはじめるAndroid 6.0対応 〜Android 7.0から8.xを見つめて〜』というタイトルで発表しました。

いまからはじめるAndroid 6.0対応 // Speaker Deck
(補足)サブタイトルがないのは、スライドのデザインの都合上です。

脳内のシミュレートでは20分でいい感じと思っていたら、実際は30分ギリギリでした。だいたい脳内シミュの1.5倍かかるという貴重な知見を得ることができました。

発表時にも触れましたが、コードを出した解説は今週中にQiitaの方で公開させていく予定です。いちおう発表後の反応から

1. Runtime Permissionを通常実装する場合とPermission Dispatcherを使った場合
2. Volley+GSONとOkHttp3+GSON、Retrofit+GSON

という順で公開していきます。あとこっちの方で(Qiitaだと技術系記事になってないので)なんであの3つを危ないと触れたのかも書きます。

それと今回の発表でもところどころでエモい感じのトークをしましたが、これには意味があります。

正直なところ、Android 6.0対応に必要な技術的な情報はもうかなりの量が投稿されているという認識があって、「やり方がわからない」で困ってる人はもうほとんどいないんじゃないかというのが自分の認識です。じゃあなんで6.0対応をしていないかというと、その必要性をチームだったり上司だったり、もしくはエンジニア自身が認識できていないのが一番の理由にあるんじゃないかと思ったからです。

今回触れた通信部分の変更とRuntimePermissionの追加は、前者は「ユーザーが変更に気づくことのない変更」ですし、RuntimePermissionは「エンジニアひとりだけでは進めづらい(周りの認識や協力が必要になる)変更」です。こうした変更は個人アプリであれば自身の意志で進められますが、仕事でチーム開発であれば自身からの提案が必要不可欠です。そしてこうした提案は、プロデューサー職やデザイナー職の方からされることはまずありえませんし、必要なことであればそれはきちんとエンジニア側から提案しなければいけないし、そしてこれは必要な提案であるということを伝えたいことで、あんな感じの発表になりました。

それと本当にWantedlyでスカウトメール取得可にしたときは、たくさんの企業からアプローチがありましたし、エンジニアの提案を尊重してくれそうな企業さんもいくつかありました。スライドの最後に「転職しよう」と書いたのは冗談ではなく、そのアプリに本気で人生を賭けるつもりがないのであれば、きちんと提案や相談を受け入れてくれる企業にいって、どんどんそこのアプリを良くしていってもらいたいです。みなさん、いいアプリ、作っていきましょう。

最後になりますが、当日参加した全ての皆様、スタッフのみなさま、おつかれさまでした。

[PR]
D.I.C. - Google Play の Android アプリ

思ったより時間(期間というより工数)がかかってしまった。あと今回気づいたけどストア掲載内容の反映、そしてAPK自体の反映がものすごく早かった。数分レベルで対応終わってた気がする。

前にも書きましたが、droidkaigiのネタとして「結局まだ6.0対応終わってないアプリってどんだけあるんだろ」というチェック目的で作ってました。そして(自分がインストールしてるアプリは)結構対応終わってるみたいですね。どんどん当日への責任感みたいな重さがなくなっていくので嬉しい…。

d0252816_19271871.png


20でのビルドって、Androidいくつになるんですかねえ。

[PR]
d0252816_19163045.png

droidkaigiの発表に合わせて、現行のアプリが果たしてどこまでtargetSdkVersionを上げているのかをチェックするためだけの機能の実装途中。取得はできたので、表示はCardViewとRecyclerViewとCordinatorLayout使うのが最近ぽい感じなんでしょうか。なんかどれも2年前感がすごいので「ホントに?」って感じになる。
とはいえ基本は自分の利用優先なので、まずは最低限のところから。あと実装に使ってるアプリがAPI17ぐらいの時代の産物だったので、ActionbarSherlockとか使ってて懐かしさがすごかった。

ちなみにこの機能はAppCheckerというアプリのリスペクトなわけですが、Android 7.0とかの対応を全然やってくれなくて(unknown表示されてしまう)、更新しないのかなあと思ってよく見たら去年末もなにかアップデートされてた。あくまでも6.0までのチェックだけなのか。男らしすぎません?

[PR]
by yamacraft | 2017-01-19 20:30 | 開発記録
d0252816_23421792.jpg

表題の通りです。DroidKaigiのトーク応募に2件応募して、うち1つが受かりました。

以下、受かった方のトークの詳細(応募当時)


『いまからはじめるAndroid 6.0対応 〜Android 7.0から8.xを見つめて〜』

知ってます知ってます。いまの最新版(droidkaigi開催当時)って7.1であることを。

とはいえAndroid 7.0対応の前にAndroid 6.0の対応が出来てないまま、誤魔化し誤魔化しアップデートを続けているアプリがあるんじゃないでしょうか?

いまはなんとかなっても、いつかはどうにもならず「苦渋の決断」をする日がくるのではないでしょうか?
本セッションでは7.0に向けた復習として、自分が業務で「いやここで対応すべきだ」と決断していくつかのアプリを6.0対応した際に得たノウハウを共有いたします。さあ、みなさんも早いうちに6.0対応を果たし、気持ちよく7.0対応を迎えましょう!

主に話す内容
* Apache廃止に伴う対応(さよならVolley、こんにちはokhttp)
* パーミッション対応と、コード以外に考えること
* その他、Android 7.0に加え、さらにその先のアップデートに備えて気をつけることはなにか


なんか無理やり7.0のワード入ってるけど、この内容って1年ぐらい話すの古くない?と思った方、正解です。 去年のDroidKaigiで応募するつもりだったネタです。

去年のDroidKaigiはちょうどいまの職場にジョインした直後の開催ということもあり、(そもそも入社時期もかなり無理なお願いをしたこともあったので)トーク応募も一般参加も不参加確定していたんですが、どうも去年はこの手の内容がなかったようだったのでせっかくだし応募してみた、という経緯です。なので受かった本人が一番驚いています。

トーク時間も30分で応募しているのでそんなに7.0とか7.1の話はやらず、本当に6.0対応の話ばっかりする予定です。

と、ちょっと採用されて困惑してる的な部分を出しすぎましたが(でも驚いたのは事実)、そもそもこういったレベルの「聞いた時点でマサカリで殴りつけられそう……でもなんとかしたい……つらい……」と悩んでいる人たちの手助けをしたいという思いが以前からあって、今回のdroidkaigiはとても良い機会に恵まれたなと思っています。あと4ヶ月ぐらい先の話ですが、当日参加されるかたはよろしくお願いします。


[PR]
by yamacraft | 2016-11-16 23:30 | いろいろ
d0252816_17391034.jpg

(DとかGIGAのシェア機能って、こうした使われ方も想定してた気がするけどどうだったか覚えてない。いまは一ユーザーなので、怒られたらこのキャプと同じリアクションをとることにします)

タイトルどおりですが、先週水曜日に行われたOtemachi Firebase #1に参加してきました。LT15分枠で、初の15分スピーカーでした。内容自体は先回の神泉Firebaseで発表した内容の修正版です。

Otemachi Firebase #1 - connpass

<資料>
Firebase crash reportの実践的導入 // Speaker Deck

今回は初の15分LTだったんですが、特に急いで発表したわけでもない状態で時間内におさまったので、最近の発表の成果がようやくでてきたなという感じでした。
ちなみに会場は日経ビルだったんですが、トイレがとても広くて素晴らしいと思いました。あとアルコール関連があんなに早く空になる勉強会は初めてでした(母数が少なかったわけではない)。

次回以降の勉強会参加は未定です(開催情報の収集に疎いので)。が、今後も月1〜2での参加を続けていきたいので、何かいい勉強会の情報があれば提供お待ちいたしております。
[PR]
by yamacraft | 2016-07-19 22:00 | 勉強会
表題の通りです。

potatotips #30 (iOS/Android開発Tips共有会) - connpass

<資料>
【プレゼン資料】FirebaseのAuthとは - Qiita

当初はDirectBoot周りを調べて発表する予定だったんですが、この機能エミュレータだと確認できない上に端末にやろうとすると端末リセットが必須らしいので諦めました。内容的にはかなり中途半端感があったので反省しています。
発表自体は8分ぐらい使ってしまったので良くなかった。あとFirebase UIの存在を教えてもらった。(これは下の勉強会でも紹介されてた)

神泉Firebase勉強会 #1 - connpass

<資料>
Firebase crashの実践的導入 // Speaker Deck
Firebase crashの導入Tips(Android編) - Qiita
Firebase crashとParseCrashReportingでduplicate symbolエラーが発生する - Qiita

こっちはじっくり時間使って調べつつ(完全とは言っていない)、余裕をもって資料を作れたのでかなり気が楽にやれた。
時間も「おまけ」までに10分消化したので、ちょうど予測通りにいけたかなという感じ。おまけ部分を含めれば15分ぐらいに抑えられそうな気がする。あとは色々ミス表記があったことに気がついた。

そして今週水曜日開催のFirebase勉強会でもLTするので、お手柔らかにお願いします。内容は神泉Firebaseのやや修正版です。
Otemachi Firebase #1 - connpass

あとHealth Hack Meetupにも(LT枠で)興味があるけど、流石に今月3回の勉強会参加はしんどいのでちょっと考え中。

Health Hack Meetup - connpass
[PR]
by yamacraft | 2016-07-10 22:20 | 勉強会
2016年6月9日に行われた「Android Testing Bootcamp #2」にLT枠で参加してきました。

Android Testing Bootcamp #2 - connpass

「Androidのテスト(+CI)環境からみの話題」ということだったので、個人開発環境の話をしてきました。

<資料>
個人的CIとテスト環境 // Speaker Deck

個人的Androidアプリ開発環境を晒す - Qiita

実は個人開発というか、プライベートなチームで作ってるアプリ開発環境だったりするんですが、実際に設計したりコードに落としこんだりgit触る人間は自分ひとりだけなので間違ってはいない。

LTに関しては「これ絶対に5分で終わらないなー」って思ったら案の定リリース前レポートのところで5分経ってしまったので、よくないなって思いました。

勉強会の会場であるVOYAGE GROUPは広いしタダで借りられるらしいし、ピザも無料提供してくれるらしく素晴らしいなあと思いました。
当初、配置でテーブル+椅子席ではなく椅子席のみに陣取ったところ、ピザが非常に食べに行きづらい状況になって辛い感じになり「辛い」と正直にツイッターで泣き言をつぶやきつつ「ピザ食べたい」とLTで発言したら終了後に余ったピザを持ってきてくれる方々がいて、VOYAGE GROUPありがとう……ありがとう……という感じでした。以上です。

発表内容に関しては「個人でちゃんと構築しててすごい」みたいなことを言われた気がしたんですが、これにはいろいろ理由があるんですけどそのうち書きます(逃げ腰)。

以上です。
[PR]
5月20日(金)に開催されたGotanda.mobile #1にLT参加しました。

Gotanda.mobile #1 in Mobile Factory - connpass

発表資料:
Firesideのcrashを試してみる // Speaker Deck

FirebaseのcrashとanalyticsをAndroidアプリで試してみる - Qiita

ちょうどGoogle IOの期間内に開催されることもあったので、Google IOで発表された内容のどれかをやろうという予定でいました(何もなければokhttpの再入門的な話にする準備もしていた)。

その中でFirebaseが一番興味惹かれそうだし、自分も興味があった部分なので、発表翌日(ただしくは当日)にさっと動作確認をしつつ発表資料をまとめました。時間的にcrashだけでも5分超える気がしていたので、発表資料はcrash、Qiitaにはanalyticsにもちょっと触れる感じの構成に決めました。

時間的には、かなり早口で進めたけどやっぱり1〜2分ほど押してしまったので反省。あと毎回keynoteのプレゼンテーションは終了するたびに経過時間がリセットされるのを忘れてしまうのでよろしくない。

crashはdependenciesに追加するだけで完了と言ってますが、本当にそれであってるか自信が持てなくてドキドキしてましたが、ツッコミもなかったので間違ってはいなかったようです。
ただこれってGoogle Play Service使ってる気がするので、非Google Play Service搭載端末だとどうなるのか気になりました。

そして5月25日(水)に開催されたpotatotips #29にLT参加しました

potatotips #29 (iOS/Android開発Tips共有会) - connpass

資料:
Multi-Window上での「共有」について // Speaker Deck

Multi-Window上で共有機能を使うとどうなるのか実験 - Qiita

こっちは以前から進めていたAndroid N Previewの知見をやろうと思っていました。実はPreview 2時代はエミュレータがWebView関連で落ちるというバグが起きていたので、最終的な調査ができたのは結構ギリギリでした。

内容としては非常にややこしいというか、自分でも資料作っててややこしくなってきたので資料を読んでややこしいと思ってしまうことに間違いはありません。
何が言いたいかというと、「マルチウィンドウは夢も持たせてくれないなんて……」ってことです。

次回は今週(LTに空きが出たら)shibuya.swift、あとAndroid Testing Bootcampに参加予定です。どちらもLT枠です。

ん、そういえばGoogleIOの感想記事書いてない。
[PR]
by yamacraft | 2016-06-05 23:50 | いろいろ