Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 47
>Если вы знаете HTML, JavaScript, CSS, jQuery и испытываете проблемы с Java, Objective-C и другими
то подумайте еще раз, возможно разработка под мобильные платформы не ваше призвание.
то подумайте еще раз, возможно разработка под мобильные платформы не ваше призвание.
Java, Objective-C это всего лишь инструменты для создания приложений. Клиентские веб разработчики тоже способны делать мобильные приложения не худшего качества — PhoneGap дает им прекрасную возможность.
Именно — это всего лишь инструменты, и мне непонятно позиция «я всю жизнь рубил деревья топором, потому гвозди забивать буду тоже топором»
В умелых руках топором можно и бомбардировщики сбивать. Я думаю, что веб-инструменты способны обеспечить качество мобильных приложений. В нашем деле главное качество и не важно чем оно будет обеспечено.
Если главное — качество, то тем более непонятно зачем такие инструменты.
Сходу можно назвать минусы:
1. никакущяя производительность.
2. будет жрать память
3. ненативный вид.
4. отсутствие плавных анимаций, еффектов итд — того, чем все платформы так любят сейчас мерится
5. отсутствие поддержки специфических для каждой платформы фич.
можно продолжить дальше.
Сходу можно назвать минусы:
1. никакущяя производительность.
2. будет жрать память
3. ненативный вид.
4. отсутствие плавных анимаций, еффектов итд — того, чем все платформы так любят сейчас мерится
5. отсутствие поддержки специфических для каждой платформы фич.
можно продолжить дальше.
Я вот веб-разработчик. Если мне понадобится какая-нибудь мелкая утилитка для моего андроидофона, я не буду тратить неделю, чтобы набросать ее на Java, а сделаю за день на том, что мне хорошо знакомо.
Согласен с вами, в идеале лучше писать нативные приложения, но
- во многих случаях производительности браузера будет достаточно,
- если не нужна работа в фоне, то для одного приложения памяти вполне хватит,
- у веб-приложений вполне себе нативный вид: dev.sencha.com/deploy/touch/examples/kitchensink/ — потыкайте там в темы. Открывать в Chrome или Safari,
- плавные анимации там же,
- да, это аргумент, но если нужно сделать приложение под обе платформы, то важны не специфические фичи, а переносимость кода.
не в бровь, а в глаз, браво!
загрузил линк в хроме, удивился что все довольно неплохо выглядит. Потом зашел с айфона и понял, что все намного хуже, чем я мог представить.
Простейшие анимации нереально тормозят, «нативный вид» почемуто отдает китайскими айфонами, производительности хватает только на то чтоб с УЖАСНЫМИ тормозами переключать елементы интерфейса. А что будет, если кроме интерфейса будет еще исполнятся хоть какаято логика?
Простейшие анимации нереально тормозят, «нативный вид» почемуто отдает китайскими айфонами, производительности хватает только на то чтоб с УЖАСНЫМИ тормозами переключать елементы интерфейса. А что будет, если кроме интерфейса будет еще исполнятся хоть какаято логика?
Ну с нативностью — это я приукрасил немного, но на айфоне контролы выглядят довольно прилично — большинство примеров я бы с первого взгляда не отличил от нативных, хотя некоторые и не совпадают с нативными, и анимация не тормозит (iPhone 4), на андроиде корявенько немного (наверное, из-за другого разрешения экрана контролы совпадают не пиксель-в-пиксель), но тоже тормозов не заметил — всё довольно живенько (LG Optimus Speed).
Вот например, достаточно не плохо pattern.dk/sun/
Начнем с того, что люди которые знают jQuery не могут называться людьми которые знают JavaScript. Это раз. Два, PhoneGap подходит только для создания «брэндового» приложения на коленке. Почему на коленке? Потому, что вменяемый заказчик отдаст это на аутсорс, а у ребят которые будут делать приложения уже есть десяток шаблонов для такого рода приложений. Не говоря уже о том, что PhoneGap медленный словно слоупок и проигрывает TitaniumApp практически во всем.
Теперь каждый может написать свое говно приложение для App Store!
Как впрочем и для остальных маркетов.
Не каждый говнописатель готов выложить 99$ за каждое приложение в App Store плюс не все проходят модерацию, вобщем качество достойное. Вот с Android Market не знаю какая ситуация.
Без аккаунта разработчика вы не скомпилируете приложение в Phone Gap, так как у вас не будет сертификатов. 99$ нужно заплатить один раз и тогда вы сможете год хоть миллион свои гавноприложений из PhoneGap публиковать. Только многие из них не пройдут проверку (особенно это касается интерфейса, он должен быть маквей, про это в правилах публикации отдельный пункт).
В последнем релизе JS-фреймворка QooXdoo разработчики начали экспериментировать с виджетами, заточенными под мобильные браузеры и в доках к релизу указали «Basic PhoneGap support». Надо будет пощупать.
Мануалы для мануалистов. Теперь и для Open Sourse)
Попробовал установить на андроид, и сразу передумал, когда увидел сколько он требует прав доступа. Это никуда не годится.
А под IOS не пробывали?
У меня нет возможности. Я считаю что требовать GPS и чтение SMS и ещё много всего для тестовой программы, которая показывает картинки — перебор. Я не говорю что здесь вирус, просто технология PhoneGap Build не понятна.
Вот ручной билд требует только
android.permission.INTERNETЧестно говоря ему нужно только гонять данные по сети, никаких фичей телефона ему не надо. Видимо PhoneGap Build требует все что есть по умолчанию. Пересоберу руками.
В чём потайной смысл так сильно использовать data-атрибуты вместо классов? Кажется, классы подходят, как нельзя кстати?
===>
rel, кстати, валиден и без data
<div data-role="page" id="dialog">
<div data-role="header">
<!-- Кнопка Назад -->
<a data-rel="back" data-icon="back">Back</a>
<h1>Image</h1>
<!-- Ссылка на полную версию - по клику откроется в браузере -->
<!-- about:blank будет заменяться на соответствующую ссылку -->
<a href="about:blank" data-icon="search" data-theme="b" id="full-image">Full</a>
</div>
<div data-role="content">
<!-- about:blank будет заменяться на путь к большой картинке -->
<p><img src="about:blank" /></p>
</div>
</div>
===>
<div class="page" id="dialog">
<div class="header">
<!-- Кнопка Назад -->
<a rel="back" class="back">Back</a>
<h1>Image</h1>
<!-- Ссылка на полную версию - по клику откроется в браузере -->
<!-- about:blank будет заменяться на соответствующую ссылку -->
<a href="about:blank" class="search" id="full-image">Full</a>
</div>
<div class="content">
<!-- about:blank будет заменяться на путь к большой картинке -->
<p><img src="about:blank" /></p>
</div>
</div>
rel, кстати, валиден и без data
C data-аттрибутами работает jQuery mobile.
(голосом Йоды) Смысл тайный в цифре 5 кроется…
Это особенность jQuery Mobile. jQM восновном предназначен для допиливаяния существующих веб-страниц. Разработчики предполагают, что мы не хотим портить имеющиеся атрибуты (class) поэтому они используют data- атрибуты для определения ролей элементов на странице.
Мда, выкладывайте на маркет. Посмотрите какие рейтинги получит ваше приложение.
Поставил и что я вижу:
— Смена ориентации экрана при просмотре картинки — прыгает на главную страницу.
— Просмотр картинки — картинка занимает 10% площади экрана и pinch-to-zoom не работает, нет стандартных zoom controls. Я уж не говорю про листалку сдвигом пальцев с права на лево.
Я расцениваю это как издевательство над пользователем и более одной звезды программа на маркете бы не получила.
Поставил и что я вижу:
— Смена ориентации экрана при просмотре картинки — прыгает на главную страницу.
— Просмотр картинки — картинка занимает 10% площади экрана и pinch-to-zoom не работает, нет стандартных zoom controls. Я уж не говорю про листалку сдвигом пальцев с права на лево.
Я расцениваю это как издевательство над пользователем и более одной звезды программа на маркете бы не получила.
Скажите, а зачем приложению столько разрешений? И смс получать, и подробную информацию о местоположении.
Кросс-платформенность не есть благо как таковое.
Пользователь, выбирая тот или иной телефон, фактически обозначает свои предпочтения. В т.ч. — к интерфейсу и способу работы с устройством. Но дело даже не в привычности иконок и построении интерфейса. Гораздо важнее — соблюдение идеологии мобильной платформы. Стандартные сценарии использования мобильного устройства сильно различаются у пользователей iOS, WM & Android.
Даже если вы пишите какое-либо маленькое приложение, подумайте несколько раз, стоит ли экономить на нормальной разработке и использовать подобные кросс-платформенные решения.
Пользователь, выбирая тот или иной телефон, фактически обозначает свои предпочтения. В т.ч. — к интерфейсу и способу работы с устройством. Но дело даже не в привычности иконок и построении интерфейса. Гораздо важнее — соблюдение идеологии мобильной платформы. Стандартные сценарии использования мобильного устройства сильно различаются у пользователей iOS, WM & Android.
Даже если вы пишите какое-либо маленькое приложение, подумайте несколько раз, стоит ли экономить на нормальной разработке и использовать подобные кросс-платформенные решения.
Для разработчика — ещё какое благо!
Представьте себе какой-нибудь сервис, который доступен через мобильные клиенты (скажем, Foursquare). На начальном этапе денег/времени/ресурсов очень не хватает (хотя лишними они не бывают не только на начальном этапе, но и вообще никогда :)). Постановка задачи: нужно написать клиентское приложение под распространённые мобильные платформы. И понеслось: Objective-C для iPhone, Java с Android SDK для Android, Java с BlackBerry SDK для BlackBerry, C++ с Qt для Symbian, на подходе C# для WP7. Разработчики смотрят на это дело, после чего обхватывают голову руками и долго, протяжно, с чувством: «Ой бляяяяяя.....»
Или берут кросс-платформенный фреймворк и покрывают их все за один присест.
Представьте себе какой-нибудь сервис, который доступен через мобильные клиенты (скажем, Foursquare). На начальном этапе денег/времени/ресурсов очень не хватает (хотя лишними они не бывают не только на начальном этапе, но и вообще никогда :)). Постановка задачи: нужно написать клиентское приложение под распространённые мобильные платформы. И понеслось: Objective-C для iPhone, Java с Android SDK для Android, Java с BlackBerry SDK для BlackBerry, C++ с Qt для Symbian, на подходе C# для WP7. Разработчики смотрят на это дело, после чего обхватывают голову руками и долго, протяжно, с чувством: «Ой бляяяяяя.....»
Или берут кросс-платформенный фреймворк и покрывают их все за один присест.
Послушайте меня внимательно.
То, что в проекте на разработку потрачено меньше времени — это еще не благо для проекта в целом. Это просто на написание кода потрачено меньше времени. Но проект в большинстве стучаев состоит не только из написания кода. Будет ли это хорошо для результата — вот это вопрос! Даже из этого обсуждения видно, что всё равно гладкой работы под все без исключения устройства такая система не даёт, всё равно возникают проблемы на разных устройствах, и надо всё тестировать и проверять.
Но моя мысль была даже не об этом. Такое упрощение программирования хорошо только в том случае, если речь идёт о некоей библиотеке интерфейса, резализующей, к примеру, API социального веб-ресурса, тогда да, скорее всего, кросс-платформенность в этом случае будет полезна. Ну, или написание какого-нибудь специфического драйвера over-HTML. Т.е. в тех случаях, когда не затрагивается взаимодействие с пользователем.
Если же продукт непосредственно взаимодействует с пользователем, то тут простая кросс-платформенность — зло прямое. Ибо кросс-платформенность подразумевает, что продукт будет выглядеть одинаково на всех мобильных платформах, а это плохо. У каждой платформы свои особенности интерфейса, но кроме этого, свой типичный профиль использования. Т.е. пользователи разных мобильных платформ используют их для решения разных задач. Если приложение реализует нечто большее, чем «Hello world!», то надо прорабатывать сценарии взаимодействия, а они для каждой мобильной платформы скорее всего окажутся разными. Более того, после проработки сценариев вполне может оказаться, что для какой-нибудь платформы и нет необходимости реализовывать данное приложение! А для другой — маст хев!
Можно ли не прорабатывать сценарии использования? Вам решать… Это зависит от того, насколько хорошего результата вы хотите добиться своим продуктом. Если вам интересно просто написать код, чтобы написать код — то сценарии не нужны. А если вы хотите заработать денег и выбиться в лидеры, то без этого не обойтись.
То, что в проекте на разработку потрачено меньше времени — это еще не благо для проекта в целом. Это просто на написание кода потрачено меньше времени. Но проект в большинстве стучаев состоит не только из написания кода. Будет ли это хорошо для результата — вот это вопрос! Даже из этого обсуждения видно, что всё равно гладкой работы под все без исключения устройства такая система не даёт, всё равно возникают проблемы на разных устройствах, и надо всё тестировать и проверять.
Но моя мысль была даже не об этом. Такое упрощение программирования хорошо только в том случае, если речь идёт о некоей библиотеке интерфейса, резализующей, к примеру, API социального веб-ресурса, тогда да, скорее всего, кросс-платформенность в этом случае будет полезна. Ну, или написание какого-нибудь специфического драйвера over-HTML. Т.е. в тех случаях, когда не затрагивается взаимодействие с пользователем.
Если же продукт непосредственно взаимодействует с пользователем, то тут простая кросс-платформенность — зло прямое. Ибо кросс-платформенность подразумевает, что продукт будет выглядеть одинаково на всех мобильных платформах, а это плохо. У каждой платформы свои особенности интерфейса, но кроме этого, свой типичный профиль использования. Т.е. пользователи разных мобильных платформ используют их для решения разных задач. Если приложение реализует нечто большее, чем «Hello world!», то надо прорабатывать сценарии взаимодействия, а они для каждой мобильной платформы скорее всего окажутся разными. Более того, после проработки сценариев вполне может оказаться, что для какой-нибудь платформы и нет необходимости реализовывать данное приложение! А для другой — маст хев!
Можно ли не прорабатывать сценарии использования? Вам решать… Это зависит от того, насколько хорошего результата вы хотите добиться своим продуктом. Если вам интересно просто написать код, чтобы написать код — то сценарии не нужны. А если вы хотите заработать денег и выбиться в лидеры, то без этого не обойтись.
«Да-а-а, учитель....»
Если стартапер будет с самого начала делать «как правильно» (прорабатывать сценарии, разбираться с платформо-специфичным фреймворком, писать нативное приложение под каждую платформу, ...), то он имеет все шансы или не запустить свой сервис вообще, или значительно сузить охват аудитории (ограничив набор платформ). Или вообще сдать позиции другому (с похожей идеей), который не заморачивался «как правильно». Почитайте классиков (того же Кавасаки): продукт надо выводить на рынок быстро (внимание: это не значит, что нужно выводить на рынок сырой продукт).
И дело даже не столько в том, чтобы опередить конкурентов, а в том, что понять потребность рынка можно только продуктом. Никакие расчёты и исследования этого не заменят. Поэтому идеальный вариант в этом случае: быстро сделать работающий прототип, запустить, посмотреть на результат — и уже после того, как продукт «пошёл», заморачиваться (или не заморачиваться) нативными приложениями.
Пока один будет делать «как правильно», потратит год и в итоге его сервис не пойдёт, второй 3-4 раза проведёт «разведку боем», нащупает работающую идею и уже после этого сделает «как надо».
Отдельное спасибо за «кросс-платформенную библиотеку для API социального ресурса». Единая библиотека для Obj-C, Java, C++ и C# — это, должно быть, будет очень хорошая библиотека :)
Особенно с учётом того, что подобное API в большинстве случаев — банальный набор REST/JSON-запросов, и куда проще реализовать соответствующий модуль нативно для каждой платформы, чем прикручивать костылями какой-нибудь JavaScript/Lua (на котором, скорее всего, она и будет реализована).
Если стартапер будет с самого начала делать «как правильно» (прорабатывать сценарии, разбираться с платформо-специфичным фреймворком, писать нативное приложение под каждую платформу, ...), то он имеет все шансы или не запустить свой сервис вообще, или значительно сузить охват аудитории (ограничив набор платформ). Или вообще сдать позиции другому (с похожей идеей), который не заморачивался «как правильно». Почитайте классиков (того же Кавасаки): продукт надо выводить на рынок быстро (внимание: это не значит, что нужно выводить на рынок сырой продукт).
И дело даже не столько в том, чтобы опередить конкурентов, а в том, что понять потребность рынка можно только продуктом. Никакие расчёты и исследования этого не заменят. Поэтому идеальный вариант в этом случае: быстро сделать работающий прототип, запустить, посмотреть на результат — и уже после того, как продукт «пошёл», заморачиваться (или не заморачиваться) нативными приложениями.
Пока один будет делать «как правильно», потратит год и в итоге его сервис не пойдёт, второй 3-4 раза проведёт «разведку боем», нащупает работающую идею и уже после этого сделает «как надо».
Отдельное спасибо за «кросс-платформенную библиотеку для API социального ресурса». Единая библиотека для Obj-C, Java, C++ и C# — это, должно быть, будет очень хорошая библиотека :)
Особенно с учётом того, что подобное API в большинстве случаев — банальный набор REST/JSON-запросов, и куда проще реализовать соответствующий модуль нативно для каждой платформы, чем прикручивать костылями какой-нибудь JavaScript/Lua (на котором, скорее всего, она и будет реализована).
Ваш пример утопичен ровно в той же степени, что и мой. В некоторых случаях нет денег на повторый выпуск продукта. И в этом плане гораздо правильнее на начальном этапе определиться с приоритетной платформой и сосредоточить усилия на выпуске одного продукта, для одной платформы и сделать его хорошо. А уже потом прорабатывать варианты для других платформ.
Про библиотеку. Пример, может, действительно не слишком удачен, но Вы поняли, что я имел ввиду. При наличии в продукте интерфейса взаимодействия с пользователем главное — построить наиболее удобную для пользователя систему.
Вы пропагандируете подход всех китайско-тайваньских производителей телефонов: как можно быстрее заимплементить какую-либо фичу и выкинуть продукт на рынок. Такие продукты интересны гикам, но не массовому потребителю. Многие ли помнят сейчас HTC Universal? Один из самых-самых первых девайсов с поддержкой сетей 3G и функцией видео-вызова. Ну, сделали его, продали какие-то слёзы (хотя я тут видел мужика в тролейбусе с этим девайсом). Всех победили? Нет. Зато через много лет пришел Стив Джобс и сказал: «Ребята, вот девайс с прекрасно работающей функцией видео-вызова — iPhone 4!» И все iSheep-еры бросились в магазины.
Безотносительно религиозности пользователей яблочной продукции, этот пример повторяет старый анекдот про двух быков — молодого и зрелого. "… нет, мы пойдем медленно-медленно и поимеем ВСЁ стадо!"
Поэтому я и говорю, что кросс-платформенность, в своем понятии «быстро-быстро наштампуем приложений под все платформы» — это зло! Причем, не открытое зло, а зло, способное убить проект наиболее изощрённым способом — когда продукт уже либо готовится к выпуску, либо уже выпущен, т.е. когда уже поздно вносить кардинальные изменения. Я уже не раз лично сталкивался с проектами, которые когда-то были сделаны именно по этому принципу (быстренько портируем), но теперь находятся в состоянии стогнации, ибо уже упёрлись в ограничения, обусловленные использованием кросс-платформенных систем, а переписывать заново с нуля в native code уже никто не хочет или не может.
Короче, давайте закончим этот спор. Я говорю о том, что кросс-платформенность это вещь, которой надо пользоваться с большой осторожностью, и что она несёт в себе вполне определённые риски (про что совсем нет упоминания в статье топикстартера), а вы пытаетесь аргументировать, что кросс-платформенность — это быстро, и это главное. Думаю, каждый останется при своем мнении…
Про библиотеку. Пример, может, действительно не слишком удачен, но Вы поняли, что я имел ввиду. При наличии в продукте интерфейса взаимодействия с пользователем главное — построить наиболее удобную для пользователя систему.
Вы пропагандируете подход всех китайско-тайваньских производителей телефонов: как можно быстрее заимплементить какую-либо фичу и выкинуть продукт на рынок. Такие продукты интересны гикам, но не массовому потребителю. Многие ли помнят сейчас HTC Universal? Один из самых-самых первых девайсов с поддержкой сетей 3G и функцией видео-вызова. Ну, сделали его, продали какие-то слёзы (хотя я тут видел мужика в тролейбусе с этим девайсом). Всех победили? Нет. Зато через много лет пришел Стив Джобс и сказал: «Ребята, вот девайс с прекрасно работающей функцией видео-вызова — iPhone 4!» И все iSheep-еры бросились в магазины.
Безотносительно религиозности пользователей яблочной продукции, этот пример повторяет старый анекдот про двух быков — молодого и зрелого. "… нет, мы пойдем медленно-медленно и поимеем ВСЁ стадо!"
Поэтому я и говорю, что кросс-платформенность, в своем понятии «быстро-быстро наштампуем приложений под все платформы» — это зло! Причем, не открытое зло, а зло, способное убить проект наиболее изощрённым способом — когда продукт уже либо готовится к выпуску, либо уже выпущен, т.е. когда уже поздно вносить кардинальные изменения. Я уже не раз лично сталкивался с проектами, которые когда-то были сделаны именно по этому принципу (быстренько портируем), но теперь находятся в состоянии стогнации, ибо уже упёрлись в ограничения, обусловленные использованием кросс-платформенных систем, а переписывать заново с нуля в native code уже никто не хочет или не может.
Короче, давайте закончим этот спор. Я говорю о том, что кросс-платформенность это вещь, которой надо пользоваться с большой осторожностью, и что она несёт в себе вполне определённые риски (про что совсем нет упоминания в статье топикстартера), а вы пытаетесь аргументировать, что кросс-платформенность — это быстро, и это главное. Думаю, каждый останется при своем мнении…
>Вы пропагандируете подход всех китайско-тайваньских производителей телефонов: как можно быстрее заимплементить какую-либо фичу и выкинуть продукт на рынок. Такие продукты интересны гикам, но не массовому потребителю.
Вы плохо читали то, что я написал. Или просто не понимаете, о чём я говорю.
>Я говорю о том, что кросс-платформенность это вещь, которой надо пользоваться с большой осторожностью, и что она несёт в себе вполне определённые риски (про что совсем нет упоминания в статье топикстартера), а вы пытаетесь аргументировать, что кросс-платформенность — это быстро, и это главное.
И снова я убеждаюсь в своём мнении: вы не поняли основной мысли. Не говоря уже о том, что я полностью разделяю вашу позицию «кросс-платформенность это вещь, которой надо пользоваться с большой осторожностью, и что она несёт в себе вполне определённые риски» (которая при этом никак не противоречит тому, о чём говорю я).
Если вам показалось, что я вижу в мобильных кросс-платформенных фреймворках этакую «серебряную пулю» — то вам это действительно показалось. Однако у них есть определённая ниша. Доволно узкая, но есть.
В общем, давайте действительно на этом закончим.
Вы плохо читали то, что я написал. Или просто не понимаете, о чём я говорю.
>Я говорю о том, что кросс-платформенность это вещь, которой надо пользоваться с большой осторожностью, и что она несёт в себе вполне определённые риски (про что совсем нет упоминания в статье топикстартера), а вы пытаетесь аргументировать, что кросс-платформенность — это быстро, и это главное.
И снова я убеждаюсь в своём мнении: вы не поняли основной мысли. Не говоря уже о том, что я полностью разделяю вашу позицию «кросс-платформенность это вещь, которой надо пользоваться с большой осторожностью, и что она несёт в себе вполне определённые риски» (которая при этом никак не противоречит тому, о чём говорю я).
Если вам показалось, что я вижу в мобильных кросс-платформенных фреймворках этакую «серебряную пулю» — то вам это действительно показалось. Однако у них есть определённая ниша. Доволно узкая, но есть.
В общем, давайте действительно на этом закончим.
Попробовал поставить на Nokia 5800 — не работает. Открывается страница без скриптов и стилей.
Что-то не получается взлететь в простом приложении с русским языком, все везде в UTF8. в свойствах проекта-тоже, а все равно кракозябры
Приложение вылетает при запуске. Делал все по инструкции
An internal error occurred during: «Launching HelloPhoneGap».
java.lang.NullPointerException
При запуске выдаётся такое сообщение. В чём может быть дело? Всё делал в точности как в статье, никаких «пустых ссылок» не нашёл. Жаль, что не показывает где конкретно проблема — файл и номер строки.
java.lang.NullPointerException
При запуске выдаётся такое сообщение. В чём может быть дело? Всё делал в точности как в статье, никаких «пустых ссылок» не нашёл. Жаль, что не показывает где конкретно проблема — файл и номер строки.
Кто работал с phonegap, можно ли в нем открывать 2-е окно браузера фоном и дергать из него данные?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка мобильных приложений на PhoneGap и jQuery Mobile