Native vs Web. Часть 0: +1 аргумент в пользу разработки native мобильных приложений

    image

    Как-то вечером мне захотелось написать статью о разработке приложений для мобильных устройств, но тут Остапа понесло...

    Так же как киборги в свое время заполонили всю планету, сейчас мобильные девайсы заполоняют нашу жизнь. А что это означает для нас, гиков? Новые возможности даже обсуждать не стоит — это вкусные плоды с дерева под названием “гаджет”. А раз есть плоды и толпы страждущих, то почему бы не начать их выращивать (я про плоды, выращивать же страждущих умеет лишь Apple )? И тот вырастит больше и вкуснее, у кого инструмент лучше. Какие есть подходы в мобильном приложениеводстве? Как минимум можно использовать старую проверенную web-платформу и заняться написанием мобильных web-приложений, либо освоить молодую отрасль разработки под iOS и Android. Выбор, не простой, и чаши весов качались крайне долго в моей голове, пока на сторону разработки приложений под iOS (потенциально и под Android) не пал один весомый аргумент, о котором сегодня и пойдет речь. Но для начала краткий экскурс в технологии и их возможности.

    Что нам стоит инструмент освоить?


    Как минимум нужно с чего-то начинать. Это могут быть либо книги, либо туториалы. В области мобильных web-приложений все просто: о без года совершеннолетнем JavaScript (прим. для танкистов: он в 1995 году появился), его сестре погодоке CSS и старшем брате HTML 1991 года рождения написано книг на терабайт, а может и более. Одним словом, сфера развитая, готового материала в ней много, как и специалистов (прим. автора: и тех кто считает себя таковыми), и процесс обучения не должен вызвать особых трудностей. Молодые бойцы могут начать тренироваться на кошках, разрабатывая обычные десктопные web-приложения, а затем планомерно перейти на мобильные платформы. Единственное, что для вас изменится — вы будете использовать jQuery Mobile с вкраплениями jQTouch вместо классического JQuery. В довесок вы получите GEO-API, события поворота устройства (увы, полноценного доступа к гироскопам и акселерометрам вам не дадут, так что написать аналог Multiponk у вас не выйдет) и довольно убогий мультитач. По вышеупомянутым “довескам”, кстати сказать, материал придется собирать в сети по крупицам, книг или руководств в стиле “Пишем современное работающее приложение для mobile web с поддержкой GEO, Rotation и Multitouch” вы скорее всего не найдете (или я плохо искал?).

    Хорошо, а как дело обстоит с нативными платформами? Т.к. нас интересует лишь рынок, то отвернем головы от MeeGo, Symbian, RIM. И вот мы видим симпотяжку робота четырех лет от роду и вкусненькое яблоко, появившееся на свет годом ранее. Из хороших моментов можно отметить, что за годы существования было написано много фундаментальных изданий как для iOS, так и для Android. Писать для Android несколько проще: в качестве язык SDK — Java, взнос за Android Market составляет 25 енотов единоразово, а SDK доступен почти под любую вменяемую OS. С iOS дела обстоят несколько сложнее, т.к. денежных вливаний будет много: вначале вам придется купить Mac, после того, как вам надоест возиться с хакинтошами, затем вы выложите около сотни енотов за аккаунт разработчика в год, без него, кстати говоря, вы не получите доступ к полной документации SDK и видео с WWDC (качаешь с торрентов?! — типун тебе в карму). За все эти денежно/временные вложения вы получите полноценную поддержку GEO-API, полноценный гироскоп (либо акселерометр), микрофон, камеру, доступ к фото галерее, хранилище данных, мультитач. Выбор плюшек явно богаче чем при web-разработке.

    Быстрее, выше, сильнее


    Дьявол в деталях. А в мобильных устройствах, на мой взгляд, самый большой дьявол скрыт в скорости отклика приложения на действия пользователя. И ни один браузер не сможет работать быстрее, чем нативное приложение. Это может показаться несущественно: разница отклика на открытие вкладки, или выбора пункта меню может исчисляться в миллисекундах, но на мобильных устройствах она будет плавнее и быстрее на десяток миллисекунд, и это ощущение не будет вас покидать. Откройте m.youtube.com (а ведь это пожалуй одно из лучших web-приложений для мобильных устройств) и походите по сайту. Зайдите во вкладку категорий, поверните ваш гаджет. А теперь откройте встроенное приложение YouTube. И сравните. Детали незначительны, но с нативным приложением работать приятнее, чем с web-версией — плавность и скорость берут свое.

    Эталоны графического дизайна


    Пожалуй, среди пользователей можно выделить две категории людей: одни кричат “Мы хотим свободы самовыражения в том, что мы создаем”, а другая категория просто делает удобные приложения выдержанные в едином стиле. С такими приложениями легче разобраться, понять, как они работают и какие возможности предоставляют. В web-приложениях же царит буйство красок и форм. Возможно необычный дизайн это и здорово, но чтобы его оценил пользователь, он должен с ним хоть немного поработать, а не закрыть вкладку со словами “не понимаю, зачем оно мне?”. В нативных приложениях платформа диктует принципы построения дизайна — проще сделать классический дизайн, чем придумывать что-то свое. Web же всегда отличался разнообразием подходов к построению пользовательского интерфейса.

    Аргумент


    “Gillette — рекламируем станки, а подымаем на лезвиях”. Помимо прямого зарабатывания денег на мобильных приложениях (дядь, купи приложение всего за 1 вечный и зеленый!), сами App-маркеты (AppStore, Android Market) являются потрясающим маркетинговым инструментом! Вы можете использовать мобильное приложение для продажи вашего сервиса.

    Сделав мобильное приложение под Android или iOS, вы запускаете его в уже существующую сеть распространения товаров в категорию FREE. И так же как в обычных супермаркетах, люди пришедшие за молоком могут обратить внимание на йогурт-новинку, так и в AppStore человек пришедший за текстовым редактором может заинтересоваться вашим приложением “Блокнотус”. Но ведь у вас, как у разработчика “блокнотуса” истинная цель привлечь пользователей к вашему сервису и не дать слонам голодать ;-)

    Планшеты и прочие мобильные устройства вошли в моду. Люди регулярно ищут новинки в AppStore и Android Market для своих карманных зверюшек. Вероятность того, что они наткнутся на ваше приложение — очень велика. А т.к. оно быстро работает, имеет каноническую графику и простой интерфейс управления, то пользователь сможет понять его и заинтересоваться им. Овладев же его интересом вы овладеваете потенциальным заказчиком услуг вашего интернет-сервиса.

    P.S.0: это первая статья из серии сравнения процесса разработки мобильных native и web приложений. Несмотря на то, что я убедился (я надеюсь, и вы тоже) в доминировании native-платформы, иногда встречаются задачи, для которых web — это быстрое и дешевое решение, от которого лишь требуется принимать пару строк текста от пользователя и возвращать результат (даю волю вашей фантазии!).
    P.S.1: интересный факт, ранее Apple активно продвигал Apple WebApps — каталог web-приложений для iOS. Но видимо что-то пошло не так и каталоги прекратили пополняться.
    P.S._the_last: побудили меня на творчество две статьи: раз и два.
    Поделиться публикацией
    Комментарии 52
      +6
      Что лучше танк или самолет?
      Инструмент не может быть лучше или хуже другого инструмента, он может быть более или менее подходящим для выполнения конкретной задачи.
        +1
        Да, идеальных инструментов не бывает, но одни используются чаще, другие — реже. У одних 5 областей применения, у других две. Собственно говоря, серия статей на это и нацелена — выявить слабые и сильные стороны. Мой текущий опыт и познания видят больше преимуществ в native приложениях
          +1
          << выявить слабые и сильные стороны
          << Мой текущий опыт и познания видят больше преимуществ в native приложениях
          Вам все правильно написали, тут не может быть больше преимуществ. Больше преимуществ для чего? У native приложений больше преимуществ для кроссплатформенной аркады?
            0
            Мой текущий опыт и познания видят больше преимуществ в native приложениях.

            Это только пока. Уверен, в будущем нативные приложения будут вытеснены веб-приложениями.
          +6
          Неплохо написано, но после прочтения мне так и не стало понятно — какой же супер-мега-аргумент в пользу нативных приложений однозначно повлиял на твой выбор.
          В статье несколько аргументов и я не вижу того одного из них, который однозначно решал бы этот вопрос для любых приложений.
            0
            App-маркетинг — вот мой текущий весомый аргумент. AppStore и Android Market позволяют не только получать прибыль от продажи приложений, но и использовать приложение как инструмент раскрутки интернет-сервисов. К примеру, многие мои знакомые начали пользоваться Evernote лишь после того, как случайно наткнулись на него в AppStore. Само же приложение Evernote для iOS не приносит прибыли — оно лишь является рекламным инструментом
              +5
              Ну так и веб-приложение может находиться в AppStore. Уже есть несколько сервисов, которые оборачивают веб-приложение в натив-оболочку. Некоторые еще и автоматом подают заявку в сторе, если не ошибаюсь.
                +1
                Можно, но как минимум, когда я изредка натыкаюсь на такие приложения, то чувствую себя несколько обманутым. Представь себе, ты видишь в магазине MacBook Pro, берешь в руки, а у него корпус пластиковый, а вместо Mac OS стоит Windows. А свиду вроде MacBook… Вот так и с такими помесями Web+Native-оболочка дела обстоят
                  0
                  А Вы пощупайте например PhoneGap + плагины для него на нативных языках: работает быстро, доступ ко всему внизу есть, полегче с переносом GUI и бизнес-логики на другие платформы. Кроссплатформенность, правда, ограничивается необходимостью эти самые плагины портировать, но как по мне, основная ценность приложения — его бизнес-логика. Вот, кстати, я не знаю, почему еще не привлекли к этому вопросу метапрограммирование, как Фейсбук компилирует PHP в C++ и потом уже компилирует нативный код, так же можно, например, и JS компилить в JAVA.
                    0
                    JS компилируется виртуальной машиной браузера примерно так же, как Java
                  0
                  tiggzi.com пишется украинцами и белорусами
                  0
                  Так получается в твоем мире — android-приложения, это клиенты для веб-сервисов ;) Я бы несколько разграничил тему выбора платформы разработки мобильных приложений вообще и тему продвижения сервиса с помощью создания мобильных приложений.
                    0
                    Да, о дивный новый мир! Нет, ребята, я тоже живу на земле ;-) Повторюсь, это был лишь аргумент, +1 аргумент в пользу native-платформы
                –6
                А я вас поддерживаю на все 100. С этими HTML CSS JS приложениями толпы говнокодеров (поверьте я знаю о чем говорю) начнут писать приложения, при этом называя себя программистами не зная даже что такое стек и куча…
                • НЛО прилетело и опубликовало эту надпись здесь
                    +5
                    Хм. А зачем Зачем веб-программисту писать приложения под мобильные платформы?
                      +1
                      «Зачем веб-программисту знать что такое стёк и куча?»

                      JavaScript использует managed heap. веб-программисту знать что это такое обязательно. Это если программисту а не web designer'у. Особенно на mobile платформе. Google for «javascript memory leak» если интересно.
                      0
                      Точно так же программисты С++, Delphi и др. говорят программистам новых языков: «эх мОлодежь, не знаете, что такое malloc/free, того и гляди, из операторов цикла только foreach останется ». Куда делись структуры памяти, двух-связный список, пяти-связное дерево… но программирование же не прекратилось — задачи решаются и довольно эффективно, хотя, неприятное ощущение от того, что я не контролирую что делается в CPU и RAM — остается.
                        0
                        Правильно. Видимо меня не совсем правильно поняли. Но никто же не пишет драйвера на JAVA RUBY PHP Phyton etc
                          0
                          точно так же как никто не пишет web-frontend на ассемблере.
                            0
                            почему не пишет? пишет.
                            sourceforge.net/apps/mediawiki/fuse/index.php?title=LanguageBindings
                            Тут есть все перечисленные вами языки.
                            И такой юзерспейс можно сделать не только для файловых систем. Поэтому я бы не был так категоричен.
                            Явный плюс этой системы есть — кроссплатформенность и простота.
                        +1
                        Эхма… "«симпатяшку» робота"
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Web версии делаются:

                            1) дольше (убогость инструментов разработки, JS, отладки, паттерны, геморой с рендерингом и JS в разных браузерах)
                            2) это будет работать только в тех браузерах, под которые затачивалось. В чем отличие от разработки различных морд native-приложения под конкретную мобильную платформу?
                            3) нативное приложение выглядит родным на вашем смартфоне, скачивается 1 раз, работает на всю «катушку» железа, жрет меньше трафика, чем веб, ибо не скачивает UI каждый раз, чтобы обновить 2-3 поля. А разрабатывать нативное приложение в -надцать раз приятнее, быстрее и продуктивнее. Не говоря уже про то, что возможности работы с самим устройством несравнимо больше.
                              0
                              Вы, похоже, не до конца понимаете, что такое мобильное веб-приложение. Оно вполне может быть «локальным», т.е. ничего не качать из сети. Все ресурсы (html+css+js) находятся в самом пакете. Соответственно оно точно так же «скачивается один раз» и ровно то же самое по трафику.

                              >А разрабатывать нативное приложение в -надцать раз приятнее, быстрее и продуктивнее.

                              «Приятнее» — может быть, «продуктивнее» — тут спорно, «быстрее» — а вот тут вполне может получиться конкретная неувязочка (в зависимости от количества платформ, которые планируется поддерживать). Разработав веб-приложение мы моментально (с минимальными отличиями на уровне упаковки в пакеты) охватываем iOS, Android, BlackBerry OS (причём как текущую, так и следующую, которая ожидается в этом году), WP7. Возможно, ещё что-то.
                              Я бы очень хотел посмотреть, сколько времени у вас уйдёт на то, чтобы охватить все эти платформы нативными приложениям.
                            0
                            Мне кажется, что нужно посмотреть на историю развития языков программирования. И тогда с высокой долей вероятности сказать, что уже в недалеком будущем нативных приложений будет все меньше.
                            Приложений же, использующих кросс платформенные решения, как и инструментов, обеспечивающих возможность их существования, все больше.

                            Не так давно, никто и подумать не мог что можно написать приложение с приемлемой производительностью на языке высоко уровня. Сейчас это можно делать используя «банальный» bash.

                              0
                              Тогда не жалуйтесь, что телефон садит батарею за сутки и не плавная прокрутка списка приложений на двух ядрах )
                                0
                                Вы сейчас точь в точь повторяете аргументы тех холиваров, когда доминирование языков высокого уровня только начиналось.

                                Когда- то было гораздо дешевле купить штат программистов для написания эффективного когда в условиях малого обьема доступных ресурсов.

                                Сейчас купить дополнительную планку памяти гораздо проще.

                                Железо не стоит на месте. И уже сейчас, мобильные платформы подходят к той границе, когда затраты на написания наивного кода, будут просто не нужны.

                                  +4
                                  Вы правильно оговорились — наивного кода )
                                    +1
                                    Раньше домашний писюк апгрейдить приходилось при выходе новой версии, теперь еще и мобильник раз в пол года менять придется.
                                      +1
                                      Вы считаете что сейчас этого еще нет?
                                        0
                                        И сейчас уже есть. Например, 2gis меня просто убивает своей прожорливостью.
                                +1
                                Скажите, а вы слышали о PhoneGap — en.wikipedia.org/wiki/PhoneGap? Что скажете на счет того, что единожды написанное веб-приложение можно сделать нативным и для разных платформ? мне кажется, что это большой плюс.
                                  0
                                  Это замечательно, сами используем, но там все равно браузер привлечен.
                                    0
                                    C PhoneGap не сталкивался. Звучит интересно, но как фреймворк покажет себя на практике — вопрос. Возьму на заметку и исследую в ближайшее время. Можете посоветовать достойные приложения написанные с помощью него?
                                      0
                                      думаю, что можно посмотреть тут: phonegap.com/apps
                                        +2
                                        PhoneGap — не фреймворк. это скорее браузер без адресной строки, который открывает сразу нужную страницу. ну и небольшой апи для связи с системой — запустить программу, позвонить, написать, открыть ещё такой же браузер.
                                        его используют вместе с фреймворками, с jquery mobile в частности.
                                        но если вы хотите делать нормально выглядящее, и отзывчивое приложение, а не тормознутое говно с претензией, то jquery mobile использовать не нужно. правда, это хороший фреймворк (в теории), но даже examples app тормозили на всех телефонах, на которых я это пробовал. включая galaxys2 и iphone4.

                                        если приложить немного усилий и сделать интерфейс самостоятельно, результат будет отличный.
                                          0
                                          Недавно наткнулся на Sencha Touch, интересно было бы посмотреть сравнение Sencha и Jquery Mobile.
                                            0
                                            Jquery нельзя сравнивать с Sencha touch. JQuery выглядит обычной библиотекой, а Sencha Touch полноценным фреймворком. JQuery для сайтов (хотя можно строить и RIA), Sencha Touch для RIA (хотя можно делать и простые сайты).
                                            + еще есть:
                                            quooxdoo
                                            sproutcore
                                            cappuccino (впечатляющий пример 280slides.com/Editor/)
                                              0
                                              спасибо, посмотрю, как раз присматриваю фреймворк/библиотеку для создания с помощью PhoneGap приложения под Android/iOS
                                          0
                                          Очень удивлен тому что разработчик ios не знает про phonegap. Но и там не все так хорошо как кажеться, хотя ваше приложение и становится нативным, но до скорости С# ему еще далеко.
                                          Да и вообще там много минусов, но как старт, это самое идеальное решение.
                                          + получите возможность публикации в апплесторе
                                            0
                                            А вы не знаете, есть ли какие-то тесты, сравнивающие скорость приложений собранных с phonegap в сравнении с нативными аналогами? какие минуса?
                                            спрашиваю, потому что предстоит с ним работать.
                                              0
                                              А зачем ios разработчку phonegap? Phonegap подходить если вам нужно быстро сделать дешевый кусок дерма, но не тот случай, если вам нужно создать качественное приложение.
                                                0
                                                не понимаю, почему вы сравниваете с C#, если речь идет об iOS/Android?
                                                И зачем С-разработчику (если говорить об iOS) знать о веб-фреймворке. Помоему как раз разработчику iOS проще создать родное приложение, чем изучать новую платформу, особенно учитывая, что большинство «нативных разработчиков» косо смотрят на такие решения как phonegap.
                                                Я могу так-же сказать, а почему веб-разработчик не разбирается в нативной разработке? Ведь ему же все равно для решения специфических задач нужно будет писать нативны код в виде плагинов для того-же phonegap?
                                            0
                                            поверьте будущее за Web, только не в том виде как сейчас, а за такими сервисами как onlive
                                            на данный момент у них один недостаток — наличие высоко скоростного интернета.

                                            я привел пример onlive, не потому что это игры, а потому что все нагрузка идет на сервера, у пользователя идет незначительная нагрузка. Если развить идею, то у пользователя идет снижение энергопотребления, тем самым увеличивая автономность работы портативного устройства.

                                            Но это будет ни сегодня и завтра, это вопрос порядка 5 лет.

                                            и еще, у меня wp7 и там есть игры Xbox live, я бы с большим удовольствием бы купил подписку на доступ по всем играм допустим за 100 рублей в месяц, чем буду платить за каждую игру как минимум 100 рублей, как это сделано в onlive. Можно так же купить и саму игру как сейчас.
                                              0
                                              Забыл самое главное, уходит фрагментация по ос для разработчика, будут играть роль два фактора, скорость соединения интернета, Разрешение дисплеев и плотность пикселей. Данный подход уменьшает и возможность пиратства. и поэтому будет возможность не покупать определенный контент, а покупать возможность подключится к сервису. Возьмем тот же Microsoft Office 365, мы арендуем с помесячной оплатой сервис, при этом когда сервис обновится нам не придется покупать обновление, нам его уже предоставят как бы бесплатно.
                                                0
                                                и еще не много, у web есть свой минус браузер, который у каждого свой и они все разные (кто-то поддерживает одно, кто другое). с технологической точки зрения, у монополии есть одно достоинство, технология ведет себя везде одинакого, независимо где запускается.
                                                Возьмем номер adobe flash, я точно знаю что мой проект будет выглядеть одинакого везде.
                                                а вот если открытый стандарт, то кто как, когда хочет внедряет.
                                                Но монополии есть и минус, он ведет к застою, вон как flash начали развивать, только тогда когда пришел грозный противник в лице html5.
                                                поэтому я могу сделать один вывод обе технологии хороши, и их надо использовать совместно, делая упор на web.
                                                  0
                                                  Вы путаете понятия «веб-приложения» и «облачные вычисления»
                                                  +1
                                                  В статье указано всё то, что меня и отталкивает от разработки нативных приложений напрямую — покупка Mac, покупка книг, покупка аккаунта в Apple, покупка… сколько ещё надо сделать покупок чтобы начать делать, если ты новичок?

                                                  Недавно была статья про Construct 2 — программа для создания HTML5 игр без программирования. Я сразу всё купил и начал тестировать. К великому счатью на моём iPad всё заработало как надо быть. И что ещё важно — всё работает на компьютере.

                                                  Так что выбрать — нативное или web приложение? Для меня выбор очевиден.
                                                    0
                                                    Все зависит от ситуации. Если у вас сайт с маленькой посещаемостью (ну скажем, меньше 1000 человек в сутки), то простая web версия подойдет лучше. И опять же что-то зависит и от специфики сайта.
                                                      0
                                                      >Т.к. нас интересует лишь рынок, то отвернем головы от MeeGo, Symbian, RIM. И вот мы видим симпотяжку робота четырех лет от роду и вкусненькое яблоко, появившееся на свет годом ранее.

                                                      М-м-м? Если у вас другие данные (именно данные, а не мысли, впечатления или домыслы) — поделитесь, пожалуйста.
                                                        –1
                                                        Лучше хорошее, функциональное и быстрое приложение под одну платформу, чем кое-какое, но под несколько. Разработка мультиплатформенного приложения автоматически означает отступление от гайдлайнов того или иного устройства. На каждой платформе у пользователей разные привычки и предпочтения — т.е. делать что-то среднее значит не угождать обоим. Я не говорю уже о дизайне подобных приложений, который всегда оставляет желать лучшего.

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

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