oyuugi-level-no-programming

[oyuugi-level-no-programming]

プジョーRCZ インプレ：7年ぶりに車を買ってみた。

本来であれば10年前に買っていたはずだったプジョーRCZ、金額や程度、仕様等々諸々条件が噛み合った中古車が見つかってこの度購入する運びとなった。

あらすじ

思えば2007年、まだコンセプトカーだった頃から日本に導入された瞬間にでも買うつもりだった。建前上「市販化の予定がない」なんてアナウンスされていたけれど、どの雑誌もその完成度からいずれ近い将来に市販する前提で記事を載せていて、事実翌年プジョーからも正式に市販化が発表された。けれでも、2010年、まだ少しだけ遠い。当時同じプジョーの206RCに乗っていたが他の206とは違う乗り味に違和感を感じ続けていた。事前予約までして手に入れたのだから良い車だとは思いたいし、回せば「パオーン」と気分良くエンジンは吹け上がるわけだけど、日常の運転で普通の道路の緩いカーブをまるで鼻先を外に向けたまま旋回する感覚が、説明しづらいのだけれども最終的に手放すまでずっと違和感に感じていた。正直不愉快だったし、車を運転する行為自体が少し嫌になりかけた。いや、もっと運転は楽しいものだったはずだ、なんて運転中の頭の中で弁明してみたりした。あの不快感はもしくは、その前にたった1ヶ月半であおり運転を受けた結果廃車に追い込まれた206 S16の、美化された亡霊じみた記憶を引きずっているだけなのかもしれない。 そこで、うんざりしていた206RCからRCZに移行する間の繋ぎとしてアルファGTVに乗り換えることにした。モデルライフの最後の1年だけ新車で売ってたツインスパーク仕様で、当時3年落ちの中古車。正直、運転ってやっぱり楽しいよね、って心底感じた。品質の高い車、性能の良い車は山程あるかもしれないけれど、自動車をエンターテイメントとしてみた場合にGTVより楽しい車はないんじゃないかと今でも思う。リヤがロールで沈み込んで車の向きを変えて、まるでコーナーのクリップポイントに絡みつくような回頭性、V6ならもっと官能的なエンジンを楽しめたのかもしれないけれどフロントヘビーな分あの旋回性能はないんじゃないかと想像する。 結局あれほど買う気マンマンだったRCZよりGTVを乗り続けることを選んでしまった。RCZをディーラーで試乗してみたけれど、GTV比なんだか室内がだだ広くてエンジンも乗り味ももっさりした印象しか残らなかった。ついでにその直後会社を辞めてしまったので経済的にも新車を買うなんてそもそも不可能になってしまったし、無職じゃ車を維持することすら困難で7年前にGTVも手放すことになった。

その後両親から懇願され実家に戻り、東日本大震災で傾いてしまった古いアパートの建て替えをして、残りの不動産を含めて大家業を引き継いて、それから胆嚢癌に罹った母の看病に専念して、母が亡くなった後は掃除と洗濯まではできても、炊事と、冠婚葬祭や公的手続きを理解しない父の面倒をみることになった。元々は会社を辞めて5年間くらいは個人でアプリ開発をやってみて、それからフロントエンド寄りの会社に再就職できればいいな、なんてふんわり考えていたのだけれど、母の病が発覚した時点で諦めた。

経緯や事情はともあれ、傍目からは仕事もせずに親のスネをかじっているようにしか見えない状況、しばらくは車とは無縁の生活が続いた。 母が亡くなってからしばらくして、気晴らしにタイムズカーシェアでデミオを借りて運転してみた。運転ってほんと楽しいよね、って再び心底思った。最終的にはステージ3になるまで利用して、結局やっぱり自分の車がほしいよねってことになり、今回のRCZの購入に至った。

と、インプレの前にごちゃごちゃと余談を記してきたのだけど、今回RCZを購入するまでの経緯は以上の通りとなる。ひょっとしたらどこかで割と湿っぽい内容が見え隠れするしてしまうかもしれない。なんせ母の遺産の一部を使わせてもらって購入したわけなので。。。

前提として２点を挙げる。 １つ目は、評価の基準として前車のアルファGTVがまず念頭にある。加えてカーシェアのデミオや、昔3台乗り継いた206の各種グレード(S16・XS・RC)、さらにはRCZのプラットフォームの大本となるプジョー307を試乗した際の記憶も交えて記す。 ２つ目として、今回購入した右ハンドル・ATより、左ハンドル・MTの方がどう考えたって運転中のストレスが少ないだろうな、という点。それを知りつつ今回右ハンドル・ATを選択した理由は、生前母が「いい加減ATにしなさい」とよく口にしていたからで、MTよりATの方が安全だと信じていた母の意向を今回遺産を使わせてもらうのに汲み入れた。とはいえ、カーシェアのデミオのおかげでだいぶAT(の主にマニュアルモード)に対する違和感は払拭できていたので別に妥協したわけでもない。MTもATもそれぞれ利点があるとした上で、母の件で今回はATを選んだというだけだ。ただし、デミオ、というより今のマツダのATのマニュアルモードはとても洗練されたものだった。RCZのそれはマツダと比べて大きく見劣りはする。

外観

RCZの外観に関してはもはや語るべきことはない気もする。初見の感想は「CCぽい」だった。個人的に、如何にもスポーツカー的なロングノーズで低いデザインより、ややキャビンフォワード気味で塊感のあるRCZのような車の方が好み。 昔プジョーのディーラーでGTVとRCZを並べてみたことがある。その際思ったのは意外にも、普段あれだけワイドに感じていたGTVが小さく見窄らしく、反面RCZは膨張して大味に見えたという、それぞれちょっとネガティブな印象だった。これは、個々の車単独では完成しているデザインであっても、比較論的にはマイナス点ばかり目についてしまったからそう感じたのかもしれない。そういった意味ではやはり両者とも純粋に格好いいとか美しいとかでは括れない個性の塊であり人を選ぶ車なのだろう。

尚、デザイン上アクセントになっているアルミナムアーチだが、経年劣化により表面に白くウロコがこびりつく。納車時に研磨してもらったが結局一ヶ月程度でウロコが浮き始めてしまっている。青空駐車だからしょうがない点もあるがこれに関しては目をつぶって見ないふりをするしかないのかもしれない。

内装

原型となる308の時点で十分にモダンかつスマートな造形のインパネ・ダッシュボード周りだし、革張り(今回のものはベースグレードなので合皮)とアナログ時計の組み合わせは見た目に十分高級車然とした印象ではある。が、ドライバーから見えない部分、あまり日が当たらず暗い部分に関してはプランス車らしいシボの粗いプラスチックがむき出しになっている。見た目的には気にならないが、例えばステアリングコラムのプラ部分の塗装が劣化してベタつくといった、如何にも一昔前のラテン車的な問題が生じているのに納車してから気づいた。あと姿勢を変えるとシートの軋む音が聞こえてくるのもちょっと気になる。この辺は単に7年落ちの車だからしょうがないのかもしれない。ただし、窓ガラスがガチャついたりボディの軋む音が聞こえたりとかは今のところない。

ドアが重い、というのはRCZのインプレ記事では必ず触れられる点ではあるが、それでも想像以上に取り回しが困難に感じる。それは、ドアハンドルがドアの付け根寄りに配置されているのも一因で、例えば右手でドアハンドルを開けるときに肘だけだとドアを支えるのがちょっとつらい。片方の手でドアの後端を支えながらハンドルを引かないと重量に負けるか、勢い隣の車にドアパンする羽目になる。また、閉める際もアルミ調?の持ち手は華奢だし、外からドアを開く際もアウタハンドルから今にも壊れそうな脆さを感じる。実際は問題ない強度なのかもしれないが。 この手の車としては意外にもフットレストがついていない。左足を置く部分はカーペット地がむき出しになっている。ついていないのは多分左ハンドルの部品をサイズ的に流用できなかったからだろう。この辺未だに右ハンドル軽視は根強い。

シートに関してはあまりいい印象はない。長時間乗っているとお尻が痛い。少々クッションが薄すぎるのではないかと勘ぐりたくなる。この辺はプジョーらしくもない。腰についてはランバーサポートを調整すればフィットして疲労感は少ない。 その他ステアリングホイールやシフトレバーは違和感なく操作できる。ステアリングホイールはマイナーチェンジで左ハンドル・MTと同様の小径のものに変更されているが、ハンドルを押して回すタイプの人であればより操作しやすいかと思う。ただし、下部が切り取られているD型の形状のため、交差点で大きくハンドルを切ると空振る感覚が慣れるまではある。シフトレバーは左ハンドル用のままなのでマニュアルモードへ切り替えるのに助手席側へ倒す形となるが、遠すぎて届かないといったことにはならない。位置としては問題はないがシフトフィールには強い癖がある。詳細は後述する。

細かいところだが右ハンドル化の弊害として先に挙げたフットレスト以外に、カップホルダーに500mlペットボトルを置くとシフトレバー操作時に肘が当たってしまう点がある。これはセンターコンソールにカップホルダーがある車に共通する問題ではあるが、RCZの場合カップホルダーの位置がサイドブレーキの右側であるため左ハンドルであれば干渉が少ないはず。これがあまり問題点として挙がってこないのは、シフト操作の頻度が多いMTは左ハンドルのみで、右ハンドルはATだから運転中シフトレバーに触れない人間が多いからなのかもしれない。ATでもマニュアルモードを常時使う人間は、ペットボトル置き場を別途用意するか、350ml等の背の低いボトルの飲み物を購入するよう気をつける必要がある。ちなみに僕は、普段は厚めのボトルカバーに入れて助手席に立て掛けておいて、助手席に人を乗せている場合はドアポケットに無理やり押し込んでいる。その他カップホルダーに関する不満点としてよくWebで見かけるのはアームレストを前にずらすと上に被さるところだが、そもそもアームレスト自体信号待ちくらいにしか使う機会がなく前にずらさないので個人的には気にならない。

全般的につい減点よりの評価となってしまったが、「2010年代にもなればプジョーも質感が大きく向上してるんだろうなあ、一応高級車的ポジションだし」という期待感が強すぎたせいだろう。それでも例えば、右ハンドルはもとより左ハンドルでも全体的に窮屈だった206に比べればシート以外は快適ではある。よりハードな仕様なはずの206RCより路面の突き上げが強く感じるのはシートのクッションの差なのかもしれない。ひょっとしたら革ではなくファブリックであればまた印象が変わるのかもしれない。

エンジン・トランスミッション

心情的な理由以外に今回積極的にMTよりATを選んだ理由は実はエンジン出力の差にある。基本は同じエンジンで日常域にそこまでの違いはないだろうし、それであればハイスペック版よりロースペック版の方が部品に対する負荷が少なくて部品代等も安価なのではないか、といった素人的憶測がまずあった。現実タイヤに関しては19インチよりも18インチの方がそれなりに安く交換することができた。後は「もういい年だしあまり飛ばさないようにしよう」という自戒もある。 156PS版のエンジンは、高回転まで淀みなく回るけれども加速感は乏しい。早く走るだけであれば4000rpm超えたあたりでさっさとギヤを上げた方がいい類のエンジンではある。そもそもマニュアルモードでも最高出力がでる6000rpmまで回る前にATがシフトアップしてしまう。マイナーチェンジでAT車にもMT車と同じく「サウンドシステム」が導入されていて、3500rpmあたりで音がそれっぽくなる。賛否両論あるが、個人的にはこのくらいの演出がないと外観のインパクトに釣り合わないのでアリだと思う。ただし2速で回転数を維持したいケースだと少々雑味があって喧しくは感じる。低回転域もトルクフルというわけでもなく、例えば3速1500rpm付近でアクセルを踏み込んでも加速までにかなりもたつく。

ATについて、Dレンジは若干変速ショックを感じることもあるが、加速時にむやみにシフトアップせず適度に低いギヤのままエンジンを引っ張ってくれるのでごく一般的な道路状況であればストレスは少ない。SモードはDレンジに比べると不自然で、道が混み合うと無駄に2速を維持し続け、道が空いてアクセルを踏んでも4000rpm手前あたりであっさりシフトアップしてしまう、というような中途半端な挙動をする。正直マニュアルモードを常用しているせいもあって使い所がいまいち見つからない。Snowモードに関してはそういった状況にまだ陥ったことがないので割愛する。 マニュアルモードは常識的なタイミングであれば変速自体はそれなりに早いが、エンジンの回転数が合わないとレバーがゲートに入らないことすら多々ある。MTであればアクセルを吹かすなりダブルクラッチなりを使えばいいだけの話なのだが、ATの場合はそうはいかない。一応シフトチェンジのタイミングでアクセルを更かし気味に入れると変速を受け付けてくれやすくはなる。その反面適切なタイミングでシフトチェンジを行うとまるでMT車のようにゲートに吸い込むかのような感触があり、その後の適度な変速ショックと合わせて小気味よさがある。このマニュアルモードでの変速の気難しさが問題になるのは渋滞時で、さっさと上のギヤに上げようとしても変速できずに1速のままエンジンを無駄に吹かしたりする羽目にしょっちゅう陥る。なので、普段マニュアルモードを常用しているとしても渋滞時だけはDレンジに入れた方がストレスは少ない。また、逆に高回転域での変速もあまり上手ではない。2速で5000rpmを少し超えたところでシフトアップしようとすると、3速に切り替わるのに体感1秒くらいのタイムラグがある。さらには3速3000rpm強あたりでシフトダウンしようとしても同じようなタイムラグが生じたり最悪操作を無視してくることがある。 RCZのATのマニュアルモードでも感覚的にMTの7割くらいは違和感なく操作はできる。が、残り3割を元々MTに乗り慣れている人間がどう感じるか、そもそも「違和感」なんて言葉を用いる時点でMTに乗ればいいのではないか、という話になりがちで、RCZに乗るならやはりMTがおすすめということになる。ただ、個人的にはこのATの癖は嫌いではない。その癖はよりMT的で、MTでクラッチやアクセルを操作してシフトチェンジする「手間」から生じる快感とベクトルは似ていると思う。

乗り心地・コーナリング

乗り心地について納車されてから1000km程度までは印象が一定しなかった。納車直後は露骨に固い、というより突き上げがボディブローのように分厚く内臓に来るレベルだった。それから200km程度走ったあたりからだいぶマイルドになっていき、タイヤをミシュランPilotSport4に変えた直後はもはや柔らかいと感じるレベルまで変化して、タイヤの慣らしが終えて空気圧を再調整した現在はやや路面からの突き上げを感じる程度に落ち着いている。今後どうなっていくかは様子見ではあるが、現状であれば「スポーティ」という範疇に収まる程度だとは思う。ただ、路面からの突き上げは時期により変化していったが、ボディから軋みを感じないのは一貫している。なので、強烈な突き上げがあった時期でもさほど不快には感じなかった。 あのタイヤの太さを考えれば当然だといえるが、轍の影響は非常に受けやすい。タイヤを変えてからは大分マイルドになったが、普通の幹線道路でもちょくちょくハンドルが取られるし、そういった路面で少し強めにブレーキを掛けるとステアリングが左右に振れることがある。

コーナリング性能についてはサーキットを走るわけではないので、日常生活で遭遇するややきつめのカーブでの印象を述べる。納車当初の印象としてはあまり曲がりたがる車ではないように思えた。旋回中もイメージより外に膨らんでハンドルを継ぎ足すことが多かった。が、これは単に車に慣れていなかっただけの話で、ステアリングをやや多めに切るよう意識することでイメージ通りに旋回してくれるようになった。違和感の大本は、中立付近からの初動におけるステアリングからのフィードバックが希薄だったからで、確かに車は向きを変えているのに無感覚だからこれ以上ハンドルを切って大丈夫なのか無意識的に躊躇していた。その無感覚な中立付近を一歩越えて切り込めばステアリングからの手応えが生じる。そうなればあとはアクセルワークで安心してコーナーを抜けることができる。 ロールはほとんどない。が、旋回中の車の動きはとてもスマートで、外輪側の前から後ろへ荷重が移動していく様子がよく感じられる。これはRCZのプラットフォームの大本である307を試乗した際に感じた印象にも通じる。言葉としての妥当性はさておき俗に「ニュートラルステア」と評されるものなのかもしれない。かつてのプジョーファンからサスペンション形式が変更されて何かと疎まれがちな307ではあるが、個人的にはこれまで乗ってきた車の中でも特に印象深い一台だったから、その末裔のRCZに同じものを感じることができて懐かしくもあり、少し嬉しくもある。思うに昔のプジョーを懐かしむ人にとっての「プジョー」には、リヤサスがコーナー時に沈み込んでロールし旋回姿勢を作るイメージがあるのだと思う。そう考えるとむしろアルファGTVの方がRCZや307より「プジョー」らしいといえなくもない。こんなことを言うとアルフェスタが怒るかもしれないが。

尚、純正タイヤであるコンチSportContact3は横方向のグリップ感が強く、旋回時にリヤのサスペンションがじわっと沈み込む感覚があったのが印象的だったが、PilotSport4に変えてからはそうした感覚は希薄になった。これをもってこのタイヤが駄目だとはいえないが、現時点では純正タイヤの頃の挙動のほうが個人的な好みではある。

その他

デビューしてから10年前の車なので、当然今流行りのCASE的な装備とは無縁だし、それどころか他メーカーであれば当時でも標準装備になりつつあったアイドリングストップやエンジンスターターボタンなんてものも存在しない。一応普通のクルーズコントロールはついている。コーナーソナーはてんこ盛りで少し狭い場所で切り返しを行うとまるで今どきの車のようにピーピー鳴り出したりする。ディーラーオプションのカーナビをつければバックモニターも使える。その他206の頃からあったオートワイパーに加え、最近義務化されたらしいオートライトもついている。 トランクはたしかに広いが、車の用途的にどの程度有効活用できるかは疑問。荷物は積めても車の幅が広くドアも長いから、スーパーやホームセンターの狭くて込み入った駐車場は心情的に避けたくなる。自転車であれば前輪を外せば積み込めそうだからアウトドアとかには便利なのかもしれない。

[oyuugi-level-no-programming]

センチな気分なのでサ終したソシャゲのことを語ってみる。

昨今、内外的にもろくなことがない。 ろくでもないことばかり続くと人は昔の記憶を白昼夢的に追体験したりする。

ということで、昔やってた今は亡きソシャゲのことを語ってみる。もちろん読んで興味を持ってもすでに存在しないのでプレイできないし、そもそも人の興味がなくなったからこそサービス終了に追い込まれた訳でもある。たまにちょっとだけ10分くらい遊んでみたいと思っても叶わないソシャゲの宿命が恨めしくもある。

あやかし陰陽録

アメリカのソシャゲ大手であるzyngaの日本法人が運営していた、当時あちこちで増殖した進撃のうんちゃら風ソシャゲ。でもBGMやイラスト、キャラクター等のゲーム性以外の要素は非常に良かった。今でもイラスト集とかサウンドトラックとか発売されるんなら予約して買うくらいには気に入ってた。 所謂ポチポチゲーの典型なのだけど、この手のゲームに初めて触れた身としては色々考えさせられることもあった。過去にもソシャゲについては色々記してきたが、その記事における「ソシャゲ」は実はこのゲームのことだったりする。

結局最終的に10万円程度課金して、最高レアの☆5は3枚、しかもそのうち2枚は過去イベントでしか価値のない、おそらく当選確率が高いやつだろうと思われるので、実質的にはたった1枚だけ。たちが悪いのはExcelでガチャ確率を集計したら数値上概ね妥当だという事実。まあ当時は会社を辞めて退職金その他で余裕があったわけで今とは「10万円」の重みが違いすぎるしもう二度とあんな無駄遣いはできまい、、、なんて思いつつ数年後某聖杯から嫁王呼び出すのに同程度費やしたりしてるので、ああ、黒い歴史は繰り返すんだなってつくづく思ったりする。

zingaの業績不振から日本法人が撤退、中国法人?に運営が移管したのが原因か、日本語訳がとち狂ってキャラ崩壊を起こしたり、レベルアップ時に対戦相手リストに優先して晒されるようになったせいで他プレーヤーからレイプ紛いにタコ殴りにされて有り金全部持ってかれたり、そもそも対戦バランスが攻め側優位だったのがキャラインフレのせいで完全にゲームとして成り立たなくなったり、課金単価の安い中華プレーヤーがイベントランキングを独占して微課金程度じゃ完走すら怪しくなったりで、辛くなって止めた。パズドラといったまともにゲームとして成立しているソシャゲが出てきたのも今思えば止めた一因な気もする。当時のパズドラは確かに覇権をとるにふさわしいよくできたゲームだった(過去形)。

その後もわりと続いていたみたいだけれども人知れずサービスが終了していた。 現在、メインイラストレーターをそのまま採用して世界観も共有してるっぽい「陰陽おとぎソール」が稼働しているが、崇徳院や酒呑童子といった前作でそれなりに存在感のあったキャラクターすら別物になっているのが個人的に受けつけなくてプレイはしていない。

ファイナルファンタジータクティクスS

GBAのFFTAの世界観を引き継いだ、スクエニが乱発しているFF系ソシャゲの一つ。通称FFTS。サービス開始当初は「ガチャが存在しない」ソシャゲであることを強くアピールしていた記憶はある。もちろん半年後にはそんなものは夢物語でしかないことが証明されてしまうのだが。結果1年ほどでサービス終了に追い込まれてしまった。

個人的にはFFTSこそソシャゲにおけるPvPの完成形なんじゃないかなと今でも思っている。とりあえずデッキ構築しておけば指定時間に自動で対戦相手をマッチングしてくれて後から結果を確認できる、というのは、例えば日中時間の取れない社会人からしてみればフェアな条件だと思う。デッキ構築に関しても三すくみや相性で決まる単純なものでもなく、3x3のマスに配置するユニットを、相手のどこに攻撃を集中させるかを仮想敵を想定しながら考える、といった形でそれなりの戦術性の高さがある。さらにはコスト上限が70までしか上がらないので、9マスユニットを埋めるには低コストキャラを活用する必要がある。

ゲームシステムとしての難点は、同キャラを複数体組み込めるところと、行動順に揺れがないため番狂わせがクリティカルとミスに期待するしかない点。前者はサービス開始直後にロキ&ルアやゼフォーが大量発生したくらいでまだマシだったが、後者に関しては稼働半ば辺りからの神のカカトさんからのネイムレスダンスが跋扈して割と洒落にならなかったらしい。その頃は既に真面目にやってなかったのでよく知らないが。それから半分言いがかりだが、味方が9体中7体ミスで相手は全員クリティカル出してきたのには流石に課金補正を疑った。

最終的にはインフレと「耐性無効貫通」問題によってバランスはとことん破綻した。 サービス開始直後からして賢者と毒バラマキの耐久パみたいないやらしい編成が跋扈していたが、個人的にくじけたのは、単体物理攻撃を一定確率(割と高め)で(物理防御がやたら高い)自分自身でかばった上カウンターまでしてくるキャラをイベントドロップでばらまいたとき。これまでメインで使ってきた弓使い系がこれ一体で完全に産廃化した。さらにはその直後に「かばう」無効を持ったキャラを、召喚チケットとかいう実質的なガチャで出してきたのには思わず苦笑いでブラウザをそっ閉じするしかなかった。

FFTSの商業的な敗因の一つは、FFTAの世界観をベースにしているところだろう。やはりFFTといえば初代のイメージが強く、FFTSにもそれを期待した人間は多かったはず。事前登録の特典からしてアグリアスだったし。予算がなかったから設定的に絵を使いまわししやすいFFTAベースの世界観を利用したのかもしれない。クリスタルディフェンダーズとかもあったし。僕自身はむしろパズドラのCDコラボから入ったので織り込み済みだったが、仮にCDコラボでFFTAのキャラを知らなかったらFFTSをプレイすることはなかったとは思う。 ちなみに今FFTコラボで集客してるFFBE幻影戦争は、ちょっとだけ興味はあったりだけど、課金ゲーらしいから遠巻きに見てる。

それはさておきFFTSの失敗にはソシャゲに対する開発側の潜在的な思い違いが垣間見れる。

１つ目は、どんなにゲームのシステムやルールが優れていてもアップデートによってゲームバランスが崩れる、という点。それでも例えばパズドラのようなゲームであれば性能がインフレしてもこれまでのクエストの難易度が落ちる程度でまだ済む。が、PvPメインのゲームでは壊れキャラには同じ壊れをぶつけるしかなくなるのでデッキ構築というゲームの根幹部分が成立しなくなる。

２つ目は、プレーヤーが思っていた以上にPvPを好まないという点。より正しく言うのであれば他人に負けることが何よりも嫌だという感情論。なのでFFTSのメインコンテンツにもかかわらずクラン戦を放棄しているプレーヤーも散見した。とはいえFFTSもその点は考慮していて、例えばあやかし陰陽録のように負けたらアイテムとお金を強奪されるといったペナルティは一切なくして、敗北時の負のイメージを払拭しようとした。買ったらもちろん、負けても報酬が入ってお得といった形で。それでも「負けるのは嫌」という感情論が勝ったのは想定外だったのだろう。 ちなみに「負けても損をしない」路線はさらに延長線上に、プレーヤー側である攻め側のみ数値的に有利補正を受けて、負けそうになったらペナルティなしでリトライ可能、防衛側は敗北どころか攻撃を受けたことすら一切の履歴を残さない、といったアズールレーンの演習まで行き着くことになった。もちろんここまで来るともはやPvPとは言えない気もしなくもない。

３つ目は、ソシャゲのユーザーと、旧来のゲーム機のユーザーとでは、似て異なる存在だという点。有り体に言えばソシャゲのユーザーは頭を使いたくない人間が多いし、ゲームに頭を使��時間もない人間もまた多い。。そういったユーザーに対し、普通の据え置き型のゲーム機でプレイするような代物を渡しても面倒臭いだけだろう。どうやら運営も途中でその辺りに気づいてらしく、ダンジョンの道中を完全にポチポチゲーに仕様変更してきたりした。あまりにも雑な変更で苦笑するしかなかったが。

FFTSにはアプリ開発者としても思い入れがあって、実は専用ブラウザという体でアプリ内メニューの改ざんツールを公開していた。 ガラケー向けモバゲーのプラットフォームを無理やりスマホ向けに流用したからか、サーバーへのリクエストは全てクエリパラメータで丸見えで、かつ戦闘画面以外は普通にHTMLでレイアウトされていたため、WebViewを用いれば簡単にいじることができた。最終的にGoogleからなりすまし扱いでBANされてしまったが、その一ヶ月後にはサービス終了がアナウンスされたから特に実害はなかった。初のBANによる精神的ショック以外はね。 まあ、一歩間違えば著作権侵害でお縄になる実例も出てきたので、笑える昔話程度で済んでほんとよかった。

あと、ロードラについても記そうかなって思ったけどメジャーだからみんな知ってるよね。つい先日コンプリートデータブックとかも発売されたし。

[oyuugi-level-no-programming]

Amazon Echoで音楽を(とりあえず)フェードアウトさせる。

Amazon Echoで現在再生中の音楽をフェードアウトしつつ一定時間後に止める、みたいな制御ができないかとWeb等を調べたところ、参考になりそうな情報がなかったので対処方法をまとめてみる。なお、完全には実現できずあくまで暫定対処となる。

やりたいこと

就寝時にAmazon Echoで音楽を流す使い方で、次のような使い方をしたいと考えた。ちなみにEcho Inputなので、いずれかの外部スピーカーとの接続が必須となる。

再生スピーカーをAUXよりBluetoothスピーカーに切り替え。

Amazon Echoのボリュームを就寝時向けのレベルに変更する。

Amazon Musicのライブラリの内容をランダム再生。

一定間隔ごとにボリュームを絞る。

1時間ほどで音楽の再生を終了する。

Amazon Echoのボリュームを日中時向けのレベルに変更する。

問題点

しかしながらAlexaアプリで提供される定形アクションでは諸々の理由で実現できなかった。

定形アクションでは再生先スピーカーの切替用アクションが用意されていない。 音声コマンドであれば「スピーカーと接続/切断して」でBluetoothスピーカーとの接続状況を制御できる。 ちなみにスピーカーの配置位置や、新規購入したメインスピーカーの機能的な都合により、メインスピーカーとBluetoothスピーカーを使い分けている。個人的にも機器の無駄遣いだなと感じてやまない状況なので普通の人であればこういった面倒事は不要だと思う���

定形アクションではボリュームの相対値変更ができない。 これは絶対値で音量を指定することで最悪代用できるが、夏場窓を開けたりしてベースとなるボリューム自体を変更する場合に定形アクションを作り直す必要が出てくる。

音楽再生は常に定形アクションの最後に実行する必要がある。 単純に一定時間後に再生を止めるだけであれば音楽再生時のアクションの一部として指定可能であるが、今回の場合は再生後にフェードアウトさせたいので問題になる。 そもそも論、なぜ音楽再生は定形アクションの最後でないといけないのかがいまいち腑に落ちない。

妥協案

ということで、現状では音声コマンドを3回呼び出すことで妥協した。

再生スピーカーをAUXよりBluetoothスピーカーに切り替え。「アレクサ、スピーカーと接続して」

Amazon Musicのライブラリ内の楽曲をランダム再生。「アレクサ、ライブラリを再生して」

音量を80%→待機→音量を70%→・・・→再生停止→音量を80%に戻す、といった定形アクションを実行。「アレクサ、フェードアウト」

正直面倒くさい。 個人的には音声コマンドをテキストで指定して、それを順次実行する程度のものであれば実装的に対して難しくもない気がするのだが、やはリ素人では計り知れない技術的かセキュリティ的な問題があるのだろうか。。。

[oyuugi-level-no-programming]

launchModeの挙動について、(今更ながら)試してみた。

AndroidのlauchModeについて、一般で説明されている内容ではいまいち解りにくかったので、実際試してみた結果をざっくり整理してみた 。

まず始めに、launchModeの挙動は以下の分類で把握する必要がある。

アプリケーション(タスク)内に複数のアクティビティが存在する場合

standard 常にアクティビティを新規作成する。タスク内に同じアクティビティが起動した分だけ存在する。

singleTop 既に同一アクティビティがタスク内に存在する場合使い回す。タスク内に同じアクティビティは一つのみ存在する。

アプリケーション(タスク)内に単一のアクティビティのみ存在する場合

singleTask アプリケーションは常に単一のタスクしか存在を許さない。

singleInstance 起動するたびにアプリケーションのタスクを起動し、同一アプリのタスクが同時に存在することを許容する。

デスクトップOSで例えると、standardとsingleTopはMDI的、singleTaskとsingleInstanceはSDI的なイメージになる。 なので例えば、singleTopとsingleTaskとでどちらを使うか悩む、というのはナンセンスだろう。

standardとsingleTopの差は、戻るボタンを押下した際の挙動に見られる。 standardの場合は、起動した分だけ延々と画面が戻り続ける。 singleTopの場合は同じ画面に1回以上戻ることはないが、元の画面を遷移先で呼び出している場合唐突にアプリが終了する可能性がある。 一般的なアプリの場合はstandardが無難だろう。その場合、可能な限りアクティビティを複製しないように画面遷移に注意する必要がある。 singleTopが有効なのは、アプリ内の画面が階層的ではなく並列的かつ単独で機能するような場合だろう。その場合各々のアクティビティで戻るボタンの押下でアプリが終了するようにしておく必要がある。

名称が似ていて公式の説明文の内容も近いsingleTaskとsingleInstanceとは混同しやすい。 が、実際の挙動は正反対で、タスクリスト上にアプリケーションを複数起動したいか否かでどちらを用いるかが決まる。ある意味挙動が理解できればstandardとsingleTopの関係より使い分けは容易だろう。

以下については未検証で想像の範疇のメモ書き。

仮にアクティビティが一つしかないアプリの場合、standard・singleTop・singleTaskは(おそらく)同様の挙動となると思われる。 singleInstanceは同一アプリを複数タスクで同時に起動できるという意味で、他のモードと比べて特異な存在といえる。

singleTaskなアクティビティ内でstandartなアクティビティを起動したいケースは、つまるところstandardからstandardを起動するのと意味合い的には同じで、特にできなくとも支障はない？ 説明文を真に受けるのであれば、別タスクで起動するはず？

singleInstanceなアクティビティ内でstandardなアクティビティを起動した場合にどうなるかは不明。 説明文を真に受けるのであれば、別タスクで起動するはず？

lauchmodeでは、デスクトップOSのブラウザや一部テキストエディタのような、MDIを複数タスク(ウィンドウ)で起動するアプリはできない？ singleInstance→standardの挙動次第？

[oyuugi-level-no-programming]

レビュー：Moto Zを1年使った結果、薄ければいい話じゃないってやっと理解した。

Moto Zというスマートフォンを先日まで1年ほど使っていた。カメラやプロジェクターなどのMotoModsモジュールによって機能拡張が特徴のモトローラのフラッグシップだ。国内版は発売当時、約9万円で販売されていたが、Amazonにて大幅にディスカウントされていたのを見つけてしまい、つい手を出してしまった。 個人的にはデザインや端末の軽さはとても気に入っていた。6mmを下回る薄さと筐体の剛性感の両立は他に類を見ない。できれば継続して利用したかったが、唐突に電源が落ちる事象が頻発したり、そうかと思えば全く問題ない時期があったりしていたのを様子見していたら保証期間が過ぎてしまい、そうこうしているうちにバッテリーが1日2、3回充電しないと持たないほど劣化したため諦めることにした。

Moto Zの利用してつくづく思ったのは、やはりスマートフォンを薄くするというのは技術的にリスクが大きいのだろうな、ということだった。一昔前、スマートフォンをより薄くする方向で各社が新製品をリリースしていた時期があって、特に品質を度外視する中華系メーカーが5mm前後の製品を出していた記憶がある。しかしながら最近のスマートフォンはどんどん肥大化していって8mmを超えるものが多い。これはバッテリーの大容量化やQi等の搭載を優先した結果で、数ミリの薄さを諦めることによるメリットが大きいからだろう。しかもMoto Zのように薄くすることで挙動が不安定になるのではなおさらメーカーからは忌諱されていくと思われる。

Moto Zを一年使ってみて感じたことを簡単にまとめてみる。

薄くて軽い、というのは手に取るたびに所有欲を満たしてくれる。ただし持ちやすいかと問われると答えを窮する。端末が四角く角が尖っていること、75mmの横幅、さらにはその薄さのせいで割と握りづらい。

バッテリーの劣化が、少なくとも僕の端末では早かった。これはそもそものバッテリー容量がスペックに対し少なすぎるがために充電回数が増えたことや、排熱に問題があったからなのではないかと推測される。

CPUはSnapdragon 820で、発売当時のハイエンドなCPUが搭載されている。が、実際のアプリでCPUの性能が額面通りに出ていたかは疑わしい。ゲーム(アズールレーン)をプレイすると露骨に処理落ちする。Webで検索するとむしろ下位機種のMoto Z Playの方が快適に動作するとの話もあった。とはいえTwitterとかGmailとかみたいな普通のアプリを使う分には問題ない。

OSは素のAndroidが搭載されている、という話だったが、連絡帳や電卓アプリ等はモトローラ謹製のものに置き換えられている。(それによる悪影響は特に感じることはなかったが)

Moto Actionは便利だった。特に端末を振ってカメラを起動する機能と、MotoVoiceを利用することで簡易スマートスピーカーにできるのが良かった。ただ僕の端末固有の問題なのか仕様なのかは分からないが、MotoディスプレイによるAlways On DisplayがAndroid 8.0にバージョンアップしてからまともに機能しなくなった。

MotoVoiceによる簡易スマートスピーカー化についての補足。まず起動キーワードを「OK Google」以外に設定することができる。ただし短すぎるものは駄目(例：Hello, Navi.)で、僕はそのまま「OK Google」で登録した。また、時刻や天気の確認は端末がスリープしていても問題なく応答してくれるが、アラームの設定のように入力系の処理については手でロック解除しないと受け付けてくれない。

やっぱり指紋認証は背面より前面にあった方が使い勝手がいいと、端末を買い替えた後に心底思った。今のベゼルレス・フルスクリーン化の方向的に、いくら反応が多少鈍くとも最終的には画面内指紋認証が主流になるんだろうなって確信した。

この端末最大の売りであるMotoModsについて、やっぱりというか結局何一つとして買うこともなく終わってしまった。。。カバーが付属していたが装着すると「薄くて軽い」というアイデンティティを失ってしまうので一度つけたきり即お蔵入りした。

結論として、Moto Zは質感が高くブランドイメージもよく所有欲をとても満たしてくれる印象深いスマートフォンではあったが、実用には耐える代物ではなかった。今もAmazonでたまに安売りをしているけれど一般人は間違いなく手を出しちゃいけないし、同じような値段なら最近技適を取得したらしいUMIDIGIあたりを買った方がまだ普通に使える可能性が高い。というか、繋ぎのつもりで今使ってるUMIDIGI Z2が驚くほど普通に使えて感動できる程度に、Moto Zはガジェットマニアのコレクターアイテムにしかなり得ない。そもそも、Moto Zの直系の後継機種は音沙汰なく派生のPlayやForceばかりに後継機種が存在するあたり、メーカー自身も失敗作として自覚しているのだと察するべきなのかもしれない。

昔から個人的に薄いガジェットに憧れを抱いてきたが、今回でちょっと現実を見せつけられた感もある。やはり薄いスマートフォンがなかなか出てこないことにはそれ相応の理由があるということなのだろう。

[oyuugi-level-no-programming]

UWP開発で気になった、ChromeとEdgeの挙動の差。

元々Android向けにリリースしていたアプリをWindowsでも使いたいと思い、つい先日までHTML+JavaScriptの、いわゆるハイブリットアプリを開発していた。 ぶっちゃけIE全盛の10年前とは違って今はモダンブラウザしかないはずだから、最新の仕様への対応状況にこそ差はあれどそこまで考慮する必要はないはず、と高を括ってChrome上でモックを作ってみたのだが、おそらくEdgeがベースのUWPアプリだと想像以上に表示崩れやJavaScriptエラーが発生してしまった。

ということで、せっかくなので一連の発生事象について備忘録として記してみる。尚、大半の問題点は「疑わしきは用いない」方針で、関連するアプリ機能自体をオミットしてしまったので、各ブラウザの仕様の詳細は調べていない。

CSSのcalc()の計算結果に誤差が生じる

今回起きたケースを例にすると、Flexbox内に要素を横に3つ並べる際に、親要素の幅から各子要素のマージンの合計を除いた値を3等分したものを子要素の幅に指定したところ、Chromeでは問題なく表示されたがUWPでは折り返してしまった。CSSの指定内容は以下の通り。

.child-elm { width: calc((100% - 6px) / 3); }

おそらくこれは、calcの計算結果において、Chromeは切り捨てでEdgeは切り上げだったことが理由と思われる。が、調査するのも面倒なのでマージンを多めにとってごまかしたので、詳細は追究していない。

font-familyの適用範囲に差がある。

親要素、例えばbodyにfont-familyを指定することでその子要素に対してもフォント指定が適用されるが、button要素に限りEdgeでは親要素の指定が無視される。ひょっとしたら他にも同様な例があるかもしれない。今回に限らずfont-familyは*セレクタ等で指定する方が無難なのかもしれない。

テキストボックスに「×」ボタンが表示される

HTMLのテキストボックス(input type="text")について、Edgeではデフォルトだと入力内容クリア用の「×」ボタンが表示される。これ自体はブラウザの便利機能なので文句はないのだけれども、今回はUWPアプリなので余計なボタンはデザイン上の邪魔になった。CSSに以下を指定すれば非表示にできる。

::-ms-clear { display: none; }

HTMLのD&Dの挙動に差がある

HTML5ではドラッグ&ドロップに関するAPIが追加されているが、流石にまだ新しい仕様のためか、ChromeとEdgeとでは挙動の差が大きかった。例えば、event.dataTransfer.setData()/getData()を呼び出すとEdgeでは未定義なのか落ちたり、Chromeだとボタンに対してD&Dを受け付けないがEdgeではできる、等の差があった。今回の要件においてD&Dはマストな機能ではなく諦めてオミットしたので詳細は調べてない。

EdgeではfileスキームだとWebStorageにアクセスできない

モックの動作確認でローカルのHTMLファイルをfileスキームでアクセスした場合、EdgeではWebStorageにアクセスできない。Chromeだとアクセスできる。しょうがないのでIISを立ち上げてそちら経由でアクセスすることにした。 ちなみにUWPアプリではSessionStorageは使えるがLocalStorageは利用できない。代わりにUWPのAPIとして提供されているLocalSettingsを用いる必要がある。

スクロールイベント関連に差がある

例えばscrollIntoView()のオプション指定が効かない。さらにはscrollBy()が普通のエレメントに存在しない。なので今回は、Element.scrollLeftへ現在のスクロール位置を指定する方法で対処している。

最後に余談だが、Microsoftも将来的にはEdgeをChromiumベースに切り替えるとか言い出している状況、上記について今後は考慮する必要がなくなるかもしれない。

[oyuugi-level-no-programming]

スマホを買わずに縛りなしで契約すると、いくら払うのか調べてみた。

最近某官房長官の発言を受けて、携帯電話の通信料金に関する意見があちこちで散見している。 とはいえ携帯キャリアの契約料金については、今も昔もどことなくきな臭さを感じさせるのはいつものことだったりする。

僕自身はとっくの昔にMNOには見切りをつけてMVNOを利用しているからどうでもいい話なのだけど、どうしてもキャリアでないと嫌だ、なんていう人間も多いらしい。 そこで、実際の携帯キャリアの料金はどうなのか、2年縛りやキャンペーンでの一時的な割引等を考慮しない素の契約料金はいくらなのか調べてみた。もちろん実際には2年縛りじゃないと割高になるので現実的な金額ではない。契約にほとんど縛りが存在しないMVNOとの差がどの程度なのかを把握することが主なる目的になる。

なお、以下の契約プランは2018年9月にて改正される内容を基準としている。

想定する条件

端末は手持ちのSIMフリー端末をそのまま利用する想定。なので端末購入に付随する割引オプションは考慮しない。 各キャリアの最低料金を見たいので、月のデータ通信量は1G未満、通話はほとんどしない、いわゆるライトユーザーを想定。家族引き等も加入しない。

ドコモ

基本契約プラン：シンプルプラン - 2480円 ※ 参考 2年縛り自動継続あり - 980円 インターネット接続サービス：SPモード - 300円 データ通信料金：ベーシックパック - 1GB/2900円

合計：5680円(税込6134円) ※ 参考 2年縛り自動継続あり：4180円(税込4514円) ※ 参考 上記+docomo with：2680円(税込2894円) + (使用しない)スマートフォン代 約40000円

au

月額料金：auピタットプラン(シンプル) - 1GB/4480円 ※ 参考 2年縛り自動契約なし - 3280円 ※ 参考 2年縛り自動契約あり - 2980円

合計：4480(税込4838円) ※ 参考 2年縛り自動契約なし：3280円(税込3542円) ※ 参考 2年縛り自動契約あり：2980円(税込3218円) ※ ちなみに当該プランの場合、スマホ応援割・auスマートバリューは適用不可。

ソフトバンク

基本契約プラン：通話基本プラン - 4200円 ※ 参考 2年縛り自動契約なし - 1800円 ※ 参考 2年縛り自動契約あり - 1500円 データ通信料金：データ定額ミニモンスター - 1G/2480円

合計：6680円(税込7214円) ※ 参考 2年縛り自動契約なし：4280円(税込4622円) ※ 参考 2年縛り自動契約あり：3980円(税込4298円)

Yモバイル

月額料金：スマホベーシックプランS - 2GB/5480円 ※ 参考 2年縛り自動契約あり - 2980円

合計：5480円(税込5918円) ※ 参考 2年縛り自動契約あり：2980円(税込3218円) ※ 通話10分無料付き

※参考・MVNO(mineo)

月額料金：デュアルタイプ - 3GB/1600円

合計：1600円(税別1728円) ※ ただし、1年以内のMNP時のみ違約金あり

結論と余談

仮に例の4割発言を真に受けたとしても、例えばドコモの場合、縛りなしで5680円→3408円、docomo withまでつけた2年縛りで2680円→1608円となる。 MVNOとMNOのデータ通信上限の差やサービスの充実度の差を考慮しても、実はあの発言はそんなにおかしなものではないのではないか、と調査結果を受けて個人的には感じた。(もちろんあの立場の人間の発言として適切だったかは話は別だが)

それでは「キャリアの料金が高いから安くしろ」で終わっていいのかというと、そうではないと考えている。例えばこの国には、単純にSIMをスマートフォンに挿してAPN設定を行うといったごくごく単純で基本的な作業すら「そんな難しいことを言われても素人じゃ無理だ」なんておっしゃる人間もいたりする。そういった低リテラシーな人間がスマートフォンで何をやろうというのかは分からないが、当たり前のようにショップの店員に設定を丸投げしてちょっとでもおかしくなると「誰でも簡単に扱えないのが悪い」なんてクレームをつける。そうした日本的「おもてなし」に基づくサービスの提供はもちろん無償ではないはずだし、それが通信料金に転嫁していると考えると、一般的なITリテラシーを持った人たちは自分たちが使ってもいない過剰なサービス料金を支払っていることになる。

なので、僕らが携帯料金を適正なレベルまで引き下げるために取るべき手段は、短期的には低リテラシーの人間が群がるMNOからさっさとMVNOへ移転することだし、長期的には「SIM挿してAPNを設定する」程度のITリテラシーなんていうのも恥ずかしいレベルの知識をこの国の人間たちに教化して過剰なサービスの提供を少しずつでも無意味にしていくことだろう。結局のところ高い金を払う羽目になっているのは無知と怠惰を詐欺師に付け込まれた結果だと言えないだろうか。いくらダダをこねても解決はしない。

[oyuugi-level-no-programming]

Windows10のタイルにChromeアプリなYouTubeアイコンを置けなくて試行錯誤してみる。

少し前から動画再生と普段の作業との兼用を考えて、俗にいう「Yogaスタイル」なWindowsノードを導入している。ノートPC自体には特に不満はないのだけれども、WIndows10のスタート内のタイルにChromeアプリへのショートカットがうまく置けない。正確には置けるのだが、アイコンがWebサイトのファビコンではなくてChromeのアプリアイコンになってしまう。見た目にこだわらなければこれはこれで問題なく使えるが、やっぱりなんか気になるので色々試行錯誤してみた。

結論としては、以下の方法で対処することができた。

Chromeから既に登録済みのアプリを削除

"chrome://apps"をアドレスバーに指定して開くと、現在追加されているアプリの一覧が表示される。そこから、今回タイルに追加したいアプリと同名のものを削除しておく。 これを行っておかないと、プログラムリスト内の「Chromeアプリ」配下に同名のショートカットが存在する場合タイル配置の際にうまくいかない。ただし、別の名前でタイルに配置する場合は削除の必要はない。

Chromeへのショートカットを作成し、起動オプションと開きたいサイトのURLを指定

ショートカットの配置場所は任意で問題ない。 例えばYoutubeをローカルアプリ風に使いたい場合、起動オプションに次のいずれかを指定する。

(アプリモード) ～¥chrome.exe "--app=http://www.youtube.com" (全画面表示) ～¥chrome.exe --start-fullscreen "--user-data-dir=(任意のディレクトリ)" "http://www.youtube.com"

本来の使い方としてはアプリモードの方が望ましいが、タッチパネルで操作する場合アプリモードではスワイプによるブラウザバックが利用できない。なのでタブレットや2in1ノートPCでは全画面表示での起動がおすすめ。その際"--user-data-dir"を指定しないと、別のChromeウィンドウが起動中の場合全画面表示にならず、起動済のウィンドウ内に一緒になって表示されてしまう。ちなみに"--user-data-dir"と似たようなオプションとして"--profile-directory"もあるが、こちらではうまくいかない。

ショートカットのアイコンを差し替え

作成したショートカットアイコンをプロパティより変更する。YouTube等のアイコンは自分で作るか、一度Chromeで「デスクトップに追加」を行い、それで作られるショートカットのものを流用する。上でも説明したが、一時的に追加したChromeアプリは"chrome://apps"から削除しておくこと。

Chromeのインストールディレクトリより"chrome.VisualElementsManifest.xml"を削除

どうやらタイルの表示スタイルはこのファイルにて指定を行っているらしい。逆にこのファイルが存在する限り、ショートカットのアイコンをいくら変えても無視される。なので、このファイルをChromeのインストールディレクトリより削除しておく。その際のファイルのバックアップは各自の任意で。

作成したショートカットをスタートのタイル表示に追加

作成したショートカットを右クリックして「スタートにピン留めする」を選べば、無事ショートカットのアイコンでタイルが追加されるはず。

[oyuugi-level-no-programming]

ALCATEL IDOL4を買ったらプリインアプリを止めなきゃ駄目だよ。

最近ALCATEL IDOL4が極一部から注目を集めているらしい。個人的にはいかに安くとも、国内発売時点で既に競合よりも色々機能面で不足があったこの端末を、発売から一年以上経ったこのタイミングで購入するのはおすすめしない。ただ、それでも人は安いものには目がないし、性能度外視でデザイン性やガジェットとしての魅力に惹かれて欲しがる人もいるかもしれない。

ということで、もし今ALCATEL IDOL4を買ってしまった人は、一部のプリインストールアプリの挙動を抑止しておいたほうがいい。

Apps

デフォルトのストアアプリ。これが有効になっていると、Google Playストアではなくこちら経由でアプリのアップデートが行われるようになり、自動アップデート等が働かなくなる。OSの設定にてアプリを無効化すれば、通常のAndroid端末と同様にアプリのアップデート処理が行われるようになる。

天気

これ自体は普通に使えそうだが、事あるたびにロック画面や通知画面に居座ろうとする。さらに一度表示を止めてもアプリがアップデートする度に復活する。目障りであるならこちらもOSの設定よりアプリを無効化することが可能。

ファイルマネージャー

IDOL4のプリインストールアプリの中でも特に問題児なのはこれ。天気アプリと同様に事あるたびに通知画面等に常駐し、止めてもやはりアップデートで復活する。さらにバックグラウンドで何かをやらかしているらしく、スリープ中だろうと延々とバッテリーを消費し続ける。真っ先に止めたいところだがなぜかシステムアプリ扱いらしく設定で無効化することができない。正直なところ二度とALCATELの端末は買いたくなくなるレベルで質が悪い一品。 アプリのアップデート削除等色々試行錯誤をしてみたが、最終的に有効だったのが別のプリインアプリであるBoostを使ってファイルマネージャーのバックグラウンド起動を抑止すること。これを行うことでバッテリーの持ちが段違いになるので、個人的にはIDOL4を使うのであればマストだと思う。

Boost

ファイルマネージャーの対処の際に用いたこちらも、特に指定もしていない他社アプリを勝手に抑止対象に指定している等、やや不穏な点があったりする。具体的には、各種Play系アプリやAmazon、Feedly、Evernoteといったものが僕の場合抑止対象に指定されていた。とはいえ一旦チェックを外しておけばそれ以降は元には戻らないし、そもそもいま時点では悪影響が見られないのでとりあえずは様子見といったところ。唯一気になるのはFeedlyでページを閲覧した後に戻ろうとすると再起動がかかる点だが、チェックを外した後も発生するので因果関係があるかは不明。

最後に、Androidのバージョンアップは諦めた方がいい。どうしても、7.0以上に上げたい場合は、LineageOS等のカスタムROMを焼くしかないが、そういった行為自体が目的だという人以外は止めておいた方が無難。仮にうまくいったとしてもリバーシブル機能等のこの端末固有の機能は動かない可能性が高い。

[oyuugi-level-no-programming]

Lollipop以降のAndroidでアクティブなアプリを取得する奥の手、だが。。。

たまに、サービスを常駐させておいて、特定のアプリが起動したのを検知して何かをする、といった処理をやりたいなんて思ったりする。 でも、Android5.0以降では他のアプリのプロセス状態を取得することが難しくなった、という話を見かけたので、早々と調査を切り上げて諦めてしまっていた。(なのでどの辺の制約がきつくなったかとかは詳しくは知らない)

で、最近、没入モードについて幾つかのアプリを試用している際に、普通にアプリの切り替わりを検知できているものがあることに気がついた。

Immersive Plugin

どうやらユーザー補助機能を利用しているようで、ちょっと試してみたら簡単に再現できた。詳細についてはユーザー補助機能(User Accessibility)を調べればすぐ分かることなので割愛する。

問題なのは、他アプリのフォアグラウンド化の検知のためにユーザー補助機能を用いるのは妥当か否かといったところ。OSのバージョンアップで機能しなくなるくらいは平気でありえそうな気がする。セキュリティ問題が世間の話題をさらうことが多くなった昨今やむを得ないことではあるが、AndroidでもiOSと同じようにサンドボックスで完結するアプリが望ましいということなのだろう。

とはいえ現状でどうしても他アプリのアクティブ化を検知したいとなった場合は必要悪的に使うしかないけどね。

[oyuugi-level-no-programming]

スマートフォンをImmersive Modeにするベストな方法はたぶん、これ。

Google Playで公開されているImmersive Mode(没入モード)化アプリについて、Root不要な方法では仕様的に限界があることを前回記した。 そこで別の方法はあるのかという話になるのだが、実はある。ただし、単純にアプリをインストールすればOKという方法ではなくて、ADB経由での操作が必要になる。Rootはいらない。

この方法を知る切っ掛けとなったのは、海外の方からのメールで「"All in one Gestures"を使えば、没入モード中でもソフトウェアキーボードが使える」との指摘を受けたところからだ。 "All in one Gestures"はジェスチャー操作で戻るボタンやホームボタンをエミュレートするアプリで、その機能の一つとして没入モードに対応している。通常時は他の没入モードアプリと同じように振る舞うが、チュートリアルに記載されている手順を踏むことでソフトウェアキーボードの表示を含む諸々の問題が解消される。ちなみにチュートリアルにて行った手順とは、ADB経由で"All in one Gestures"に"WRITE_SECURE_SETTINGS"権限を付与するというもの。 手順の具体的な内容については、Google Playストアの"All in one Gestures"や、そこに記載されているチュートリアルページを参照してほしい。

というわけで、"WRITE_SECURE_SETTINGS"と"Immersive Mode"をキーワードにWebを検索しまくったところ、OSの設定を変更して没入モードにする方法が記載されているページを幾つか見つけることができた。 その方法は、スマートフォンをデバッグモードでPCに繋いで次のADBコマンドを入力するだけ。ちなみにPC経由で設定変更する場合"WRITE_SECURE_SETTINGS"権限はいらない。

ステータスバーのみ非表示にする場合。

adb shell settings put global policy_control immersive.status=*

ナビゲーションバーのみ非表示にする場合。

adb shell settings put global policy_control immersive.navigation=*

フルスクリーン表示にする場合。

adb shell settings put global policy_control immersive.full=*

上記の設定を解除し、元に戻す場合。

adb shell settings delete global policy_control

現在の設定内容を確認したい場合。

adb shell settings get global policy_control

上記コマンドで何をやっているかというと、「settings.db」内の「global」テーブルの「policy_control」カラムに「immersive.～」というデータを設定する、ということらしい。正直なところこのテーブルやカラムの本来の意味についてよく分かっていない。手持ちのスマートフォンを確認したところデフォルトでは何も設定されていないので今のところは上書きしても多分問題はないだろうと割り切っている。

さらに、

adb shell settings put global policy_control immersive.full=com.android.chrome

のように指定すれば、Chromeのみフルスクリーンで表示することもできるし、

adb shell settings put global policy_control immersive.full=*,-com.android.chrome

であれば、Chromeのみフルスクリーン表示の対象から除外することもできる。

この方法の唯一の欠点は、基本はフルスクリーンで一部アプリだけナビゲーションバーのみ非表示にする、といった指定ができないこと。実はAndroidのソースに「PolicyControl.java」というそのままズバリなクラスが存在していて、その実装では":"で複数の指定を連結することもできそうなのだが、実際に試してみたところ最後に指定したものしか有効にならなかった。

尚、アプリ内からこの設定を変更するには「Settings.Global」クラスを用いることになるが、その際に「WRITE_SECURE_SETTINGS」権限をアプリが持っていないと例外が発生する。

ということで、個人的にはAndroidなスマートフォンでナビゲーションバーを非表示にしたい場合は、この方法がベストだと思っている。OSの設定により没入モードを実現しているからアプリの機能やレイアウトとの不整合は起きないはず。一つ不安要素があるとすれば、「policy_control」に別の指定がなされる可能性があることだが、その時は多分なにかおかしなことになるだろうからそのときに考えることにする。

ちなみに、アプリ単位で挙動を指定するのにわざわざ都度パッケージ名を調べてPCに繋いでコマンドを打つのも面倒なので、設定アプリをGoogle Playストアに公開してみた。あくまでもOSの設定の変更を行なうツールのため、利用の際は自己責任でお願いしたい。

Immersive Settings

[oyuugi-level-no-programming]

Root不要でImmersive Modeにするアプリの仕組みを分析してみる。

AndroidのImmersive Mode(没入モード)について、色々試してみて分かったことをまとめてみる。 あらかじめ断っておくと、今回紹介する方法では仕様上どうしても不便なところが出てくる。最終的にどうしたかは別途まとめる予定、ここでは最終的な結論に至るまでの模索について記したい。

Google Playストアには、他のアプリを強制的に没入モードにできるアプリが幾つか公開されている。それは大別して、Root権限が必要であるか否かの二種に別れる。端末のRoot権限を取ってしまうとOSアップデートで支障があったりするので、ここではRoot不要のアプリを俎上に上げる。

Root不要で没入モードを実現できるアプリは共通して以下のような仕様がある。

没入モード中はソフトウェアキーボードが表示できない。つまり、文字入力ができない。

一部のアプリについて、ステータスバーやナビゲーションバー部分が空白となってしまい、没入モードでもフルスクリーンで表示できない。これに該当する主なアプリとして、Google Play系アプリ全般やtwitter、feedlyがある。(Fragmentを用いたアプリの大半)

没入モード化するアプリのうちの一部では、戻るボタンが効かなくなる。ただし、殆どのアプリについては何らかの対策がなされている。

強制的に没入モードを実現するこれらのアプリについて、つい最近までその仕組みが僕には分からなかった。公開されているAndroidのAPIでは、没入モードはその指定を行うアプリ自身にのみ有効で、他のアプリの画面表示を変更できるようなAPIは存在しない。 複数のアプリを試用しておそらくこうだろうと僕なりに分析した結論を記してみる。多分合っているとは思うけれどひょっとしたら間違っているかもしれないが、とりあえず試しに作ってみたら同じような挙動にはなった。

Root不要で強制的に没入モード化するアプリは、(おそらく全て)オーバーレイビューを利用している。つまり、常駐サービスにて通常のアプリよりも上位のレイヤー(大抵はひとつ上の"SYSYTEM_ALERT"レイヤー)にビューを設定し、そのビューに対し没入モードを指定する。 その際のビューに対する指定例は以下の通り。

overlayView.setSystemUiVisibility( View.SYSTEM_UI_FLAG_FULLSCREEN // ステータスバーを非表示 | View.SYSTEM_UI_FLAG_HIDE_NAVIGATION // ナビゲーションバーを非表示 | View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY); // 没入モード状態を維持し続ける layoutParams = new WindowManager.LayoutParams( WindowManager.LayoutParams.WRAP_CONTENT, WindowManager.LayoutParams. WRAP_CONTENT, WindowManager.LayoutParams.TYPE_SYSTEM_ALERT, // SYSTEM_ALERTレイヤーに表示 WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL // モードレス指定(=下位レイヤーを操作可能) | WindowManager.LayoutParams.FLAG_WATCH_OUTSIDE_TOUCH, // 領域外のタッチを検知 PixelFormat.TRANSLUCENT);

ここで重要なのは、LayoutParamsに"FLAG_NOT_FOCUSABLE"を指定していないことで、これがこの方法の最も肝になる点であり、仕様的な限界につながるところでもある。つまり、通常のアプリより上位のレイヤーに表示されているビューにフォーカスが当たっていることになり、そのビューが没入モード指定であるから、下位レイヤーのアプリ諸共没入モードでの表示が適用される。 こういう仕組みであると分かった上で先に挙げた強制没入モード化するアプリの仕様を確認してみると、どうしてそうなるのかはなんとなく想像ができる。

没入モード中はソフトウェアキーボードが表示できない。 → フォーカスがオーバーレイビュー側にあることが原因と思われる。

一部アプリがフルスクリーン表示にならない。 → アプリとしては没入モードとして認識はしていないため、レイアウト配置の計算が通常表示前提で計算される。

戻るボタンが効かない。 → フォーカスが当たっているビューに対応するアクティビティがないことが原因と思われる。

[oyuugi-level-no-programming]

レビュー: ONYX MINIがあんまり「MINI」っぽくない

(2017/5/27追記) 新旧の評価が入り混じって分かりづらくなってしまったので、全文を書き直したものを再掲している。その点まずは断っておきたい。

harman/kardonのONYX MINIというbluetoothスピーカーを買ってみたのだけど、結構癖が強い割にWebにレビュー記事が出回っていなかったので、使ってみた印象を記してみる。

音質について

僕自身あまり音響関係に詳しいわけではないが、音質は、最終的には普通に聴くには十分なものだと思う。「最終的には」と断っているのは、使い始めの状態では中高音域が全く駄目だからで、30～50時間くらいかけてエージングする必要がある。ただしエージング前から低音域はかなり響く。最低でもこれまで僕が使っていたUE MINI BOOMより間違いなく低音が出ている。 エージングが済むまでは音量を絞った状態だと中高音域が完全に低音域でかぶるため、音量をある程度上げないとかなりストレスが貯まることになる。時間が経つにつれ解消されバランスがよくなり、ある程度音量を絞っても問題なくリスニングできるようにはなる。が、本質的には壁際において部屋全体を鳴らす用途の方が向いていると思う。コンパクトなスピーカーというよりかは、既存のラジカセやミニコンポの代替として使うべきものだという印象を持った。 また、スピーカーの形状やサイズから受けるイメージよりステレオ感が強い。もちろん左右にセパレートしているスピーカーに比べれば劣るが、一般的なBluetoothスピーカーより音の広がりはあると思う。

Bluetooth関連について

ONIX MINIのBluetooth接続は他と比べてちょっと癖がある。少なくとも僕がこれ��で使ってきたBluetoothスピーカーとは若干挙動が異なる。 このスピーカーには同時に3台まで接続できる、所謂マルチポイント機能がある。繋いでいる端末のうちのどれかが再生中に別の端末で音楽再生を始めた場合、このスピーカーだと後勝ちになる。つまりこれまで再生していた側は再生を停止して、後から再生をした端末の音が流れる。これは僕の持っている他のスピーカー、例えばUE Mini Boomとは挙動が逆だったりする。

無音状態が30分程度続くと自動で電源オフになる。ただし、Android端末の場合、再生が終わっても延々接続を維持し続けるケースがある。そうしたケースでは大抵Google Play Music等が再生終了後にも通知エリアに残り続けているからで、そのアプリをきちんと終了すれば一定時間後にスリープするようになる。

電源をオンにした際の再接続先について、通常この手のBluetoothスピーカーは最後にアクティブだった端末へ再接続をしようとする。そのときに周囲にその端末が存在しない場合、もしくはBluetoothをオフにしている場合は、そのまま他の端末に接続せず待機状態になる。しかしONIX MINIの場合、最後にアクティブだった端末が見つからなくてもマルチポイントにて接続済みだった他の端末へ接続しようとする。これは、自分からは自動で接続を復元しようとしないiOS端末を含めてマルチポイント接続をしているケースで特に有効で、iOS以外の端末をBluetoothオフか電源オフにしておけば、スピーカーの電源オン時で常に自動でiOS端末に接続してくれる。Android側はBluetoothをオンにしてあげれば自動で最後にアクティブだったスピーカーとの接続を復元してくれるし、Tasker等のアプリを使えばその辺も自動化することができる。

その他の機能について

しょっちゅう警告音が鳴る印象も強い。電源オン・オフ時、ペアリング時や接続時はもちろん、バッテリーレベル低下時は電源をつなぐまで警告音が鳴り続く。しかも、それをオフにすることも音量をコントロールすることもできない。人によってはこれでNGになるかもしれない。 音量については一つ問題点があって、電源オフで変更したボリュームがリセットされてしまう。ただし、iOSや一部のAndroidスマートフォンのようにボリュームがスピーカー側と連動している端末の場合(AVRCPプロファイル対応?)は問題ない。対応していない端末の場合、ONIX MINI側の音量の初期値がかなり小さめなので使うたびに都度調整する必要がでてくるかもしれない。

充電はmicroUSBで行う。電源ボタンの後ろにバッテリーの残量がLEDで5段階表示されるのは便利だと思う。その代わり、UE MINI BOOMのように端末からバッテリーの残量は分からない。再生時間は仕様だと10時間となっているが、使った印象ではだいたいそのくらいは持ちそうだ。 あと特に説明書等にも記載がない機能として、microUSBで給電中は一定時間経過した後も電源オフにはならずスリープモードに移行する。この状態になると電源ランプ以外は消灯するが電源オフにはならないので、接続元の端末側からアクセスすることで復帰する。ただし、Androidの場合は接続自体は切断された扱いとなるため、明示的に再接続する必要がある。iOSではこの状態でもステータスバーの表示を見る限りBluetooth接続を維持しているようなので、普通に音楽を再生するだけでスリープから復帰する。

スピーカー自体はそこまで重くはないが、ONYX Studioのように持ち手があるわけでもなく、背面にパッシブラジエーターがあるのも影響して非常に持ちにくい。片手だと掴みづらいから両手で抱え込むように持つしかない。また、足の部分の素材が柔らかく接地面とのグリップも強いため、位置の微調整がしづらい。このあたりの構造からしてやはり据置用途を見据えて設計されているんだなと思えてくる。

説明書や商品説明によると、2台用意すればTWSで使えるらしい。TWSの使い勝手は流石に2台持っていないので不明だが、おそらく2台目のONYX MINIもマルチポイントの1台としてカウントされるだろうから、3台端末を繋げて使いたいと思っている人は気をつけた方がいい。あと、同グループのJBL製スピーカーの場合都度TWS設定が必要である話も聞いたことがあるので、たとえばUEのBluetoothスピーカーのように電源を入れたら自動的にTWSになるような仕組みであるかは、実際にやってみないと分からない。

総評

まず、とりあえず30時間くらいは我慢して使ってあげる必要がある。エージングが済んだ後であれば価格に見合った音を鳴らすスピーカーだと思う。僕が確認した時はAmazonに2名ほどレビューを投稿していたが、それぞれ評価が別れたのはひょっとしたらエージングの有無の差なのかもしれない。Boseのスピーカーはヨドバシ等の騒がしい中でしか聴いたことがないから実際のところは分からないけれど、高評価のAmazonレビューにある通りSoundlink mini2より音がいい可能性もあり得るかもしれない。最低でも僕の手持ちのUE MINI BOOMに比べれば十分価格差分の価値があるように感じた。ただし、UE MINI BOOMの時みたいに手軽にキッチンやテーブルへ移動できなくなったのは、この手のコンパクトさをうたうBluetoothスピーカーとしては人によっては致命的な欠点になるかもしれない。 古いとはいえ上位機種のONIX Studioが大幅な価格崩れを起こしているのをみると悩ましくはなる。ただ、音質以外の機能は新しい分ONIX MINIの方が充実していて、かつユニークな実装がなされているので、その癖を熟知して利用できればそんなに悪い買い物でもないとは思う。

結論として、買った当初は割りと後悔していて、素直にJBLのCHARGE3にすればよかったなんて考えたりもしたけれど、今はONIX MINIを選んでよかったととても満足している。

[oyuugi-level-no-programming]

AdMobの実装ポイント覚書。

AdMobを久しぶりに使おうとしたらWebの情報が新旧錯綜していたので、覚書としてまとめてみる。 当然各種バージョンは最新のものを使う方が望ましいと思われるが、とりあえずは動作したものを使う方向で。また、AdMob用に追記した部分のみ抜粋して記載している。

事前作業として以下が必要。

事前にAdMobに登録(登録にはGoogle Playにリリース済みである必要あり?)。その過程でFirebaseへ登録、アプリに対応するgoogle-service.jsonをダウンロード。

app/配下にgoogle-service.jsonを配置。

/build.gradle

dependencies { classpath 'com.google.gms:google-services:3.0.0' }

app/build.gradle

android { compileSdkVersion 23 } dependencies { compile 'com.google.firebase:firebase-ads:10.0.1' } apply plugin: 'com.google.gms.google-services'

AndroidManifest.xml

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> <uses-permission android:name="android.permission.INTERNET" /> <application > <meta-data android:name="com.google.android.gms.version" android:value="@integer/google_play_services_version" /> </application>

string.xml

<!-- 以下はテスト用ID --> <!--「アプリID」ではなく「広告ユニットID」なので注意 --> <!-- ("~"を含むIDではなく、"/"を含むID) --> <string name="banner_ad_unit_id">ca-app-pub-3940256099942544/6300978111</string>

layout.xml

<FrameLayout xmlns:ads="http://schemas.android.com/apk/res-auto" > <com.google.android.gms.ads.AdView android:id="@+id/adView" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_gravity="bottom|center_horizontal" ads:adSize="SMART_BANNER" ads:adUnitId="@string/banner_ad_unit_id" /> </FrameLayout>

Activity.java

private AdView mAdView; onCreate() { MobileAds.initialize(getApplicationContext(), getResources().getString(R.string.banner_ad_unit_id)); mAdView= (AdView) findViewById(R.id.adView); AdRequest adRequest = new AdRequest.Builder().build(); mAdView.loadAd(adRequest); } onResume() { // 広告配信を再開 mAdView.resume(); } onPause() { // 広告配信を停止 mAdView.pause(); } onDestroy() { // 広告配信を終了 mAdView.destroy(); mAdView = null; }

[oyuugi-level-no-programming]

ロック画面を横にしたくて、勢い余ってアプリ、つくっちゃった。

最近のスマートフォンはサイズが大きい。 昔、まだiPhone4や5のサイズが全盛だった頃のスマホスタンドに立てるとちょっとした振動やテーブルの移動で転がってしまう。なので、最近は縦置きは諦めて、横向きにしてスタンドに立てている。

その際ちょっと困ったのは、スマートフォンだとロック画面が横方向に回転しないことだ(タブレットなら当然回転する)。特にAlcatel IDOL4にしてからノックオンが使えるようになったので通知を気軽に確認できるようになったのだけど、表示は縦方向のままなのですこぶる読みづらい。

と、普通であればGoogle Playからローテーション制御アプリを導入すれば解決する。 例えば、次のようなアプリであればロック画面の向きについても制御できる。

Rotation Control 最高のローテーション制御

でも僕は、これらのアプリを入れた際に設定の仕方をミスっていたらしく、うまくロック画面を横向きにすることができなかった。 ちなみに、今入れたら普通に設定を変更したらできた。ちょっと前の僕が何を勘違いしてたのかはよくわからない。

で、それなら自分でつくればいいじゃないかぁ、ということでわざわざつくってしまった、「ロック画面のみを回転させる」アプリを。

Rotation LockScreen - ロック画面を回転

仕組み的には多分、他の強制的にローテーションするアプリと同じだと思う。 具体的にはサービスから通常のアプリやロック画面より上位のレイヤ(今回の場合「TYPE_SYSTEM_OVERLAY」)にビューを表示して、それに対してローテーション制御を行っている。

ぶっちゃけたところ車輪の再発明でしかないのだが、一応このアプリが他と違う点を挙げてみる。

ロック画面「のみ」回転させる。 他の画面では強制ローテーションは無効にしているので、他のアプリの動作に影響を与えにくい。

設定なしで、ロック画面の回転が可能。 先に挙げたアプリの場合、設定をしないとロック画面が回転しない。

着信時はローテーション制御の対象外。 例えばAlcatel IDOL3や4のようなリバーシブル対応なスマートフォンの場合、着信時にローテーションしてしまうと挙動が怪しくなる。

[oyuugi-level-no-programming]

Android実機だと残ってるBigDecimalの不具合。

Androidアプリで動作確認している際に、BigDecimal.stripTrailingZeros()を呼んでいるのに小数部の不要な0が削除されない不具合に遭遇した。しかもAndroid StudioのJUnitにてテストしているときには問題なく、実機でのみ発生する。

BigDecimalについてWebで調べたところ、Java7までだとstripTrailingZeros()に不具合が存在していたらしい。"0.0"の場合に本来であれば"0"となるところ、"0.0"のままとなってしまう事象のようだ。 で、開発に使っているPCのJavaのバージョンは8なのでこの問題は起こらない。でもJUnitはきちんと通過したはずのプログラムをAndroidスマートフォン実機で動かすと不具合が生じる。

今まではわりと実機と開発環境との差は軽視していたのだけれども、こういった問題が他にも潜在しているのかもしれない。

[oyuugi-level-no-programming]

補足レビュー：ALCATEL IDOL4 のあれこれ気になるところ。

しばらくALCATEL IDOL4を使ってみて、気になったところを記してみる。

リバーシブル機能について

リバーシブルのオン・オフは、端末のローテーション設定とは独立している。 そのため、ローテーション設定を縦方向のみとしている場合でもスマートフォンを上下反対にすればきちんと反転する。 上下反転した際に物理キーである音量ボタンについてもきちんと連動する。が、それは画面がオンの場合のみで消灯してると本来の挙動に戻ってしまう。なので、音楽アプリを操作しているときには注意が必要。

オーディオ周りについて

スピーカーはこの端末の売りだが、あくまで「スマートフォン」としては優秀といったレベルなので過度な期待はしちゃいけない。 例えば、数千円ほどで手に入るUE MINI BOOM(WS510)と比べてさえ、素人がちょっと聴けば分かる程度の差はある。 この手のスピーカーをありがたるのは音ゲーのプレイヤー達が主なのかもしれない。僕はその手のゲームはやったことがないので、このスピーカーで用途的に足りるのかはちょっと分からない。普通外出時はイヤホンを使うだろうし、家ならBluetoothスピーカーを用意したほうがいいんじゃないのかなと個人的には思ったりする。

イヤホン出力についてはスマートフォンの標準レベルだと思う。専用のミュージックプレーヤーと比較するとどうしてもノイズが乗りやすい。手持ちのイヤホン(ATOMIC FLOYD HiDefJax)だと若干ホワイトノイズが気になる。そのためか、付属のJBL製イヤホンの抵抗値はやや高めになっている。イヤホンの音質自体もそんなにこだわりがなければそのまま使っても不満は少ない。

BOOM Keyについて

画面オフ時とオン時とで、適用できる項目が異なる。

画面オフ時は、1回押しで画面オン、2回押しでカメラ撮影及び長押しで連写、という2つの機能をそれぞれ有効・無効にすることができる。 ちなみに僕的にはリバーシブル機能のことを考えてノックオンを利用しているので、こちらは無効にしている。

画面オン時は選択肢が増えるが、結局使い道があるのは「アプリケーションをトリガ」、つまり任意アプリのショートカットキーとして使うくらいな気がしている。一番らしい使い方は「ブーム効果を有効にする」だが、対応アプリが限られている上に有効な機能が少ない。特に音楽再生時にBoom Keyを押すとブーストがかかるようになるが、音質的にも悪化する上に解除するのに通知エリアから操作しないといけなくなる。ただ、通話中に押すと騒音時に音声が明瞭になる機能とかもあるので、それはひょっとしたら使えるかもしれない。(普段通話は使わないし、ほとんど室内で受けてしまうので試す機会はないが)

ちなみに「ブーム効果」については、Boom Keyの設定メニュー上部にアニメーション付きで補足説明が表示される。

その他

使い物にならないほどではないが、ノックオンのレスポンスが悪い。前に店頭にて他の端末で試した時はもっと反応が早かった気がするので、この端末固有の問題なのかもしれない。 虹彩認証について、僕の場合は使い物にならなかった。ただこれは、僕の視力が0.1未満でかつ裸眼だと左右のピントが合わず、さらにメガネをかけて認証をしようとしたのが悪いんだと思う。

あと多分どうでもいい話だろうけど、よく100均で売られているクリップ型のスマホスタンドで挟むことはできた。一応クリップ型スタンドの仕様では幅70mmまでとあって、かつIDOL4を挟んだ際の残りの隙間は0.5mmもない感じなので、たとえばZenfone3では無理だろう。もちろん反対側の支えの部分がその分狭くなるので若干不安定にはなる。 IDOL4の側面には中央より下にボタンが存在しな��ので、リバーシブル機能を利用すればかなりの角度調整が可能になる。と考えると100均のクリップ型スタンドとは実はかなり相性がよかったりする。

(2016/12/16追記) ステレオスピーカーがついてるからとIDOL4をゲーム目的で買うのは避けた方がよいかもしれない。スマートフォン向けのゲームの幾つかはROOT権限を取っている端末では起動しないよう細工がしてあるが、どうやらIDOL4は出荷状態でROOT取得済みと判定されるらしく、これらのゲームは起動時に弾かれる。とりあえず、パズドラとFGOは起動せず、モンストとロードラとシャドバは起動した。 前モデルのIDOL3でもOSバージョンアップ後に同様の状態になり、今後のアップデートで解消するとの話もあるので、IDOL4もひょっとしたらいずれ修正されるかもしれない。 (2017/5/24追記) FGOは動くようになった。ちょっと触った感じでは普通にプレイできそうだが、長時間プレイに堪えられるかは分からない。 (2018/1/10追記) 知らないうちにパズドラも動くようになってた。ただし、4:3と16:9の縮小表示にしか対応してなく、フルスクリーンでは表示できない。

VRゴーグルについて

(2016/12/24追記) VRについてはまだまだコンテンツが揃ってなく、また「VR」であることに価値があるようなものしか存在しないので、個人的にはあまり期待はしていない。またプリインストールされているLittlstarはちゃんと動くが、DMMのVRアプリでは処理落ちがひどくてまともに再生することができなかった。 通常の動画を視聴するためのヘッドマウントディスプレイとしては大きな可能性を感じる。いま時点ではYoutubeくらいしか存在しないが、普段見ている動画を圧倒的な大画面で体感できるインパクトはすごかった。 IDOL4に限らずVRゴーグルの問題の一つに、コンテンツを視聴する前にスマートフォンをゴーグルから都度外してモードを変更する必要があることがある。それに対してIDOL4ではVRランチャーを用意してコンテンツの切り替えをゴーグルを装着したまま可能としているが、いかんせんそのコンテンツの選択肢がLittlstarくらいしかないから実質的に使い物にならない。 もし今後OSにてVRをOSレベルで標準サポートして、全ての表示をVRゴーグル向けにできるようになれば、色々面白いかもしれない。