アプリ開発日記 #188 リジェクトされた原因の修正

新しく作るアプリ

いつも期限前日に焦ってしまう人のためのスケジュール管理アプリを作ろうと考えています。

今日の作業

ある程度完成したので、iOS版をいったん審査に出していました。
そして、何度かのやり取りのすえ、みごとリジェクトされました。

リジェクト原因ですが、致命的なバグがあったことが原因となります。
簡単に言うと、ある捜査を行った際にアプリが落ちてしまっていました。

そして、アプリが落ちた原因も簡単で、既に修正を終えて後は再審査に出すだけとなります。
また、バグの修正と同時に画面レイアウトで気になっていた箇所についても修正を行いました。

これで、修正が完了したため、再審査に出してしまおうと思います。

特に意味はないけれど、クリスマスっぽいもの

クリスマスステッカー クリスマス 飾り オーナメント クリスマスデザイン ウォー ルステッカー 静電ステッカー christmas decoration クリスマス サンタ トナカイ シール おしゃれ 窓ステッカー 170PCS

AMIR LED キャンドルライト LEDキャンドル ろうそく 癒しの灯り 揺らぐ炎 リアル感 火を使わない 安全 省エネ 長持ち 便利 おしゃれ クリスマス 結婚式 誕生日 室内 室外飾り インテリアライト (12個セット)

クリスマスツリー 卓上 60cm ミニツリー クリスマス飾り LEDイルミネーション 22点セット おしゃれ キラキラ 雰囲気満々 暖かい 組立簡単 収納便利 飾り 部屋 商店 おもちゃ プレゼント

アプリ開発日記 #187 動かしながらバグ探し

新しく作るアプリ

いつも期限前日に焦ってしまう人のためのスケジュール管理アプリを作ろうと考えています。

今日の作業

動作のおかしなところや、画面の表示のテストを行いました。

テストといってもモンキーテスト的な感じで、アプリに適当に値を入力しながら動かすようなテストをしました。
本当は、テストケースを作成して、過不足なくプログラムの検証ができるといいのですが、UnitTestでモデルの部分をある程度確認しているため、とりあえず動かしてみて大丈夫そうか確認しています。

そして、動作のおかしいところが見つかった場合は、正しく動くように修正を行っています。

とりあえず、このままリリースしても一応問題なく動きそうなレベルにはなってきました。
ただ、モンキーテストのみだと十分テストができたかわからないため、簡単なテストケースは作ったほうがいいとは思っています。

本当なら単体テストとして、ホワイトボックステストとブラックボックステストをやって、結合テストをやって、、、なんだよな。

はじめて学ぶソフトウェアのテスト技法

ソフトウェアテスト293の鉄則

マンガでわかるソフトウェアテスト入門 テスターちゃん Vol.1

明日以降の作業

アプリのテストなど

アプリ開発日記 #186 ひとまず実装完了

新しく作るアプリ

いつも期限前日に焦ってしまう人のためのスケジュール管理アプリを作ろうと考えています。

今日の作業

バグの修正と追加機能の実装が完了しました。
まだ実装したい機能もありますが、いったん保留とします。
これで実装はひとまず完了となります。

あとは、テストをして、審査の提出の準備をするだけとなります。

あと少しです。

ただ、Android版については、実機を手に入れられていないため、課金のテストができない状態です。
そのため、テスト用にAndroid端末を手に入れる必要があります。

そんなわけで、テスト用端末は、どれにしようかな？

HUAWEI MediaPad M5 lite 8 タブレット 8.0インチ Wi-Fiモデル RAM4GB/ROM64GB シャンパンゴールド 【日本正規代理店品】

Lenovo タブレット Wi-fiモデル Tab M8(8.0型WUXGA Helio P22T Tab 4GBメモリ 64GB)

NEC LAVIE Tab E TE708/KAS - 8型タブレットパソコン[メモリ 4GB / ストレージ 64GB] PC-TE708KAS

エイスース 8型タブレットパソコン ZenPad 8.0 Wi-Fiモデル （ブラック） Z380M-BK16

明日以降の作業

アプリのテストなど

アプリ開発日記 #185 バグ修正と仕様変更

新しく作るアプリ

いつも期限前日に焦ってしまう人のためのスケジュール管理アプリを作ろうと考えています。

今日の作業

見つかったバグの修正を淡々と行っておりました。
そして、設計時に十分に検討できていなかった箇所について、仕様の変更と実装を行いました。

仕様の変更については、以下の理由から、それほど多くの時間をかけずに修正ができました。

1. もともと作成していた処理の再利用ができた
2. 修正箇所が限定的であった
3. 修正による他機能への影響がほとんどなかった

仕様変更が比較的容易だったことを考えると、今回のDDDを取り入れた設計はそれほど悪くなかったように感じます。
しかし、仕様の抜け漏れがあったことから、機能設計は不十分であったようです。

今回は、DDDを取り入れることを優先しており、機能設計が不十分であったことは想定していました。
そのため、修正が容易であったことで十分な成果があったように思います。

明日以降の作業

バグ修正、機能追加等の実施

そろそろクラウドとかも学ばないとなー

改訂新版　Vue.jsとFirebaseで作るミニWebサービス (技術の泉シリーズ（NextPublishing）)

Azure Functions入門

Docker/Kubernetes 実践コンテナ開発入門

AWS Lambda実践ガイド (impress top gear)

アプリ開発日記 #184 動作がいまいちなところを直していく

新しく作るアプリ

いつも期限前日に焦ってしまう人のためのスケジュール管理アプリを作ろうと考えています。

今日の作業

課金機能について、iOS版のみですが、課金アイテムの取得および、sandboxでの課金の実行が成功しました。
まだ、Android版については動作の確認をしていませんが、課金機能は一段落しました。

そのため、次の作業として、アプリの実装中に気付いた動作がいまいちな箇所や、アプリのバグの修正を行うこととしました。

とりあえず、まずは簡単に治せるバグを一通り修正しました。
また、バージョン情報やライセンス情報を表示する画面の作成や、画面遷移の見直しなど機能の修正も行っています。

動かしてみていまいちな機能の修正については、何も考えずに修正すると改悪となることがあるため、もう一度設計を考えながら慎重に修正を行っています。

明日以降の作業

バグ修正、機能追加等の実施

そろそろクラウドとかも学ばないとなー

改訂新版　Vue.jsとFirebaseで作るミニWebサービス (技術の泉シリーズ（NextPublishing）)

Azure Functions入門

Docker/Kubernetes 実践コンテナ開発入門

AWS Lambda実践ガイド (impress top gear)

アプリ開発日記 #183 課金の検証機能のアプリ側の実装

新しく作るアプリ

いつも期限前日に焦ってしまう人のためのスケジュール管理アプリを作ろうと考えています。

今日の作業

今回作成のアプリでは、アプリ内課金の実装を予定しています。

そして、アプリ内課金について調べたところサーバーでの検証が必要なことがわかりました。
そのため、アプリ側からサーバーへ課金の検証を依頼し、サーバー側で課金の検証を行う機能を追加することになりました。

アプリ側では、以下の機能の実装が必要なようです。

1. 課金処理
2. 課金処理後に発行されたレシートのアプリ内への保存
3. サーバーの検証処理の呼び出し

また、確実にレシートの検証ができるように検証処理を実装する必要があるようでした。
そして、今日はとりあえず、アプリ側の課金処理とレシートのアプリ内への保存の実装ができました。

明日以降の作業

課金処理のサーバー側の実装

そろそろクラウドとかも学ばないとなー

改訂新版　Vue.jsとFirebaseで作るミニWebサービス (技術の泉シリーズ（NextPublishing）)

Azure Functions入門

Docker/Kubernetes 実践コンテナ開発入門

AWS Lambda実践ガイド (impress top gear)

アプリ開発日記 #182 だいぶ完成に近づいた

新しく作るアプリ

いつも期限前日に焦ってしまう人のためのスケジュール管理アプリを作ろうと考えています。

今日の作業

iOS版でデバッグすると途中で画面がフリーズしてしまうバグが発生していました。

Visual Studioのコンソールを見るとSQLiteのエラーが出ていたため、最初はSQLite関連のバグかと思っていました。
しかし、いろいろと調べていくうちに非同期処理の書き方が悪そうだということに気付きました。

そして、1か所だけ非同期処理の書き方を修正したところ、修正箇所が無事動くようになりました。。

そのため、async/awaitの処理をすべて書き直すことになりました。
とりあえず、以下のような書き方をしたらいけないことが分かったのでよかったということにします。

public async Task Sample()
{
    // 変数でTaskを受け取って、あとでawaitしても意味ないっぽい
    var a = Task.Run(() => {何らかの処理};
   await a;

    // awaitとTask.Resultは一緒に使ったらだめ
    // awaitとTask.Resultの両方で待機処理が実行されるらしい
    var returnVal = a.Result();
}

そして、下記のような書き方にしたことで、無事iOS版でもアプリが動くようになりました。

public async Task Sample()
{
    // Taskの戻り値がない場合
    await  Task.Run(() => {何らかの処理};

    // Taskの戻り値がある場合(変数aにTaskの戻り値が入る)
    var a = await  Task.Run(() => {何らかの処理};
}

ほかにも、画面の見た目の修正や、ダークモード対応などを進めました。
そして、アプリもだいぶ完成形に近づいてきました。

さらに、自分が全くasync/awaitを理解できていないことがわかりました。
ちゃんと勉強しなきゃな。。。

C#で非同期プログラミングをする方法: Thread，ThreadPoolからTask，async awaitまでを分かりやすく解説

C#によるマルチコアのための非同期/並列処理プログラミング

明日以降の作業

課金処理の実装

今後の課題

<<大量の設計書がなくても、過不足なく使用を説明できるようにしたい>>

アプリが複雑になると設計書の量が増えてしまいます。
しかし、すべての設計書の整合性を取りながら、アプリを修正することは結構大変だと思います。

今回も、複数の設計書の間で不整合が起きていたことで、バグを作りこむところでした。

そのため、仕様を説明するためのドキュメントについて、もっといい感じでまとめられるようにしたいです。<>
アプリケーションサービスや、ドメインモデル、ドメインサービスのそれぞれの役割を明確に定義できていなかった、そして十分に理解できていなかったため、実装時に実装するレイヤーが違うものがいくつか表れてしまいました。

そのため、改めてアプリケーションサービスや、ドメインモデル、ドメインサービスのそれぞれの役割を明確に定義できるようにしたいと思います。