ASUS Nexus 7 2012 USBコネクタ交換 その2

前回からの続きです。

中国経由で注文した USB コネクタが届いたものの、実は Amazon でUSBコネクタを含むモジュールを購入した方が安いという事実に気がつき、こちらを購入&交換してしまったので、なかなか続きを書くことができませんでした。

しかし今回、交換したケーブルで再度コネクタが破損するトラブルに見舞われ(涙)、もはやこれまでとばかりに重い腰を上げたのでした。

nexus7_2012_connector_fixed1

作業そのものは単純で、4カ所の足をスルーホールに通してハンダで固定し、そのあと端子(5本)をハンダ付けするだけです。
ただし 0.5mm ピッチの端子なので、ハンダごての先端に載せるハンダが多いと、すぐに隣同士の端子がくっついてしまうのでハンダ付け後の導通チェックは入念に行って下さい。最悪ショートさせてしまうと本体が故障してしまいます。

もしくっついてしまった時は、慌てずハンダ吸い取り線で余分なハンダを除去しましょう。
吸い取り線を強く押し当てたり、こすりつけたりすると端子やパターンを痛めてしまうので焦らず慎重に。

nexus7_2012_connector_fixed2

あとは本体とモジュールを繋ぐコネクタの止め忘れにはご注意。
モジュールはコネクタを接続しなくても本体にぴったり収まるよう設計されているので、止めなくてもズレたりしないのでつい止めるのを忘れてしまいます。(自分だけかもしれませんが)

USBコネクタ交換後、無事充電が開始されるようになりました。(^^)

Nexus7 2012 はもうずいぶん前に発売された端末で、LTEに対応していなかったりと旧世代機であることは事実なのですが、保守性が高い設計でかつ故障箇所もある程度絞り込めているので、大事に使えばまだまだ現役で頑張ってくれる端末です。

Firefox OS Bluetooth API の翻訳(と試行錯誤)

このエントリは MDNやFirefox OSのドキュメントをみんなで翻訳! Advent Calendar 2015 の 21 日目 です。

Bluetoothマネージャと設定操作に必要な Setting API あたりを翻訳してみました。
初めての翻訳作業でしたが、初日のUemmra3さんの投稿などを参考にさせていただきながら、色々悩みつつも楽しんで作業しました。

訳したのはこのあたり↓です。
BluetoothManager (Firefox OS)
デバイス設定の利用

基本自分は締め切りに終われないと動かない(動けない)人なので、ウィキペディアとか自主的に書いてる人本当にすごいなあと思います。

今回もそうなんですが、作業開始からある地点を超えると、どんどん作業速度が増してくるんですよ。で、そのスピードに乗れると、今度は作業そのものが楽しくなってきて、気がつくと時間を忘れて没頭してたりするんです。
(ただしその地点をいつ越えられるかが分からないので、それまでは終わりの見えない悶絶タイムが続くわけですが)

今回 Firefox OS の bluetooth まわりを翻訳してみようと思ったきっかけは、Firefox OSで bluetooth がらみのアプリを作りたいなとのほほんと思いついたからなんですが、名乗りを上げてからよくよく調べてみると、bluetooth 関連のAPIは認定アプリ(内部アプリとか公認アプリとか呼ばれていたりもします)に属するAPIで、セキュリティの観点から通信事業者やOEM事業者、つまりプリインストールされるアプリにのみその利用を限定されてたんですね。

どおりでテストプログラム書いて BluetoothManager オブジェクトとか取得しても null 返ってくるわけですよ・・・

ドキュメントちゃんと読めって感じです。訳して下さった方ごめんなさい。というか翻訳作業者が何やってるんだって感じですが。

で、そもそも触れないAPI翻訳したって仕方ないじゃないの、とやさぐれてたんですが、久しぶりに引っ張り出してきた Firefox Flame の開発者メニューを眺めてたらこんな項目を見つけて釘付けに。

flame_unlock_privilages

何この危険そうな感じの素敵なスイッチ。押してみよう。

2015-12-22-02-37-14

セキュリティを解除した上にデータまで削除。
たぶんよい子は押しちゃいけないやつです。でも押す。

2015-12-22-02-37-23

この画面のあとボタンを10回押すとFASTBOOTの画面が表示され、本当に真っ新な状態でデバイスが起動しました。

期待をこめて、Bluetooth Managerを取得してコンソールに出力するだけの簡単なコードを実行してみます。

// Bluetooth Manager 取得
bluetooth = window.navigator.mozBluetooth;
console.info("mozBluetooth", bluetooth);
console.info("BluetoothManager.enabled", bluetooth.enabled);

すると・・・

console_log

ちゃんとオブジェクト返ってきてます!成功です!!

・・・と、思ったんですが、よく見るとたった一つしかない .enabled プロパティが取れていません。(涙)
.getAdapters() メソッドも叩いて見たのですが、やはりこちらも空っぽの配列が返ってくるだけ。
つまりオブジェクトが取れただけで、あとは何もできないんです。

Firefox WebIDE は認定アプリのデバッグは正式にサポートしていないし、そもそもコンソールのデバッグにも限界を感じ始めました。そこでない知恵を絞って色々考えてながら調べてゆくと、Android SDK にバンドルされている Android Monitor が使えそうだということに。

Android Monitor | Android Developers

ええもう翻訳時間よりデバッグ時間の方が長くなってます。

実は BluetoothManager は、マネージャーと言いつつも Bluetooth アダプタの取得と bluetooth の有効/無効の監視くらいしかできなかったりします。割と守備範囲の狭い子なんです。

そこで Settings API を使って Bluetooth の状態変更を任意に発生させ、イベント発生を拾えないかテストしてみました。

新たに追記した Setting API はこれだけです。

// Setting API の取得と lock オブジェクト作成
var settings = window.navigator.mozSettings;
var lock    = settings.createLock();

// 設定取得
var setting = lock.get('bluetooth.enabled');
setting.onsuccess = function () {
    console.log('setting.result', setting.result);
};
setting.onerror = function () {
    console.warn('setting.error', setting.error);
};
// 設定変更
var result = lock.set({
    'bluetooth.enabled': true
});
result.onsuccess = function () {
    console.log("bluetooth settings has been changed");
};
result.onerror = function () {
    console.log("An error occure, the bluetooth settings remain unchanged");
};
console.info("result", result);

その実行結果がこちら。
(読みにくくてすみません)

12-22 00:17:01.346: I/BlueToothTest(5221): Content JS INFO: mozBluetooth [object BluetoothManager] 
12-22 00:17:01.356: I/BlueToothTest(5221): Content JS INFO: BluetoothManager.enabled  
12-22 00:17:01.676: I/BlueToothTest(5221): Content JS LOG: bluetooth settings has been changed 
12-22 00:17:01.746: I/GeckoDump(2449): [system] [SettingsCore][2851.691] observing settings bluetooth.enabled changed to true
12-22 00:17:01.746: I/GeckoDump(2449): [system] [AirplaneModeServiceHelper][2851.694] observing bluetooth.enabled : true
12-22 00:17:01.746: I/GeckoDump(2449): [system] [AirplaneModeServiceHelper][2851.695] observer for bluetooth.enabled found, invoking.
12-22 00:17:01.746: I/GeckoDump(2449): [system] [AirplaneModeServiceHelper][2851.696] unsuspending: bluetooth.suspended
12-22 00:17:01.746: I/GeckoDump(2449): [system] [AirplaneModeServiceHelper][2851.696] writing {"bluetooth.suspended":false} to settings db
12-22 00:17:01.746: I/GeckoDump(2449): [system] [SettingsCore][2851.697] writing {"bluetooth.suspended":false} to settings db.
12-22 00:17:01.796: I/GeckoDump(2449): [system] [SettingsCore][2851.741] observing settings bluetooth.suspended changed to false
12-22 00:17:01.796: I/GeckoDump(2449): [system] [AirplaneModeServiceHelper][2851.741] observing bluetooth.suspended : false

ログを見る限りでは Setting API で Bluetooth の有効に成功しているし、実際 Setting API の .onsuccess() コールバック関数では設定変更のイベントも取得できているんですが、肝心の BluetoothManager が設定の変更を検知してくれないんです。

そもそも .enabled プロパティは相変わらず null だし、そもそもあるはずの Bluetooth アダプタが返ってこないのもおかしい。

もはやソースコードを確認するしかない。
他のプラットフォームなら多分諦めてますが、こんな時ソースコードがJavascriptで書かれているのが有難いです。

githubを彷徨って、多分これが BluetoothManager のソースコードだと思われる箇所を発見。

gaia/apps/bluetooth/js/modules/bluetooth/bluetooth_adapter_manager.js

しかし .enable プロパティが定義されていない。あれ?間違えた?
ここで初期化された後どこかで追加されるとか。いや、そんな追いにくいコード書くかなぁ。
システム構造の基本知識がないから判断に迷うところです。こんな事なら Firefox OSのコードリーディングに参加しておくんだった・・・

gaia/apps/system/js/bluetooth_v2.js

あれ、bluetooth_v2.js なんてソースコードがあるぞ?
こっちには .enabled が定義されてる。ひょっとして flame に入れた OS のバージョンが古い?いやいや Latest master builds なんですけど・・・。

と、色々試行錯誤しているうちに時間切れになってしまいました。
ここまで読んで下さった人、本当に申し訳ない。でもありがとうございます。

今回の経験を通じて問題解決のための手数が増えたので、一応得るものはあったのですが、やっぱり解決にたどり着けなかったのは悔しいです・・・というか気になって仕方がないです。

あと後半は脱線気味でしたが、自分はやはり bluetooth まわりを習得したいです。
でも頑張って作っても自分の開発端末でしか動かせない、配布できないというのは寂しいです。

なのでもし将来的にはマーケットのレビュープロセスで配布可能になったり、カメラAPIのように低い権限レベルでも利用可能になると嬉しいです。Mozillaの偉いひと、お願いします。そんな未来がやってくるならデバッグにも身が入ります(笑)

ASUS Nexus 7 2012 USBコネクタ交換 その1

奥さんに譲ったNexus7 2012年モデルが、なにやら充電できないと相談を受けました。
ケーブルを交換してもダメ、純正チャージャーからつないでもダメ。元々少し調子が悪かったので、分解して調べてみることにしました。

ネットで情報を集めてみると、どうやら2012,2013両モデルで同じ症状が発生しているようで、MOUMANTAIさんの公式ブログでも多くの修理事例が載っています。

分解手順を張り切って解説しようと思ったのですが、デバイス分解の老舗「ifixit.com」にNexus7 2012年モデルの分解方法が載っていたので割愛(おい)します。ちなみにこちらの記事ではカッコイイ専用ツールを使って背面パネルを分解していますが、親指のツメでぐっと押すだけで簡単に開きました。超強力な両面テープなども使われていないので気軽に外せるの設計になっているのが好感を持てます。自分の分解人生を振り返っても歴代1位に輝く簡単さです。

20150214_全体図

裏蓋を外したところです。既にUSBコネクタが下部に見えています。

20150214_ねじを外す箇所

USBコネクタの全面にはスピーカーモジュールがついていますが、こちらは3カ所のねじとコネクタを外せば簡単に取り外せます。

OLYMPUS DIGITAL CAMERA

スピーカーモジュールを外すとUSBコネクタが露出します。USBコネクタはマイクジャックと共通のフレキシブルケーブルに接続されています。こちらは5カ所のねじとコネクタを外せば簡単に取り外せますが、コネクタのロックを外す方向だけ少し注意が必要です。

20150214_コネクタ取り外し

こちらはコネクタのロックを解除した直後の状態です。上図の矢印の報告にロックを持ち上げることでコネクタとフレキシブルケーブルを分離することが出来ます。

20150214_導通チェック

ここからが肝心の充電不良の原因調査です。
かなり強引な方法ですが、5Vの充電器に繋いだ状態のUSBケーブルを取り外したUSBコネクタに接続して導通チェックしてみます。

マイクロUSBコネクタの場合、1番ピンと5番ピンにそれぞれ+5VとGNDが接続されているので、この間の電圧を計って電圧が来ていればOKです。

・・・あれ、電圧出ないな・・・

20150214_コネクタ割れ

ハンダ割れも疑いましたがどうやらそうでもなさそうで、しかし何となくコネクタの端子部分を覗き込んで納得しました。画像では見にくいですが、内部の端子の両側が欠けて半分ほど消失しています。どうやら3歳の息子が充電中に無理矢理ケーブルを引き抜いたらしく、恐らくその際に端子の両端に負荷が掛かって欠けてしまったのではないかと思われます。

Nexus7のコネクタの耐久性が低い可能性もありますが、これってマイクロUSBのBコネクタの構造上の問題のような気もします。しかもトラブルが発生した場合、比較的安価なケーブルよりも機器側が破損してしまうというのはかなり致命的。

そう考えると最近あまり見かけなくなったMini-Bコネクタの方が優秀に思えてきました。ちょっと時代遅れっぽい感じで見ていたのですが、改めます。ごめんMini-B。

たまたま手元に秋月電子で購入したBコネクタがあったのですが、外側の形状が異なるため残念ながら使えそうにありません。やはりNexus7用の交換用コネクタを探す必要がありそうです。

5分くらい悩んで結局Aliexpress.comのこのショップで購入。2個で1,176円は高いですが背に腹は代えられません。

ちなみにMOUMANTAIさんでも1個から販売しているので、中国からの発送という配達スリルがご不要な方はこちらをおすすめします。MOUMANTAIさんはクロネコメール便で無料発送してくれるので、コネクタ1個あたりの単価で考えるとAliexpress.comで購入するのと大差ありません。自分大失敗。

とりあえず気を取り直して、中国からコネクタが到着するまで時間があるので、今日は破損したコネクタだけ外しておくことにしました。

20150214_コネクタカット

まずはUSBコネクタを固定している、4つの羽根のような部分から取り外します。
本来はハンダごてでハンダを溶かしながら、少しずつ持ち上げてやるのが正しいやり方なのかもしれませんが、自分はワイルドにニッパーで切断してしまいました。羽根の残骸はUSBコネクタ撤去後に除去してやればよいので合理的です。

はい、ここまではよかったんです。

20150214_パターン飛ばした

パターンからUSBの端子を外して撤去完了・・・のはずがここで大失敗。
上の写真でお気づきの方もいらっしゃるかもしれませんが、5本あるはずのパターンが3本しか残っていません。そう、両側のパターン飛ばしてしまったのです! orz

こんなことならいっそフレキシブルケールごと購入すれば良かったじゃん・・・と嘆いても後の祭り。アフターフェスティバル。ここから何とかするしかありません。

泣きながらカッターを取り出して、フレキシブルケーブル表面のマスクをカッターの刃の反対部分で少しずつ慎重に削り始めました。そう、ジャンパーするのです。

20150214_マスク削り

両側のマスクを削り終えたところです。

先ほど書いたようにマイクロUSBの両端はそれぞれ+5VとGND。そのためどちらも広い面積で基板上に印刷されているため比較的簡単に作業を進めることができました。まさに不幸中の幸いです。

20150214_ハンダペースト

露出したパターンにハンダペーストを塗りつけてハンダのノリを良くします。
いまさら気がつきましたがプリント基板には使用不可でした。フレキなので多分セーフ。

20150214_ジャンパ

で、最終的にできあがったのがこちら。
写真だと分かりにくいですが、割と綺麗にハンダがのってます。

ひとまず今日はここまで。
中国からコネクタが届いたら、続きます。

2016/06/11 追記
実際にコネクタを交換した時の記事はこちらから

USBシリアル変換アダプタ(CP2102)からDTR信号を引き出す

前回の投稿の続きです。

Arduino公式ドキュメントによれば、Arduio Pro Miniはプログラム書き込み時にリセット信号をGRNピンに送信する(またはリセットボタンを毎回押す)必要がありますが、私が購入したUSBシリアル変換アダプタ(CP2012チップ使用)には、その機能がなかったため、アダプタを少しだけ改造してみました。

CP2102_usb_serial_adapter

最初はピンヘッダのひとつに「RST」という記載があったので、てっきりこれがArduinoのリセットに使えるとばかり思っていたのですが、CP2012のデータシートを確認したところ、CP2012をリセットするための信号でした。ちゃんとデータシート読まないとダメですね(汗)。

CP2012_DTR
その代わり?28番ピンにDTR(データ端末レディ)信号が出ているのを見つけました。
28番ピンは何処にも接続されていなかったので、この信号を何とかしてArduino Pro Miniに繋いでやることにします。

CP2102 howto

具体的には、RST用のピンヘッダを拝借して、代わりにDTR信号を送ることにしました。
最初はRST用のピンヘッダから9番ピン(RST)へ繋がっているパターンをカットするつもりだったのですが、途中に抵抗R3がハンダ付けされていたので、こいつを外してパターンカットの代わりとして、さらに空いたランドに積層セラミックコンデンサを取り付けました。

capacitor 0.1μF (104)

積層セラミックコンデンサは0.1μF(104)を使用しています。Arduino公式の回路図を見ると、DTRからRESETへのラインには0.1μFが入っているので、積層セラコンを入れずに直接28番ピンをRSTピンに繋いでも動作するかもしれません(未検証ですが)

CP2102_modified

できあがりはこんな感じになります。
積層セラコンの足はなるべく短くカットしてみました。長すぎると抜き差ししているうちに指が当たってパターンごと剥がれる事故が発生するかもしれないので。というかしました。(涙)

28番ピンには作業前に少しだけハンダをのせておくと作業がしやすいです。
ただし0.5mmピッチなので隣のピンとくっついてしまわないように注意して下さい。

arduino_pro_mini_connected

Arduino Pro Miniと接続してみました。こうしてみるとPro Miniの小ささが際立ちますね。
小さなデバイスを作りたいユーザにとって、この小ささと低価格(互換機だとさらにお安く!)が大きな魅力です。ブレッドボードに直接刺さるというのもお手軽で良いですね。

もし安価にArduinoを試したい!という方はぜひチャレンジしてみて下さい。
もちろん最終的には自己責任でお願いしますが、もし質問などあればコメント欄にお願いします。m(_ _)m

Arduino Pro Mini 互換 起動メモ

Arduino Pro Mini Compatible

AliexpressでArduino Pro Mini互換機を購入しました。
USBシリアル変換アダプタ(CP2102)付きで1セット4ドルちょっとという破格のお値段でした。
何よりもArduino Pro Mini初体験ということで、色々とはまりどころもあったのでメモしておきます。

Arduino Pro Mini Compatible
Arduino Pro Mini Compatible

駆動電圧は2種類存在

まずArduino Pro Miniには5V版と3.3V版が存在します。
これは使用されているマイコンATMEGA 328Pの仕様として、最大動作速度が供給電圧に依存していることに起因しています。データシートを確認すると4.5V以下の電圧で使用する場合は最大動作速度が線形に変化することがわかります。

ATMega328P Speed Grades

今回私が入手したのは5V版ですが、供給電圧を3.3Vに変更することと、スケッチの「ツール」メニューから「Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328」を選択すること以外は特に利用方法は変わりません。

Microprocessor Board Select

プログラム書き込みにはUSBシリアル変換アダプターが必要

Arduino Pro Miniの最大の特徴がこれで、Arduino UNO等には標準で装備されているデータ書き込み用Micro USBコネクタが存在しません。このためUSBシリアル変換アダプターを本体のTX/RXピンに接続して、アダプタ経由でプログラムを書き込むことになります。
ちなみにこれはVCCとGNDを接続するのと同じく必要最低限の準備であり、実際には後述するデータ端末レディ(通称DTR。シルク基板上にはGRNと表記)ピンを接続しておかないと、プログラム書き込み時に毎回リセットボタンを押す事になります。

プログラム書き込み時には毎回リセットが必要

今回自分がつまづいたのがここでした。Arduino UNOと同じ感覚でスケッチをArduino Pro Miniに描き込もうとすると、実行時に「マイコンボードに書き込もうとしましたが、エラーが発生しました」というメッセージが表示されます。

avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude done.  Thank you.

原因はプログラム書き込み直前にArduino Pro Miniをリセットしないと書き込みが許可されず、結果としてタイムアウトしてしまうというものでした。

当初はこちらのサイトを参考にして上記ログが出力される直前にArduino Pro Mini本体にあるリセットボタンを押してリセット信号を手動で送出していましたが、毎回押すのが面倒な上に、タイミングが結構難しいので何度も失敗するとストレスがたまります(笑)

この問題の解決策は、プログラム書き込み時に使用するUSBシリアル変換アダプターのDTR信号ピンを、Arduio Pro MiniのGRNピンに接続してやることです。Arduino Pro Mini用と謳われているUSBシリアル変換アダプター(例えばスイッチサイエンスさんで販売しているこちらの商品とか)であれば、このあたりのお約束は特に意識する必要がないと思いますが、自分が入手したCP2102チップを用いたUSBシリアル変換アダプターには実はこの信号がCP2102チップから引き出されていなかったために、結果として変換アダプタを改造してやる必要がありました。

このCP2102のUSBシリアル変換アダプタの顛末については次回詳細に述べたいと思います。→書きました

OSX MavericksでApache使うときの覚え書き

とりあえず以下の3つ覚えておけば何とかなるかと。

$ sudo apachectl start
$ sudo apachectl stop
$ sudo apachectl restart

というかマニュアル見た方が早い?

$ sudo apachectl -man
Usage: /usr/sbin/httpd [-D name] [-d directory] [-f file]
                       [-C "directive"] [-c "directive"]
                       [-k start|restart|graceful|graceful-stop|stop]
                       [-v] [-V] [-h] [-l] [-L] [-t] [-T] [-S]
Options:
  -D name            : define a name for use in <IfDefine name> directives
  -d directory       : specify an alternate initial ServerRoot
  -f file            : specify an alternate ServerConfigFile
  -C "directive"     : process directive before reading config files
  -c "directive"     : process directive after reading config files
  -e level           : show startup errors of level (see LogLevel)
  -E file            : log startup errors to file
  -v                 : show version number
  -V                 : show compile settings
  -h                 : list available command line options (this page)
  -l                 : list compiled in modules
  -L                 : list available configuration directives
  -t -D DUMP_VHOSTS  : show parsed settings (currently only vhost settings)
  -S                 : a synonym for -t -D DUMP_VHOSTS
  -t -D DUMP_MODULES : show all loaded modules 
  -M                 : a synonym for -t -D DUMP_MODULES
  -t                 : run syntax check for config files
  -T                 : start without DocumentRoot(s) check

上記マニュアルには載ってないけれどconfigtestも使えるみたいです。

$ sudo apachectl configtest
Syntax OK

Mac版 Google Chrome の Local Storage の場所

JavaScriptの開発にはJetBrains WebStormとGoogle Chromeの組み合わせが最強だと信じて疑わない自分です。おかげでFireFox全然使わなくなっちゃいました。

で、今回開発環境を引っ越す必要があり、Local Storage使い回せないかなーと少し調べてみました。目的のファイルは

~/Library/Application\ Support/Google/Chrome/Default/Local\ Storage/ 

にあります。Local Storageを生成したサイトのURL毎に作成されているのですぐ分かると思います。

ShareMarker 1.00 リリースしました

今月半ばに申請を出していたiPhoneアプリ「ShareMarker」がようやく受理されました。

ShareMarker
カテゴリ: SNS
価格: 無料 App

実際にアプリを申請された方のブログなどを拝見していますと、通常アプリケーションをiTunes Connectに送信してからレビュー開始までに1週間程度待たされるものの、実際にレビューが始まると約1日くらいで結果が分かると書いてあったのですが、ShareMarkerの場合、レビュー開始までに1週間、その後レビュー完了までさらに2週間を要しました。最初だから時間がかかったのか、画面遷移が多いのでレビューに時間がかかったのかは不明ですが、ここまで2週間ずっとモヤモヤしていたのでとりあえずホッとしたというのが正直な感想です。

せっかくなので、アプリの宣伝をちょこっとだけ。

ShareMarkerは自分だけが知っている(はず)お気に入りの場所を共有するサービスです。
気に入った場所・お店を見つけたら、写真を撮って、コメントを書いて、地図上に貼り付けることで友人達と情報を共有することができます。

こうしたサービスは、例えば大手サイトなどでも似たようなものを見かけたりしますが、個人的な狙いとしてはもう少しローカルな、地元の人たちが気軽に訪れる場所とかお店をメインに集めていきたいと考えています。

現在は札幌市内、特にすすきの周辺(笑)のお店情報が充実しているわけですが、狙いがローカルなのでこんな感じになります。こういう小さな輪が、全国あちこちに広がればいいなと考えています。

久しぶりに帰省した友人連れて飲みに行くときに「あの店どこだっけな」的な使い方をしてもらったり、友人が旅行先で投稿したマーカーを見て「へえ、素敵な場所だな」と興味を持ってもらえたら最高ですね。

アプリ的には機能に関してまだまだ不親切な部分があるのと、友人間での情報共有の手段をもっと充実させないといかんなあと思っています。
使ってみての感想・要望などあればコメントお願いします。

AppStore経由でのXcode 4.2アップデートにハマる

Xcode4から、入手先がAppStore経由でのダウンロード方式に変わったわけですが、これで見事にハマりました。
正確にはXcodeではなくAppStoreなんですが。

Xcode4.2にアップデートしようとしたものの、1.8GBもあるファイルを一気に落としきれず、一旦中断。
ダウンロード途中のファイルは一時フォルダに格納されてレジューム状態に入るため、再開すれば中断した状態からダウンロードが再開される・・・はずだったんですが、これがいつまでたっても再開しないのです。

AppStoreを立ち上げ直したり、アカウントをサインアウト&サインインしてみても効果なし。
AppStoreのメニューには[Store]→[ダウンロードが完了していない項目があるか確認…]という、いかにもそれらしい項目は存在するのですが、こちらをクリックしても「全てダウンロードされています」と表示されるだけ。

諦めてXcode4.1で開発続けようとも思いましたが、残っている作業はiOS5での実機テストだったので、SDKがないことにはインストールもできません。ほとほと困ってしまいました。

で、ひょっとしたらレジューム状態の一時ファイル消しちゃえばいいんじゃない?と思いついたわけです。

結果的にこれがアタリだったわけですが、まず一時ファイルの格納先がわからず調査。
するとAppStoreにデバッグモードなんてナイスなモードが存在することが分かりました

Where does the Mac AppStore download temp files to
http://www.ryanragle.com/index.php?/site/comments/where-does-the-mac-app-store-download-temp-files-to

具体的には、ターミナル上から「defaults write com.apple.appstore ShowDebugMenu -bool true」と叩いてからAppStoreを立ち上げると、メニュー最後尾に「Debug」が追加されます。ここから「Show Download Folder…」を選択すると、ファイルの格納先が表示されます。私の環境では「/private/var/folders/0s/[英数字の羅列]/C」というパスでしたが、このあたりは環境によって異なってくるかと思われます。

で、そのフォルダ直下にあった「com.apple.Xcode.501」フォルダをまるっとゴミ箱へ放り込み、AppStoreを起動します。
すると「アップデート」のアイコンに「①」というバッジが表示されており、クリックするとXcodeがダウンロード開始をゼロの状態で待ち受けていてめでたしめでたし、というわけでした。

ちなみにインストール完了後、自動的にXcodeが4.2にアップデートされるわけではなくて、アプリケーションフォルダにある「Install Xcode.app」を起動することでXcode 4.2への更新が始まります。なんで?って感じなんですけどね。恐らくはAppStoreのレジューム機能を活用したかったのではないかと邪推するわけですが、それにしても直感的でないですよね。アップルらしくないというか。

iPhoneのファームウェア置き場

iPhoneアプリを開発していると、様々な実機でかつ様々なOSバージョンでテストする必要に迫られるわけですが、肝心のOSファームウェアをAppleが公開していません。

iTunes経由でファームウェアの復元を行う場合、Windows環境であればctrlを、Mac環境であればoptionを押しながら「復元」ボタンを押せば、復元対象となるファームウェア(.ipswファイル)を指定できるわけですが、ローカルに保存されるファームウェアは最新のイメージを除いて全て削除されてしまう(少なくともMac環境では)ため、毎回アップデートをかける前に1世代前のファームウェアを別のフォルダにコピーする、という作業を怠ってしまうと取り返しの付かないことになってしまいます。

そこで必然的にグレーなROM置き場が必要になってくるわけですが、私が見つけたのはここ。
iPhone以外のアップル製品のファームウェアも置いてあります。

iPod, iPhone and iPad Firmware Download
http://www.felixbruns.de/iPod/firmware/

上記サイトはこちらのサイトを辿って見つけました。(ありがとうございます)

iPhoneOSの保存先
http://pentan.info/iphone/iphone_os.html

ちなみにMacだと、iTunes経由でローカルに保存されるファームウェアは
/Users/[ユーザ名]/Library/iTunes/iPhone Software Updates
に格納されているのですが、OS X 10.7 Lionでは隠しフォルダ扱いになってしまい、Finder上に表示されません。
常に表示状態にする
にはターミナル上から「chflags nohidden ~/Library/」と叩くと見えるようになります。
非表示状態に戻すには「chflags hidden ~/Library/」です。

参考サイト:
OS X 10.7 Lion で隠しフォルダになったライブラリを常に表示させる方法
http://tukaikta.blog135.fc2.com/blog-entry-166.html