![Xcodeのバージョンを上げずに、新しいOSが入った端末でデバッグする方法(iPhoneのOSをアップデートしちゃったあと)](https://cdn-ak-scissors.b.st-hatena.com/image/square/337ba83b4405e5c7354bf66b71109d8dce5a95f5/height=288;version=1;width=512/https%3A%2F%2Fsussan-po.com%2Fimg%2F0-site-ogp.jpeg)
効率よくiOSアプリ開発を行うために、効率よくデバッグを行いたいですよね。 このエントリでは「print文を書く以外デバッグの方法を知らなかったあの頃の自分」を初級者と定義して、自分がやってるデバッグ方法について書いてみます。 Xcodeデバッグ術 1. printを使わずに変数の中身を確認する age, name, coverImage という以下の3つの変数が宣言されています。 let age = 27 let name = "Ryosuke Hiramatsu" let coverImage = UIImage(named: "sample.jpg") これらの変数の中身をチェックしたい時、printで出力するのでも良いですが、それでは出力する値を変えたくなった時(print(age)をprint(age*2+1)に変更とか)に再度ビルドが必要になって時間がかかります。 printで
WebエンジニアのためのiOSデバッグ速習会@Wantedly に参加してきたので、内容を忘れないようまとめました。 wantedly.connpass.com 参加者は事前に Xcode を自分の PC にインストールしておき、講師の人が説明した後に実際に手を動かして確認していく、というスタイルでした。 また速習会中は、Sync を使って参加者同士がコミュニケーションを取るというのは、独特で面白かったです。 講師は @hedjirog さんでした。 やったこと 講師の方が資料を用意してくださったので、それに沿って以下のようなことをやりました。 テーマは iOS アプリのデバッグです。 使用したのは Xcode 7.1.1 です。 題材アプリ Artsy のインストール ブレークポイントを配置して任意のコードで実行を止める ビューデバッガでビュー構造からクラスなどを特定する chisel
個人開発者の方はこれで結構救われるんじゃないかな? Cocos2d-xを使うゲームはC++で記述するので、メモリ関連のバグに悩まされるケースが多いと思います。Xcodeでデバッグしてその場所を突き止められるのならいいのですが、メモリのオーバーランなんかだとしばらく問題なく動いた後に突然訳のわからないところでエラーが出てアプリが落ちるということになってしまいます。こうなると原因を特定することは非常に困難です。コンソールゲームの開発であればグローバルなnewを拡張するなど独自のメモリ管理の仕組みを使ってこれを検出するのが通常のようですが、少々難易度が高いです。自分もどうするか悩んでいたところ、stackoverflowにこんな記事を見つけました。 stackoverflow.com 注目は二つ目の回答。なんとXcodeでそれを検出することができるのだそうです。Edit SchemeのDiagn
Go言語は gdbでのデバッグがサポートされている のだが、OS X でそれを使おうとしたらいろいろ罠にはまったのでここに記しておく。 (このエントリ執筆時の手元の環境は OS X 10.9(.0) Mavericks + Xcode 5.0.1) 罠一覧 OS X 付属のgdbが古い Xcode 5.0.1のclangだとgdbのビルドがこける ビルドするgdbはpython2にリンクさせないとGo付属のruntime-gdb.pyが動かない[1] ビルドしたgdbにコード署名をしないと他プロセスをアタッチできない OS X 付属のgdbが古い Goのコードをgdbでデバッグするには、gdb 7.1以上が必要ということだが、OS X (Xcode?) 付属のgdbは古くて使えない。 手元のバージョンは GNU gdb 6.3.50-20050815 (Apple version gdb-
2013-01-29 初級者向け iOS デバッグ Tips こちらの良記事を拝見しまして、 中級者向け iOSデバッグTips 初級者向けを作ってみようかと。 とりあえず、 ブレイクポイント操作のステップ実行あたりと NSLog周りについて ブレイクポイント操作のステップ実行 まずブレイクポイントの張り方は、 .mファイルの行番号をクリックするだけで有効になります。 ※青くならない場合は、Toolbar上のBreakPointsをクリックしてください。 で、実際に実行し、その箇所にくると処理が止まってくれます。 ※今回はviewDidLoadに記載しているので、いきなり止まります。 そうすると、デバッグエリアが自動的に表示されます。 ここで重要なボタンがあるので、まずはそこから。 とりあえず、左から番号を振ってみましたが 1.Step over 一行ずつ処理を進めます。ただし、メソッドを
導入 iOS 開発者のみなさん、こんにちは。 このブログでは主にチュートリアルだったりフレームワークの紹介みたいなことを書いてきました。 そこで、たまには中級者向けのエントリを書いて「Xcode バリバリ使って、ビシバシ Objective-C 書いてますよ」アピールします。 iOS 開発をはじめて一通り Framework は理解したけど Xcode 使いこなせてる感が足りない方、夢にまで EXC_BAD_ACCESS が出てくる方に参考になる記事となればと思います。 といっても Xcode はマッシブな IDE なので、4つのデバッグツールに分けて「あれ、それ知らなかった!便利じゃん!」な方法を紹介します。 ブレークポイント デバッグには切っても切れない関係ですね。アプリを実行中に指定した行で処理を中断し、そこからステップ実行で細かいデバッグを可能にしてくれます。 ショートカットキー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く