Manifest for web application 요약

2015.02.14 15:39

Manifest for web application을 사용할 일이 있어 스펙을 살펴보며 간단히 정리했다. 이 스펙은 web application을 브라우저가 아닌 곳에서 실행시킬 때 기기에서 표시할 정보와 실행에 필요한 정보를 저장하는 방법에 대해 정의하고 있다. 모바일 사이트나 web os등 이 스펙이 사용되는 곳은 심심치 않게 있겠지만 일반 사용자에게는 거의 눈에 띄지 않는 스펙이기도 하다.


개인적인 필요로 http://w3c.github.io/manifest/ 문서를 한 번 살펴보면서 정리한 것이므로 개인적으로 불필요하다고 생각하는 부분은 정리하지 않았고 문서의 품질을 높이기 위해 리뷰를 하지 않았으므로 내용이 누락되어 있거나 오역이 있을 가능성이 높다. 그러므로 이 문서를 참고할 분들은 적용 전에 반드시 원본 문서를 참고하면 좋겠다.


===


Manifest for web application

Editor’s Draft 

11 Feb 2015


http://w3c.github.io/manifest/


요약

이 스펙은 개발자들이 웹 애플리케이션의 메타 데이터를 집중해서 관리할 수 있는 JSON 기반의 선언 방법을 정의한다. 앱의 이름, 링크, 아이콘을 지정하는 일 외에도 시작할 때 열리게 되는 페이지 등을 지정할 수 있다. 웹 앱의 기본 화면 방향이나 표시 방법 (풀스크린과 같은) 을 설정할 수 있다. 또한 앱을 URL에 scope하도록 함으로써 웹 앱에서 다른 웹 앱으로 이동할 수 있는 딥 링크를 사용할 수 있는 방법을 제공한다.


메타데이터를 사용하면 user agent (이하 ua)는 개발자들에게 네이티브 앱처럼 동작하는 사용자 경험을 제공할 수 있는 방법을 제공한다.


또한 여기서는 manifest 링크 타입을 정의하며 이는 문서 내에서 manifest를 연결하는 선언 방법을 제공한다.


1. 사용 예


1.1 일반적인 manifest의 예

{

  "name": "Super Racer 2000",

  "short_name": "Racer2K",

  "icons": [{

        "src": "icon/lowres",

        "sizes": "64x64",

        "type": "image/webp"

      }, {

        "src": "icon/hd_small",

        "sizes": "64x64"

      }, {

        "src": "icon/hd_hi",

        "sizes": "128x128",

        "density": 2

      }],

  "scope": "/racer/",

  "start_url": "/racer/start.html",

  "display": "fullscreen",

  "orientation": "landscape"

}


1.2 link를 사용한 manifest의 연결

<!doctype>

<html>

<title>Store finder - search</title>


<!-- Startup configuration -->

<link rel="manifest" href="manifest.json">


<!-- Fallback application metadata for legacy browsers -->

<meta name="application-name" content="Store Finder">

<link rel="icon" sizes="16x16 32x32 48x48" href="lo_def.ico">

<link rel="icon" sizes="512x512" href="hi_def.png">


2, 설치할 수 있는 웹 앱

manifest의 값들은 top-level browsing context (application context)에서 유효하다. > see 6.3


2.1 설치 가능 표시

적절한 값이 지정된 manifest가 있다면 ua에서는 설치 가능하다고 판단할 수 있음

하지만 정확한 기준은 브라우저마다 다를 수 있음


3. navigation scope

manifest랄 적용했을 때 application context가 이동할 수 있는 URL을 표시한 것


scopeUrl이 지정되어 있지 않거나 targetUrl과 scopeUrl이 same origin이고 pathname이 scopeUrl의 pathname으로 시작하면 이동 가능.

navigation scope은 scope 값으로 지정. 지정하지 않으면 unbounded 상태. 모든 url로 이동 가능


3.1 고려해야 하는 보안 문제

unbounded이고 browser 모드가 아닌 경우 ua에서는 보안/프라이버시 문제가 발생하면 사용자에게 알려야 함


3.2 deep links

설치된 웹 앱의 범위 내에 있는 url


4. display mode

사용자에게 보여지게 될 모습을 지정

display mode를 지정하면 top-level browser context에서 기본 display mode가 됨

기본은 browser

browser를 제외하고는 fallback display mode가 있다.


fullscreen: ua chrome이 없고 화면 전체를 사용

standalone: native app처럼 보임

minimal-ui: fullscreen과 비슷하나 네비게이션을 컨트롤 할 수 있는 최소의 ui를 제공

browser: 플랫폼에서 지정된 ua사용


4.1 display-mode 기능

css에서 display-mode로 구별하여 css를 지정할 수 있따.

EcmaScript에서는 matchMedia()를 사용하여 값을 확인할 수 있다.


5. 리소스와 manifest를 연결

resource는 리소스의 표현자인 html 문서에 manifest 링크 관계가 포함되어 있을 때 manifest와 연결되어 있다고 한다.


5.1 manifest 연결

link 엘리먼트를 이용하여 manifest 키워드를 사용할 수 있다.


manifest 타입이 여러개 있을 경우 첫 번째 line 엘리먼트만 유효하다.


6. manifest 라이프 사이클


6.1 manifest의 획득

브라우저에서 성공하면 처리된 manifest와 manifest url을 반환하지만 다른 경우에는 바로 멈추고 아무것도 반환하지 않음. 아무것도 반환되지 않으면 브라우저는 manifest 선언을 무시해야 함. 이 과정에서 브라우저는 load 이벤트를 지연시켜서는 안됨


manifest를 캐시하기 위해서는 명시적으로 캐시 선언자를 지정하기를 권장함


6.1.1 컨텐트 보안 정책

manifest-src, default-src를 사용하여 ua가 manifest를 얻을 수 있는 출처를 지정할 수 있음.

기본적으로 manifest-src는 * 이며 ua는 cors를 통해 어떤 곳에서도 값을 받아올 수 있음.


6.2 manifest의 처리

개발자에게 경고를 해야 할 때, ua에서 에러를 표시할 수도 그렇지 않을 수도 있음

에러를 무시할 경우 ua는 내용이 지정되지 않은 것처럼 처리되어야 함


extension point: 다른 스펙에서 새로운 종류의 값을 manifest에 추가하는 방법


manifest 처리 순서

파싱

extension point: 다른 값을 처리

start URL

display mode

orientation

name

short name

icons

scope

파싱이 끝난 manifest 반환


6.3 manifest의 적용

top-level browsing context에 manifest 적용

manifest의 값이 표시 방법이나 동작에 영향을 미치게 됨

manifest가 적용된 top-level browsing context는 application context라고 함


ua가 딥링크로 이동하는 요청을 받아 application context가 생성되면

ua는 즉시 replacement enabled[?]인 상태로 딥링크로 이동해야 함


6.4 manifest의 갱신

manifest URL을 사용하면 ua는 변경 여부를 주기적으로 확인하기도 한다. (HTTP cache 선언자에 따르거나 실행 이후의 업데이트를 확인) 변경 내용이 있다면 동일한 처리 방법으로 갱신한다.

변경사항이 없더라도 manifest에서 지정한 리소스가 변경됐는지를 주기적으로 확인할 수도 있다.

변경사항이 있으면 업데이트를 할 수도 있다.


7 manifest와 구성 요소

manifest는 웹 애플리케이션이 실행될 때 시작 파라미터와 기본값을 담고 있는 JSON 문서다.


7.1 name

웹 앱의 이름을 표시하는 문자열

meta element에서 application-name 속성과 동일하게 동작한다.

지정하지 않을 경우 application-name이나 title의 값으로 대신한다.

trim된 값을 사용함


7.2 short_name

웹 앱의 짧은 이름을 표시하는 문자열

공간이 부족할 때 사용

trim된 값을 사용


7.3 scope

application context에서 이동할 수 있는 범위를 나타내는 문자열


7.4 icon

icon 객체의 배열. 아이콘으로 표시되어야 하는 곳에서 다양하게 사용된다.

icon 객체는 src, type, sizes, density로 구성될 수 있다.

동일한 선언이 있는 경우 마지막에 선언된 것을 사용


7.5 display

display mode를 나타내는 문자열

값이 지정되지 않거나 잘못 지정되면 ua에서는 항상 대체 방안을 적용해야 한다.


7.6 orientation

기본 방향을 설정

any

natural

landscape

portrait

portrait-primary

portrait-secondary

landscape-primary

landscape-secondary

중에 선택 가능 (https://w3c.github.io/screen-orientation/#idl-def-OrientationLockType)


7.7 start_url

사용자가 처음 실행시켰을 때 ua에서 로드할 url 문자열

권고 사항임. 사용자가 북마크 하는 과정에서 변경될 수도 있음.

manifest 파일의 url의 상대 경로로 지정할 수 있음.


8. icon 객체와 구성 요소

ua에서 조건이 가장 잘 맞는 아이콘을 찾게 됨

rel 속성이 icon인 link 엘리먼트와 동일한 기능


8.1 icon 객체의 내용 보안 정책

아이콘 로드는 manifest를 참조하는 문서와 연관된 image-src 선언자에 의해 결정된다.


8.2 density

icon에 최적인 device pixel density 

dot per px로 지정

0보다 큰 값

기본 값은 1.0


8.3 sizes

공백으로 구분되는 토큰의 집합으로 구성되는 문자열

토큰은 대소문자를 가리지 않으며

아이콘의 크기를 나타낸다.

값은 any나 양수로 표시하며 x(또는 X)로 구별한다.

실제 pixel값을 의미함


8.4 src

ua가 icon 데이터를 얻어올 수 있는 url

manifest의 url을 기준으로 값을 계산한다.


8.5 type

icon의 media type에 대한 힌트.

ua에서 지원하지 못하는 종류를 걸러내기 위한 것이 목적

기본 값은 없으나 ua에서는 image타입으로 예상해야 한다.


기타

manifest의 media type은 application/manifest+json




nundefined HTML5_JS_CSS html5, manifest, w3c, Web Application

  1. iOS에서의 add to homescreen
    https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html#//apple_ref/doc/uid/TP40002051-CH3-SW3

    android에서의 add to homescreen
    https://developer.chrome.com/multidevice/android/installtohomescreen

  2. android의 옛날 버전을 지원하기 위해
    <meta name="mobile-web-app-capable" content="yes">
    를 사용하면 주소창이 노출되지 않는 상태로 실행된다.

WebSocket API

2013.07.15 23:40

지난 7월 13일 강남역에서 열렸던 JSLounge 여섯번째 세미나에서 발표한 WebSocket API 자료이다.



WebSocket의 경우 표준이 논의된지 상대적으로 오래된 상황이라 이미 다양한 라이브러리가 나와 있고 WebSocke에 대한 번역서도 나와 있을 정도로 널리 알려진 프로토콜/API이다. 개인적으로 업무에 활용하게 되면서 내용을 살펴봤고 HTTP와는 달리 서버와 항상 연결되어 있다는 점에서 게임, 채팅, Push 등 HTTP의 약점을 메꿀 수 있을 것이라고 생각한다.


API는 간단한 편이나 프로토콜까지 살펴보기에는 다소 어렵다는 생각이 든다. 특별히 WebSocket을 지원할 서버를 만드는 것이 아니라면 프로토콜을 살펴보지 않아도 충분하며 API의 사용법을 간단히 익힌 후 API를 직접 사용하기 보다는 좋은 라이브러리를 찾는 편이 빠르게 개발할 수 있는 길이라고 생각한다.



nundefined Presentations html5, socket.io, WebSocket, 웹소켓

HTML5 API - The Screen Orientation API and Fullscreen

2013.05.20 22:34

지난 5월 2일 JSLounge의 다섯 번째 세미나에서 발표한 HTML5 API - The Screen Orientation API and Fullscreen 발표자료이다. 지난 달 게임을 개발할 때 유용하게 사용할 수 있는 HTML5 기능들에 대해 조사하다가 조금 더 자세히 알아보고 싶은 생각이 들어 주제로 정했다. 




Fullscreen은 이미 플래시에서의 전체 화면 기능이나 동영상을 볼 때 종종 사용했던 기능으로 프로그램을 사용하여 기능을 제어할 수 있다는 점을 빼면 특이한 내용은 없다. 개발자의 관점에서는 혼동할 수 있는 부분이 있으나 특별히 어려운 것은 아니다. 


반면 Screen Orientation API의 경우 앞으로 모바일 웹 또는 웹앱을 만들면서 제작자의 의도를 잘 표현하기 위해 필요한 내용이다. 내용이 어려운 것은 아니나 device의 회전(window.orientation)과의 차이점에 대해 이해하고 있어야 활용이 용이할 것으로 생각한다. 아직 지원하는 모바일 웹 브라우저가 많지 않은데 그 이유는 Screen Orientation API가 엄밀히 말하면 HTML 5.1에 해당하는 명세이기 때문이다. 하지만 내년 이맘때 정도면 어떤 브라우저에서든 사용할 수 있지 않을까 조심스럽게 예상해본다.






nundefined Presentations FullScreen, html5, jslounge, screen orientation

fluent 2013에서 관심 있는 세션

2013.03.01 12:09

JavaScript와 HTML5를 주제로 하는 Fluent 컨퍼런스가 5월 28일부터 30일까지 샌프란시스코에서 열린다. 한 번쯤 가보고 싶은 컨퍼런스지만 이래저래 연이 닿고 있지 않은 컨퍼런스다. 트위터를 돌아다니다가 누가 이 컨퍼런스에 대해 이야기했길래 가볍게 스케쥴을 살펴보다가 관심이 생기는 세션 몇 개를 정리해본다.


Secrets of Awesome JavaScript API Design

혼자만 사용할 기능을 만드는 것이 아니라면 항상 고민하게 되는 주제이다. 설명 중 APIs are developer UX.라는 표현이 와닿는다.


Who Killed My Battery: Analyzing Mobile Browser Energy Consumption

모바일 브라우저와 배터리 소모량의 관계라니. 삼성전자와 같은 곳에서는 이에 대한 정보가 있겠지만 그 누구도 이야기해주지는 않는다. 웹서비스 회사에서는 관심도 없고 측정하려 하지도 않고. 좋은 정보를 얻을 수 있을 것 같다.


Web Components: A tectonic Shift for the Web Platform

아직 널리 퍼지진 않았지만.. 조금 더 보기 좋은 웹을 만드는데 도움이 될 것이라고 생각한다.


How To (Semi-)Automate JavaScript Refactoring

Refactoring에서 한 번 낚이고, Automate에서 두 번째로 낚이고, (Semi-)에서 빵 터졌다. 보다 좋은 코드를 만드는데 도움이 될 것 같다.


Break Out of The Browser With HTML5

구글 패키지드 앱이 주제로 보이는데.. 들어본 적이 있는 것 같기도 하고 아닌 것 같기도 하고 가물가물하다. 구글 확장 프로그램을 볼 때 봤던가.. 각설하고, Google Packaged Apps가 업데이트 됐다보다. 이에 대한 세션. 브라우저 바깥에서도 의미있는 HTML5를 만드는 좋은 도구가 될 듯.


Improving JavaScript Code Quality: Strategies and Tools

코드의 퀄리티가 생산성이나 총 운영비용의 감소로 이어진다는 이야기는 개발자 사이에서 많이들 하는 이야기고 -내가 모르는 어느 곳엔가- 이에 대한 연구 결과도 있을 것으로 예상된다. 하지만 최근의 내 주위에서는 동작만 하면 장땡이라는 사업가들이 너무 많아서 뭐가 옳은지 혼란스럽다. 어쨌든.. 2~3년 전에 시도했다가 지금은 싸그리 없애버린 JavaScript Code의 품질에 대한 세션. 아마 계속 했으면 이런 것도 가능했을라나.


An Overview of ECMAScript6

다음 버전의 자바스크립트 표준인 ECMAScript6에 대한 세션. 올해 말까지 표준 제정이 끝나고 나면 내년부터는 이 표준을 사용할 수 있는 브라우저들이 훨씬 많아질 것이다. 전공 필수 과목같은 느낌으로 들어야 할듯.


Scraping the World with JavaScript

Node.js로 만드는 크롤러와 스크랩퍼라니.. 재미있을 것 같다. 만들어보고 싶은 것이 있어서 Python 공부를 좀 해봤는데 그냥 때려치고 Node.js로 가버릴까..;;



세션들을 살펴보다가 들은 생각은 클라우드로 백엔드 하나쯤은 구성할 수 있어야 한다는거랑 WebRTC가 있는데 소개만 봐서는 며칠 전에 한 Getting Started with WebRTC와 큰 차이가 없어보인다는 것.


Fluent는 작년의 경우 컨퍼런스 참석자들에게 모든 세션의 동영상을 제공해줬는데 올해도 그럴지 궁금하다. 주변에 컨퍼런스 가는 사람이 없을지 잘 찾아봐야겠다.







nundefined HTML5_JS_CSS code quality, ECMAScript, ecmascript6, fluent, fluent conf, html5, javascript, node.js, refactoring, web components, webrtc

Getting Started with WebRTC

2013.02.28 01:11

지난 화요일 JSLounge의 네 번째 세미나에서 Getting Started with WebRTC라는 제목으로 WebRTC에 대해 발표했다. 완전히 새로운 구성으로 발표를 하기에는 아직 스스로도 WebRTC에 대해 잘 알지 못하기에 스스로도 이번 기회에 공부한다는 목표로 http://www.html5rocks.com/en/tutorials/webrtc/basics/ 의 내용을 정리하는 방법을 이용했다.



이번 준비를 하면서 느낀 것은 WebRTC가 단순히 카메라와 마이크로 수집한 정보만을 보내기 위한 스펙이 아니고 많은 활용 가능성이 있는 스펙이라는 점이다. 여러 보안 문제로 브라우저에서 실행되는 이상 데스크톱 애플리케이션만큼의 강력함을 발휘하기는 어렵겠지만 이러한 문제는 일부 디바이스에서는 자연스럽게 해결되리라 생각하며 그런 경우 매우 강력한 도구가 될 것이다.


nundefined Presentations html5, html5rocks, webrtc