PRAY技術的で気になった事を書きます。Androidがメイン。この広告は、90日以上更新していないブログに表示しています。参加しましたちょっと体調が悪かったため、一部しか参加できませんでした。個人メモですが、感想を書きます。dispatch登壇者が高校生なのに衝撃を受けました。「希望の国のエクソダス」という小説をちょっと思い出しました。メソッドディスパッチの挙動がコンパイラの最適化をかけるかけないで変わり、それによって(かなり特殊な)処理の実行結果が変わるようです。speakerdeck.comSwiftの型システムに入門するむずかったです(前提知識が足りなかった)。勉強しようと思いました。参考に入門していきたいと思います。(他の発表を聞いていたため、スライドを見ての感想です)SSL証明書の中間者攻撃ってできるんだっけ?と最初びっくりしましたが、認証局がハッキングされた場合の話でした。公衆無線LANで仕事とかしていいのか悩ましいなと思いました。運用はけっこう大変そう。サーバサイドエンジニアと連携したり、強制アップデートが必要だったり等。ググりましたが、公開鍵ピンニングを採用するべきかは賛否両論ありそうです。一般論ですがサービスの性質に応じて導入を検討、という感じですね。Japan全体的な感想アプリ開発のノウハウが成熟してきているのか、自分の興味のバイアスがかかっているのか、発表するのに深い知識か経験が必要な発表が多いように思いました。圏論とか気になるのでスライド読んで勉強していこうと思います。一つのユースケースでBLE通信とWebAPI通信を行う場合を考えます。書いたように、想定されるエラーを@OnErrorに記述するとします。以下をエラーを想定し、それぞれに例外クラスを定義したとします。(NetworkException)機内モード、圏外とか接続先からエラーレスポンスがきた。(APIBadResponseException)上記のケースをハンドリングしたいとすると以下のような見た目になります。:Completable}問題@OnErrorの記述が多くてメソッドの挙動が把握しづらいですね。上記レイヤーが下位レイヤーの例外をキャッチして、上位レイヤーにふさわしい抽象度の例外を投げるようにします。https://www.amazon.co.jp/dp/4621066056詳しくはEffectiveJavaを読むとして、ざっと理解するには以下が参考になりました。//ハンドリングしなくてよい例外はそのまま流すとやってますが、本当はRuntimeExceptionでラップした方が良いかもしれないです。僕はめんどくさいのでやってないですが。以下のような文があります。実装するすべてのチェックされない例外は、RuntimeExcePtionをサブクラス化すべきですこれに従うなら、ハンドリングしなくて良い例外はRuntimeExceptionにラップして投げた方が良いでしょう。RxJavaには必要であればRuntimeExceptionでラップしてくれるメソッドがあります。例外の見通しが良くなった気がします。冗長になるのでやり過ぎには注意ですね。RxJava前提RxJavaでは例外が投げられた時、Observable#subscribeの引数onErrorにThrowableで渡って来る。})問題どのようなエラーが返って来るかという情報がメソッド定義にない。KClass<*>)ハンドリングして欲しい例外の基準ユーザーが回復可能かどうか。回復可能な場合、ハンドリングしてユーザーに回復方法を伝える価値がある。toast("ネットワーク接続状態を確認してください。toast("リクエストに失敗しました。時間を置いて再度お試しください。//想定してない例外なのでとりあえずな文言を出して、裏でクラッシュレポーティングツールとかに伝えるのが良いんじゃないかと思う。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。