[Android] - 愛と勇気と缶ビール

しばらく前に家のマシンをArch Linux/半自作PC からOS X/Mac miniに移行した際にそれまで作っていたAndroidアプリのsign key (~/.keystoreに作ってたもの) を全消滅させました。

二度とアプリをアップデート出来なくなって悲しかったので、2と銘打って同じようなものを作った次第です。

アプリ的には特筆すべき点も何もないのですが、今回の自分への課題設定として

Android4.x系の新しいfeature(特にAction Barとか)に慣れる。
Scala on Androidな開発にInteliJ IDEAを使ってみる。
Scaloid (pocorall/scaloid ? GitHub) を使ってみる。

というものがありました。メインはやっぱり「作り方がもう分かってるアプリで、4.x系への肩慣らし」ですね。

1.については、こないだ「Android4.0以上が搭載されている端末が日本全体で50%を超えた」とのニュースを見て、「50%超えたなら、もうそれ以下のは見捨てていいや。どうせ今後もっと増えるし」と決めたからです。企業だとあり得ない選択ですが僕は趣味で作っているので、今後何らかのアプリを作る際は全部4.0以上対応にして新し目の機能もガッツリ使って可能ならそれをウリにしていきたい次第。

2.については、元々Java/Eclipseめんどい、という比較的消極的な理由でScala/Vimで開発していたのですが、最近はXcodeを触ったことで「IDEもよくね？」という拘りなきマイルドな気分になってきており、特にiOS/Android開発みたいな「コアライブラリががっつり存在していて、それに乗っかって作るもの」についてはIDEによる支援があった方がありがたいので、InteliJ IDEAデビューしてみました。Android開発では「これこれのクラスのこれこれのメソッドをオーバライドする」みたいなケースが多いのですが、InteliJ IDEAは元々のJavaのシグネチャをよしなにScalaのそれに置き換えた上でオーバライドするコードを生成してくれます。中々賢いです。今のところCommunity Edition（無料）の機能で問題なく開発できており、Saleがあれば有料版のライセンス買ってもいいかな…？ぐらい。個人的には、Scala on Androidな開発はこれをもって大分こなれてきた感じ。SBT ConsoleもlogcatもIDEAから使って、ストレスなく開発できる環境が整いました。

3.については、元々はPositronic Net (rst/positronic_net ? GitHub) を使ってみる予定だったのですが、あまり開発が盛んでなさそうなのでScaloid (pocorall/scaloid ? GitHub)にしました。以前はAndroid API周りをScala的に書きやすいようラップするのを意図的に避けていた（それに依存しすぎて、Javaで書けない = 一般的なAndroid開発のスキルとして意味がなくなっては困るので）のですが、以前よりAndroid周りの知識も増えたので、元々のAPIを分かった上で使うなら別にいいか、と。

同じものをJavaで書いたわけでもないので「Scalaだから短い」とは言い切れませんが、アプリ全体は400行くらい、そのうちオレオレSQLite ラッパーライブラリ(not ORM)が100行くらいです。後者はそのうち固まったら公開するかもしれません。

Permalink | コメント(0) | トラックバック(0) | 20:37

2012-12-24

2012年度個人的iOS開発系・Android開発系のお勧め書籍まとめ

iOS, Android

今年は、iOS開発/Android開発の両方について曲がりなりにも学んだ年だったので、他の人の参考のために僕が読んで有益だった書籍をまとめます。厳選しているので数は少ないです。

全体として、ある程度のプログラミング経験がある人向けです。各プラットフォームに関してXcode, Eclipseなどの開発環境を整えて、サンプルプログラムを自分で動かすことくらいは簡単に出来るレベルを想定しています。

iOS開発

詳解 Objective-C 2.0 第3版

いきなりアプリ開発系の本を読んでもいいのですが、何でも基礎の部分（この場合はObjective-C）を理解せずに突き進むのは結果として時間の無駄になることが多いので、まずはObjective-Cに関する勉強をこの本でガツッとやってしまうといいのではないでしょうか。

Objective-Cは、誤解を受けることが多い言語です。メソッド呼び出しなどの構文の見た目がよくあるオブジェクト指向言語と異なるため、なんとなく「Objective-Cキモいわー。ありえないわー」と思っている方も多いと思います。僕もそうでした。

だいたいどんな言語でもそうですが、勉強する前にイメージとして持っていたキモさは勉強した後では払拭されることが多いです。そりゃお前がキモさに慣れてしまっただけだろうと思われる方もいるかも知れませんが、大抵の言語は何かしらキモいのでまあそんなもんだと思って諦めましょう。ある程度真面目に時間を使ってこの本に取り組んでみれば、キモいかどうかは別にしてObjective-Cが色々おもしろい側面を持った言語であることが分かると思います。具体的な根拠はありませんが、Rubyが好きな人はObjective-Cも好きになれるんじゃないかと思っています。

現状、個人で開発するならiOS4系は無視した上でiOS5系から使えるARCを利用してメモリ管理を簡略化するとよいと思います。この本では、その辺の比較的新しい言語事情（ARCが言語事情かは置いといて）もフォローされています。よりObjective-Cを楽しみたい方はDynamic Objective-Cも読んでみるといいと思います。最短距離を行きたいならば不必要かと思います。

iPhoneプログラミングUIKit詳解リファレンス

実際のアプリ開発ではUIKitというiOS用GUIフレームワークに乗っかって開発することになるのですが、この本ではUIKitを使ってものを作る上で必要な基礎知識が広範にフォローされています。StoryBoardなどのGUIビルダーでUI作るぜ！という人には正直不要かもしれません。僕はこれ以上Appleに振り回されたくないため、今のところGUIビルダーは使わずUIKitで書いています。この辺は意見の分かれる所かとは思いますが、UIKitで作る人はリファレンスを兼ねて持っておいて損はない本です。

iPhoneアプリ設計の極意 ―思わずタップしたくなるアプリのデザイン

僕がいまさらお勧めするまでもない本ですが、アプリを何で作るか（iOS/Android/HTML5）に関わらず考え方のヒントになる本です。スマートフォン開発のプロデューサー等でこれをちゃんと読んでいないような奴はモグリだ、と言っても過言ではありません。しばきましょう。

Android開発

本格アプリを作ろう！ Androidプログラミングレシピ

開発環境も整って、サンプルアプリも動かして、さあ自分の作りたいものを作ろう、と思った時に「でも、あれを実現するには具体的にどうしたらいいんだ？」と手が止まってしまう人は多いかと思います。これは、その段階から実際に動くものを作り出すまでの架け橋となる本です。一般にこういったレシピ本（あるいはQ&A形式の本）は内容が薄いことが多いですが、この本は例外です。特に、第1章のAndroidアプリケーションのアーキテクチャおよびActivity, Service等のライフサイクルについての概説は秀逸です。

Android Layout Cookbook アプリの価値を高める開発テクニック

AndroidはiOSに比べるとデフォルトのUIパーツがぶっきらぼうなので（ICS以降はもそっと違うかもしれませんが）、そのままにしているとダサダサなアプリになってしまいがちです。この本にはAndroidにおける見た目の制御についてかなり詳細かつ正確な記述があるため、ネットで得た曖昧な情報に四苦八苦するくらいならこれを初めに買ってしまった方がよいです。著者のあんざいゆきさんはAndroid界ではかなり有名な方で、ICS以降のレイアウトに関しても本を出されています。（Android UI Cookbook for 4.0 ICS（Ice Cream Sandwich）アプリ開発術）こちらは僕はまだ持っていませんが、そのうち買う予定です。

プログラミングAndroid

レビューにもあるように訳にいささか難がありますが、Oreillyらしくガチな内容で良い本です。特に6.3の「Androidの並行処理」にあるAsyncTask, スレッド拘束, LooperとUIスレッドの関連性についての記述は有益です。AndroidにおけるMVC（と書くのが微妙ならデータソースとActivityの疎結合化）について、他の本にはないような展望が示されているのも素敵な所です。

その他

Androidについては、「インプレス・ジャパン以外の本は基本買わなくてよし！」と断言してしまいたいほどに、インプレス・ジャパンにいい本が揃っています。Android Security　　安全なアプリケーションを作成するためにもそうですね。この本は敢えてオススメには挙げませんでしたが、企業で仕事としてAndroid開発に関わっている方には必携の書籍だと思います。

総括

あらゆる他の情報と同じくして、僕が紹介したこれらの本に載っている情報の断片はインターネットを駆使して手に入れることも可能です。が、総合的なコストを鑑みるとお金を出してまとめて知識を仕入れてしまった方が安上がりです。

人ごとに合う合わないがあるためここに載せた全ての本があらゆる人にとって最良だとは思いませんが、技術書というのはおおむね高額なので、出来るだけ無駄な本を買わずに前に進む際の一助になれば幸いです。

Permalink | コメント(0) | トラックバック(0) | 17:51

2012-12-09

2012年度Androidアプリ開発収支報告あるいは個人でAndroidアプリ開発は儲かるのかって話

Android

最初に書いておくと、これはサクセスストーリーじゃないぞよ。

それは去年の暮れのことだった

思えば僕がAndroid開発やってみよっかなーと思ったのは、去年の暮れにこの裏Android Advent Calendar2011のエントリーを読んだのがきっかけだった。ホントに儲かんのかなー、と思って。要は分かりやすく金に釣られたわけだ。

といっても、上記のようなエントリーを読んで「よし、自分もやってみよう」と思う人は実際にはそんなに居ない。なぜかといえば、「よしやろう」と思う前に以下のような疑問・思いに支配されて手が動かなくなるから。

新しいプラットフォーム・言語について勉強して、ある程度使いこなせるようになるまでには結構なコストがかかるよねー
たまたま上記ブログの人が大成功してるだけで、そんなに上手くいくわけねーだろ
Android(iOS)アプリってもう色々な個人・会社が参画してるし、過当競争だよねー
俺はHTML5がそのうち市場を席巻すると思ってるし、その時代が来るまでネイティブアプリに時間を費やすなんて無駄なことはしたくないぜ

どれもある程度は正しいし、別に間違っちゃいない。ただ、共通しているのは自分が行動した結果から導いた考えじゃない、ってことだ。ネットにある情報を拾って、なんとなく現状を理解したような気分になり、自分がやらなくてもいい理由を作る。よくある話だ。

去年の暮れには、僕も上のような疑問に囚われて、ネット上で裏付けを探した。裏付けっていうのは、これからiPhoneが流行るのかAndroidが流行るのか、果たしてホントに儲かるのかどうか、そういう疑問に対する信頼のおけるソースだ。今思えばそんなもの探したって何の意味もないし時間の無駄なんだけど、行動に踏み出す勇気のない人間のやることってなぁ大体そんなもんである。

結局そういう裏付けを探すのはやめにして、市場調査と称してAndroid Marketのランキングをなめるように見ることにした。僕は年に一回、大学の部活の先輩の家で忘年会をやるために大阪に帰る。その集合場所であるスーパーマーケットのベンチで延々とHTC evoを使ってランキングを見ていた時のことを思い出すと、今でもなんだかドキドキする。謎の野望に燃えていた。

1月～3月くらいのこと

大阪での忘年会の後、実家に戻ってウダウダし、本格的に開発を始めたのは1月の中盤に東京に戻ってからだった。本当は実家でも「端末を振ると起動するメモ帳アプリ」という不思議な物体の開発に勤しんでいたのだが、そもそもそういうアプリはお行儀がよくないというのと、アプリの起動が満足のいくレスポンスタイムにならなかったので、ボツにした。

ランキングを見て、その時点では「お話し系アプリ」がまあまあ流行っていることが分かっていたので自分もそれに倣うことにした。「お話し系アプリ」というのは何ぞやというと、多分みんなどこかで見たことのあるだろう「感動する話」「泣ける話」「都市伝説」「凶悪犯罪事件簿」「2chの怖い話」みたいなアプリの僕の中での総称である。正直言って下らないことこの上ないジャンルなのだが、一つ一つのお話しはテキストファイルにでもしてアプリにぶっ込んでおけばいいし、アプリの作りも簡単なので、一番初めに作るものとしては最適に思えた。何でもそうだけど、最初からすごいもの・かっこいいものを作ろうとするのはアホである。自分に対して適切な高さのハードルを設定していくのが挫折しないコツなのだ。

かくして「お話し系アプリ」に手を染めたのだけども、これが意外に儲かった。昔すぎてあまり記憶に残っていないが、出してしばらくして一日に200円くらい広告で儲かるようになったと思う。お話し系アプリは一度全てのお話しを読んだらやることがなくなってしまうし、それを防ぐためには自分でコンテンツを追加しなければいけないのであまり筋はよくないのだが、それでも初めに沢山コンテンツを作っておけばそれなりに時間を潰せるものになる。そんでもってお話し系アプリをわざわざ端末に入れて読むような人は間違いなく暇なので、暇な人なら広告をクリックすることもそれなりにあるだろう、という読みだった。

ちょっと脱線すると、そのアプリに適さない収益化モデルをとって儲かるの儲からんのと言ってもしょうがないのである。カメラアプリを使う人は、今すぐ何らかの写真を撮りたい人だ。だから、そんな人に広告を見せてもしょうがない。だからカメラアプリは有料アプリにして売り切りにするのが合っているし、その逆として「お話し系アプリ」は無料にして広告を入れるのが適している。お話し系アプリは、ヒマな人がある程度の時間を使って画面を眺めるものだからである。

広告は、当時色々試して単価が高かった（1クリック10円くらい？）Adlantisとnendをエロ広告ありでメインにした。この後具体的な金額の話も出てくるが、他のアドネットワークはほとんどオマケみたいなもんである。ちなみに、これは1～3月くらいに試した結果から判断しただけなので、多分今は色々変わっているだろう。

このアプリでだいたいの開発のノリ、Android Marketのノリが分かったので、次はアンサイクロペディアがSmartPhone向けviewを持っていないことに着目して専用ブラウザを作ることにした。これについては記事も書いている(「アンサイクロペディア・ブラウザ」とかいうAndroidアプリをつくった - 愛と勇気と缶ビール)。レビュー依頼をしたら、結構有名どころのアンドロイダーに取り上げてもらえたこともあってかまあまあDLが伸びた。これを出してしばらく後の広告収入は、2つのアプリを合わせて一日に500円くらいだったような記憶。

その次は、AKB48やその眷属のGoogle+での発言をGoogle+のアカウントなしで見られるアプリを作ることにした。これは僕の作ったものの中でおそらく最も手が込んでいて、Google+をクロールしてDBに突っ込むcronjobと、API serverもどきとクライアントが絡んでいる。さくらのVPSでUbuntuを立てて、サーバサイドはPerlで書いた。クライアントでは、ネットワークアクセスをバックグラウンドでやってUIに結果を戻す、という部分をScalaのActorで書いている。書き忘れていたが、今のところAndroidアプリはjberkel/android-plugin ? GitHubを使って全部Scalaで書いている。個人的にはiOS/Androidのアプリを別言語で書く系のソリューションはあまりお勧めしないのだが、android-pluginは例外で、なぜなら

ScalaからJavaのAPIは透過的に使えるので、問題が起こらない (AsyncTaskなどの稀な例外を除く）
android-plugin自体がよく出来ている。レールがちゃんと敷かれており、こうした類のhackに伴う罠や障害が少ない。
パフォーマンスも普通のアプリを書く分には全然問題ない（と、おもう）

…などなど。特にUIが絡むコードでは「イベント発火」→「処理」→「UIを更新」という流れのコードを書くことが多いのだが、こうしたコードではクロージャが自由に使えると小回りが利いて便利である。AndroidをJava以外で書く系のソリューションについてちょっとだけ書くと、個人的にはMonoDevelopや次いでTitanium辺りがマシなのではないかと思っている。PhoneGapはiOSでならいざ知らず、Androidで使うのは~~ちんこ丸出しで歩くようなものだ~~セキュリティ的な意味で論外である。詳しくは以下の記事を参照されたし。

僕はまあ諸々の理由でScalaで書いていますが、大事なのは「何で作るか」ではなく、「何を作るか」なのは言うまでもないことです。Native vs HTML5論争とかも含めて。

でまあ、どのくらい儲かったか

能書きはこの辺にしておくとして、実際にどの位のお金が得られたかというと、2012年の1月から開発を始めて今までで約20万円くらい。ちょうど、経費なども考えると税金を払わなくてもいい位の金額である。実質的に収益があったアプリは3本くらいで、いずれも広告収入。開発期間は2週間～4週間くらいで週末プログラミング駆動。一番良かった時（5～7月くらい？）の週末に一日1200円くらいの収益があった。今は放置しているのもあいまってユーザが減ったり、クリック広告の単価が減るなどもあいまって一日に300円くらい。実質上4月以降はほぼ何も開発せずに放置している。

1年で20万というと、ビッグなビジネスを目指している人や、スマホアプリで一山！みたいなこと考えてる人から見たらカスみたいなもん。サラリーマンのお小遣い稼ぎと思えばまあまあ上々。個人の実感としては、開発にかけた時間コストが大したことない（1～3月に作って残りはほぼ放置）のと、得られた知識やノウハウなどの金銭以外のメリットも合わせて考えると全然儲けもの。まあ、こういう計算に「得られた知識」とか入れちゃう時点でアレなんだけどね。

ちょっとだけ現Google Playの数字をば。MAUだとかDAUだとかそういうのは一々出してません。めんどいので。

x	お話し系アプリ	アンサイクロペディアのやつ	AKBのやつ
total user installs	12500	15389	5583
active device installs	1997	6497	1183

これを見て「これだけしかユーザいないのかー」と思うか、「これだけの数のユーザしかいない割には儲かってる」と思うかはあなた次第ですが、まーどうなんですかね、比べたことないので分かりません。それこそモデルにも寄りますからね。

iOSやAndroidのマーケットにどんどんアプリが増えていて、企業によるクオリティが高いアプリが増えているのは確かですが、僕個人としてはまだまだアイデア次第で個人がつけいる隙はあるんじゃないかなー、と思っています。だいたいみんな同じようなアプリを作ってるだけ、っていうイメージなので。もちろん例外はありますが。企業と同じようなアプリを個人で作ってもクオリティの面で勝てる確率は低いので、別の所で勝負する必要がありますな。

Androidアプリで得た小金でMac miniを買って、今はiPhoneアプリを作っていたりもします。自分が普段使うものは、別にお金にならなくても全然構わない、むしろお金が入ればラッキー、くらいの気持ちで作れるのでよいですね。プログラミングをこういう形でお金に結びつけるのがあまり好きじゃない方もいるかもしれませんが、小遣い稼ぎになるというのは技術習得に向けたモチベーション維持という意味でも地味によいです。捗ります。

最後に宣伝になってしまってアレなのですが、ついこの間作ったiPhoneアプリの「漢の家計簿」ですが、11/30までセールで0円、それ以降は85円、という形にしていたのを以降ずっと0円にしました。

お金を節約するためのアプリに85円とはいえ初期投資が要るのってどうなの？
やっぱ有料だとDL数が減ってしまうので、~~思ったよりもうからなかった~~無料にしてより多くの人に使ってもらいたい
シンプルで使いやすいアプリを標榜してるけど、まず使ってもらわないとやっぱり良さは分からない。では無料だ

という理由からです。次のアップデートで、カテゴリの編集などの追加機能をIn-App Purchaseで買えるようにする予定です。結局金取るんかい！っていう話ですが、~~嫌儲はくたばれ~~まあ、開発に使う時間はタダではないので。

そんなわけで今後も勉強がてらiPhoneやらAndroidやらのネイティブアプリや、そっちが適していると思ったらWebアプリなども作ったり作らなかったりするかもしれませんが、よろしくお願いします。

漢の家計簿

カテゴリ: ファイナンス

価格: 無料

Permalink | コメント(0) | トラックバック(0) | 00:52

2012-11-26

iPhoneやAndroidのUIガイドラインは念頭に置きつつほどよく無視するのがいい

iOS, Android

「漢の家計簿」は、項目をスワイプ → 削除ボタンが出る → 削除ボタンをタップという操作で登録した項目を削除できるのですが、分かりづらい！という指摘が@xaicronからあったので、スワイプでなく項目のタップでも削除ボタンが出るようにしました。現在、審査待ちです。iPhoneアプリはやっぱり更新に時間がかかるのがイライラムラムラしますね。

なんとなく知っている人も多いかと思いますが、iPhoneでテーブル（あるいはリスト）から項目を削除するのは大体二通りの方法があって、

ナビゲーションバー（アプリ上部のバー）に「編集」とかのボタンがあって、それをタップするとテーブルにある全ての項目の編集・削除モードに入る
セルをスワイプするとその項目の削除モードに入る

という感じです。ちょっと分かりづらいですが iPhoneアプリ開発、その(190) 削除するぜ！｜テン＊シー＊シーに両方の画像がありますね。

iOSの5.0 (4.0だったかな) くらいからはナビゲーションバーの右側とか左側にそれぞれ2つのボタンを置けるようになったので1つ目の方法を取れないこともなかったのですが、ミスタッチしそうだし、なんだかあの削除モードというのが僕はあまり好きでないので、「まぁスワイプでいいか」と思って2つ目の方法にして放置してました。サーセン。

「スワイプで項目を削除できる」っていうのは一応iOSで共通の操作というかAppleお勧めの挙動だったりするんですが、どう考えても分かりづらいんですよねコレ。分かりづらいから初期起動した時に「ここをスワイプで消せますよー」みたいなガイドを表示しようかなーとも思ったのですが、なんか実装するのめんどくさいし、そもそも使い方の説明が必要な時点でそのアプリってシンプルじゃないよね？と思ったのでガイドはやめて項目タップで削除ボタンを出すようにしました。

(※本記事のコメントにあるように、スワイプ動作に慣れていない人向けに「編集」ボタンを置かないというのは完全にアプリ側の都合なので、スワイプ動作の直感性の無さだけをもって「Appleのガイドラインは微妙」という主張をすることは出来ません）

とはいえ、実はiOS SDKには「スワイプした結果として表示される削除ボタンを、プログラム中から任意のタイミングで表示させる」方法が実はありません。少なくとも僕の知る限りでは。iPhoneアプリはこんな感じに変に融通の利かない所が多くて、これがWebアプリとかだったらこんなの簡単なのに！ムキー！と時々なるのですが、まあフレームワークに乗っかるというのは元々そういうもんなので、しょうがないですね。しょうがないので、UITableViewCellのaccessoryViewにそれっぽいUIButtonをぶっ込んで対応しました。ちゃんちゃん。

これに限った話ではないのですが、AppleやGoogleの出しているiOS, Android用のUIガイドラインは頷ける内容も多いのですが、鵜呑みにするものではないと思っています。大きなやつを挙げると、

iOSのガイドライン通りにアプリを作るとアプリの設定画面とアプリの本体が別々になってしまう（なぜか「設定」アプリから個々のアプリの設定画面に行かなければいけない…）。これはどう考えても使いにくいだろうハゲ。アプリの設定はアプリの中に置け。
(これはガイドラインではないが) Android3.0以前ではAction Barの代わりにMenuを使うけど、あれは存在が分かりにくい。tabとかの方がマシ。

とかとか。「iPhoneではこれが普通だから」「Androidではこれが普通だから」「これはWebアプリだから」「Apple (or Google) がそう言っているから」というような理由で思考停止しないようにせんといかんなあ、と今回思いました。とはいえプラットフォームで共通の動作、推奨の動作を完全に無視すると今度はその動作を期待している人にとっておかしな動きをするアプリケーションになってしまうので、単純にガイドラインを無視するっていうわけにもいかないのが面倒なところです。

今回の話でいうと、「タップで削除ボタンが出るようにする。スワイプでも期待通りに削除ボタンが出るようにしておく」というのが正しいプラクティスになると思われます。この辺のことは↓の本にも書いてあります。この本はよいものだ。

あれ、日本語のオライリー本を買うのはやめたんじゃなかったっけ？てへぺろ。

Permalink | コメント(2) | トラックバック(0) | 15:27

2012-08-01

Google Playからメールがきた

Android

もそっとアプリのチェックを厳しくするぞ、ってことでおｋ？

Hello Google Play Developer,

We are constantly striving to make Google Play a great community for developers and consumers. This requires us to update our policies when we launch new features, like subscription billing, and also when we see unhealthy behavior, like deceptive app names and spammy notifications. This email is to notify you that we’ve made some changes to our policies which are highlighted below.

- We’ve added clearer details to the payment policy, and guidelines on how we will handle cancellations in our new subscription billing feature
- We are restricting the use of names or icons confusingly similar to existing system apps in order to reduce user confusion
- We are providing more detail on the kinds of dangerous products that are not allowed on Google Play. For example, apps that disclose personal information without authorization are not allowed.
- We are giving more examples of practices that violate the spam policy.

Additionally, we are adding a new section that addresses ad behavior in apps. First, we make it clear that ads in your app must follow the same rules as the app itself. Also, it is important to us that ads don’t negatively affect the experience by deceiving consumers or using disruptive behavior such as obstructing access to apps and interfering with other ads.

Please take a look at the Google Play Developer Program Policy at http://play.google.com/about/developer-content-policy.html to see all the changes and make sure your app complies with our updated policies.

Any new apps or app updates published after this notification will be immediately subject to the latest version of the Program Policy. If you find any existing apps in your catalog that don’t comply, we ask you to fix and republish the application within 30 calendar days of receiving this email. After this period, existing applications discovered to be in violation may be subject to warning or removal from Google Play.

Regards,
Google Play Team

Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043

You have received this mandatory service announcement to update you about important changes to your Google Play service or account.

Permalink | コメント(0) | トラックバック(0) | 16:48

愛と勇気と缶ビール

2013-03-17

アンサイクロペディア・ブラウザ2というアプリをScalaで作ってGoogle Playに出した