「2048」というゲーム

「2048」

これは、最近Web上で騒がれているゲームアプリになります。

game2048

このゲームの特徴ですが・・・

(1)操作がスワイプのみで簡単

(2)同じ数字のマス目が隣接した際に、その合計値のマス目に計算統合される。

(3)最終的に「2048」の数字を持つマス目を作成できればクリア

という、極めて「簡単」かつ「明快」、それでいて「面白くてハマってしまう」というゲームアプリになります。(私の私見かもしれませんが・・)

 

しかし、このゲームには物言いが生じています。

 

ことの経緯は、このようになっているようです。

(経緯1)
作者Aにより「Threes!」というパズルゲームが開発され、有料アプリ(販売価格¥200)として公式公開される。

(経緯2)
しかし、作者Bがこの「Threes!」を真似て(もしくは近似した内容で)「2048」を開発し、これまた公式公開する。しかも、広告付きではあるが、無料で公開している。 ※補足すると、「2048」は「Threes!」のゲームエキス的部分を、作者Bがアレンジした開発した内容になっているようです。

(経緯3)
さらに、作者BがGitHubに「2048」のソースコードを公開したため、アプリ市場に「2048」の模倣アプリが蔓延し、経緯1で記載の「Threes!」がその模倣アプリの中に埋もれる事態になっている。

(経緯4)
そして、最もWeb上で騒がれているのが、この「2048」が、あの任天堂が携帯ゲーム機「3DS」用ソフトとして商品化し今月より販売を開始したことである。(ちなみに、販売価格は¥300)

 

私は、このニュースを、初めて知った時、「ソフトウェア業界、何だかおかしくなってるな・・」と思わずにはいられませんでした。

(1)
作者Aのソフトウェア著作権はどこに消えたのか?

(2)
任天堂は、作者Bからアイデアを買い取ることになるのか? (作者Aの立場は?)

(3)
そもそも、ことの経緯を知りながら、任天堂がこのような販売を行うとは・・・どうなんだろうか? 
なお、任天堂社から「法律的に問題ないことを確認した上で販売決定した」というコメントが出ているようです。

(4)
今後、世の中に発表されるアプリに関しても、このような模倣(パクリ)が合法として市場に認めらてしまうのか?

 

さて、皆様はどう思われますか?

 

 

Androidアプリを公開したら・・来ました。広告勧誘メール(苦笑)

先日、AndroidアプリをGooglePlayより公開したところ、すぐに以下のような広告勧誘メールが送付されてきました。

当社アプリ「連勝じゃんけん」に関しては、開発当初から「広告機能は組み込まない」という思いがありましたので、このメールは無視することにしました。
(あくまでも私個人の判断ですが)

 

その前に、本気で広告勧誘したいなら以下の2点は考慮して欲しいものです。

(1)
開発者の母国語
によるメール文章の記載
(今回は日本語で送付すべきです)

(2)
どうみても、「会社名」「アプリ名」をパラメータとして機械処理したとしか思えない無機質なメール文章
(連勝じゃんけんを気にかけた事由を記載すべきです)

 

<これが、その広告勧誘メール> ※多分、青字がパラメータと思われます。
————————————————————————————-
Dear Transsoft team,

My name is xxxxx and I am specialized in helping android developers to
better monetize their apps on Google Play. Our premium advertisers are
currently looking to buy android traffic at a very high price in apps
like 連勝じゃんけん.

We think you can generate up to $10 CPM with their full screen ads,
which are very clean. Indeed, most of our advertisers are willing to pay
over $1 per installation. You’re free to display these ads whenever you
want in your app so that it’s not intrusive.

If you’d like to learn more, don’t hesitate to ask me. You can also
visit our website: the link is in my signature

What do you think? Do you want to give it a try?

Cheers,
————————————————————————————-

スマホアプリの開発は、思い立ったらスピードが命です!

先日、Androidアプリ「連勝じゃんけん」をGooglePlayより公開させていただきました。

無事に公開できてなによりだったのですが・・・・

私、個人としては残念でならないことがありました。

それは、この「連勝じゃんけん」が公開される約1カ月前に同名(しかも、ほぼ同機能)のアプリが公開されていたのです。

内容的には、当社のアプリの方が出来が良いと思っております。
自画自賛と言われるかもしれませんが・・)

実は、このようなことを経験するのは、これで2回目になります。

前回は、転職前の会社で開発したiPhoneアプリでして、AppStore公開前に東京のITフェアで事前プレゼンをしたところ、そのiPhoneアプリの仕様をそっくりコピーされたようなアプリが他の方からAppStoreに公開されてしまいました。しかも、そのITフェアで紹介したアプリ名もそのまま使われて・・・(まず、間違いなくアイデアを盗用されたものと考えます)

その数か月後、転職前の会社よりそのアプリをAppStoreに正式公開することになったのですが、くやしいかな後発となったため、アプリ名を再検討して若干不本意な名前で公開することになったのです。

スマホアプリ開発は、
アイデアが生まれたら、
すぐに開発して、
すぐに公開する。
しかも、公開するまでアイデア(アプリ仕様)は他言無用を厳守する。

今度は、これを徹底するぞ!

開発メモ:ソースコードに誤りがなくても……。

先日、Androidのアプリを開発中にある不具合が発生しました。トグルボタンを押した際に、ボタンの背景がなぜか真っ黒になってしまうという不具合でした。

もちろん、アプリの見た目を大きく損ねてしまう不具合なので、即座に原因を探ることとなります。ですが、トグルボタンのデザインは、独自にxmlファイルを定義することで静的に変更しており、ソースコードの側では一切触れていません。
ということは、xmlファイルの方にエラーがあるのか? と思い調べてみるも特に問題は発見できず。さて一体なにが原因なのだろう、と首をひねったところでふと気づきました。

現在弊社では、試験用の端末として二つのAndroidタブレットを使用しているのですが……もう片方のタブレットでは、この不具合が確認できないのです。
ということは、まさか端末の方に原因があるバグなのか? 不具合が起こる端末の方で最新のシステムアップデートが公開されていたので、それをダウンロードしてみます。

すると……直りました。どうやら、本当に端末側の不具合だったようです。
アプリで不具合が発生すれば当然、自分の書いたソースコードをまずは疑うものですが、今回のように端末側が原因で起こる不具合というのもあるのですね。
一つ、経験になった事例だったと思います。

2013年9月5日 | カテゴリー : Android開発 | 投稿者 : youchin

Google Playより、Androidアプリ「連勝じゃんけん」を公開しました。

本日より、Google Play にてAndroidアプリ「連勝じゃんけん」を公開開始とする運びとなりました。

単純に、じゃんけんで連勝をして「気分爽快」になっていただくだけのアプリになります。

お暇な時に、ダウンロードしていただければ幸いですね。

■Google Play  「連勝じゃんけん」の紹介ページ https://play.google.com/store/apps/details?id=jp.co.transsoft.janken&hl=ja

開発メモ:システムバーを一時的に隠す、または見えにくくする方法


システムバー

Androidタブレット端末で、画面下部を常に陣取っているシステムバー(上画像赤枠部分)を一時的に隠したり、見えにくくしたりする方法を調べましたのでメモしておきます。

タイトルバーやステータスバーの非表示は、Manifestファイルにてアクティビティのテーマを、『Theme.Light.NoTitleBar.FullScreen』などの『NoTitleBar.FullScreen』がついているテーマに変更することで行えます。ですが、システムバーをこのような方法で非表示にすることはできないようです。
まあ、非表示にしてしまうとホームボタン等の各種ボタンが押せなくなって操作不能になってしまうので、当然といえば当然ですね。
けれど時には、そのせいで画面領域を最大限に活用できなかったり、操作ユーザーの集中力を妨げる原因になってしまうこともあるので、本記事のタイトルにもある通り、二つの折衷案が用意されていました。

ではまず、システムバーを一時的に隠す方法から。ソースコードに以下の内容を記述します。


View view = (View)findViewById(R.id.relativeLayout);
view.setSystemUiVisibility(View.SYSTEM_UI_FLAG_HIDE_NAVIGATION);

作成するViewインスタンスには、アプリのレイアウトXMLファイルで定義されているレイアウトを、どれか一つ指定します(ここではRelativeLayout)。なお私がテストした環境では、最上位以外のレイアウトでも大丈夫でした。
そして作成したViewインスタンスを使って、setSystemUiVisibilityメソッドに『SYSTEM_UI_FLAG_HIDE_NAVIGATION』を設定し、呼び出すだけです。

システムバーを一時的に非表示にする

このように、アプリの画面からシステムバーを一時的に隠すことができます。ただし画面がタッチされた際に、自動で表示状態に戻ります。
タッチしただけですぐ元に戻ってしまうので使いどころが難しいですが、例えば動画を流す場面ではユーザー側からの操作があまり行われないため、画面領域を広く活用することができそうです。
なお引数として与える『SYSTEM_UI_FLAG_HIDE_NAVIGATION』はAPI14(Android4.0)からの新機能ですので、Manifestファイルのandroid:targetSdkVersionは14以上を指定しておきましょう。

続いてシステムバーを見えにくくする方法ですが、上の方法とほとんど変わりません。変わるのはsetSystemUiVisibilityメソッドに与える引数だけで、


View view = (View)findViewById(R.id.relativeLayout);
view.setSystemUiVisibility(View.SYSTEM_UI_FLAG_LOW_PROFILE);

と、『SYSTEM_UI_FLAG_LOW_PROFILE』を引数にして呼び出します。

システムバーを見えにくくする

するとこのように、システムバーが(正確にいえばシステムバー上のボタンが)薄っすらと白い点になって、見えにくい状態となります。
こちらはアプリの画面をタッチしても元には戻らないので、例えばゲームアプリでユーザーを画面に集中させたい時に効果を発揮しそうですね。
『SYSTEM_UI_FLAG_LOW_PROFILE』については、先述の『SYSTEM_UI_FLAG_HIDE_NAVIGATION』と同様にAPI14(Android4.0)以上が推奨となります。

なおAndroidスマートフォンのナビゲーションバーについても、これらの方法で隠したり見にくくしたりできます。
タブレットを操作する上でなくてはならないけれど、時には邪魔にもなってしまうシステムバー。より使い心地のいいアプリを目指す際には、これらの方法で操作ユーザーの集中力を妨げないよう配慮してみるのも、大切かもしれませんね。

2013年8月20日 | カテゴリー : Android開発 | 投稿者 : youchin

問題事例(3): カスタムフォントの設定方法

カスタムフォントの設定でハマりにハマりました。ようやく原因を特定できたので備忘録としてまとめておきます。
カスタムフォントをテキストビューなどに設定する常套手段として、広くサンプルが公開されているのは、assetsフォルダに配置したttfファイルをTypefaceで読み込む方法かと思います。

———-サンプルコード———-

TextView text = (TextView)findViewById(R.id.textView);
text.setTypeface(Typeface.createFromAsset(getAssets(), "sample.ttf"));

—————————————-

sample.ttfがプロジェクトのassetsフォルダに置かれていれば、これでテキストビューのフォントを変更できます。ボタンなどのフォントについても同様の操作で変更が可能です。
Androidデフォルトのフォントは正直あんまりカッコよくないので、これで綺麗なフォントに変更してみよう! ……と、あの頃の私は思っていたのですが。
そこで立ち塞がったのが原因不明の強制終了。悩みに悩みやっとのことで原因を特定してみれば、このコードにはなにやら重大なバグが潜んでいるようです。
確かにこのコードで、フォントの変更自体はできます。ですがどうやら、Typeface.createFromAssets()によるフォントの参照が、バグでGC(ガベージコレクション)の対象になっていないようなのです。つまり、この方法でフォントを変更すればするだけ、メモリが次々と潰されていってしまうのですね。
強制終了の原因は、これによるメモリリークと思われます。コードのミスならまだしも、OSのバグが原因だったなんて、道理でハマるわけです。
一応、フォントファイルをSDカード上からTypeface.createFromFile()で読み込むなどの対処法があるようですが……それは後々考えるとして、ひとまず、カスタムフォントの使用は見送りとなりました。(フォントの変更が絶対に必要、というわけでもなかったので……)

ちなみに、今回の方法でフォントの変更を多く行った場合、メモリの問題もそうですが、アクティビティを切り替える際にも時間がかかるようになってしまった、といった悪影響もありました。
教訓として、楽な方法が必ずしも最適とは限らないのだと、そんなことを学んだ一件でした。

2013年6月28日 | カテゴリー : Android開発 | 投稿者 : youchin

問題事例(2): android:nameのパスは絶対か相対か?

先日Androidの学習をしていた際に、見事にハマって苦労した箇所があったので、備忘録として掲載しておこうと思います。
引っ掛かったのは、Fragment機能を実装する場合の、android:nameの記述方法でした。
以下、サンプルです。

———-main.xml———-

<LinearLayout
   xmlns:android="http://schemas.android.com/apk/res/android"
   xmlns:tools="http://schemas.android.com/tools"
   android:id="@+id/LinearLayout1
   android:layout_width="match_parent"
   android:layout_height="match_parent"
   android:orientation="horizontal"
   tools:context=".MainActivity" >

   <fragment
      android:name=".FragmentA"
      android:id="@+id/fragmentA"
      android:layout_width="wrap_content"
      android:layout_height="match_parent"
      android:layout_weight="1" />

   <FrameLayout
      android:name=".FragmentB"
      android:id="@+id/fragmentB"
      android:layout_width="wrap_content"
      android:layout_height="match_parent"
      android:layout_weight="1" />

</LinearLayout>

——————————-

内容は至ってシンプル、画面を二分割して左と右とで別々の内容を表示する、というもの。これの他にMainActivity.java等必要なファイルを揃えてテストしてみると、しかし起動していきなり、エラーで強制終了してしまいました。んんっ?
しばらく悩んでようやく解決してみれば、前述の通りandroid:nameの記述方法に不備があったようです。具体的には、

android:name=”.FragmentA”
android:name=”.FragmentB”

この二箇所。ここは相対表記ではなく、パッケージ名も含めた絶対表記(完全修飾クラス名)で指定しなければいけないみたいです。つまり、

android:name=”jp.co.transsoft.sample.FragmentA”
android:name=”jp.co.transsoft.sample.FragmentB”

こんな具合で書く必要があるみたいです。なるほど、確かに参考書の方は絶対表記で書かれています。
ではなぜ参考書で絶対表記になっているところをわざわざ相対表記で書いたのかという話ですが(笑)、それはManifestファイルでアクティビティコンポーネントを記述する時(<activity>タグを使って書く部分)は、android:nameを相対表記で書いても問題が起こらなかったからです。

———-Manifestファイルのサンプル(一部)———-

<application
   android:label="@string/app_name"
   android:theme="@style/AppTheme" >
   <activity
      android:name=".MainActivity"
      android:label="@string/app_name" >
   </activity>
</application>

———————————————————-

こんな具合で。
なので、Manifestファイルの方でできたんだから、こっちでもできるんじゃないか? とつい思ってしまったわけですね;
ところでこの記事を書くにあたって、もう一度Fragmentのプログラムを実行し直して確認してみたのですが、なぜか相対表記でもAVDで実行できてしまいました。今までできなかったはずなのに、どうして今になって……^^;
しかし実機テストではあいかわらず強制終了だったので、やはり相対表記は使わない方が無難なようです。
なぜManifestファイルで相対表記が可で、こちらでは不可なのか、原因の特定までは至っていないので引き続き調べる必要がありそうですが。
とりあえず、android:nameはパッケージ名込みの絶対表記で指定しておくようにすればハマる確率はグッと減らせそうなので、これからは絶対表記で書いていこう、と思った今日この頃でした。

2013年6月10日 | カテゴリー : Android開発 | 投稿者 : youchin

問題事例(1):AndroidManifest.xmlでActivity記述は大事

実機上で試験実行した際に「Unable to open stack trace file ‘/data/anr/traces.txt’: Permission denied」というエラーメッセージが発生しました。

この問題を解決するために、Web上に存在する有識者方々の情報から、何とか参考情報を取得しようと検索してみると「traces.txtへの書き込み権限が無いことが理由」「該当フォルダに書き込み権限を付与してみては」という情報が大半であった。

しかし、解決方法は「本当に些細で初歩的な内容」となっていました。

本カテゴリの第1記事として掲載するには、とてもお恥ずかしい内容ですが、もし他の方が同様の問題で悩まれていた際にお手伝いできるのではないかと考え掲載させていただきます。

■試験実行したアプリ仕様(記載に必要な箇所のみ記載)

第1画面のボタンをタップすると、第2画面へ画面遷移する。

こちらが、第1画面です。

「次の画面へ進みます」を選択すると、第2画面へ遷移します。

 

 

 

 

 

そして、第2画面です。

 

 

 

 

 

 

■試験実行したときのエラー画面(AVD画面)

以下のエラー画面が表示される。

 

 

 

 

 

 

 

そして、Eclipse上には以下のエラー情報が表示される。

(1)実機上で、エラー発生した際のエラー情報

表示されたメッセージは「Unable to open stack trace file ‘/data/anr/traces.txt’: Permission denied」

 

(2)AVD上で、エラー発生した際のエラー情報

表示されたメッセージは「Wrote stack trace to ‘/data/anr/traces.txt’」

 

 

■問題原因と解決方法

原因は、AndroidManifest.xmlに、第2画面の<activity>タグの記載がされていないことであった。

下図のように、AndroidManifest.xmlに、第2画面の<activity>タグを追加記載したところ、正常に第2画面への画面遷移が行われるようになった。

 

 

 

 

 

-以上-

 

 

2013年6月8日 | カテゴリー : Android開発 | 投稿者 : sanobo