Pull to refresh

Comments 65

Я верил, что за веб приложениями будущее. Потом я понял, что это будущее будет очень далеким, пока такие приложения клепаются людьми, выучившимся по книгам «javascrpit для чайников».
Более высокий порог вхождения при разработке нативных приложений отфильтровывает таких «разработчиков».

Почти две недели я провел в попытках привести во вменяемое состояние приложение на PhoneGap, которое разряжало телефон за час-полтора и загоняло все остальные приложения в своп (я до этого даже не знал, что у меня на телефоне есть своп). Разработчик свалил в кучу jquery, mootools, zeptojs и sencha-touch.
В итоге оказалось проще переписать с нуля в нативный код.

Конечно это крайность, но с ростом популярности, эта крайность перейдет в норму.
К сожалению, есть люди, которые клепают нативные приложения, выучившись по книгам «Objective C/JAVA для чайников».
У них хотя бы интерфейс более-менее нативный выходит. C phone-gap получается смесь бульдога с носорогом. В лучшем случае интерфейс «под айфон» на андроиде.
тож не всегда… Qt и аналоги не дремлют… FireMonkey рекламируется… %(
Канал тут вообще не причем.
Как нативные так и html приложения примерно одинаково работают с данными через сеть, все что надо кешируется или обновляется очень редко.

Проблема только в тормозах и глюках javascript решений по отношению к нативным.
Дело в том, что данные в веб-приложениях кэшировать в память устройства чуть сложнее, чем в нативном устройстве. Поэтому нативные приложения имеют преимущество: ими можно пользоваться даже если интернета нет (например, просмотреть видео ранее просмотренного рецепта приготовления блюда).
Разговор про канал, ИМХО, достаточно странный — в большинстве случаев можно хранить приложение локально, загружая его только в первый раз. С другой стороны, к каждому приложению все равно придется дописывать девайс-специфичную обертку — системы уведомлений, обращения к батарейке, акселерометру и так далее все равно будут разниться от системы к системе. И, что самое, ИМХО, главное, на данный момент мобильные HTML-приложения дают достаточно убогий look-and-feel (я сейчас сужу на примере устройства на WP7). Возможность зума всей страницы, возможность скролла вбок, достаточно неприятная подсветка ссылок при нажатии и отсутствие анимации… Платформа, которая даст возможность настроить браузер так, чтобы страница в нем не отличалась от нативного приложения, почти сразу же получит море достаточно приличных приложений.
> Платформа, которая даст возможность настроить браузер так, чтобы страница в нем не отличалась от нативного приложения

на iOS такая возможность была с самого начала, Apple сделала ставку на них в первом iPhone. Найтив приложений, SDK, и магазина AppStore тогда не было.
developer.apple.com/library/safari/#referencelibrary/GettingStarted/GS_iPhoneWebApp/_index.html
можно делать элементы управления как найтив, обрабатывать мультитач, получать данные некоторых датчиков

есть каталог приложений
www.apple.com/webapps/whatarewebapps.html
(уже не развивается)

особо он не пошло, вначале хакеры расковыряли API и сделали свой SDK, потом Apple выпустила официально и SDK и AppStore.
>Платформа, которая даст возможность настроить браузер так, чтобы страница в нем не отличалась от нативного приложения, почти сразу же получит море достаточно приличных приложений.

Посмотрите на превью браузера в грядущем BlackBerry 10. Я сильно подозреваю, что если бы я вам сейчас не сказал, что само приложение «браузер» — это веб-приложение, полностью написанное на HTML5+JS, то сами бы вы ни за что об этом даже не подумали :)
При этом он выглядит и ведёт себя абсолютно так же, как нативные приложения, написанные с использования основного фреймворка Cascades.

Как можно прогить не на C/C++?
Ответ очевиден не хотят учить этот гибкий и самый лучший и одновременно сложный язык программирования.
Не берегут ресурсы процессора, быстрая работа программы на слабом железе нынче не тренд. Понапридумывают миллион интепретаторов и мучают проц, прикрываясь «оно типа мультиплатформенное». Всё равно, на разных устройствах по-своёму делают (по крайней мере это неизбежно), и приходится это учитывать. Так какая разница, если можно просто перекомпилировать проект на си и без особых проблем портануть, не мучая при этом проц?
Мне очень нравятся плюсы, я пишу на них много лет и именно с них попал в серьезную разработку. Но называть их лучшим языком я бы не стал. По крайней мере не после того как познакомился с питоном, лиспом и эрлангом. Мне кажется что понятие лучший язык вообще звучит немного по-детски, как будто бывает что-то однозначно лучшее или худшее. Впрочем автор статьи об этом и пытался сказать.
UFO just landed and posted this here
Статья ни о чем. Смысла в ее переводе вообще не вижу. Уже вроде бы всем понятно, что там, где можно обойтись вебом — будут им обходиться, чтобы получить универсальность и гибкость. Где скорости недостаточно, или нужны какие-то специфические фичи платформы — там пишутся нативные приложения. Автор либо пиарит свой ресурс, либо страдает графоманством, если накатал 5 страниц А4 текста с очевидными выводами.
Однозначно графоманство, да. Либо сама по себе статья изначально была задумана для нехабровской ЦА.
А про веб — приложения, как приложения будущего, это вообще бред сумашедшего, из дурки не успели выписать, пускай веб останется вебом для украшения сайтов и увеличение его интерактивности. Что-то они на самое святое посягают!
Пора заводить мем «типичный сишник».
не знаю, может быть потому что я знаю несколько ассемблеров, работаю с железом и памятью на низком уровне, знаю настоящую ценность Си, у меня патологическое отвращение к «искусственным» языкам?
А с чего вы взяли, что именно это — «типичный сишник»?
Была замечена тенденция :) иначе бы не писал.
Вот именно, «замечена». Как насчёт того, что вы могли чего-то не заметить? Скажем, вы заметили десяток таких сишников-фанатиков, но не заметили ещё сотню, которые сидят себе тихо и не орут «сишечка форева!»
В итоге вы замечаете десяток упоротых (потому что они орут), но не замечаете сотню нормальных (которые сидят и не кричат)?
UFO just landed and posted this here
>> 2. Javascript не предназначался для написания сложных приложений.

Вот сейчас набегут фанаты прототипного наследования и объяснят, кто тут не прав :)
UFO just landed and posted this here
Имелась ввиду структурная сложность системы, справляться с которой помогает (иногда) объектный подход.
Вот мне абсолютно до фонаря прототипное наследование. А удручает то, что нетбук на атоме купленный 2 года назад тормозит при работе в вебе из-за всеми любимого JS. Это печально…
Глупость полную морозите. Ноут тормозит не из-за JS. Сам по себе язык достаточно шустрый.
И даже если бы сайты были написаны на С они тормозили бы, потому что работают с тормозящими API а-ля DOM и отрисовка всяких красивостей без графического ускорителя.
Кога Марк Андреессен говорит «Приложения будущего», так и хочется попросить его «define будущее».

Вот прямо сейчас приходится работать с RhoMobile. Начнем с того что порог вхождения есть, и он высок. И дело не в ruby, не в HTML5, нет, дело в общем состоянии платформы. Просто чтобы настроить рабочее окружение на Mac OS нужно основательно замучить гугл, расковырять несколько rake-файлов и в последствии натыкаться на различные проблемы. Просто запустить RhoSimulator для нужного приложения мне не удалось, на форумах несколько людей с такой же проблемой и ответа пока нет.

Дальше идет вопрос нативных расширений (native extensions), опять же, rhogen генерит Xcode проект в формате 3.1, в котором не прописан необходимый путь RHO_HOME, требуется время чтобы только обнаружить что не так, и ответа не нагуглишь, и т.д. Один и тот же код с использованием блоков и dispatch queue будет работать в вашем тестовом нативном приложении, но вылетит при запуске в rhomobile приложении. Вызов нативного picker-а вызывает неожиданный зум HTML странички, который сам по себе никуда не денется. В iOS6 изменился подход к авторотации, некоторые мои нативные приложения перестали реагировать на вращения, исправление было в одну строчку, к сожалению, все не так просто в RhoMobile, приложение просто не хочет «крутиться» и все, пока фикс не добавят в саму платформу. И «отзывчивость» — оно слово: кошмар, как-будто тычешь пальцем в какой-то резистивный тачскрин лохматых годов.

Продолжать можно долго, после всех костылей и пробем я вижу ужасно медленное и сырое приложение, над которым год работали 2 человека, при этом тестировалось оно тольком только на Android, поддержка Windows Phone, BlackBerry и iOS разве что «гарантирована» RhoMobile, а на деле там непаханное поле мелких багов и куча подводных камней, плюс целая обойма native extensions, которые необходимо реализовать для данного конкретного приложения. Т.е. если говорить прямо, работает только на Android (и не на всех версиях одинаково стабильно). За вдвое (если не втрое) меньшее время один опытный iOS и один Android разработчик сделали бы отлично бегающий клиент под каждую платформу, с общими библиотеками на том же C++. Еще остается время на другие платформы.

Вывод, исходя из моего опыта, будущее еще не наступило и еще не скоро наступит. Ни одна «универсальная» платформа не успевает идти в ногу с основными мобильными операционками (Android, iOS, Windows Phone, BB). Если вам кровь из носу необходимо писать под 3-4 операционки сразу и вы сильно ограничены в ресурсах, тогда да, подход может себя оправдать.

P.S. Я понимаю что речь в статье идет немного о другом, когда вообще все приложения доступны «просто через браузер». Но до этого будущего, имхо, еще гораздо дальше, даже не берусь делать прогнозов.
Надеяться на то, что «написал одну программу» для всех платформ, это то же самое, что надеяться, что все люди земного шара будут говорить на одном едином языке.
был опыт с Qt, выводы аналогичны. Поиск идеальной кроссплатформенной равен поиску серебряной пули. Если родной SDK вменяемый, то лучше делать на нем, выделяя некоторые модули в кроссплатформенные библиотеки
Flash (убита Стивом Джобсом)
Что, простите? Flash конечно пострадал от мобильных платформ, но неплохо себя чувствует и поныне, а вот Стив Джобс…
Думаете, в смерти Стива виноват Флеш?
Нет, что вы. Просто абсурдность высказывания очевидна.
UFO just landed and posted this here
Почему не освещен вопрос хмм заимствования кода? Защитить свой продукт на JS cложно. Или я неправ?
лицензий достаточно, или вы параноик?
в любом случае код восстановить можно, в компилируемых языках может не так просто всё, но если это кому то нужно, то структуру программы, алгоритмы и все остальное восстановить не будет невозможным.
Вообще, любопытно, как изменилось внимание к этому вопросу. Еще недавно половина приложений паковалась UPX и ASPack'ом, а сейчас веб-приложения вообще нараспашку, а приложения на управляемых языках зачастую легко декомпилируются вплоть до восстановления имен переменных, и никого это, вроде как, особо не напрягает.
Дайте мне исходники 10 самых популярных приложений из мобильного маркета. Пожалуйста. В личную почту.
А вы в ответ готовы дать денег или что-то аналогичное?
1000 баксов за скайп под iOS сразу. Куда перечислить?
Какая-то у вас низкая оценка трудозатрат. Считаете, что 1 приличный специалист с лёгкостью справится за 1 неделю?

P.S. Благодарю за приятные моменты проведённые за вашими игрушками 90х на наших школьных 286х.
Было заявлено, что приложения легко декомпилируются. Какая такая «неделя»?
а приложения на управляемых языках зачастую легко декомпилируются


Не выдирайте из контекста. Или скайп из этих?
Так это не ко мне должен быть вопрос, а к PapaBubaDiop :)
PapaBubaDiop вроде ничего про легко не говорил.
В ответ на сообщение о том, что приложения на управляемых языках легко декомпилируются, он попросил исходники 10 самых популярных приложений из мобильного маркета, а в следующем комментарии — конкретно скайпа.
За неделю упорного труда можно свой клиент сотворить. Хотя, если честно, и трех дней хватит, используя стековерфлоу.
исходники 10 самых популярных приложений

Не знаю, как там мобильные приложения. Но смотрю на пример Майнкрафта и всяких Java-вирусов для мобильных телефонов. И то, как легко они из скомпиленного кода превращаются в исходники.

А вообще клиент является совершенно беззащитным. Защититься можно только имея обязательную серверную часть.
Тонкие приложения в той или иной форме уже есть сейчас. А вот массовые тонкие клиенты в виде удаленной работы на сервере не появятся еще долго, очень долго. О чем там говорить, я пока даже cleartype не могу включить когда работаю на серверах в Америке, трафик растет в несколько раз (из-за выключения glyph caching) и все, терминал начинает выдавать пару кадров в секунду. Да, лет через 30-40, когда последняя миля будет не 1, 10, 100 МБит, а в 1000 раз больше, появятся новые каналы и технологии — тогда может все это и взлетит.

А тонкие приложения это просто — если оно не тормозит у пользователя (по любой причине), то будущее уже наступило. else: try again tomorrow.
Дело не в скорости, а пинге. А он может буть уменьшен только до предела, который ограничен скоростью света. Т.е. если до сервера в Штатах 9000км, то пинг никак не будет меньше 60мс, даже если прямой кабель проложить. А этот пинг уже очень ощутим при работе инферфейса, не говоря уже о том, что это недостижимый идеал.
Ну да, поэтому я и написал «может» :). Теоретически скажем мощные ЦОД могли бы располагаться в каждом крупном городе, а компании снимали бы у них мощности под свои приложения и раздавали бы их в виде тонких клиентов. Правда к тому времени у каждого в кармане будет эквивалент Blue Gene или что-то еще круче и все просто упрется в рентабельность написания софта под зоопарк разных платформ.
Ну оптимально — тяжелые операции делать в ДЦ, а интерфейс локально. И нативность тут пока очень даже рулит, полагаю, в будущем ничего не поменяется. Сколько поколений компьютеров сменилось, а разница между какой-нибудь джавой или флешом и нативной программой заметна на глаз.
А можно ли как то получить в веб приложении, работающем на мобильном устройстве, достум к сведениям о географических координатах?
Geolocation API (W3C Proposed Recommendation от 10 мая 2012 года).

Поддерживается всеми нынешними версиями браузеров, окромя Opera Mini.

Из прежних же версий следует отметить отсутствие поддержки в Internet Explorer версии 8 и более ранних версий. (А в IE9 может подглючивать).
Иногда в мобильном приложении даже джава не подходит — приходится переходить на нативный код, типа C/C++ под андроид и Objective-C под iOS.
У нас для проекта свой VoIP клиент мобильный — джаву выкинули, потому что размер, качество и быстродействие были просто отвратительными, сделали всё в нативном коде и по этой причине у нас качество лучше многих других (это не отменяет того, что каналы связи в некоторые у провайдеров просто неахти).

Да взять то же приложений фейсбука — у меня Galaxy Tab P-1000, на сегодня далеко не мощьная железка, но Angry Birds летает без проблем, свежий Bad Piggies взлетел на ура, 720p играет без проблем, Opera Mobile летает. Приложение от фейсбука это просто адская тормозиловка. Да ещё и размер у него 30 мегабайт. КУДА СТОЛЬКО?! А функционал просто уродский — разве что читать свою ленту + отвечать на сообщения в чат. Больше в нём делать ничего нельзя — или зависнет, или функционал глючит, или просто нету нужной фишки. И все это с жуткими лагами интерфейса.
Так что Native ещё очень долго будет лучше. Просто потому, что оно быстрее, жрёт меньше ресурсов и занимает меньше места.
UFO just landed and posted this here
UFO just landed and posted this here
Основная проблема, с которй столкнулся — это когда веб-разработчики получают доступ к, например, андроиду, слышат слово html5 и начинают что-то делать под него так, как будто не на мобильнике запускаются, а на обычном браузере.
Ну, в идеале, конечно, ни в чём. Но когда страница загружается на wifi по 30с (gprs — это вообще смерть всему живому), наверное, всё-таки это не правильно для мобильного приложения.
«Технология хочет» — это очень умилительно, когда отдельно взятый индивидуум из IT знает чего хочет технология. Или ему хочется так думать? Разница между нативными приложениями и веб-ориентированными примерно такая же как между компилируемыми языками и нет. Прошло уже куча времени, а С до сих пор жив почему то. JavaScript HTML5 CSS3 и другие примочки при всем желании не смогут сравнится с нативными приложениями по определенным параметрам. Опять же — надо смотреть на задачи. Есть задачи, где нет разницы на чем реализовывать, есть задачи, где преимущества одного решения над другим будут очевидны. А тут белки-истеричны открыли для себя еще одну панацею.
Халивар в комметах, причем, в основном не о тонких и толстых клиентах, а о нативных и кроссплатформенных вариантах решения.

Абсолютно тонкий клиент для современной мобилы (wireless device) должен иметь функционал тач-экрана, связанного с удаленным сервером.
Задачи такого тонкого клиента сводятся к следующей последовательности:
1. Получить инфу от сервера (может быть даже в виде целых скринов);
2. Отобразить полученную инфу;
3. Получить инфу по тачам юзера;
4. Отправка тачей на сервер.

Как правило, по мере утолщения клиента последовательно появляются следующие фичи:
1. Вместо целых скринов брать от сервера и отображать контент описательного характера (это ж HTML!)
2. Отправлять на сервер не тачи с экрана, а инфу о взаимодействию юзера с активными элементами GUI
3. Уметь кешировать для дальнейшего использования некоторые данные от сервера (для разгрузки канала и сервера)
4. Производить «тяжелые» операции с кешированными данными
5. Быть все более функционально автономным от сервера
6. Отправлять на сервер результаты вычислений (для хранения и/ли многопользовательского использования)

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

Но даже самая крутая кроссплатформа, как и любое универсальное решение может иметь свои ограничения (например, по ресурсоемкости/скорости или по кастомизации GUI), которые могут нивелировать в ноль плюсы ее применения.
И вот тут-то становится явным, что без натива — никуда.

И еще, имхо, кроссплатформенные тонкие клиенты лучше всего подходят для прототипирования (в широком смысле) решения, т.к. это не трудоемко.
Для серьезных, «устоявшихся» решений скорее всего потребуется толстый нативный клиент, Но далеко на каждый проект доживает до такого этапа.
Sign up to leave a comment.

Articles