Comments 52
Что лучше танк или самолет?
Инструмент не может быть лучше или хуже другого инструмента, он может быть более или менее подходящим для выполнения конкретной задачи.
Инструмент не может быть лучше или хуже другого инструмента, он может быть более или менее подходящим для выполнения конкретной задачи.
Да, идеальных инструментов не бывает, но одни используются чаще, другие — реже. У одних 5 областей применения, у других две. Собственно говоря, серия статей на это и нацелена — выявить слабые и сильные стороны. Мой текущий опыт и познания видят больше преимуществ в native приложениях
<< выявить слабые и сильные стороны
<< Мой текущий опыт и познания видят больше преимуществ в native приложениях
Вам все правильно написали, тут не может быть больше преимуществ. Больше преимуществ для чего? У native приложений больше преимуществ для кроссплатформенной аркады?
<< Мой текущий опыт и познания видят больше преимуществ в native приложениях
Вам все правильно написали, тут не может быть больше преимуществ. Больше преимуществ для чего? У native приложений больше преимуществ для кроссплатформенной аркады?
Мой текущий опыт и познания видят больше преимуществ в native приложениях.
Это только пока. Уверен, в будущем нативные приложения будут вытеснены веб-приложениями.
Это только пока. Уверен, в будущем нативные приложения будут вытеснены веб-приложениями.
Неплохо написано, но после прочтения мне так и не стало понятно — какой же супер-мега-аргумент в пользу нативных приложений однозначно повлиял на твой выбор.
В статье несколько аргументов и я не вижу того одного из них, который однозначно решал бы этот вопрос для любых приложений.
В статье несколько аргументов и я не вижу того одного из них, который однозначно решал бы этот вопрос для любых приложений.
App-маркетинг — вот мой текущий весомый аргумент. AppStore и Android Market позволяют не только получать прибыль от продажи приложений, но и использовать приложение как инструмент раскрутки интернет-сервисов. К примеру, многие мои знакомые начали пользоваться Evernote лишь после того, как случайно наткнулись на него в AppStore. Само же приложение Evernote для iOS не приносит прибыли — оно лишь является рекламным инструментом
Ну так и веб-приложение может находиться в AppStore. Уже есть несколько сервисов, которые оборачивают веб-приложение в натив-оболочку. Некоторые еще и автоматом подают заявку в сторе, если не ошибаюсь.
Можно, но как минимум, когда я изредка натыкаюсь на такие приложения, то чувствую себя несколько обманутым. Представь себе, ты видишь в магазине MacBook Pro, берешь в руки, а у него корпус пластиковый, а вместо Mac OS стоит Windows. А свиду вроде MacBook… Вот так и с такими помесями Web+Native-оболочка дела обстоят
А Вы пощупайте например PhoneGap + плагины для него на нативных языках: работает быстро, доступ ко всему внизу есть, полегче с переносом GUI и бизнес-логики на другие платформы. Кроссплатформенность, правда, ограничивается необходимостью эти самые плагины портировать, но как по мне, основная ценность приложения — его бизнес-логика. Вот, кстати, я не знаю, почему еще не привлекли к этому вопросу метапрограммирование, как Фейсбук компилирует PHP в C++ и потом уже компилирует нативный код, так же можно, например, и JS компилить в JAVA.
tiggzi.com пишется украинцами и белорусами
Так получается в твоем мире — android-приложения, это клиенты для веб-сервисов ;) Я бы несколько разграничил тему выбора платформы разработки мобильных приложений вообще и тему продвижения сервиса с помощью создания мобильных приложений.
А я вас поддерживаю на все 100. С этими HTML CSS JS приложениями толпы говнокодеров (поверьте я знаю о чем говорю) начнут писать приложения, при этом называя себя программистами не зная даже что такое стек и куча…
UFO just landed and posted this here
Хм. А зачем Зачем веб-программисту писать приложения под мобильные платформы?
«Зачем веб-программисту знать что такое стёк и куча?»
JavaScript использует managed heap. веб-программисту знать что это такое обязательно. Это если программисту а не web designer'у. Особенно на mobile платформе. Google for «javascript memory leak» если интересно.
JavaScript использует managed heap. веб-программисту знать что это такое обязательно. Это если программисту а не web designer'у. Особенно на mobile платформе. Google for «javascript memory leak» если интересно.
Точно так же программисты С++, Delphi и др. говорят программистам новых языков: «эх мОлодежь, не знаете, что такое malloc/free, того и гляди, из операторов цикла только foreach останется ». Куда делись структуры памяти, двух-связный список, пяти-связное дерево… но программирование же не прекратилось — задачи решаются и довольно эффективно, хотя, неприятное ощущение от того, что я не контролирую что делается в CPU и RAM — остается.
Правильно. Видимо меня не совсем правильно поняли. Но никто же не пишет драйвера на JAVA RUBY PHP Phyton etc
точно так же как никто не пишет web-frontend на ассемблере.
почему не пишет? пишет.
sourceforge.net/apps/mediawiki/fuse/index.php?title=LanguageBindings
Тут есть все перечисленные вами языки.
И такой юзерспейс можно сделать не только для файловых систем. Поэтому я бы не был так категоричен.
Явный плюс этой системы есть — кроссплатформенность и простота.
sourceforge.net/apps/mediawiki/fuse/index.php?title=LanguageBindings
Тут есть все перечисленные вами языки.
И такой юзерспейс можно сделать не только для файловых систем. Поэтому я бы не был так категоричен.
Явный плюс этой системы есть — кроссплатформенность и простота.
Эхма… "«симпатяшку» робота"
UFO just landed and posted this here
Web версии делаются:
1) дольше (убогость инструментов разработки, JS, отладки, паттерны, геморой с рендерингом и JS в разных браузерах)
2) это будет работать только в тех браузерах, под которые затачивалось. В чем отличие от разработки различных морд native-приложения под конкретную мобильную платформу?
3) нативное приложение выглядит родным на вашем смартфоне, скачивается 1 раз, работает на всю «катушку» железа, жрет меньше трафика, чем веб, ибо не скачивает UI каждый раз, чтобы обновить 2-3 поля. А разрабатывать нативное приложение в -надцать раз приятнее, быстрее и продуктивнее. Не говоря уже про то, что возможности работы с самим устройством несравнимо больше.
1) дольше (убогость инструментов разработки, JS, отладки, паттерны, геморой с рендерингом и JS в разных браузерах)
2) это будет работать только в тех браузерах, под которые затачивалось. В чем отличие от разработки различных морд native-приложения под конкретную мобильную платформу?
3) нативное приложение выглядит родным на вашем смартфоне, скачивается 1 раз, работает на всю «катушку» железа, жрет меньше трафика, чем веб, ибо не скачивает UI каждый раз, чтобы обновить 2-3 поля. А разрабатывать нативное приложение в -надцать раз приятнее, быстрее и продуктивнее. Не говоря уже про то, что возможности работы с самим устройством несравнимо больше.
Вы, похоже, не до конца понимаете, что такое мобильное веб-приложение. Оно вполне может быть «локальным», т.е. ничего не качать из сети. Все ресурсы (html+css+js) находятся в самом пакете. Соответственно оно точно так же «скачивается один раз» и ровно то же самое по трафику.
>А разрабатывать нативное приложение в -надцать раз приятнее, быстрее и продуктивнее.
«Приятнее» — может быть, «продуктивнее» — тут спорно, «быстрее» — а вот тут вполне может получиться конкретная неувязочка (в зависимости от количества платформ, которые планируется поддерживать). Разработав веб-приложение мы моментально (с минимальными отличиями на уровне упаковки в пакеты) охватываем iOS, Android, BlackBerry OS (причём как текущую, так и следующую, которая ожидается в этом году), WP7. Возможно, ещё что-то.
Я бы очень хотел посмотреть, сколько времени у вас уйдёт на то, чтобы охватить все эти платформы нативными приложениям.
>А разрабатывать нативное приложение в -надцать раз приятнее, быстрее и продуктивнее.
«Приятнее» — может быть, «продуктивнее» — тут спорно, «быстрее» — а вот тут вполне может получиться конкретная неувязочка (в зависимости от количества платформ, которые планируется поддерживать). Разработав веб-приложение мы моментально (с минимальными отличиями на уровне упаковки в пакеты) охватываем iOS, Android, BlackBerry OS (причём как текущую, так и следующую, которая ожидается в этом году), WP7. Возможно, ещё что-то.
Я бы очень хотел посмотреть, сколько времени у вас уйдёт на то, чтобы охватить все эти платформы нативными приложениям.
Мне кажется, что нужно посмотреть на историю развития языков программирования. И тогда с высокой долей вероятности сказать, что уже в недалеком будущем нативных приложений будет все меньше.
Приложений же, использующих кросс платформенные решения, как и инструментов, обеспечивающих возможность их существования, все больше.
Не так давно, никто и подумать не мог что можно написать приложение с приемлемой производительностью на языке высоко уровня. Сейчас это можно делать используя «банальный» bash.
Приложений же, использующих кросс платформенные решения, как и инструментов, обеспечивающих возможность их существования, все больше.
Не так давно, никто и подумать не мог что можно написать приложение с приемлемой производительностью на языке высоко уровня. Сейчас это можно делать используя «банальный» bash.
Тогда не жалуйтесь, что телефон садит батарею за сутки и не плавная прокрутка списка приложений на двух ядрах )
Вы сейчас точь в точь повторяете аргументы тех холиваров, когда доминирование языков высокого уровня только начиналось.
Когда- то было гораздо дешевле купить штат программистов для написания эффективного когда в условиях малого обьема доступных ресурсов.
Сейчас купить дополнительную планку памяти гораздо проще.
Железо не стоит на месте. И уже сейчас, мобильные платформы подходят к той границе, когда затраты на написания наивного кода, будут просто не нужны.
Когда- то было гораздо дешевле купить штат программистов для написания эффективного когда в условиях малого обьема доступных ресурсов.
Сейчас купить дополнительную планку памяти гораздо проще.
Железо не стоит на месте. И уже сейчас, мобильные платформы подходят к той границе, когда затраты на написания наивного кода, будут просто не нужны.
Скажите, а вы слышали о PhoneGap — en.wikipedia.org/wiki/PhoneGap? Что скажете на счет того, что единожды написанное веб-приложение можно сделать нативным и для разных платформ? мне кажется, что это большой плюс.
Это замечательно, сами используем, но там все равно браузер привлечен.
C PhoneGap не сталкивался. Звучит интересно, но как фреймворк покажет себя на практике — вопрос. Возьму на заметку и исследую в ближайшее время. Можете посоветовать достойные приложения написанные с помощью него?
думаю, что можно посмотреть тут: phonegap.com/apps
PhoneGap — не фреймворк. это скорее браузер без адресной строки, который открывает сразу нужную страницу. ну и небольшой апи для связи с системой — запустить программу, позвонить, написать, открыть ещё такой же браузер.
его используют вместе с фреймворками, с jquery mobile в частности.
но если вы хотите делать нормально выглядящее, и отзывчивое приложение, а не тормознутое говно с претензией, то jquery mobile использовать не нужно. правда, это хороший фреймворк (в теории), но даже examples app тормозили на всех телефонах, на которых я это пробовал. включая galaxys2 и iphone4.
если приложить немного усилий и сделать интерфейс самостоятельно, результат будет отличный.
его используют вместе с фреймворками, с jquery mobile в частности.
но если вы хотите делать нормально выглядящее, и отзывчивое приложение, а не тормознутое говно с претензией, то jquery mobile использовать не нужно. правда, это хороший фреймворк (в теории), но даже examples app тормозили на всех телефонах, на которых я это пробовал. включая galaxys2 и iphone4.
если приложить немного усилий и сделать интерфейс самостоятельно, результат будет отличный.
Недавно наткнулся на Sencha Touch, интересно было бы посмотреть сравнение Sencha и Jquery Mobile.
Jquery нельзя сравнивать с Sencha touch. JQuery выглядит обычной библиотекой, а Sencha Touch полноценным фреймворком. JQuery для сайтов (хотя можно строить и RIA), Sencha Touch для RIA (хотя можно делать и простые сайты).
+ еще есть:
quooxdoo
sproutcore
cappuccino (впечатляющий пример 280slides.com/Editor/)
+ еще есть:
quooxdoo
sproutcore
cappuccino (впечатляющий пример 280slides.com/Editor/)
Очень удивлен тому что разработчик ios не знает про phonegap. Но и там не все так хорошо как кажеться, хотя ваше приложение и становится нативным, но до скорости С# ему еще далеко.
Да и вообще там много минусов, но как старт, это самое идеальное решение.
+ получите возможность публикации в апплесторе
Да и вообще там много минусов, но как старт, это самое идеальное решение.
+ получите возможность публикации в апплесторе
А вы не знаете, есть ли какие-то тесты, сравнивающие скорость приложений собранных с phonegap в сравнении с нативными аналогами? какие минуса?
спрашиваю, потому что предстоит с ним работать.
спрашиваю, потому что предстоит с ним работать.
А зачем ios разработчку phonegap? Phonegap подходить если вам нужно быстро сделать дешевый кусок дерма, но не тот случай, если вам нужно создать качественное приложение.
не понимаю, почему вы сравниваете с C#, если речь идет об iOS/Android?
И зачем С-разработчику (если говорить об iOS) знать о веб-фреймворке. Помоему как раз разработчику iOS проще создать родное приложение, чем изучать новую платформу, особенно учитывая, что большинство «нативных разработчиков» косо смотрят на такие решения как phonegap.
Я могу так-же сказать, а почему веб-разработчик не разбирается в нативной разработке? Ведь ему же все равно для решения специфических задач нужно будет писать нативны код в виде плагинов для того-же phonegap?
И зачем С-разработчику (если говорить об iOS) знать о веб-фреймворке. Помоему как раз разработчику iOS проще создать родное приложение, чем изучать новую платформу, особенно учитывая, что большинство «нативных разработчиков» косо смотрят на такие решения как phonegap.
Я могу так-же сказать, а почему веб-разработчик не разбирается в нативной разработке? Ведь ему же все равно для решения специфических задач нужно будет писать нативны код в виде плагинов для того-же phonegap?
поверьте будущее за Web, только не в том виде как сейчас, а за такими сервисами как onlive
на данный момент у них один недостаток — наличие высоко скоростного интернета.
я привел пример onlive, не потому что это игры, а потому что все нагрузка идет на сервера, у пользователя идет незначительная нагрузка. Если развить идею, то у пользователя идет снижение энергопотребления, тем самым увеличивая автономность работы портативного устройства.
Но это будет ни сегодня и завтра, это вопрос порядка 5 лет.
и еще, у меня wp7 и там есть игры Xbox live, я бы с большим удовольствием бы купил подписку на доступ по всем играм допустим за 100 рублей в месяц, чем буду платить за каждую игру как минимум 100 рублей, как это сделано в onlive. Можно так же купить и саму игру как сейчас.
на данный момент у них один недостаток — наличие высоко скоростного интернета.
я привел пример onlive, не потому что это игры, а потому что все нагрузка идет на сервера, у пользователя идет незначительная нагрузка. Если развить идею, то у пользователя идет снижение энергопотребления, тем самым увеличивая автономность работы портативного устройства.
Но это будет ни сегодня и завтра, это вопрос порядка 5 лет.
и еще, у меня wp7 и там есть игры Xbox live, я бы с большим удовольствием бы купил подписку на доступ по всем играм допустим за 100 рублей в месяц, чем буду платить за каждую игру как минимум 100 рублей, как это сделано в onlive. Можно так же купить и саму игру как сейчас.
Забыл самое главное, уходит фрагментация по ос для разработчика, будут играть роль два фактора, скорость соединения интернета, Разрешение дисплеев и плотность пикселей. Данный подход уменьшает и возможность пиратства. и поэтому будет возможность не покупать определенный контент, а покупать возможность подключится к сервису. Возьмем тот же Microsoft Office 365, мы арендуем с помесячной оплатой сервис, при этом когда сервис обновится нам не придется покупать обновление, нам его уже предоставят как бы бесплатно.
и еще не много, у web есть свой минус браузер, который у каждого свой и они все разные (кто-то поддерживает одно, кто другое). с технологической точки зрения, у монополии есть одно достоинство, технология ведет себя везде одинакого, независимо где запускается.
Возьмем номер adobe flash, я точно знаю что мой проект будет выглядеть одинакого везде.
а вот если открытый стандарт, то кто как, когда хочет внедряет.
Но монополии есть и минус, он ведет к застою, вон как flash начали развивать, только тогда когда пришел грозный противник в лице html5.
поэтому я могу сделать один вывод обе технологии хороши, и их надо использовать совместно, делая упор на web.
Возьмем номер adobe flash, я точно знаю что мой проект будет выглядеть одинакого везде.
а вот если открытый стандарт, то кто как, когда хочет внедряет.
Но монополии есть и минус, он ведет к застою, вон как flash начали развивать, только тогда когда пришел грозный противник в лице html5.
поэтому я могу сделать один вывод обе технологии хороши, и их надо использовать совместно, делая упор на web.
Вы путаете понятия «веб-приложения» и «облачные вычисления»
В статье указано всё то, что меня и отталкивает от разработки нативных приложений напрямую — покупка Mac, покупка книг, покупка аккаунта в Apple, покупка… сколько ещё надо сделать покупок чтобы начать делать, если ты новичок?
Недавно была статья про Construct 2 — программа для создания HTML5 игр без программирования. Я сразу всё купил и начал тестировать. К великому счатью на моём iPad всё заработало как надо быть. И что ещё важно — всё работает на компьютере.
Так что выбрать — нативное или web приложение? Для меня выбор очевиден.
Недавно была статья про Construct 2 — программа для создания HTML5 игр без программирования. Я сразу всё купил и начал тестировать. К великому счатью на моём iPad всё заработало как надо быть. И что ещё важно — всё работает на компьютере.
Так что выбрать — нативное или web приложение? Для меня выбор очевиден.
Все зависит от ситуации. Если у вас сайт с маленькой посещаемостью (ну скажем, меньше 1000 человек в сутки), то простая web версия подойдет лучше. И опять же что-то зависит и от специфики сайта.
>Т.к. нас интересует лишь рынок, то отвернем головы от MeeGo, Symbian, RIM. И вот мы видим симпотяжку робота четырех лет от роду и вкусненькое яблоко, появившееся на свет годом ранее.
М-м-м? Если у вас другие данные (именно данные, а не мысли, впечатления или домыслы) — поделитесь, пожалуйста.
М-м-м? Если у вас другие данные (именно данные, а не мысли, впечатления или домыслы) — поделитесь, пожалуйста.
Лучше хорошее, функциональное и быстрое приложение под одну платформу, чем кое-какое, но под несколько. Разработка мультиплатформенного приложения автоматически означает отступление от гайдлайнов того или иного устройства. На каждой платформе у пользователей разные привычки и предпочтения — т.е. делать что-то среднее значит не угождать обоим. Я не говорю уже о дизайне подобных приложений, который всегда оставляет желать лучшего.
Sign up to leave a comment.
Native vs Web. Часть 0: +1 аргумент в пользу разработки native мобильных приложений