So-net無料ブログ作成

iCalendarについて [iCalendar]

地震ですが、私の被害は軽微でほぼ無い様な状況でしたが、原発の問題を含めてどうも手がつかずと言うことで更新が滞ってしまいました。まあ、このブログを更新することに意味があるのかどうかもよくわからないんですが、戻せるところはなるべく日常に戻していきましょうと言うことで、更新を再開することにします。

*

さて、SDツールですが、Mac上で動作を試したい気になってきました。これについて、ソースの受け渡し(とか保存)の方法をちょっと変えようかと思っていて、その準備ができるまでまた違うことをしようと思います。ほったらかし中は「手書きメモ」「バックアップツール」「Androidアプリ開発」「SDツール」となっております。よそ事をするたびに、列挙しときましょう。

と言う感じで、ちんたら中途半端に続けていますが、実は自前のスケジュール管理のアプリが欲しいなぁとずっと思ってたりします。Zaurusを使ってた時には作りかけてました。で、今Androidでも作りたいなぁと思っているんですが、悩むのデータの内容です。PDAが出たての頃はアプリによって、いろいろと項目も異なっていてどうしても独自になりがちでした。今でも状況は同じ様なものなのかもしれませんが、最近はiCalendarと言う仕様への対応も進んできていてある程度統一方向なのかなとも思ったりします。と言うことで、開発はともかくiCalendarの仕様を把握しときたいと思います。

*

そのiCalendarですが、以前はRFC2445が該当の仕様だった様です。現在は、2009年に作成されたRFC5545で置き換えられている様ですね。確認してみると全168ページ。全て読むのは大変そうです・・。気になるところをつまみ読みして行きましょう。まずは、目次でどんな項目があるのかとざ~っと読んで気になった点を確認しておきます。

1 Introduction
 導入部ですが、メモとしては下記の様な感じでしょうか。
 ・スケジュール関連のプロトコル(?)はiTIP(RFC5446)に定義されている。
 ・定義はABNF(RFC5234)で記述
2Basic Grammar and Conventions
 いろんな定義をするための決まりごとみたいな感じでしょうか。
 ・「MUST」とかの表記はRFC2119を参照とのこと
 ・定義はABNF(RFC5234)で記述
 ・数値は十進数で表記
 ・propertyの名前、パラメータ名、列挙子、パラメータ値は大文字、小文字の区別なし
 ・propertyの値は特に記載が無い限り、大文字、小文字の区別あり
 ・iCalendarのオブジェクトのメディアタイプ(RFC2425)は「text/directory」
2.1Formatting Conventions
2.2Related Memos
3iCalendar Object Specification
 iCalendarの個々のオブジェクト(Core Object)の定義ですかね。
 ・iCalendarのオブジェクトは、「calendar property」と1つ以上の「calendar compnent」の羅列からなる
 ・本章の情報はMIME content type registrationの付属部分・・・(?)
3.1Content Lines
3.2Property Parameters
3.3Property Value Data Types
3.4iCalendar Object
3.5Property
3.6Calendar Components
3.7Calendar Properties
3.8Component Properties
4iCalendar Object Examples
表題の通り、例ですね。
 ・一つのデータの場合、「text/calendar」と言うContent Typeで送信されることもある様子
 ・「busy time information」と言うデータが拡張子「.ifb」で保存されている
5Recommended Practices
iCalendarオブジェクトに関する奨励事項の様です。ポータビリティを持たせるための注意事項と言う感じですかね・・?
 1. 75オクテット以上の「Content line」は「fold」すること
 2. 完了日時のみが記載されている繰り返しか期間データについて書かれている気がしますが、今、理解できません・・・。
 3. 複数のメーリングリストで同じイベントについての連絡が来ても、一つに対してのみ応答すべき
 4. "SUMMARY"プロパティは255オクテットで切り詰めてもいいが、UTF-8のコードの途中で切ってはならない
 5. 「秒」をサポートしない場合は、値を"00"にすること
 6. "TZURL"と言う値(?)はURIとして使わないこと
 7. "CATEGORIES"プロパティに入れる値(?)の記載と、それらに対する複数言語のサポートについて
 8. "RESOURCES"プロパティに入れる値(?)の記載と、それらに対する複数言語のサポートについて
6Internationalization Considerations
iCalenderのストリームはUTF-8 charsetで生成すること(MUST)。受信時はUTF-8、もしくはUS-ASCII charsetを受け入れること(MUST)。
7Security Considerations
スケジュールデータはプライバシー情報なので、セキュリティには気をつけろとか。ただし、本仕様はその辺とは独立していて、議論はプロトコルの仕様iTIP(RFC5546)、iMIP(RFC6047)、CalDAV(RFC4791)でされるとか。
8IANA Considerations
IANAに登録した内容とかが書かれている様子。プロパティやパラメータの名前なども定義されている様子で、後で必ずチェックした方が良さげ。
8.1iCalendar Media Type Registration
8.2New iCalendar Elements Registration
8.3Initial iCalendar Elements Registries
9Acknowledgments
謝辞ですかね。
10References
参照資料についてです。
ADifferences from RFC 2445
RFC2445との差分が書かれている様ですが、私はそもそもそっちを見てないので、不要ですかね・・。互換性とかを考える必要が出てきたら見なければならないかも・・。


とりあえず、ここまでで見たところ、中身の詳細は3章の様ですね。後は大枠と言う感じなんですかねぇ・・。取りあえず、2章、3章あたりを拾い読みしてみましょうかねぇ・・。


つづく。





クラス構成の変更 [SD Tool]

前回、クラス構成に変更が必要かもと書きましたが、気にしていたのは、SDのフォルダのドロップの処理。ドロップされた時に独自の処理が必要になると思うのですが、signalでそんなのが出てくるのかなと確認したところ、出て来ないようです。

ドロップの処理としては、QWidget::dropEvent()に書く様な感じがします。と言うことで、QTextEditを直接使うのではなく、派生したクラスを作成し、そこに処理を追加することにします。と言うことで、クラス図はこんな感じ。

11030800.png
結局派生


で、当初はSdToolMainから直接QTextEditを操作する様な感じで考えていましたが、そう言うのはやめて、SdToolMainからはsignalを出すだけにすることにしました。それを受けて処理するのはMainWindowClassと言う感じの想定です。

これに伴って、Qt Creator上の修正もしときます。以前やった通りに修正して、オブジェクト名もsdtoolViewに変更。新規作成したクラスのコンストラクタもQTextEditに合わせる様に修正。で、実行。

11030801.png
見た目は何も変わりませんが・・


これで、一応、土台まで修正が完了しました。


つづく。







起動シーケンスとSdToolMainの仕様検討 [SD Tool]

前回の続きで、起動シーケンスを考えます。3つのクラス間でこんな感じのシーケンスになりますかね。

11030100.png
大雑把ですが・・


SdToolMainの「起動時チェック」は以前考えた、起動時のファイル待ちまでのシーケンスを実行して、SDの状態を保持することにします。SDの状態は、SdToolMainの中で、いくつかのデータを保持することにします。

QString sd_statusSDの状態。マウントされてる、されてない、FOMAのものかなどを文字列で表しましょう。
QString sd_pathSDのルートまでのフルパス。
QList<SdFolderInfo> folder_listフォルダ情報のリスト。「SdFolderInfo」の内容は別途定義。


sd_statusに格納されるSDの状態は下記の通りとしときます。

const QStringSD_STATUS_UNAVAILABLE"unavailable"。マウントされていないなど、使えない状態
const QStringSD_STATUS_NOTSUPPORT"not support"。利用できるが、サポート外の用途で利用されている状態
const QStringSD_STATUS_FOMA_SH"foma-sh"。FOMAのシャープ端末と判断した状態


SdFolderInfoは下記の通りの構造体とします。

struct SdFolderInfo
QString nameフォルダ名
QString pathSDカードのルートからのパス。


そして、SDカード状態の取得要求に対する関数が必要ですね。

getSdStatus()
引数なし
戻り値QString状態を示す文字列
処理 sd_statusの内容を返す。


とりあえずはこんな感じですかねぇ・・。

書きながら考えてたんですが、先日考えたクラス構成は、ちょっと修正が必要かもしれませんね。ドロップの処理のためにQTextから派生して何か独自クラスを作る必要があるかもしれません・・・。とふと思いました。今回の内容とは全然関係ありませんが・・。


つづく。




ioPLAZA【ロックチューブ】
ブログを作る(無料) powered by So-netブログ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。

×

この広告は1年以上新しい記事の更新がないブログに表示されております。