iOSアプリケーションの開発の歴史。 主に熊手について

Habréにはすでにそのような話がたくさんあることを理解しています。 しかし、それぞれの物語は独特であり、誰かのインスピレーションのほんの一部です。 この記事では、iOS用のアプリケーションをどのように作成したか、どのようなレーキを踏んだか、今後のプロジェクトでどのように変更するかについて説明します。



アイデア



基本の基礎はアイデアです。 最後に何をすべきかの明確な考えなしに何かを実現することは困難です。 そして、私はそのような考えを持っていました。 私はいつも自分の人生の量的指標に興味を持っていました。 さらに、テクノロジーを測定するのが単に不可能なのは、まさにこれらの基準です。 それらは主観的であり、私たちの感覚によって評価されます。 このアイデアは、そのような主観的なアイデアで正確に過去の日を評価できるアプリケーションを作成するために生まれました。 また、目標に向けての進捗状況を記録するのにも役立っていればいいと思います。



アイデアの説明



アイデア自体はもちろん非常に優れています。 しかし、彼女は物質的な化身に達するまでは何もありません。 そして、このパスに沿った最初のステップはその説明です。 将来のアプリケーションの最初の説明、最初のTKのドラフト、インターフェイスの最初のドラフトを作成します。 ここで最大の間違いを犯しました。 それについては、同様の各記事に記載されており、すべて同じです。 アプリケーション全体が頭の中にあるように思えます。すべての画面、すべてのアクションを想像できますが、後で判明したように、これでは十分ではありません。 作業の過程で、多くのニュアンスがあり、何らかの理由で頭には見えなかった些細なことがあり、まさに開発時間の大部分を占めるのはそれらです。 私は次のプロジェクトにもっと徹底的に取り組みました。そのための参照条件には、トランジションの説明、プレスへの反応、アニメーションなどが含まれています。 つまり、アイデア内のすべての白い斑点を可能な限り排除する必要があります。 ユースケースの最大数を提供します。 これにより、開発の次の段階での作業が大幅に加速されます。



開発



何もできないと思ってはいけません。 残念ながら、そうではありません。 私は時間と神経を使って決断し、支払いました。 最終製品を想像しているので、それを描く必要はないように思えますが、プログラミングの過程ですべてを行います。 素晴らしい妄想。 その結果、UIだけでなくUXもひどくなりました。 プロトタイプが作成されましたが。







確かに、その作成には1〜2週間かかりましたが、2.5か月以上かかりました。 このプロトタイプの存在は、将来的に非常に役立ちました。 これから、プロトタイプを作成しますが、専用ツールを使用してこれを行います。





開発。 再起動



最初の選択肢は良くありませんでしたし、さらに、AppleがAppStoreに入れてはいけないと確信していました。 したがって、開発を再開することが決定されました。 私が最初にしたことはTKの書き換えでした。 アイデアの単なる説明ではありませんでしたが、理想からはほど遠いものでした。 アプリケーション画面とそれらの間の遷移の説明が表示されました。



アプリのデザイナーを見つけました。 デザイナーと従業員の検索については、かなり多くのことが書かれています。 freelansim.ruを検索し、もちろんみんなと話しました。 仕事のための人々の選択は常に主観的で不可解な決定であることに注意すべきです。 これは宝くじに似ているようにさえ思えます。



幸運なことに、このタスクで優れた仕事をしただけでなく、テスト段階で多くの助けをしてくれた人を選んだ。



デザインが作成され、ゆっくりとアプリケーションが登場しました。 それまでの間、開発を再開してから、可能な限りすべてをスマートに行うことにしました。 私自身の経験から、失敗したプロトタイプは1つしかなかったので、他の人の経験を調査することにしました。 記事を読んだりレポートを表示したりして学んだことは次のとおりです。



これらの簡単な準備手順と優れたプロジェクト構造により、変更、特にプロジェクトナビゲーションの時間を大幅に節約できます。



欠点、プロジェクトの組織における率直な誤算、興味深いエラー



これは、私にとっては最も興味深く有用な部分です。 この記事で説明していることの多くは、経験豊富な開発者にとって明確で明白なはずですが、最初に始めたときは、この知識がまったくありませんでした。



アプリケーションのローカリゼーション



WWDC14で、Appleはアプリケーションをローカライズする新しい方法を導入しました。 プロジェクト全体を.xliffファイルにエクスポートして翻訳できます。 これは、実際には翻訳者の世界の標準です。 少なくとも、プレゼンテーションはまさにそれを言った。 良い、簡単な方法で、すべてを1か所で行うことができて嬉しかったです。 通常の行の代わりに、翻訳が必要なプログラムの場所に、マクロが書き込まれます。

NSLocalizedString(@“ string”、@“ comment”)。

冒頭には、主に翻訳者向けの翻訳とコメントが必要な行があります。 プログラムには何の影響もありません。 しかし、問題は、誰も間違いから安全ではないことであり、プログラム内で繰り返される場所があります。 一般に、どこかでミスをした場合、それを修正するにはプロジェクト全体を確認する必要があります。 しかし、それだけではありません。 実際には、.xliffファイル内の翻訳の行がキーになります。プログラムでそれを変更し、翻訳者が翻訳ファイルを変更しない場合、同じ翻訳と異なるキーの2行が表示されます。 Xcodeは翻訳を見つけられず、場所はローカライズされないままになります。



この問題の解決策は、古いローカライズ方法と新しいローカライズ方法の組み合わせでした。 翻訳に必要なすべての文字列は、Key-ValueとしてLocalizable.stringsファイルに送信されます。 そして、鍵に目を向けます。 これで、翻訳を恐れることなく原文を修正する機会が得られました。 そして再び、翻訳者は仕事に慣れ親しんだ便利なフォーマットを取得します。



奇妙な間違い



このセクションで説明されていることはすべて、私の無知のためだけに起こりました。

iPhone 5で書いたものをすべてテストしました。プログラムは完璧に機能しました。 ユーザーが自分の日を評価しなければならない瞬間がアプリケーションにあります。そのため、スライダーを使用するよう招待されますが、評価は3つの異なるスケール(100〜10および3ポイントシステム)で実行できます。 1ポイントシステムと10ポイントシステムの場合はスライダーが使用され、3ポイントシステムの場合は絵文字が使用されます。 これらはすべて表に表示され、各基準には独自のセルが割り当てられます。 便宜上、次のように書きました。



typedef enum: NSInteger{ EDEvaluatePriceHundredPoint, EDEvaluatePriceTenPoint, EDEvaluatePriceThreePoint }EDEvaluatePrice;
      
      





値自体はCoreDataに保存され、NSNumberとして表されます。 選択するとき、私は次の比較を行うことにしました:



 if (c.priceCriterion == [NSNumber numberWithInteger:EDEvaluatePriceHundredPoint]) { }
      
      





特に携帯電話で機能していたので、私にとっては理にかなっているようでした。 ここでは、2つの異なるオブジェクトを比較しています。

しかし、iPhone 5S以降では、これはもう機能せず、空のセルが表示されました。 私はまだ理解していない奇妙な話。 しかし、それは簡単に解決されます:



 if ([c.priceCriterion integerValue] == EDEvaluatePriceHundredPoint) { }
      
      





2番目のエラーはiPhone 6 Plusでのみ発生し、アプリケーションのレイアウトが壊れていました。 さらに、すべての画面ではなく、一部の画面でのみです。 この問題は、Xcode 6で提示されたマージンの制約に現れました。 デフォルトでは、この機能は有効になっています。 繰り返しますが、正確にこれが起こった理由を言うことはできません、問題はコンテナを使用しているように思えます。 しかし、Appleは、TabBarControllerなどで同じメカニズムを使用しました。 そして、問題は、再び、それ自体が常に現れなかった。



PSすべての奇妙な点と多くの落とし穴にもかかわらず、私はまだiPhone向けの開発が好きでした。 私の申請書は数週間しか店頭にいませんでしたので、結果について話すのは時期尚早です。 後で、アプリケーションプロモーションレポートを公開します。



All Articles