2013年12月16日月曜日

MacOSでのファイルを開くアプリケーションの設定

MacOSでのファイルを開くアプリケーションの設定の覚書。
Windowsでは拡張子別にしか開くアプリケーションの設定は付けられない(と思う)が、Macではファイル単位でもできるし、拡張子単位でも設定できる。

まずファイル単位。ファイルを選択状態にしてマウス右クリック。
「このアプリケーションで開く」で「その他」を選ぶと開くアプリケーションを選択できるので、「常にこのアプリケーションで開く」にチェックを入れると、以降、常にこれで開くようになる。



拡張子別の場合。ファイルを選択し、右クリックから「情報を見る」を選択。
「このアプリケーションで開く」で設定し、「すべてを変更」を押すと、同じ拡張子のものはすべてこれで開くようになる。


2013年12月13日金曜日

Mac用LibreOfficeとApache OpenOfficeについて

ことMac版で、Calcについてのみ言えば、LibreOffice(v4.1.3.2)よりApache OpenOffice(v4.0.1)の方が出来が良い。

LibreOfficeのダメな点は以下の3つ。
・入力中の文字がずれるというか、変な空白が入ってしまう。空白が入るだけでなく、カーソル位置がずれるので文字列編集がものすごくしにくい。
上がLibreOfficeで下がOpenOffice。

・保存のたびに図形の位置がずれたりサイズが変わったりする(変形する)
こちらのほうが致命的。毎回直さなくてはいけない。というか、直しても無駄という話もある。

・デフォルトの図形のアンカーがセルでない
 だから、行の挿入・削除・幅変更をすると図形がずれる。

 ExcelとOpenOfficeはセルアンカー。絶対そのほうが良い。


でもOpenOfficeにもバグがある。
ツールバーのカスタマイズに追加しようとすると、表示が真っ黒になってしまう。
追加からドラッグでツールバーの内容のところに入れようとするとこうなる。
一応入れることは可能で、スクロールすると表示は戻るのだが、ものすごく面倒。

あと、枠線が勝手に変更されてしまう(太くなる)というバグもいる模様。隣接するセル(例えば左右)で両方から枠線設定をするとそうなるような。片方で罫線を解除しても消えないという、ほとんどバグとも言える仕様もある。これは改善してほしい。

・・・

LibreOfficeで知りたいことをまとめておく。上記のバグが直り、これらの設定法がわかればだいぶ使いやすくなるのに。

Calcのデフォルト設定の変更
 図形のアンカーの対象をセルにする
 外部ツールでの編集のツールを変更する

あと、ウインドウの分割が「ウインドウ〜固定〜組み合わせ解除」というわけのわからん方法じゃなくて、素直に固定だけか分割ってしてほしい。

ということで、私はApache OpenOfficeをおすすめ、ということで。

2013年12月9日月曜日

Xcode5;謎のSecurityエラー

Xcode5で(実機をつないで)アプリを実行しようとしたら、こんなエラーが出て実行できなかった。

一度アプリを削除しても、何度やってもダメなのだが、ホーム画面上にはアイコンが出来るのでとりあえずそれを実行してみたら、なんかメッセージが出た後に(はっきり読まなかったので失念)、実行できた。

調べてみると、
http://stackoverflow.com/questions/19112794/xcode-5-could-not-launch-only-reports-security-as-error
の現象が同じではないかと思われた。上記画像もそれから拝借したもの。

どうやら、何らかの原因でこれが発生した時は、開発者が信頼出来ないので起動できないと言っているようなので、ホームに出来たアイコンを手動で起動しなければならないらしい。

実は今2台の開発機で開発していて、いつも使っているのとは違う機械で実行しようとしたらこうなった。2台は証明書などは同じなのだが、何かまだ違う部分があるのかもしれない。

また今度発生したらもう少し調べてみたい・・・とも思うが、いろいろと「あれ」なのでできないかもしれない。

2013年11月29日金曜日

Xcode5上でiOS5のシミュレーターがインストールできたりできなかったりする理由

Xcode5がいくつかのMacに入れてあるのだけど、そのDownloadsにiOS5シミュレーターが出てきたり出てこなかったりして「なぜ?」となっていた。

X-BASIC for iOSもまだiOS5対応をしている(つもり)なので、入れたい。

で、いろいろ調べて分かった、その理由。

「OS X 10.9上のXcode5ではiOS5シミュレーターは新ストールできない」ということだった。
10.8上でならインストールできる。
また、Xcode4.6.xでもインストールできる。

ということで、iOS5でも開発が必要なら、10.8環境を残すか、Xcode4.6.xを残すしかない。iOS7までの開発を一本化したいなら、10.8を残す以外の選択肢はない。

Xcodeのキーバインド設定ファイルの位置

Xcodeの環境を別マシンに移植する際、キーバインド設定ファイルのコピーに手間取ったので覚書。

その設定ファイルは
/Users/ユーザー名/Library/Developer/Xcode/UserData/KeyBindings
の下にある、*.idekeybindingsというファイルに入っている。
*は自分の使っているバインド設定名。

Xcodeを閉じた状態でこれを別のマシンの同ディレクトリにコピーし、Xcode上で設定すれば移植できる。

LibreCalcのデフォルトフォントの変更方法

LibreCalcでデフォルトのフォントの変更に手間取ったので覚書。
2ボタンマウスの利用を前提として書いているので、1ボタンの人は適当に読み替えて。

(1)メニューバーから書式を選択

(2)スタイルと書式設定を選択
 (3)これが出てくるので標準で右クリック
 (4)変更を選択
 (5)フォントを選択し、変更する。


以後、これに従って作成される。

iOSシミュレーターでSafariが起動しなくなったりした時の解決法・・・じゃなくて原因

Xcode上でプログラムを作っていて、iOSシミュレーターで動作させようとするのに、
Safariが起動しなくなった。
具体的には、このようなコードを実行してもSafariが起動しない。

NSURL *url=[NSURL URLWithString:@"http://www.blogger.com"];
// httpがあるので自動的にブラウザが立ち上がる
if ([[UIApplication sharedApplication]canOpenURL:url]) {
    [[UIApplication sharedApplication] openURL:url];
}

最初はプログラムやURLを疑ったのだけどどうにもならなくて、結局iOSシミュレーターで「コンテンツと設定のリセット」をすることで治った。

でもその原因は何だったのか。

調べた結果これだった。

(1)iOSシミュレーター(正確にはXcode)は以下の場所にプログラムの実行コードを作成する
/Users/ユーザー名/Library/Application Support/iPhone Simulator/バージョン/Applications/
バージョンはiOS7.0.3用なら7.0.3になる。
この下にアルファベットと数字とハイフンからなるディレクトリがいくつか作られている。
なお、このディレクトリは、Buildだけでは作成されず、Run後、実際にシミュレーター上にプログラムが起動する直前に初めて作成される。

(2)このディレクトリの内、少なくとも1つはユーザーの作ったアプリケーションであるが、他に6つほど、見に覚えのないディレクトリが存在する。その内容は、以下のとおり。
    Web.app
    StoreKitUIService.app
    WebViewService.app
    MobileSafari.app
    WebContentAnalysisUI.app
    DDActionsService.app

(3)見知らぬアプリのフォルダなので、「消してしまえ」とすると、以後動作がおかしくなる。

という次第である。今回の場合、MobileSafari.appを消してしまったので上記現象が発生したと。

アプリ内で作る中間ファイルなどを確認するために、アプリのフォルダの中を見ることはよくあるのだけど、他のが必要なんて今まで気づかなかった。

・・・と言うか、このフォルダ構成、iOS7.0以降でこうなった気がする。
6.xや5.xの下にはこういうのは出来ていない。

ということで、「フォルダはむやみに消しちゃダメ」というお話。

2013年11月6日水曜日

Mavericksのバグ

Mavericks、どうやらぱっと見ではないけど、深いところにバグが多数いる模様。
とりあえず情報集約開始。

(1)WDの外付けHDDを付けていると、その内容を消してしまう可能性があるらしい。
WDからも直接警告のメイルが来た。うちもまさにそれに相当するので、まだアップデートしてないMacはアップデートを当面しない、すでにMavericksにした機体は当面起動しないことに決定。

(2)ネットワークで共有したWindows7管理下のHDDに大量(GB越え)のファイルを書き込んでいると完全にハングアップしてしまう(電源の強制OFFしかなくなる)。MoutainLionでは同じ作業しても問題なかった。

(3)どうやら動作中にかなり頻繁にネットワークにアクセスする模様。会社ではProxyサーバー経由でネットワークにつながれているのだけど、そのパスワード要求が頻繁に出てくるので気がついた。MoutainLionでは「全く」出てこない。

(4)キーチェーンのパスワードを要求してくるのもバグかもしれない
   (3)とあわせて、もうどうしようもなくなったので、MountainLionに戻した。

(5)USB-ディスプレイでディスプレイを接続すると、その上でのマウスカーソル移動が異常に遅くなる。もちろんこれはドライバ側の問題の可能性もある。また、USBディスプレイをつないでいる状態ではMissionControlによる複数画面切り替えが正常動作しない。正確には、画面は切り替えられるが、ウインドウの画面間の移動を行えない。ウインドウが表示されないから。

2013年10月24日木曜日

Macのシリアル番号の調べ方

iWorkの件でアップルに電話すると、インストールしたMac本体の情報を求められる。

そこで、教えてもらった、本体シリアル番号の調べ方。

(1)メニューバー(タスクバーだっけ?)からリンゴマーク~このMacについてを選ぶ

(2)「バージョン」と書かれたあたりをクリック すると、ビルド番号が表示される



(3)「ビルド」と書かれたあたりをクリック すると、シリアル番号が表示される


以下、この繰り返しとなる。

2013年10月23日水曜日

OS X Mavericks上でのiWorkの'09からのアップデートについて

OS X Mavericksにアップデートすると、iWorkの既存ユーザーは無料で最新版にアップデートできる、という告知がされている。

しかし、実際MacAppSoreでKeynotes/Pages/Numbers見るとそれぞれ¥2000と表示されていて、無料でアップデートできるように見えない。

アップルとのやりとりの結果、どうもMac mini2010プリインストールのは対象外らしい。
 「それならそうと書いておけ!!」大損失。
一転、「やっぱり無償だった」という連絡が来た。
返金手続きを行った。


実際に「Appを購入」を押すと、「(古いバージョン)がインストール済みであるため、Mac App Storeからの購入は行われませんでした」と表示され、ここで「購入する」を押すと、課金されずにインストール可能である。

現在はやらない方が良い。課金されてしまう。
問題が解決されてから行うこと!!
プリインストールモデルで無ければ、コメントにもいただきましたが、英語環境に変更してから行うとすんなり通るらしいです。

2013/11/05追記
「無料」と表示されるようになっていることを確認。
2013/10/24追記
こんなメッセージがくるのに、iTunes Storeからは料金が引き落とされたとのメイルがきていた。いったいどっちが本当なのか現在確認中。

2013/10/24確認
この課金に関しては、iTunes Store側の問題であるということらしく、「取り消される」という見解をいただいた。なので、アップルのサポートに電話して、この件に関して伝え、向こうの言うとおりに作業すれば課金取り消しされる「らしい」(まだ本当に処理されたかまでは確認できていない)。
この際、インストールしたMac本体の情報(シリアル番号など)と、受領メイルにある注文番号、およびインターネットにつながる環境(アップルのサポートHPにつなぐため)が必要となる。

2013/10/26追記
どうやらこの件で相当の問い合わせが来ているらしく、時間をくれとの返答。

2013/10/30追記
上記の通りで、課金対象になることもあると判明。

2013/10/31追記
やっぱり無償という連絡が来た。と言うことで訳がわからん状態。
なので、
(1)英語環境でやってみて、すんなり行ければそれでよし。
(2)プリインストール版の場合は、やる前にアップルに問い合わせた方が良いかもしれない
という感じ。


iLife(iMovie/iPhoto/GarageBand)に関してはこんなことは無い。

なお、インストールしてもiWork'09や旧バージョンのiMovie/iPhoto/GarageBandもフォルダを作って残されるので、互換性に問題があるファイルの場合はそのまま使い続けるのもありだろう。

・・・

そういえば、Mavericks。この上で正常に動かないアプリは、今のところ手持ちの中では
  DIM2.0.2:アイコンの位置を保存・復帰するフリーウエア
      アイコン位置は復帰するが保存できない(パネルが開かない)
 DoubleBoth:マウスカーソルの位置をわかりやすく表示するフリーウエア
     表示され方がおかしい(が一応使える)
だけで、Xcode4.6.3も動作している(他は最新版で確認)。

Xcode5.0.1は、MoutainLion上でアップデートしていても、Mavericks上でも再度アップデートを求められた。ただしインストール時間は大幅に短かったので、何か少しだけ違うのかもしれない。

ただ、マルチモニタにしていると、OS(設定)上は認識されているのに表示が出ないという問題が発生した。再起動したら治ったけど、そのあたりにはまだ何かいるのかもしれない。

それでも、MoutainLionが最初問題ありまくりだったことに比べると、格段に安定しているように思う。なんか応答速度も早くなっているし、良さげじゃないんだろうか。

2013年10月2日水曜日

iOS7やXcode5のバグとかiOS6との違いとか(随時追加)

X-BASIC for iOSのiOS7対応を始めて、iOS6との違いとかバグとかが見えてきたので、
ここに覚書をしていく。
発見した時点のものを書くので、最新バージョンのiOS7(もしくはSDK7)でどうかは、特に調べたもの以外は未確認。

・・・

(1)NSMutableArrayにUILabelを入れ、
- (UIView *)pickerView:(UIPickerView *)pickerView viewForRow:(NSInteger)row forComponent:(NSInteger)component reusingView:(UIView *)view
{
    return [lblArray objectAtIndex:row];
}
とすると、選択項目(中央)の表示が抜けてしまう。

{
    UILabel *lbl=[lblArray objectAtIndex:row];
    if (getSystemVersion()>=7.0) {
        // iOS7上では一旦別のUILabelにコピーしないと選択中項目の表示が抜けてしまう
        // iOS7上でSDK6までアプリを動かす場合も同様になる
        UILabel *label = [[[UILabel alloc] initWithFrame:lbl.frame]autorelease];
        label.backgroundColor = [UIColor clearColor];
        label.font = lbl.font;
        label.text = lbl.text;
        return label;
    }
    // iOS6以前ではこれでOK
    return (lbl);
}
とするとうまくいく。.font/.text..back〜Colorの設定が肝ではなく、UILabelを再確保するのが肝(やればわかる)。
ただし、項目別に高さが変わるように設定している場合、幅が極端に変わるとき、表示上欠けてしまうことがある(Zapfinoフォントなど)。

(2)UITextView.contentSizeの返り値が異なる。
iOS6では設定されている内容の高さ(スクロールを伴なう場合は、表示領域だけじゃなく全体の表示高さ)を返すが、iOS7では意味不明の値を返してきている(UITextView.frame.sizeとも微妙に違う)。
このため、contentSizeで実表示行高さを得ている処理はすべからく動かなくなる。
 以下のコードでとりあえず回避可能だが、iOS6の値とは同じではない。
-(CGSize)getContentSize:(UITextView *)myTextView
{
// getSystemVersion()はiOSのバージョンをfloatで返す関数とする
    if (getSystemVersion()>=7.0) {
        // FLT_MAX : float最大値
        return [myTextView sizeThatFits:CGSizeMake(myTextView.frame.size.width, FLT_MAX)];
    }
    // iOS6以前
    return myTextView.contentSize;
}

更に困った事に、これで得られた各行の高さや位置を.contentOffsetに設定しても、正確にはその位置にスクロールされない(微妙にずれる)。補正係数が必要である。

これも、UITextViewが従来のWebKit派生から、完全独立したせいだと思うが、互換性は保ってほしい。


(3)Search BarのBar Style(iOS6ではStyle)のBlack Translucentの表示が違う
iOS7ではdeprecated=廃止予定になってるので、defaultにする。

(4)Xcode5上のiOS6シミュレーターの挙動がXcode4上それと異なるので、
iOS6での挙動を正確に調べるにはXcode5は使えない。
両方の環境は共存できるが、シミュレーターは同時に両方起動できないので、
それぞれでの実行時に一度終了させる必要がある。

 XcodeのバージョンとiOSのバージョンの組み合わせによる動作結果はこんな感じ。

Xcode4で作ったiOS6用オブジェクトをiOS6で動かす
 →普通
Xcode4で作ったiOS6用オブジェクトをiOS7で動かす
 →iOS6互換モード
 iOS6上とほぼ同じ動作&表示になるけど違う部分も多少ある(上記1など)
 実機でのみ可能(シミュレーター上でも無理やりやれば出来るのだけど、面倒)
  X-BASIC for iOS v2.7はこれで正常動作することを確認した。

Xcode5で作ったiOS6用オブジェクトをiOS6で動かす
 →動く。問題ないように見える。
  実機でのみ可能
Xcode5で作ったiOS6用オブジェクトをiOS7で動かす
 →iOS6互換モードとは異なる結果になる事がある

Xcode5で作った32bit iOS7用オブジェクトをiOS7で動かす
 →iOS7 32bitモード
 表示や動作がiOS6と大幅に異なるのでプログラムの修正が極めて面倒。
 でもそれとなく動作はする。

Xcode5で作った64bit iOS7用オブジェクトをiOS7 64bitで動かす
 →iOS7 64bitモード
 動作が大幅に異なるので動かない(X-BASICの場合)。


(4)シミュレーターで「Appをインストールできませんでした」となることがある
 一旦アプリを削除すると直るが、設定なども初期化されるのでとても面倒。
 発生原因は特定できず。iOSのバージョンを切り替えた時に発生しやすいが、発生しないこともある。
 Xcode5のバグと思われる。5.0.1/2では発生頻度は下がったが完治はしていない。


(5)「SpringBoardがAppを起動できません」となることがある
 シミュレーターを再起動すると直る。
 発生原因は特定できず。
 Xcode5のバグと思われる。5.0.1では発生していない。5.0.2ではまた発生するようになった。

(6)バグじゃないけど、Xcode5で編集したxibはXcode4で編集できなくなってしまう
確認した限りxibがそうなる。
なので、Xcode4/5を共存させる場合でも同じソースを両方で編集してはいけない。
現状、Xcode5上のiOS6用環境が信用出来ないので、この点は要注意。
(戻せなくなってえらく苦労した。)

(7)UITextViewでキーボードを表示→消去したあと、下になった部分の表示が欠ける(戻らない)ことがある。
キーボード表示前後でUITextViewの表示サイズを変更するとこうなるみたい。
(キーボードに重ならないようにサイズを変更するなど。)
OS内部での再描画エリアの計算を間違っていると思われる。
setNeedDisplayをかけても再表示されない。
さんざん手を尽くして見つけた回避方法は、 強制的にスクロールをさせること。
「例」
        CGPoint ofst=textview.contentOffset;
        ofst.y++;
        textview.contentOffset=ofst;
        ofst.y--;
        textview.contentOffset=ofst;
iOS7のバグ。7.0.3でも治っていない。iOS6まででは発生しない。
また、UIWebViewでは発生しない(iOS6までで発生しないのはこのため)。

(8)UIScrollView.scrollsToTopのデフォルト値がNOになってる
iOS6はYESなので、ステータスバーのところをタップすると先頭へスクロールしたが、
iOS7はステータスバーを見かけ上一体にしたせいかNOになっており、
強制的にYESにしないとスクロールしない。

(9)xib内にレイアウトしているActivity indicatorの表示座標が画面外になってしまう
Xcode4→Xcode5での変換に失敗していると思われる。
多分レイアウトしているviewの高さの座標が入れられている。
IB上で座標を再設定するか、表示座標は プログラム的に設定するようにする。

それ以前にActivitor indicatorがIB上で表示されないような・・・。

(10)iPod touch/iPhoneでpushViewControllerで画面を表示したとき、
Viewが上がって=NavigatioBarに重なって表示されてしまう
viewDidloadにて
    self.edgeForExtendedLayout=UIRectEdgeNone;
を発行すれば良い。
NaviのないiPadのpickerViewの中では不要。

(11)ナビゲーションバーとステータスバーが重なってしまう
iOS 6/7 Deltasで補正するとか、そもそもnavigation barの置き方が悪いとかちまたにいろいろと情報があるけど、うまくいかない。
強制的に表示位置を変えて重ならないようには出来るが、それをすると下に来るUIViewのサイズが「なぜか」ステータスバー分狭くなる。
StoryBoardを使わない画面遷移は考慮されてないんじゃないか?と思っている。

→いろいろやった結果、 統括しているUIViewのbackgroundColorをclearColorにし、Naviバーの表示位置を下げ、その下に来るUIViewのサイズを調整して同等の画面を作り出せた。

UIView----------------------------Status Bar=default,Background=clearcolor
  Navigation Bar----------------viewDidLoadでこのframe.origin.y+=20する
  UIView---------------------------同上
     いろいろな表示コントロール-------ここは基本的に調整不要


(12)UIBarButtonItemに動的に画像を入れた場合、正しく表示されない
btnBreak.image=[UIImage imageWithContentsOfFile:〜]
解決手段は見つからず。X-BASICでは結局画像をやめて文字にしてしまった。
(identiferが簡単に変更できれば良かったのだが。)
.enable=YES/NOとか、UINavigationItemあたりは表示結果がiOS6とは大幅に異なるのでかなりの変更が必要そう。

(13)Xcode5のエディター上でUndoした時、表示上は元に戻っているのに内部的に戻ってないことがある。
謎のコンパイルエラーが出るので調べたらこれだった。
ソースをちょっといじれば正しくなる。
Xcode5.0のバグ。5.0.1でも頻発。5.0.2でも発生を確認。

(14)UIWebViewに対してstringByEvaluatingJavaScriptFromString:でJavascriptを実行するとき、その対象となるHTMLが読み込み終わってないと、呼び出し後に表示が消えてしまう。
たとえば、
    [web reload]; // [web loadHTMLstring:~]でも同じ
    [web stringByEvaluatingJavaScriptFromString:@"~"];
とすると、表示が消える。
だからといって、
 while (web.loading) {
    NSDate *dt=[NSDate dateWithTimeIntervalSinceNow:1.0]
    [[NSRunloop currentRunLoop]runUntilDate:dt]
  }
とかして読み込み終了を待っても同じだった。.loading自体が正しい状態を返してないのでは?とも思っている。

(15)同一フォントでもサイズが異なる
iOS6と7では、同一名フォントでも大きさが微妙に異なることがある。
このため、フォントサイズに厳密に依存しているアプリは表示位置の調整が必要になる。
X-BASICではファンクションキーの表示位置が違ってくる。

(16)UITextView:styleStringが使えなくなった
iOS6までは非公開APIのstyleStringで行の表示状態を強制変更できたが、iOS7ではこれが呼び出されなくなったので効かない。
X-BASICでは、これを使えばUITextViewの高さが得られない問題を回避できるかと思ったが、どうやってもうまくいかないので調べたらこのことに気がついた。
ただし、そもそも styleStringを使っていると拒絶されるという話もあるので使わないで良かったのかも。
→UITextViewはiOS6まではWebKitから派生されていたがiOS7では完全に分離されたらしいので、この辺りは使えなくなったようである。attributedTextと使えということだろう。

(17)UIWebView.backgroundColorの設定が無視される
IB上でも設定可能なのに、表示すると色が出ない。常に透明になっている気がする。
設定があるということは反映されるべきで、間違いなくiOS7のバグ。

(18)UIWebViewとUITextViewを表示面で同調させてた処理は、ことごとくだめになる
何度も書くとおり、iOS6まではこの2つはWebKitを使っていたが、iOS7では後者は分離されたため、表示結果もことごとく異なる。フォントサイズの指定結果とか。UIWebViewをテキスト表示に使ってたような処理は、UITextViewにattributedTextで渡すように作り直す必要があるかもしれない
(X-BASIC for iOSはそうした)。
iOS7対応のためにiOS6以前を切り捨てるアプリがあるのは、こういう違いが大きく、双方をサポートするのが面倒なためだと思う。

(19)UITextViewでズームしなくなる
これは、スクロール対象ビューを返すviewForZoomingInScrollViewデリゲートで返すべき値が変わるから。iOS6ではUIWebDocumentViewだったが、iOS7では_UITextContainerViewに変わっている。以下のようにして回避。

-(UIView *)viewForZoomingInScrollView:(UIScrollView *)scview
// UIScrollViewのデリゲート:ズーム対象のUIViewを返す
{
  NSString *zoomSubviewDescription;
  if (getSystemVersion()>=7.0) {
    zoomSubviewDescription=@"<<_UITextContainerView"; // <_なので注意
  } else {
    zoomSubviewDescription=@"<UIWebDocumentView";
  }
  if (scview==対象view) {
    // 返すView:editorの中のスクロール対象UIView
    for (id subview in scview.subviews) { // subviewsはUIViewのプロパティ
        //NSLog(@"subView=%@",[subview description]);
        if ([[subview description]hasPrefix:zoomSubviewDescription]) {
        //NSLog(@"リターンsubview=%@",subview);
        return subview;
        }
    }
  }
  return nil;
}

(20)UITextViewでテキストが途中で切れてしまい、それ以降表示されないし、スクロールもできなくなる
X-BASIC for iOSで最後まで悩まされたバグ。
1ヶ月以上かかって、http://stackoverflow.com/questions/18859637/setting-uitextview-frame-to-content-size-no-longer-works-in-xcode-5 を参考に(これだけじゃだめ)、ようやく以下で回避可能になった。

-(void)setAttributedText:(UITextView *)textView text:(NSAttributedString *)atext
{
  // 一旦スクロールをOFFにする
  [textView setScrollEnabled:NO];
  // テキスト設定
  textView.attributedText=atext;
  // サイズを再設定
  [textView sizeThatFits:textView.frame.size];
  // スクロールをONに戻す
  [textView setScrollEnabled:YES];
  // 強制スクロールをさせて再描画をかける;これも必要
  CGPoint pt=textView.contentOffset;
  pt.y++;
  textView.contentOffset=pt;
  pt.y--;
  textView.contentOffset=pt;

}

(21)XcodeのIBでUser Defined Runtime Attributesを設定すると・・・
(21−1)Key Pathに入力しても消えてしまうことがある
 入力→フォーカスを他に移動→再度入力でようやく入る
(21-2)入力を続けていると、高確率でXcodeがハングアップする
 複数の値を設定するときは、1つ入れてはビルド、を行うと回避できる
拡張したクラスへの値を設定するにはとても便利な機能なのだけど、このバグのせいで使い勝手が悪くなっているという残念さ。

(22)Xcodeのエディタ上で、半角カナ+半・濁点文字を入力すると、2つは1文字として扱われてしまう
メモ帳でも発生する。Xcode4以前ではどうだったかは不明だが多分同じだろう。
TextWranglerなどのテキストエディタ(でSHIFT-JISで処理している場合)では問題ない。
めったに出てこないとは思うけど、半角カナを扱うプログラムを書く場合は要注意。


(23)Mavericks上では、iOS5シミュレーターがインストール出来ない
これはバグと言うより仕様。10.8上のXcode5でならインストールできる。
iOS5向け開発するならMavericksは入れない方が吉。

(24)Xcode5の64bitシミュレーター上で、UITextFieldなどで物理キーボードからの入力ができない
32ビットシミュレーター上では物理キーボードから(漢字も含め)入力ができるので、効率が非常に良いが、64ビット上ではこれが「なぜか」できない。
最初、プログラムのバグではないかと疑ったが、シミュレーターのバグだった。
5.0.2で確認。
→32ビットシミュレーターでも発生することがあると判明。どうやったらそうなるのか全くわからない。
設定も見つからないし、あったとしてもいじった記憶は全くないのだが。


(25)シミュレーター上で実行中、HOMEダブルタップでタスク選択に入って、実行中アプリを削除(これでXcode上でも実行が止まる)、もう一度XcodeからRUNすると、画面が表示されない。
内部的には動いているつもりになっているようだが、画面が一切表示されない。
(動いているつもりなので、起動できないエラーは発生しない。)
こうなったら、一度シミュレーターを終了して、再度Xcode上からRUNするしかない。


・・・おまけ:iOS6のバグ
・UITextViewに入れるテキスト中に連続するスペースがあった場合、まとめられてしまう
 たとえば、スペース4つが2つになる。いったいいくつがいくつにまとめられるのか、規則性はわかっていない。iOS7では同様の現象は起こらない。
おそらく、iOS6までのUITextViewはWebKitを使っていることに起因していると思われる。

・・・

とにもかくにもiOS7は変わりすぎてて困る。UITextViewは同じメソッドやプロパティーで結果が異なるので特に注意が必要。これだけ異なるなら別ものにすれば良かったのに。


フラットデザインは、どこがボタンがわからなくなって操作もしにくいし、なんか妙にアニメーションしてて酔いそうになるし(7.0.3である程度抑えられるようになったようだけど)、良いことないと思うのだが。
(UISwitchのON/OFFだけは設定~一般~アクセシビリティ~オン/オフラベルで表示させることが出来るので、是非ともオン(1)にすることを勧める。ボタン系も枠を表示するよう設定できれば良いのに。)





2013年9月27日金曜日

Mac miniのHDD交換方法

Mac mini(2011)のHDDに交代保留セクターが増え続け、さらに全体にアクセス速度が遅くなってきているので、完全にだめになる前に交換することにした。


基本的には下記サイト↓
http://henjinkutsu.com/text/pc/macmini2011_upgrade/
を参考にしたが、いくつか間違いがあるので補足しようと思う。


まず、交換前にTimeMachineで内容を外部HDDに全バックアップしておくこと。
BOOTCAMP領域がある場合はさらに、WincloneもしくはWindows上のバックアップツールを使ってバックアップしておく。


交換に必要なものはトルクスドライバT5/T5.5/T6/T8。T5.5がないときはペンチ。それに非常に細い(薄い)マイナスドライバ。多分にほこりも溜まっていると思うので、掃除機とかほこり取りは適当に。


外すねじは、まずは以下の通り。ねじはすべてトルクスねじ。赤線はT8、白はT6だったと思う、青はT5.5。ねじを外す前にメモリは外しておく(外さなくてもHDD交換は出来ると思うけど、念のため)。金属部分に触れて、静電気防止を忘れずに。
青の部分のねじはT5.5と思われ、私の持っているトルクスビットには存在しなかった。しかし、ここは緩いねじなので、ドライバがなければペンチでつまんで外すことが出来る(というか、そうした)。


白線T5の内左2本は2重のねじで、上側=ファンを留めているのがT5(上の写真)、ファンを外した下にあるのがT8で、それを外すと左側の黒のカバーが外れる。

これで冷却ファンが外れるようになるが、電源線のコネクタも抜かなければならない。
このコネクタは基本的には上からはめるだけだが、抜くときは隙間に非常に細いマイナスドライバを入れてゆっくりすき間を広げていく。

その後上の金属網プレートを横によける。基板とは極小コネクタで接続されているので、外さないようにする(外しても良いが、はめるのはちょっと難しいので)。
次に左側の黒カバーを外す。ちょっと引っかかりがあるので揺らしながら右方向へ抜く。



HDDは黒カバーの下、この位置でコネクタで基盤につながっているので、上に引き抜く。
HDDは手前上方向に引き出すようにする。


外したHDDがこれ。左上に見えているのが、外したコネクタ。

HDDは、横側がT8ねじで留められているので外す。

また、HDD全体に黒いシートがシールでくっついているので、丁寧にはがす。このときにも薄いマイナスドライバがあると便利。


後は、元通りに戻していくだけ。
コネクタ類をちゃんとはめることを忘れずに。
私はメモリが半分しか認識されてなくて再度開く羽目になったので。

上の金属プレートのT8ねじは、このようにちょっと浮いたような感じで閉まるので注意。

くだんのHPではHDD(SSD)の増設を目指しているようで、交換だけには不要な部分のねじなども外すように指示している。それをしようとするとT5.5ドライバが絶対必須。


新HDDへの内容リカバリは2段階で行う。
(1)インターネットリカバリーでOSを戻す。
電源ON時に「command+option+R」を押しっぱなしにして起動する。
ただし、USB-Apple純正キーボードで行うこと。
(Windowsキーでは配置が違いうまく行かない。)
このとき、下記以外のHDDや機器は一切繋がないこと。
 (USB)キーボード
 (Bluetooth)マウス
 有線LAN
 モニタ

(2)TimeMachineで復元
Command+Rで起動してTimeMachineから復元する。
新HDDの容量が旧と異なっていても問題ない(もちろん、容量的に入りきる必要はある)。
Macはこれで完全復旧する。すごい!

BOOTCAMPがある場合は、Wincloneなどで戻す。

HDDの内容を戻すのは簡単だけど、HDDの交換自体は結構手間がかかるのがMac mini2011の欠点かも。



 そうそう、外したHDDを予備に使うとか、そこから内容をコピーするとかいう場合にはSATA 2.5'のHDDケースがあると便利、と書いておこう。うちでもWindows側の設定戻しに重宝したので。
Amazonなら800円くらい。



使ったHDD


使ったドライバーセット(ただし、T5.5はない)




2013年9月18日水曜日

Objective-Cの勉強(10):Class型



Class型



クラス変数を「インスタンス化した」時、そのオブジェクトの中には「自分自身のクラス定義内容」も入っている。これを「クラスオブジェクト」という。実はこれこそがNSObjectクラスの主な機能である。
これはClass型で定義され、変数にも代入できる。代入するメソッドはclassである。


万が一クラスオブジェクトが存在しない時は「Nil」という値が返ってくる。ここではNULLは使わんようだ。



定義内容そのものを動的に取得可能というわけだ。しかも、その定義内容を元にインスタンスを作成することも出来る。型(定義)そのものを変数に代入し、その変数に代入された型で変数を宣言できるということだ。
うぉっ、ややこしい。でもなんかうまく使えば強力そう。

@interface Test : NSObject
+ (void)Write;  // クラスメソッド
- (id)init;     // インスタンスメソッド
@end
@inprementation Test
    省略
@end
int main()
{
    Class testClass = [Test class]; // Class型変数testClassを宣言し、Testというクラスのクラス情報を代入する
       // testClassはクラス宣言に相当する
    [testClass Write];         // testClass->Write();相当 Writeがクラスメソッド(+)だから呼び出せる
    [[testClass new] ObjFree]; // testClassの保持するクラス型のオブジェクトを作成→即解放している
    [testClass ObjFree];       // クラスオブジェクトを解放
    return(0);
} 
 

2013年9月11日水曜日

Objective-C勉強(9);メンバーの公開範囲



メンバーの公開範囲



通常、クラスメンバー変数はそのメソッドによってのみアクセスされるべきである。
が、メソッドの呼び出しはCの関数呼び出しに比べ(出来ることが多い分)遅いので、
高速性を求められるプログラムではメンバー変数に直アクセスアクセスする必要があるかもしれない。


しかし、全メンバーを公開してしまうと、いじられたくない部分までいじられる可能性がある(特に派生クラスを作る時)ので、公開範囲を限定できる。


@public 全公開(外部、このクラス内、子クラス内)
@private このクラス内のみ公開
@protected このクラスおよび子クラス内のみ公開;デフォルト


これを記述した後のメンバー変数は全てその公開範囲となる。クラス定義内で何回、どの順序で書いても良い。
クラスの属性値は@publicに、内部変数は@privateまたは@protectedにするといいのだろう。
C言語で言うなら、グローバル変数、ファイル内static変数、auto変数と考えるとわかりやすい。

Apple純正のObjective-C解説

によると
@publicの利用は避けるべき

と書かれている。
デバッグ時に内容読むのには使えると思うけどね(デバッグ中だけ@publicにしておく)。


ついでに書くと、クラスをidで受けてしまうとメンバー変数がコンパイル時には不定でエラーになるので、「クラス名 *」で定義する必要がある。
@interface A : NSObject
{
@public
    int a;
@protected
    int b;
@private
    int c;
}
- (id)initWithA:(int)a arg2:(int)b arg3:(int)c;
- (void)WriteA;
@end

@interface B : A
// 変数がないので{}は省略
- (void)WriteB;
@end

@implementation A
- (id)initWithA:(int)a arg2:(int)b arg3:(int)c
{
    self->a = a;  // @publicメンバーへの代入はポインタを経由して行う
    self->b = b;
    self->c = c;
    return(self);
}
- (void)WriteA
{
    printf("[A Write a=%d, b=%d, c=%d]\n", a , b , c);
}
@end

@implementation B
- (void)WriteB
{
    printf("[B Write a=%d, b=%d]\n", a , b); // cにはアクセスできない
}
@end

int main()
{
    B * objb = [[B new] initWithA:1000 arg2:100 arg3:10];
    printf("[main() a=%d]\n" , objb->a); // @publicなのでメンバー変数に直接アクセスできる
    objb->a=200; // 当然代入も出来る
    [objb WriteB];
    [objb WriteA];
    [objb ObjFree];
    return(0);
}
このあたりはCで書いてた構造体を持つライブラリを移植していくと理解が深まるのであろう。

Objective-C V2.0で導入されたプロパティを使うと自動的にアクセスメソッドを生成させることが出来るので、この公開範囲をいじるというのは「高速化を除き」今後余り行わない方が良いのかもしれない。


世間に公開するようなライブラリを作るならいざ知らず、個人の開発においてはほぼ無用であろう。
私は一度も使ったことがない。

2013年9月5日木曜日

Objective-Cの勉強(8):id型よりクラス名 *の方が安全



id型よりクラス名 *の方が安全



クラスの型としてはid型が汎用的で使いやすいが、逆に言えば型(クラス)が特定出来ないので、
持っていないはずのメソッドを呼び出してしまったりする可能性がある。

それを動的に調べる方法もあるのだが、コンパイラレベルでもある程度チェックできる。
素直に元のクラス名のアドレス型で宣言すればよいだけである。
これはコンパイルレベルのチェックを強化させるだけなので、実行時には全く影響を与えない。

@interface A : NSObject
- (void) Write;
@end
@implementation A
- (void) Write
{
    printf("Write\n");
}
@end
int main()
{
    id obj1 = [A new];      // クラスAにはWriteというメソッドが存在するが、
    id obj2 = [NSObject new]; // 親クラスであるNSObjectにはない(場合)

    [obj1 Write];
    [obj2 Write];   // 実行時にエラーとなる
    [obj1 ObjFree]
    [obj2 ObjFree]
    return(0);
}
↓これを明示的なクラス名で記述する。
int main()
{
    A * obja = [A new]; // idは元々ポインタを示す型なので、クラス名で明示する時は"*"が必須
    [obja Write];       // もしクラスAがWriteメソッドを持たない場合は、コンパイル時にエラーになる
    [obja ObjFree];
    return(0);
}
この場合は呼び出す元となるインスタンスが固定されているので、メソッドの存在があらかじめ解るが、Objective-Cでは逆に、メソッド名自体=メッセージを固定して呼び出し対象とするインスタンスを変更していく;送るメッセージは同じだが、それを解釈するオブジェクトが違う、という記述をよく行う。その場合はこの方法は使えない。

その「動的なメソッドの存在チェック方法」については後述。

2013年8月26日月曜日

Objective-Cの勉強(7):オブジェクトの所有権



オブジェクトの所有権


Objective-Cでは、前述の通りクラスはローカルやグローバルな領域に実体を確保できないため、必ずオブジェクトの生成と破棄を必要とする。
アクセスしたメソッドが、それを解放して良いか、解放するならそれはいつかは、わかりにくいこともある。
特にメソッドのリターン値になる場合などはそうである。
誰が解放するかということについて、一応の規約が存在する。


オブジェクトを作成する alloc / allocWithZone:
オブジェクトをコピーする  copy / copyWithZone: / mutableCopy / mutableCopyWithZone: 
オブジェクトを保持する retain
以上を自身で行った場合はreleaseでオブジェクトを解放する。
行ってない場合は「そのオブジェクトの所有権はない」として解放処理は行わない。


別のまとめ方をすると、以下の通りとなる。
ローカルでallocしたそのスコープ内でrelease
クラスメソッド(+で始まるメソッド)で確保された基本的には何もしない(OSが解放する)
または明示的にAutorelease Poolを確保~解放する
プロパティでcopyまたはretaindeallocメソッド内でrelease
allocとcopyは実メモリの確保を伴い、retainはアドレスが示す内容の解放を遅らせるだけ、と意味が異なる。にもかかわらず、同じreleaseで解放指示を行うところが注意である。



allocとcopyは特にわかりにくいことはないと思うが、retainは少しわかりにくい概念かもしれない。
Objective-Cのクラスはアドレスでやりとりされる。
従って、代入したもしくはメッセージに引数として渡したと思って元のオブジェクトを解放してしまうと、代入先が参照できなくなってしまう。これを渡された側で「解放に待ったをかける」方法が「retain」である。
Objective-Cではマルチタスクを前提としているので、呼び出されたメソッドと呼び出したメソッドは並行動作する可能性が高い。そのためこのような指示が必要なのである。
呼び出し側でその後の処理でreleaseをかけても、そこでは解放せず、呼び出された側もreleaseをした時に初めて実解放がかかるようにする。



しかしこれもあくまで解放の遅延だけであって、内容の書き換え禁止ではないことには注意すべきである。元の内容を書き換えると、代入先の内容まで書き換わってしまう。これが顕著になるのが配列オブジェクトを使う場合である。



Objective-CのクラスはCの構造体と見た目似ているが決定的に違う部分があって、それは「実体を代入することが出来ない」である。このことは配列クラスであるNS(Mutable)Arrayの要素にて特に問題になる。
NSArrayの要素はid型であるが、これはすなわち要素として実際に格納されるのはアドレスであることを示している。addObject:メッセージで要素を追加しても、その要素のオブジェクトのアドレスが格納されるだけであって、要素実体のコピーが格納されるわけではい。Cで構造体の配列を作った場合は、その実体がコピーされる。これが最大の違いである。
 
// 構造体の場合
typedef struct {
    int x;
    int y;
} XY;
XY xy[10]; // 構造体XYの実内容を持つワークが10個分用意される。
~
    xy[0]=xy[1]; // xy[1]の内容全てがxy[0]の領域にコピーされる


// クラスの場合
@interface XY : NSObject
{
    int x;
    int y;
}
~
{
    XY *xy0=[[XY alloc]init];
    NSMutableArray *ary=[[NSMurableArray alloc]init];
    //
    [ary addObject:xy0]; // ここではxyのアドレスだけが格納され、xyの実体は格納されない
    XY *xy1=[ary objectAtIndex:0];

(構造体とクラスのプログラムは同じ意味ではない。)
ここで、構造体の場合はxy[1]の内容をこの後いじってもxy[0]の内容は変化しない。
実内容がコピーされているからである。
ところが、クラスの場合、xy0の内容をいじるとxy1から読み出す内容も同じになる。
配列に格納されているのはあくまで実体アドレスであって、内容ではないからだ。
このことを理解しておかないと、「配列に要素を保存したはずなのに内容が変わってる!」という現象に悩まされる。クラスではこれはバグではなく仕様なのである。
仮にretainを指定しても、それはあくまでアドレスの示す領域の解放を遅らせるだけであって、内容の書き換えを禁止するわけではない(その方法はない)ので要注意である。


MacのCocoaではメモリの有効活用のためにワークを移動させてまとめたり不要になった領域をメモリ上から消すガベージコレクション機能を持つらしい。古くはBASICで文字列を扱うと発生していたのが「ガベージコレクション」だし、X68のSX-Window上でもワークの移動はOSの大事な機能だったが、それとほぼ同じである(こんな事書いても解る人の方が少ないだろうが)。
確かにそれがあれば解放を気にしなくて済むようになるからプログラムは楽に書けるようになるかもしれない。
が、本来メモリ管理は明確かつ厳密に行われるべきであって、ガベージコレクションなどに頼るべきではないと思う。
アセンブラやCの時代からプログラムを組んでいると、ガベージコレクションどころか、クラスインスタンス以外のAutorelease Poolだって甘やかしだと思うのだが。

2013年8月17日土曜日

Objective-Cの勉強(6):インスタンスの確保/初期化/解放とAutorelease Pool



インスタンスの確保/初期化/解放とAutorelease Pool

クラスのメンバー変数やインスタンスメソッドは、クラスを宣言するだけでは使えない。
実体が存在しないからである。利用時には必ず実体の確保が必要となる。
これは、基本的にはCの構造体と変わらない。


構造体の場合、その確保はグローバルまたはローカルの変数として宣言することで行う。
typedef struct {
    int a;
    int b;
} SINT2; // 構造体の宣言

SINT2 x; // 実体の確保
Objective-Cでも宣言に関しては(記述方法はともかく))基本的に同じであるが、実体の確保はかなり異なる。
クラスを示す変数はアドレスで宣言し、実体確保もメソッドで行うである。
クラスの実体はローカルでもグローバルでも直接確保は出来ない。
なので、

// CINT2がクラスの場合
CINT2 x; // エラー
 
はエラーとなる。宣言時はクラス位置を示すアドレスを宣言、実体確保は別途allocメソッドで行わなければならない。

CINT2 *x;
x=[INT2 alloc];
~
[x release];

C風に書くなら、
x=malloc(sizeof(CINT2));
~
free(x);
となるだろう。

なぜこんな面倒なことをするのかであるが、Objective-Cのクラスは、実行アドレスの確定を初め動的な部分が多いので、ある特定のメモリ領域に一括して格納し、管理するためではないかと思われる。Cのヒープ領域よりもっと高度に管理されたメモリ領域を使うということだ。
そのため、位置不定のローカルや、逆に位置が完全に固定されるグローバルな確保をさせないのだと思う。


クラスの利用を宣言するとき、多くの場合2つの確保し方/され方がある。
alloc/copyなどで明確に領域の確保を指定する場合と、クラスインスタンスを使って確保する場合である。

たとえば、NSStringでは、
(1)NSString *str1=[[NSString alloc]initWithString:@"文字列"];
(2)NSString *str2=[ NSString     stringWithString:@"文字列"];
の2つは、どちらも領域を確保して、その実体として@"文字列"をコピーする。
もっと正確に言えば、str1/str2には確保された領域の先頭アドレスが入り、そのポインタが指し示す領域に"文字列"が格納される(ここではどのように文字列が格納されているかは言及しない)。


ではこの2つは同じなのかというと、「メソッド内で使うだけなら同じ」であるが「メソッドを抜けた後の動作が全く違う」。

(1)がmalloc相当による確保、(2)はAutorelease Poolという自動開放領域への確保となる。
(1)はメソッドを抜けてもその領域は確保されたまま=有効であるが、
(2)はメソッドを抜けると、あるタイミングで自動解放されてしまい内容が不定となる。
メソッドだけでなく、関数で使う場合も同じ。


(1)は必ず対応するreleaseが必要となる。
それは、同一関数内である必要はない、と言うか、無理な場合も多い。その場合は呼び出し側でreleaseすることを忘れてはいけない。ただし同一関数内でreleaseしないと、Analyzeを掛けたとき警告が出る。基本的にallocで確保したものをそのまま関数のリターン値に使うことは避けた方が良い、という考えなのであろう。


ちなみに、自分で翻訳しておいてなんだが、アップルのメモリ管理の規約に従えば、メソッドや関数内でallocしたままリターンし、呼び出し側でreleaseするのは御法度とされている。クラスメソッドを使って返すか、allocする場合はautoreleaseしておけと書いてある。

今度からそうしよう(^_^;)


なおreleaseは厳密にはfree()とは異なる。詳しくは次のオブジェクトの所有権に譲るが、即時解放ではなく解放要求である。

というのも、Objective-Cではオブジェクトは複数から保持要求されることがあり、その場合、全てのrelease要求が揃った時点で初めてメモリが解放されるからである。


Cocoa Touch上では、NSArray等のように要素を自動的にretainするようになっているクラスあり、
その場合、プログラムの記述上では要素に代入したら即時relaseするような、
Cで考えたら「おかしいんじゃねぇ?」と思えるような書き方も当然のように必要だったりするが、
それもreleaseが「即時解放」ではなく「解放要求」だからこそ成立する仕組みである。


(2)のようなクラスメソッドによる確保は、いちいちallocする必要もないし、終了時にreleaseも必要ない(してはいけない)。
なので、ローカルで使うには便利であるが、逆にローカルから外へは持ち出す=リターン値として返す場合は、受け側でcopyするか、retainして明示的に解放を遅らせる必要がある。


それをしなかったらどうなるか。それは、str2の記憶しているポインタアドレスそのものは変化しないのに、その指し示す領域の内容が変化するということになり、デバッグ時に非常にやっかいな現象を引き起こす。Cでローカルワークに格納したものをリターン値にして、呼び出し側で受けようとしたら内容が化けてた、というのと同じである。


(1)(2)の違いを正しく把握することは、Cocoa Touch上でプログラムを組む上で、きわめて重要である。にもかかわらず、アップルのドキュメントにおいてもそれに関する記述が見つけられなかったし、インターネットで調べても書いてあるサイトが1つも見つけられなかったという始末である。
ひょっとして、誰も正しく理解してなかった?それとも理解している人は隠していたか。



Autorelease Pool(自動解放プール)とは、登録されたオブジェクトを、自動解放プールを解放したときに一括して解放する仕組みである。自動開放プールの宣言からその開放までの間に登録されたオブジェクトに対し、自動的に release メッセージを送ってくれる。


NSAutoreleasePool

メソッド名動作
-(void)drain全強制解放する(ガベージコレクション付き)
-(void)release解放する(ガベージコレクションなし)

+(void)addObject:(id)object

-(void)addObject:(id)object
オブジェクトを追加する
-(id)autorelease解放要求+1
-(id)retain保存要求+1

// プール作成
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
// たくさんのオブジェクトを登録
id *anObject = [[NSObject alloc] init];
[pool addObject:anObject];

    ~ 
 
//プール解放時に、登録したオブジェクトにもreleaseが送信される
 [pool drain]; // プールの解放 / iOSではreleaseでも同じ
 
このように、自動解放プールに登録したオブジェクトは、自動解放プールを解放したときと同時に解放される。
iOSではガベージコレクションを行わないので、drainとreleaseは同じである(Xcodeが自動的に作るmain.mでもreleaseを使っている)。



私は、iOSアプリを作り始めてしばらくは「クラスメソッドによる確保はローカルスタックに作られる」と理解していた。実際動作だけから見ると、その理解は「ほぼ」間違いではない。
が、もっと詳細に動作を追跡する必要が出て、それをやっている内に「Autorelease Pool領域内に確保されている」と理解した次第である。

なぜか。

Instrumentという解析ツールの中にメモリの確保状況を見る機能がある。
これで追跡していると、クラスを抜けた後にもかかわらず、クラスメソッドで確保したワークが解放されていないことが分かった。
ローカルスタックなら、リターン時に絶対に解放されるはずである(内容が破壊されるかどうかは別にして)。
試しに呼び出し前後でAutorelease poolを確保~解放したら,そのワークも解放された。
ここで「Autorelease pool内に確保される」と理解した次第である。


Autorelease poolは、iOSアプリ起動時にmain()内で自動的に確保される。
だから、ユーザープログラムの中でそれを宣言しないでもクラスインスタンスによる確保が使えるわけだが、これはメインスレッド用なので、ユーザーが別スレッドを動かす場合は、その中で明示的にAutorelease poolを確保~解放する必要がある。
これをしないと、メイン用のAutorelease PoolがあふれてiOSが異常動作を起こすこともある。
経験から言えば、アプリが落ちるのではなく、画面表示がされなくなることが多い。
非常にわかりにくいバグになるので要注意。


スレッド内でクラスインスタンスによる確保をしていないと思っても、一応AutoreleasePoolは確保しておいた方が良い。
なぜなら、アップル純正や、ちまたに流れているクラスライブラリの用意しているメソッドや関数の中には、autoreleaseオブジェクトを返してくるものがあるからである。
確認している範囲では、
  • becomeFirstResponder
  • UIGraphicsGetImageFromCurrentImageContext()
  • UTF8String
等がある。特にbecomeFirstResponderやUTF8Stringは見逃しがちである。
逆に、クラスメソッドでもシステム内のアドレスを返すだけのものは例外的に自動開放プールを使わない。
まあ、なんにせよ転ばぬ先の杖。



また、for等ループの中も同様で、ループを抜けないとAutorelease Poolが解放されないため、
ループ内でクラスインスタンスによる確保を行うとあふれてしまうことがある。
ここでも、ループ内で別途Autorelease Poolの宣言が必要となる。
 
NSMutableArray *array = [NSMutableArray array];
 
for ( int i = 0; i < 10000; i++ ) {
    NSAutoreleasePool *p = [[NSAutoreleasePool alloc] init];
    [array addObject:[NSNumber numberWithInt:i]];
    [p drain];
}
for ( id n in array ) NSLog( @"%@", n );
 
for 内の[NSNumber numberWithInt:i] は、クラスメソッドによる確保であり、自動開放プールなしでループを回すと、NSNumberインスタンスが一時的に 10000個作成されることになる。
このようなところでは局所的に自動開放プールを作成・解放しておく。


allocした結果をpropertyで宣言したインスタンスに代入する場合、たとえば
 
@interface MyClass : NSObject
{
    NSString *string;
}
proterty (nonatomic,retain) NSString *string;
@end

の場合は、確保は同じだが、解放は
 
self.string=nil; // [string release]; string=nil;相当

でもいいらしい。プロパティーとして作用させる必要があるので、「self.」は外してはいけない。
でも、allocしたのにreleaseがないというのはやはり美しくない。それはCでmallocしたのにfreeがないのと同様で、メモリの確保と解放は、見た目上も対で存在すべきなのだ。

世の中にはreleaseを書かないことを美しいように言っているホームページもあるようだが、メモリの確保と解放を意識しないことがメモリ漏れバグの温床であるから、むしろ「releaseは意識的に書く」方が美しく、理にかなっていると思う。
まあ、個人が「ちゃんと」理解して使っている分にはどちらでもいいのだが。


Cocoa Touchで提供されているクラスは、allocに対しては単純にreleaseを発行すれば解放される。
しかし、自分でクラスを設計するとき、その中で別の領域を確保するかもしれない。
このような場合は、単純にreleaseすると中の領域が開放されないまま残ってしまう。
このようなクラスの場合、中にdeallocメソッドを作って、独自の解放処理を記述しておく。
deallocはクラスをreleaseするときに内部的に呼び出されるメソッドである。
C++でいうところの「デストラクタ」に相当する、のだと思う。
 
@interface MyClass : NSObject
{
    NSString *string;
}
@end

@implementation MyClass

-(NSString *)initString
{
    string=[[NSString alloc]initWithString:@"初期化"];
}

-(void)dealloc
{
    [string release];
}
@end

~

MyClass *my;
    my=[[MyClass alloc]init];
    ~
    [my release]; // ここでdeallocが呼び出される
 
なお、deallocをユーザーが呼び出してはいけない。実行エラーとなる。
それはシステムがオブジェクトを解放するときに自動的に呼び出すものだからである。
ユーザーが呼び出すのはあくまでreleaseのみである。


Google Objective-Cスタイルガイド日本語訳 では「確保する変数はautoreleaseしてから代入せよ」と書いてあるけど、これは「すべての確保系をautoreleaseで行うときのみ」にのみ使える方法であって、上記のようにallocを使っている場合にはしてはいけない。確実に落ちる。
私個人的な感想としては、Googleのスタイルガイドには従いづらい部分が多いので、基本的には無視している。クラスメンバー名の付け方とか、TABとか。


オブジェクトは多くの場合、初期化を必要とするC++ではコンストラクタと呼んでオブジェクト生成時に自動的に呼び出しがかかるが、Objective-Cでは初期化をイニシャライザまたはコンビニエンス コンストラクタと言い、明示的に呼び出す必要がある。


イニシャライザ(initializer)/コンビニエンス コンストラクタ(convenience constructor)はどちらも初期化を行うメソッドであり、よく似た機能を持つが、前者がインスタンスメソッド用、後者はクラスメソッド用で、動作も微妙に違う。


実はクラスの「内容=メンバー変数」はインスタンス化されるときに0で初期化されることが決まっている。Cはauto変数は内容不定だったのとは違う。これは、実はObjective-Cのクラスはスタック上に作られるauto変数ではなく、メモリ上に直に確保されるグローバル変数だからである。Cもグルーバル変数は0で初期化された。Objective-Cで特別に変更された仕様ではない。
(ただし、通常はイニシャライザで必要な初期値を与えておくべきである)。


しかし、インスタンスのアドレス自体はnil(=0)ではない(そのアドレスがselfである)。
プログラム上、時にインスタンスのアドレスをnilで初期化して呼び出すことを要求しているクラスがあるので注意が必要である。



initはNSObject(NSObject)が用意しているインスタンスの初期化用の標準的にイニシャライザー(メソッド)である。多くのクラスはこれをオーバーライドして独自の初期化処理を追加している。
initは多くの場合、初期化された自身のオブジェクトのアドレス=selfを返すが、オーバーライドの実装によっては他の値を返したり、nilでエラーを返す場合もある。
従って、そのリターン値を確認することは重要である。


@interface Point : NSObject
{
    int x;
    int y;
}
- (id)init;     // 引数なしだから変数名のように見えるけど、関数
- (id)ObjFree;  // 〃
- (int)getX;    // 〃
- (int)getY;    // 〃
@end

@implementation Point
- (id)init  // initは引数を持たせることが出来ない
{
    [super init]; // 親クラスのinitを呼び出しておく;子クラスを作る時は必須
    self = [super init];
    if (self != nil) {
        x = y = 0;
        printf("init method\n");
    } // self==nilの時は何らかの原因で初期化に失敗している
    return(self);
}
- (id)ObjFree
{
    printf("ObjFree method\n");
    return [super ObjFree]; // 親クラスのObjFreeを呼び出しておく;子クラスを作る時は必須
}
- (int)getX
{
    return(x);
}
- (int)getY
{
    return(y);
}
@end

int main()
{
    id pt = [[Point alloc]init]; // 確保して初期化
    //      [Point new];    と書き換えることも出来る。new=alloc+init
    printf("x=%d,y=%d\n", [pt getX] , [pt getY]); // なんか変数を並べているようで違和感あるなぁ
    [pt ObjFree];
    return(0);
}
initはオーバーライド時にも引数を持たせることが出来ない。無理に持たせようと定義してもコンパイラがエラーを出す。これはnewというクラスメソッドが=alloc+initと定義されているので、その互換性を維持するためだろう。


そういうこともあって、Point.init()は引数を取れないので=0という固定値で初期化しているが、
引数付きとして任意の値で初期化する場合は別途そういうイニシャライザを定義する。
それを「指定イニシャライザ」といい、慣習的に名称はinitWith~とする。


initと同じく、子クラスのイニシャライザでは、superで親クラスの初期化も行う必要がある。
 
@interface Point : NSObject
{
    ~
}
- (id)initWithPoint:(int)x arg2:(int)y;
~

@implementation Point
- (id)init // initは引数を持たせることが出来ない
{
    [super init];   // 親クラスのinitを呼び出しておく;子クラスを作る時は必須
    return [self initWithPoint:0 arg2:0];
}
- (id)initWithPoint:(int)x arg2:(int)y
{
    self->x = x;
    self->y = y;
    return(self);
}
int main()
{
    id pt1 = [Point new]; // alloc+init=new
    id pt2 = [[Point alloc] initWithPoint:400 arg2:300]; // こちらはnewにはできない
    //
    printf("pt1.x=%d,pt1.y=%d\n" , [pt1 getX] , [pt1 getY]);
    printf("pt2.x=%d,pt2.y=%d\n" , [pt2 getX] , [pt2 getY]);
    [pt1 ObjFree]
    [pt2 ObjFree]
    return(0);

実行結果(未確認)
pt1.x=0,pt1.y=0
pt2.x=400,pt2.y=300
ObjFree method
ObjFree method
「メモリ管理」も参照のこと。



2013年8月8日木曜日

Objective-Cの勉強(5);super



super



クラスを継承した子クラスでは、親クラスを同じ名前のメソッドを作り、処理を置き換えることが出来る。これをオーバーライドという。
オーバーライドした時でも、親のメソッドを呼び出す必要がある場合は「super」を使う。
(親クラスは英語で「SuperClass」と書く。子クラスは「SubClass」。)

@interface SuperClass : NSObject
// 変数がないので{}は省略
- (void)method;
@end

@interface SubClass : SuperClass
// 変数がないので{}は省略
-(void)method; // 同一名関数を作りオーバーライドする
@end

@implementation SuperClass
- (void)method
{
    printf("SuperClass.method\n");
}
@end

@implementation SubClass
-(void)method
{
    printf("SubClass.method\n");
    [super method]; // [SuperClass method]を呼び出す
}
@end

void CallMethod(id obj)
{
    [obj method];
}

int main()
{
    CallMethod([SuperClass alloc]); // [SuperClass method]が実行される
    CallMethod([  SubClass alloc]); // [SubClass method]が実行される→その中で[SuperClass method]も呼び出される
    return 0;
}

実行結果(未確認)
 SuperClass.method
 SubClass.method
 SuperClass.method

こうした時、CallMethod()は引数によって呼び出し関数を変更することになる。
Cではswitch caseか関数のアドレスを持つ配列を使った呼び出しUByte (*fnc)()[]を使ったが、
その辺りの記述が大幅に簡潔になる。
superはselfとは違いアドレスを示すものではなく予約語なので、super->という使い方は出来ない。

2013年8月1日木曜日

Objective-Cの勉強(4);メソッド実体実装


メソッド実体実装



メソッドの実体実装は、@implementationで行う。

@implementation クラス名
+(リターン値)関数名:(引数型)引数    // クラスメソッド
{
    return(リターン値); // 当然(void)なら省略
}
-(リターン型)関数名:(引数型)引数    // インスタンスメソッド
{
    return(リターン値);
}
命名規則はCと同じだが、習慣的にメソッド名は小文字から始めるらしい。
(Cとしての通常変数名とメソッド名は同じになっても良い。でも分けた方がわかりやすいのは当然。)


クラス宣言と実体記述は、ファイルを分離するのが「原則」である。
ファイル名は同じで、拡張子はヘッダーは.hでCと同じだけど、実体は.mと異なる。
実はXcodeでは.cと.mでコンパイル時の挙動がかなり変わる。
自動的にimport/includeするファイルが異なり、また.c内では、ごく一部を除きObjective-Cによる拡張部分は使えない。
<UIKit.h>のimportも許されないし、@"~"もエラーになる。と言うことは、それを使うNSLog()などの関数も使えないと言うことを意味する(代わりにprintf()を使う)。
先に書いたとおり、BOOLも.c内では使えない。
例外は、私の知る限りでは#importくらいである。これはプリプロセッサ命令だからだと思される。
逆に、.m内ではCの全てが使える。従って、基本的には.mで統一しておいた方が面倒がなくて良い。


Objective-Cではインスタンスもしくはクラスにメッセージを送ることでメソッドを実行させる。
この「メッセージを送る」式はCに対して拡張された部分なので、識別できるように[]で括る。これをメッセージ式という。
あるメソッド中で同じクラス内の別のメソッドを呼び出す場合は[self 関数]と記述する
Objective-Cにおいて、メソッドの呼び出しは基本「オブジェクトへのメッセージ送信」の形を取るからである。
自分自身クラス中である場合にはselfが必要となる(メソッド名(引数)という形で呼び出すことは出来ない)。
「基本的に」Cで記述された部分とObjective-Cで記述された部分は切り離されているからである。
その垣根を越える方法はあるが、難しいので省略。

//                                _____引数型
-(int) CheckDropPoint:(int)x arg2:(int)y
//                    ~~|~~  ~|~~
//                   引数型  第2引数ラベル
{
    ~
    return(1);
}
- (int) Cascades
{
    while ([self CheckDropPoint:x arg2:y]==0) { // ←ここ要注意
        r=[super getScrn:x+1 arg2:y];           // ←親クラスのメソッドに対してはメッセージで送る
        ~
    }
    return(0);
}

クラスインスタンスを保存しておく必要がない場合は、その確保宣言そのものを省略して、
[[Class alloc] method]
と記述することも出来る。


プログラムの実行がmain()からなのはCと同じ。
iOSアプリケーションの場合はもう1段上のクラスからの呼び出し処理が入るのだけど、
その辺りは「アプリケーション実装の勉強」で。

int main()
{
    id obj = [Class alloc];
    [obj method];
    return (0); // iOS上ではexit()は使えない
}
メソッドは、クラスを@implementationで実装すれば使えるようになる。
処理実体がメモリ上に存在するということである。
しかし、@implementationしてもメンバー変数は確保されない。
クラスインスタンスの実確保は別途行う必要があるということである。
メンバー変数にアクセスするメソッド=インスタンスメソッドはクラスの実体が確保されるまで実行できないが、クラスの構造だけに依存するメソッド=クラスメソッドはこの時点で実行できる。
この「実体の存在」の認識はObjective-Cでは非常に重要となる。



式の記述上は似ているメンバー変数とグローバル変数には、実は根本的な違いがある。
「メンバー変数はアドレスが固定でない」ということである。


グローバル変数は、コンパイラがコンパイル時にそのアドレスを確定する。
(正確にはリンカーやOSがプログラムをメモリ上に読み込み際に確定される)。
だから、プログラム内どこからアクセスしても同じアドレスにアクセスする。
しかし、クラスメンバはインスタンスによってアドレスが変わる。
だから、記述上は同じに見えても実行時のアクセスという意味では全く異なるわけである。


Cで構造体の制御関数を作るときは、必ず、引数に構造体(多くの場合そのアドレス)を渡すことが必須となる。
制御関数内でのメンバーへのアクセスは、その引数のアドレスからの相対アドレスによる。
ところがObjective-Cのクラス定義では@implementationにクラスのアドレスを渡す記述はない。ないが、内部的には、クラス内のメソッドが実行されるときには、自動的にその時使うクラスインスタンスのアドレスが渡される。
逆に言えば、クラスインスタンスのアドレス確定=領域確保は絶対必須であるということである。


クラス実装はあくまでひな形であって、クラスそのものの領域確定宣言そのものではない。このあたり、慣れるまではクラス実装を書いただけで、インスタンスがあるような錯覚を起こすことがあるので要注意である。


ここからは少し、高度なお話。
iOSは実はかなり高度にマルチタスクを行う。少なくとも、メソッド単位ではマルチタスクが基本になっているので、「このメソッドを呼び出して、返ってきてからこの処理が走って・・・」と考えてはいけない。メソッドを呼び出したら、帰りを待たずに呼び出し側は次の処理を実行してしまう、こともある。どこが待ってどこが待たないかは実のところはっきり理解してないのだが、たぶん「リターン値を持たないメソッドは並行動作する」で間違いないと思う。
少なくともUIKitは呼び出したら即並行動作するので、「表示されたはずだから」と想定してその後の処理を書いてはいけない。
表示が完了したらデリゲートが呼び出されるので、そこで後の処理を書く必要がある。
あまりに高度な並行動作なので、頭の中でなかなか追い切れなかったりする。
自分でマルチスレッドなどを書いたらさらに複雑になるわけで、μITRONのようなイベントドリブン型マルチタスクに慣れているなら、考え方を根本的に変える必要があるかもしれない。(私がそうだった)。
絶対に処理終了を待つ必要がある場合は、別途フラグなどで判定して待つ必要がある。
しかし、ループで単純に待ったら他のスレッドが走らなくなるので、いろいろと対策を入れる必要がある。

拙作X-BASIC for iOSはマルチタスクでないプログラム動作を実現するために、このあたりがかなり複雑になっている。実はBASICのコア自体がバックグラウンドで動いてたりするのだが、その辺の話は、そうさなぁ、1万本くらい売れたら書くと言うことで(^_^;)。


2013年7月23日火曜日

Objective-Cの勉強(3);クラスの宣言



クラスの宣言



クラスはObjective-Cの肝であり、Cで言う所の「構造体」を大幅に機能/思想拡張した物である。
クラスは通常何らかの親クラスからの継承で作られる。


表面上、何も継承することがない場合でも、クラスの基本的機能を内包させるため、NSObject(一部NSProxy)を親にする。
親クラスを書かない場合は、それらのクラスが持つべき全てのメソッドを自前で実装する必要があるので、よほど腕に自信がない限り行うべきではない。
メーカー提供のクラスは必ずNSObject(相当)を親にしている。



クラスの宣言には@interfaceコンパイラディレクティブを使う。
クラス名は習慣的に大文字から始めるらしい。

@interface クラス名:親クラス名
{
    変数型 メンバー変数宣言;
}
メソッド宣言;
@end
「例」
@interface AClass : NSObject
{
    id var;
}
-(void)setVar: (id)v;
@end

メンバー変数を持たないクラスの場合、{~}の部分は省略できる。
変数の型はCと同じ基本の型(int等)、もしくはid型を含む後述のクラス型となる。



クラス内で実装されるメソッドにとってメンバー変数は、プログラムの記述上はグローバル変数とほぼ同じ扱いができる。
これは楽そうに思えるが実は、「ローカル変数を使うつもりだったが実は未宣言で、同名メンバーがクラス内にある場合、コンパイルエラーにならない」ので要注意である。このあたりは命名規則を作って避けるようにしなければならない。



NSObjectから継承した場合、メンバーにはid self;というものも自動的に定義される。
self->メンバー名でメンバーに確実にアクセスできる。
メソッドの引数がメンバー名と重複する場合に有効であるが、これはCと同じで引数がグローバル変数を隠蔽してしまう「バグの元」なので、別の名前にするのが本筋であろう。慣れるまでは。

2013年7月12日金曜日

Objective-Cの勉強(2);メソッドの宣言



メソッドの宣言



メソッドは以下の書式で宣言する。
関数のプロトタイプ宣言に近い。Objective-Cでは関数名から引数のラベル名までを含め全体を「メッセージ」と呼ぶ。
 
 -(リターン型)メソッド名:(引数型)引数;                       // 1引数の場合
 -(リターン型)メソッド名:(引数型)引数1 label2:(引数型)引数2; // 2引数の場合
 -(リターン型)メソッド名:(引数型)引数,...;                   // 可変引数の場合

リターン型は必ず()で括る。なぜかというと、Objective-Cの基本型はintではなくid型というものになっているからである。要するに、この()はid型からの型キャストを示しているのである。事実id型なら()も要らないし、省略も出来る。しない方が良いけど。

id型はクラスに対し、動的に(=実行時に確定される)型や内容を変更することが出来る万能型。int等基本型の代わりにはできないけど。
idの本性は、オブジェクトのアドレスを示すポインターである。typedefで*を含めて名称定義してあるようなので、*は省略する。


引数の区切りは「:」であり「,」ではない。「,」は可変引数を示すからであるが、可変引数はあまり使われない。Apple提供のクラスでも、それほど多くは出てこない。
Objective-Cでは、同名メソッドを引数別に定義出来るため、必要性が少ないのだろう。
可変引数の取り出し型は、Cと同じくva_listとva_start()を使う。


2引数以上の場合、引数名にラベルを付けるのが「習慣」だそうな。ラベルはその直後の変数の物。すなわち、Objective-Cではメソッド名は第1引数のラベル、その後各引数にラベルを付けるということだ。ラベルなのでラベル名と:に間にスペースを入れてはいけない。
Objective-CはCからの拡張実装であるから、すでにそれが持っているラベル認識機能をうまく使った実装であると言えよう。
(実はラベルは省略可能だが「推奨されていない」。)


ラベル名を変えると、同じメソッド名でも異なるメッセージとして扱われる。
これはオーバーライドとはちょっと違い、メッセージの受信オブジェクトの変更になる。


メソッドはメンバー変数名と同じであってもかまわない。通常メンバー変数は外部から直アクセスさせることはないかららしい。
ただ、初心者は分けた方が迷わなくて良いかもしれない。



ラベル名はCの予約語名とは同じでも大丈夫だが、#define定数名と同じではいけない。
プリプロセッサの方が先にソースを通すためである。


1つのメソッドで複数の引数が同じラベル名を持っていても良いようである。
NSObjectには-(id)performSelector: withObject: withObject:というメソッドが存在したりする。
が、あんまり使うべきじゃないのでは、と思ったりする。



先頭の「-」はインスタンスへのメソッドであることを示す。
他に「+」というのもあって、これはクラスに対するメソッドであることを示す。
インスタンスメソッドは実体を持ったオブジェクトに対して実行される関数であり、クラスメソッドはクラスに実体を持たせる時に実行させる関数、もしくはクラスの特性をして持っておくべくメソッドと理解すればいい。


インスタンスメソッドはselfおよびメンバー変数にアクセスできるが、クラスメソッドはそれがアクセスできない。当然コンパイルするとエラーが出る。
クラスメソッドはクラスを実体化=インスタンス化するときなど、インスタンスがない状態でも呼び出されるからである。



init=初期化されていない/またはalloc=確保されていないクラス内のメソッドを呼び出すとどうなるか。
実は何も起こらない。エラーも何も発生せずに素通りしてしまう。Objective-Cでは初期化してしていないクラスはnilであり、nilへの呼び出しは全て無視するようになっているからである。
もし実装したはずのメソッドが実行されないときは、そのインスタンスが正しく初期化されているか確認すべきである。



2013年7月6日土曜日

Objective-Cの勉強(1);基本

しばらくの間、Objective-Cを勉強した時にまとめた文章をアップします。
全て独学で覚えたので、世間一般の認識とは違う部分があると思います。
私はアセンブラ→C言語→Objective-Cあがりで、特にCで考えることに慣れているため、それとの対比を多く行っています。


基本


まずは用語と基本を覚える。Objective-Cおよびオブジェクト指向言語特有の名称が多いが、覚えやすくするためにCの名称に置き換えることもする。その対応表の作成は後日に行うかもしれない。
要するにここはC言語は習得しているが、C++は勉強したけどあきらめた人(=用語ぐらいは少しは解る)向けで、「普通」とは異なるので注意(自分以外の誰が読んでんねん、という突っ込みは無視^_^;)。


まずは、絶対覚えなければならない基本用語。
オブジェクト メモリ上に配置されるワークエリアの一般名称
クラス オブジェクトのひな形(構造定義書)
Cの構造体に近く、その中に制御関数;メソッドも含む
メソッド クラスの専用制御関数
インスタンス クラスを実際にメモリ上に割り付けた「オブジェクト」実体
インスタンス化  クラスを定義しただけでは構造体宣言と同じく実体は存在しないので、
それを元に変数を宣言、実体をメモリ上に確保すること
継承 あるクラスの機能を受け継いでで新規のクラスを定義すること
親クラス(スーパークラス)の全ての機能を受け継いだ上で、新機能または置き換え分のみ実装すればいい
オーバーライド 既存メソッドを同名メソッドで再実装すること。
基本的には、子クラスで親クラスに存在するメソッドを同名メソッドで再実装する。
レシーバー メソッドを実行するインスタンスのこと。
Cの構造体だって関数をメンバーに出来るので(関数だって所詮はアドレスに過ぎないから)、よく言われる「構造体とクラスはメソッドの有無が違い」というのは実は間違い。


Cの構造体のメンバー関数は「呼び出す」というし、アセンブラレベルでもCallするが、Objective-Cのメソッドは「メッセージを送る」という。
実はObjective-Cの基本にして重要な思想がここに現れている。Cのメンバー関数は(基本的に)構造体に固定されているが、メソッドは受信するオブジェクトを選択することが出来る。

異なるクラスに同じメソッド(名)を実装した場合、それは「同じメッセージを受信できるクラス群」として扱われる。そして、あるメッセージを送信した場合、それを実際に受信するクラスによって動作を切り替えることが出来る。

Cでなら、同じメンバー名関数を持つ構造体群があったときに、場合によって構造体側を切り替える場合にはswitch caseか関数の実行アドレスを持つ配列に入れて切り替えるしかないが、Objective-Cでは受信するクラス名を変数に出来るため、このあたりが実に簡潔に記述できる。
この両者の「基本概念の向きの違い」を覚えておかなければならない。それが「オブジェクト指向」である(この場合「思考」の方が合ってそうだけど)。



Objective-CはCの完全な拡張であるので、一部に制約が付いたC++とは異なり、Cで使えた書式は全て使える。
変数の型も同じだが、typedefにより、見かけ上いくつか追加がある。
id オブジェクトを示す汎用変数(正確にはインスタンスのアドレス=ポインタ)
Class  クラスオブジェクト(クラスの定義内容そのものを持つオブジェクト)へのポインタ
SEL メソッドのセレクタ値
IMP メソッドの実行アドレス(ポインタ)
BOOL YES/NOのどちらかの値を持つ型


また、以下の定数もobj.hをimportすることで使える(標準定数)。
定数名用途・意味定義
nil CにおけるNULLをidに拡張したものと思えば正解。終端やエラーを示すのに多く用いられる(id)NULL
YES/true BOOLの肯定(BOOL)1
NO/false BOOLの否定(BOOL)0
NSNotFound 要素を探したが見つからないとき開発環境によって異なる
もちろんCの標準定数(NULLなど)も使える。
BOOLはCでも定義して使っている人が多いけど、私は使わない主義であった。
関数の改良時によく、それ以外のリターン値を返すようにしてたからである。でも今は「区別しといた方がいい」派になっている。「年々歳々人同じからず」である。



余談。実はCocoa Touch上には真偽値を示す型が複数ある。BOOL/Boolean/boolである。NS/UIクラスで使われているのはBOOL、しかし、plistという物で使われているのはBooleanであったりする。
Boolean/boolではtrue/falseが値として使われるが、YES=true/NO=falseである。
boolがISO Cの標準真偽値型のようなので、正確にはifで判定されるのはbool型だと言えるが、混在してもコンパイラのチェック上でも動作でも特に問題は起こさない。まあ、NS/UIクラスと同じくBOOLで統一しておくのが無難かも知れない。BOOLはObjective-Cのソース、すなわち.m内でのみ使える。BooleanはCのソース、すなわち.Cでも使える。C内ではBOOLはエラーになる。Booleanはどちらでも使えると思う。
実際の値は同じだが、相互に使える使えないがあるので、注意が必要である。




Cの関数も全くの変更なしに呼び出すことが出来る(C++はextern "C"でヘッダーの書き換えが必要)が、一部機能は強化されている。
(古い)CとObjective-Cの細かい違いとしては、
  • ヘッダーは「基本的に」#includeではなく#importで読み込む
  • プロトタイプ宣言が必須(前方参照不可)Xcode4.3では同一ファイル内では自動的に前方参照が解決されるようになった。
  • 一部の例外を除き、変数宣言をスコープの先頭で行う必要がない
と言うのがある。

#importはCのヘッダーで問題になっていた2重読み込みを自動的に排除してくれる。
ただし、#defineで定数の定義内容を書き換える(切り替える)タイプのヘッダーを#includeする場合は、#importに変更するとバグになる可能性がある。
Cのヘッダーは#includeで、Objective-Cのヘッダーは#importで読み込むのがいいかもしれない。


メソッドは、基本的に宣言と実体実装を別ファイルにするため、宣言ファイル(ヘッダー)を#importしておけばいいが、通常のC関数も、それがプロトタイプ宣言されているヘッダーを読み込んでおく必要がある。


(本当はクラスの独立性を高めるためらしいが、)ヘッダーを#importするのが面倒な場合で、クラス名であることを宣言するだけで良いなら、
  @class クラス名1,クラス名2...;
というコンパイラディレクティブを使って宣言しておける。Cにおけるexternに近い。
「コンパイラディレクティブ」とは、Objective-Cで拡張されたプリプロセッサ命令である。プリプロセッサ命令であるため、コンパイル時には実内容に展開される=静的に決定される。


古いCの場合、ローカルに新規の変数を使う場合は必ず新しいスコープの先頭(宣言文以外が出てくるまで)に宣言しなければならなかったが、Objective-Cではこれがかなり緩くなる。本当は最近のCの規格ではそういうものらしい。
ただし、一部例外がある。

Cの場合         Objective-Cの場合
{               {
int x;              int x;
    x=1;            x=1;
    {               int y; // 必要時に宣言すればよい
    int y;          y=x+1;
    y=x+1;
    }
}               }

Cの場合         Objective-Cの場合
switch (x) {      左に同じ
  case 1:         switch内だけはスコープを新規に作る必要がある
     {              (厳密にはcase文の直後に宣言するときのみ、新規スコープの宣言が必要。)
     int y;       "Switch case is in protected scope"エラーが発生することもあるが、発生しないことのほうが多い。
     y=x+1;       
     }
}
という具合である。ただし、正確には上の例は変数yのスコープが異なる。Cの場合の記述は{}の中だけで有効だが、Objective-Cの記述では宣言以降全てである。従って、厳密にスコープを規定する場合は、Objective-CでもCと同じにする。単に「使うときに宣言したい」という意味の時のみ書き換えることが出来る。


各種名称の命名規則は基本的にCと同じであるが、「習慣的」には推奨がある。
クラス 大文字から始める
メソッド 小文字から始める。_(アンダーバー)から始まる名称は禁止(アップル予約)
カテゴリ 大文字から始める
プロトコル 大文字から始める
ラベル   小文字から始める
型名 クラス名に準じる(だから見分けが付かなくてややこしい)
変数 小文字から始める
定数 Cの場合大文字だけど、Objective-Cはクラス名に準じる(だから見分けが付かなくてややこしい)

ただし、Google推奨記法ではkで始めると書いてある。アップル標準もそういうのが多い。


また、「同じ名前を付けたときにどうなんねん」については、以下の規則がある。
  • メンバー変数名とメソッドの引数が同名の場合は、メンバー変数名が隠蔽される(要注意)。この場合、self->で回避できる(メンバーアドレスへのアクセスであり、プロパティ式ではない)
  • メソッド名および引数ラベル名は予約語名と同じでもかまわない(int:とか)
  • メソッド名および引数ラベル名は#define定数名と同じではいけない。プリプロセッサの方が先にソースを通すため
  • クラス同じ名前のグローバル変数はあってはいけない(コンパイルエラー)
  • 異なるクラス間では同じメソッド名を使うことが出来る
  • 継承したクラスが親と同じメソッド名を持つ場合は、親のメソッドの代わりに実行される=オーバーライド
    親のメソッドを実行する場合は、superを使う
  • 継承したクラスに親と同じメンバー変数名を持ってはいけない(コンパイルエラー)
  • 異なるクラス間では同じメンバー変数名があってもかまわない
  • メンバー変数とメソッド名が同じでもかまわない。というか積極的にそうしてメンバー変数への直アクセスをさせないようにする=プロパティ
  • インスタンスメソッドには、クラスメソッドと同じ名前を付けてもいい(対象によって自動的に切り替わる)
  • プロトコルには、クラス、カテゴリ、その他のものと同じ名前を付けてもいい
  • 1つのクラスのカテゴリには、他のクラスのカテゴリと同じ名前を付けてもいい
この他はCと同じ。詳細はその都度。
Objective-Cでは同じ名前でも、機能さえ異なればちゃんと識別される場合が多いということだ。
同一機能であれば同じ名前にしておくとわかりやすいかもしれないが、だからといって全然異なる機能に同じ名前を付けるとバグの元なので避けるべきである。


こまどり君 V1.5;超簡易説明書

iOSアプリ「こまどり君」の使い方が解らん、という方がいらっしゃるので、
ここに超簡易説明書を置いておきます。
V1.5からはこちらが内蔵になり、詳細取説はサポートページに置かれます。


・・・








・・・


不具合報告及び要望は、必ずこちらにコメントでお寄せください。

「動かない」と書き殴るだけでは何も解決しません。
手元の開発環境では動くことを確認してから審査に出し、しかも審査も通っているのですから、動かないのは設定または環境に依存するからです。

不具合報告は必ず
・機種(モデル名、メモリ容量、WiFiか3Gか)
・iOSバージョン
・設定
・具体的な不具合状況
を添えて送ってください。

それがないものは全て無視します。

AppStoreのカスタマレビューを読まないのもそれ故です。
あれは開発者にとってはほとんど無意味、というよりむしろ読むだけ不快になる代物です。
有意義な20件に1件くらいでしょうか。

ごくまれにそれらを添えて報告をくださる方がいらっしゃります。
非常に感謝しております。残念ながら、手元で現象が再現できないこともありますが、出来るだけの対応と何かしらの回避策は提案できるはずです。

個人が趣味で作っている以上、サポートに使える時間は限られています。有償であってもそれは変わりません(非常に安いシェアウエア)。ゆえに、より有効な情報と励ましが必要なわけです。
そのあたりをご理解の上、ご協力をお願いします。




2013年6月7日金曜日

Mac Blu-rayプレイヤーやVLCでテンポがずれる問題について

Mac Blu-rayプレイヤーでは、盛大にテンポがずれることがある。
音楽のテンポがおかしかったり、音程が微妙に狂ったり、セリフが長伸ばしされたりである。

メディアからの読み出しが遅れた時やCPU負荷が高まった時に発生しやすい。

一方、フリーウエアのVLCメディアプレイヤー でも同様の現象が多発する。
Mac版でもそうだが、Windows版は聞くに耐えないほどひどく発生することがある。
USB接続のHDDからデータを読み込んでいる時に特にそう思う。

どうやらこの2つは同じソースを元に作られているらしい。
VLCはフリーウエアで、Mac Blu-rayプレイヤーは商用だが、後者で行われた改良や修正
がVLCに取り入れられている、という関係らしい。

逆に言えば、両方とも同じ問題を持っているとも言える。

このテンポの問題もその1つ。

はっきり言って、こんなにテンポがずれるもので音楽聞いてたらおかしくなる。とても気持ち悪い。全く使いものにならない。なんでこんなんでOK出してるんだ?
世間でこのテンポ問題が全く出ていないのが理解不能。環境によるのか?


Mac Blu-rayプレイヤーは、BDプレイヤー部の出来があまりに悪いので使うのをやめてしまったが、音楽プレイヤーとしても、根本的に使いものにならないと判明した。

どうしても使わなくてはならないなら、
・内蔵ドライブに音楽ファイルを入れておく
しかないような感じ。今のところは。USB3位なら大丈夫なのかもしれないけど、少なくともUSB2やIEEE1394ではだめ。

・・・そういえば

X68000の音楽ドライバーでは、割り込みの受け付け方の微妙な差異でテンポのズレが起こるからどうしたとかいう、そんな議論がなされていたことを思えば、これらのダメさ加減は、少なくとも音楽においてテンポの重要性を全く意識してないか理解してない人間が開発しているとしか思えない。根本的に作りなおすことを提案したい。

・・・

少なくともWindowsでは、VLCほど出来の悪いプレイヤーは他に知らない。
Windows上にはプレイヤーも数多くあるから、これを選択する必要は全くない。
でも、Macでは、プレイヤーの選択肢がとても少ないから何とかなってくれればいいと思う。
iTunesは不明のアーティストのを勝手にまとめる大問題がいるので使えないし。
求む、まともなプレイヤー on Mac。

調査結果
songbird アーティスト別にまとめたがるのはiTunesと同じ 
Play(0.3) waveに対応してない(リストには出るが音が出ない)
sonora  文字化けする


Fusion4 windows上にUlilithでも入れるしかないのか。
でも問題は、USB-HDDを認識させられないこと。
これはFusion側の問題。

2013年5月28日火曜日

一太郎や花子のヘルプを見ようとするとATOKのインストールを求められる問題とその解決法

一太郎や花子のヘルプを見ようとすると、毎回ATOKのインストールを求められる問題が発生していた。

現在の最新バージョン「一太郎 玄」「花子2013」でもそうだし、実は以前のバージョンから発生していた。

「マニュアル」「トラブルQ&A」「新機能の紹介」 などは問題なく見られるのに、ヘルプでだけこの現象が発生した。

 面倒なので、今まではヘルプを見るのをあきらめていたが、今回突っ込んで調べてみた。そしてようやくその原因を突き止めた。

 原因は
スタートメニューのルートに『JustSystems ツール&ユーティリティ』というフォルダが存在しない
と言うことだった。逆に言えば、それがあればこの問題は発生しない。

Justsystemの製品をインストールすると、スタートメニューのルート、正確には

  c:\ProgramData\Microsoft\Windows\スタートメニュー\プログラム
 (Windows7の場合)

の位置に、アプリケーション別にフォルダと作る。
ATOKとか一太郎とか。その中に「JustSystems ツール&ユーティリティ」というのも作られる。

私は、同じ会社のアプリケーションは1つにまとめたい主義なので、Justsystemというフォルダを作って、それらをその下に移動していた。

ところが、一太郎や花子のヘルプは、ルートに「JustSystems ツール&ユーティリティ」フォルダがあることを調べているらしく、ない場合、ATOKのインストールをしてそれを復活させようとするのだ。


このフォルダの中にあるのは「JS使用者情報変更ツール」という物へのショートカットだけだが、それは削除してもかまわない。要は、フォルダのみをルートに残しておく必要があるというわけだ。

なお、「JustSystems ツール&ユーティリティ」フォルダに隠し属性を付けておけば、スタートメニュー上は表示されなくなる(ただし、Windowsの再起動が必要)。

・・・

このように、スタートメニュー中のフォルダまたはファイルの存在を検知しているソフトなんて他には見たことがない。Justsystemだけの理不尽というか、極めて無意味なくせに有害な仕様であると言える。次のバージョンでは是非ともやめていただきたい。

ちなみに、同社の製品では

 三四郎2009、ホームページビルダー16、Shuriken2012

が同様であり、

 花子フォトレタッチ
  一発!OCR Pro6
 翻訳ブレイン3

では問題なかった。OEM製品および同社製でも古い物は大丈夫という感じ。
ということは、同社製のヘルプ表示プログラムの問題だろう。

・・・

本当はJustsystemに直接報告もしたいのだが、いかんせん同社のサイトには問題を報告する窓口がない。少なくとも普通に見つけられる場所には存在しない。

電話受付はあるが、こちらから高い電話料金をかけてまで問題報告をしてやる義理はない。


オンラインの問い合わせ口があると、いろいろと送られてきて嫌だ、というのは理解できんでもないが、.それなりの価格の物を大々的に売っているのだから、やはりホームページ上にオンラインの問い合わせ口は持つべきだ。

サポートという面においては同社の姿勢は、全く感心しない。
ここまでサポートが手抜きな会社は、大手中小含めて他に知らない。

たとえば、いくらバグが多くても、Appleは報告窓口があるだけ良心的だ。
自社でまかなえない部分は、フォーラムを開設してユーザー同士で情報交換するのも一手だ。これもAppleはやっている。

その点も、是非とも改善していただきたい。

・・・と、直接言ってやりたい。

2013年5月25日土曜日

UIWebViewの特異的レンダリングについて

UIWebViewはHTMLをレンダリングしてくれるが、どうも他のブラウザとは結果が異なる部分が存在する。それもHTML5とか新しい部分ではなく、極めて簡単と思われる部分で。
気がついたのは以下の部分。

(1)<pre>中の<table>内の<br>の挙動

<pre>
<table>
<tr><td>メッセージ<br>
改行</td></tr>
</table>
</pre>

と記述した場合、UIWebViewは

メッセージ

改行

となり、Chrome/Firefox/Safariでは

メッセージ
改行

となり、<br>改行の挙動が異なる。

この違いがレンダリングエンジンの違いから来るならまだ理解できるのだが、同じWebKitのはずのSafariとUIWebViewが異なるのがわけのわからんところ。UIWebViewはWebKitではないのか?

そもそも<pre>内に<table>を記述するのが文法違反だという話もあるが、現実に存在する以上、合わせて欲しい気はする。

(2)オーディオファイルのaiffが再生できない
(3)<audio>〜</audio>の部分に改行が入ってしまう
このため、<audio>定義は表示上影響の少ない部分にまとめておく必要がある。

2013年5月20日月曜日

Xcode 4.6.2のバグ

Xcode4.6.2は比較的安定しているバージョンだと思ってたけど、やっぱりバグが有った。

・C Flagsの設定で-Dオプションをつけた場合、3つ目以降が無視される
たとえば、-DDEBUG -DIOS -TESTとした場合、DEBUGとIOSはdefineされるが、TESTは定義されない。

コンパイル結果がどうにもおかしいので調べたらこれだった。

これは勘違いだった。
PROJECTではなくTARGETで設定するのが正解か。
おかしいなぁ、今までPROJECT側でいけてたと思ったんだけど。


・シミュレーター環境で、2回に1回しかRUNできないCouldn't register アプリケーション名 with the bootstrap server. Error: unknown error code.
This generally means that another instance of this process was already running or is hung in the debugger.
と出て起動できない。実際にはUIApplicationMain()呼び出し時にsignal SIGABRTを発生して止まる。
実機では発生しない。まったくもって意味不明。

→4.6.3では修正された。

・[UITextField.layer setAffineTransform]の結果がおかしい
UITextFieldをUIViewにaddSubviewする。このとき、UIView.layerにsetAffineTransformで変形をかけてあったとしても、UITextFiledでそれが無視される。ならばとUITextFiled.layerにも同じ設定すると、多くは良くなるが、なぜかy座標だけおかしくなる。
なので、frameで表示位置の再設定が必要になる。
言葉で書くとわかりにくいけど、プログラムで実行するとすぐ解る。X-BASIC for iOS V2.1でのinputのバグはこれが原因。



あと、前から直ってないのがこれ
・Open Separate Assitant Editorした場合、第2画面以降で単語補完がすぐ消えてしまう


-Dが効かないのは、たとえば.pchの中で#defineすれば回避できるけど、面倒。
Appleの作るものにバグがなかった試しはない。
新機能部分にバグがあるならまだしも、エンバグが多いのが困ったものだ。


2013年4月21日日曜日

ATOK2013の誤変換出まくり問題の解決法

ATOK2013にしてから誤変換が多発した。


ATOK2013は、最初はインストール問題から始まり、入れてからもあまりの誤変換の多さに嫌気がさして利用をやめていた。Google日本語入力を使っていたが、辞書登録がやりにくいのでATOK2011に戻していた。

が、ATOK2011と2013の設定を見比べているうちに「ここが原因ではないか?」と思われる部分を見つけ、やってみたら直った(たぶん)。

・・・まずは、誤変換多発時の変換状況・・・

こんな変換をしやがった。


「あさおきたらかだらがいたい」   「かいけつほう」
ATOK2013      「麻生キタラからだが痛い。」    「解穴法」
ATOK2011       「朝起きたら体が痛い」        「解決法」
Google日本語入力 「朝起きたら体が痛い」        「解決法」

昔はFEPの誤変換をあげてネタにしたこともあったけど、最近は効率がよくなっておもしろい誤変換にはあまり出会えなくなった。しかし、ATOK2013では「狙っているのではないか?」と思うほど多発した。
どうも名詞を最優先するようだ。「そこはどう考えても名詞が来る場所じゃないだろ」という場所でも名詞単語を出してくる。しかも傾向として、難しい=あまり使われない単語を優先する感じ。

「使うたびに発見がある」 ではあったが、遊びならまだしも、長文書いているときにこれをやられたら、たまったもんではない。

・・・そして解決法・・・

結局何がいけなかったかというと、辞書設定にて、標準辞書セットには他の変換辞書を入れてはいけないということであった。


 ↑これが正しい設定で、ここに
を入れたら変換がむちゃくちゃになる。
(角川~辞書は入れても問題ない。)

使ってみるとわかるが、この3つの辞書(だけで)変換辞書として使うと正しい変換を全くしない
じゃあ、標準辞書を優先にして、これらを組み合わせたらどうなるかと言えば、これが私の所で発生してた誤変換出まくりになるわけである。

ゆえに、これらは変換辞書には設定してはいけない。電子辞書検索にのみ設定する、が正解である。

(3つ全部だけがだめなのではなく、どれか1つでも入れたらだめ。)

ATOK2011でもたぶん同様になる。

なお、いったん3つの辞書を入れて誤変換だらけな状態から外した場合は、学習結果をクリアし、省入力変換辞書や、確定履歴も見直すかクリアした方がいい。変な癖が付いてしまっているので。

そもそもの原因は、変換辞書としては使い物にならないものに、変換辞書として設定をできるようにしていることなので、「設定できなく」してほしい。

・・・余談・・・

先日あったJustSystemの一太郎玄アンケートにも「ATOK2013が全く使い物にならねぇ」と書いてしまった。しかし、今回やった設定は別段特異なものではなく、辞書の意義からすると当然考えられる範疇だから、決して間違ったことは書いてない。よって謝罪する気もない。が、ちょっと後味悪い気もしてる。

ちなみに、これで変換が戻ったからといってATOK2013の変換効率が2011に比べて良いかと聞かれると、「特にそうは思わない」というのが正直なところである。統計を取ったわけではないが、2011の方が変換効率が良いような感じもする。
推測変換に関しては、明らかにGoogle日本語入力の方が数段上。

念のため現在は、ATOK2011/2013、 Google日本語入力を共存させてある(MS-IMEも一応あるけど、全く使ってない)。なお、ATOK2013を導入するときATOK2011も残すように設定すると、2011から2013への単語登録や学習内容などの引き継ぎが行われないようである。極めて面倒。

(引き継ぎさせる方法:
(1)ATOK Sync2011でATOK2011の設定を保存
(2)ATOK2013を導入&2011を削除;ここでATOK2011→2013の引き継ぎが行われる
(3)ATOK Sync2013を導入、2013の設定を保存
(4)ATOK2013/Sync2013を削除
(5)ATOK2011/Sync2011を導入
(6)ATOK Sync2011で設定を戻す
(7)ATOK2013を追加で導入
(8)ATOK Sync2013を導入、設定を戻す;この時点でSync2011は削除される
これで設定を引き継いだ状態で共存環境が出来る。)

ATOKにはさらなる精進を期待したい。


・・・余談・・・
ATOKは「いやがおう」では変換できない。「いやがおうでも」まで入力しないとだめ。
2013も2011も同じ。
変換できなくても推測表示して欲しい。そうでなくても意味合い的に間違いやすいのだから。
Google日本語入力ではちゃんと出してくれる。
やはり推測変換ではGoogle日本語入力が数段優秀。

・・・やっぱり
学習すればするほど馬鹿になるのはATOKの伝統だけど、2013はいっそうその傾向が強い気が。時々学習結果を消さないと誤変換出しまくりになる。
学習は弱めにするのが良いのかも。

使いものにならないので標準を2011に戻した。ソフトウエア は試用ができないので、買ったけど使い物にならなかった時に困る。

2013年4月9日火曜日

ゼンハウザーHD580のイヤーパッド&ヘッドパッドの交換方法

ヘッドフォンとしてゼンハウザーのHD580を愛用している。しかし購入して10年、さすがに耳当て部分(イヤーパッド)と頭の部分のクッション(ヘッドパッド)がへたってきた。
HD580は装着性も音も非常に気に入っているので、買い換える気は今のところない。 
というか家計的に無理。そこで、それらを交換することにした。 

調べてみると、イヤーパッド自体は楽天のe☆イヤホンという店で購入できた。送料込みで5250円だった。
また、交換方法についてはここに情報があった。基本的にはその通りに行うのだが、若干情報が少ないので、追記も兼ねてここに記述する。
私は、ヘッドパッド部の修繕にはスポンジとクリアファイルを使った。 

・・・
これが10年経過したイヤーパッド。この角度からはわかりにくいが、クッション部の弾力が少なくなり、変色している。また、写真ではユニット部が見えているが、本当はここにも薄いスポンジがあって、見えない。破けてしまっているのだ。

 まずはこのイヤーパッドを取り外す。ちょっと堅いが、力まかせで引き抜くしかない。外れると、下にある薄い「元」スポンジシートが見える。、穴が開いてユニットが見えている。

 そのシートも外すと、このようになる。

スポンジカスをきれいに取り除く。その上にあたらしいスポンジシートを置く。

さらにその上に耳当て部を置く。そして、このあたりを強く押してはめ込む。

これでイヤーパッド部の交換は終わり。交換部品には手順説明が一切なく、かつ上記情報サイトにもその方法に関する記述がない。いろいろと試して解ったのがこれである。

イヤーパッドを自前で修理できないかどうかだが、これはまず無理。
スポンジシートはなんとかなるが、クッション部分がスポンジを布で巻いて接着剤で固定してあるため。よほど腕に覚えがあれば再生できるかもしれないが、極めて難しいといえる。なので、ここは素直に購入したほうが良いかと。

・・・

次はヘッドパッドの交換というか修繕。
こちらは部品は購入しなかった。けちったのではなく、「交換する必要はない」と何故か思い込んでいたためである(同店で買うと2625円)。
実際には、こちらの方が劣化が激しかった。

これがヘッドパッド部分。完全にへたってしまい、膨らみがないのが解る。 まずは、これを取り外す。赤丸の部分の留め具を外せば、ヘッドパッド部分を取り外すことが出来る。

留め具は、隙間にマイナスドライバーを差し込んでひねると外れる。

そうしたら、ヘッドパッド部をスライドして引き抜く。

外したのがこれ。スポンジ部が融けて完全にぺしゃんこになってる。


裏を向けてスポンジ部あたりをカッターで切り抜く。オルファカッターなら、一番浅く刃が出ている状態でちょうどであった。切り抜いた片は再利用しないので破棄してもかまわない。

中はこんな状態。ウレタンスポンジが加水分解と皮脂でどろどろになっている。
これを水と洗剤で洗いながら出来るだけ取り除く。 それだけでは完全には取れないので、あとは古布などでこすりながらきれいにしていく。ウレタンは、普通に家にある洗剤などでは溶かすことが出来ないのでこの方法しかない(と思う)。すると最終的には、布地の袋部が現れる。

乾燥させている間に、その袋部より一回りくらい大きいのスポンジブロックを作る。
私が使ったのは、とある筋から入手してあった導電スポンジであるが、普通のスポンジ、もしくは、弾力性のある布を詰めてもいいと思う。スポンジの場合、穴と同じ大きさではいけない。若干大きめの物を無理矢理入れ込むことで弾力が出る。

スポンジを切り抜いた部分の蓋にはクリアシートを使った。これをヘッドパッドと同じ大きさに切っておく。

ヘッドパッドを元に戻す。まずはクリアシート片をヘッドパッドが入る部分に入れておく。
その上から修理したヘッドパッドを入れる。これでクリアシートが蓋の代わりになる。
そもそも隙間がほとんどないので、ヘッドパッドに対して接着しておく必要はない。
入れ込んだら、留め具を戻す。まずは片側だけをはめ(他方は浮いた状態)、後でぐっと押し込む。

これでヘッドパッド部分も修理完了。結果、これほどふっくらとする。

多少手間はかかるが、これで、購入当時の装着感が戻った。
乾燥時間も含め、1時間見てればいいのはなかろうかと思う。

これを書きながら、PCの排気で乾燥させてた、というのは秘密でもなんでもない。
これもリサイクルの一種。