DroidKaigi 2017で登壇してきた - Just for Fun
2日目の16:00から「Error Handling in RxJava」というタイトルで、RxJavaにおけるエラーハンドリングについて発表してきました。 スライド 概要 RxJavaのおさらい Reactive Extensions for Java マーブルダイアグラム RxJavaにおけるエラーハンドリング Catch（エラー発生時にリカバリーを行う） onError：エラーをキャッチする onErrorReturn：エラーをキャッチして代わりのデータを返す onErrorResumeNext：エラーをキャッチして代わりのObservableを返す Retry（エラー発生時に再購読を行う） retry：エラー発生時に再購読する retryWhen：再購読する条件を細かく制御する 基礎編 エラーをトーストで表示する：onError 代わりのデータを表示する：onErrorReturn
Exploring new Android layouts
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
ANDROID IDがどのように生成されているかざっくり調べた - Qiita
ANDROID IDを使用する際の気をつけていること ざっくり以下かなー他にもなにかあれば教えてほしいかなー 「ランダムに生成される64ビットの数値を16進数文字列にしたもの」なので文字数は固定ではない どんなアプリでも同じ値がAPIを通して取得できる ファクトリーリセットすることで値が変わる 同じANDROID IDを持った端末が存在する可能性がある multiple users環境ではユーザごとにANDROID IDが生成されるため、ANDROID IDは端末に１つではない ANDROID IDがどのように生成されているのか とりあえずAndroid Nのコードから見てみる。 ANDROID IDを生成しているのはSettingsProvider.javaのensureSecureSettingAndroidIdSetLockedメソッドだね。 全体の処理は以下のような感じ。詳しくは見
React Nativeはクロスプラットフォームモバイルアプリ開発の夢を見るか #DroidKaigi
This document summarizes a presentation about React Native given at DroidKaigi 2017. It discusses how React Native allows building native Android and iOS apps using React by rendering UI components to native platform views. It describes how React Native maps React components to native platform views, implements native modules to access platform features, and uses the JavaScript bridge to allow cal
「視線」と「目線」 どう違う？
「目線という言葉に違和感がある」というお便りを、何度か頂いています。この言葉は社内でも判断が揺れている言葉です。 「目線」という語はもともと、映画・演劇の世界で演技者が目を向ける方向のことを指す言葉でした。小学館の日本国語大辞典には戸板康二さんの著書「楽屋のことば」の一節が引いてあります。それには「役者が演技中に、月を見あげたり、山を眺めたりする時の、目のつけどころを『目線（メセン）』という。視線とはいわない」とあります。同辞典はその記述のあと「②転じて、一般に視線をいう」とあり、現在の使用状況の実態としては「視線」とほぼ同じ意味です。 ほぼ同じ意味ですので、特段のことがなければ「視線」とするのを原則としてきました。毎日新聞用語集は「通常、一般社会で使わない隠語、品位がなく読者に不快感を与えるような語句は使わない。口語体で一般化している俗語も安易に使うことはしない」としていて、「目線」とい
コードを美しく保つためのたった一つの方法 - ボクココ
ども、@kimihom です。 とあるイベントでエンジニアの方々と話していて話題になった “クリーンなコード” について書いていくとする。 結論から言うと、コードを書かない のが最も美しく保つための条件だと考える。 サービス設計レベルでの"美しさ" を極めよう いくら優秀なエンジニアがサービスを作ったところで、優秀でないプロダクトマネージャーの元で開発をしてはいいコードを保つことはできない。優秀でないプロダクトマネージャーは、機能の多さで他社と差別化をしたり部下の仕事を作ろうとする。この機能が他社サービスにはあるから、うちにも取り入れよう。そんな自社サービスの思想を全く考えない機能をエンジニアに要求するのだ。 その時点で、どんな優秀なエンジニアでも作ったシステムは確実に複雑になる。例えて言うなら、小説家が１冊の本の中にうまく章立てをしてまとめていたのに、全く別の話題をその本に書けと言われて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
