Streaming media on Web

Conventional video playback (also known as Progressive) involves a single video file at a single quality that is transferred as it is being played. If the user’s playback has caught up to how much of the video has been downloaded, the player pauses and buffers. YouTube subscribes to this method of playback but offers different quality levels that you manually select. You only watch a single quality unless you manually switch it.

With adaptive media streaming, a high quality base video source (often called a Mezzanine) is converted into a set of video files of varying qualities. This process is known as encoding. For example, you can take a mezzanine file and encode low, medium, high, and ultra quality versions of a video. These encoded files are then stored for distribution on a Server or Content Delivery Network (CDN).

When the user attempts to play a video adaptively, they are given a Manifest file that lists information for all these different video qualities. Adaptive streaming technologies then alternate between the different qualities (bitrates) depending on a user’s varying connection while playing the video in order to ensure that buffering is minimized. In order to start playback as soon as possible, adaptive streaming technologies usually begin playback at the lowest quality and then scale upwards after a few seconds. You may have noticed this happening when you start watching a movie or episode on NetFlix.

A video player (often referred to as a Client) that supports an adaptive media streaming technology will handle this process of switching between qualities automatically without a user’s involvement.

AMS&Progressive

What are some adaptive streaming technologies?

The two biggest smooth streaming technologies I’ve worked with in my time at Digiflare are Apple’s HTTP Live Streaming (HLS) and Microsoft’s Smooth Streaming (MSS) technologies. These technologies differ in terms of the video and audio formats they support as well as how they go about delivering the video content optimally.

Streaming – What does HLS, HDS and MPEG-DASH mean?

These are all ‘chunked HTTP’ streaming protocols. These work by breaking the content in small (a few seconds) chunks that can be delivered as separate files rather than a constant stream of content.  The advantage of this method is that it allows the client to make use of the ‘bursty’ nature of the internet and does not rely on a constant bandwidth being available.

Apple’s HTTP Live Streaming (HLS)

HLS stands for HTTP Live Streaming and was developed by Apple to serve its iOS and MAC OS devices.  It is also widely available for other devices notably Android.  Apple made the specification public by publishing it as a draft IEEE RFC. HLS usually makes use of MPEG -2 transport stream technology which carries a separate licensing cost which deters some manufacturers from implementing it in their devices.  It is a simple protocol that is quite easy to implement.

Summary:

  • Manifest: M3U8 playlist
  • Video: H.264
  • Audio: MP3 or HE-AAC
  • Container: MPEG-2
  • Server: No special server software

Microsoft’s Smooth Streaming (MSS)

Microsoft’s Smooth Streaming technology also involves encoding a mezzanine into various quality levels but MSS supports slightly different formats in the encoding process. Video can be encoded using H.264 or VC-1 and audio is encoded to AAC or WMA. The encoded quality level video is wrapped in an MP4 container with a *.ismv or *.isma file extension.

During the encoding process, XML manifest files are also generated. An *.ism file is generated for use by the server in describing the available bitrates while a *.ismc file is used by the client to inform it of available bit rates and other information required in presenting the content. One such piece of information is the chunk duration.

Unlike HLS, Microsoft’s Smooth Streaming doesn’t encode the individual qualities into a series of chunks. Instead, the server cuts the full content into chunks as it’s being delivered. This requires a specially set up server using Microsoft’s Internet Information Services (IIS).

For more information regarding the setup of IIS Servers and MSS manifest formatting see Microsoft’s guide on Getting Started with IIS Smooth Streaming and Smooth Streaming Deployment guides.

Summary:

  • Manifest: XML file with *.ism/ismc file extension
  • Video: VC-1 or H.264
  • Audio: AAC or WMA
  • Container: MP4 (with *.ismv/isma file extension)
  • Server: IIS (Internet Information Services) server
  • Additional: Only quality files are stored but server virtually splits them up into chunks at playback

HDS

HDS stands for HTTP Dynamic Streaming and was developed by Adobe to serve its Flash platform.  The BBC uses this protocol for its desktop browser presentations using the BBC Standard Media Player (SMP) which implements the Flash playback client.  Adobe has published the HDS protocol to register developers.  It is a more complex protocol and is harder than HLS to implement.

MPEG Dynamic Adaptive Streaming over HTTP (DASH)

MPEG-DASH stands for Motion Pictures Expert Group Dynamic Adaptive Streaming over HTTP.  This is a new completely open source protocol that is just starting to be adopted by content producers and client implementations.  It has the simplicity of HLS whilst being free of additional licencing other than that required by the codecs.

Unlike, HLS, HDS and Smooth Streaming, DASH is codec-agnostic.
DASH is audio/video codec agnostic. One or more representations (i.e., versions at different resolutions or bit rates) of multimedia files are typically available, and selection can be made based on network conditions, device capabilities and user preferences, enabling adaptive bitrate streaming[10] and QoE (Quality of Experience) fairness.

Summary:

  • Manifest: Media Presentation Description (MPD)
  • Video: Codec agnostic
  • Audio: Codec agnostic
  • Container MP4 or MPEG-2

MPEG DASH is the result of a collaborative effort from some of the biggest players (ie. Adobe, Apple, and Microsoft) of adaptive bitrate streaming. From a bird’s eye view it functions similarly to the technologies previously described, but differs in the details of its delivery to end users.

In DASH, the entirety of an available stream, made up of a media portion and a metadata manifest, is known as a Media Presentation. The manifest portion of this is called a Media Presentation Description (MPD). Much like an M3U8 or Smooth Streaming manifest, an MPD contains metadata for the media available.

The media portion of a presentation is made up of different quality levels of the same media. Each quality level is known as a Period. A period is a set of time-aligned contents (audio, video, captions, etc.) which form one entire viewing of the content at a single quality level. Each period consists of a collection of different media forms, each known as an Adaptation. So a period may consist of a separate video adaptation and audio adaptation. Each encoding of a particular adaptation is known as a Representation. Each representation is split into short chunks, dubbed segments. Using the terminology at hand, the entire stream consists of a set of periods where each period will typically contain a representation of each type of adaptation being delivered to a user in the presentation. Adaptive playback is facilitated appropriate quality as segments are downloaded as playback is taking place and connection speed is being monitored.

As confusing as that may have been to sort out, there is a significant theoretical advantage to this approach of different adaptations to build up a period versus the approaches previously described for MSS and HLS. This advantage is the codec agnostic nature of DASH. The media is served in either an MP4 or MPEG-2 container using whatever video and audio formats and the onus is put on players to be able to decode and render the video/audio/captions/etc. This eases up effort for content creators and distributors to prepare their content for adaptive streaming and also removes a lot of restrictions associated with proprietary solutions. That includes the IIS server set up for MSS and the proprietary encoding software for HLS.

However, this large scope of supported codecs does make for more complex player development. Communities have banded together to provide a plethora of player framework options for developing for DASH on a variety of platforms and for an assortment codecs. These frameworks vary in their supported platforms and features so a good amount investigation must be done in advance to find the right fit for the feature requirements of the player as well as the platform.

This is where subscribing to MPEG DASH as a solution may become problematic on more obscure platforms, and even on some of the more popular ones. This means MPEG DASH is not yet the answer to the segregation issue that exists with adaptive bitrate streaming.

hls_pro_con.png

DASH_pro_con.png

AdaptiveBitrateComparison

 

Sample data flow of MS video streaming service

streaming-diagram

Ref.:

http://iplayerhelp.external.bbc.co.uk/radio/other/streaming_hls_hds_mpeg

http://www.digiflare.com/adaptive-media-streaming-hls-vs-mss-vs-dash/

https://www.sitepoint.com/html5-video-understanding-compression-drm/

http://streaminglearningcenter.com/blogs/dash-or-hls-which-is-the-best-format-today.html

http://www.internetvideoarchive.com/documentation/video-api/progressive-download-vs-adaptive-bitrate/

https://bitmovin.com/mpeg-dash-vs-apple-hls-vs-microsoft-smooth-streaming-vs-adobe-hds/

https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP

Advertisements

타이젠 웹 애플리케이션 개발

타이젠과 웹 애플리케이션
애플 앱스토어 및 구글 플레이 스토어 성공 신화의 비밀은 킬러 애플리케이션의 존재 및 사용자의 요구 사항을 만족하는 다양한 애플리케이션에 있다. 타이젠은 이제 막 개발자에게 타이젠스토어[1]를 공개했기 때문에 다른 플랫폼에 비해 애플리케이션의 수가 부족한 단점이 있다. 이를 채우기 위해 타이젠 애플리케이션 개발자 대회[2]와 같은 행사로 개발자들의 관심을 끌고 있다. 네이티브 애플리케이션에 비해 호환성이 높은 웹 애플리케이션을 이용하면 기존에 존재하는 더 많은 애플리케이션을 타이젠으로 흡수할 수 있다.
이와 같은 이유로 웹 애플리케이션은 타이젠의 초기 생태계를 늘리기 위한 핵심 요소이다. 또한 웹 애플리케이션은 네이티브 애플리케이션에 비해 개발 진입 장벽이 낮고 상대적으로 빠른 시간에 손쉽게 애플리케이션을 작성할 수 있기 때문에 웹 애플리케이션을 개발하는 것은 개발자에게도 좋은 기회가 될 수 있다.
타이젠 웹 애플리케이션 특징
앞서 언급한 것과 같이 웹 애플리케이션은 타이젠 플랫폼에 있어 큰 비중을 차지한다. 이에 타이젠은 다른 플랫폼과 차별화를 위해 웹 애플리케이션을 위해 다양한 지원을 끊이지 않고 있다. 그 중 몇 가지 중요한 특징을 간추려봤다.
<높은 HTML5 호환성>
HTML5, CSS5 등 W3C(월드와이드웹 컨소시엄, World Wide Web Consortium) 표준 웹 기술을 최대한 지원하고 있다. 특히 HTML5 호환성 테스트 측정 사이트인 html5test.com의 측정 결과에 의하면 500점 만점에 492점(+보너스 16점)을 받아 모든 상용화 및 개발 중인 브라우저 대비 가장 좋은 HTML5 호환성을 보여주고 있다(그림 1).
<디바이스 API 지원>
기존의 W3C 및 여러 표준 단체에서 지원하지 못하는 기능을 처리하기 위해 다양한 디바이스 API도 지원하고 있어, 애플리케이션 개발에 불편함이 없도록 하고 있다.
웹 애플리케이션을 이용하면서도 GL의 성능을 활용할 수 있다. 이는 게임과 같이 성능에 민감한 애플리케이션 개발 등에 사용할 수 있다.
<패키지 생성>
W3C의 Packaging and XML Configuration 정책[3]에 따라 웹 애플리케이션 패키지 생성(wgt 확장자)을 지원한다. 이를 통해 타이젠 웹 애플리케이션은 타이젠스토어 등록 및 판매가 가능하며 개별 애플리케이션으로 설치가 가능하다.
모바일 애플리케이션 용어
모바일 애플리케이션의 세가지 개발 방식인 네이티브(native), 웹(web), 하이브리드(hybrid) 애플리케이션에 대해 알아 본 후, 타이젠 웹 애플리케이션에 대해 설명하고자 한다. 가급적 통상적인 기준으로 분류하였으나, 경우에 따라 일부 용어는 그 범위가 다르게 쓰이기도 한다.

그림 1.
html5test.com의 호환성 테스트 점수(출처 : 자체 제작)
<네이티브 애플리케이션>
네이티브 애플리케이션(native application)은 플랫폼 별로 제공되는 네이티브 언어로 개발된 애플리케이션을 말한다. iOS는 오브젝티브-C, 안드로이드는 자바, 타이젠은 C/C++를 사용한다. 네이티브 언어를 사용하기 때문에 플랫폼에 가장 최적화 할 수 있어 성능이 우수하다. 하지만 플랫폼 별로 개발 언어가 다르기 때문에 멀티 플랫폼을 지원하기 위해서는 개발 비용 및 유지보수 비용이 높은 단점이 있다.
<웹 애플리케이션>
웹 애플리케이션(web application)은 웹 브라우저의 주소를 통해 접속 할 수 있는 애플리케이션이다. 웹 언어를 사용하기 때문에 호환성이 좋아 하나의 소스코드로 다양한 플랫폼에서 실행 가능하다. 하지만 속도가 느리고 하드웨어 접근이 제한적이다. 또한 패키지 형태의 배포가 되지 않아 앱스토어 등록 및 판매를 할 수 없다.

표 1. 애플리케이션 유형별 비교

그림 2. HTML, CSS 및 자바스크립트(출처 : 자체 제작)
<하이브리드 애플리케이션>
하이브리드 애플리케이션(hybrid application)은 네이티브 애플리케이션과 웹 애플리케이션의 장점을 취한 개발 방식이다. 웹 애플리케이션을 네이티브 언어나 오픈소스 크로스 프레임워크로 감싼 후, 네이티브 애플리케이션으로 빌드 하여 배포하는 것을 말한다. 즉 애플리케이션의 기본 골격은 네이티브 언어로 구성하고, 이를 기반으로 웹뷰(webview)를 사용하여 웹 애플리케이션을 로드하는 방식이다. 하이브리드 애플리케이션은 웹 애플리케이션의 호환성 장점을 가지면서 네이티브 애플리케이션처럼 앱스토어 등록 및 판매도 할 수 있다. 대표적인 오픈소스 크로스 프레임워크로 폰갭(PhoneGap)과 앱스프레소(Appspresso)가 있다.
<타이젠 웹 애플리케이션>
타이젠 웹 애플리케이션(Tizen web application)은 웹/하이브리드 애플리케이션보다 진보된 방식을 지원한다. 일반적인 웹 애플리케이션과 달리 독자적으로 패키지 형태 배포가 가능하여 하이브리드 애플리케이션처럼 별도의 네이티브 언어나 오픈소스 크로스 프레임워크를 사용할 필요가 없다. 또한 타이젠은 네이티브 애플리케이션에서만 지원하던 다양한 디바이스 API 및 UI를 웹 애플리케이션에서도 사용 가능하도록 지원한다(표 1).
웹 애플리케이션 관련 기술
웹 애플리케이션 세미나를 진행하다 보면 웹 애플리케이션 개발을 처음 접한 분들로부터 어디부터 공부해야 할지 막막하다는 이야기를 많이 듣는다. 그만큼 웹 애플리케이션 개발은 다양한 기술과 폭넓은 지식이 필요하다. 기본적으로 웹 애플리케이션은 HTML(구조) + CSS(디자인) + 자바스크립트(동적 요소) 3가지로 구성된다(그림 2).
그리고 복잡한 자바스크립트를 좀 더 쉽게 사용할 수 있도록 웹 표준 프레임워크인 제이쿼리(jQuery, 그림 3)를 사용하며, 특히 모바일 디바이스 최적화를 위하여 제이쿼리 모바일(jQuery Mobile)을 사용한다.
HTML(HyperText Markup Language)은 웹 페이지의 구조를 정의 하기 위한 마크업 언어이다.
CSS(Cascading Style Sheet)는 HTML 엘리먼트(Element)의 디자인 표현을 정의한다. 레이아웃과 스타일을 정의할 때 정교한 디자인 제어가 가능하다.
<자바스크립트>
자바스크립트를 사용하면 상호작용, 액션, 애니메이션 및 다양한 효과를 통해 동적인 웹 애플리케이션을 개발할 수 있다. 유럽컴퓨터제조협회(ECMA)는 자바스크립트의 공식 명칭을 EC MAScript로 표준화했다. 하지만 아직까지 자바스크립트라는 용어가 널리 사용되고 있다.

그림 3. 제이쿼리 로고(출처 : 제이쿼리 웹사이트)

그림 4. 제이쿼리 모바일 지원 플랫폼(출처 : jquerymobile.com)

표 2. 자바스크립트와 제이쿼리에서 아이디가 TIZEN인 엘리먼트에 접근하는 소스 코드 비교
<제이쿼리>
웹 표준 프레임 워크인 제이쿼리[4]를 사용하면 자바스크립트를 좀 더 쉽게 이용할 수 있다. 제이쿼리의 모토인 “Write less, do more” 처럼 적은 양의 소스로 원하는 웹 애플리케이션을 쉽게 제작할 수 있다. 제이쿼리는 자바스크립트의 복잡한 작업을 대신해 주고, 다양한 효과를 쉽게 사용할 수 있도록 한다.
<제이쿼리 모바일>
제이쿼리 모바일[5]은 터치스크린에 최적화 된 제이쿼리 기반 웹 프레임워크다. 제이쿼리 모바일은 스마트폰, 태블릿 등 다양한 환경에서 웹 애플리케이션이 작동할 수 있도록 지원한다(그림 4).

그림 5. Single Page Application 템플릿 실행 화면(출처 : 자체 제작)

그림 6. Multi Page Application 템플릿 실행 화면(출처 : 자체 제작)

그림 7. Master Detail Application 템플릿 실행 화면(출처 : 자체 제작)

그림 8. Navigation Application 템플릿 실행 화면(출처 : 자체 제작)
타이젠 IDE 웹 애플리케이션 템플릿
타이젠은 일관성 있는 UI를 가진 웹 애플리케이션 개발을 위해 제이쿼리 모바일 기반의 웹 UI 프레임워크를 지원하고 있다. 기존의 제이쿼리 및 제이쿼리 모바일 기반의 웹 애플리케이션 개발자라면 더욱 손쉽게 타이젠 웹 애플리케이션을 제작할 수 있다. 타이젠 웹 UI 프레임워크는 기본적으로 제이쿼리 1.8.2 버전, 제이쿼리 모바일 1.2.0 버전을 포함하고 있고 타이젠 UI 컨셉에 맞춘 컨트롤을 제공한다.
타이젠 IDE는 타이젠 웹 UI 프레임워크를 이용한 애플리케이션 개발을 위해 다음과 같은 4가지 형태의 템플릿을 제공한다.
가장 단순한 형태의 템플릿으로 인덱스 파일 하나에 한 페이지만 존재하는 템플릿이다. 제이쿼리 모바일은 페이지라는 개념을 추가해 한 HTML 파일 내에 여러 뷰(view)를 담을 수 있도록 했다. 이 구조에 대한 자세한 자료는 제이쿼리 모바일 공식 홈페이지를 통해 찾아 볼 수 있다(그림 5).
한 인덱스 파일에 두 개의 페이지가 존재하는 템플릿이다. 제이쿼리 모바일은 한 인덱스 파일에 여러 페이지가 존재할 경우 상단에 있는 페이지를 첫 화면으로 지정한다. 해당 템플릿은 링크를 통해 뷰를 전환하는 코드까지 포함되어 있다(그림 6).
HTML 파일 별로 별도의 뷰를 제공하는 템플릿이다. 템플릿 생성시 해당 프로젝트 내에서 index.html, section1.html, section2.html을 확인할 수 있고 웹 애플리케이션의 시작점이라 할 수 있는 index.html에서 다른 페이지들을 접근할 수 있는 코드가 포함되어 있다(그림 7).
웹 애플리케이션의 가장 기본 형태라 할 수 있는 리스트뷰와 하단 네비게이션 바가 포함되어 있는 템플릿이다. 뷰 파일의 경우 Master Detail Application과 마찬가지로 한 HTML 파일에 페이지가 하나 포함되어 있다. 하단 네이게이션 바를 통해 뷰 전환을 할 수 있고, 화면 중앙 컨텐츠 영역에 리스트뷰를 통해서도 뷰 전환을 할 수 있다(그림 8).
타이젠 IDE의 메뉴에서 File-> New -> Project -> Tizen Web Project를 선택한 뒤, Template -> Tizen -> Tizen Web UI Framework를 선택하면 그림 9와 같이 타이젠 웹 UI를 이용한 4가지 애플리케이션 템플릿을 확인할 수 있다.
타이젠 IDE는 타이젠 웹 UI 프레임워크 템플릿 이외에도 기본(Basic) 템플릿 및 제이쿼리 모바일 템플릿, 타이젠 웹 UI 빌더 템플릿을 제공하니 한 번씩 실행해보도록 하자.

그림 9. 타이젠 웹 UI 프레임워크를 이용한 애플리케이션 템플릿(출처 : 자체 제작)
<코드 1>
<코드 2>
<코드 3>
<코드 4>

Single-page application

<코드 5>

  • Item1
  • Item2
Footer content

표 3. 샘플 애플리케이션 코드 전문
샘플 웹 애플리케이션 제작
이번 호에서는 Single Page Application 템플릿을 바탕으로 간단한 형태의 웹 애플리케이션을 제작해 보도록 하겠다. 우리가 제작할 애플리케이션은 상단에 타이틀 바와 서치(search) 텍스트 박스가 존재하고 컨텐츠 영역에 리스트 뷰가 존재하는 가장 기본적인 형태의 웹 애플리케이션이다(그림 10).
타이젠 IDE를 실행하고, 앞서 설명한 Single Page Application 템플릿을 선택한 뒤 Project name을 기재하고 Finish 버튼을 클릭한다.
화면 좌측의 Project Explorer에서 방금 생성한 프로젝트를 선택한 뒤 index.html을 더블 클릭하자. 표 3은 샘플 애플리케이션 코드 전문이며 파란색으로 표시한 부분은 템플릿에 없는 코드로 여러분이 직접 입력해야 하는 부분이다.

그림 10. 샘플 애플리케이션 실행 화면(출처 : 자체 제작)

그림 11. 기본적인 타이젠 웹 UI 기반 애플리케이션의 헤더, 컨텐츠, 푸터 영역(출처 : 자체 제작)
<코드 1>
타이젠 웹 UI는 제이쿼리와 제이쿼리 모바일을 기반으로 제작되기 때문에 관련 스크립트 파일을 HTML head 내에 반드시 포함시켜야 한다. 추가적으로 타이젠 웹 UI 프레임워크의 경우 tizen-white 및 tizen-black 두 가지 테마를 지원하고 있다. 테마는 data-framework-theme 속성(attribute)을 이용해 선택적으로 사용 가능하며 값을 설정하지 않으면 tizen-black으로 설정된다.
<코드 2>
타이젠 IDE는 타이젠 웹 UI 프레임워크 템플릿을 사용하여 프로젝트를 생성할 경우 기본적인 폴더 구조와 스크립트, 스타일시트 파일을 생성해 준다. 개발자는 해당 파일과 폴더 구조를 활용하여 애플리케이션을 개발할 수 있으며 원하는 경우 이 구조를 변경할 수 있다. 이번 샘플 애플리케이션 제작에서는 해당 코드를 별도로 수정하지 않도록 한다.
<코드 3>
타이젠 웹 UI 프레임워크의 최소의 화면단위는 한 HTML 파일이 아니라 바디 태그 내에 존재하는 페이지이다. 이는 div 태그에 data-role=”page”를 추가함으로써 구현할 수 있다. 만약 바디 태그 내에 여러 페이지가 존재할 경우 최 상단에 위치한 페이지가 기본 페이지로 선택된다.
<코드 4>
일반적으로 페이지는 그림 11과 같이 상단의 헤더(header), 중앙부의 컨텐츠(contents), 하단의 푸터(footer)로 구성된다. 코드 4의 경우 헤더를 표현하기 위한 코드를 담고 있다. 먼저 헤더 표시를 위해 를 작성한 뒤, 타이틀 표시를 위해 h1 태그를 사용했다. 서치 텍스트의 경우 input type=”search” 통해 표현할 수 있고, 해당 코드를 h1 태그 아래 덧붙임으로써 타이틀 아래 서치 텍스트 박스가 위치하도록 했다.

그림 12. 타이젠 IDE의 Window ->Prefernces 메뉴(출처: 자체 제작)

그림 13. 프로파일 이름 입력(출처 : 자체 제작)

그림 14. Certificate Generator 다이얼로그 정보 입력(출처 : 자체 제작)
<코드 5>
이제 컨텐츠 영역의 리스트 코드를 살펴보도록 하자.
리스트의 경우 ul data-role=”listview” 코드를 통해 리스트 컨테이너를 제작할 수 있고 ul 태그 내에 li 태그를 추가함으로써 해당 리스트의 아이템을 표현할 수 있다. 샘플 애플리케이션의 경우 ul 태그 내에 li를 활용하여 Item1, Item2를 추가하여 리스트를 제작했다.
간단히 템플릿을 수정하여 샘플 애플리케이션을 제작해봤다. 우리가 작성한 애플리케이션을 타이젠 에뮬레이터에서 실행하는 방법을 알아보자.
먼저 타이젠 에뮬레이터를 실행한다. 그 다음 타이젠 IDE의 Project Explorer에서 실행하려는 프로젝트를 선택한 뒤, Run As -> Tizen Web Application을 선택하면 에뮬레이터 상에서 애플리케이션이 실행된다. 단, 최초 실행 시 애플리케이션 Signing을 위한 보안 프로파일(Se cure Profile)을 생성해야 한다. 보안 프로파일은 타이젠 IDE를 활용하여 손쉽게 제작할 수 있다.
① IDE 상단 Window 메뉴의 Preference를 선택한다(그림 12).
② Preferences 다이얼로그의 좌측 Tizen SDK 메뉴 Security Profiles를 선택한 뒤 우측 Add 버튼을 클릭한다. Profile Name 다이얼로그에 원하는 Profile Name을 입력한다(그림 13).
③ Preferences 다이얼로그 중앙 Author Cer tificate의 좌측에 있는 Generate 버튼을 클릭한다. 이후 화면에 출력되는 Certificate Generator 다이얼로그에 관련 정보들을 입력한다(그림 14).
④ Certificate Generator 다이얼로그에 정보들을 입력한 뒤, OK버튼을 누르면 certificate가 생성되고 이를 사용할 것인지를 묻는 창이 출력되는데, Yes 버튼을 누르면 보안 프로파일이 생성된다.
타이젠 IDE에서 빌드, 실행을 하면 해당 앱의 구동화면을 에뮬레이터에서 확인할 수 있다.
위와 같이 타이젠 웹 UI 프레임워크를 사용한다면 모바일 환경에 최적화된 화면을 큰 어려움 없이 꾸밀 수 있다.
예제에서 사용한 헤더, 텍스트 박스, 리스트 외에도 다양한 컨트롤을 제공하고 있으니 해당 링크를 참조하길 바란다.
타이젠 2.2 배포 소식
지난 6월호에서 타이젠 2.1 배포 소식을 전하며 타이젠은 활발하게 개발이 진행되고 있다고 언급했다.
그런데 얼마 지나지 않은 지난 7월 21일 타이젠의 새로운 버전인 2.2 버전이 배포됐다.
새로운 API추가, IDE 및 도구에 보안 프로파일 UX, UI 커스터마이저, CSS/HTML5 실시간 편집 및 미리보기 기능 추가 등의 다양한 부분이 추가되었다. 타이젠 2.2는 2.1에 비해 외관상으로도 많은 변화가 있어 그 중 몇 가지 내역을 살펴본다.

그림 15. 타이젠 2.2 배포 공지(출처 : 공식 웹사이트)
<소프트웨어 버튼 대신 하드웨어 뒤로가기/메뉴 버튼 추가
타이젠 2.1까지는 메뉴 버튼과 뒤로가기 버튼이 애플리케이션 화면 안에 존재했었다. 타이젠 2.2부터는 그림 16과 같이 메뉴 버튼과 뒤로가기 버튼이 애플리케이션 밖으로 나와 물리적인 버튼으로 존재한다.

그림 16. 뒤로가기/메뉴 버튼 변경(출처: 자체 제작)
<검은 계열 UI 추가>
기존에 제공하던 아이보리 계열의 화이트 테마 이외에도 검은 계열의 블랙 테마가 추가돼 눈길을 끈다.

그림 17. 화이트 테마와 블랙 테마(출처 : 자체 제작)
<인디케이터 디자인 변경>
타이젠 2.1은 시계 및 배터리 잔량을 표시하는 아이콘이 가운데 위치했던데 비해 타이젠 2.2에서는 시계 및 배터리 잔량 아이콘이 좌측으로 이동하였다.

그림 18. 변경된 인디케이터 디자인(출처 : 자체 제작)

 

타이젠 웹 UI 프레임워크
타이젠은 일관성 있는 웹 애플리케이션 UI 개발을 위해 제이쿼리 모바일(jQuery Mobile) 기반의 웹 UI 프레임워크를 제공하고 있다. 해당 UI 프레임워크를 사용할 경우 웹 애플리케이션 개발자들은 큰 어려움 없이 타이젠 뷰에 최적화된 UI를 구성할 수 있다.
타이젠 웹 UI 프레임워크를 사용하기 위해선 표 1에 기술된 3개 파일이 해당 HTML 파일 header에 포함되어 있어야 한다.
jquery.js ( version 1.8.2 이상 )
tizen-web-ui-fw-libs.js
tizen-web-ui-fw.js
표 1. 타이젠 웹 UI 프레임워크를 사용하기 위한 파일
타이젠 IDE의 타이젠 웹 UI 프레임워크 템플릿을 사용한다면 해당 파일들은 자동으로 포함된다. 위와 관련한 조금 더 자세한 사항은 타이젠 개발자 사이트[1]를 통해 확인하길 바란다.
이제 타이젠 웹 UI를 사용함으로써 얻을 수 있는 이점에 대해 알아보도록 하자.
<웹 애플리케이션 테마 지원>
타이젠 웹 UI 프레임워크를 사용한다면 프레임워크에서 지원하고 있는 화이트 또는 블랙 테마를 애플리케이션에 선택적으로 적용할 수 있다. 테마 선택 방법은 표 2와 같으며, 해당 스타일 속성을 오버라이딩(overriding) 할 경우 조금 더 개발자의 입맛에 맞는 테마를 제작할 수 있다.

그림 1.
화이트 테마(출처 : 자체 제작)

그림 2.
블랙 테마(출처 : 자체 제작)
// 화이트 테마를 선택할 경우
// 블랙 테마를 선택할 경우
표 2. 테마 선택 방법
<웹 위젯(widget) 지원>
타이젠 웹 UI 프레임워크를 사용한다면 표 3의 위젯을 손쉽게 사용할 수 있다.
이외에도 Tabbar, Context Popup, Progress 등 타이젠 뷰에 최적화된 다양한 위젯을 손쉽게 사용할 수 있다. 관련한 자세한 사항은 타이젠 개발자 페이지[1]를 통해 정보를 얻을 수 있고, 타이젠 IDE에 포함되어 있는 웹 애플리케이션 샘플코드인 TizenWinset을 통하여 각 위젯의 코드 및 뷰를 확인할 수 있다.

표 3.
웹 위젯(좌측부터 Button, Checkbox, Date picker, Popup, List)

그림 3.
Tabbar를 활용하여 구성한 화면(출처 : 자체 제작)
(HTML 코드)

Tabbar text with title

표 4.
Tabbar 위젯 활용 코드
(HTML 코드)

    (Javascript 코드)
    ② $(“#listcontainer”).append(”

  • Test”);
    ③ $(“#listcontainer”).listview(“refresh”);
    표 5. List 위젯 활용 코드
    앞에서 언급한 위젯 중 하나인 Tabbar위젯을
    실제로 어떻게 화면에 적용할 수 있는지 표 4 샘플 코드를 통해 확인해보자.
    (1) 최상단에 표기할 텍스트를 헤더 내에 작성한다.
    (2) ooter 부분에 태그를 추가하여 Tabbar를 구성한다. Tabbar 내부에서 ul태그를 활용하여 컨텐츠를 구성한다.
    별도의 스타일 시트나 HTML파일의 수정 없이도 위와 같이 모바일에 최적화된 뷰를 구성할 수 있다. 이는 곧 개발시간의 단축으로 이어질 수 있을 것이다.

    표 6. 애플리케이션 유형별 비교
    $( Page element ).on( “pageshow” ,
    function() {
    } );
    표 7. pageshow 이벤트 바인드
    이제 조금 더 동적인 웹 애플리케이션을 구성해보도록 하자. 단순히 HTML만을 사용해서 애플리케이션을 구성할 수도 있지만 자바스크립트 등을 활용하여 뷰를 구성할 경우 조금 더 사용자에 최적화된 경험을 제공할 수 있다.
    List 위젯에 아이템을 추가하는 예제 코드(표 5)를 통해 자바스크립트를 활용하여 화면을 구성하는 방법을 알아보도록 하겠다.
    (1) HTML을 통해 listcontainer라는 ID를 가진 list를 생성한다
    (2) 제이쿼리의 append 함수를 활용하여 list에 아이템을 추가한다
    (3) listview의 refresh API를 호출하여 화면을 갱신한다.
    표 5와 같이 HTML 코드를 단순히 뷰에 추가하는 것뿐만 아니라, 별도로 API를 호출해야 한다. 자바스크립트를 활용한 동적인 뷰 구축과 관련하여 더 자세한 사항은 제이쿼리 모바일 공식 웹사이트[2]에서 확인할 수 있다.
    <페이지 초기화 이벤트>
    제이쿼리 모바일 기반의 애플리케이션을 제작할 때 가장 애매한 부분은 언제 어떤 코드를 추가해야 하는지에 관한 것이다. 이는 제이쿼리 모바일이 자바스크립트를 활용하여 뷰를 재구성하기 때문인데, 페이지 초기화 이벤트를 정확하게 파악하고 있다면 큰 문제 없이 진행할 수 있는 부분이다.
    지난 호에도 언급한 것처럼, 타이젠 UI 프레임워크는 제이쿼리 모바일을 기반으로 하고 있고, 제이쿼리 모바일은 HTML내의 페이지 엘리먼트를 뷰의 최소 단위로 하고 있다. 페이지 엘리먼트는 표 6의 순서대로 이벤트가 발생한다.
    위의 이벤트는 표 7과 같은 방법으로 바인드하여 처리한다.
    페이지 초기화 이벤트에서 주의 깊게 살펴볼 부분은 pageshow 이벤트다. pageshow 이벤트가 발생하기 전까지 사실상 화면에는 아무것도 출력되지 않는다. 만약 pageshow 이전에 자바스크립트 등으로 복잡한 연산을 수행할 경우 사용자들은 마치 애플리케이션이 멈춰 있는 듯한 느낌을 받게 된다.
    그렇다고 pageshow 이후로 화면을 구성하는 코드를 작성한다면 화면 갱신이 단계적으로 발생하여 사용자에게 애플리케이션 완성도가 떨어지는 듯한 인상을 줄 수 있다. 페이지 라이프 사이클을 정확하게 파악하여 사용자에게 최고의 경험을 선사하는 애플리케이션을 개발해 보도록 하자.

    표 8.
    타이젠 디바이스 API 종류(일부)
    – 홈스크린(Homescreen), 락스크린(Lockscreen) 배경을 사용자가 원하는 이미지로 변경
    – 디바이스 기본정보 출력
    표 9.
    실습 프로그램
    디바이스(Device) API
    타이젠은 W3C 및 여러 표준 단체에서 지원하지 못하는 기능을 처리하기 위해 자체적으로 다양한 디바이스 API를 지원한다. 이를 통해 기존의 웹 플랫폼 대비 기기에 최적화된 기능을 더 많이 사용할 수 있다. 애플리케이션 라이프 사이클을 관리하든가 스케줄 관리, 데이터 전송, NFC를 이용한 결제 등의 기능을 수행할 수 있다.
    타이젠 디바이스 API는 크게 공통, 애플리케이션, 커뮤니케이션, 컨텐트, 입력/출력, 소셜, 시스템, 사용자 인터페이스로 나눌 수 있다. 각 카테고리 별로 다양한 종류의 디바이스 API를 제공하고 있으며 그 중 자주 사용하는 몇 가지 디바이스 API를 표 8에 설명했다. 더 많은 디바이스 API 설명은 타이젠 웹 디바이스 API 레퍼런스 사이트[3]를 참고하기 바란다.

    그림 4.
    Single Page Application 선택(출처 : 자체 제작)

    그림 5.
    타이젠 디바이스 API 등록(출처 : 자체 제작)
    타이젠 웹 애플리케이션 실습
    지금부터 간단한 예제 프로그램을 통해 타이젠 UI 프레임워크 및 타이젠 디바이스 API를 실습해 보자. 실습 프로그램은 표 9와 같다.
    앞으로 설명할 예제 프로그램은 150줄도 안 되는 짧은 소스코드로 위 기능을 모두 구현하고 있다. 물론 본 프로그램은 예제이기 때문에 간결한 전달을 위하여 예외처리 등은 삭제했다.
    하지만 이 예제를 통하여 짧은 소스로 많은 기능을 쉽게 구현할 수 있는 웹 애플리케이션의 장점을 경험할 수 있을 것이다. 타이젠 SDK 설치, 빌드 및 에뮬레이터 실행관련 설명은 이전 호를 참고하기 바란다.
    1. 타이젠 웹 애플리케이션 프로젝트 생성
    우선 타이젠 웹 애플리케이션 프로젝트를 만들어보도록 하자. 생성 순서는 다음과 같다.
    1) 타이젠 IDE 실행
    2) 상단 메뉴 중 File 선택 후 New > Project 선택
    3) Wizards 메뉴에서 Tizen > Tizen Web Pro ject 선택
    4) 그림과 같이 Template 탭에서 Tizen Web UI Framework 선택 후 Single Page Applica tion 선택(그림 9)
    5) Project name 입력
    6) Finish 버튼 클릭
    2. 타이젠 디바이스 API 사용 설정(config.xml)
    타이젠 디바이스 API를 사용하기 위해서는 프로젝트 생성시 자동 생성되는 config.xml 파일 내 Privileges를 설정해야 한다. Privileges를 설정하기 위해 config.xml 파일을 더블 클릭하면, 상단에는 Overview 내용이, 하단에는 메뉴탭이 표시된다.
    하단 메뉴 중에 Privileges를 선택한 후 Add 버튼을 통해 그림 5와 같이 필요한 타이젠 디바이스 API를 등록할 수 있다. 등록되지 않은 타이젠 디바이스 API는 사용할 수 없다.
    본 실습에서 필요한 타이젠 디바이스 API는 다음과 같다.
    – application.launch: 사용자가 원하는 이미지를 선택할 수 있는 외부 프로그램 호출시 필요
    – setting: 선택된 이미지를 홈스크린, 락스크린 배경으로 설정시 필요
    – system: 디바이스 정보 획득시 필요
    3. index.html
    HTML은 페이지 구조를 정의한다. 프로젝트 생성시 자동 생성된 index.html의 body 영역을 수정해 보도록 하자. 본 실습의 index.html는 main,about-phone 2개의 페이지로 구성되어 있다. 본 예제는 CSS 파일을 사용하지 않았지만 이 간단한 소스만으로 그림과 같이 디자인이 적용된 결과물을 출력한다. 이것은 우리가 제이쿼리 및 타이젠 UI 프레임워크를 사용하기 때문이다(표 10).
    ① 아이디가 main인 새로운 페이지를 정의한다.
    ② 헤더 영역에 System settings 텍스트를 출력하고 상단에 고정시킨다.
    ③ listview 생성후 list-divider 및 메뉴를 추가한다.
    ④ ui-li-dialogue 클래스로 지정된 li 태그에 ui-li-bigicon 클래스로 지정된 이미지와 텍스트를 삽입한다. 단순히 이미지 및 텍스트를 나열하였지만, 지정된 클래스 값에 따라 타이젠 UI 프레임워크는 그림 6, 7처럼 디자인을 변환해 준다(이미지 위치, 이미지 크기, 텍스트 위치, 텍스트 크기 등).
    ⑤ 메뉴 클릭시 “about-phone” 페이지로 이동할 수 있도록 “a” 태그로 페이지 이동을 처리했다. 이와 달리 Home screen, Lock screen 메뉴는 자바스크립트로 이벤트를 처리하는 예제이기 때문에 “a” 태그 내에 주소를 넣지 않았다.
    ⑥ 아이디가 about-phone인 새로운 페이지를 정의한다.
    … (헤더 생략) …

    System settings

    표 10. index.html 코드

    그림 6. main 페이지(좌측), 그림 7. about-phone 페이지(각 출처: 자체 제작)
    4. main.js(1)
    index.html을 실행하면 페이지 디자인 출력 및 “About Phone”클릭시 메뉴 이동이 정상적으로 될 것이다. 하지만 스크린샷 변경 버튼이 작동하지 않고, about-phone 페이지의 시스템 정보가 출력 되지 않는다. 이것을 구현하기 위해서는 표 11과 같이 웹 애플리케이션의 동적인 역할을 담당하고 있는 자바스크립트를 작성해야 한다.
    ① main 페이지가 최초 초기화될 때 해당 함수가 호출된다.
    ② home-screen-button 아이디를 가지는 엘리먼트 (

  • )에 tap 이벤트를 등록한다. 해당 이벤트가 발생하면 launchImagesGal lery를 호출하여 그림13과 같이 이미지를 선택 할 수 있는 외부 프로그램을 실행한다.
    ③ 타이젠 2.2에서는 하드웨어 뒤로가기(back) 키를 지원하기 때문에 하드웨어 키 이벤트를 처리해야 한다. 첫 페이지인 main 페이지에서 back 키 이벤트가 발생하면 프로그램을 종료하고, 이외에 페이지에서 back 키 이벤트가 발생하면 이전 페이지로 이동시킨다.
    ④ 호출할 외부 프로그램의 Operation 및 MIME Type을 지정한다. 해당 Operation 및 MIME값에 따라 미리 정의된 프로그램이 호출된다. 자세한 Operation 및 MIME 타입은 타이젠 공식 문서[4]를 참고 바란다.
    ⑤ 타이젠 디바이스 API인 AppControl로 ④번에서 지정한 외부 프로그램을 실행한다.
    ⑥ 외부 프로그램의 반환 값(여기서는 사용자가 선택한 이미지)을 타이젠 디바이스 API인 시스템세팅을 사용하여 배경이미지로 설정한다(그림 9).
    ①$(document).delegate(“#main”, “pageinit”, function() {
    ②$(“#home-screen-button”).bind(“tap”, function() {
    launchImagesGallery(‘HOME_SCREEN’);
    });
    $(“#lock-screen-button”).bind(“tap”, function() {
    launchImagesGallery(‘LOCK_SCREEN’);
    });
    ③$(window).on(‘tizenhwkey’, function (e) {
    if (e.originalEvent.keyName === “back”) {
    if ($.mobile.activePage.attr(‘id’) === ‘main’) {
    tizen.application.getCurrentApplication().exit();
    } else {
    history.back();
    }
    }
    });
    });
    function launchImagesGallery(type) {
    var service, onReply;
    onReply = {
    onsuccess: function (data) {
    ⑥tizen.systemsetting.setProperty(type, data[0].value[0], function () {}, function () {});
    },
    onfailure: function () {}
    };
    ④service =new tizen.ApplicationControl(‘http://tizen.org/appcontrol/operation/
    pick’,null,”image/png”);
    try {
    ⑤tizen.application.launchAppControl(service,null,function () {},function (err) {},onReply);
    } catch (error) {
    }
    }
    (…)
    표 11.
    main.js(1)

    그림 8. 파일을 선택할 수 있는 프로그램(좌측), 그림 9. 변경된 배경 이미지(각 출처: 자체제작)
    5. main.js(2)
    ① “pagebeforeshow” 이벤트에 따라”about-phone”페이지 화면이 출력되기 전 함수가 호출된다.
    ② 시스템 정보를 제공하는 타이젠 디바이스 API인tizen.systeminfo.getPropertyValue를 ‘BUILD’옵션으로 호출하였다. 정상적으로 타이젠 디바이스 API가 수행되면 콜백 함수로 등록한 updateBuild가 호출된다. 이 때 요청한 시스템 정보가 매개변수로 전달된다.
    ③ manufacturer-value의 아이디를 가진 엘리먼트()에 value.manufacturer 값이 출력된다(그림 10).
    타이젠 웹 애플리케이션 샘플
    타이젠 IDE에는 타이젠 UI 프레임워크, 타이젠 디바이스 API 및 W3C API 등을 사용한 다양한 타이젠 웹 애플리케이션 샘플이 내장되어 있다.
    또한 타이젠 공식 웹사이트의 샘플 웹 애플리케이션 페이지[5]에도 게임 및 유틸리티 장르의 타이젠 웹 애플리케이션 샘플이 등록되어 있다.
    이 샘플을 활용한다면 타이젠 웹 애플리케이션 개발에 큰 도움이 될 것이다.
    (…)
    ①$(document).delegate(“#about-phone”, “pagebeforeshow”, function() {
    ②tizen.systeminfo.getPropertyValue(‘BUILD’, updateBuild, null);
    tizen.systeminfo.getPropertyValue(‘BATTERY’, updateBattery, null);
    tizen.systeminfo.getPropertyValue(‘CPU’, updateCpu, null);
    });
    function updateBuild(value) {
    ③$(‘#manufacturer-value’).html(value.manufacturer);
    $(‘#model-value’).html(value.model);
    }
    function updateBattery(value) {
    $(‘#battery-value’).html((value.level * 100) + ‘%’);
    }
    function updateCpu(value) {
    $(‘#cpu-value’).html((value.load * 100) + ‘%’);
    }
    표 12.
    main.js(2)

    그림 10. about-phone 페이지(출처 : 자체 제작)</TABBAR위젯>

     

     

     

     

     

     

     

    http://www.embeddedworld.co.kr/atl/view.asp?a_id=6441

    http://www.embeddedworld.co.kr/atl/view.asp?a_id=6539