Как делалось iPhone-приложение для ServerClub

    В преддверии осени я завершил разработку iPhone-приложения для хостинга ServerClub.com. Теперь выдалась свободная минутка, и мне хотелось бы воспользоваться ею, чтобы поделиться с Хабрасообществом некоторыми усвоенными в ходе проекта уроками, а также поведать о «граблях», которые встретились на пути.

    Итак, началось все с того, что в HQ компании ServerClub.com, предоставляющей в аренду серверы и сопутствующий сервис, родилась идея дополнить веб-сайт мультиплатформенным мобильным клиентом, который предоставлял бы пользователям доступ к их серверам, данным по трафику, датчикам, тикетам, финансам, счетам на оплату, а также позволял бы заказывать серверы прямо из приложения. Вообщем, задумали они повторить весь функционал веб-клиента, переосмыслив и упаковав его в мобильное приложение. Сразу было понятно, что работы предстоит немало, но все же, как это часто бывает, оптимизм переборол разум, и я оценил работу в 1 календарный месяц, по прошествии которого я рассчитывал опубликовать приложение в App Store. Вот только в ходе разработки, согласования и уточнений каждая крупная фича «обросла» еще и мелкими нюансами, на реализацию и полировку которых ушло дополнительное время. Кроме того, неожиданные сюрпризы преподнесли ревьюверы, но обо всем по порядку.

    Состав проектной команды стоит отдельного упоминания. Я работал в Москве, разработчик серверной части — во Вьетнаме, заказчик находился в Нью-Йорке, дата-центр — в Голландии, а офис с инженерами — в Питере. При этом все были русскоязычными. Вот такая глобализация :)

    Первым делом решили выбрать технологию. Соблазнительным вариантом выглядел мультиплатформенный html-сайт, который одинаково работал бы не только на iPhone, но и на Android, и других платформах. Рассмотрев все за и против, мы все же решили начать с native-клиента для iPhone, ввиду его популярности, а также простоты установки приложения из App Store. В случае html-сайта единственным преимуществом является мультиплатформенность и более низкая стоимость, в ущерб скорости навигации, скорости отрисовки, а также гибкости в использовании аппаратных возможностей. Вообщем, интересы пользователя были поставлены во главу угла.

    Заказчиком сразу были предъявлены особые требования к безопасности соединения с сервером и хранения реквизитов доступа к учетной записи пользователя. Это предопределило выбор https, Keychain и прочее. Важно то, что эти моменты были оговорено на самых ранних стадиях проекта и мне не пришлось спешно все переделывать на стадии релиза, когда заказчик вдруг придумывает новые требования — а такое тоже бывало.

    Начали с выработки API для клиент-серверного взаимодействия. Для этого я создал в Google Docs расшаренный на всю команду документ и за пару дней сформировал основу API. В дальнейшем по ходу работы над проектом мы не раз дополняли его и уточняли, но самые важные основы были заложены сразу, поэтому двигались быстро, не возвращаясь назад и не ломая построенного.

    Теперь, имея перед глазами проработанный и согласованный API, я увидел более ясную картину предстоящего объема работ. И стало ясно, что первоначальные оценки были оптимистичными. Сделав переоценку, довел ее до заказчика. Надо отдать ему должное, он принял их без претензий. Серверной частью занялся один разработчик, клиентской — непосредственно я сам.

    Прорабатывая API и архитектуру, я уже представлял схему навигации по приложению и готов был отдать ее в дизайн. Нашел дизайнера-фрилансера. Договорились о цене и сроках. В течении пары дней появился макет 1-ого экрана, затем 2-ой. Работа пошла. И вдруг парень пропадает. На звонки и почту в ответ — тишина. Как выяснилось позже, у него родился ребенок. И с его слов, много времени проводил в роддоме, трепетно держа за руку жену. И так почти неделю. Что ж можно понять отцовские чувства. Но время было упущено, а доверие подорвано. Пришлось спешно искать другие варианты. Дизайн, который вы увидите на скринах ниже, делал уже другой человек.




    Технологических проблем, пожалуй, не было. Поэтому я упомяну лишь об некоторых особенностях. Тем, кого интересуют более тонкие подробности, постараюсь ответить в комментах. Взаимодействие с сервером: json via https, передача картинок: png via https. Фреймворки, которые здорово помогли сократить рутину и время: 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, и до сих пор ревью проходили без каких-либо претенций со стороны цензоров. А тут сразу три. Во-первых, глубоко затабуированным оказалось спрашивать у пользователя его е-мейл при логине и регистрации. Ранее я не раз перечитывал Apple Review Guidelines, но то ли не обращал внимания на этот пункт, то ли он появился там совсем недавно. Пришлось убрать экран регистрации, не смотря на крайнее недовольство заказчика. При логине использовался никнейм и это спасло его от праведного гнева «богов». Вторая претензия была, очевидно, вследствие невнимательности уже со стороны цензора. Он заявил, что заказ и оплата серверов возможны только через In-App Purchase (IAP). А дело в том, что заказ через приложение не оплачивается, а лишь формируется как POST-запрос и отправляется на сервер. Я написал об этом и стал ждать ответа. Через 7 дней приходит ответ, что из приложения (внимание!) надо УБРАТЬ In-App Purchase, поскольку реальные товары, к коим относится аренда серверов, не позволено оплачивать через IAP. Замкнутый круг. Снова письмо. Снова отказ через 5-7 дней. После этого я подал аппеляцию, после которой мне достаточно оперативно перезвонили и сообщили, что все претензии сняты, достаточно только убрать экран регистрации, что я и сделал. И в-третьих, в тексте пользовательского соглашения цензоры усмотрели ссылку на главную страницу хостинга ServerClub.com и потребовали убрать ее. В чем здесь подвох я даже не стал выяснять и просто убрал ссылку. Вся переписка заняла около 20 календарный дней.

    Итого, весь цикл разработки — от идеи до релиза в App Store — занял примерно 2 календарных месяца.

    Приложение в App Store: http://itunes.apple.com/app/id453939265

    Выводы:
    • формировать основной фиче-лист с заказчиком надо на самых ранних этапах проекта. Хотя рассчитывать на его 100% неизменность тоже глупо.
    • нельзя недооценивать стабилизацию, нюансы и полировку. На них всегда будет потрачено дополнительно время.
    • важно не только согласовать и документировать основополагающие технологии проекта, но и довести их до каждого участника
    • не стоит бояться итеративных корректив своих первоначальных оценок. Утаивание их от заказчика и срыв сроков в дальнейшем могут принести больше хлопот, испорченных нервов и бессонных ночей.
    • незнакомый фрилансер в проекте — высокий риск, особенно для краткосрочного проекта
    • хорошо читаемый код сокращает время разработки, особенно при стабилизации проекта
    • внимательно и почаще читать Apple Review Guidelines, ибо он периодически и без уведомления разработчиков меняется
    • в некоторых случаях App Review Board помогает бороться с упертостью цензоров, которые тоже люди и им свойственно ошибаться.

    Пожалуй, именно в этом проекте как никогда я ощутил всю безграничность мира, в котором небольшая группа людей, находясь на разных континентах и общаясь исключительно посредством Интернета, делала одно общее дело, слаженно и результативно. Спасибо всем, кто сделал этот проект возможным, а также тебе читатель — за то, что проявил терпение и дочитал до конца.
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 10
    • +4
      Небольшой совет из области управления проектами, формула подсчета времени разработки: оптимистичный_прогноз * 2, а если проект большой и в нем задействовано несколько команд, коэффициент может быть и 3, и даже 4.
      • 0
        почем?
        • +2
          Сама апликация бесплатна, но писалась для наших клиентов.
          • 0
            Тоесть в рамках сопровождения вы потратили 2 месяца на расширение функционала в совершенно новом направлении.
            Если «по человечески» — Уважуха!
            Если «по финансически» — Писец!

            Сколько заняло рассмотрение ПО со стороны Apple?
            • +3
              Интересно почему-же «по финансически» — Писец! :)
              Это дополнительное удобство для наших клиентов, представте, вы арендуете у нас сервер,
              и вы за всем можете уследить на ходу, посмотреть тикеты, финансовую ситуацию, график загрузки канала, итд.Удобно :)
              • 0
                каждая итерация рассмотрения занимала 5-7 дней. Суммарно на препирания и взаимную аргументацию ушло дней 20.
          • +1
            у нас тоже была проблема с мэйлом, но мы сделали поле не обязательным для заполнения и приложение приняли.
            • +1
              У Вас графики на скриншотах приложением нарисованы или получены в виде картинок с сервера? Если первое, то, если не секрет, что использовали для их построения?
              • 0
                P.S. Спасибо за MBProgressHUD :)
                • 0
                  Картинки графиков асинхронно загружаются с сервера. Трафик они создают совсем небольшой. По трудоемкости это было оптимальным решением как для серверной части, так и для клиентской.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое