MOSA Multi-OS Software Artists

「Wonderful Server Life」　　第83回　　田畑 英和

　　〜「iCalサーバ」編〜

　さて今回がiCalサービスの解説の最終回になります。今回はイベントに参加者を設定して他のユーザに通知を送る方法について解説します。ローカルカレンダー上に作成したイベントでも参加者を追加すれば、参加者宛に通知のメールを送信することができますが（ただし、事前にアドレスブックにメールアドレスの登録が必要）、カレンダーサーバ上のイベントの場合はiCal上で通知を
やり取りすることができます。

◇参加者の追加
　まず参加者の追加ですが、iCalサーバ上のカレンダーにイベントを追加し、参加者の欄にユーザを追加します。このとき参加者を直接入力することもできますが、「ウインドウ」メニューから「アドレスパネル」を表示しておくと、ドラッグ＆ドロップで参加者を登録することができます。ただしこのとき複数のユーザをまとめてドラッグ＆ドロップすることはできないので1人ずつユー
ザを追加する必要があります。このところはちょっと使いづらいので次のバージョンではぜひとも改善してもらいたいところです。

・イベントへの参加者の追加
http://www.htabata.com/img/MXS105/iCal/iCal_attend01.png

　あらかじめ各参加者の予定を確認しておきたいときは、「空いている時間…」をクリックします。するとイベントを設定した日の各参加者の予定が分かります。ここでは具体的な予定の内容までは分かりませんが、とにかく予定が空いているかどうかは確認できます。各ユーザはiCalの環境設定の「アカウント」であらかじめ基本空き時間を設定しておくこともできます。デフォルトは平日8:00〜18:00と設定できるようになっており、カスタマイズすれば曜日ごとに基本空き時間を設定することもできます。
　空き時間は、イベントを選択して「ウインドウ」メニューから「空き時間状況パネル」を選択することでも確認できます。

・空き時間状況の確認
http://www.htabata.com/img/MXS105/iCal/iCal_Availability.png

　空き時間だけではなく他のユーザの具体的なスケジュールを参照したい場合にはあらかじめ相手のユーザから委任の設定をしてもらう必要があります。この方法は前々回に既に解説済みです。委任が許可されたユーザのカレンダーは「ウインドウ」メニューから参照することもできます。また参照可能なカレンダーはユーザのカレンダーだけではなく、前回紹介した「ディレクトリ」で設定した場所やリソースも、委任の設定がされていれば参照することができます。例えばリソースに対して備品の管理者を委任しておけば、管理者は備品の予約状況をカレンダー上で参照することができます。

◇通知の送信と確認
　イベントを作成し参加者を追加すれば、あとは「送信」ボタンをクリックすることによりすべての参加者に通知を送信できます。それぞれの参加者はiCal上で通知を受け取ることができます。現バージョンでは通知はプッシュされませんので、最新の通知を確認するには「カレンダー」メニューの「更新」を選択します。またiCal起動時には自動的に通知の確認が行われます。
　通知を受け取った参加者は仮承認／欠席／参加のいずれかから回答を選択することができます。欠席と回答した場合には主催者に通知が送信されますが、参加と回答した場合には通知は送信されません。参加または仮承認と回答した場合には参加者のカレンダーにもイベントが自動登録されます。自分の状況は後から変更することもできます。

・通知の確認
http://www.htabata.com/img/MXS105/iCal/iCal_attend02.png

　主催者は自分のカレンダーイベントを確認することで各参加者の参加状況を確認できます。また、イベントを削除したような場合にはキャンセルの通知が参加者に送信されるようになっています。イベントの日時が変更された場合も参加者に再度通知が送信され、あらためて参加の有無を確認できるようになっています。

・参加状況の確認
http://www.htabata.com/img/MXS105/iCal/iCal_attend03.png

◇iCalサーバのデータ
　さて以上がiCalサービスの解説になります。最後にサーバ上でどこにiCalのデータが保存されているかを紹介しておきましょう。データの保存場所は次のパスになります。

・iCalデータの保存場所
   「/Library/CalendarServer/Documents」

　このディレクトリはオーナーが「_calendar」となっており、root権限がないと中身を参照することができません。このディレクトリには各ユーザのスケジュール情報が保存されますので取り扱いには注意が必要です。またiCalサービスの設定ファイルですがこちらは次のパスに保存されています。

・iCalデータの設定ファイル
   「/etc/caldavd」

　来年リリースが予定されているSnow Leopardですが、これにはiCal Server2が搭載されることになっており、グループカレンダーや通知のプッシュ、非iCalサーバユーザへのメールでの通知、Webブラウザからのカレンダーの参照などが新機能として予定されています。
次回へつづく　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

小池邦人のCarbon視点でiPhone探求（2008/12/12）

 〜　テンプレートを選ぶことから　〜

今回から、XcodeとInterface Builderを利用したiPhoneアプリケーションの開発に取り組んでいきたいと思います。まずは、Xcodeで用意されているiPhoneアプリケーション用のテンプレート（雛形）プロジェクトを調べてみることにします。

iPhoneアプリケーションでは、ユーザの作業対象（表示の状態など）を変更する場合に、ウィンドウを切り替えるようなことはしません。代わりに「UIViewのみ」（Mac OS XであればNSView）もしくは「UIViewControllerとUIViewのペア」を切り替えて対応することになります。つまり、iPhoneではスクリーン上に表示されているウィンドウは常にひとつだけとなります（複数用意してもかまわないのですが…）。そういう意味では、Mac OS X用アプリケーションと
は若干様子が異なります。

このようなiPhone独特の仕組みを念頭に置き、Xcodeが用意しているテンプレートの種類を確認してみます。Xcodeをアプリケーションから起動し、ファイルメニューから「新規プロジェクト…」を選択すると、テンプレートを選択するためのダイアログが表示されます。まず最初に、左側の対象OSとソフト種類から、iPhone OS直下の「Application」を選んでおきます。すると、右側に選択可能なテンプレート用アイコンが並びます（下に表示される説明は残念ながら英文のまま）。若干意味不明のアイコンもありますが（笑）こうしたテンプレートは、目的別に全部で6種類用意されています。

・Window-Based Application

「Window-Based Application」は、nibファイル（MainWindow.xib）に登録されているUIWindow（UIViewのサブクラス）に対して描画を実行するアプリケーションを作成します。UIWindow上にビューやコントロールを配置したり、そこへQuartz 2D APIでダイレクトに2D描画を実行することで、アプリケーション機能を実現します。Mac OS Xで例えると、モニターのスクリーン上に必要なGUIを設置して、すべての処理を完結させてしまうタイプのアプリケーション
だと考えれば良いでしょう（例えばFront Rowなど）。このテンプレートが提供しているのが、一番簡単なiPhoneアプリケーションの構造です。

・OpenGL ES Application

「OpenGL ES Application」は、UIWindow（UIViewのサブクラス）上にひとつだけUIViewを配置し、それをEAGLViewクラスと定義してから、その内容をソースコードで実装します。そしてUIViewの幾つかのメソッドをオーバライドすることで、EAGLView上にOpenGL APIによる3D描画ができる環境を形成します。Mac OS XのCocoaならば、スクリーンと同サイズのウィンドウをオープンし、その上にNSOpenGLViewを配置した状況だと考えてください。またCarbonであれ
ば、スクリーン自体をOpenGL描画環境で「キャプチャ」した状態と同じです。これは、一般的な3Dゲームを開発するのに向いているテンプレートです（ところで何故アイコンは碁盤なのでしょうか？）。

・View-Based Application

「View-Based Application」では、 nibファイル（MainWindow.xib）にUIWindowとUIViewControllerが用意されています。そして、このUIViewControllerのサブクラスをソースコードを記述し実装します。また、UIViewControllerで使われるUIViewは別のnibファイルとして保存されており、アプリケーション起動時に、このUIViewがスクリーン全体に表示されます。前のふたつのテンプレートでは、UIWindowは単にUIViewを置く場所でしたが、UIViewControllerの方は、Cocoaのウィンドウと似た機能をアプリケーションに提供します。Mac OS X的に言えば、ダイアログやウィンドウをひとつだけオープンし、それですべての処理を完結させるタイプのアプリケーションを開発する時に使うと考えてください。そういう意味では、このテンプレートは「ViewController-Based Application」と呼んだ方が良いかもしれません。

・Utility Application

「Utility Application」では「View-Based Application」と同じように、nibファイル（MainWindow.xib）にUIWindowとUIViewController（RootViewController）を用意します。しかしView-Based Applicationの時とは異なり、RootViewController経由で操作するのは、MainViewControllerとFlipsideViewControllerの2つのUIViewControllerです。このふたつのクラスはソースコードで実装されます。それぞれのUIViewControllerに配置される
UIViewの方は、MainView.xibとFlipsideView.xibという二つのnibファイルに保存されています。このテンプレートでは、用意した2つのUIViewControllerをCore Animationの機能を使い切り替えることが可能で、ダッシュボードの「Widget」をiPhone内に実現した感じとなります。 Mac OS X的に言えば、あるウィンドウから別ダイアログを表示して処理を続けるタイプのアプリケーションです。

・Navigation-Based Application

「Navigation-Based Application」は、nibファイル（MainWindow.xib）にUIWindowとUINavigationControllerを用意します。UINavigationControllerはUIViewControllerを継承しており、複数のUIViewControllerを管理し、その表示を切り替える機能を利用できます。ここでは、管理対象としてUIViewController（RootViewController）がひとつだけ用意されていますが、テンプレートを拡張して複数のUIViewControllerを追加することが可能です。ちなみに、RootViewControllerクラス自体はソースコードで実装されています。RootViewControllerで利用されるUIView（UITableView）は、別のnibファイルであるRootViewController.xibに用意されています。Mac OS X的に言えば、目的に応じて階層化された複数のウィンドウを切り替えることで作業を進めるタイプのアプリケーションだと考えれば良いでしょう。

・Tab Bar Application

「Tab BarApplication」では、nibファイル（MainWindow.xib）にUIWindowとUITabBarControllerが用意されています。このUITabBarControllerのタブ数は2に設定されています。ひとつ目のタブをタップして表示される内容は、FirstViewControllerクラスとしてソースコードで実装されていますが、ふたつ目のタブのタップで表示される内容は、nibファイルのSecondView.xibに登録されているUIViewです。ユーザがタップ可能なタブの数を増やせば、さらに多くのUIViewControllerやUINavigationControllerを管理することが可能です。機能的にはウィンドウ上に配置したタブコントロールに似ているのですが、Mac OS X的に言えば、多数のウィンドウを切り替えて作業を行う大規模なアプリケーション向けのテンプレートです。

上記のアイコンのうちのひとつを選んで下の「選択…」ボタンを押してからプロジェクト名を入力すると、保存先に必要なファイル（Objective-Cソースファイルやnibファイルなど）をすべてまとめたプロジェクト用フォルダが作成されます。この時のプロジェクト名にはなるべく日本語を使わないでください（使おうと思えば使えますが…）。出来る限り開発アプリケーションの「名称」そのものにしておくと、後で煩わしい変更作業が必要なくなります。

開発の第一歩は、自作アプリケーションの機能や構成に向いたテンプレートを選択することです。よって、Xcodeがどんなテンプレートを「はき出す」のかを熟知していることは大変重要です。例えば「App Store」で販売されているiPhoneアプリケーションが、どのテンプレートから開発されているのかを推測するのも勉強になります。現状では、ゲームやパズルが多いので、ほとんどは
「Window-Based Application」や「OpenGL ES Application」のような気がしますが（笑）。

さて、iPhone用の「しんぶんし」の開発には、どのテンプレートを使いましょうか？　とりあえず「Navigation-Based Application」が向いているような気もしますが、その結論は宿題として次回まで取っておくことにしましょう。

ターミナルの向こうから　　　　　　第38回　　海上 忍

〜 いま敢えて学ぶTerminalのイロハ（5） 〜

・「パス」を理解するための予備知識
　コマンドを入力してENTERキーを押すとコマンドの機能が実行される — 当たり前のように使っている機能ですが、これにはいくつかの約束事があります。
　まず、コマンドを実行するという処理が、シェルによって実現されていることを認識しなければなりません。シェル（初期設定では「bash」）がENTERキーを合図に、現在入力を受け付けている行をコマンドラインとして解析し、コマンドと判断された部分 — 通常は行頭 — を探して実行する、という意味です。
　シェルがコマンドとして認識した文字列は、特定のディレクトリを対象に同名の実行形式ファイルが検索されます。この検索対象のディレクトリは、すなわちコマンドの保存場所であり、Leopardの初期設定では/binと/sbin、/usr/binと/usr/sbin、/usr/local/binと/usr/X11/binが設定されています。言い換えれば、これらのディレクトリに保存されている実行形式ファイルが、シェルがコマンドとして認識しているプログラムです。

・「パスが通っている」の意味
　では、他のディレクトリにコマンドは保存できないか？　というと、そうではありません。前述したディレクトリは、環境変数「PATH」で定義され、それをシェルが参照しているに過ぎません。PATH環境変数を再定義することにより、シェルが認識可能なディレクトリであればコマンド置き場として利用することが可能です。
　前置きが長くなりましたが、このPATH環境変数こそが「パス」であり、コマンドが保存されたディレクトリがPATH環境変数に登録された状態を「パスが通っている」といいます。「パス」はコマンドサーチパスともいいますが、単に「パス」と呼ぶほうが一般的です。ちなみに、PATH環境変数を定義／再定義してコマンドの保存場所をシェルに知らせる処理は、「パスを通す」といいます。

・シェルも工夫しています
　先ほど「コマンドを検索している」と書きましたが、これには少々語弊があります。実際には、シェルはコマンド名と保存場所の対応表（ハッシュテーブル）を作成し、コマンド実行時における処理の高速化を図っています。
　bashには、常にハッシュテーブルを最新の状態に保つ機構が装備されています。PATH環境変数が定義／再定義されたとき、コマンドを追加するなどパスの通ったディレクトリの内容が変更されたときには、ハッシュテーブルも自動的に更新されるため、その存在を意識する必要はありません。
　なお、bash以外のシェルは多少事情が異なります。たとえば、以前Mac OS Xで標準のシェルに採用されていた「tcsh」は、コマンドを追加したあとは内部コマンドの「rehash」を実行し、ハッシュテーブルを明示的に更新する必要があります。

・パスを通そう
　Leopardでは、bashが起動されるとシステムワイドなbashの起動スクリプト（/etc/profile）を実行します。内容を参照すればわかりますが、そこでは/usr/libexecディレクトリにあるpath_helperというシェルスクリプトを呼び出し、PATH環境変数の定義を行っています。
　この設定を変更する場合には、PATH環境変数の再定義を行います。たとえば、/sw/binディレクトリにパスを通す場合は、以下の要領でexportコマンド（環境変数を定義するためのbashの内部コマンド）を実行します。コマンドラインの意味ですが、操作時点のPATH環境変数（＄PATH）に/sw/binを加えたものをPATH環境変数として定義する、となります。

- - - - -
$ export PATH=$PATH:/sw/bin
- - - - -

　このとき注意しなければならないのは、PATH環境変数に列挙した順序のとおりコマンドが検索される、ということです。たとえば、上のコマンドラインを実行したとき、初期設定でパスが通っている/usr/binディレクトリと、後からパスを通した/sw/binディレクトリに同じコマンドが存在する場合、/usr/binのほうが優先されます。反対に、後から追加するディレクトリを最優先にパス
を通したい場合には、以下の要領でexportコマンドを実行します。

- - - - -
$ export PATH=/sw/bin:$PATH
- - - - -

　この設定を常に利用したい場合は、ユーザ別に用意するシェルの起動スクリプトにコマンドラインを書き加えます。bashの場合、ホームディレクトリの「.bash_profile」に書き加えるのが適当でしょう。次回は、この起動スクリプトについて説明したいと思います。

◇MOSAからのお知らせと編集後記は割愛します◇