iOS

2015年4月 6日 (月)

【swift】カメラで撮影した画像からexifや回転の向きを取得する

最近swiftを使い始めたので備忘録。

UIImagePickerControllerを利用してカメラで撮影した画像から、exifや
回転の方向 を取得する例。
ちなみに、これはカメラで撮影したときの例。
フォトアルバムから画像を選択した際とは取得方法が異なる。

2014年5月15日 (木)

自作アプリ「めんくいカメラ 〜イケメン・美人しか写らない恐怖のカメラ〜」のご紹介

★よかったらtwitterのフォローお願いします!@Soramame_1110

今日は、ろくにブログも更新せずコソコソと作成していたアプリ、

"めんくいカメラ
〜イケメン・美人しか写らない恐怖のカメラ〜"

の、ご紹介です!

とりあえずストアのリンクを。iPhone版、android版両方作りました。
<iPhone版>
https://itunes.apple.com/us/app/menkuikamera-ikemen-mei-renshika/id846563434?mt=8

<android版>
https://play.google.com/store/apps/details?id=com.yso.menkuicamera

リリース自体は2週間ほど前に行ったのですが、

実は今日、こちらのサイトに紹介記事が掲載されているのを知りました(!)
http://www.appps.jp/90024/

まさかこんなふうに扱っていただけるとは思わなかったので嬉しいです。

さて、アプリの内容ですが・・・、

 

正直、上に書いた紹介記事がさすがプロの文章なだけあり上手すぎて、
僕が下手に紹介文を書くより記事を読んで頂いたほうがわかりやすく伝わると思います(笑)

なので、細かい話は置いておいて、

どんなアプリかを簡潔に言うと、

「名前のとおりイケメンや美人だけが写り、そうでない人は写らないカメラアプリ」です。

具体的には下のようになります!

●イケメンの場合・・・輝きます
Unnamed_2

●ダメな顔の場合・・・モザイクにより、消されます
Unnamed2

●論外の場合・・・↓のように悲惨なことになります
Unnamed3

なお、このアプリは写りの良し悪しも判定するため、

同じ人物の写真でも、写りがよければ点数は上がります。

なので、キメ顔とナナメ45度を超える究極の角度で写れば、

顔に自信がないアナタも高得点を狙えるはずです!

ちなみに今のところ、ぼくが知る限りの最高得点は

会社の後輩がネットで拾ったキムタクの画像の82点です。

自撮りした写真はたいてい50点前後をウロウロです・・・。

このブログをご覧になってくださったみなさんも、

是非遊んでみてください!!

※アプリの不具合報告やご質問、ご要望などありましたら、

  是非このブログにコメントください。お待ちしております!

2014年2月20日 (木)

【iOS】nendの公告を導入したiPhoneアプリがリジェクトされた

おひさしぶりです!

最近は、AndroidやTizenを離れ、

いそいそとiPhoneアプリを作ったり、

インフルエンザにかかったり、

雪の日に派手に転んで打った利き腕の右肩が上がらなくなったり、

いろいろなことがありながら過ごしていました。


さて、本題ですが、

先日、公開しているiPhoneアプリのアップデートを行ったところ、

Appleからリジェクトをくらいました。

なにせ、開発を始めて間もないiPhoneアプリでリジェクト、

焦りに焦りました。


どうやら、nendさんのSDKがひっかかったらしい。


その際にリジェクト理由としてappleから頂いたメールは以下のとおり。

PLA 3.3.12

We found your app uses the iOS Advertising Identifier but does not include ad functionality. This does not comply with the terms of the iOS Developer Program License Agreement, as required by the App Store Review Guidelines.

Specifically, section 3.3.12 of the iOS Developer Program License Agreement states:

"You and Your Applications (and any third party with whom you have contracted to serve advertising) may use the Advertising Identifier, and any information obtained through the use of the Advertising Identifier, only for the purpose of serving advertising. If a user resets the Advertising Identifier, then You agree not to combine, correlate, link or otherwise associate, either directly or indirectly, the prior Advertising Identifier and any derived information with the reset Advertising Identifier."

Please check your code - including any third-party libraries - to remove any instances of:

class: ASIdentifierManager
selector: advertisingIdentifier
framework: AdSupport.framework

If you are planning to incorporate ads in a future version, please remove the Advertising Identifier from your app until you have included ad functionality.

To help locate the Advertising Identifier, use the “nm” tool. For information on the “nm” tool, open a terminal window and enter, “man nm.”

If you do not have access to the libraries source, you may be able to search the compiled binary using the "strings" or "otool" command line tools. The "strings" tool lists the methods that the library calls, and "otool -ov" will list the Objective-C class structures and their defined methods. These techniques can help you narrow down where the problematic code resides.



英訳を読む限り、

"adsupport.frameworkを使用しているにもかかわらず、

公告を表示していないアプリは審査を通してあげることは出来ないよ!"

と、いうことらしい。

adsupport.frameworkは、アプリ内に導入しているnendさんのSDK内にて

使用されています。

とはいえ、もちろんnendSDKを使用した公告表示は行っているので、

なんら問題ないはずだ・・・。


と、いうわけで、「公告表示は間違いなく行っているので、もう一度審査をやり直してください!」と、appleにメールを投げつけました。


すると、数日後、バイナリの変更を行うことなく無事審査が通過しました。


本当に人騒がせです。

もし、nendさんの公告を使用していて、私と同様にリジェクトされた方は、

同じようにappleにメールを投げると良いかもしれません。


ちなみにadsupport.frameworkの件でリジェクトされるようになったのは

2014/2以降で、このときに審査基準が変更されたようです。

2013年8月 2日 (金)

AndroidとiOSで、画面をバックグラウンドに移動させた時のタイマーの動きを比較してみた

最近、仕事でiPhoneのアプリを触ってます。

iOSの画面はViewController、Androidの画面はActivityという

クラスで作るのですが、タイマーを起動した状態でこれら画面を

バックグラウンドに移動した際の動きに違いがあったので、

忘れないようメモっておこうと思います。

比較した動作は、以下のとおりです。

タイマーを起動した状態で、以下の操作を実行

  • 画面上に別の画面を重ねる
  • 画面を終了させる
  • ホームキーを押下する

【iOSの場合】

●画面上に別の画面を重ねた場合

上に別のViewControllerを重ねても、タイマーは裏で動き続ける。

●画面を終了させた場合

画面を終了させても、タイマーは生存し続ける。

●ホームキーを押下する

タイマーによるメソッドコールが行われなくなる。

しかし、タイマーは死んだわけではなく、再びアプリを復帰させると、

タイマーのメソッドコールが再開される。

バックグラウンドにいる間に、タイマーに設定したインターバル時間が超過した場合は、

フォアグラウンドに復帰直後にメソッドコールが行われる。

【Androidの場合】

●画面上に別の画面を重ねた場合

すなわちonPause(), onStop()が呼ばれたとき。

上に別のViewControllerを重ねても、タイマーは裏で動き続ける。

これはiOSと同じ。

●画面を終了させた場合

onDestory()まで呼ばれたとき。

アクティビティが終了しても、タイマーは裏で動き続ける。

これもiOSと同じ。

●ホームキーを押下する

ホームキーを押下されたあとも、タイマーは動き続ける。

ここがiOSと違う。

まとめると・・・、

(1)  ホームキーを押下したときのタイマーの振る舞いが異なる。(※ここでハマった。やっぱり同じ感覚でソース書いたらだめですね・・・。)

(2)AndroidでonDestroy()が呼ばれたからといって、タイマーは破棄されない。というかonDestroy()後もアクティビティのメモリが残ってしまっているのでタイマー解除は忘れずに。

(3) iOSでも、画面を消去後もタイマーは破棄されない。破棄してあげないと、やはりメモリは解消されないので要注意。

その他のカテゴリー

購入


無料ブログはココログ