http://www.w3.org/Mobile/mobile-web-app-state/

2013년 2월


0. 개요

- 현재 웹기술이 full-featured 모바일 앱을 만들만큼 충분히 무르익음

- W3C는 웹앱 개발 기술을 확장하기 위해 노력하고 있으며 관련 교육 링크도 운영하고 있음 (http://www.w3devcampus.com/writing-great-web-applications-for-mobile/)


1. Graphics

- SVG : Scalable 벡터 그래픽 표준

- Canvas : 2D programmatic API 표준

- 폰트 : WOFF(Web Open Font Format) 표준

- Fullscreen API, Screen Orientation API 표준

* WebGL(3D graphic API)은 W3C 밖에서 표준화 작업 진행 중(Khronos Group)

* 표준화 안정 단계, 표준 적용 활성화 단계


2. Multimedia

- <video>, <audio> 태그 : 과거 image처럼 멀티미디어 요소를 Web의 1st class citizen으로 취급

- Encrypted Media Extensions : DRM 컨텐츠 재생에 관한 표준

- Pick Media Intent, Networked Service Discovery API : DLNA 컨텐트에 대한 접근 표준

- HTML Media Capture : 카메라, 마이크(녹음) 등에 의한 captured 컨텐트에 대한 접근 표준

- Web Real-Time Communication WG 활동 중

- Web Audio API : 오디오 컨텐트에 대한 분석, 수정, 합성을 위한 API 표준

- W3C Web and TV Interest Group : 모바일 Web을 통해 TV 시청 경험을 풍요롭게 하는 연구 진행 중

* 표준화 초기 단계, 표준 적용 초기 단계(모바일에서 활용 제한적)


3. Device Adaptation

- Device Description Repository API : 다양한 장치 특성(스크린 크기, 입력 장치 특성, 미디어 기록/재생 특성 등)을 조회할 수 있는 server-side API 표준

- Media Capture Streams API : 카메라, 마이크 등의 media capture 장치 제어 표준

- CSS Media Query : 반응형 layout 지원 표준

- Adaptive images(picture 태그, srcset 속성) : 화면 크기에 최적인 이미지를 다운로드 하도록 지원

* 표준화 초기 단계, 표준 적용 초기 단계


4. Forms

* W3C는 모바일 기기의 제한된 입력 기능을 보완하기 위한 form 구성 요소를 지원하기 위해 노력 중

- date and time <input type="date">: OS가 제공하는 native calendar 컨트롤 사용 지원

- <input type="email">, <input type="tel">, <input type="url"> : 데이터 형태에 따른 키보드 지원

* 표준화 안정 단계, 표준 적용 초기 단계


5. User interactions

- Pointer Events : 터치 기기 및 마우스 등의 전통적 포인터 기기의 이벤트 관련 표준

- vibration API : 햅틱 피드백(진동) 관련 표준

- IndieUI Events : 기기별 specific 이벤트를 한 레벨 추상화한 이벤트 표준("click", "key press", "touch" 이벤트를 대신하는 "undo", "next page" 이벤트)

- Web Notifications : 웹을 통한 사용자 notification 표준

- Speech API Community Group : 음성인식 기반 사용자 인터랙션 표준 논의 중

- Mobile Accessibility, WAI-ARIA : 장애인을 위한 웹 접근성 관련 표준 논의 중

* 표준화 초기 단계, 표준 적용 초기 단계


6. Data storage

- Web Storage : 브라우저를 통한 간단한 데이터 저장/관리 API 표준

- File Reader API, File Writer API, FileSystems API : 정교한 파일 관리 API 표준

- Indexed Database API : 로컬 DB 관리 API 표준

- Quota Management API : 웹앱을 위한 로컬 저장공간 확보 관련 API 표준

- Web Cryptography API : 데이터 암호화 관련 API 표준

* 표준화 초기 단계, 표준 적용 초기 단계


7. Personal Information Management

- Contacts API, Calendar API : 주소록, 일정 정보 관리 API 표준

* 관련 API 표준이 Web Intents 기반 API 형태로 대치되고 있는 중

* 표준화 아주 초기 단계, 표준 적용 전무


8. Sensors and hardware integration

- Geolocation API : 센서를 통해 기기의 현재 위치를 알아내는 API 표준(GPS, WiFi 네트웍, Cell 네트웍 등의 방법 등 중 가능한 방법을 이용)

- DeviceOrientation Event Specification : 센서를 통해 기기의 가로/세로 상태를 알아내는 API 표준

- Battery Status, Proximity sensors, Ambient Light Events 등 표준 stable 단계

- NFC WG : NFC 관련 표준 논의 중

* 표준화 안정 단계, 표준 적용 초기 단계


9. Network

- XMLHttpRequest : AJAX API 표준

- Cross-Origin Resource Sharing : 현재 웹 페이지와 다른 도메인의 자원을 공유하기 위한 표준

- Push API : 웹앱이 (브라우저에 활성화되지 않은 상태에서도) 서버로부터 전달되는 메시지를 수신하기 위한 표준

- WebSocket API : 저비용 양방향 통신 지원 표준

- Web Real-Time Communications : P2P 데이터 통신 지원 표준

- network-information API : 현재 이용하고 있는 통신망의 bandwidth 등의 정보를 파악하기 위한 표준

* 표준화 안정 단계, 일부 표준 적용 단계


10. Communication and Discovery

- Messaging API : sms://, mms://, mailto:// 등 URI 스킴 기반 메시지 전달 표준, Web Intents 방식으로 재정의될 예정

- Networked Service Discovery API : DLNA등 로컬 네트웍 서비스와 웹앱 사이의 seamless 협업을 위한 표준

- Web Real-Time Communications WG : 커뮤니케이션 관련 표준을 주도적으로 논의 중

* 표준화 초기 단계, 표준 적용 초기 단계


11. Packaging

* 웹앱을 오프라인 상태에서 이용하기 위한 표준과 웹앱을 app store를 통해 유통할 수 있는 포맷으로 만들기 위한 표준

- ApplicationCache : 웹앱을 오프라인 상태에서도 이용하기 위한 표준

- W3C Widgets : 웹앱을 ZIP 형태로 패키징하기 위한 표준

* 표준화 안정 단계, 일부 표준 적용 단계


12. Performance & Optimization

- Web Performance WG : Navigation Timing, Resource Timing, Performance Timeline, User Timing 등 웹앱 성능 최적화 도구 개발 중

- Page Visibility API : 페이지가 보이지 않는 시점에서 네트웍 자원 사용을 억제하기 위한 표준

- battery API : 배터리 잔량에 따라 자원 활용을 억제하기 위한 표준

- Web Workers : 리소스를 많이 소비하는 작업을 백그라운드 스레드로 처리하기 위한 표준

* 표준화 안정 단계, 표준 적용 초기 단계


(이상)

Posted by ingeeC
,

코너스톤 WDK (Cornerstone WDK)


SKT가 만든 코너스톤 WDK (Web Dev. Kit)를 소개합니다.

코너스톤 WDK의 핵심은 코너스톤 프레임웍 (이후 f/w)입니다. 코너스톤 f/w을 만들면서 염두에 두었던 생각들을 요약합니다. 상세한 내용은 http://cornerstone.sktelecom.com 에서 확인할 수 있습니다.


1. 힘 빼고 만들었습니다.

SKT가 처음부터 끝까지 세상을 새로 만들겠다는 못된(?) 욕심을 버리고 접근했습니다. 거인들의 업적을 존중하면서 그 어깨 위에 작은 노력을 더해 세상에 기여하겠다는 철학으로 접근했습니다. 개발자들에게 인기 높은 검증된 오픈소스 f/w들을 기반으로 코너스톤 f/w을 개발했습니다. 이미 익숙한 f/w들을 근간으로 하고 있기 때문에 개발자 입장에서는 학습 비용이 적을 뿐 아니라, 코너스톤 f/w을 쓰기 위해 학습한 내용을 다른 f/w들을 개별적으로 쓸 때도 활용할 수 있을 것입니다.


2. Modern Web App 개발의 최신 동향을 담았습니다.

Modern Web App 개발의 최신 기술들을 지원합니다. 코너스톤 f/w은 UI f/w 뿐만 아니라 모듈화, MVC (Model-View-Control 패턴), RWD (Responsive Web Design) 등 Javascript 프로그래밍의 핵심 동향을 모두 포함하고 있는 full featured Javascript f/w 입니다. 그리고 코너스톤 f/w은 UI f/w과 MVC f/w 사이의 정합성을 맞추는데 상당한 노력을 기울였습니다. 코너스톤 f/w을 이용하면 개별 f/w들을 따로 선택하고 이들 사이에 정합성을 맞추는데 소요되는 비용을 줄일 수 있습니다.


3. 모바일에서의 성능 보장을 위해 노력했습니다.

코너스톤 개발을 시작할 당시, 세상에 공개된 거의 모든 모바일 UI f/w들을 검토하고 성능을 비교했습니다. 코너스톤 f/w은 트위터 Bootstrap을 UI f/w의 근간으로 선택했습니다. Bootstrap의 간결함을 유지하면서 Bootstrap에 모자란 모바일 Widget과 기능을 추가했습니다. 조심스럽지만, 현재 시점에서 가장 빠르고 안정적인 모바일 UI f/w이라고 자신합니다.


4. 한글 문서를 제공합니다.

정말 공들여 만든 한글 문서를 제공합니다. f/w을 만들면서 배우고 느낀 내용을 모두 담으려고 노력했습니다. 한국의 SW 분야가 성공하려면 제대로된 한글 개발문서가 축적되고 공유되어야 한다고 생각합니다. 코너스톤 개발문서가 조그만 기여를 할 수 있으면 좋겠습니다. 코너스톤 f/w 개발문서는 정적으로 고정된 문서가 아니라 샘플코드를 작성하고 결과를 확인할 수 있는 살아있는 문서입니다 (http://cornerstone.sktelecom.com/livedoc/).


운 좋게도 훌륭한 개발자 분들을 만나서 신나게 개발할 수 있었습니다. 하지만 아직은 미약한 시작입니다. 개발자 분들의 소중한 의견을 듣고 싶습니다. 코너스톤 블로그에 의견 남겨 주세요.


Posted by ingeeC
,

BaaS 개요 및 현황


+ BaaS란?

    - 모바일 어플리케이션에 특화된 클라우드 서비스

    - 서버사이드 개발 능력 없이도 손쉽게 Backend를 구축

    - 모바일 생태계와 밀접한 관련이 있음

    - '11년 태동된 따끈한 서비스 사업


+ BaaS를 사용하지 않으면(즉, 서버사이드를 직접 개발하면),

    - 서버사이드 SW 개발에 막대한 비용 소요

    - 운영 인프라 확보에 막대한 비용 소요

    - 운영 라이선스 확보에도 막대한(?) 비용 소요

    - Time to Market 보장 못함


+ BaaS 서비스 종류

    - 데이터 저장

    - Push Notification

    - Social 통합

    - 사용자관리/권한제어

    - Rating

    - 인증

    - Location

    - Billing 

    - 사진 저장 및 공유

    - 기타등등...


+ BaaS 사용자들이 선호하는 서비스 순위

    - 1위 Location Service(35%), 2위 Notification(33%), 3위 Rating(11%)


+ BaaS의 목표

    - 서버코드를 작성 않고도 클라이언트가 서버 API를 호출하여 필요한 Backend 서비스를 이용

    - 모바일 어플리케이션의 개발 효율 제고


+ BaaS의 기능이 확장되면서 PaaS와 경계가 모호해지는 경향이 존재함

    - 커스텀 API 생성 지원

    - Java, Ruby, Python, Lua 등을 통한 Biz로직 커스터마이징 지원


+ 관련 업체

    - Appcelerator : Titianium 개발업체, 최근 BaaS 업체인 Cocoafish를 인수함

    - Parse : 공개 베타 종료, 정식 서비스 오픈함

    - 기타 StackMob, Kinvey, Apple iCloud, RhoMobile 등

    - 현재(2012년 04월 기준), BaaS 참여업체는 최소 20개


+ BaaS 제공업자가 고민해야 할 점

    - 클라우드를 통한 확장성(Scaling), 높은 가사용성(Availability)

    - Backend 데이터 보안(Security), 신뢰성(Reliability)

    - 서비스 재사용성(Reusability of Services)

        - 서비스가 특정 App과 tightly coupled되지 않게 주의해야 함

        - 그래야 App 개발 생산성을 보장할 수 있음


+ BaaS 사용자가 고민해야 할 점

    - 벤더 안정성

        - 벤더가 갑자기 가격정책을 변경하면?

        - 벤더가 갑자기 없어지면?


+ BaaS 가격 정책 예시(API 호출 횟수에 따라 과금)

    - free tier: 500,000 calls/month 까지 free

    - paid tier: 500,000 calls/month 이후, 

        - 매 1000 calls 당 $0.2

        - 10 million calls/month 당 $249

        - 매 1000 calls 당 $0.15

    - enterprise tier: 비밀?



Reference

BaaS(Backend as a Service) 에 대하여

http://www.mimul.com/pebble/default/2012/05/05/1336192251452.html


The Rise of Mobile Cloud Services: BaaS Startups Grow Up

http://www.readwriteweb.com/mobile/2012/04/mobile-backend-as-a-service-ec.php


StackMob: The Complete Technology Stack for Mobile Apps

http://www.readwriteweb.com/mobile/2011/01/StackMob-the-complete-technology-stack-for-mobile-apps.php


Open Source Mobile Backend as a Service

http://apievangelist.com/2012/08/28/open-source-mobile-backend-as-a-service/


Mobile Backend as a Service Roundup and the Future of Web APIs

http://developerthinktank.com/roundtable/mobile-backend-as-a-service-roundup-and-the-future-of-web-apis/


Appcelerator, Cocoafish 홈

http://cocoafish.com


Buddy Announces Pricing!

http://us2.campaign-archive2.com/?u=89af861528a693bdec7af3af7&id=5ae7773b1a


(끝)

Posted by ingeeC
,

HTML5 Device API 표준화 현황 (2012년 10월 19일 기준)

출처: http://www.w3.org/2009/dap/


W3C의 표준화 단계는 WD -> LC -> CR -> PR -> Rec

- WD: Working Draft

- LC: Last Call

- CR: Candidate Recomendation

- PR: Proposed Recomendation

- Rec: Recomendation


스펙별 진행상태

+ Battery Status API, 08 May 2012, CR

+ HTML Media Capture, 12 Jul 2012, LC

- Web App에서의 사진찍기, 녹음하기 방식 규정

+ Media Capture and Streams, 28 June 2012, WD

- media stream 접근 API 규정

+ Network Information API, 7 June 2011, WD

+ Ambient Light Events, 2 August 2012, WD

+ Proximity Events, 12 Jul 2012, WD

+ Vibration API, 08 May 2012, CR

+ Web Intents, 26 June 2012, WD

- Web App 사이의 상호 발견 및 RPC 방식 규정

+ Web Intents Addendum Local Services, 04 Oct 2012, WD

- Web Intent를 통해 브라우저가 Web Intent Service를 발견하고  통신하는 방법 규정

+ Pick Media Intent, 12 July 2012, WD

- Web App에서 사용자의 미디어 갤러리 접근 방식 규정

+ Pick Contacts Intent, 12 Jul 2012, WD

- Web App에서 사용자의 연락처 정보 접근 방식 규정

+ Network Service Discovery, 04 Oct 2012, WD

- 네트웍 상에 공개된 서비스를 발견하는 프로토콜 규정

+ Menu API, 진행상황 없음

+ Permissions for Device API Access, 5 Oct 2010, WD


총 14개의 HTML5 Device API 표준 중 LC이상이 3개, WD이하가 11개.

- Battery Status API, 08 May 2012, CR

- HTML Media Capture, 12 Jul 2012, LC

- Vibration API, 08 May 2012, CR

- Media Capture and Streams, 28 June 2012, WD

- Network Information API, 7 June 2011, WD

- Ambient Light Events, 2 August 2012, WD

- Proximity Events, 12 Jul 2012, WD

- Web Intents, 26 June 2012, WD

- Web Intents Addendum Local Services, 04 Oct 2012, WD

- Pick Media Intent, 12 July 2012, WD

- Pick Contacts Intent, 12 Jul 2012, WD

- Network Service Discovery, 04 Oct 2012, WD

- Menu API, 진행상황 없음

- Permissions for Device API Access, 5 Oct 2010, WD


아직 갈 길이 멀다. 브라우저에서 모든 일을 할 수 있는 세상이 빨리 오길...

(이상)


Posted by ingeeC
,

Javascript MVC Framework

Dev 2012. 8. 14. 19:23

Modern Javascript WebApp 동향

+ SPA : Single Page Application

- 하나의 HTML 파일(Single Page)에 여러 화면을 담아 제공

- 화면이 바뀔 때마다 새로운 HTML 파일을 읽어들일 필요가 없어지기 때문에 응답성이 개선됨

- WebApp의 현재 상태/화면을 hash-url(한 HTML 페이지 안의 위치를 나타내기 위해 사용하는 #으로 시작되는 http://some.domain.com/some-page.html#some-location 과 같은 형태의 URL)로 관리

- hash-url을 이용하여 WebApp의 상태/화면 관리하는 개념을 Routing이라고 하고, hash-url을 해석해서 WebApp의 상태/화면을 관리하는 모듈을 Router라고 함

+ Off-line enabled WebApp

- HTML5의 off-line 지원 기능을 활용, 네트웍에 연결되어 있지 않아도 로컬에 캐시된 WebApp 코드를 이용해서 WebApp을 실행

- Off-line enabled WebApp이 되려면 서버의 도움 없이 실행될 수 있도록 모든 프로그램 로직이 front-end에 존재해야 함

+ BaaS : Back-end as a Service

- WebApp의 front-end에 모든 로직을 담고 정형화된 back-end를 RESTful API 형태로 제공하는 개념

- Back-end가 제공하는 데이터를 가공하는 모든 로직은 front-end에 존재해야 함

=> SPA, Offline enabled Web App, BaaS 등 Modern JS WebApp은 기본적으로 규모가 큰 front-end 코드를 요구함

=> front-end code의 규모가 커짐에 따라 소스코드의 유지/보수 비용을 절감하기 위해 MVC 패턴을 이용해서 WebApp 코드를 구조적으로 만들 필요가 생김


MVC 디자인 패턴

+ 디자인 패턴이란?

- 재사용 가능한 소프트웨어 디자인(설계)

- 검증된 문제 해결 방식

- 필요에 따라 유연하게 적용 가능

+ MVC 패턴이란?

- Model, View, Controller로 소프트웨어 구조를 나눔

- Model은 데이터를 표현

- View는 화면(보통 아무런 로직도 없음)을 표현

- Controller는 M과 V 사이의 조율, 비즈니스 로직을 처리

- 전통적으로 서버-사이드에서 많이 사용됨

MVC를 지원하는 Javascript f/w 종류

+ JavaScriptMVC

- 완성도 높은 성숙한 기술

- all-in-one 솔루션

- 대규모 프로젝트에 적합

- GrooveShark(미국의 음원 제공 서비스)에 적용됨

+ Backbone.js

- 경량

- SPA 제작에 최적

- 다른 컴포넌트와 함께 사용하기 좋음

- MetaLab, SoundCloud, BitTorrent 등에 적용됨

+ Spine.js

- 경량

- Class 개념 제공

- Backbone API에 기초하여 Backbone 개발자라면 추가 학습 비용이 낮음

+ Sammy.js

- Route 기반 앱 개발에 적합한 경량 프레임워크

- Controller만 제공 (M과 V를 제공하지 않음)

- PaperlessPost에 적용됨

+ SproutCore

- 데스크탑 어플 같은 Rich함을 지향하는 앱 개발에 적합

- 대규모 엔터프라이즈 앱 개발에 적합

- 애플 MobileMe에 적용됨


Reference

- MVC and the Web

http://kanian77.wordpress.com/category/software-engineering/mvc/mvc-and-the-web/page/3/

- Tools For jQuery Application Architecture (Extended Slides)

http://addyosmani.com/toolsforjqueryapparchitecture/

- 자바스크립트 웹어플리케이션 개발경험기

http://blog.outsider.ne.kr/787

- Digesting JavaScript MVC ? Pattern Abuse Or Evolution?

http://addyosmani.com/blog/digesting-javascript-mvc-pattern-abuse-or-evolution/

- Scaling Isomorphic Javascript Code

http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

- MVC Architecture for JavaScript Applications

http://michaux.ca/articles/mvc-architecture-for-javascript-applications


(이상)

Posted by ingeeC
,