真面目なブログはこっち 👉 blog.s64.jp

Android TV搭載チューナ内蔵STB「PIX-SMB400」のハマりどころなど

待ちに待ったピクセラのAndroid TV搭載STB「PIX-SMB400」が発売された。
これの特徴は、国内のAndroid TVでは珍しく 地上波 / BS / CS のチューナーが搭載されており、また4K出力や4K放送にも対応している。
従来のAndroid TVでチューナが搭載されているものの多くは液晶テレビと一緒になっていたため、テレビごと買い替えが必要だった中これは嬉しい。

いろいろハマりどころや注意すべきことがあったので、これから購入を検討される方向けにメモ。

アンテナケーブルが付属してない

箱の中にアンテナケーブルが入っていない。これはおそらく、この製品が「既存のテレビを置き換える」という用途を想定しているからと思われる。
もし未だテレビを利用したことがない場合、一緒にアンテナケーブルを買っておく必要がある。

私は以下2つを買って組み合わせ使っている。

HORIC アンテナ分波器 BS/CS/地デジ対応 白ケーブル2本付き(S-4C-FB) 40cm BCUV-971

HORIC アンテナ分波器 BS/CS/地デジ対応 白ケーブル2本付き(S-4C-FB) 40cm BCUV-971

LANケーブルが付属していない

同上。

リモコンはBluetooth接続

これはAndroid TV全般に言えることだが、赤外線ではないので注意。Nature Remoなどでリモートコントロールはできない。

電源投入時に自動でテレビが点く

一般的なAndroid TV端末は電源投入時はLauncherが表示されるが、この製品は前回点けていたテレビのチャンネルが自動で点く。
なお、スリープからの復帰時は通常通り前回のアプリ / 画面。

テレビの表示がLive Channelsではなく独自アプリ

これは国内の多くのAndorid TVが該当するが、放送の視聴はLive Channelsからではなく、搭載されている独自アプリから行う。

おそらくこのアプリとほぼ同等だが、外付けではなく内蔵チューナ用にカスタマイズされていたりとパッケージ自体は異なる模様?

スマートスピーカー連携の設定動線が一方のみ使えない

多分これは現行ファームウェア (Build OPR6.170623.013, Revision 4.4.1538216619) の不具合。

設定 → デジタル放送 → カスタム設定 → スマートスピーカー連携 の動線から設定しようとすると、途中永遠にプログレスになってしまい進まない。
TVアプリ → メニュー → 設定 → カスタム設定 → スマートスピーカー連携 から進めると、正常にログイン画面が表示される。

外部Google Assistantから「画面消して」ができない

まず前提知識として、PIX-SMB400はAndroid TV製品では珍しくスリープ(ケータイで言うなら画面ロック)機能がある。
これは大変便利で、たとえば多くのモニタには省電力機能が搭載されているため、HDMIから信号が途切れた時点でモニタのバックライトが消灯したりする。すなわち、PIX-SMB400側をスリープさせるだけであたかもモニタ自体の電源が落ちたかのような挙動を実現することができる。

PIX-SMB400上のGoogle Assistantに対し「画面消して」と言うと、画面を消す(スリープさせる)ことができる。
が、Google Home等に対し「(設定したデバイス名) の画面消して」などと言っても画面を消すことはできない。

ただし、ピクセラ製テレビのスマートスピーカーアプリを経由しようと「ピクセラテレビに繋いで」から「テレビを消して」とした場合、TVアプリを終了させる (= Launcherを表示する) ことはできる。画面をスリープにさせることはできない。

Amazon Prime Videoが観れない

これもAndroid TV製品全般に言えることだが、Amazon Prime Videoアプリが利用できない。

まれにリモコンが音声を認識しなくなる

これはリモコン側の電池を抜いて再度入れるとよい

外部端末からCastを受け付けなくなる

設定メニュー内のストレージとリセット → データの初期化を行ったが解決しなかった。
が、試しに本体裏側の初期化スイッチからリセットを試みたところ、上手く動作するようになった。なんだろう。

Google AssistantからCast中に「音量上げて」というと音量が下がる

これがかなり致命的な不具合。Google Home等の端末から「テレビでSpotify再生して」などと伝えてCastをしているとき、「音量上げて」と言うと音量が下がってしまう問題がある。なお、音量下げてというと正常に音が小さくなる。

定期的に放送が止まる

解決方法を調査中

所感

とりあえず購入後23時間程で気付いた点について書いた。全体としては満足度の高い商品なのだが、いかんせんFire TVをメインで利用した後ではコンテンツに乏しく感じてしまう。
他なにか気付いた点があれば追って記事を出したい。

高田馬場でコオロギを食べた

連日の40度にも達するかという気候の中では、今日はずいぶん涼しい。
都庁を間近で眺めるのは初めてで、試しに写真を撮ってみたものの、どうもこの曇り空ではうすぼんやりとした印象になってしまい、結局Twitterでシェアすることもなかった。

先週、高校時代からの友人より久々に連絡があった。彼女が連絡を寄越す時は、大概パートナーと喧嘩しただとかそういう時だ。
飲みに行こうと、彼女が提案したのはミャンマー料理専門店だった。

ミャンマー料理には馴染みが無い。どんな料理か想像が付かない。そしてどうもその店は昆虫料理を出すらしい。
虫は大の苦手なのだが、何度かためらいのメッセージをやり取りした後、興味のほうが勝った私は承諾した。

待ち合わせは夜。翌月に講師の案件が迫っていたので、日中に取引先との打ち合わせを入れる。なんでも先方が準備するはずだった資料が上がっていないらしく、当日までに準備できないかという相談だった。まあ、これが無ければ講義もままならないし、特急料金で発注頂けるのなら。


18時。遅れると言いつつ時間丁度にやってきた彼女は、最後に会った時から比べてずいぶんとほっそりしていた。ショートカット、ノースリーブ、薄塗りのファンデーション。いつの間にか大人びた彼女に対し、金だけ払ってジムへも通っていない小太りの自分が連れ立って歩く様子は滑稽だっただろう。

高田馬場駅からほど近い、ノングインレイという店。いつも見えるビルの1階に、こんな店があるとは。

店に入ると、白髪のおじいさんが客席に座って何か作業をしている。女性スタッフがたどたどしい日本語で人数を聞く。
2人と答えると、奥から出てきたスタッフや手前のおじいさんが矢継ぎ早に奥の席へと言う。後に調べたところ、このおじいさんはオーナーなのだという。

くすんだ緑色の内装に、壁際にテーブルが置いてある。下町の小さな食堂といったところだ。
店の中央が壁で遮られているが、カウンターキッチンでもあったのだろうか。


お目当ての昆虫料理はメニューの後半にあった。エキゾチックゾーンと銘打たれた料理たちは、当然ながら見慣れないものたち。
写真のとおり、小さめに掲載されているためディテールまではわからないが、それでも十分にインパクトがある。

"いちばん食べやすいかも" という文句から「竹蟲」を選んだが、聞くと今日は無いという。この店のメニューは原則として入荷時のみの提供となり、この日は「竹蟲」と「セミの炒め」は無いのだそう。話ではこの2つとも食べやすいと聞いていたため、出鼻をくじかれた思いだ。
彼女は家でカエルを飼っている。そのためカエル肉は選びづらい。また、サナギは独特の食感がして上級者向けだと聞く。入門以前の私には厳しい。

最終的なオーダーはこうだ:

  • コオロギの炒め
  • お肉とお米の皮なしソーセージ (豚)
  • ピータンのサラダ (正式な名称は失念)

なお、最初 皮なしソーセージ をオーダーしたところ、「今日は牛しかない」と言葉の足りない日本語で数分掛けて伝えられた。仕方なく牛を注文したのだが、何故か実際に提供されたのは豚だった。


さて、肝心のコオロギは明らかにメニューを上回るビジュアルだった。

彼女曰く、コオロギにも複数の種類があるらしい。普段ペットに与えているものはもう少し小さいと言う。
この店は食料品の輸入も行っているらしい。これは所謂 "本場" のコオロギなのだろうか。

勢いよく頬張って戻しても良くないため、まずは片脚から頂く。
あれ、意外といける。もう片脚。案外薄味だ。

どこか懐かしさを感じる。間違いなく初めて食べるのに、以前食べたことがあるかのような感覚になる。
これは、サクラエビだ。パリッとした殻と、中身は空洞。味に至ってはそのもの。
触覚も食べてみる。うん、素揚げしたエビの触覚となんら変わらない。

問題は腹の部分だが、ここも案外普通である。
イメージするとしたら、蒸した葉が詰まっている感じだろうか。とは言っても臭みがあるわけでもない。食感だけである。
独特ではあるが、食べたことのない感覚ではない。

とはいえ、このビジュアルだ。味も食感も食べ慣れているとはいえ、今自分が食べているものを想像すると、一瞬えずきそうになる。
人は見た目やイメージに支配されているのだなと改めて感じる。そういう時は、飲み物で流し込む。ミャンマーのドリンクを一緒にオーダーしておいてよかった。
多分、内容を知らされず、目隠しでもさせられていれば、特段の違和感なく食べてしまうだろう。

皮なしソーセージ、これも美味しい。おそらく掛けてあるのは唐辛子の酢漬けか何かだろう。
私はすこぶる辛いものが苦手だ。ライスが欲しくなる。

ピータンの乗ったサラダだが、これは日本の食卓でも日常的に並ぶ味だと思う。ピータンこそ日常的には食べないが、鶏卵のゆで卵さえ使えば同様の具材でサラダを作ることもあるだろう。
ところでピータンの寒天のような側面には、結晶に似た柄がある。どんな反応でこうなるのだろう。

水を頼むと、琥珀色のお茶が提供される。バニラのような甘い風味があり、美味しい。なんて言うのだろう。もしなら家で飲みたい。

f:id:S64:20180728161451j:plain

彼女のSNSアカウントから拝借した。


3品を食べ終え、腹ごなしに暗くなった高田馬場を散策する。神田川あたりを歩くだけでも、複数のミャンマー料理店を見かける。なんでも高田馬場は「リトルヤンゴン」と呼ばれるほどの大きなミャンマー人コミュニティが形成されているらしい。

30分ほど歩き、駅前まで戻り安いチェーンの居酒屋へ入る。さきほどまでの異国情緒とはうって変わって、疲れた日本人サラリーマンがスマホ片手に酒を飲んだり、スーツを着た仕事仲間と下世話な話で騒いでいる。そういえば、今日はプレミアムフライデーか。

とりあえずビール、というわけでもなく、互いに好きな酒を好きなように注文する。腹が空いているわけでもないので、簡単なナゲットだけ2人でつつき合う。何の変哲もない、スッと箸がのびる味。

世間話、共通の友人の話、アイドルの話、パートナーの話、仕事の話、2人きりだからできるオフレコの話。
最近「LGBTカップルには生産性が無い」なんて話がバズっていたが、大した金額を落とすわけでもなく長時間居座って、これこそ生産性が無いよなぁなんて考えていた。とはいえ、私は代わり映えのしないなんとなく過ぎる時間が好きだ。

彼女は化粧直しで席を立つ。偉いなぁ。学生の頃こそ化粧直しに手間を掛ける時もあったが、最近はめっきりやらなくなった。小鼻の溝が皮脂で浮いてようが、誰も気にしないだろうとパウダーをはたき直すこともなくなった。こんなんだからダメなんだろうなぁ。
自炊もしない私に、彼女がクックパッドからオススメのレシピを選んで送ってくれる。日常的に料理でもしてないと、こういった行動はできないだろう。


「そろそろ出ようか」といって、店を出る。2人で3,000円も飲まなかった。
せっかく高田馬場に居ても、この時間では拝島行きの西武線も出ていない。新宿まで行って、中央線で帰るか。

「なんだか名残惜しいな」なんて言われても、気の利いたアクションが取れない。互いに反対方向の山手線へ乗って、別れた。

この時間に新宿に居ると、高校生最後のクリスマスや社会人1年目の時を思い出して、虚しくなる。最後にはいつも1人になることが寂しい。

水分を失い張り付いたカラコンに忌々しさを感じながら、いっそ今日も新宿で泊まって帰ろうかなどと考えていた。

「基礎から学ぶ Vue.js」の読書感想文

急に片手間で知識が必要になったものの、プラグインとかも開発してるくせに実際のアプリケーション開発レベルの知識が皆無だったので、C&R研究所より出版されている基礎から学ぶ Vue.js (著: mio氏)を読んだ。表紙がかわいい。

基礎から学ぶ Vue.js

基礎から学ぶ Vue.js

以下、読書感想文です。

読むとよさそうな人

  • Vue.jsやほかフロントエンドフレームワークを雰囲気で使っている
  • とりあえず今選んどけば安泰なフレームワークを知りたい
  • なんかVue.jsつらい
  • 猫がすき

向いてる用途

  • 業務でVue.jsを使うために手早く全体的な知識を注入する
  • 一般的な用途とそれに対応するコード片やアイデアを集める
  • Vue.jsで何ができるのか知る

できるようになること

  • 業務でとりあえずVue.js入れる
  • 簡単なアプリを書けるようになる (に相当する機能を網羅できる)

読めない人 (前提知識)

  • webpackなどを用いたモダンな開発現場の基礎を知らない人
  • フレームワークの発想がわからない人
  • HTML / CSS / JavaScriptを業務レベルに書けない人 (ES2015を網羅するまでは不要)

できないこと / 身につかないこと / 向いてない用途

  • Vue.jsで高度なアプリケーションを書くためのハマりどころを知る
  • Nuxt.jsの使い方を知る (基礎は知れるので十分だけどね)
  • Vue.jsのソースコードを読めるようになる、具体的な仕組みを知る
  • webpack等プロジェクトに必要な設定を組めるようになる
  • TypeScriptで利用する
  • Web APIの利用方法など、ビジネスロジックの作り方を知る

感想

期待以上の大変よい本だった。

本自体は終始「Vue.jsの機能をサンプルコードと一緒に紹介」というチュートリアル的な形式だが、ところどころに実際の運用にあたってのアドバイスが挿入されていたり、たとえば序盤でVue.jsのライフサイクルが紹介されていたり、各項目で関連するメソッド等APIが必ず含まれるなど、これから実際に使いはじめ、後々「こうすればよかったのに」という手戻りや後悔が無いよう配慮されていると感じた。

Vuex, Vue Routerの機能紹介も含まれており、この本一冊でアプリを作ることが十分に可能だと感じた。

一方、プロジェクトの構築がVue CLIへ完全にお任せだったりと、セットアップに関する面が手薄い。
またWeb APIの具体的な利用方法がほぼ書かれない (axiosの存在がさらっと話されて当たり前にサンプルコードに出る) など、ビジネスロジックレベルの話はほぼ無い。
これらから、おそらくある程度モダンなWebフロントエンド開発経験が既にあり、新たにVue.jsの導入を検討している開発者を想定している書籍だと感じた。

もし現場の既存システムへVue.jsの導入を検討しているなら、まずは手に取ると良いかも知れない。
集中さえできるなら、5時間もあれば優に読み切れる軽い本だ。

ちなみに、同時に Hello!! Vue.js 最新プログレッシブフレームワーク入門 (著: 那須 理也氏) を買った。重複する部分が大半な中で細かい部分を補い合えるだろう、という想定。次回はこれ。

とりあえずサクッとAndroid JetPack の Navigation Architecture Component を使ってみる


いままでのAndroid開発では、たとえばディープリンクにはGradleからAndroidManifestを書き換える黒魔術を、たとえばルーティングやナビゲーションにはオレオレフレームワークもどきを作って使ってきましたが、Google I/O 2018で発表された Navigation Architecture Component を使うと大変便利でした。
とりあえず使ってみたメモです。

考え方とか構造

  • シングルアクティビティ・マルチフラグメント
  • 最上位の (唯一の) ActivityがToolbarや ナビゲーション用コントロール(BottomNavigation, NavigationDrawer など) を持つ
  • ActivityがNavHostFragmentというのを持ち、そのさらに入れ子でアプリケーションドメインのFragmentが管理・表示される
  • NavHostFragmentが内包するNavControllerというやつがルーティングをしている
    • Fragmentのinstantiateなどはこれが内部でやってくれる
  • ナビゲーション定義はXMLで行い、どのアクションをするかはR.id.*で指示する
  • ディープリンクも同上。権威Activityがすべて受け取り、NavControllerがよしなにルーティングする
    • を実現するために、navigationのxmlをManifest Mergerがパースし、intent-filterを書き換える

作る順序のコツ

各コンポーネントが複雑に絡み合っているので、ゼロから作っていく時は順序にコツがある気がしました。
私の所感としては、

  1. Gradleに依存書く
  2. 内包されるFragmentクラスと各レイアウト
  3. res/navigation/*.xmlの定義
  4. Activityを作る
  5. Fragmentのインタラクションを繋ぎこむ

がスムーズです。

使ってみる

使ってみる。とりあえず「入力された文字をそのまま表示するアプリ」を目指します。

Gradleに依存書く

プロジェクトルートのbuild.gradleへ以下のように書きます。

buildscript {
...
    ext.navigation_architecture_component_version = '1.0.0-alpha01'
...

同ファイルのdependenciesへ以下を追加します。

buildscript {
    ...
    dependencies {
        ...
        classpath "android.arch.navigation:navigation-safe-args-gradle-plugin:${navigation_architecture_component_version}"
        ...

アプリケーションモジュールのbuild.gradle冒頭に以下プラグインを追加します。

...
apply plugin: 'androidx.navigation.safeargs'
...

同じファイルに依存するライブラリを追加します。

dependencies {
...
    implementation "android.arch.navigation:navigation-fragment:${navigation_architecture_component_version}"
    implementation "android.arch.navigation:navigation-ui:${navigation_architecture_component_version}"
...

本質から外れるけれどRelativeLayoutはdon't useでuse ConstraintLayoutらしいので、このサンプルアプリではConstraintLayoutの依存も加えます。

...
    implementation 'com.android.support.constraint:constraint-layout:1.1.0'
...

内包されるFragmentを作る

このサンプルアプリでは以下の画面を作ろうかな、

  • タイトル画面
  • 文字入力画面
  • 結果画面 (そのまま文字が表示される)
  • バージョン情報画面

これらは一般的なAndroidアプリケーション開発となんら違いが無いので、詳細な解説は飛ばします。
また、画面遷移に関わるボタンクリック時のインタラクション等はこの時点では実装しません。要は、

package jp.s64.android.prototype.myechoapplication

import android.os.Bundle
import android.support.v4.app.Fragment
import android.view.LayoutInflater
import android.view.View
import android.view.ViewGroup

class *Fragment : Fragment() {

    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
        return inflater.inflate(R.layout.*_fragment, container, false)
    }

}

程度の記述のみです。

TitleFragment InputFragment
f:id:S64:20180513121614p:plain f:id:S64:20180513121953p:plain
ResultFragment AboutFragment
f:id:S64:20180513122452p:plain f:id:S64:20180513123019p:plain

Google I/Oのサンプルを見る限り、命名規則が従来のfragment_*.xmlやlayout_*.xmlではなく*_fragment.xmlとなっている方がこれからはイケてるみたい。

res/navigation/*.xmlの定義

キモです。resディレクトリでnavigationというディレクトリを作成し、その中に任意の名前のxmlを記述します。私の場合、app_navigation.xmlとしました。
ナビゲーションの対象とするFragmentをひととおり記述します。

<navigation ... >
...
    <fragment
        android:id="@+id/launcher_title"
        android:name="jp.s64.android.prototype.myechoapplication.TitleFragment"
        android:label="@string/title"
        tools:layout="@layout/title_fragment" />

    <fragment
        android:id="@+id/flow_input"
        android:name="jp.s64.android.prototype.myechoapplication.InputFragment"
        android:label="@string/input"
        tools:layout="@layout/input_fragment" />

    <fragment
        android:id="@+id/flow_result"
        android:name="jp.s64.android.prototype.myechoapplication.ResultFragment"
        android:label="@string/result"
        tools:layout="@layout/result_fragment" />

    <fragment
        android:id="@+id/screen_about"
        android:name="jp.s64.android.prototype.myechoapplication.AboutFragment"
        android:label="@string/about"
        tools:layout="@layout/about_fragment" />
...

各要素のandroid:idは遷移先として指定されるものなので、たとえば起動時の画面ならlauncher_*などとするのが良いです。
Aboutが操作フローから独立した画面なので暫定的にscreen_*としましたが、はたして命名のベストプラクティスはなんでしょうか...
android:labelには文字列またはstringリソースが使えます。これはToolbarに表示されるtitleです。

次にルート要素に起動時の初期画面を指定します。

<navigation
    ....
    app:startDestination="@id/launcher_title">
...

TitleからInputへ遷移できるようにします。@+id/launcher_titleのfragment要素内にactionを追加します。

<fragment
        android:id="@+id/launcher_title"
        ... >
    <action
        android:id="@+id/action_launcher_title_to_flow_input"
        app:destination="@id/flow_input" />
</fragment>

同様に、InputFragmentからResultFragmentへ遷移できるようにactionを記述します。

<fragment
        android:id="@+id/flow_input"
        ... >
    <action
        android:id="@+id/action_flow_input_to_flow_result"
        app:destination="@id/flow_result" />
</fragment>

ResultFragmentが入力された文字を受け取れるように、argumentを定義します。

<fragment
    android:id="@+id/flow_result"
    ... >
    <argument
        android:name="input_text"
        android:defaultValue="No Input!"
        app:type="string" />
</fragment>

Activityを作る

MainActivityとでもして作成します。レイアウトは例えば以下のようになります。

<?xml version="1.0" encoding="utf-8"?>
<android.support.constraint.ConstraintLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivityActivity">

    <android.support.design.widget.BottomNavigationView
        android:id="@+id/bottomNavigation"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:menu="@menu/menu_bottom_navigation" />

    <fragment
        android:id="@+id/navHost"
        android:name="androidx.navigation.fragment.NavHostFragment"
        android:layout_width="match_parent"
        android:layout_height="0dp"
        app:defaultNavHost="true"
        app:layout_constraintBottom_toTopOf="@+id/bottomNavigation"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        app:navGraph="@navigation/app_navigation" />

</android.support.constraint.ConstraintLayout>

ポイントはNavHostFragmentが画面全体を覆っていることと、app:navGraphでさきほどのxmlを指定していること。
BottomNavigationViewまたは (DrawerLayoutで包んだ) NavigationView を使うと、app:menuで指定したメニューからよしなに遷移をしてくれます。

今回つくったres/menu/menu_bottom_navigation.xmlの内容です。

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android">

    <item
        android:id="@id/launcher_title"
        android:icon="@drawable/ic_home"
        android:title="@string/title"/>

    <item
        android:id="@id/screen_about"
        android:icon="@drawable/ic_info"
        android:title="@string/about"/>

</menu>

こちらのポイントはandroid:idに指定している内容がapp_navigation.xmlの各fragmentのものであること。ここに指定したものを呼び出してくれます。

Activityのコードを書いていきます。以下のようになりました。

package jp.s64.android.prototype.myechoapplication

import android.support.v7.app.AppCompatActivity
import android.os.Bundle
import android.support.design.widget.BottomNavigationView
import androidx.navigation.fragment.NavHostFragment
import androidx.navigation.ui.NavigationUI

class MainActivity : AppCompatActivity() {

    lateinit var navHost: NavHostFragment

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.main_activity)

        navHost = supportFragmentManager
                .findFragmentById(R.id.navHost) as NavHostFragment

        val bottomNavigation = findViewById<BottomNavigationView>(R.id.bottomNavigation)

        NavigationUI.setupActionBarWithNavController(this, navHost.navController)
        NavigationUI.setupWithNavController(bottomNavigation, navHost.navController)
    }

    /*
    override fun onOptionsItemSelected(item: MenuItem): Boolean {
        return NavigationUI.onNavDestinationSelected(item, navHost.navController) || super.onOptionsItemSelected(item)
    }
    */

    override fun onSupportNavigateUp(): Boolean {
        return navHost.navController.navigateUp() || super.onSupportNavigateUp()
        //return NavigationUI.navigateUp(drawer, navHost.navController) || super.onSupportNavigateUp()
    }

}

NavigationUI.setupActionBarWithNavControllerでタイトルなどActionBarを、NavigationUI.setupWithNavControllerでBottomNavigationViewのクリックイベント等をNavHostFragmentの内包するNavControllerと繋ぎ込みます。
onOptionsItemSelectedはActionBarのmenuから直接遷移させる時用の記述です。必要に応じてコメントアウトしてください。
onSupportNavigateUpはActionBarでupした際に画面スタックをpopさせるために必要です。また、Drawerを利用する場合はコメントアウトしてあるような記述を用いることで可能です。

Fragmentのインタラクションを繋ぎ込む

各画面のボタンクリック等を繋ぎます。
TitleFragmentは単に以下のような記述を追加すれば十分です。

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        view.findViewById<Button>(R.id.button).setOnClickListener(Navigation.createNavigateOnClickListener(R.id.action_launcher_title_to_flow_input))
    }

createNavigateOnClickListenerには遷移先fragmentのidではなく、actionのidを指定しているのがポイントです。

対しInputFragmentでは次の画面へ値を渡す必要があります。今回の場合は以下のように記述できます。

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        val editText = view.findViewById<EditText>(R.id.editText)

        view.findViewById<Button>(R.id.button2).setOnClickListener {
            Navigation.findNavController(it).navigate(
                    R.id.action_flow_input_to_flow_result,
                    ResultFragmentArgs.Builder()
                            .setInput_text(editText.text.toString())
                            .build()
                            .toBundle()
            )
        }
    }

ResultFragmentArgsはnavigation-safe-args-gradle-pluginが自動生成しているもので、navigationのxmlに記述した内容が元になっています。
同様に、ResultFragmentでも渡された値を表示できるようにします。

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        val args = ResultFragmentArgs.fromBundle(arguments)

        view.findViewById<TextView>(R.id.textView).text = args.input_text
    }

以上で基本的な機能の実装は完了です。

f:id:S64:20180513152738g:plain

らくちん!

ディープリンク対応

app_navigation.xml内のfragment要素に、以下のように記述します。今回はaboutに対応するリンクにしました。

<fragment
    android:id="@+id/screen_about"
    ... >

    <deepLink app:uri="http://example.com/about"/>

</fragment>

AndroidManifest.xmlのActivity内に、以下のように記述します。

...
<activity android:name=".MainActivity">
    ...
    <nav-graph android:value="@navigation/app_navigation"/>
    ...
</activity>
...

以上で完了です。

f:id:S64:20180513153800g:plain

らくちん!

所感

よさそう

※ 今回のコードはこちらに置きました

「詳細! Swift 4 iPhoneアプリ開発 入門ノート」の読書感想文

プログラミング学び直しシリーズの一環として、SwiftおよびiPhoneアプリ開発を総ざらいしようとした。
今回は「詳細! Swift 4 iPhoneアプリ開発 入門ノート Swift 4 + Xcode 9対応」という本を読んだ。

詳細! Swift 4 iPhoneアプリ開発 入門ノート Swift 4 + Xcode 9対応

詳細! Swift 4 iPhoneアプリ開発 入門ノート Swift 4 + Xcode 9対応

以下は読書感想文です。

読むとよさそうな人

  • Androidアプリなどを既に開発している人
  • 既にプログラミングを始めている人
  • iPhoneアプリの概念を知りたい人
  • Swift特有の概念を知りたい人

向いてる用途

  • とりあえずiPhoneアプリ作りの足掛かりを知る
  • iOSアプリで作りたい機能の逆引きをする

向いてない / できないこと

  • 初めてプログラミングをする
  • iPadアプリを作る
  • ストアで配信する
  • 高度な機能を作る

感想

既に他プラットフォームでアプリ開発をしている人間向けの入門書、という印象を受けた。初心者が読んで理解するにはスピードが早く解説も弱いが、その分プログラミングの経験がある人間には小気味良く読み進められる内容だと感じた。Xcodeの使い方としても、他プラットフォームから入った場合に困りそうな操作やレイアウトの設定は網羅されている印象を受けた。

反面、詳細なアプリの設定や高度な機能に関しては解説が一切といってよいほど無いため、これをベースに自身で調べ進める、または次のステップとして他の書籍を当たることが想定されているように感じた。入門として十分であるため、ネガティブには捉えていない。

"初めてのアプリ開発への入門ノート" としてではなく "iPhoneアプリ開発への入門ノート" として読むべきであり、それに十分な内容である。

Mac版LINEで一部AAが豆腐になる問題

例えばこうなる時がある

f:id:S64:20180415152051p:plain

回避策

LINEアプリ上のフォント設定を Times にすると表示できる

f:id:S64:20180415152249p:plain

こうなる。

f:id:S64:20180415151911p:plain

なぜ?

てきとうにやって当たっただけなのでわかっていない。また、検証してない。
どのフォントにどの文字が含まれてどういった場合にフォールバックされるのかもよく理解していない。

ちなみに

期待していた Noto Sans や Noto Sans CJK JP、Source Han Sans とかで試したけどダメだった。
今回の豆腐化してしまう文字自体は Noto Sans Yi に収録されているような気がしている。オールインワンの合成フォントとかあればいけるんだろうか。