すべてはシンプルなアイデアから始まりました。
私たちの生活では、良いことも悪いこともありますが、それは問題ではありません。 私はいつもそのようなことを記録したかったので、後で自分がどこにいたのかを理解することができました。
メモ帳とペンは信頼できる方法ですが、それでも携帯する必要があり、書き留めることを忘れないでください。また、何かを書くのは物理的に難しいことが多いです。 しかし、私たちは常に携帯電話を持っているので、そのようなイベントを記録する機能を備えたウェブサイトを作成することが決定されました。
各イベントは何らかの形で説明できます。
これは、たとえば、イベントの「 タイプ 」の概念がどのように生まれたかです-あなたが競争に勝った、これは良いイベントです。
タイプには何らかの形でマークを付ける必要があるため、開発の初期にWebデザインに関する多くの文献を読みました。色を使用することが決定されました（心への影響について言及されているすべての場所）。
最初に、タイプは事前定義されていました-良い（緑）と悪い（赤）。 もちろん、2つのタイプは私たちの人生を記述するのに十分ではなく、他のタイプ-楽しみ、ストレス、問題などが現れ始めました。
問題
「問題」タイプの出現により、新しいビジョンが現れました。結局のところ、問題が現れ、しばらくの間、私たちの生活に影響を及ぼし、その後、それらは解決されます（ほとんどの場合）。 このイベントはその時点ではなく、間隔で発生することがわかりました！ これは、イベントにはそれ自体で期間を設定する機能が必要であることを意味します。
さらに、現在発生しているイベントは、すでに終了しているイベントよりも大きな影響を及ぼします。 これらすべてを1つの概念にまとめると、次のようになりました- イベントには開始日と終了日があり、イベントの種類には現在と過去のイベントの色が異なります （たとえば、現在の悪いイベントには明るい赤色を使用し、過去の悪いイベントには-色あせた）。
すべてが順調でしたが、新しいタイプが絶えず登場し、それらを手動で追加するのにうんざりしたとき、ユーザーは自分のタイプを追加し、それらの色を調整することができました。
この瞬間のどこかで、私はウェブサイトのアイデアを放棄することにしました
次の2つの理由がありました。
- オフラインでイベントを追加できるようにしたかった
- ウェブサイトを使用することは、それがどれほど適応されていても、モバイルからは不便です。
メモリーゴーレム
そこで、モバイルアプリケーション「Memory Golem」が誕生しました。 タイトルは特別な注目に値します。まず、「 イベント 」が「 思い出 」になりました。 第二に、ユダヤ人のおとぎ話の神話上の生き物のような「 ゴーレム 」という言葉は、これらの同じ記憶の一種の保護を暗示しています。
サーバーバックエンドは常にJavaで、特にSpringMVCでした。
1つの詳細（メモリを節約する方法）を除き、現在の機能はすべてアプリケーションに移行されました。 これからは、モバイルデバイスに完全にオフラインで保存されました。 つまり、アプリケーションは、すべての機能が利用可能な飛行機でも使用できます。
ただし、必要に応じて、ユーザーは登録してリモートサーバーにメモリを保存し、さらに（異なるOS上であっても）異なるデバイス間でこれらのメモリを同期できます。
モバイルプラットフォームにより、視野を広げることができました
最初の重要なステップは、アプリケーションをユーザーの状態に適応させることでした。 ポイントはこれです：
ユーザーが特定のタイプの「現在の」記憶を持っている場合、それらは定義により彼の人生に影響を与えます。 各タイプには、現在のメモリ用に個別の色があります。 そのため、どの色がユーザーの生活に影響を与えているかを、推移性によって一意に判断できます！
そして、それを決定できれば、それを表示できます。 これは私がやったことです-アプリケーションは、現在の記憶の中で最も人気のあるタイプの色に色を変える機会を得ました。
問題がありました
アプリケーションにはラベルがありますが、ラベルがアプリケーションの色と同じ色の場合はどうなりますか？ 答えは簡単です-碑文の色が変わるはずです。
この質問を詳細に検討した後、次の解決策を決定しました：ユーザーを色の数と混同しないように、可能なテキストの色は白黒のみであり、どちらを使用するかを決定するために、単純なロジックを使用しました-現在の色からのユークリッド距離が大きい色を選択しますアプリケーション。
ゴーレムに戻る
彼は守らなければなりません。 したがって、サードパーティの表示からメモリを保護する方法が必要です。 古典的な解決策は、アプリケーションで設定され、メモリのロック/ロック解除に使用されるパスワードコードです。
他のアプリケーションの同じ種類のソリューションとの唯一の違いは、アプリケーション全体ではなく、個々のメモリのみをブロックする機能です。 ロックされたメモリは、ロックを解除するまで表示または編集できませんが、それ以外の場合はアプリケーションを自由に使用できます。
さらなる統計が登場
何かを書き留める場合にのみ論理的です-そこにどれだけ書いたかを見たいかもしれません。 統計は簡単です：
- すべての記憶の量
- 現在のメモリの数
- 過去の思い出の数
メモリのタイプごとにグループ化されています。 これらはすべて見栄えの良い図に表示されますが、列->円形->放射状にも切り替えることができます。
この段階では、アプリケーションをリリースできるように思えました
しかし、偶然にも、私は周期表の3Dモデルと、それがどのように私に起こったのかを目撃しました-私は自宅で同じことをする必要があります。
私は仕事に取り掛かりましたが、1か月後には、アプリケーションはいわゆる「メモリーマトリックス」を自慢することができました。これは、ユーザーの回顧録リストの3Dモデルで、3つの形式で表示されます：Sphere、Spiral、Matrix。 これらのモデルは、メモリ上で直接ツイスト、移動、および編集できます。
最も難しかったのは、解析ジオメトリでさえなく、表示された記憶の数でした。 実際には量ではなく、モバイルデバイス向けであり、一度に130のみを表示することが初めて可能であったという事実（200以上のアプリケーションがすぐにクラッシュしました）が、最適化後、この数はほぼ4倍に増加しましたそして、512個の最後の思い出が表示されます。
ブランド変更
アプリケーションはほとんどリリースの準備ができていたので、アイコン、名前を見て、落ち込みました。 彼らがひどく悪いというわけではありませんが、アイコンは率直に言って安く（彼はインク空間でそれを塗りました）、名前は、まあ、少なくとも長すぎました。
アイコンから変更を開始しました。 友人は私が後者を選択するのを大いに助けてくれました。なぜなら、私は細部が大好きすぎたので、このようなものが欲しかったからです：
しかし彼は、ミニマリズムが現在流行していることに気づき、AppStoreのページを装飾するものを選択するのに役立ちました。
そして、アイコンの変更により、新しい名前が発明されました。
リリースが 拒否されました
AppStoreの公開プロセスについては、ハブ上に多数の記事がありますが、多くの人はそのプロセスが何であるかを知っていると思いますが、そうでない場合は簡単に説明します：iTunes Connectでアプリケーションを作成し、説明、スクリーンショットなどの情報を入力し、ビルドをアップロードして公開しますいわゆるレビュー。
最初のレビューに合格しませんでした
その理由はばかげているだけです。アプリケーションをダウンロードするだけではデータがなく、データに合わせて色が調整されるため、最初は白黒です。
Appleの担当者は、この結果をスクリーンショットと比較しました。スクリーンショットでは、わかりやすくするために、すでにメモリが埋められており、バグだと考え、アプリケーションをリダイレクトしました。
重要なレッスン
不快でしたが、UXを再確認することができました。 その結果、UIのほぼ全体をやり直し、初期データの初期化を追加し、多くのことを簡素化しました。 ですから、結果として、アプリケーションを改善しただけだと思います。 最終的に、たとえAppleの担当者がそれを理解できなかったとしても、一般ユーザーに期待されること
フィニッシュライン
UIのレビューと改訂に失敗した後、アプリケーションをリリースする準備が整いました。 プライバシーポリシーを追加し、美しいスクリーンショットを作成し、魅力的な説明を作成し、アプリケーションのWebサイトを作成し、かなり詳細な使用ガイドを追加し、万が一に備えてレビュアー向けに情報を更新したため、すべてを理解し、レビュー用の新しいビルドを埋めました。
アプリのステータス「***」が販売準備完了になりました
午前5時にAppleからそのようなメッセージを受け取り、信じられないほど幸せで、Test Flightですべてをすばやくチェックし、友人のためにプロモーションコードを生成し、アプリケーションを公開して、勉強に行きました。
この物語の教訓は何ですか？
いくつかの困難を経験した人のように、私は他の人がそれらを回避するのを助けたいです、私はこの道に着手する前に私が知りたいことです：
- 初回起動時のアプリケーションの動作が異なっていても、アプリケーションのインストール時にレビューアが見るものがスクリーンショットにあるものと一致することを確認してください。 それ以外の場合、redjectに実行できます。 大丈夫のようですが、沈殿物は残ります。 （別のオプションは、レビューの注記にすべての違いとその原因を記述することです）
- ユーザビリティテストは必須です。 開発が終わると、アプリケーションに慣れてしまい、ユーザーが概念を理解できないことを想像することすらできなくなります。特に、頭の中のアイデアが長い間進化してきたものになった場合
- ハイブリッドアプリケーションがjsを介してローカライズされている場合、これはAppStoreがそれについて知ることを意味しません。 Xcodeでローカライズを設定する必要があります（iTunes Connectでのローカライズを除く）、そうでない場合は私のように動作します-アプリケーションはロシア語のAppStoreでロシア語の名前を持ち、内部のすべてのテキストは正しくローカライズされています-デバイスにインストールされると、英語の名前を持つため、 Xcodeでローカライズを設定しなかったこと。 次のアップデートでこれを修正したいと思っています。
- iOSでハイブリッドアプリケーションをリリースする予定の場合-ポピーはどこにもありません。
- ブラウザーでハイブリッドアプリケーションをテストする機能は確かに便利ですが、最初の段階でしか役に立ちません。 ネイティブ機能で動作するプラグインを接続した後、すべてのテストは必ずデバイスまたはシミュレーターで実行する必要があります。
参照資料
アプリケーションの構築に実際に役立ったオープンライブラリ（これらの要素がswiftにあるのではないかとさえ思います）