2017-07-09 に書いたとおり bouzuya/bs-android をつくりはじめた。
きっかけは bouzuya/bbna 以外の Android アプリをつくってみたくなったから。いくつか試したいことはあるのだけど、ひとつのアプリで試していると書いて消してになり、さみしい感じがする。実験場は多いほうがいい。
bs-android は bouzuya/bs の Android クライアント。これはメモ取りツールになる予定。 bbna は read only なので、今度は read / write なアプリにする。
他とデータを共有しないといけないので、保存先をローカルのみにするつもりはない。ユーザー別のデータを管理することになるし、ユーザーの認証・認可も必要になるだろう。こういうものをつくるのは大変なので、 Firebase を試したい。
bbna でまだ設定していない CI や ProGuard 、 Google Play App Signing なども試していきたい。
2017-W27 をふりかえる。
目標。
記事。
『ゼルダの伝説 神々のトライフォース』の代わりに『花火 (HANABI) 』で遊んでいる。わりと好評だ。ゼルダはライフ・装備が万全になったところ、残すは最後のダンジョンの残りとガノンだ。
bbna 1.4.0 に合わせて RxAndroid (RxJava) へ手を出している。 2017-07 の目標に合わせて新しい Android アプリをつくりはじめている。次もまた業務に振り回されそうではある……。
2017-07-03/2017-07-09
bbna は 1.4.0 (beta) を公開。シェアボタンと読み込みが表示されるようになった。
bs-android は新アプリ。 bouzuya/bs の Android クライアント。 bbna は read only なので、今度は write を含むアプリにするつもりだ。認証も必要になるだろうし、 Firebase を試しておきたい。また書く。
oikurs は完成しなかった bouzuya/oikura のようななにか。 Rust で簡単なスクレイピングをしている。前回の bouzuya/rust-example / bouzuya/gh-repos-rs と大した差はない。
Android アプリ、せっかくつくれるようになったので、いろいろつくっていきたい。
半年のふりかえりがきちんとできていない気がする……。ここに書くかは別として改めてやっておこう。
bouzuya/bbna 1.4.0 (beta) をつくった。
blog.bouzuya.net for Android - Android Apps on Google Play
bbna は blog.bouzuya.net for Android 。このブログの Android 向けのクライアントだ。
bbna の過去の記事は↓のとおりだ。
1.4.0 は↓の変更点は↓のとおりだ。
- URL を他のアプリへシェアできるようになりました
- 記事の読み込み中が表示されるようになりました
- 端末の再起動なしでも更新が通知されるようになりました
1.3 でブラウザ→ bbna という経路を追加し、 1.4 で bbna →他のアプリという逆向きの経路を追加した形だ。
内部実装としては ReactiveX/RxAndroid の採用が大きい。
これまでは AsyncTaskLoader を使ってきた。 LoaderManager 経由でのこれは Activity / Fragment と密に結合している点などで良くなかった。 Activity から Presenter へ LoaderManager を渡すと回避できるが、 Presenter が Android Framework に依存してしまう。それを隠したとして、 init / restart / destroy という操作やピンとこないコールバックに振り回される。メインスレッドとバックグラウンドスレッドの境界にこれを配置しないといけないという制約がつらかった。
RxAndroid は特に Activity などとは結びつかない。スレッドの違いは Scheduler で対応。良い。 Activity などのライフサイクルに合わせた dispose は必要だが、逆に言うとそれだけだ。そも AsyncTask -> AsyncTaskLoader をいまは失敗だったと思っている。 AsyncTask をラップした独自クラスを用意するほうが動きやすかったと思う。ちなみに AsyncTask は execute だと並行して処理できないし、再実行の注意などが必要なのでラップするほうが良い。極端な話、愚直に Handler と Thread (まわりの Java 標準クラス) を使った独自のクラスを持つと良い。 Rx を使うのはその代替のようなものだ。
RxAndroid は上記のようなスレッドまわりの都合もそうだが、 Fragment をまたがる状態の共有に良い。更新通知が流れてくる形だ。オブザーバーパターンを実装すればいいだけではあるが、いろいろな箇所ですこしずつ違うコールバックがあってつらくなる。慌てて共通化したら EventEmitter のようなものをつくってしまったところで、ぼくは諦めた。最初から素直に RxAndroid を使えば良かったんだ。
ちなみに Android Architecture Components | Android Developers として更新通知を流すような仕組みは導入されるようだ。もう標準はどうでもいいという気持ちになっているが……。
RSpec では似たような context を共有するために shared_context というものがある。 include_context を呼び出すことで使えるのだけど、ほかにも方法があることを知った。それがメタデータとして指定する方法だ。
RSpec 3.5 から現在の記法になっているらしい。
http://rspec.info/ja/blog/2016/07/rspec-3-5-has-been-released/
分かりやすくないけど、公式にも例がある。
RSpec.configure には触れられていないけど、メタデータとしての指定がほしくなる経緯については↓が分かりやすい。
http://qiita.com/aereal/items/4c42f8e470ba6e061d40
↓のような雰囲気だ。
# spec/support/contexts/context1.rb
shared_context 'context1', context: 1 do
let!(:params) { 'baz' }
end
# spec/rails_helper.rb
# ...
Dir[Rails.root.join('spec', 'support', '**', '*.rb')].each { |f| require f }
# ...
RSpec.configure do |config|
# ...
config.include_context 'context1', context: 1
end
# spec/models/foo_spec.rb
require 'rails_helper.rb'
RSpec.describe Foo, type: :model do
describe '#bar' do
context 'context1', context: 1 do # メタデータで include_context 'context1' を代替
# params は 'baz'
# ...
end
end
end
2017-07-04 以来、花火 (HANABI) を何度か遊んでいる。初回は参加しなかったが、その後は妻も参加している。記憶力のなさを痛感する。ミスを重ねている。
協力するゲームだから良いと思いがちだけど、ミスをした味方を責める形になることもあり、直接的に競争するときとは違うやりづらさがあるかもしれない。
bouzuya/bbna の通知が来ない。1.3.1 で Service での inject に失敗している点は直したが、まだ来ない。 blog の更新をなまけているせいかと思ったんだけど、どうも怪しい。
AlarmManager で毎朝 07:00 頃に更新を確認するはずなのだけど、動いているのか、よく分からない。そもそも、 Broadcast Receiver で端末起動時しかアラームを設定していないので、それがまずいのかもしれない。アプリの起動時にもアラームを再設定するようにしてみる。
『ゼルダの伝説 神々のトライフォース』の進捗。最後のクリスタルを手に入れた。あとは最後のダンジョン・ボスだけだな。拾いそびれたアイテムを探しに行っても良さそう。
定期の散髪。前回は 2017-06-21 。
テーブルゲーム『花火 (HANABI) 』を遊んだ。
今日は『ゼルダの伝説 神々のトライフォース』はおやすみして『花火 (HANABI) 』で遊んだ。ひさしぶりのテーブルゲームだ。
ルール。
『花火 (HANABI) 』は 2 人〜 5 人の協力ゲー。目的は 5 色の花火の完成。 1 〜 5 の数字の書かれたカードが各色 10 枚ずつ、計 50 枚ある。すべての花火を 1 から昇順に 5 までを場に並べることができれば完成だ。
手札から順にカードを出して上記の目的を目指すのだけど、重要な点として「自分の手札を見てはいけない」。他のプレイヤーだけに見せる形で持ち、教え合いながら花火の完成を目指す。
各プレイヤーは自分の手番で 3 つの行動を選べる。「出す」・「教える」・「捨てる」の 3 つだ。これらの行動には制限がある。3 つの赤いコインと 8 つの青いコインでそれを表現する。
「出す」は先に書いたとおり、花火の完成を目指すための行動だ。場に出ているつくりかけの色の花火に続くかまったくつくられていない色の花火の 1 を出せなければ、赤いコインをひとつ失う。
「教える」は誰かの手札の色または数字のどちらかを教える。特定の一枚ではなく、手札全体について教えなければならない。たとえば「これとこれは赤ですよ」などだ。青いコインをひとつ失う。
「捨てる」は手札を捨てる。青いコインをひとつ得る。
すべての色の花火が完成すれば完全勝利。赤いコインがすべて失われれば即終了・得点計算。山札がなくなれば、最後に一周して得点計算。
結果。
17 点。コインについてのルールを間違って遊んでいた気がする。
なぜか記憶力を問われていた。あれ、ここに持っていたはずなのに……のような。カードを同じ位置で持ち続けているのがつらいので、カードスタンドがほしくなる。
どのカードが何色で何番なのかもそうだけど、「なぜいま教えるのか」という情報もわりと重要だ。明らかなときもあるが、理由の分からないときもある。また教えたいタイミングに限って、余計な色・数字が混じっていたりしても全体を教えないといけないのがもどかしい。
教え合いが組み込まれているものの、会話を楽しむゲームではない。空気を読み、読ませる感じ。「(これを教える理由は)分かるよな？」的な。
もう一度やりたい。
妻は参加してくれなかった。一緒に遊べる形を模索しての取り組みだったはずなんだけどな……。
