ふとStethoを見てみると、以下の通り1.1.1がリリースされていました。 ここでは、bug fixとstetho-timberが追加された模様。 https://github.com/facebook/stetho/releases/tag/v1.1.1 stetho-timber 自体、okhttpやhttpconnetionのようにpluginとして実装されてます。 なので、build.gradleにtimber向けの行を追加する必要があります。 SetUp stetho-timber add dependencies build.gradle Plant StethoTree on Timber Example… ここでなくても、 onCreate に Timber.plant(new StethoTree()); を加えてあげるだけで良いです。 ここはTimberと同じですね。 Build… and see Google Dev Console 地味に、同じlog文字列に対しては行を折りたたんでカウントしてくれるのが優しいですねMore
Category Archives: Uncategorized
今月のobjc.ioはiOS at Scaleだった
今月のobjc.ioでは、iOS at Scaleということで、iOS開発においてスケールに対する話が中心でした。 http://www.objc.io/issue-22/ モバイルアプリでサービスを提供する企業も、サービスの拡大に伴ってアプリも肥大化してきて、ある程度プロセスの整備も必要になってきたような。読んでみると、だいたいは抱えている問題は同じ感じ。その解決方法も似たようなもの。だけれど、ここに書いているように抽象化したところを除けばその組織ごとの事情によって色々最適化されているのでしょうね。 Square Registerに関する話 http://www.objc.io/issue-22/square.html The Art of Code Review: A Dropbox Story http://www.objc.io/issue-22/dropbox.html 理想と現実のギャップを埋めるために問題を解決していくエンジニアリングを繰り返して、より無理のない安定した開発を目指したいところですね。More
Stethoを使ってAndroidアプリのデバッグを容易にする
Android、iOSのようなクライアントアプリの開発では、特にDB関連や通信環境が絡むデバッグが面倒です。実際にデバッグを行うとき、例えば、Proxyサーバを立てて通信を覗いたり、SQLiteのファイルを直接覗いたりしますね。はたまた、Logの出力を仕込んで、そのログを追うという方法をとることが多いです。 また、単純な通信量であればAndroid Device Monitorなどが使えますが、通信の中身までは見れません。 それらの壁を低くするツールとして、SquareのGitHubから得られるPony Debuggerが有名です。これは、Chrome Developer Tools を使い、通信の内容を簡単に観察したりできるツールです。また、Android/iOSのChromeブラウザであれば、同様にChrome Developer Tools を使い端末上で動作するブラウザの情報を得ることができます。 そして最近、Facebookが出したAndroid向けのStethoを見つけました。リポジトリを見てみると、最初のコミットが2015年1月30日と非常に若いです。これを組み込んだapkではChrome Developer Tools を介し、SQLiteやNetworkの中身を観察することができます。特別なProxyを用意したり、SQLiteのファイルを直接操作する必要もありません。 まだ若いので、使い方とか諸々変わりそうなのでリンクだけ貼っておきます。 http://facebook.github.io/stetho/ https://github.com/facebook/stetho 基本的には、Applicationを継承したクラスをonCreateするときに、合わせて初期化メソッドを追加するだけ。 ネットワークをChromeで見るには少し手間かけますが、Squareのokhttpを通信向けパッケージとして使っている場合、OkHttpClientを初期化するときにデバッグ設定を追加するだけという手軽さ。 これらの機能を、例えばBuildConfig.DEBUGのときだけ有効にするとかしておけば、社内で配布するapkは誰もがChromeさえあれば通信内容を確認するという環境が作れてすごく良さそう。 なお、logcatに以下のようなsocketに接続できたという出力が得られたらネットワークの通信もChrome上で見ることができる状態になります。 Chromeを経由してネットワークの中身を見るとこんな感じ。More
Why The Facebook App is Rated Below 2 Starsを読んだ
最近みたこの記事から、モバイルアプリ開発に関して学ぶことができた気がするので、メモ。 これはメモなので、興味のある方は本文読んだ方が良いです… 最近のiOSのFacebookアプリは、各国で以下のように平均で低いレートを得ています。この記事では、その原因を分析していました。 Breakdown of Issues Reported 以下は、1月1日〜1月15日の間の、USにおけるレビューの内容を集計したものです。 これを見ると、マイナス要因になるレビューは アプリのクラッシュ コア機能 の2つが大きいそう。他にも要因も書かれていましたが、大きくはこの2つのようですね。 リリースサイクルとQAチーム FacebookのiOSチームは、2週間のリリース間隔を持っているようです。また、1週間ごとのスプリントで開発サイクルを継続しているよう。 このYouTube記事によると、FacebookはQA期間を設けていますが、公式なQAチームは存在しないらしいです。その代わり、テストベースの開発に注力しているようです。 “As you may know, Facebook does not have big QA teams…we believe that developers are responsible for their own code, and they’re supposed to write the tests to do that.”- Quote from Alan Cannistraro 実施しているテストツールの一部 以下のようなテストツールを使っているそうです。 Snapshot unit test ios-snapshot-testingのやつですね。GitHubで公開されています。…More
ハイパフォーマンスブラウザネットワーキングを読んでモバイルアプリ開発(クライアント/サーバ含め)に関わる人が知っているべきだと思ったこと
モバイルアプリやWebアプリをテストする上で、それらの構成要素を知ることは非常に大事です。また、モバイル通信環境ではネットワークを考慮した環境への配慮の必要性がさらに大事です。そこで、ハイパフォーマンスブラウザネットワーキングを読みました。その中で、重要と感じたところをメモがてら残しておきます。 ハイパフォーマンスブラウザネットワーキング 始めに 大学や職場では、電波や光の変調技術や伝搬遅延などの基礎、TCPのセッション確立、その上側のHTTP通信の話しまでは知っていたのですが、物理層の端末側状態遷移までは知らなかったです。また、モバイルネットワークでも、基地局や3G/LTE/WiFiなどの切り替えや特性が存在することは知っていましたが、それらが物理層でどういう状態で待機状態になっているか?など知らなかったです。この本では、そこらへんを含めたネットワーキングを全体的に知ることできたことが一番の収穫です。 というのも、モバイルアプリのテストって、PCよりも通信状態によるパケットの損失など、環境に依存する箇所が大きいとつくづく感じているのですよね。そこら辺をある程度ざっくりとテストしはするのですが、不具合解析やよりユーザの利用状況を考えたテストまで踏み込むと、厳密に通信がどのような状態か、まで考慮できた方が良いです。なので、個人的にここはすごく良かったです。 以下、いくつかモバイル通信環境に焦点を当てた上で、個人的に重要だと感じたところをピックアップ。 RRCレイテンシの存在 RRC(Radio Resource Controller)は、モバイル端末が基地局との通信を物理層で制御する機能です。モバイル通信(3G/4Gなど)では、モバイル端末が基地局との通信を物理層で確立した後、TCPの確立などに進みます。それらすべてには遅延が生じるのですが、その一番始めに存在し、モバイル通信固有の機能になります。 このRRCレイテンシは、LTE/3Gでは以下のようなレイテンシが発生するようです。 LTE: 10~100ms 3G: 最大で2秒 なので、モバイルネットワークの場合、HTTPリクエストの到達までにかかる遅延要素は以下になるのですね。 RRCネゴシエーション=>DNSルックアップ=>TCPハンドシェイク=>TLSハンドシェイク=>HTTPリクエスト この遅延を考慮した上で、端末上で動作するネイティブ/ブラウザアプリを設計・実装していく必要が現実世界ではあるのですね。モバイルアプリにおけるテストでは、OS側の責務だからと3G/LTE/WiFiと通信方式が異なる環境下でテスト(というか、動作確認)されることが少なくない気がします。一方で、こういう所はユーザビリティという視点でもアプリの快適さに大きな影響を与えるので、気に留めた方が良いです。 ハンドオーバー LTEでは、基地局から基地局のハンドオーバーに100ms以内の時間かかるそうです。一方、3Gなどでは、数秒かかることも多いそうです。日常的にこういう遅延が発生しているのですね。 ジッタ モバイルアプリケーションの通信では、ジッタと呼ばれる変動的なパケットの遅延が発生するらしいです。ここは知らなかったです。 AT&Tの各種ネットワークにおける、モバイル端末がRRCを行いDNSルックアップに到達するまでの、平均的なレイテンシは以下のようです。 LTE: 40~50ms HSPA+: 100~200ms HSPA: 150~400ms モバイル通信における、実世界で考慮されるトレードオフ バッテリー消費とネットワークパフォーマンス スループットをユーザ個別に最適化するか、ネットワーク全体に最適化するか レイテンシとジッタの考慮 コストとフィージビリティ 国や地域 他の基準 モバイルネットワークへの最適化 バッテリー消費を抑える 無線通信は、ディスプレイに次いで2番目に電力を消費するそうです。また、無線のエネルギー消費量とデータ転送量は比例する訳ではないそうです。 AT&TのApplication Resource Optimizerを使うことで、AndroidやiOSにおけるバッテリー消費量の概算を出せるそうです。やってみよう。 非効率な定期データの送受信を排除する プッシュ通信の活用、データをなるべくまとめる、重要度の低い通信は端末がアクティブになったときにのみ通信する、などを実施する。 ネットワークコミュニケーションとユーザインタラクションを切り離す 変化するネットワークインタフェース状態に対応するデザイン 無線の回線品質は、基地局との距離、混雑度、干渉などにより刻々と変化する 到達不能なホスト 突然のスループット低下やレイテンシの上昇 突然の圏外 エンドツーエンドの通信に置ける帯域幅などの予測は、モバイルネットワークの話しになると有線状態の倍以上の難しさになる バースト的に送受信し、アイドル状態に戻る モバイル端末のインタフェースはバースト的な送受信に最適化されている 多くのリクエストを集約し、できるだけ多くのデータをできるだけ早くダウンロードした上で、通信をアイドル状態にすることが望ましい バッチ処理や、プリフェッチで多くの情報を取得しておくことが大事…More
Selenium/Appium Advent Calendar 2014の23日目の記事に載せた
Appiumを使ってiOS/Androidの要素を取得する方法の数々をポスト。 iOS/Androidにおける、要素の取得方法で普段使っていることをまとめたもの。 話は関係ないですが、Circle CI、Travis CI、Hosted CIと、少しづつiOS/AndroidがビルドできるCIサービスが増えてきましたね。 Enterprise用途でも使えそうなものが散見されはじめているところも、これからに期待。More
Appium1.2.1 released !!
Appium1.2.1がリリースされましたね。 https://github.com/appium/appium 既に、結構お世話になっているのですがAndroidに関してはiOSにくらべて不安定だったり、やりたいことを実現できていないことが多いのですが、今回の更新で少し良い意味で気になった箇所をピックアップしてみます。 いくつか小さな不具合修正や、使いやすさ向上は置いておいて。 iOS fix bug with parsing of binary vs XML plists retry getting screenshot if it fails fix error in getting localized strings XMLの修正や、screenshotのretry処理は嬉しい。特に、screentshotはリトライなくてここで失敗するシナリオもあったし。 あとは、Safariで操作するときの振る舞いが安定してきたみたい?いろいろ改善が見られる。 Android fix handling of IME activation support API level 10 style focused activity strings update api level dependency for the project to 19 fix bug with xpath…More
チェックリストを作るために
最近、チェックリストを作ることがあったのですが、良い書籍を紹介して頂きました。 アナタはなぜチェックリストを使わないのか? この付録にもある、チェックリストを作成するためのチェックリスト この本の内容は、医療現場や航空業界のように、複雑ながらも非常に難しい職種において、どのようなチェックリストが本当に有効なものなのか、ということを多くの物語を交えて説明しています。 以下では要素のみをかいつまんで、要点だけまとめてみようと思います。 ただし、それらを理解して腹をすえるには、本書を読んだ方が良いと思いでしょう。More
問題解決入門を読んで
テストエンジニアをはじめとしたエンジニアの肩書きを持つ方々には、往々にして問題解決能力が求められると思います。最近、私の関わる活動の中でそういう流れが高まってきたので、問題解決入門を読んでみました。 そのまとめをつらつらと。 書籍の詳細には例題やらいろいろ合わせて書かれており、非常に理解しやすかったです。 エンジニアは往々にして問題解決能力が求められることは多いと思いますが、その基礎的な内容を体系的に頭にインプットする、という意味で非常に良い書籍だと思いました。 内容 問題とは 問題とは、目標と現実のギャップであり、解決すべき事柄である 目標 あるべき姿 望ましい状態 期待される結果 現状 実際の姿 予想される状態 予期せぬ状態 数値化可能な目標 定量的目標 数値化が困難な目標 定性的目標 勤労意欲、知名度、満足度などMore
GooglePlayのレビューを新着順に取得する
ちまたで見られるGooglePlayのレビューを取得する記事の多くは、GetリクエストからHTMLのページを取得、その要素から必要なものを取得するという方法でした。 ただし、GooglePlayはデフォルトではレビューの並びが新着順ではありません。 一方、私は新着順の情報が欲しい。 そこで、簡単なスクリプトを作ってみました。 すんなりいくかと思っていたら、Net::HTTPから取得しいたNet::HTTPResponseのbodyをNokogiriに読み込ませていたのですが、うまくパースされない。 そこで解決に至ったまでの作業を備忘録として残しておきます。More