Отладка javascript на мобильных устройствах

    Недавно возникла у меня необходимость создать небольшое html5 приложение для смартфонов.
    Почему html5? Все предельно просто: при наличии мобильной версии, сайт можно за пару дней допилить до необходимого состояния или же написать с нуля (что не так важно) и в дальнейшем заниматься поддержкой только одной версии кода, не распыляясь на различные платформы.

    Для сборки приложения я использовал Phonegap (не буду вдаваться в описания тулзы, так как статей на хабре хватает). HTML, javascript вроде был отлажен на десктопе, успешно собран и залит на тестовые смартфоны, однако не все так гладко. В процессе тестирования мне пришлось столкнуться с несколькими глюками свойственными, только конкретным платформам и браузерам ( Скажем в android 2.1-2.2 если вставить input с обработчиком какого-либо события в определенное место DOM, баузер будет просто падать и главное тут ничего не поделать, это чисто баг андройда и его браузера, эта проблема «попортила мне не мало крови», так как в начале я не понимал что вообще происходит и грешил на кривой phonegap, пока не подключился дебагером и не посмотрел что там происходит).

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

    Для отладки html приложения под андройд неплохо подойдет Eclipse (скорей всего вы используете именно его для сборки приложения). Если у вас установлен android sdk и плагин для eclipse ( если нет, пройдя по ссылочке это можно исправить ), то во вьюшках можно найти logCat, который при подключении к устройству будет выводить все полученную информацию, в том числе и сообщения console.log() выводимые javascript'ом + выводятся все действия производимые с телефоном, это помогает отлаживать если есть какие-то проблемы с обработкой событий.
    LogCat можно кстати использовать и без эклипса, это инструмент android sdk, но по мне такой вариант не совсем удобен.

    Для iphone есть неплохая утилитка weinre, кстати её рекомендуют ребятки из phonegap. Более конктено с ней можно ознакомиться по сылке, но суть такая: вы скачиваете программку, запускаете и она начинает слушать порт компьютера. В код вашего приложения добавляете js, который подгружается запущенного вами сервера, конектится к нему и начинает общаться с приложением. Далее вся отладка происходит по стандартному сценарию в отладчике хрома. который запускает программка, имхо это самый удобный вариант. Краткое пособие по запуску:
    1. скачиваем и распаковываем архив
    2. устанавливаем
    3. идем в папочку ~/.weinre/ (если её нет создаем) там создаем файл server.properties с таким текстом
      boundHost:    -all-
      httpPort:     8081
      reuseAddr:    true
      readTimeout:  1
      deathTimeout: 5
      
      настройки конечно можно поменять под себя.
    4. далее узнаем ip своей машинки и добавляем в наше приложение эта строчка будет подгружать js код для общения с сервером weinre. Соответственно надо чтобы телефон и компьютер были в одной сети и a.b.c заменить на свой ip. Запускаем приложение в телефоне или симулятор и начинаем отлаживать в привычной среде.


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

    В заключении хотел бы поведать вам ещё про один интересный способ, недавно наткнулся на него, принцип работы схож с weinre. Есть такой сайтик jsconsole.com, который предоставляет инструмент, с помощью которого можно достучаться до html на удаленном устройстве и получать от туда сообщения через console.log, а также работать с его DOM деревом. Это конечно не полноценный дебагер, как в случае с wienre но простота и доступность способа заставляет обратить на него внимание! На сайте прекрасная документация и пара обучающих видео, так что проблем с использованием ни у кого возникнуть не должно.
    Если в двух словах то вам надо зайти на сайт, вбить команду ":listen", скопировать выданный скрипт в ваш сайт или приложение и вуаля — все работает.

    Это конечно не все возможные варианты, мне попадалось описание и других, но проблематичность их использования заставила исключить их из списка. Если кто-то может дополнить список достойным кандидатом, то я только за! (включу его в статью с копирайтом автора)
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 25
    • +6
      Первыми remote debugging запили в Опере — это была одна из стартовых фишек Dragonfly, и было это на год или два раньше, чем об этом подумали другие браузеростроители. Тогда же они предложили открытую спецификацию по связи отладчик-браузер или отладчик-javascript-runtime: dragonfly.opera.com/app/scope-interface/index.html Если бы дело пошло, то сегодня каждый из нас мог бы взять любимый отладчик — тот же Firebug — и использовать его для отладки в Хроме или в браузере Андроида, например. Или Chrome Dev Tools для работы с Opera.

      Но поскольку в Гугле всем сотрудникам разослана секретная директива «не поддерживать Оперу», они решили разрабатывать свой велосипед. Параллельно с ними велосипеды изобретают все, кому ни лень, а в результате разработчики должны пользоваться зоопарком несовместимых костылей.
      • –2
        Вот я и попытался этот зоопарк осветить. Тем более если делать упор на html5 приложения, то сами понимаете это webkit.
        • 0
          а можно подробнее про секретную директиву?
          • +3
            Вспомните про любой новый продукт от Гугла или любой редизайн одного из существующих сервисов. В львиной доле случаев при запуске в Опере вас встречает надпись, мол, пользуйтесь хромофоксом, товарищ — мы в вашем браузере не работаем. Причем смена юзерагента на Хром или Фокс помогает в 95% случаев — внезапно оказывается, что сервис в Опере прекрасно работает.

            Добавьте к этому абсолютное нежелание поддерживать Оперу в компиляторе GWT — из-за этого как раз и не работал в ней Google Wave, — а также полное непризнанеи норвежцев как инноваторов индустрии. Например, когда зарелизили Chrome, в комиксе и в документации, а также во всех видеопрезентациях Google с радостью рассказывали о том, как они взяли лучшее из Firefox, IE и Safari, но функции, изобретенные в Опере, преподносили как свои. Сейчас припомню только табы выше адресной строки, но на момент релиза я насчитал штук семь или восемь таких вот «нововведений».

            На всех презентациях Google Опера если и фигурирует, то очень и очень редко.

            В Опере есть такая штука, как browser js — с его помощью исправляются баги в некоторых крупных сайтах. При каждом обновлении какого-то гуглового продукта, которое ломает что-то в браузере, ребятам из Оперы приходится, засучив рукава, разбираться, что же именно не так. Часто, как я писал выше, дело ограничивается простым удалением соответствующей проверки "if (isOpera())" из гуглового кода. Но иногда все-таки всплывают какие-то баги, и чтобы их исправить, прихдется разбираться в минифицированном и обфуцированном коде Google. Я не говорю, что они должны давать Опере свои исходники, хотя такое сотрудничество пошло обеим компаниям на пользу. Но полностью запрещать доступ к своим продуктам — это, имхо, никуда не годится. Особенно с учетом того, что различия между Opera и WebKit-браузерами минимальны.
            • 0
              не могу не вспомнить один жестокий статус
              Хотя к сейчас уже исправились.
              • +3
                Особенно с учетом того, что различия между Opera и WebKit-браузерами минимальны.

                Вы знаете, я сейчас разрабатываю игру на html5 canvas. И я вам скажу, что Опера — это просто IE6 для html5. Намаялся я с ней порядочно. Особенно меня огорчает просто отвратный сборщик мусора из-за чего Опера течёт как малолетняя школьница перед рок-звездой
                • 0
                  Ну, можете не рассказывать — сами пишем на Canvas и Svg — в Опере, IE8 и Firefox в плане скорости совсем туго. В результате портим логику на флэш и WebGL. — портим логику на флэш. Причем проблемы с производительностью не возникают только в IE9, даже с Хромом не все гладко, чего я, прямо скажем, не ожидал.

                  Вообще это длинная история, полная профайлинга и изворотливости. Если интересно, могу статью написать.
                  • 0
                    нуу… нам больше интересно что вы пишите на canvas. Также FF прост омного памяти жрет, что тут скажешь, но все же работает адеватно.

                    и во тчто самое инетерсное, если вы пиште игру то непонятно зачем поддерживать ie < 9? а если не игру то почему тормозит, что вы там такого нагромоздили.
                    • 0
                      Статья — интересна. Может расскажете чего, что мы ещё сами экспериментальным путём не поймали.
                      На ie8 — забили. А в Фоксе — нормально, в общем-то.
                      • 0
                        Мы пока боремся — у нас проект не для открытого пользования, будет поставляться в интранеты США, где статистика пока что не в нашу пользу: gs.statcounter.com/#browser_version-na-monthly-201010-201109-bar

                        Глядя на график, думаю, что хорошо хоть от IE7 и FF3.6 как-то с отвязались. Вообще сейчас политика версий такая: IE >= 8, остальные — latest stable. Первый релиз будет в следующем году, пока же ограничиваемся демонстрациями продукта. Поэтому и возлагаем надежды на WebGL, который к тому времени появится у всех, кроме Восьмерки.

                        С IE8 все весьма печально: тратим на него около 45% всех ресурсов и постоянно идет разговор об отмене его поддержки, но я исхожу из того, что в каком-то виде degraded experience у нас уже есть, поэтому пока терпим.
                        • 0
                          Это конечно хорошо, но вот не зная, что за приложение/сайт/игру вы пишите, очень сложно все это оценивать.
                          Просто логика такая: если это крутая игра то логично, что можно выдвинуть требования хром, фф, опера 12+ и тд.
                          Если это приложение для все то там не особо нужны тонны красивостей можно graceful degradation использовать.

                          Между этими вещами и ищется компропис, а не знаю что за приложение и для чего я не знаю и судить не могу.
              • 0
                ну да, в опере как обычно первыми сделали кривую реализацию. а остальные как обычно попытались сделать прямую, а не подстраиваться под нишевый браузер.
                • +1
                  Реализация открытая, и сама спецификация, кстати, тоже — все доступно уже два года на BitBucket. Идея как раз была в том, чтобы другие вендоры добавляли свои замечания и расширяли протокол, если это необходимо.
                  • 0
                    да будь она хоть трижды открытая. она кривая до мозга костей. банально: переходим в оффлайн и отладчик уже не запускается.
                • 0
                  Вроде как топик про отладку приложений в мобильном вебките, а вы все холивары устраиваете. Нехорошо.

                  Методы вытеснения других браузеров с рынка у корпорации добра вполне в рамках закона и морали, конкуренция же.
                • 0
                  Отличный инструмент в плане отладки мобильных сайтов — jsconsole.com
                  Удаленная отладка и прочие фичи прилагаются.
                  • 0
                    я его упомянул, хорошая вещь, а главное простая и с хорошей документацией для старта, но wienre будет поудобней если надо для iphone отладить
                  • +2
                    Минимальны? в верстке возможно? Полгода тому назад я писал очередной велосипедик — микро-фреймворк с поддержкой новых фишек ECMA5. Писалось, конечно, для использования на мобильных платфомах, но решил опробовать и десктоп. Итог вебкит — в идеале ( целеваая платформа ) фаерфокс — пару строчек чиркнул и заработало, пробую ie9… о боги рабооает, только еще пару правок, вспоминаю про оперу (я впоследнее время работаю на западный рынок, а там нет оперы) — и… фейл, полный фейл и для того чтобы заставить работать надо написать почти тоже что и для 7ого осла. FormData, Object.create, Object.keys, Object.defineProperty, нативные гетеры/сетеры (без магических методов с двумя подчеркиваниями) — это то что я смог вспомнить. может ситуация изменилась? Полгода назад это был фейл
                    • 0
                      писалось в опере мини — ответ ушел не по адресу, предпросмотр зафейлился
                      • 0
                        да я согласен в принципе, ставлю себе оперу последнюю и память она жрет как остальные, уж точно ничуть у хрома не выигрывая и косячки есть, не удивляет в общем, да и по всему миру её 5% если не ошибаюсь не больше это в России пользуются.
                        • +1
                          И самое главное — Funtion#bind добавили только в 12-й версии. =(
                          • 0
                            Да, просто поразительный факт. По моим наблюдениям в некоторых областях разработчикам просто не интересно исправлять ошибки.
                        • 0
                          Firebug lite помог мне в отладке страниц на не PC устройстве. Не знаю как у него с работой на телефонах…
                          Кто то пробовал?
                          • 0
                            вы себе как это все представляете на столь маленьком экранчике?
                            • 0
                              Не представляю. Я просто спросил — может кто пробовал.

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