iPhoneのSDK3.0からカメラ用APIが色々追加されたと聞きました。
いくら探してもキャプチャを取れなくするAPIは公開されていません。
カメラ付きケータイが禁止されている会社もあるのに、なぜ非公開なのでしょうか。疑問です。
ソースコードなどを書くとまずそうなので、方法だけ載せます。
まず前提として、iPhoneはシングルタスクで稼動する。ということがあります。
そして、非公開APIを含めて実現できること。
カメラロールに入っている画像の撮影時間を取得すること。
カメラロールに入っている画像を削除すること。
ということはつまり、
1)アプリ起動時の起動時間を保持しておく。
2)アプリ終了時に(起動時間≦撮影時間)の画像を全て削除する。
とすれば、アプリ起動中にキャプチャした画像は亡き者になります。
※OSアップデートによって実装できなくなる可能性もあります。
ちなみにOS3.1.2ではこの方法がうまくいくことが確認できました。
2009年10月14日水曜日
xfireでSOAP
最近仕事でjavaのSOAP通信にxfireというライブラリを使い、どつぼにハマった。
ドキュメント類も一切ないので、これから使う人のためにメモ。
xfireとは:
次世代のSOAPフレームワーク。各種標準をサポートしており、扱いやすいAPIを通じてSOA開発のアプローチを実現する。
※このフレームワークというのがポイント!
使い方
①SOAPサーバ側にxfire設定ファイル(services.xml)を、WEBアプリの以下のパスに配置されるようにする。
WEBルート/classes/META-INF/xfire/services.xml
services.xml
②SOAPサーバ用xfireライブラリをクラスパスに入れる。
③web.xmlにxfire定義を追加する。
web.xml
④WEBアプリをデプロイ
注意点
①SOAPクライアントとしてxfireを使用するときは、SOAPサーバ側もxfireでなければならない。
②SOAP通信に用いるインタフェースは、クライアント側とサーバ側で同じパッケージにしなければならない。
ドキュメント類も一切ないので、これから使う人のためにメモ。
xfireとは:
次世代のSOAPフレームワーク。各種標準をサポートしており、扱いやすいAPIを通じてSOA開発のアプローチを実現する。
※このフレームワークというのがポイント!
使い方
①SOAPサーバ側にxfire設定ファイル(services.xml)を、WEBアプリの以下のパスに配置されるようにする。
WEBルート/classes/META-INF/xfire/services.xml
services.xml
<bean>
<service>
<name>WebServiceName</name>
<serviceclass>com.oboegaki.servers.TestService</serviceclass>
<implementationclass>com.oboegaki.servers.Test</implementationclass>
</service>
</bean>
②SOAPサーバ用xfireライブラリをクラスパスに入れる。
③web.xmlにxfire定義を追加する。
web.xml
<web-app>
<servlet>
<servlet-name>XFireServlet</servlet-name>
<display-name>XFire Servlet</display-name>
<servlet-class>
org.codehaus.xfire.transport.http.XFireConfigurableServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>XFireServlet</servlet-name>
<url-pattern>/servlet/XFireServlet/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>XFireServlet</servlet-name>
<url-pattern>/services/*</url-pattern>
</servlet>
④WEBアプリをデプロイ
注意点
①SOAPクライアントとしてxfireを使用するときは、SOAPサーバ側もxfireでなければならない。
②SOAP通信に用いるインタフェースは、クライアント側とサーバ側で同じパッケージにしなければならない。
2009年10月9日金曜日
2009年9月26日土曜日
iPhoneのAPNs
最近仕事でiPhoneを使った業務システムの開発を行った。
社内PCからiPhoneへ向けたメッセージを送信するのに、
apple社のAPNs(Apple Push Notification service)を使用したので、
覚えたことをメモ。
・APNs番号について
APNs番号とは、iPhoneのデバイスIDとアプリケーションのBundleIdentifierが紐付けられた、端末を一意に特定するための番号。半角英数で64文字。
APNs番号の作成タイミング:iPhoneアプリからappleAPNsサーバに初回アクセスに行ったとき、appleAPNsサーバで発行し、iPhoneアプリに戻してくる。
・プロビジョニングプロファイルとプロバイダ証明書について
プロビジョニングプロファイルは、開発用(Development)と商用(Production)が存在する。
それぞれ違いはあるが、注意すべきは、Productionが有効になっている場合、Developmentは無効になるということ。つまり、Production登録したあとは、iPhoneアプリに食わせるプロビジョニングプロファイルも、プロバイダサーバに置く証明書(pemファイル)も、Production版の証明書をキーチェーンからExportして使用しなければならない。
おそらく、APNsサーバ内で制御しているのだろう、APNsのテスト機(gateway.sandbox.push.apple.com)へアクセスしても、反応してくれなくなる。
参考:
iPhoneアプリで稼げるのか:PushNotificationの実装方法
Push Notification 用フレームワーク
社内PCからiPhoneへ向けたメッセージを送信するのに、
apple社のAPNs(Apple Push Notification service)を使用したので、
覚えたことをメモ。
・APNs番号について
APNs番号とは、iPhoneのデバイスIDとアプリケーションのBundleIdentifierが紐付けられた、端末を一意に特定するための番号。半角英数で64文字。
APNs番号の作成タイミング:iPhoneアプリからappleAPNsサーバに初回アクセスに行ったとき、appleAPNsサーバで発行し、iPhoneアプリに戻してくる。
・プロビジョニングプロファイルとプロバイダ証明書について
プロビジョニングプロファイルは、開発用(Development)と商用(Production)が存在する。
それぞれ違いはあるが、注意すべきは、Productionが有効になっている場合、Developmentは無効になるということ。つまり、Production登録したあとは、iPhoneアプリに食わせるプロビジョニングプロファイルも、プロバイダサーバに置く証明書(pemファイル)も、Production版の証明書をキーチェーンからExportして使用しなければならない。
おそらく、APNsサーバ内で制御しているのだろう、APNsのテスト機(gateway.sandbox.push.apple.com)へアクセスしても、反応してくれなくなる。
参考:
iPhoneアプリで稼げるのか:PushNotificationの実装方法
Push Notification 用フレームワーク
Antの基礎
最近Antでのビルド環境を構築しているので、覚えたことをメモ。
・環境変数を取得する
・ビルドバージョンファイルを自動生成
こうすると、バージョンファイルが存在しない場合は生成し、存在する場合はビルド番号を1足してくれる。作成するアーカイブに取り込むようにする。
・他のビルドファイルを取り込む
まさにjavaのextendsのように、ビルドファイルも取り込むことができる。
参考:
公式ドキュメント
Hidedama's Ant Memo
・環境変数を取得する
<property environment="env"/>
<path id="ENV.TARGET">
<fileset dir="${env.libpath}" includes="*.jar"/>
</path>
・ビルドバージョンファイルを自動生成
<buildnumber file="src/build_version.properties"/>
こうすると、バージョンファイルが存在しない場合は生成し、存在する場合はビルド番号を1足してくれる。作成するアーカイブに取り込むようにする。
・他のビルドファイルを取り込む
まさにjavaのextendsのように、ビルドファイルも取り込むことができる。
<import file="../common_build.xml"/>取り込んだビルドファイルに定義しているターゲットでも、自分のターゲット名を同じにすればオーバーライドできる。
参考:
公式ドキュメント
Hidedama's Ant Memo
教訓 ライブラリ・ソース管理
仕事をしていて感じたこと、トラブルプロジェクトでの経験を生かして、
ここに教訓を書いておく。
ライブラリ・ソース管理
大規模開発において、必ずトラブルが発生するライブラリ・ソース管理。
開発するに当たって相当の工数を取られてしまうのが現状だと思われる。
管理を簡素化するためにいくつか覚書。
(1)ディレクトリ構造を同一にする
開発を行うメンバーは、開発に関する全てのディレクトリ構造を同一にする。
(2)ソース管理はバージョン管理ソフトを使用する
ソース管理は、フォルダを分けて「old」「new」などやるのは時間と手間の無駄。
バージョン管理ソフトを導入する。
VSS(Visual Source Safe)やCVS、SVN(Subversion)など。
CVSとSVNはフリーなので、導入が楽かもしれない。
VSSはファイルベースの管理ソフトなので、サーバが不要。ネットワークフォルダとクライアントソフトがあればOK。
SVNはサーバソフトとクライアントソフトが必要で、通常SVNといわれているのはサーバソフトのこと。SVNクライアントでは、TortoiseSVN(トータスSVN)がWindowsシェル統合で使いやすい。
(3)プロジェクトファイルを共有する
EclipseやVisualStudioなど、統合開発環境(IDE)のプロジェクトは必ず共有し、全メンバーで同一のものを使用する。
IDEのプロジェクトファイルには、様々な設定(例えばjavaの開発ならクラスパスや参照ライブラリの設定)が入っているため、各メンバーでバラバラの設定を持ってしまうと、ソースを新しくすると動かなくなる、などの事態が発生する。当然プロジェクトファイルもバージョン管理する。
(4)ビルド・メイク環境を一つにする
プログラムのビルド・メイクは、必ず一つの環境とし、バージョン情報を付加する。
ここに教訓を書いておく。
ライブラリ・ソース管理
大規模開発において、必ずトラブルが発生するライブラリ・ソース管理。
開発するに当たって相当の工数を取られてしまうのが現状だと思われる。
管理を簡素化するためにいくつか覚書。
(1)ディレクトリ構造を同一にする
開発を行うメンバーは、開発に関する全てのディレクトリ構造を同一にする。
(2)ソース管理はバージョン管理ソフトを使用する
ソース管理は、フォルダを分けて「old」「new」などやるのは時間と手間の無駄。
バージョン管理ソフトを導入する。
VSS(Visual Source Safe)やCVS、SVN(Subversion)など。
CVSとSVNはフリーなので、導入が楽かもしれない。
VSSはファイルベースの管理ソフトなので、サーバが不要。ネットワークフォルダとクライアントソフトがあればOK。
SVNはサーバソフトとクライアントソフトが必要で、通常SVNといわれているのはサーバソフトのこと。SVNクライアントでは、TortoiseSVN(トータスSVN)がWindowsシェル統合で使いやすい。
(3)プロジェクトファイルを共有する
EclipseやVisualStudioなど、統合開発環境(IDE)のプロジェクトは必ず共有し、全メンバーで同一のものを使用する。
IDEのプロジェクトファイルには、様々な設定(例えばjavaの開発ならクラスパスや参照ライブラリの設定)が入っているため、各メンバーでバラバラの設定を持ってしまうと、ソースを新しくすると動かなくなる、などの事態が発生する。当然プロジェクトファイルもバージョン管理する。
(4)ビルド・メイク環境を一つにする
プログラムのビルド・メイクは、必ず一つの環境とし、バージョン情報を付加する。
登録:
投稿 (Atom)