iPhone アプリ研究会

ご無沙汰しております。
Tasakiです。

恐ろしい程の猛暑も過ぎ去り、一気に秋がやって来たという感じですね。
来週にはAppleの発表会も迫っており、季節の変化をさらに感じさせます。

さて、今回は表題の通り、web版のGoogleMapsを使う際のお話です。
テーマ的にはニッチであまり参考にならないのではと思うのですが、自分がweb上で探しきれなかったので取り上げてみることにします。

Tasakiです。


隣国から無視できない量の粒子状物質が飛来する今日この頃、いかがお過ごしでしょうか。
そろそろ花粉も飛散する頃合いとなり、そのうちノーマルスーツが必要になるんじゃないかという気もしてきます。

さて、今回のテーマはUIに関するものです。
文中のURLを選択すると、そのままブラウザに飛んでほしい。
こういう要求は、多々あると思います。
そんなときは、

はい、どうもUTOです。
ブログ当番を一週間すっぽかしていたようですが、なんのことやら

さて、先月iOS6が正式にリリースされ、
私達アプリ開発の人間視点ではだいぶﾋｰﾋｰいっております。

なぜならば、iOS5からiOS6にかけてUIな部分で対応が余技なくされるからです。

みなさん、こんばんは
hayateです

Mobile Safariを知る
第一回目の今日は、その画面領域に迫りたいと思います。

我々の生活の一部と言っても過言ではないMobile Safari。
PC用ブラウザの延長として使うだけでは見えてこない様々な仕様があります。
その中でも今日は、Webコンテンツ制作者には欠かせないその画面領域について
皆さんと学んでいきたいと思います。

さて、Mobile Safariと一言で言ってもその実態は大きく２種類に分類されます。
・iPhone、iPod touchに搭載されているのもの（320pt×480ptベース）
・iPadに搭載されているもの（1024pt×768ptベース）
この２種類です。

まずはiPhoneのMobile Safariの画面領域からみていきましょう。
以下のとおりです。

※以下、サイズの単位はポイントです。
ピクセル換算するとRetinaディスプレイでは２倍となります。





■iPhone UIサイズ

向き	Portrait	Landscape
ステータスバー	20	20
ステータスバー(電話中)	40	40
アドレスバー	60	60
ツールバー	44	32

そして、コンテンツ領域は以下のとおりです。

■iPhone コンテンツ領域

向き	Portrait	Landscape
アドレスバー表示時	320 x 356	480 x 208
アドレスバー非表示時	320 x 416	480 x 268

次に、iPadのUIサイズとコンテンツ領域ですが
iPad版のMobile SafariはiOS4.3からiOS5へのバージョンアップ時にUI構成が変化しました。
タブバーの追加です。これによりコンテンツ領域のサイズが変わっています。

先日行われたWWDCやインターネット上の情報では、iOS4系の使用者はまだ約20％ほど存在するようですので、今回はiOS5.x系とiOS4.3を対象としましょう。（※2012年6月現在）




iPad UIサイズ

	iOS 5	iOS 4.3
ステータスバー	20	20
ツールバー	44	58
ブックマークバー	28	30
タブバー	32	-

iPad コンテンツ領域

	iOS 5		iOS 4.3
向き	Landscape	Portrait	Landscape	Portrait
ブックマークバー 非表示時	1024 x 672	768 x 928	1024 x 690	768 x 946
ブックマークバー 表示時	1024 x 644	768 x 900	1024 x 660	768 x 916

こうして見てみると、意外とコントロール部分が大きな割合を占めていること、
そして、ユーザの使い方によってコンテンツ領域が変化することがわかります。

このため、Webアプリをネイティブアプリ風に制作する場合、高さの変化に対応できるように
レイアウトを考慮する必要があります。

こうした問題の解決策としてAppleはスタンドアロンモードと呼ばれるものを用意しています。
これについては次回とりあげたいと思います。

さて、いかがでしたでしょうか。
「Mobile Safariを知る」
第一回目の今日は、その画面領域についてお送りいたしました。
次回は、スタンドアロンモードについて学んでいきます。

それではまた。

お久しぶりの投稿です。江原です。

入社させていただいて半年
日々すばらしい経験をさせていただいて本当に感謝しています！

一日も早くもっと戦力になれればと
頑張って行きたいと思います。

今日はUIViewとタップイベントについて調べてみたいと思います。

まず。。。
透明（又は半透明）のUIViewの後ろに
ボタンを配置して押下させたいとき

↑う～んやはり、UIButtonは押せません。
手前のUIViewがイベントを処理した為です。

そこでUIViewのuserInteractionEnabledをNOにして
タップイベントを無視すると
背景のUIButtonにイベントを透過する事が出来ます。


でもこの方法ですと
透過した手前のUIViewにUIButtonを配置した場合に


↑UIView上のボタンがタップできません。。


親のViewがuserInteractionEnabled=NOだと
その上に配置されるview(subView)は押下イベントが発生しないようです。


そこでuserInteractionEnabledをYESにて
subviewのイベントを発生させつつ
自身のUIViewのイベントのみを透過させる方法を調べました。

// HitTestView.h
// UIViewを継承して自身のみ透過させ
// サブビューのイベントは破棄しないViewを作る
#import <UIKit/UIKit.h>
    @interface HitTestView : UIView
@end

// HitTestView.m
#import "HitTestView.h"
@implementation HitTestView
- (id)initWithFrame:(CGRect)frame
{
self = [super initWithFrame:frame];
if (self) {
}
return self;
}
- (UIView*)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{
// 現在イベントが発生しているViewを取得
UIView *nowHitView = [super hitTest:point withEvent:event];

// 自分自身(UIView）だったら透過して(nilを返すとイベントを取得しなくなる)
if ( self == nowHitView )
{
return nil;
}

// それ意外だったらイベント発生させる
return nowHitView;
}
@end

こんな感じでUIViewのhitTestをオーバライドすれば
背景と自身の上に存在するUIButtonが押下できるみたいですね。