ラベル iOS7 の投稿を表示しています。 すべての投稿を表示
ラベル iOS7 の投稿を表示しています。 すべての投稿を表示

2015年6月24日水曜日

iOS8とXcode6.3.2(一部7)のバグ

X-BASIC for iOS v3.00の開発に際して、iOS8のバグとかiOS7との挙動の違いをいくつか見つけたので記録しておく。Xcode6.3.2のバグも。

巷で情報がないもの。

(1)iOS8で、UITextViewでズームを繰り返すとシステムが反応しなくなることがある
iOS7.1では問題ない。なので、iOS8.1では頻発、8.2以上では頻度は減ったけどやはり出る。
UIScrollView上にUIImageViewを載せた場合は問題なさそう。
 回避策なし。


(2)iOS8.xで、UITextViewでズームした時、画面外に出た部分を表示できない
表示及びスクロール可能範囲が拡大前のそれと同じであり、またスクロールもできないし、表示も欠ける。
iOS7では問題ないが、iOS8は全てのバージョンで不可。他の設定が必要になったのかと思ったが、それらしいものはなかった。
 回避策なし。

UIScrollView上にUIImageViewを載せた場合は問題ない。
(1)(2)のせいで、X-BASICではテキストのズーム表示をiOS8上禁止した。iOS7では動く。


(3)UITextViewのscrollRangeToVisible:selectRangeで指定範囲までスクロールしようとした時、iOS8ではその設定のあとそれを発行するtextViewの内容を変更してもその場所に飛ぶが、iOS7では無効になる。

「例」
[txView  scrollRangeToVisible:selectRange];
txView.attributedText=〜
iOS8では修正後テキストの指定位置に移動するが、iOS7では移動しない。

先に修正すればOK。
txView.attributedText=〜
[txView  scrollRangeToVisible:selectRange];

 iOS7の動作もおかしいとはいえないが、なまじiOS8で動いてしまうだけにiOS7上での隠れバグになりそう。


(4)iOS8/iOS7とも、UITextView.contentOffsetに値を設定してもそこに飛ばないことがある。
 txView.contentOffset=offset
 としてもだめで、
 [txView setContentOffset:offset animated:YES];
とするといける。=offsetの後にsetNeedDisplayを発行しても、RunLoopに戻すようにしてもダメ。
animatedにすると時分割でoffsetを与え続けてくれるので動くのだと思う。
ということは、contentOffsetへの設定が無視されるタイミングがあるのだろう。

(5)contentSizeの値が正しくない
これはiOS7で散々騒がれて回避ロジックも編み出されたけど、iOS8でも治ってなかった。

ちなみに、UITextView内で行を追加した時、各行の表示位置はsizeWithAttributesで求められる文字列描画高さの累積に一致しない。このため、各行の表示位置を正確に知る方法がない(それがX-BASICでスクロール同期がうまくいかない理由)。


(6)Xcode6.3.2のバグ;IB上でのUndo
以下の手順で操作すると、おかしくなる。
1. IB上で何かUI要素を乗せて実行して動作を見る。
 IBActionでの接続もしてたらよりわかりやすい
2. その要素を削除して実行
3. Undoで要素を戻す
 IBActionでの接続も戻っている
これで元(1.の段階のもの)に戻るように思うが、実際には戻らない。UI要素が表示されない。表面上どこにも問題ないのに戻らないのでしばらく調査したが、どうもXcodeのバグ臭い。要素を一旦削除し、再度乗せたらうまく行った。
IB上で、実行を挟んだUndoは気をつけろ、ということ。

(7)Xcodeのバグ;iPhone6シミュレーターで日本語にならない
ここに情報があった
簡単になったのかそうでないのかわからないところ。でもシミュレーター上でも切り替えられるようにするのが筋。

(8)Xcodeのバグ;Breakポイントが違う場所に付く
 break文にBreakポイントをつけると、実行時にはbreakして飛んだ先に設定されてしまう。
 breakを通過したあとで止まるならいいが、breakを通らない時も止まってしまうので、デバッグがしにくくなる。
「例」
switch (n) {
 case 1:
   break; <- ここにBreakポイントを設定しても
}
<-ここで止まってしまう。n=1でなくても。

Xcode7でも治っていない。Xcodeでブレイクポイントはあまり使いものにならない状態。
バックグラウンドで動くタスクの場合だけかもしれないが。

(9)シミュレーター上で、Intervalが非常に短い間隔のNSTimerを発行すると正しい時間にならない。
1/10=0.1秒くらいなら大丈夫そうだけど、1/1000秒になると1秒以上(正確には計ってない)に1回くらいになってしまう。iPad2を選択しているとうまく動くのにiPad RetinaやAirを選んでいるとだめなので、それらのバグ。ちなみに、実機ではちゃんと動く。

(10)Xcode7で、ツールバーが表示されないことがある。2つ以上のプロジェクトを同時に開いた場合、2つ目以降にてこうなる模様。表示を選択しても表示されない。また、一旦閉じるとツールバーの表示状態がリセットされてしまう。極めて面倒。

UITextViewはiOS7で大問題を起こしたけど、iOS8でも別のバグを入れ込んでいる体たらく。アップルはもっと開発者の声を聞いて、大量の人員を導入してバグ取りすべき。iOS9なんて出している場合じゃない。

余談:
UITextViewで、画面上に表示されている範囲を知る方法が欲しいのだけど、実装してくれないかなぁ。

2014年11月15日土曜日

iOS7以降におけるUIButtonの挙動の問題について

iOS7以降では、UIButton.textを設定した時、UIButton.textLabel.frameが変更されるのは実際に表示されるタイミングになっている。すなわち、.text代入時にはtextLabelの表示幅や位置は取得できない。

通常それを知る必要はないが、UIButtonではtextLabelは基本的にセンタリングで表示される(titleEdgeInsetで補正は可能)ため、例えばボタンを表示上左寄せしたい場合にはtextLabel.frame.origin.x=0にしなければならない。ところが、.text代入直後は.textLabel.frameは{0,0,0,0}であり、この時点で代入しても無効になる。

ではどうするかというと、KVOで.textLabel.frameを監視して、その代入があったタイミングで補正する。

こんな感じ。

――――――――
UIButtonWithLabelAlignment.h
――――――――
#import <UIKit/UIKit.h>

// 左寄せと上寄せがORで設定できる
enum {
  kUIButtonWithLabelAlignment_normal=0,
  kUIButtonWithLabelAlignment_left =(1<<0),
  kUIButtonWithLabelAlignment_up   =(1<<1),
};

@interface UIButtonWithLabelAlignment : UIButton
@property (nonatomic) NSInteger align;
@end

――――――――
UIButtonWithLabelAlignment.m
――――――――

#import "UIButtonWithLabelAlignment.h"

#define OBSERVE_FRAME @"titleLabel.frame"

@interface UIButtonWithLabelAlignment()
{
  BOOL setKVO;
}
@end


@implementation UIButtonWithLabelAlignment

-(instancetype)initWithFrame:(CGRect)frame
{
  self=[super initWithFrame:frame];
  if (self) {
     [self addObserver:self forKeyPath:OBSERVE_FRAME options:
NSKeyValueObservingOptionNew context:NULL];
     setKVO=YES;
  }
  return self;
}

// KVOによる変更通知受信
-(void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void *)context
{
  // 1つしか登録してないのでkeyPathのチェックは省略
   // 即解除;そうしないと以下でframeを操作するとまた発生してしまうから
  [self removeObserver:self forKeyPath:OBSERVE_FRAME];
  setKVO=NO;
   // 寄せる
  UIButton *btn=(UIButton *)object;
  CGRect frame=btn.titleLabel.frame;
  if (self.align&kUIButtonWithLabelAlignment_left) {
     frame.origin.x=0;
  }
  if (self.align&kUIButtonWithLabelAlignment_up) {
     frame.origin.y=0;
  }
  btn.titleLabel.frame=frame;
}

-(void)dealloc
{
  if (setKVO) {
   // 外れてないのが残ってたら外す
   self.titleLabel.frame=CGRectZero; // 上の通知でKVOを解除する
  // これでは解除処理が終了するまでにdeallocが終了してしまうためエラーが発生する
  // [self removeObserver:self forKeyPath:OBSERVE_FRAME];
  }
}


ついでに書いておくと、[UIButton sizeToFit]するとボタン幅が表示幅に合わされるので中央寄せ=左寄せで問題ないが、.textLabelにtruncateを設定していると、その表示幅はボタンの幅より必ず狭くなるのでセンタリングが起こる。これはtruncateが発生するラベルと発生しないラベルを並べた場合には、表示位置がずれて見えるということを意味する。なお、truncateが発生したボタンにsizeToFitをかけるとtruncateが外れてしまう(全体が表示できる幅のボタンになる)のでやってはいけない。

2014年9月14日日曜日

iOS7でのdrawAtPoint/drawInRectについて

iOS6までに存在したNSStringの
 - (CGSize)drawAtPoint:(CGPoint)point withFont:(UIFont *)font
 - (CGSize)drawInRect:(CGRect)rect withFont:(UIFont *)font
はiOS7で非推奨になった。

代替メソッドとしては
 - (void)drawAtPoint:(CGPoint)point withAttributes:(NSDictionary *)attrs
 - (void)drawInRect:(CGRect)rect withAttributes:(NSDictionary *)attrs
が紹介されているが、実はこれらには描画色に関して重大な違いがある。

代替メソッドについて書かれてるサイトはあったけど描画色について書かれているところは見つけられなかったのでここに書いておく。

iOS6の

 - (CGSize)drawAtPoint:(CGPoint)point withFont:(UIFont *)font
 - (CGSize)drawInRect:(CGRect)rect withFont:(UIFont *)font

は[UIColor set]で設定された現在の描画色で描画されるが、iOS7の

 - (void)drawAtPoint:(CGPoint)point withAttributes:(NSDictionary *)attrs
 - (void)drawInRect:(CGRect)rect withAttributes:(NSDictionary *)attrs

はそれでは描画されない。常に黒になる。

 ではどうやって描画色を指定するかといえば、attrsに入れる。すなわち、
    NSDictionary *atrb=@{
                         NSFontAttributeName : font,
                         NSForegroundColorAttributeName:color
                         };
    [self drawAtPoint:point withAttributes:atrb];
である。

本当なら[UIColor set]で設定された現在の描画色を得る方法があれば、それを読み取ってcolorに入れればいいが、その方法がないので、、描画色は他に変数に入れて管理しておく必要がある。

アップルはこういう重大な変更を平気でするから困る。変えるなら変えるでちゃんと告知して、正確な代替案を出してほしい。このことがわかるのに半日もかかってしまった。

X-BASIC for iOSの次バージョンは、この問題を超えて発表まであと少し。今回は機能追加なし。

2014年8月28日木曜日

iPadでsizeToFitを使う場合の注意

UILabelを使っている処理で、末尾の1文字が欠けるという現象が出た。
よくよく調べると、
・文字列中に半角文字が1文字だけある
・sizeToFitを使っている
・iPad(32/64bit共)のみである
であった。

更に調査した結果、興味深いことがわかった。
sizeToFitした結果のサイズを調べると、iPadのみ1ピクセル分少ないのだ。

 CGRect frame=label.frame;
 NSLog(@"元frame=%@",NSStringFromCGRect(frame));
 [label sizeToFit];
 frame=label.frame;
 NSLog(@"後frame=%@",NSStringFromCGRect(frame));

この後frameの.size.width値がiPhoneでの結果に比べiPadは1小さい値が返ってきている。

さらに、UILabelでは、文字表示必要幅に対して1ピクセル分でも足りないと、末尾1文字がまるごと欠けるしまうようである。

iOS7のバグ。iOS6以前ではどうかは不明。

なので、対策としては

if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
  // iPadのみ
  CGRect frame=label.frame;
  frame.size.width=frame.size.width+1; // +1ピクセル
  label.frame=frame;
}

とすればよい。

2014年1月15日水曜日

iOS7のUITextViewのバグ(その2)

iOS7のUITextViewには前にも書いたとおり、非常にたくさんのバグが存在するが、
またバグを発見してしまった。これは表に出てこないのでちょっとわかりにくいバグ。

 (1)入力状態にある間中、メモリ利用量が増加し続ける
64バイトずつメモリが確保され続けている。
だいたいではあるが13KB/分くらいの増加量。
調べると、libdispatch.dylibが_dispatch_continueation_alloc_from_heapを発行し続けているらしいが、
詳細は不明。

終了すると一括開放されるのでリークとはならない。



(2)メモリリークもある模様
しかし、別のところでメモリリークがある。内部で呼び出されていると思われる、NSUndoManagerというものが、メモリを開放しないで終了している。
1回あたりは少量だが、メモリリークが検出されること自体余り良い気分ではない。

なにはともあれ、iOS7のUITextViewはバグが多すぎて困る。一から作り直したりするからこういうことになるのだ。 従来版も残しながら新版をリリースし、以降を推奨しながら、バグが枯れた頃に旧版を廃止するのが普通ではないかと思うのだが、アップルには世間の常識は通用しないからなぁ。


おまけ
(3)UIDatePickerを回し続けると急激にメモリ利用量が増加する
ただし、止めて一定時間立つと開放される様子。
メモリ残り容量が少ない時にUIDatePickerを 動かすとメモリ不足で落ちたりするかもしれない。

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)にすることを勧める。ボタン系も枠を表示するよう設定できれば良いのに。)