1. Реализация интерфейса взаимодействия с пользователем через веб-приложение, вся работа приложения с использованием HTML + CSS + JS, а не нативное приложение.
2. Только если требуется какая-то специальная обработка (о чем было сказано в обсуждении выше) — естественно натив, но натив на любой вкус и цвет, а не только Андроид-API и ява, C# или др., но и они в том числе. Эта серверная часть только для исключительных вещей типа реалтайм.
3. На стороне удаленного сервера точно так же возможна обработка и хранение значительных объемов данных, а работа веб-приложения на стороне клиента — тонкий клиент-приложение.
Будьте внимательнее, пожалуйста, при чтении ветки диалога, прежде чем ляпнуть что-то невпопад.
Вы меня немного не правильно понимаете. Я не принижаю натив ниже того уровня, на котором он должен быть, потому как в силу объективных обстоятельств производители ОС для мобильных устройств просто обязаны возвышать натив-приложения, дабы продвинуть свою ОС на как можно большее количество мобильных устройств. Это обусловлено тем, что работая с нативными приложениям, пользователю уже сложнее сменить платформу, задаваясь вопросом — а будет ли тот же самый набор приложений на другом мобильнике, на другой ОС? Ответ чаще всего будет отрицательным. Таким образом мы имеем обычный захват рынка — будь то гугл или эпл — не важно. Только одна причина. Все элементарно просто.
Да и по ходу ответов как раз любители натива более предрасположены называть связку HTML+JS костылями, кривой, неприспособленной и т.д.
Совершенно иная ситуация с веб-приложениями — тут априори считается, что разработчику достаточно один раз написать приложение, правильно, по стандартам написать, и оно будет работать практически везде, где есть браузер, нормально отображающий информацию Интернет. Все механизмы давно испробованы на практике. Множество инструментов для разработки. Интернет. Какие могут быть еще доказательства состоявшейся и работоспособной технологии? Но на данный момент ни один из производителей ОС для мобильных устройств не заинтересован в свободном блуждании пользователей с платформы на платформу, пока рынок не обрел более-менее определенные очертания и процентные соотношения.
И еще один момент. Я считаю, что будут как веб-приложения, так и натив. Тут не будет какого-то абсолютного победителя. Поделят нишу приложений. Но уже и не будет такого убеждения, что для мобильников только натив — наиболее верное решение.
Вы сами ответили на свой вопрос почти.
В том-то и дело, что реализовать интерфейс, взаимодействие с пользователем гораздо проще на html, чем пилить натив.
И, к тому же, всю бизнес-логику, моделирование, обработку информации в веб-приложении разработчик может реализовать на стороне сервера — как ему удобно и, главное, удобными ему средствами, а не только одним-единственным любезно предоставленным API для натив.
Разделяй и властвуй!
Конечно же нет! Не говорите такого… всему свое время… только разработчики это понимают. Если Вам не жалко своих усилий, то можете смело писать мобильные натив-приложения для этого переходного периода мобильных устройств. Но, как правило, пользователи редко задаются вопросом, почему у интернет-магазина, например, нет мобильной версии, пользуются успешно сайтом. Придет время все это успешно вдруг как-будто появится и на мобилах в виде веб-приложений, чего на нативе я пока не особо наблюдаю. Все дело в том, что полноценные мобильные устройства — это совсем не то, что мы сейчас имеем — мобильные телефоны с кучей ограничений. Всему свое время.
Вот-вот… тут-то и выходят на сцену шаманы на костылях. А как здорово все начиналось — мобильный натив может все!
Если далее рассуждать и продолжить в том же направлении, то можно запросто поставить и веб-сервер, сделать критичные вещи на серверной части, а интерфейс для пользователя — через веб-приложение. И остались от натива рожки, да ножки. Нет, конечно натив есть — серверные скрипты, но, согласитесь, это уже несколько иной натив… совсем уже не Андроид, и совершенно не обязательно ява.
Во-первых, для систем реального времени я бы выбрал другую ОС, а далее уже надо смотреть — какие средства для построения интерфейса там имеются. Но лучше всего я бы предпочел распределенную систему:
1. система реального времени, которая производит сбор информации, реагирование на события, выдачу управляющих сигналов и передачу информации в систему №2 (если имеются какие-то статистические данные);
2. обработка и хранение информации, взаимодействие с пользователями на уровне интерфейса, а интерфейс я все же предпочел бы на HTML, как ни крути. Лишние головняки с натив мне совершенно ни к чему.
Ну так-то совсем не обязательно использовать весь стандарт, даже не обязательно весь его знать, а обращаться к нему по мере необходимости, во-вторых — толщина стандарта, как мне кажется, говорит о том, что продуманы многие мелочи, что очень даже не плохо.
А с каких это пор у нас Андроид (или iOS) стал системой реального времени? Вы вообще представление хотя бы имеете о том, о чем говорите? Если даже в самой статье было указано на то, что музыка прерывается в момент приема текстового сообщения. В данном случае я бы даже остерегся говорить хотя бы о нормальной многозадачности, какой уж там реалтайм!
«Или вообще с любыми критическими секциями» — конкретнее, пожалуйста, если можно.
Была бы нужда… Вопрос в другом, и я его задал как встречный. Вы же тут пытаетесь утверждать, что невозможно реализовать удобный и понятный интерфейс на HTML + JS. А вы попробуйте хотя бы нечто похоже на натив изобразить. Или все же проще «сам дурак!»?
Можно подробнее про ржавые костыли HTML5, покрытые пылью времен, которые так мешают, видимо, Вам свободно передвигаться Вашим разработкам? Просто до сих пор как-то ни разу не столкнулся с чем-то, что не смог бы реализовать с помощью Ruby или PHP (серверная часть) + HTML + CSS + JS.
Очень хочется узнать!
С успехом реализовано inet777.ru/portfolios/57/adminka-ruby-on-rails в довольно короткие сроки. Я даже связываться с натив не хочу — мне чисто-нативных приложений хватило в 90-е, ассемблер — вот где экстрим, вот где натив в чистом виде!
Встречный вопрос к Вам — раелизуЙ мне хотя бы похожий интерфейс на натив?
Вы действительно полагаете, что сложную задачу будет проще реализовать на натив? Уж не поэтому ли сейчас разработчики берутся за написание натив-приложения в 5 раз дороже, чем веб-приложения, что это как минимум в 5 раз сложнее, а следовательно — еще более усложняет процесс написания и без того сложных задач. Или Вы полагаете, что натив — это волшебная палочка, которая делает сложное — простым? Вот мое мнение, что как раз с точностью до наоборот.
Важно понимать, что сравнивать надо не сайты, в том виде, в котором они сейчас есть, и натив, а именно веб-приложения под мобильные веб-ОС, такие как Firefox OS, и натив под тот же Андроид.
Сейчас основным и наверное единственным преимуществом натива является работа с оборудованием как бы напрямую (хотя на самом деле все же через определенный API). Погодите совсем немного, будет Вам API такого же плана и для HTML5. Вот тогда и поглядим, что проще и эффективнее для разработки, и как следствие, для появления разнообразных и полезных приложений. Что сейчас может предложить натив? Навигация, музыка, фотки, соцсети, мало-мальские игры… я что-то пропустил?
А что Вы делаете, когда у Вас на десктопе нативное приложение, которое проигрывает музыку, свернуто (убрано с экрана) или просто рядом с другим приложением (что проблематично на маленьких экранах мобилок, где экранное пространство на вес золота). Или каким-то чудесным образом оно «услышит» Вас, что вы обращаетесь именно к нему, когда Вы работаете в другом приложении? В любом случае Вы сначала переключаетесь на то приложение, потом ставите на паузу — и уже не столь важно — вкладка это или значок в таскбаре.
Еще один момент заслуживает внимания.
Насколько это «бывалый веб-разработчик»? Довольно странно, как он все преимущества веб-разработки вмиг позабыл и даже не упомянул о них для честного сравнения. Или это один из тех, кто меняет средства разработки, ОС, технологии в надежде на то, что «вот тут-то у меня точно все получится!»?
К таким очень хорошо подходят слова из басни Крылов И.А. «Квартет»:
А вы, друзья, как ни садитесь;
Всё в музыканты не годитесь
Во-первых необходимо сравнивать сопоставимые вещи. Конечно, в ОС, где все ориентировано под натив, веб-приложению уделяется гораздо меньше внимания, чем следовало бы. И, скорее, это недоделки мобильных браузеров, чем какие-то проблемы веб-приложений.
Давайте будем честными и будем тогда сравнивать Android, iOS и Firefox OS, Tizen, Chrome OS. К слову, последние еще на стадии разработки — факт, но факт еще и в том, что после всего этого натива гиганты индустрии все же смотрят в сторону веб-приложений.
1. Интерфейс работы с оборудованием.
Опять же, я думаю, что в скором времени мы увидим прекрасные расширения стандарта HTML5 для работы с железом.
> По контрасту, парадигма веб-приложений — документо-центрична. Архетипичное веб приложение в основе визуально, находится в своей собственной песочнице и завершается, как только пользователь закрывает соответствующее окно браузера.
Что-то я не заметил, чтобы музыка, играющая на одной из вкладок моего браузера вдруг перестала играть, когда я переключаюсь на другую вкладку браузера, при этом никакой визуализации не требуется. Да, это на десктопном компе, но это опять же говорит не об ограниченности веб-приложений, а об ограниченности браузеров на мобилах.
2. Отсутствие повсеместного доступа в Интернет
А вот это уже чистой воды недостаток мобильных устройств. Не доросли пока мобильники до полноценных устройств.
2. Доступ к многим «видам (поверхностям)» отображения
Опять же, давайте рассматривать все же ОС, ориентированные на веб-приложения.
3. Фоновое управление памятью.
Одна из основных головных болей разработчика натива — управление памятью. Вообще-то когда ОС управляет памятью — это более правильно. Я пишу на Ruby и давным-давно уже забыл все эти «прелести» пожирания памяти, после перехода на системы разработки, где виртуальная машина исполнения сценария (назовем так) сама заботится о правильном выделении и освобождении памяти.
А тут это выдается за преимущество? Что за бред?
Насчет приоритетов приложения, тут тоже надо подумать… есть многозадачность… а то, что Андроид не может проигрывать музыку и тихонько без шума (без паузы) получить сообщение, так это наверное все же проблемы многозадачности Андроид.
4. Внешний вид
Да-да, давайте всех снова загоним под общие интерфейсы. При этом автор лукавит, говоря о фрагментированности веб-приложений, и умалчивая об еще бОльшей фрагментированности натив-приложений — когда даже под одну ОС приходится реализовывать множество версий приложений для конкретных мобильных устройств, отчасти именно благодаря различному разрешению устройств. И это благо? Сомневаюсь.
Возможно, автор просто как и Цукерберг — ниасилил. А точнее будет сказать, что надо подождать еще немного развития именно ОС ориентированных на веб-приложения, а потом уже делать выводы о том, что натив — это хорошо.
Сначала написал ответ… А потом подумал — оно мне зачем? Вы того не стоите.
Вам самому с этим жить — с таким Вашим внутренним миром — когда дабы только до чего зацепиться. Посоветую только более обращать внимание на смысл, содержание.
Придраться хоть к чему-то захотелось? Заняться больше ведь нечем, аха?
Да, я не всегда правильно по-русски пишу… и что из того?
Многие верят в Бога и даже читать не умеют, не то что писать. Или для того, чтобы цитировать Библию, надо отлично знать русский?
Нет, мне не кажется странным — спешу разочаровать Вас. Я думаю, что многие из контекста диалога даже поняли, что (т.е. Кого, простите великодушно) именно я имел ввиду, а Вы, видимо только читать умеете — написано с ошибкой — уже теряете нить мысли.
С Вашим «ясновидением», которое Вы тут демонстрируете, я бы поостерегся давать какие-то прогнозы.
Перспективность заключается хотя бы в уже существующей огромной инфраструктуре — Интернет, и достаточно большом количестве веб-разработчиков, в устоявшихся и проверенных временем и практикой стандартах HTML, CSS, JS, а если считать и серверную часть — тут вообще решений не счесть — на любой вкус!
2. Только если требуется какая-то специальная обработка (о чем было сказано в обсуждении выше) — естественно натив, но натив на любой вкус и цвет, а не только Андроид-API и ява, C# или др., но и они в том числе. Эта серверная часть только для исключительных вещей типа реалтайм.
3. На стороне удаленного сервера точно так же возможна обработка и хранение значительных объемов данных, а работа веб-приложения на стороне клиента — тонкий клиент-приложение.
Будьте внимательнее, пожалуйста, при чтении ветки диалога, прежде чем ляпнуть что-то невпопад.
Да и по ходу ответов как раз любители натива более предрасположены называть связку HTML+JS костылями, кривой, неприспособленной и т.д.
Совершенно иная ситуация с веб-приложениями — тут априори считается, что разработчику достаточно один раз написать приложение, правильно, по стандартам написать, и оно будет работать практически везде, где есть браузер, нормально отображающий информацию Интернет. Все механизмы давно испробованы на практике. Множество инструментов для разработки. Интернет. Какие могут быть еще доказательства состоявшейся и работоспособной технологии? Но на данный момент ни один из производителей ОС для мобильных устройств не заинтересован в свободном блуждании пользователей с платформы на платформу, пока рынок не обрел более-менее определенные очертания и процентные соотношения.
И еще один момент. Я считаю, что будут как веб-приложения, так и натив. Тут не будет какого-то абсолютного победителя. Поделят нишу приложений. Но уже и не будет такого убеждения, что для мобильников только натив — наиболее верное решение.
В том-то и дело, что реализовать интерфейс, взаимодействие с пользователем гораздо проще на html, чем пилить натив.
И, к тому же, всю бизнес-логику, моделирование, обработку информации в веб-приложении разработчик может реализовать на стороне сервера — как ему удобно и, главное, удобными ему средствами, а не только одним-единственным любезно предоставленным API для натив.
Разделяй и властвуй!
Если далее рассуждать и продолжить в том же направлении, то можно запросто поставить и веб-сервер, сделать критичные вещи на серверной части, а интерфейс для пользователя — через веб-приложение. И остались от натива рожки, да ножки. Нет, конечно натив есть — серверные скрипты, но, согласитесь, это уже несколько иной натив… совсем уже не Андроид, и совершенно не обязательно ява.
1. система реального времени, которая производит сбор информации, реагирование на события, выдачу управляющих сигналов и передачу информации в систему №2 (если имеются какие-то статистические данные);
2. обработка и хранение информации, взаимодействие с пользователями на уровне интерфейса, а интерфейс я все же предпочел бы на HTML, как ни крути. Лишние головняки с натив мне совершенно ни к чему.
Математика, моделирование? Да пожалуйста!
habrahabr.ru/post/174659/
«Или вообще с любыми критическими секциями» — конкретнее, пожалуйста, если можно.
Очень хочется узнать!
Встречный вопрос к Вам — раелизуЙ мне хотя бы похожий интерфейс на натив?
Сейчас основным и наверное единственным преимуществом натива является работа с оборудованием как бы напрямую (хотя на самом деле все же через определенный API). Погодите совсем немного, будет Вам API такого же плана и для HTML5. Вот тогда и поглядим, что проще и эффективнее для разработки, и как следствие, для появления разнообразных и полезных приложений. Что сейчас может предложить натив? Навигация, музыка, фотки, соцсети, мало-мальские игры… я что-то пропустил?
Насколько это «бывалый веб-разработчик»? Довольно странно, как он все преимущества веб-разработки вмиг позабыл и даже не упомянул о них для честного сравнения. Или это один из тех, кто меняет средства разработки, ОС, технологии в надежде на то, что «вот тут-то у меня точно все получится!»?
К таким очень хорошо подходят слова из басни Крылов И.А. «Квартет»:
А вы, друзья, как ни садитесь;
Всё в музыканты не годитесь
Во-первых необходимо сравнивать сопоставимые вещи. Конечно, в ОС, где все ориентировано под натив, веб-приложению уделяется гораздо меньше внимания, чем следовало бы. И, скорее, это недоделки мобильных браузеров, чем какие-то проблемы веб-приложений.
Давайте будем честными и будем тогда сравнивать Android, iOS и Firefox OS, Tizen, Chrome OS. К слову, последние еще на стадии разработки — факт, но факт еще и в том, что после всего этого натива гиганты индустрии все же смотрят в сторону веб-приложений.
1. Интерфейс работы с оборудованием.
Опять же, я думаю, что в скором времени мы увидим прекрасные расширения стандарта HTML5 для работы с железом.
> По контрасту, парадигма веб-приложений — документо-центрична. Архетипичное веб приложение в основе визуально, находится в своей собственной песочнице и завершается, как только пользователь закрывает соответствующее окно браузера.
Что-то я не заметил, чтобы музыка, играющая на одной из вкладок моего браузера вдруг перестала играть, когда я переключаюсь на другую вкладку браузера, при этом никакой визуализации не требуется. Да, это на десктопном компе, но это опять же говорит не об ограниченности веб-приложений, а об ограниченности браузеров на мобилах.
2. Отсутствие повсеместного доступа в Интернет
А вот это уже чистой воды недостаток мобильных устройств. Не доросли пока мобильники до полноценных устройств.
2. Доступ к многим «видам (поверхностям)» отображения
Опять же, давайте рассматривать все же ОС, ориентированные на веб-приложения.
3. Фоновое управление памятью.
Одна из основных головных болей разработчика натива — управление памятью. Вообще-то когда ОС управляет памятью — это более правильно. Я пишу на Ruby и давным-давно уже забыл все эти «прелести» пожирания памяти, после перехода на системы разработки, где виртуальная машина исполнения сценария (назовем так) сама заботится о правильном выделении и освобождении памяти.
А тут это выдается за преимущество? Что за бред?
Насчет приоритетов приложения, тут тоже надо подумать… есть многозадачность… а то, что Андроид не может проигрывать музыку и тихонько без шума (без паузы) получить сообщение, так это наверное все же проблемы многозадачности Андроид.
4. Внешний вид
Да-да, давайте всех снова загоним под общие интерфейсы. При этом автор лукавит, говоря о фрагментированности веб-приложений, и умалчивая об еще бОльшей фрагментированности натив-приложений — когда даже под одну ОС приходится реализовывать множество версий приложений для конкретных мобильных устройств, отчасти именно благодаря различному разрешению устройств. И это благо? Сомневаюсь.
Возможно, автор просто как и Цукерберг — ниасилил. А точнее будет сказать, что надо подождать еще немного развития именно ОС ориентированных на веб-приложения, а потом уже делать выводы о том, что натив — это хорошо.
Вам самому с этим жить — с таким Вашим внутренним миром — когда дабы только до чего зацепиться. Посоветую только более обращать внимание на смысл, содержание.
Всего хорошего Вам!
Да, я не всегда правильно по-русски пишу… и что из того?
Многие верят в Бога и даже читать не умеют, не то что писать. Или для того, чтобы цитировать Библию, надо отлично знать русский?
Нет, мне не кажется странным — спешу разочаровать Вас. Я думаю, что многие из контекста диалога даже поняли, что (т.е. Кого, простите великодушно) именно я имел ввиду, а Вы, видимо только читать умеете — написано с ошибкой — уже теряете нить мысли.
Перспективность заключается хотя бы в уже существующей огромной инфраструктуре — Интернет, и достаточно большом количестве веб-разработчиков, в устоявшихся и проверенных временем и практикой стандартах HTML, CSS, JS, а если считать и серверную часть — тут вообще решений не счесть — на любой вкус!