携帯電話各機種におけるiアプリ実行環境の実装は、各メーカーにより行われており、その動作は細部で異なることがあります。ここでは各機種におけるコンテンツ作成上の注意点について解説します。

資料名 概要
(PDFファイルが開きます)N901iC/iS iアプリ作成に関する注意事項
(PDF形式:84.0KB)
1.0 N901iCおよびN901iS 対応のiアプリを開発する上での注意点について解説しています。
(PDFファイルが開きます)P901i(S) iアプリ作成に関する注意事項
(PDF形式:139KB)
1.0 P901iおよびP901iS 対応のiアプリを開発する上での注意点について解説しています。
(PDFファイルが開きます)SH901iC/iSアプリ作成に関する注意事項
(PDF形式:110KB)
1.0 SH901iCおよびiS対応のiアプリを開発する上での注意点について解説しています。
(PDFファイルが開きます)D901i (S)アプリ作成に関する注意事項
(PDF形式:94.0KB)
1.0 D901iおよびD901iS対応のiアプリを開発する上での注意点について解説しています。
資料名 概要
(PDFファイルが開きます)N900i(S) iアプリ作成に関する注意事項
(PDF形式:112KB)
1.0 N900iおよびN900iS 対応のiアプリを開発する上での注意点について解説しています。
(PDFファイルが開きます)P900i(V) iアプリ作成に関する注意事項
(PDF形式:95.7KB)
1.0 P900iおよびP900iV 対応のiアプリを開発する上での注意点について解説しています。
(PDFファイルが開きます)SH900i iアプリ作成に関する注意事項
(PDF形式:70.2KB)
1.0 SH900i対応のiアプリを開発する上での注意点について解説しています。
(PDFファイルが開きます)D900i iアプリ作成に関する注意事項
(PDF形式:75.0KB)
1.0 D900i対応のiアプリを開発する上での注意点について解説しています。

iアプリで取得されるシステム時刻についての注意点

事象

D2101Vでは、iアプリにおけるシステム時刻取得処理においてサマータイム処理が有効となっており、1年のうち一定の期間についてiアプリから取得したシステム時刻が実際の時刻より1時間進みます。

サマータイム期間と見なされる期間は以下の通りです。

サマータイム開始

3月最終日曜の午前10:00に11:00へ切替えます。これ以降に起動されたiアプリでは、システム時刻が実際の時刻より1時間進むようになります。

実際の時刻 D2101V
内蔵時計
D2101V
Calendarクラス
9:00 9:00 9:00
9:30 9:30 9:30
9:59 9:59 9:59
10:00 10:00 11:00注意1
10:30 10:30 11:30

注意1 以降サマータイム開始まで正常な時刻

サマータイム終了

10月最終日曜の11:00に10:00へ切替えます。これ以降に起動されたiアプリでは、システム時刻は実際の時刻と一致します。

実際の時刻 D2101V
内蔵時計
D2101V
Calendarクラス
9:00 9:00 10:00
9:30 9:30 10:30
9:59 9:59 10:59
10:00 10:00 10:00注意1
10:30 10:30 10:30

注意1 以降サマータイム開始まで正常な時刻

サマータイム期間か否かの判断はiアプリ起動時に1回だけ行われます。従って、iアプリ実行中にサマータイム開始・終了切り替えのタイミングをまたいだとしても、iアプリ起動時の判断が有効のまま存続します。

アプリケーション作成時の指針

D2101V向けに時計アプリケーションなどシステム時刻を取得するアプリケーションを開発される場合には、D2101Vにおけるサマータイム期間中はシステム時刻から1時間遅らせた時刻を実際の時刻として使用するようにしてください。

通信を行うiアプリでは、iアプリ開発者は通信エラーや通信の結果得られたデータのエラーをリカバリーするために通信処理のリトライを行う処理を組み込むことがあります。通信に関するエラーをiアプリが検出して自動的にリトライを行うことは、通信品質(電波状況)が頻繁に変化する携帯電話上でiアプリを快適に使用できるようにする観点で有用な手段です。しかしiアプリが無限に通信のリトライを行わないよう、そのような処理を組み込む場合は必ず繰り返し回数に上限を設けるようにしてください。

iモードサービスではパケット課金システムが採用されており、通信料金は実際に行われた通信量に比例して課金されます。1回の通信サイズが小さくても、上限なく通信のリトライが行われると短時間のうちに非常に高額の課金が行われる可能性があります。

通信処理、または通信処理を含むアプリケーションロジックのリトライは多くても数回程度までとし、その回数で目的の処理を完遂することができなかった場合はダイアログ表示などによりユーザーにエラーを通知するような仕組みとすることを強く推奨します。
(待受アプリケーションの場合には、エラーを検出した際にiアプリを自動的に終了させるような仕組みとすることも推奨されません。待受アプリケーションはシステムにより自動的に再起動され、結果として同じ処理を繰り返してしまう可能性があるためです。)

Adobe Reader を入手する(別ウィンドウが開きます)

PDF形式のファイルをご覧いただくには、アドビシステムズ社から無償提供されている別ウィンドウ:Adobe® Reader® プラグインが必要です。「Adobe® Acrobat®」でご覧になる場合は、バージョン10以降をご利用ください。

このページのトップへ