Как стать автором
Обновить

Комментарии 10

Эти программы сосредоточены на конкурентном взаимодействии во время просмотра телевизора, позволяя пользователю взаимодействовать со своим персональным устройством во время просмотра.

Concurrent — это «одновременное» или «параллельное», а не «конкурентное».
Спасибо, исправил.
> Кошмар ТВ фрагментации
'Никто из разработчиков не может работать сразу на всех платформах'
от себя добавлю, что разрабатывать все равно приходится под разные платформы.
И к сожалению нет возможности разработать одно приложение работающее на нескольких платформах одновременно. Тут либо идти на упрощения (отходить от ТЗ и менять его), либо для каждой писать свое приложение (такой вариант в краткосрочной перспективе лучше и быстрей получается результат).
И если с серверной частью приложения все более или менее гладко, то с клиентской (HTML + JS) все довольно уныло.
К примеру на филипсе(NET-TV) туго обстоят дела с производительностью — и JS должно быть по минимум — иначе возникают тормоза в работе приложения — медленный отклик на попытку навигации с ПДУ. Сложно разрабатывать интерактивные приложения.
На Самсунге беда с нехваткой памяти (очень сложно добиться стабильной работы AJAX приложения), и из-за беды со сборщиком мусора затруднено использование сторонних библиотек, типа Jquery.

Везде используются разные стандаты: Philips — это CE-HTML, operaTV — обычный HTML5(даже с поддержкой тега VIDEO), SAMSUNG и LG — HTML4 (+ у каждого свой API для видео объекта).
на Philips перемотка в видеоплеере реализуется резким переходом на другой время 'seek(newTime)'
на Samsunge же есть возможность реализовать перемотку изменением скоростью воспроизведения (х2, х4)

практически везде беда с эмуляторами (а на каждую платформу получить тестовое устроиство — не всегда возможно):
в эмуляторе Philips не работает видеоплеер (не реализовано по лицензионным причинам… ) изза чего проблемно отлаживать этот видеоплеер
Эмулятор Самсунга нестабилен — и при использовании некоторых возможностей API приводит к крэшу эмулятора.
Уже молчу про то что поведение на эмуляторе не всегда аналогично устоиству.

Прежде чем начинать разработку для TV устроиства — лучше день-неделю потратить на изучение спецификации, а не читать ее по ходу разработки — иначе приходится порой все переделывать, по причине что чтото неучел и/или незнал.

Ну и малое кол-во информации в сети по данному вопросу затрудняет решение возникающих сложностей. методом тыка пытаешся решить проблему…

В общем высказался что наболело за последние месяцы активной разработки под TV платформы… :)
НЛО прилетело и опубликовало эту надпись здесь
я просто скину часть внутренней переписки в чем беда(как я смог выяснить — хотя конечно могу ошибаться):
если гденить в приложении есть это:
var element = $('#e1');
а потом гденить вызывается 'putInnerHTML' который удаляет этот '#e1', и поскок все это происходит в обход сборщика мусора, то значение переменной element — становится непонятным :)

и короче все начинает тупить и вылетать… поскольку повсеместно используется Jquery и прочие библиотеки. а они и не разрабатывались чтоб работать когда чтото будет удаляться в обход сборщика мусора
Из моего опыта (Samsung, Philips, LG) — Самсунг работает стабильнее всех. Скорость приложения, даже с использованием jQuery и не слабого дизайна, практически не страдает. LG на втором месте, на некоторых телевизорах наблюдаются проблемы с производительностью, но jQuery (плюс наша собственная навигационная библиотека) работают. А вот Филл — это что-то с чем-то. Память кончается мгновенно, тормоза. Использование их стандарта CE-HTML порождает какое-то самоуправство телека (он сам решает, куда фокус поставить, внешний вид фокуса отличается на 100% от желаемого, отваливается AJAX и т.п.). В итоге все решается использованием обычного HTML с js-навигацией, хотя остаются жуткие проблемы с нехваткой памяти.
Да я согласен, из того с чем я плотно сталкивался, Самсунг наиболее приятный в разработке. Ту проблему которую я описал наверно проявляется не всегда и не увсех — там все зависит от архитектуры приложения… Если исключить вероятность случайного использования удаленных элементов методом — putInnerHTML, то проблем не должно быть.

А что касается навигации в филипсе — у меня все впринципе более или менее:
1) Content-Type: application/ce-html+xml;charset=«UTF-8»
2) css3 spatial Navigation
и фокус ведет себя вполне корректно и дизайн вполне оправдывает ожидания
Но вот на динамической странице (где элементы навигации проподают/появляются или перемещаются) управлять этим spatial Navigation еще тот геморрой — но есть мысль написать API для этого — чтоб както автоматизировать процесс.

а вот при JS навигации, не используя css3 — тормоза при навигации оч заметные
Да хочется все-таки сделать одно приложение под эти три платформы. И мне кажется, что это все-таки возможно.
Вы расскажите лучше — они прибыль то хоть приносят, чтобы через такой АДЪ проходить?
Для меня — вопрос окупаемости не важен — у меня ЗП. Но закзчику прибыль приносит. Но ТВ приложение для них — это во первых источник доп дохода (основной доход с ПК версии сайта), и как реклама ПК версии, поскок пользователь может не знать ПК версию сайта, но наткнуться на приложение в телике…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий