Ott відео сервіси на екранах panasonic тв

This post is also available in: Англійська

Найбільші виробники телевізорів в останні роки активно освоюють можливості надання послуг через інтернет, і компанія Panasonic не стала в цьому відношенні винятком. Своє бачення концепції розумного телебачення фахівці японської компанії втілили в технології Viera Connect.

З прес-релізу Panasonic:

У цій статті ми хочемо поділитися досвідом розробки додатків для платформи Viera Connect.

Налаштування середовища розробки

Hello, World!

організація додатки

Будь-який додаток Panasonic Viera Connect складається з стейдж або екранів. Вищезгаданий файл main.js - головний стейдж, точка входу в додаток. Зазвичай стейдж містять графічні елементи призначеного для користувача інтерфейсу і код для взаємодії з користувачем. У нашому випадку ми трохи відійшли від цієї концепції і використовували стейдж main.js для підключення всіх необхідних бібліотек з подальшим перенаправленням користувача на головну сторінку програми.

Організація паралельної роботи декількох членів команди.

Розробка програми

Cистема навігації

Ми почали з того, що розробили 3 основні класи:

• NavigationStage
• NavigationArea
• NavigationNode

NavigationStage містить загальні методи для пересування курсору по стейдж і навігації між стейдж. NavigationArea - це клас навігаційної області, яка об'єднує навігаційні елементи NavigationNodes. Області можуть мати сусідні області зверху, знизу, праворуч і ліворуч. Це справедливо і для навігаційних елементів. Навігаційні елементи віртуальні, але зберігають посилання на елемент на стейдж, візуальне відображення якого ми можемо змінювати в залежності від того, знаходиться елемент у фокусі чи ні.

Інтерфейси NavigationArea і NavigationNode містять схожі методи: executeSelect і executeLeave. Вони викликаються, коли область або елемент отримують або втрачають фокус. Крім цього об'єкти NavigationNode також мають метод executeEnter, який викликається для елемента, що знаходиться у фокусі, коли користувач натискає кнопку OK на пульті дистанційного управління.

Всі навігаційні області поводяться однаково. При початковій постановці курсора в навігаційну область для неї активується навігаційний елемент за замовчуванням. Якщо користувач переводить курсор в іншу область, ми запам'ятовуємо індекс останнього активного навігаційного елемента. Це робиться для того, щоб, коли курсор повернеться назад, ми змогли б активувати елемент, з якого був здійснений перехід.

На самому початку розробки всі навігаційні елементи і області також вели себе однаково. Спочатку це були текстові написи, які міняли колір залежно від положення фокуса і це поведінка була прописано в самому класі NavigationNode. Коли ми верстали сітку фільмів, постала необхідність створювати більш складні навігаційні елементи, які складалися б з довільного набору графічних елементів і тексту. Тому ми винесли поведінку навігаційного елемента в окремий клас типу strategy, об'єкт якого передавали в конструктор навігаційного елемента. Цей підхід працював ідеально, але не довго. Справа в тому, що поки ми створювали навігаційні області, всі елементи в яких були однаковими, наприклад меню з текстовими пунктами або сітку з обкладинок фільмів, все було нормально. Потім виникла необхідність створювати навігаційні області, що складаються з довільних елементів, а при роботі над клавіатурою для пошуку нам треба було не тільки призначати стратегію поведінки для кожного елемента а й передавати їй додаткові параметри поведінки. Наведу приклад. Нехай необхідно створити клавіатуру для введення пошукового запиту. На клавіатурі є 4 типи кнопок, які відрізняються стратегіями поведінки:

• CharButtonStrategy
• CursorMoveButtonStrategy
• BackspaceButtonStrategy
• SwitchLayoutButtonStrtegy

Кожна кнопка зі стратегією CharButtonStrategy отримує масив налаштувань, в якому міститься, зокрема, код символу, який буде додано до пошуковому рядку при натисканні на цю кнопку. SwitchLayoutButtonStrategy приймає масив, що містить ID клавіатури, на яку необхідно переключитися, регістр букв і т.д.

Цей підхід ми також використовували в подальшому при створенні спливаючих вікон - кнопки «так» і «ні» отримують в конструкторі різні стратегії поведінки, які, в свою чергу, не започатковано власними параметрами.

прокручувати контейнери

Ще однією великою завданням стала реалізація прокручуються елементів інтерфейсу - скроллером.

Тому подія прокрутки контейнера поєднали з переміщенням фокусу від одного навігаційного елемента всередині контейнера до іншого. Для доступу до подій переміщення по елементах ми використовуємо описану вище систему навігації. Так як при створенні навігаційної області ми задаємо взаємне розташування елементів в ній, то при переміщенні фокуса з першого елемента меню до другого, розташованому під першим, ми завжди маємо можливість обчислити відстань, на яке повинен бути прокручений скроллер. Так була реалізована перша версія скроллера. В процесі розробки стало зрозуміло, що скроллер повинен прокручуватися не завжди. Наприклад, в описаному вище прикладі з переходом від першого елемента меню до другого прокручувати скроллер немає сенсу тому, що на екрані все ще багато видимих ​​елементів меню. Коли ж настає момент, коли необхідно включити прокручування? Ми прийняли рішення прокручувати скроллер тільки в разі, якщо елемент, на який здійснюється перехід, розташовується на невеликій відстані від центру скроллера. Наступним кроком була введена перевірка на те, що кордони прямокутника, навколишнього прокручуваний контент, завжди повинні розташовуватися поза межами скроллера.

Варто відзначити, що всі елементи на стейдж позиціонуються щодо полярної системи координат з нульовими координатами в центрі екрану. Цю цікаву особливість необхідно враховувати при проектуванні.

налагодження коду

Panasonic не надає ніяких вбудованих засобів налагодження. Це означає, що стейдж, який використовує функціонал, який ви зараз налагоджувати, - або запускається, або падає все додаток і далі Вам належить поступово відкочувати код до робочої версії, щоб локалізувати і виправити помилку. Можна трохи спростити цю задачу. У документації для розробників Panasonic рекомендує написати функцію, що дозволяє виводити налагоджувальні повідомлення. Суть в тому, що за допомогою об'єкта http_request під час виконання коду можна відправляти асинхронні запити в backend вашого застосування і Залогуватися їх. Ми писали повідомлення в файл, який потім відкривали за допомогою команди tail debug.log -f. Потрібно відзначити, що при такому підході не слід розраховувати, що все налагоджувальні повідомлення будуть приходити в лог в тій послідовності, в якій вони зустрічаються в коді, так як запити асинхронні. Частково вирішити проблему вдається, послідовно об'єднуючи налагоджувальні повідомлення в один рядок, а потім відсилаючи їх на сервер одним запитом. Однак цей підхід спрацьовує тільки в разі, якщо код від першого отладочного повідомлення до рядка, що відсилає весь лог на сервер, не містить помилок, - інакше повідомлення просто не буде відправлено.

Спробуємо коротко підсумувати сказане вище. Процес розробки додатків для платформи Viera Connect можна назвати простим. Крім безпосереднього проектування і написання коду, розробник повинен вирішити велику кількість організаційних питань, включаючи настройку середовища розробки, а також написання необхідних утиліт. Налагодження програми сильно ускладнюється відсутністю в SDK емулятора і специфікою роботи з пристроями Panasonic.