読者です 読者をやめる 読者になる 読者になる

もっとラクにできたのに

アプリケーションを開発する過程で、作った後になってから「もっとラクにできたのに」という点を書き記していく所 魅了屋という零細デベロッパーが書くよ


↑広告

楽をしたい とにかく楽をしたい

楽に複数OSに対応したアプリを作りたい

 

究極の楽といえば「誰かに丸投げ」or「宝くじ当てる」の二つである事は明白であるが、これを言った所で叶える人脈も運も無い、素敵な物は欲しいけどあんまり売って無いから好きな歌を歌う、という訳にも行かないのが現状である。皆様如何お過ごしだろうか。

アプリも作らずに調査をしていたここ数週間だった。具体的には、一つのプログラミング言語で複数OSに対応したアプリを作る為に何が必要かを調査していた。そこで今回はその調査の結果を報告したいと思う。

 

複数のOSに対応するために必要な事 

異なるOS上で同じ物を動かすプログラムの事を「クロスプラットフォーム」と言うらしい。このクロスプラットフォームを実現する為には何を使えば良いのかを挙げていく。

 

Unity

2D/3Dゲームエンジンである。iOSAndroid、パソコンOSのアプリを書き出す事が出来る。Unityアプリという物があり、個人であれば無料で利用する事が出来る。言語はC#を利用する。

 

Xamarin

Microsoftに買収された企業が開発した.NET環境である。iOSAndroidUNIX系のパソコンOSのアプリを書き出す事が出来る。Macでは「Xamarin Studio」を、Windowsでは「VisualStudio」というアプリを利用する。こちらも条件があるが、個人であれば無料で利用する事が出来る。こちらも言語はC#を利用する。

 

Multi-OS EngineMOE

Intelが考えたクロスプラットフォームのライブラリである。iOSAndroidといったモバイル系OSのアプリを書き出す事が出来る。AndroidStudioプラグインをインストールして利用する。言語はJAVAまたはKotlinを利用する。

 

Scade(まだベータ版)

彗星のごとく表れた(と自分では思っている)開発環境である。iOSAndroidといったモバイル系OSのアプリを書き出す事が出来る。Scadeというアプリをインストールして利用する。言語は何とSwiftを利用する。

 

クロスプラットフォームを実現する為には4つの方法を取る事が出来る事が分かった。

 

じゃあ実際に何を使うの?

ではどれを採用するのか?ここで自分のスキルを整理してみようと思う。

 

C言語:やった事ある 最初に触った言語

Swift:やったことあるしアプリも出した 

JAVA:やった事あるけどコードを見ると殺意が沸く 苦手 

Kotlin:本を読んだ程度 Swiftに近いと言うのは知ってる

C#Unityやった時に本当にちょっとだけ触った

 

そして前項で挙げたクロスプラットフォームを表に整理してみるとこうなる。

 

f:id:waspossible:20170326104034p:plain

 

Multi-OS Engineは使うにはちょっとリスクがデカイ気がする。ScadeSwiftを使えるのは利点だが、ベータ版である事と日本語資料が全く無いのがちょっと厳しい。残るはUnityXamarinの二つなる。ゲームはUnity、その他のアプリはXamarinとするのが良いと思う。日本語資料も沢山ある。しかし、C#をほとんど扱った事が無い事が足枷になるのは間違いないだろう。うーん・・・。

 

決めた!!

ゲームUnity、ツールアプリXamarinで作成、C#は本を見ながら勉強すれば良いという結論にした!!というのも理由がある。こんな資料が発売されたからである。  

 

 ↑本の画像が何故か出ません。すみません。↑

Xamarinエキスパート養成読本 (Software Design plus)

Xamarinエキスパート養成読本 (Software Design plus)

 

 

かずきのXamarin.Forms入門

かずきのXamarin.Forms入門

 

 

養成講座の方は発売日に手に入らなかったので詳細は見ていないが、日本語資料として本があるのは非常に有り難いし、家の最寄り駅の本屋にピンポイントで置いてあったのは運命だと感じたので、C#も使える様にすれば、モバイルOSだけでなく、パソコン用のOS対応にも活きると思ったのだ。try!Swiftに参加したのだから、Scadeを取ると思った貴方、残念!実は長い長いインストールと設定作業を乗り越えて使ってみたのだが、何故か一部強制終了になってシミュレータが動かなかったりするので、安定化するまではちと怖いなと感じたのだ。でも期待はしているので是非とも成功して欲しいと思っているのは本当である。

 

長々と書いたが、同じく楽をしてマルチプラットフォーム対応したという方の参考になれば幸いである。販路広げてみんなで売れようぜ!!

try! Swift Tokyo 2017に参加した話

家に帰るまでがイベントじゃなかった

 

というわけで、過去のBlogにも書いた通り、売った株の利益でtry! Swift Tokyo2017に参加した話をしようと思う。過去の話はこちらを参考にしてくれ。

 

moreeasily.hatenablog.com

 

try!Swiftとは

www.tryswift.co

まぁこういったイベントがありまして、具体的にはスペシャリストと公募による方による、Swiftに関連する(とも限らないが)プレゼンを聴いたり、他の参加者とコミュニケーションを取ったりするというのが目的のイベントである。

 

しかし、そのプレゼンについての考察や感想、実践してみた検証などは他の方のBlogを検索して読んだ方がためになるし、深い部分に関する考察という点では自分は他の人に比べ劣ってしまうので、今回は別の視点、特に食べ物飲み物からtry!Swiftというイベントをレポートしてみようと思う。

 

朝食の話

朝食としてバームクーヘン二種(プレーンとチョコ)、クッキー、あんこの入ったパイがそれぞれ用意されていた。ここでの人気はクッキーとパイだった。バームクーヘンはまだ余裕があった。私は初日はチョコのバームクーヘン、二日目はクッキーとアンコパイを食べずに持ち帰った。三日目はクッキーが昼でも余っていたので頂いた。おいしかったし、コーヒーと合わせて食べたいなという味だった。というわけで次はコーヒーの話。

 

コーヒーの話

会場には大量のコーヒーが用意されていた。20リットル入るサーバーが10個くらい並んでいたと思う。初日の朝に来て、イベント開始30分前には幾つかのサーバのコーヒーが空になっていた。ちなみに二日目も同じ量のコーヒーが用意されていたが、午後4時くらいには完全に無くなり、主催が「コーヒー無くなりました。すみません。」と謝罪する事態にもなった。その上、企業ブースでもコーヒーが用意されていた。中でもLINEのブースではコーヒーがくじ付きであり、当たりを引くとモバイルバッテリーがプレゼントされる。speeeでは担当者のオリジナルブレンドが飲める。それもその場で豆を挽いてドリップしてくれるから、酸化していないコーヒーが飲めた。私も頂いたが、おいしかった。というかみんなコーヒー飲み過ぎだろ。そんなにカフェインが欲しいか。

 

お弁当の話

今回のイベントではプレゼンを聴く日が二日間あり、三日目はハッカソンorワークショップという形になっていた。全ての日で昼食はお弁当があった。10種類くらい用意されており、ベジタリアン向けのお弁当も用意されているという準備の良さだった。ここでは鶏めし弁当の人気について書きたい。とにかく鶏めし弁当が人気なのだ。この三日間、お弁当でいの一番に無くなったのが鶏めし弁当である。何故か分からない。trySwiftTokyo2017のキャラクターがヒヨコだから、鶏を食べるのはちょっと罪悪感があるかもしれない。と一瞬思ったのだが、そんな事はおかまいなしで大人気である。キャラクターと人間の食の好みは別である事が分かった。あと二日目、三日目とお弁当が余る事態が発生していた。主催は「もう一個食べたい人は食べていいよ」とアナウンスをしていた。さすがにこれは持ち帰る気にはなれなかった。もったいない話ではあるが、足りないより余らせた方が良いと考えるのは我々のエゴなのかも知れない。ちなみに私は初日炊き込みご飯弁当、二日目洋風幕の内弁当、三日目に念願の鶏めし弁当を頂いた。おいしかったです。

 

飲み物の話

お弁当にはお茶がやはり合うだろう。昔シリコンバレーでは「お〜いお茶」が流行っていると言うのを聞いた事がある。数年前の話である。その流れを引き継いでいるかは分からないが、このカンファレンスでもお〜いお茶が大量に用意されていた。あと水も用意されていたが、お〜いお茶の1/10くらいの量だった。各日終了時にはキレイに無くなっていた。あと三日目の会場にある、数字が揃うと当たりでもう一本貰えるタイプの自動販売機で当たりを引いた。ピーチティーありがとうございます。

 

その他の食べ物の話

oisix社からは野菜ジュースが提供された。飲んでみるとストレートに野菜の果汁だというのがわかる。カボチャとトマトの甘さをベースに、葉物野菜の味がダイレクトに伝わってくる。市販の野菜ジュースが如何に果物の味で野菜の味を包んでいるのかがよく分かった。firebase社はのブースでは、ホットソース(辛いヤツ)を配っていた。欲しかったが、何をすればくれるのか分からず、貰えず仕舞いだった。後でTwitterを見てみると、普通に「ホットソースくれ!」と言えば貰えたらしい。リクルートマーケティングパートナーズ社ではオリジナルパッケージのブラックサンダーを配っていた。他社のブースでも何か食べ物を配っていたのかもしれないが、私の目には入らなかったので紹介出来ない。許して欲しい。

 

懇親会の話

懇親会はビュッフェ形式で、様々な料理が出ていた。私は参加していない。事前にアナウンスで「荷物をコインロッカーに預けてくるように」と言われていたのだが、コインロッカーが見つからず、参加するのを断念した。電車に乗って移動してしまったのがいけなかったようだ。歩いていけば道中に大きなコインロッカーがあったらしい。まぁこれは仕方がないな。荷物は手持ち鞄だけだったが、みんなが持ち込んでそこら辺に放置してしまうと、歓談スペースが無くなってしまうので、ここは自重する事にした。

 

おわりに

try!Swiftのような、プログラミング言語がっつりのカンファレンスには初めて参加した。プレゼンの内容を実践するには、まだまだレベルが足りないなというのがはっきり分かったが、貴重な体験だったし、会場の熱気を感じるだけでも良かったのかなと思った。登壇する事は無いと思うが、少しでも他の方の役に立てられる様、レベルアップして情報を伝えていきたいなと思った。また来年参加するかは、関東で開催してくれて、日本語訳があり、チケット代が払えるかが鍵になるので、どうかそこの所よろしくお願いいたします(切実だしチケット代はお前が頑張れ)。

 

おわり

また最近の出来事を書いてお茶を濁す

時代の移り変わりは意外と早い

moreeasily.hatenablog.com

 ↑この記事で取り上げたスマ検、サービスが終了するとの事。取り上げて一ヶ月くらいでサービス終了のメールが来た。わしゃ死神か。

 

十日ほどこのBlogを書いてなかったので、また近況を書いてお茶を濁そうと思う。と言っても技術的な事も書くかも知れない。いや、書かないかも知れない。書いている段階では分からないので時間があれば読んでいってくれ。

 

アプリ開発的には、過去に途中まで作って放置していた物に、再び手を付けようと思った。まず、Swift2からSwift3へのコンバートをXcodeが行った。Xcodeでコンバートしきれない所を、Xcodeの言うがまま直した。プロジェクト的にエラーは無くなった。しかし思った通りの動作をしない。おかしいなと思いながらコードを解析したり、端末固有の問題で正確な動作をしなかったりという問題をクリアし、何とか動く段階までたどり着いた。よかったよかった。と思っていた所にまた問題が浮上した。一つの関数の中に処理を全て書いているため、何がどうなっているかよく分からない。コードを書いた本人でさえも何故動いているのか分からないし、どういう仕組みなのか思い出せない。記憶を辿ろうと思っても、スカスカでシワの少ないであろう私の脳みそには記憶が残ってない。仕方ないので、ソースコードと言う名の暗号を解読する事にした。何となく動く仕組みは分かったが、解読出来た所で、仕組みが分かりにくいという事に変化は無い。そこでコードを書き直す計画を立てた。まず紙にフローチャートもどきを書いた。もどきと表現したのは、私がフローチャートの正確な書き方を思い出せず、正しい形式の物でないからだと考えての事である。次に拙い英語力とプログラミング能力をフル回転して関数名とその動きを定義する。定義した関数と動きは別の紙に書いてまとめた。A4紙二枚分にまとまった物を見て満足する。あとは書き直すだけだが、私には直す前のソースコードが大きな山があるように見えるのだ。とにかく大きな障壁に見える。ハリウッド映画風に表現すれば「そびえ立つクソ」である。直す前のソースコードに立ち向かう勇気が今は無い。「あ、別の用事があったんだー!」と言ってその場を後にするしか無かったのだ。

 

その別の用事というのが確定申告である。平成二八年度分は儲けたからでなく、損失を繰り越すために行うと言うのが悲しい所である。最初も書いたが時代の移り変わりは早い。今は青色申告のソフトを使って指示された通りに数字を入力すれば良いし、ネットの確定申告書作成コーナーでで指示された通りに数字を入力すれば申告書が出来上がってしまう。何なら税務署に行かず、家からも出ずに確定申告を終わらす事も可能である。私は楽な方楽な方へ水が低い所へ流れていくが如く進んでいく習性があるので、迷わず電子申請をすることにした。青色申告ソフトで前々から数字を入力していた(正確には連携ソフトから取り込んだ)事もあり、青色申告書の作成は順調に終わった。次に確定申告書作成コーナーで、青色申告ソフトで作ったデータを取り込んで、確定申告書を作れば終わりである。電子化万歳!e-Taxは良い文明!と思っていたが問題が発生する。確定申告書作成コーナーで読み込めるデータは拡張子が「.data」である。しかし青色申告ソフトで出力されたデータの拡張子は「.xtx」である。もちろん.xtxファイルを読み込んでも「拡張子が違う」と言われるのは当然である。何故だ。回避方法を探していると、e-TaxソフトWeb版と言うのがある事が分かった。ここでは.xtxファイルを扱うようだ。場所が間違っていたのか。こちらのミスだと思いつつ、操作をする。当然のように問題が発生する。今回の確定申告では、事業と株で赤字だったため、損失の繰り越しを証明する書類を作らなければならない。しかしここでは作れないし、青色申告ソフトも損失の繰り越しに関連する書類は対象外になっている。オーマイガーである。それにプラスして更に調べた結果、どうしても郵送するか、税務署に持って行かなければいけない書類がある事が分かった。それが損失の繰り越し書類である。この他にもICカードリーダーが上手く動かず、パソコンを再起動してから一回目しかICカードの情報を読み込まないという、脱出ゲームを解くようなトラブルにも見舞われた。結局どうしたか。確定申告書作成コーナーで、青色申告ソフトで作った書類の数字を見ながら、同じ物を作るために数字を入力すると言う写経作成で切り抜けた。良く調べなかった自分も悪いのだが、万歳であり良い文明の恩恵を100%受けられないのは、ここに書くネタを勝手に提供してくれているということなのだろうか。真実は分からないが、その真実は今一つである事は間違いなさそうだ。もっと言うとその後印刷しようと思ったら家のプリンタのインクが切れたり、お世話になっているコワーキングスペースにて有料で印刷してもらおうとしたら、項目の抜けが見つかったりと、まだまだ郵送出来るまで時間が掛かりそうな気配である。

 

と言うわけで平成二八年は大赤字が確定した。貯金も切り崩して貯金の底が見えてきている現状である。アプリ専業で生きていくと宣言したのにも関わらず、バイトの募集を見ていたら、家の近所らしき場所でマンション管理人の募集をしているのを見つけた。少し迷った末、応募した。早速メールで返事が来て、履歴書を送れとあったので、履歴書を印刷して郵送した。それも土曜日にだ。フットワークが軽い点を是非評価して頂きたい。住んでいる街に恩返しと言う点で、直接では無いかも知れないが、貢献出来ると思いたい。マンションに住んでいる方や、出入りする業者の方々が気持ちよく出入り出来るような環境を是非構築したいのだ。決して待機時間を使ってパソコンを持ち込んでアプリ開発をしようだなんて不埒な感情は持ち合わせていない。絶対にだ。でも仮に「好きな事してOKですよ〜」と、採用先の人事から言われてもリップサービスだなと思えるが、直属の上司から「いや、自由に何でもやっていて良いよ」と言われたらとても戸惑う未来が想像出来てしまう。その前に選考に勝ち残りなさいとか、アプリ開発しなさいとか突っ込まれそうなので、午後から何かしら手を動かします。

 

月曜日のお昼前 多分昼食はスムージーだけ

完結・ちょいとしたチャレンジをしてみたかったんだ

まだまだリジェクト攻撃は終わらない

moreeasily.hatenablog.com

 

知らせは朝の5時半くらいに来た。またリジェクトである。内容を見てみると、「iPad上で動かない」「IPv6で接続していると動かない」と書いてあった。IPv6はしょうがないとしよう。しかし、iPadで動かないというのは納得いかない。これはiPhone用だ。iPadで動かす事は想定してないのだ。

 

・嘆いていても仕方がない

とりあえずIPv6での検証方法を探した。ちょうど良い方法があったのでリンクを張っておく。

qiita.com

本当にこの記事は有り難かった。早速設定をして検証をしてみるが、動く。ちゃんと動く。広告周りも問題ないし、結果のTweetも出来る。IPv6は関係ないようだ。次に、iPad上でアプリを動かしてみる。結果、ゲームが出来ない事が分かった。正確にはボタンが押せなくて進める事も戻る事も出来ない。何故このような事になったのかが分からず、時間だけが過ぎていく。とりあえず気分転換ということで郵便局と銀行へ行く事にした。

 

・再びひらめく

用事を終え、そのまま帰るのも癪なので喫茶店でコーヒーを飲んでいた時にひらめいた。iPadの画面比率はiPhoneの3.5インチサイズと同じである。OS対応でiOS10が動かない機種は切り捨てている。つまりiPhone3.5インチは想定していなかった。しかしこれが間違いだった。iPhone3.5インチを切り捨てたとは言え、画面比率が同じなiPadでは、拡大モードでアプリが起動してしまう。つまり、iPhone3.5インチも想定しないと動かない。アプリの審査はiPadで行っているようなので、そこで動かないという結果になってしまったのでは無いか。そう仮説を立ててから、頼まれたタマゴを買って帰ったのだ。

 

・いざ調整

ここで必要なのは、AutoLayoutの調整である。正直やりたくない分野ではあるが、アプリのためである、リリースすると決めたのだから、最後までやり切るのである。調整しては、様々なiOSsimulatorで検証をする。ここを動かせば別の物がズレる、というのを4~5時間ほど繰り返す。途中怒りでペンが飛んだりしたが、何とか終わらせた(打ち切ったと言った方が正しいかも知れない)。遅くなってしまったが、アプリを審査に提出した。

 

・結局どうなったか?

メールを見ると、朝に審査が始まったと言う知らせが来ていた。朝食、準備、外出をし、コーヒーショップでコーヒーを飲んでいた時に知らせが来た。

 

Ready for Sale

 

無事に審査を通過して、AppStoreに並んだのだ。戦いは終わったのだ。最初はトータルで24時間以上掛けないと決めていたが、何だかんだあって50~60時間は掛かってしまった。何度もリジェクトを喰らい、諦めかけた事もあった。しかし、支えてくれたのは、賽の河原という名前のアプリが無く、誰も踏み込んでいない領域に足を踏み入れられるという特別感と、広告周り手続きをしてけた中の人の作業をしてくれた労力(実際はそんな難しい事では無いのかも知れないけど)があったからである。これが無ければ間違いなく諦めていただろう。本当に良かった。本当にやり遂げて良かった。そう心から思う。

 

・ここからが新たなスタート?

f:id:waspossible:20170203111117p:plain

というわけで配信開始です。「賽の河原」というゲーム。ある意味脱出ゲーム、ある意味クリックゲーム、その正体は名状しがたいゲームという物です。石を百段積上げてください。一個ずつ積上げるも良し、一気に積上げるも良しです。鬼に邪魔されて崩されないようにしてください。崩されたら最初からやり直しです。無事に救われるか、それとも諦めてしまうか、それはプレイヤーである貴方次第・・・。

 

賽の河原

賽の河原

  • Hiroyasu Hirai
  • ゲーム
  • 無料

 

続・ちょいとしたチャレンジをしてみたかったんだ

 リジェクトを喰らった

moreeasily.hatenablog.com

 

以前見事にリジェクトを喰らったこのアプリ。本来であればこれでお蔵入りのはずだった。しかし、広告の設定をしてくれた広告配信会社の中の人たちの労力の事を考えると、このままお蔵入りにするのは申し訳ないという気持ちが芽生えてきた。少しばかし考え、覚悟を決めた。

 

「やはりこのアプリをストアに配信しよう」

 

・変更点

と言ってもこのままでは審査を通過するわけがない。改良が必要だ。具体的には以下の点を改良した。

  •  積上ボタンを3種類用意。
  •  以前は百段積上げないとTweet出来なかったが、そうでなくても結果をTweetできるようにした
  •  積上げた石の総数をタイトル画面に表示させた

 

多少なりとも便利になったと思う。これでアプリを提出して審査を待とう。

 

・しかし次の日

f:id:waspossible:20170125161239p:plain

リジェクト、リジェクト、リジェクトである(写真は使い回し)。今回は役に立たないとか有用性が無いという理由では無い。リジェクト理由を読む(実際はGoogle翻訳に入れてから読む)と、機内モードで何かしら問題が発生したようだ。コワーキングスペースに出勤して更に原因を調査すると、機内モード時にアプリを起動し、一定の時間が経過するとアプリがクラッシュすると事が分かった。過去に作った物や、ネット検索を駆使して問題の原因を探るが、中々解決策が思い付かない。どうすればいいんだ。

 

・問題はひらめきで解決した。

 

「広告が悪さしてんじゃないの?」

 

具体的には、機内モード、つまりインターネットに接続されていない状態で広告のデーターを読み込もうとし、タイムアウトしてクラッシュするのではないかという仮説を組み立てた。ネット検索などを駆使し、インターネットに接続されていない状態では広告を読み込まないようにコードを書き換えた。すると、アプリはクラッシュしなくなった。ついでに、インターネットに接続されていない状態では、Tweetボタンを表示しないようにした。これも少し工夫をして実装した。結果は良好だった。

 

これで審査に出せる。早速審査提出を済ませた。結果を待つだけである。ちなみにだが、提出した後にまた不具合を見つけたが、ゲームには大きな影響が無いと判断して、次回のアップデート時に解決する事にしたのは別の話である。

 

2017/02/03追記

完結編、アップしました。こちらも良かったらどうぞ。

moreeasily.hatenablog.com

 

 

2017年01月30日(月)に調べた事

アプリ開発で躓いて、Google先生のお世話になった所をまとめていく。

 

・UserDefault

記憶の中では「NSUserDefault」だと思っていたが、Swift3で「UserDefault」に名前が変わっていた。Swift3になってから関数名の頭にある「NS」が無くなる物が多くなった印象である。

dev.classmethod.jp

ここが役に立った。ありがとう、ありがとう。

 

バイブレーションさせる

理想としては0.1秒だけバイブレーションさせたかったのだが、出来ないようだ。ちなみに、普通にバイブレーションをさせるには、AudioToolBoxをインポートした上で

 

AudioServicesPlaySystemSound(kSystemSoundID_Vibrate) 

 

と打ち込めば震える。会いたくても会いたくなくても震える。Timerと一緒に組み合わせると、○秒後にバイブレーションさせるといった事も可能である。理想を言えばキャリアメールとPCメールでバイブレーションの仕方が違うように、アプリを作る側でもバイブレーションの仕方が違う設定が出来れば、アプリの幅が広がる気がするのだが、そう簡単にAPIは開放してくれないようだ。

 

・画面遷移時に値を引き渡す

画面Aから画面Bに遷移する時に、値も一緒に連れてきてくれる方法を探した。自分が考えているアプリでは良く使う(はず)テクニックである。

qiita.com

ここが役に立った。ちなみにStoryBoard上でも設定が必要なので忘れないようにしたい。とか書いてあるといざ使う時になって忘れるんだろうなぁ。

 

リンクを張っただけで終わったのは、ソースコードの貼り付けが上手くいかなかったである。何故か言う通りにやっても上手くいかないのだ。Swift対応してない?

help.hatenablog.com

ちょいとしたチャレンジをしてみたかったんだ

ふと思い付いて一日でアプリが出来るか試してみた

今作っているアプリの進捗が良くない。具体的には、仕様変更をしなければならず、面倒臭いと言うオーラが身体を包んでいて離れない状況である。何となく別の事をしたいと思っていた1月20日の午前であった。そこで、気分転換も兼ねて、一日以内でアプリを完成させ、審査手続きまでステータスを進める事が出来るかやってみた。

 

まず企画

「賽の河原」という言葉を思い出した。幼くして亡くなった子供がひたすらに石を積む。目標の数まで積み上がると救われるのだが、あと少しの所で鬼に壊され、最初からやり直すというのを永遠と繰り返す、無駄な事の例えに良く使われる言葉である。これをテーマにして、石を積んでも積んでもリセットされるゲームアプリにした。

 

グラフィック

余りグラフィックにかける時間と技量が無いのと、あえて不気味さを出すために、文字だけで構成する事とした。アイコンも文字だけである。クオリティの高いアプリが全盛のこの時代には逆に目立つかも知れないが、それは実際にストアに並んでみないと分からない。

 

ゲームシステム

play.google.com

100万のタマゴというクリックゲームがあるが、これを参考にしてクリックすると石を積まれていき、あと少しの所でリセットされるという仕様にした。積む石の数は100に設定し、100個石を積めるとゲームクリアという目標も設定した。

 

プログラミング言語

言語はSwiftを使用し、対象OSはiOSのみとした。使用IDEXcodeAndroidはやった事ないので今回はiOSに一点集中トライという作戦を採用する。

 

画面構成

画面はタイトル画面、ゲーム画面、info画面の三画面で構成する。クリア回数やハイスコアは今回のバージョンでは採用せず、審査通ったら今後のアップデートをで対応する事にした。最初はUILabelとUIButtonの二つで画面を構成しようとしたが、AutoLayoutの調整に時間が掛かるため、タイトル画面などの一部はImageViewを利用し、画像を採用した。しかし画像と言っても手順はテキストエディタで文字打ってキャプチャしてはい出来上がりという方法なので、文字だけと言う世界観は崩れていない(誰も求めてないと思うけど)。

 

コーティング

石は数で表し、見た目はカウンタアプリの様にしようと思った。しかし、英数字で表示では能が無いと思ったので、漢数字で石の数を表示するようにした。仕組みは簡単で、数字の位ををそれぞれ10で割った数(10の位)と余りの数(1の位)をSwitch文で仕分け、それぞれ当てはまる漢数字をLabelで再結合して漢数字を表示させた。鬼に石の山を崩される仕組みは、一定の石の数からランダム関数で数字を呼び、ある条件に合致したら石を崩しリセットする。

 

仕上げ

iOSには、AndroidOS対応機種ほどでは無いにしても、幾つかの画面サイズがあり、それぞれに対応する必要がある。iOSの場合はまず大きな括りとしてiPhoneiPadというのがあるのだが、今回はiPhoneのみに対応させ、iPhoneの中でも4、4.7、5.5インチの画面に対応させる設定とした。相変わらずAutoLayoutの調整に手間取る。ここに半分近く時間を費やしたと思われる。イライラしながらも泣き言は言っていられない。とにかくゴールへ進むのだ。他にもスプラッシュ画面が出なかったりもしたのだが、色々と設定をいじっていたら表示されるようになった。

 

審査提出へ

1月20日の17時過ぎに一旦審査を出そうとしたのだが、すぐに表示の不具合に気付き修正を余儀なくされた。この日は18時までしか開発が出来なかったので、この日の審査提出は諦めた。次の日の午前から作業を再開した。相変わらずAutoLayoutの調整に難航したが、14時前に審査提出が出来た。1月20日10時から作業を開始し、同日18時に作業打ち切り、次の日の10時半から14時前まで作業をしたのでトータル12時間位で審査提出へ持ち込めた。

 

完成品 

f:id:waspossible:20170125160638p:plainf:id:waspossible:20170125160705p:plain

f:id:waspossible:20170125160746p:plain

この作業量であれば、半分から三分の二位の時間で仕上げなければいけないのかなと感じた。プログラミングで詰まった所は無かったが、AutoLayoutの調整や、細かい所が目に付いたら修正しないと気が済まず、先に進めない性格によって時間をロスしてしまった。この点は今後修正していかないと、規模が大きなアプリケーションの場合、より手順と時間の回り道をしてしまう事になる。中々難しいが、クリアしなければならない課題である。とにかく企画を立てて、数を作って慣れていくしかないんだろうなと思ったチャレンジだった。

 

その後

f:id:waspossible:20170125161239p:plain

審査落ちた。

この規模のアプリケーションが審査を通過したらそら他の人は怒りますよ。おそらく数年前なら通過する可能性もあったかもしれませんが、今は時代が違うし、クオリティやアプリの有用性が明確である事が求められるようになっていると思われる。ちなみにだが審査を待っている間、謎の高熱に浮かされ、医者に行って「インフルでは無いと思いますが一応検査しますね」と言われて検査をし、結果が出るまで1〜2分掛かる検査キットでわずか10秒でインフル陽性の反応が出てお互い気まずくなった経験をした。何となく審査側の「こんなアプリ審査させやがって、呪うぞ」という声が届いたのかも知れないし、そうでないかも知れない。

 

とにかく今言える事は、インフルを治して本命のアプリを早く作ろう。という当たり前の事を当たり前に言うしかないと言った所だろうか。

 

平熱になって二日目の16時半前