そのため、サーバーレンタルおよび関連サービスのレンタル会社であるServerClub.comは、ユーザーがサーバー、トラフィックデータ、センサー、チケットにアクセスできるマルチプラットフォームモバイルクライアントでWebサイトを補完するというアイデアを思いつきました。財務、支払い請求書、およびアプリケーションからサーバーを直接注文することもできます。 一般的に、彼らはWebクライアントのすべての機能を繰り返し、モバイルアプリケーションで再考し、パッケージ化することを考えました。 やるべきことがたくさんあることはすぐに明らかでしたが、それでもよくあることですが、私の心は楽観主義を克服し、1か月に作品を評価しました。その後、App Storeでアプリケーションを公開する予定でした。 それは、開発、調整、改良の過程でのみ行われます。それぞれの主要な機能はわずかなニュアンスで「成長」し、その実装と洗練には余分な時間がかかりました。 さらに、予想外の驚きが査読者によって提示されましたが、最初に最初のものがありました。
プロジェクトチームの構成は、特に言及する価値があります。 私はモスクワで働き、サーバー側の開発者はベトナムに、顧客はニューヨーク、オランダのデータセンター、そしてサンクトペテルブルクにエンジニアがいるオフィスにいました。 同時に、誰もがロシア語を話していました。 ここにそのようなグローバリゼーションがあります:)
最初にテクノロジーを選択することにしました。 iPhoneだけでなくAndroidや他のプラットフォームでも同様に機能するマルチプラットフォームのHTMLサイトは、魅力的なオプションのように見えました。 長所と短所を考慮して、私たちはまだ人気があり、App Storeからアプリケーションをインストールするのが簡単なため、iPhoneのネイティブクライアントから始めることにしました。 htmlサイトの場合、唯一の利点は、ナビゲーション速度、レンダリング速度、およびハードウェア機能の使用における柔軟性を損なうマルチプラットフォームと低コストです。 一般に、ユーザーの利益は最前線に置かれました。
顧客はすぐに、サーバーに接続し、アクセスの詳細をユーザーアカウントに保存するための特別なセキュリティ要件を提示しました。 これにより、https、キーチェーンなどの選択が事前に決定されました。 重要なことは、これらの点はプロジェクトの初期段階で合意されたものであり、顧客が突然新しい要件を思い付くリリース段階で急いですべてをやり直す必要はなかったということです。
クライアントとサーバーの相互作用のためのAPIを開発することから始めました。 これを行うために、Google Docsでチーム全体が共有するドキュメントを作成し、数日でAPIの基礎を作りました。 プロジェクトの後の作業の過程で、私たちは何度もそれを補足し、明確にしましたが、最も重要な基盤はすぐに置かれたので、私たちは戻って構築されたものを壊さずに素早く移動しました。
目の前によく発達した一貫性のあるAPIがありましたので、今後のワークロードのより明確な画像を見ました。 そして、最初の見積もりは楽観的であることが明らかになりました。 再評価した後、私はそれを顧客に持ってきました。 私たちは彼に彼の義務を与えなければなりません、彼は文句なしでそれらを受け入れました。 サーバーの部分は1人の開発者が担当し、クライアントの部分は自分で直接担当しました。
APIとアーキテクチャの開発中に、アプリケーションナビゲーションスキームを既に提示し、それを設計に提供する準備ができていました。 フリーランスのデザイナーを見つけました。 価格と条件に同意しました。 数日のうちに、最初の画面のレイアウトが表示され、2番目の画面が表示されました。 仕事はなくなりました。 そして、男は消えます。 呼び出しとメールに応答して-沈黙。 後で判明したように、彼には赤ん坊がいました。 そして彼によると、彼は病院で多くの時間を過ごし、心配して妻の手を握っていた。 そしてほぼ一週間。 まあ、あなたは父親の気持ちを理解することができます。 しかし、時間が失われ、信頼が損なわれました。 他のオプションを急いで探す必要がありました。 以下のスクリーンショットに表示されるデザインは、すでに他の人によって作成されています。
おそらく技術的な問題はなかったでしょう。 したがって、いくつかの機能についてのみ言及します。 より微妙な詳細に興味がある人は、コメントで答えてみます。 サーバーとの対話：https経由のjson、画像転送：https経由のpng。 ルーチンと時間の削減に大いに役立ったフレームワーク： ASIHTTPRequest 、 SBJson 、 MBProgressHUD 、 SFHFKeychainUtils 。
少し遅れて、ブロックを使用したビューのアニメーションを発見しました。 アニメーションを段階的に配置するいくつかの方法の代わりに：
-(void)showPickerPopup { [UIView beginAnimations:nil context:nil]; [UIView setAnimationDuration:0.5]; [UIView setAnimationDelegate:self]; [UIView setAnimationDidStopSelector:@selector(pickerPopupShown)]; tableView.alpha = 0; [UIView commitAnimations]; } -(void)pickerPopupShown { tableView.hidden = YES; }
... iOS 4.0以降、次のように、よりコンパクトで読みやすいように記述できます。
-(void)showPickerPopup { [UIView animateWithDuration:0.5 animations:^{ tableView.alpha = 0; } completion:^(BOOL finished) { tableView.hidden = YES; } ]; }
一見、両方の方法は似ていますが、実際のコードでは、アルファ（この例のように）だけでなく、いくつかのビューから他のパラメーターの束も制御する必要がある場合、ブロックベースのコードは視覚的に非常に明確になり始めます。 また、コードが視覚的に視覚的に便利な場合、最終的にエラーが少なくなり、最終段階でデバッグにかかる時間が短縮されます。 私はそのような結論を出すだけでなく、さまざまなプロジェクトで長年の仕事に苦しみました。 したがって、私は他の人に助言するこの原則を厳守しようとします。
そして今、App Storeでアプリケーションを公開するときに私を待っていたのとほぼ同じ「熊手」。 私はこれがiPhone用の私の最初のアプリケーションではないことを言わなければなりません、そして今のところレビューは検閲官からの主張なしに合格しています。 そして、ここで一度に3。 まず、ログインおよび登録時にユーザーに電子メールアドレスを尋ねるために、詳細に集計されていることが判明しました。 Appleレビューガイドラインを何度も読み直しましたが、この項目に注意を払っていないか、最近掲載されました。 顧客の極端な不満にもかかわらず、私は登録画面を削除しなければなりませんでした。 ログイン時にニックネームが使用され、これにより「神」の正しい怒りから彼が救われました。 2番目の不満は、明らかに、検閲の不注意によるものでした。 彼は、サーバーの注文と支払いはアプリ内購入（IAP）によってのみ可能であると述べました。 しかし、実際には、アプリケーションを介した注文は支払われず、POSTリクエストとして形成され、サーバーに送信されるだけです。 私はこれについて書き、答えを待ち始めました。 7日後、答えはアプリケーションから得られます（注意！）サーバーレンタルを含む実際の商品はIAPで支払うことが許可されていないため、アプリ内購入を削除する必要があります。 悪循環。 再び手紙。 再び5-7日で失敗します。 その後、私は控訴を提出し、その後すぐにコールバックされ、すべての申し立てが削除されたことを通知されたので、登録画面を削除するだけで十分でした。 そして第三に、ユーザー同意書の本文で、検閲官はServerClub.comホスティングのメインページへのリンクを見つけ、それを削除するよう要求しました。 ここでのキャッチは何でしたか、私は見つけさえせず、単にリンクを削除しました。 すべての通信には約20暦日かかりました。
合計で、アイデアからApp Storeでのリリースまで、開発サイクル全体で約2か月かかりました。
App Storeのアプリ： http : //itunes.apple.com/app/id453939265
結論：
- プロジェクトの初期段階で顧客と主要な機能リストを作成する必要があります。 100％の不変性に頼るのも愚かです。
- 安定化、ニュアンス、研磨を過小評価しないでください。 彼らは常に余分な時間を費やします。
- プロジェクトの基本技術を調整して文書化するだけでなく、それらを各参加者に提供することも重要です
- 最初の見積もりを繰り返し調整することを恐れないでください。 顧客からそれらを差し控え、将来の締め切りに間に合わない場合は、より多くのトラブル、甘やかされた神経、眠れぬ夜をもたらす可能性があります。
- プロジェクトのなじみのないフリーランサー-特に短期プロジェクトの場合のリスクが高い
- 読みやすいコードは、特にプロジェクトを安定させるときに開発時間を短縮します
- Apple Review Guidelinesは、開発者に通知することなく定期的に変更されるため、注意深く頻繁に読んでください。
- 場合によっては、App Review Boardは検閲者の頑固性との闘いを支援します。検閲者は人であり、間違いを犯しがちです。
おそらく、このプロジェクトでは、これまでにないほど、世界の広大さを感じました。そこでは、異なる大陸に住み、インターネットを介して排他的に通信する少数の人々が、調和して効果的に一つの共通のことをしました。 このプロジェクトを実現してくれた皆さん、そして忍耐と最後まで読んでくれた読者の皆さんに感謝します。