NSURLRequest ~ NSURLConnectionのひながた

HTTPでファイルを取得する方法を調べていたら、
少し混乱したので、整理もかねてひな形を保存しておく。

まずはひな形、基本これをコピーして、URLの入力の部分をゴニョゴニョすれば、
一連のDelegateが発火する……ハズ。


// アクション契機のURLリクエスト開始処理
- (IBAction)urlRequest:(id)sender {
NSString* urlStr = urlField.text;
if ( [urlStr length] <= 0 ) {
return;
}


NSURL* url = [NSURL URLWithString:urlStr];
NSURLRequest* request = [NSURLRequest requestWithURL:url];
[NSURLConnection connectionWithRequest:request delegate:self];
}




#pragma mark NSURLConnection delegate implementations
// Request送るよ。
- (NSURLRequest *)connection:(NSURLConnection *)connection willSendRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse *)response {
return request;
}


// 応答受信
- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response {
}


// データ受信
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data {
}


// キャッシュがするよ
- (NSCachedURLResponse *)connection:(NSURLConnection *)connection willCacheResponse:(NSCachedURLResponse *)cachedResponse {
return nil;
}


// 読み込み完了
- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
}


// エラー
- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error {
}


この実装の気に入らないところは、NSURLConnectionに対してDelegateを設定しているというのに、selfのクラス宣言で、プロトコルの実装宣言が要らないところだ。

要らないなら、手間が省けるじゃないかとう意見もあるが、少数の例外が存在するというのは、いろいろ疑う余地が増えてくるので、気持ちのいいものではない。

とわ言え、動くものは動く、とりあえずはソレでヨシとする。

UITableViewのひながた。

UITableViewは便利だ。
普通に使うぶんにはレイアウトはFrameWorkにお任せでOK。
こっちは内部の動きに専念できる。

だが、Delegateの実装が必須になる、これをいちいち覚えておくのは面倒クサイ。
なので、必要最低限のひな形を載せておく。
ただし、ヘッダー側にもそれ用の宣言が必要になる。

以下、ひな形

#pragma mark UITableViewDataSource Implementation
// tableのsection数
-(NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return 1;
}


// section中の行数
-(NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
return 1;
}


// Cell表示
-(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
return nil;
}


// sectionヘッダタイトル
-(NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section {
return nil;
}


#pragma mark UITableViewDelegate Implementation
// 行選択
-(void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
}

UnlockMe 1.1.0 アップデートしました。

だいたい1月前に公開を開始したiPhone/iPod touch向けゲーム
UnlockMeのバージョンアップ版が本日アップルの審査を通過、


UnlockMe 1.1.0の公開を開始しました。


アップデート箇所は下記。
・ダイヤルの動きをより鈍くして、ホンモノのダイヤルキーに近い、
渋い動きを再現しました。
・操作に伴う効果音を追加しました。
もちろん設定画面で効果音の無効も選択できます。

ではでは、ダウンロードはこちらから。

UITableViewCellのいろいろ

UITableViewを使おうと思うと、どうしても避けて通れないのが「UITableViewCell」
凝った事をしようと思うと、自分でゴリゴリとCellをデザインする必要が出てくる。

だが、まずはSDKで提供されている機能の中でどこまでできるか試してみる。
用意したコードは下記、Cellリサイクル方法が、これでいいのかはいささか不安だが、
そこは今回の検証範囲ではないので黙殺。

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 UITableViewCell* cell = nil;
 switch ( indexPath.row ) {
  case 0:
   cell = [tableView dequeueReusableCellWithIdentifier:@"Goal0"];
   if ( cell == nil ) {
    cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Goal0"];
   }
   cell.textLabel.text = @"StyleDefault";
   break;
  case 1:
   cell = [tableView dequeueReusableCellWithIdentifier:@"Goal1"];
   if ( cell == nil ) {
    cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:@"Goal1"];
   }
   cell.textLabel.text = @"StyleSubtitle";
   break;
  case 2:
   cell = [tableView dequeueReusableCellWithIdentifier:@"Goal2"];
   if ( cell == nil ) {
    cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleValue1 reuseIdentifier:@"Goal2"];
   }
   cell.textLabel.text = @"StyleValue1";
   break;
  case 3:
   cell = [tableView dequeueReusableCellWithIdentifier:@"Goal0"];
   if ( cell == nil ) {
    cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleValue2 reuseIdentifier:@"Goal3"];
   }
   cell.textLabel.text = @"StyleValue2";
   break;
  default:
   break;
 }
 cell.detailTextLabel.text = @"detailTextLabel";
 cell.accessoryType = UITableViewCellAccessoryDetailDisclosureButton;
 cell.imageView.image = [UIImage imageNamed:@"hoge.png"];
 return cell;
}

上記のコードは、Section:1 Row:4のUITableViewを想定したコード。

で、出てきたテーブルはこういうものである。

【補足】UserLocationには障るべからず

先日投稿した、MKMapViewのPinを削除するコードが、

ウマく動かない場合があるようなので補足。

for ( id<MKAnnotation> annotation in mapView.annotations ) {

  if ( [annotation isKindOfClass:[MKUserLocation class]] )continue;

  [mapView removeAnnotation:annotation];

}

先日投稿したコードは上記。

しかしこのコード、iOS4.3.1のiPod touchでは動いたのだが、

iOS4.1のiPhoneではExceptionが発生して動作しなかった。

いわれてみれば、このコードには致命的な欠陥がある。

mapView上のannotationリストでループを回しながら、当のannotationを削除してゆこうという、しかも、順番はframeworkにお任せと………。

回し方によっては、これ以上にないくらい致命傷だ。

どうやら、この辺のロジックが最新のframeworkではお利口さんになっているらしく、問題が隠蔽されていたらしい。

何も考えずに書いていると、こういう地雷的なコードが出来上がってしまう事があるので、注意したい。

対応方法をかんがえないとなぁ〜