Mobile web me2day_seminar

268 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
268
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \n
  • 가트너 그룹에서 2013년에는 18억 2천만 모바일기기, 17억8천만PC로 모바일 기기가 피씨의 수를 압도할 것으로 내다보고 있다. \n단순히 기기의 숫자 이상의 의미가 있다. \n\n\n95%아이폰유저들이 주기적으로 인터넷을 검색한다. \n(아이폰/아이패드/아이팟을 가지고 테시트한다면 UK전 트래픽의 75%를 차지하는 기기를 가지고 테스트하는것이다.\n구글 통계 : 아이폰 유저가 다른 모바일 유저들보다 평균 50배 이상 검색을 더 많이 함.\n안드로이드의 마켓 점유율에도 불구하고. It’s about usage, not units)\n\nme2day와 SNS에 경우에는 더 큰 영향을 받기 때문에 \n이제 데탑웹은 기본이고, 그 이상으로 모바일 쪽에 집중을 해야할 때이다. \n\n- refers\nhttp://www.morganstanley.com/institutional/techresearch/pdfs/Internet_Trends_041210.pdf\nIt’s about usage. not units. : http://blogs.pancentric.com/2011/09/14/it’s-usage-not-units-that-defines-mobile/\n
  • \n
  • \n\n
  • 당위성 : 포용 디바이스가 많을 수록 좋음. 하지만 \n더 많은 디바이스에서 돌릴수 있도록 agent 분기가 중요한 요소라 생각됨. \n효과적인 멀티스크린 사이즈 디자인 : http://mobiforge.com/designing/story/effective-design-multiple-screen-sizes \n\n분기의 대표적인 방식 \n1. User-Agent 헤더 식별\n2. X-Wap-Profile헤더 식별:RDF(Resource Description Framework)형시의 User Agent ProfileURL을 제공. 혹은 Wap-profile 헤더로 제공 \n3. Accept헤더를 통한 분기 \n\n하지만 이런 방식으로만 구분을 하기에는 문제가 많다. X-Wap-Profile에 잘못된 URL을 포함한다거나 기기가 100Kb이상의 GIF를 받을 경우\nreject을 하는 경우도 있다. UserAgent는 대부분 정확한 정보를 주기 때문에 이를 근거로 DB를 제공받으면 될것이다. \n이런 툴로는 WURFL, DeviceAtlas, UAProf.com등이 있는데 DeviceAtlas는 상용이고 UAProf.com은 기능과 데이터가 적고 가장 많이 \n쓰이고 추천받는 것이 WURFL이다(Cont’)\n\n\n\n\n
  • 당위성 : 포용 디바이스가 많을 수록 좋음. 하지만 \n더 많은 디바이스에서 돌릴수 있도록 agent 분기가 중요한 요소라 생각됨. \n효과적인 멀티스크린 사이즈 디자인 : http://mobiforge.com/designing/story/effective-design-multiple-screen-sizes \n\n분기의 대표적인 방식 \n1. User-Agent 헤더 식별\n2. X-Wap-Profile헤더 식별:RDF(Resource Description Framework)형시의 User Agent ProfileURL을 제공. 혹은 Wap-profile 헤더로 제공 \n3. Accept헤더를 통한 분기 \n\n하지만 이런 방식으로만 구분을 하기에는 문제가 많다. X-Wap-Profile에 잘못된 URL을 포함한다거나 기기가 100Kb이상의 GIF를 받을 경우\nreject을 하는 경우도 있다. UserAgent는 대부분 정확한 정보를 주기 때문에 이를 근거로 DB를 제공받으면 될것이다. \n이런 툴로는 WURFL, DeviceAtlas, UAProf.com등이 있는데 DeviceAtlas는 상용이고 UAProf.com은 기능과 데이터가 적고 가장 많이 \n쓰이고 추천받는 것이 WURFL이다(Cont’)\n\n\n\n\n
  • 당위성 : 포용 디바이스가 많을 수록 좋음. 하지만 \n더 많은 디바이스에서 돌릴수 있도록 agent 분기가 중요한 요소라 생각됨. \n효과적인 멀티스크린 사이즈 디자인 : http://mobiforge.com/designing/story/effective-design-multiple-screen-sizes \n\n분기의 대표적인 방식 \n1. User-Agent 헤더 식별\n2. X-Wap-Profile헤더 식별:RDF(Resource Description Framework)형시의 User Agent ProfileURL을 제공. 혹은 Wap-profile 헤더로 제공 \n3. Accept헤더를 통한 분기 \n\n하지만 이런 방식으로만 구분을 하기에는 문제가 많다. X-Wap-Profile에 잘못된 URL을 포함한다거나 기기가 100Kb이상의 GIF를 받을 경우\nreject을 하는 경우도 있다. UserAgent는 대부분 정확한 정보를 주기 때문에 이를 근거로 DB를 제공받으면 될것이다. \n이런 툴로는 WURFL, DeviceAtlas, UAProf.com등이 있는데 DeviceAtlas는 상용이고 UAProf.com은 기능과 데이터가 적고 가장 많이 \n쓰이고 추천받는 것이 WURFL이다(Cont’)\n\n\n\n\n
  • http://wurfl.sourceforge.net\nDDR(Device Description Repository)로, 세계의 수천개 device에 대한 기기정보를 담고 있으며, 그 정보를 가져올 수 있는 API로 최신데이터를 가져올 수도 있다. 오픈소스이며 모바일 애플리케이션을 만드는데 있어서 기기 인식을 하기위해 Google Facebook등으로부터 쓰이고 지원받는다. 주최는 ScientiaMboilee과 커뮤니티를 중심으로 이루어지고 있다. HTTP표준의 User-Agent헤더가 사실상 다른 방식으로 어뷰즈 하는 사례가 있어서 X-Device-User-Agent라는 확장 헤더를 참고할수도 있게 된다. WURFL은 모바일 뿐만 아니라 모든 기기의 User-Agent에 대한 정보를 수집하며 총 7000개의 정보를 가진다. Java, .Net, PHP로 구현된 XML DB를 접근할 수도 있다. \n\nhttp://beradrian.wordpress.com/2008/10/10/mobile-device-recognition/\ndetect device :http://beradrian.wordpress.com/2008/10/10/mobile-device-recognition/ \n디텍팅한 디바이스에 대한 자료 : http:///cloudfour.com/mobile/summary.php\n
  • 디바이스를 인식했더라도, 모든 디바이스를 case by case로 지원하기가 힘들기 때문에 그룹핑이 필요하다. \n보통 모바일과 데탑 웹의 가장 좋은 개발 방법 론으로 “점진적 개발방법론”을 말한다. 컨텐츠 개발에 중점을 두고 그다음 CSS같은 프레젠테이션계층 개발을 하면서 \n각 그룹에 맞는 UI를 만들어 나가고, 그다음 AJAX와 같은 JS로직을 넣는 것을 이야기한다. 하지만 대부붑분의 대규모 벤더는 이미 웹이 있고 \n모바일 웹도 있다. 따라서 현재 있는 legacy를 안고서 더 개선할 방법을 찾으며 defect에 취중하는 것이 좋은 방법이다. \n지금 me2day에 있는 웹에서의 뷰는 총 3가지라 할 수 있다. 데탑브라우저를 위한 웹을 빼면, WAP/MobileWeb(스마트폰용) 두가지다. \n\n\n- Ajax 지원 여부 : 주로 스마트폰, 단, 스마트폰에서 Ajax지원을 전제할 수 없다.\n- 화면너비 : Portrait, Landscape모드가 있는지, 또는 그 모든가 변경되었을 때 event callback을 받을 수 있는지. \n- Webkit : CSS를 무리없이 지원한다 (webkit에 대해서 좀더 상세히 조사 )\n- 터치 : 웹페이지가 크게 보여졌을 때 손가락이나 스타일러스가 쉽게 선택할 수 있도록 클릭영역 설정이 필요 \n\n\n이를 근거로 \n웹페이지 : 데탑, 그에 상응하는 큰 화면의 태블릿, \n모바일웹 : 터치와 CSS, JS를 지원하는 스마트폰 \nWAP : 터치와 JS가 제약적인 피쳐폭 혹은 그외 모든 폰들.\n로 그루핑 하여 제공할 수 있겠다. \n\nWAP : http://me2day.net/m/humbroll/friends/friends/all/older?_me2day_sess=6f602b630e222d18ad9d965c97bb53b3\nMobile Web : http://me2day.net/n/jseon57/pyqldro-qj1k\nDesktop : http://me2day.net/jseon57/2012/01/15/pyqldro-qj1k \n\n
  • 디바이스를 인식했더라도, 모든 디바이스를 case by case로 지원하기가 힘들기 때문에 그룹핑이 필요하다. \n보통 모바일과 데탑 웹의 가장 좋은 개발 방법 론으로 “점진적 개발방법론”을 말한다. 컨텐츠 개발에 중점을 두고 그다음 CSS같은 프레젠테이션계층 개발을 하면서 \n각 그룹에 맞는 UI를 만들어 나가고, 그다음 AJAX와 같은 JS로직을 넣는 것을 이야기한다. 하지만 대부붑분의 대규모 벤더는 이미 웹이 있고 \n모바일 웹도 있다. 따라서 현재 있는 legacy를 안고서 더 개선할 방법을 찾으며 defect에 취중하는 것이 좋은 방법이다. \n지금 me2day에 있는 웹에서의 뷰는 총 3가지라 할 수 있다. 데탑브라우저를 위한 웹을 빼면, WAP/MobileWeb(스마트폰용) 두가지다. \n\n\n- Ajax 지원 여부 : 주로 스마트폰, 단, 스마트폰에서 Ajax지원을 전제할 수 없다.\n- 화면너비 : Portrait, Landscape모드가 있는지, 또는 그 모든가 변경되었을 때 event callback을 받을 수 있는지. \n- Webkit : CSS를 무리없이 지원한다 (webkit에 대해서 좀더 상세히 조사 )\n- 터치 : 웹페이지가 크게 보여졌을 때 손가락이나 스타일러스가 쉽게 선택할 수 있도록 클릭영역 설정이 필요 \n\n\n이를 근거로 \n웹페이지 : 데탑, 그에 상응하는 큰 화면의 태블릿, \n모바일웹 : 터치와 CSS, JS를 지원하는 스마트폰 \nWAP : 터치와 JS가 제약적인 피쳐폭 혹은 그외 모든 폰들.\n로 그루핑 하여 제공할 수 있겠다. \n\nWAP : http://me2day.net/m/humbroll/friends/friends/all/older?_me2day_sess=6f602b630e222d18ad9d965c97bb53b3\nMobile Web : http://me2day.net/n/jseon57/pyqldro-qj1k\nDesktop : http://me2day.net/jseon57/2012/01/15/pyqldro-qj1k \n\n
  • 디바이스를 인식했더라도, 모든 디바이스를 case by case로 지원하기가 힘들기 때문에 그룹핑이 필요하다. \n보통 모바일과 데탑 웹의 가장 좋은 개발 방법 론으로 “점진적 개발방법론”을 말한다. 컨텐츠 개발에 중점을 두고 그다음 CSS같은 프레젠테이션계층 개발을 하면서 \n각 그룹에 맞는 UI를 만들어 나가고, 그다음 AJAX와 같은 JS로직을 넣는 것을 이야기한다. 하지만 대부붑분의 대규모 벤더는 이미 웹이 있고 \n모바일 웹도 있다. 따라서 현재 있는 legacy를 안고서 더 개선할 방법을 찾으며 defect에 취중하는 것이 좋은 방법이다. \n지금 me2day에 있는 웹에서의 뷰는 총 3가지라 할 수 있다. 데탑브라우저를 위한 웹을 빼면, WAP/MobileWeb(스마트폰용) 두가지다. \n\n\n- Ajax 지원 여부 : 주로 스마트폰, 단, 스마트폰에서 Ajax지원을 전제할 수 없다.\n- 화면너비 : Portrait, Landscape모드가 있는지, 또는 그 모든가 변경되었을 때 event callback을 받을 수 있는지. \n- Webkit : CSS를 무리없이 지원한다 (webkit에 대해서 좀더 상세히 조사 )\n- 터치 : 웹페이지가 크게 보여졌을 때 손가락이나 스타일러스가 쉽게 선택할 수 있도록 클릭영역 설정이 필요 \n\n\n이를 근거로 \n웹페이지 : 데탑, 그에 상응하는 큰 화면의 태블릿, \n모바일웹 : 터치와 CSS, JS를 지원하는 스마트폰 \nWAP : 터치와 JS가 제약적인 피쳐폭 혹은 그외 모든 폰들.\n로 그루핑 하여 제공할 수 있겠다. \n\nWAP : http://me2day.net/m/humbroll/friends/friends/all/older?_me2day_sess=6f602b630e222d18ad9d965c97bb53b3\nMobile Web : http://me2day.net/n/jseon57/pyqldro-qj1k\nDesktop : http://me2day.net/jseon57/2012/01/15/pyqldro-qj1k \n\n
  • 디바이스를 인식했더라도, 모든 디바이스를 case by case로 지원하기가 힘들기 때문에 그룹핑이 필요하다. \n보통 모바일과 데탑 웹의 가장 좋은 개발 방법 론으로 “점진적 개발방법론”을 말한다. 컨텐츠 개발에 중점을 두고 그다음 CSS같은 프레젠테이션계층 개발을 하면서 \n각 그룹에 맞는 UI를 만들어 나가고, 그다음 AJAX와 같은 JS로직을 넣는 것을 이야기한다. 하지만 대부붑분의 대규모 벤더는 이미 웹이 있고 \n모바일 웹도 있다. 따라서 현재 있는 legacy를 안고서 더 개선할 방법을 찾으며 defect에 취중하는 것이 좋은 방법이다. \n지금 me2day에 있는 웹에서의 뷰는 총 3가지라 할 수 있다. 데탑브라우저를 위한 웹을 빼면, WAP/MobileWeb(스마트폰용) 두가지다. \n\n\n- Ajax 지원 여부 : 주로 스마트폰, 단, 스마트폰에서 Ajax지원을 전제할 수 없다.\n- 화면너비 : Portrait, Landscape모드가 있는지, 또는 그 모든가 변경되었을 때 event callback을 받을 수 있는지. \n- Webkit : CSS를 무리없이 지원한다 (webkit에 대해서 좀더 상세히 조사 )\n- 터치 : 웹페이지가 크게 보여졌을 때 손가락이나 스타일러스가 쉽게 선택할 수 있도록 클릭영역 설정이 필요 \n\n\n이를 근거로 \n웹페이지 : 데탑, 그에 상응하는 큰 화면의 태블릿, \n모바일웹 : 터치와 CSS, JS를 지원하는 스마트폰 \nWAP : 터치와 JS가 제약적인 피쳐폭 혹은 그외 모든 폰들.\n로 그루핑 하여 제공할 수 있겠다. \n\nWAP : http://me2day.net/m/humbroll/friends/friends/all/older?_me2day_sess=6f602b630e222d18ad9d965c97bb53b3\nMobile Web : http://me2day.net/n/jseon57/pyqldro-qj1k\nDesktop : http://me2day.net/jseon57/2012/01/15/pyqldro-qj1k \n\n
  • Even Google was not rich enough to support all of the different mobile platforms from Apple’s AppStore to those of the BlackBerry, Windows Mobile, Android and the many variations of the Nokia platform\n- 기술 부사장 빅 건도트라 - \n구글의 VP도 모든 기기에 구글앱을 지원하는 것은 무리다라고 말함. 하이브리드의 당위성.(HTML5에 집중하고자 한다는 정치적 발언.)\n\nHTML5이 네이티브를 cover해 나갈것이라는 의미 내포. \n\n
  • 하이브리드앱 방법론. \n기존의 웹페이지를 기반으로, 혹은 네이티브 앱에 들어가기 좋은 개선된 디자인 버전으로 모바일 웹을 개선하고 \n그 다음 그 모바일 페이지를 재활용하는 것이 좋다. \n하이브리드란? : 하이브리드웹컨테이너는 웹개발의 단순함과 네이티브 디바이스의 파워를 가진다. 하이브리드 웹 컨테이너는 모바일 개발을 빠르게 진행되도록 도와주며 비즈니스적으로 비용을 줄일수 있다. \n\n모바일팀에서는 앱 중심으로 하이브리드앱에 대해서 설명을 할것으로 예상. 본 발표에서는 하이브리드앱을 만들기 위한 backend architecture에 대해서 이야기 한다. \n\nhybrid vs web vs native 에 대한 좋은 바룦자료:http://www.slideshare.net/fling/native-v-hybrid-v-web\n꼭 읽어볼것 : http://techcrunch.com/2010/04/30/joe-hewitt-web-development/ \n오! 레일스와 네이티브 어플리케이션의 통합 ; http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201008.html\n동기화 기술에 대해서 참고기 좋은 Google gears 문서 : http://code.google.com/apis/gears/architecture.html\n동기화 아키텍쳐 : http://www.squad16.com/download/2010/ACT!2010SynchronizationWhitepaper.pdf \n\n\n\n하이브리드이든 네이티브든 모바일앱이든 결국 네트워크상의 데이터를 핸들링해야 하는 것은 매한가지이기 때문에 \n모바일 웹에서의 개발 관련(성능, 개발방식,테스팅 방식) 등에 대해서 알아볼 것이다. \n\n\n\nhttp://xguru.net/593\n모바일에서 특히 중요한 HTML5요소들\n- 오프라인 지원 : Web database, LocalStorage, AppCache \n- 위치정보 : GeoLocatoin \n\nbetst phonegap app : https://docs.google.com/document/d/1SC-H5oZii9sHC-P6G2PaUmqx66TC1v14ixzXiv8XqCo/edit?hl=en&authkey=CPTVrPEM&pli=1 \n\n\n
  • 하이브리드앱 방법론. \n기존의 웹페이지를 기반으로, 혹은 네이티브 앱에 들어가기 좋은 개선된 디자인 버전으로 모바일 웹을 개선하고 \n그 다음 그 모바일 페이지를 재활용하는 것이 좋다. \n하이브리드란? : 하이브리드웹컨테이너는 웹개발의 단순함과 네이티브 디바이스의 파워를 가진다. 하이브리드 웹 컨테이너는 모바일 개발을 빠르게 진행되도록 도와주며 비즈니스적으로 비용을 줄일수 있다. \n\n모바일팀에서는 앱 중심으로 하이브리드앱에 대해서 설명을 할것으로 예상. 본 발표에서는 하이브리드앱을 만들기 위한 backend architecture에 대해서 이야기 한다. \n\nhybrid vs web vs native 에 대한 좋은 바룦자료:http://www.slideshare.net/fling/native-v-hybrid-v-web\n꼭 읽어볼것 : http://techcrunch.com/2010/04/30/joe-hewitt-web-development/ \n오! 레일스와 네이티브 어플리케이션의 통합 ; http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201008.html\n동기화 기술에 대해서 참고기 좋은 Google gears 문서 : http://code.google.com/apis/gears/architecture.html\n동기화 아키텍쳐 : http://www.squad16.com/download/2010/ACT!2010SynchronizationWhitepaper.pdf \n\n\n\n하이브리드이든 네이티브든 모바일앱이든 결국 네트워크상의 데이터를 핸들링해야 하는 것은 매한가지이기 때문에 \n모바일 웹에서의 개발 관련(성능, 개발방식,테스팅 방식) 등에 대해서 알아볼 것이다. \n\n\n\nhttp://xguru.net/593\n모바일에서 특히 중요한 HTML5요소들\n- 오프라인 지원 : Web database, LocalStorage, AppCache \n- 위치정보 : GeoLocatoin \n\nbetst phonegap app : https://docs.google.com/document/d/1SC-H5oZii9sHC-P6G2PaUmqx66TC1v14ixzXiv8XqCo/edit?hl=en&authkey=CPTVrPEM&pli=1 \n\n\n
  • 하이브리드앱 방법론. \n기존의 웹페이지를 기반으로, 혹은 네이티브 앱에 들어가기 좋은 개선된 디자인 버전으로 모바일 웹을 개선하고 \n그 다음 그 모바일 페이지를 재활용하는 것이 좋다. \n하이브리드란? : 하이브리드웹컨테이너는 웹개발의 단순함과 네이티브 디바이스의 파워를 가진다. 하이브리드 웹 컨테이너는 모바일 개발을 빠르게 진행되도록 도와주며 비즈니스적으로 비용을 줄일수 있다. \n\n모바일팀에서는 앱 중심으로 하이브리드앱에 대해서 설명을 할것으로 예상. 본 발표에서는 하이브리드앱을 만들기 위한 backend architecture에 대해서 이야기 한다. \n\nhybrid vs web vs native 에 대한 좋은 바룦자료:http://www.slideshare.net/fling/native-v-hybrid-v-web\n꼭 읽어볼것 : http://techcrunch.com/2010/04/30/joe-hewitt-web-development/ \n오! 레일스와 네이티브 어플리케이션의 통합 ; http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201008.html\n동기화 기술에 대해서 참고기 좋은 Google gears 문서 : http://code.google.com/apis/gears/architecture.html\n동기화 아키텍쳐 : http://www.squad16.com/download/2010/ACT!2010SynchronizationWhitepaper.pdf \n\n\n\n하이브리드이든 네이티브든 모바일앱이든 결국 네트워크상의 데이터를 핸들링해야 하는 것은 매한가지이기 때문에 \n모바일 웹에서의 개발 관련(성능, 개발방식,테스팅 방식) 등에 대해서 알아볼 것이다. \n\n\n\nhttp://xguru.net/593\n모바일에서 특히 중요한 HTML5요소들\n- 오프라인 지원 : Web database, LocalStorage, AppCache \n- 위치정보 : GeoLocatoin \n\nbetst phonegap app : https://docs.google.com/document/d/1SC-H5oZii9sHC-P6G2PaUmqx66TC1v14ixzXiv8XqCo/edit?hl=en&authkey=CPTVrPEM&pli=1 \n\n\n
  • 하이브리드앱 방법론. \n기존의 웹페이지를 기반으로, 혹은 네이티브 앱에 들어가기 좋은 개선된 디자인 버전으로 모바일 웹을 개선하고 \n그 다음 그 모바일 페이지를 재활용하는 것이 좋다. \n하이브리드란? : 하이브리드웹컨테이너는 웹개발의 단순함과 네이티브 디바이스의 파워를 가진다. 하이브리드 웹 컨테이너는 모바일 개발을 빠르게 진행되도록 도와주며 비즈니스적으로 비용을 줄일수 있다. \n\n모바일팀에서는 앱 중심으로 하이브리드앱에 대해서 설명을 할것으로 예상. 본 발표에서는 하이브리드앱을 만들기 위한 backend architecture에 대해서 이야기 한다. \n\nhybrid vs web vs native 에 대한 좋은 바룦자료:http://www.slideshare.net/fling/native-v-hybrid-v-web\n꼭 읽어볼것 : http://techcrunch.com/2010/04/30/joe-hewitt-web-development/ \n오! 레일스와 네이티브 어플리케이션의 통합 ; http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201008.html\n동기화 기술에 대해서 참고기 좋은 Google gears 문서 : http://code.google.com/apis/gears/architecture.html\n동기화 아키텍쳐 : http://www.squad16.com/download/2010/ACT!2010SynchronizationWhitepaper.pdf \n\n\n\n하이브리드이든 네이티브든 모바일앱이든 결국 네트워크상의 데이터를 핸들링해야 하는 것은 매한가지이기 때문에 \n모바일 웹에서의 개발 관련(성능, 개발방식,테스팅 방식) 등에 대해서 알아볼 것이다. \n\n\n\nhttp://xguru.net/593\n모바일에서 특히 중요한 HTML5요소들\n- 오프라인 지원 : Web database, LocalStorage, AppCache \n- 위치정보 : GeoLocatoin \n\nbetst phonegap app : https://docs.google.com/document/d/1SC-H5oZii9sHC-P6G2PaUmqx66TC1v14ixzXiv8XqCo/edit?hl=en&authkey=CPTVrPEM&pli=1 \n\n\n
  • 하이브리드앱 방법론. \n기존의 웹페이지를 기반으로, 혹은 네이티브 앱에 들어가기 좋은 개선된 디자인 버전으로 모바일 웹을 개선하고 \n그 다음 그 모바일 페이지를 재활용하는 것이 좋다. \n하이브리드란? : 하이브리드웹컨테이너는 웹개발의 단순함과 네이티브 디바이스의 파워를 가진다. 하이브리드 웹 컨테이너는 모바일 개발을 빠르게 진행되도록 도와주며 비즈니스적으로 비용을 줄일수 있다. \n\n모바일팀에서는 앱 중심으로 하이브리드앱에 대해서 설명을 할것으로 예상. 본 발표에서는 하이브리드앱을 만들기 위한 backend architecture에 대해서 이야기 한다. \n\nhybrid vs web vs native 에 대한 좋은 바룦자료:http://www.slideshare.net/fling/native-v-hybrid-v-web\n꼭 읽어볼것 : http://techcrunch.com/2010/04/30/joe-hewitt-web-development/ \n오! 레일스와 네이티브 어플리케이션의 통합 ; http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201008.html\n동기화 기술에 대해서 참고기 좋은 Google gears 문서 : http://code.google.com/apis/gears/architecture.html\n동기화 아키텍쳐 : http://www.squad16.com/download/2010/ACT!2010SynchronizationWhitepaper.pdf \n\n\n\n하이브리드이든 네이티브든 모바일앱이든 결국 네트워크상의 데이터를 핸들링해야 하는 것은 매한가지이기 때문에 \n모바일 웹에서의 개발 관련(성능, 개발방식,테스팅 방식) 등에 대해서 알아볼 것이다. \n\n\n\nhttp://xguru.net/593\n모바일에서 특히 중요한 HTML5요소들\n- 오프라인 지원 : Web database, LocalStorage, AppCache \n- 위치정보 : GeoLocatoin \n\nbetst phonegap app : https://docs.google.com/document/d/1SC-H5oZii9sHC-P6G2PaUmqx66TC1v14ixzXiv8XqCo/edit?hl=en&authkey=CPTVrPEM&pli=1 \n\n\n
  • 하이브리드앱 방법론. \n기존의 웹페이지를 기반으로, 혹은 네이티브 앱에 들어가기 좋은 개선된 디자인 버전으로 모바일 웹을 개선하고 \n그 다음 그 모바일 페이지를 재활용하는 것이 좋다. \n하이브리드란? : 하이브리드웹컨테이너는 웹개발의 단순함과 네이티브 디바이스의 파워를 가진다. 하이브리드 웹 컨테이너는 모바일 개발을 빠르게 진행되도록 도와주며 비즈니스적으로 비용을 줄일수 있다. \n\n모바일팀에서는 앱 중심으로 하이브리드앱에 대해서 설명을 할것으로 예상. 본 발표에서는 하이브리드앱을 만들기 위한 backend architecture에 대해서 이야기 한다. \n\nhybrid vs web vs native 에 대한 좋은 바룦자료:http://www.slideshare.net/fling/native-v-hybrid-v-web\n꼭 읽어볼것 : http://techcrunch.com/2010/04/30/joe-hewitt-web-development/ \n오! 레일스와 네이티브 어플리케이션의 통합 ; http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201008.html\n동기화 기술에 대해서 참고기 좋은 Google gears 문서 : http://code.google.com/apis/gears/architecture.html\n동기화 아키텍쳐 : http://www.squad16.com/download/2010/ACT!2010SynchronizationWhitepaper.pdf \n\n\n\n하이브리드이든 네이티브든 모바일앱이든 결국 네트워크상의 데이터를 핸들링해야 하는 것은 매한가지이기 때문에 \n모바일 웹에서의 개발 관련(성능, 개발방식,테스팅 방식) 등에 대해서 알아볼 것이다. \n\n\n\nhttp://xguru.net/593\n모바일에서 특히 중요한 HTML5요소들\n- 오프라인 지원 : Web database, LocalStorage, AppCache \n- 위치정보 : GeoLocatoin \n\nbetst phonegap app : https://docs.google.com/document/d/1SC-H5oZii9sHC-P6G2PaUmqx66TC1v14ixzXiv8XqCo/edit?hl=en&authkey=CPTVrPEM&pli=1 \n\n\n
  • 하이브리드앱 방법론. \n기존의 웹페이지를 기반으로, 혹은 네이티브 앱에 들어가기 좋은 개선된 디자인 버전으로 모바일 웹을 개선하고 \n그 다음 그 모바일 페이지를 재활용하는 것이 좋다. \n하이브리드란? : 하이브리드웹컨테이너는 웹개발의 단순함과 네이티브 디바이스의 파워를 가진다. 하이브리드 웹 컨테이너는 모바일 개발을 빠르게 진행되도록 도와주며 비즈니스적으로 비용을 줄일수 있다. \n\n모바일팀에서는 앱 중심으로 하이브리드앱에 대해서 설명을 할것으로 예상. 본 발표에서는 하이브리드앱을 만들기 위한 backend architecture에 대해서 이야기 한다. \n\nhybrid vs web vs native 에 대한 좋은 바룦자료:http://www.slideshare.net/fling/native-v-hybrid-v-web\n꼭 읽어볼것 : http://techcrunch.com/2010/04/30/joe-hewitt-web-development/ \n오! 레일스와 네이티브 어플리케이션의 통합 ; http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201008.html\n동기화 기술에 대해서 참고기 좋은 Google gears 문서 : http://code.google.com/apis/gears/architecture.html\n동기화 아키텍쳐 : http://www.squad16.com/download/2010/ACT!2010SynchronizationWhitepaper.pdf \n\n\n\n하이브리드이든 네이티브든 모바일앱이든 결국 네트워크상의 데이터를 핸들링해야 하는 것은 매한가지이기 때문에 \n모바일 웹에서의 개발 관련(성능, 개발방식,테스팅 방식) 등에 대해서 알아볼 것이다. \n\n\n\nhttp://xguru.net/593\n모바일에서 특히 중요한 HTML5요소들\n- 오프라인 지원 : Web database, LocalStorage, AppCache \n- 위치정보 : GeoLocatoin \n\nbetst phonegap app : https://docs.google.com/document/d/1SC-H5oZii9sHC-P6G2PaUmqx66TC1v14ixzXiv8XqCo/edit?hl=en&authkey=CPTVrPEM&pli=1 \n\n\n
  • 하이브리드앱 방법론. \n기존의 웹페이지를 기반으로, 혹은 네이티브 앱에 들어가기 좋은 개선된 디자인 버전으로 모바일 웹을 개선하고 \n그 다음 그 모바일 페이지를 재활용하는 것이 좋다. \n하이브리드란? : 하이브리드웹컨테이너는 웹개발의 단순함과 네이티브 디바이스의 파워를 가진다. 하이브리드 웹 컨테이너는 모바일 개발을 빠르게 진행되도록 도와주며 비즈니스적으로 비용을 줄일수 있다. \n\n모바일팀에서는 앱 중심으로 하이브리드앱에 대해서 설명을 할것으로 예상. 본 발표에서는 하이브리드앱을 만들기 위한 backend architecture에 대해서 이야기 한다. \n\nhybrid vs web vs native 에 대한 좋은 바룦자료:http://www.slideshare.net/fling/native-v-hybrid-v-web\n꼭 읽어볼것 : http://techcrunch.com/2010/04/30/joe-hewitt-web-development/ \n오! 레일스와 네이티브 어플리케이션의 통합 ; http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201008.html\n동기화 기술에 대해서 참고기 좋은 Google gears 문서 : http://code.google.com/apis/gears/architecture.html\n동기화 아키텍쳐 : http://www.squad16.com/download/2010/ACT!2010SynchronizationWhitepaper.pdf \n\n\n\n하이브리드이든 네이티브든 모바일앱이든 결국 네트워크상의 데이터를 핸들링해야 하는 것은 매한가지이기 때문에 \n모바일 웹에서의 개발 관련(성능, 개발방식,테스팅 방식) 등에 대해서 알아볼 것이다. \n\n\n\nhttp://xguru.net/593\n모바일에서 특히 중요한 HTML5요소들\n- 오프라인 지원 : Web database, LocalStorage, AppCache \n- 위치정보 : GeoLocatoin \n\nbetst phonegap app : https://docs.google.com/document/d/1SC-H5oZii9sHC-P6G2PaUmqx66TC1v14ixzXiv8XqCo/edit?hl=en&authkey=CPTVrPEM&pli=1 \n\n\n
  • 하이브리드앱 방법론. \n기존의 웹페이지를 기반으로, 혹은 네이티브 앱에 들어가기 좋은 개선된 디자인 버전으로 모바일 웹을 개선하고 \n그 다음 그 모바일 페이지를 재활용하는 것이 좋다. \n하이브리드란? : 하이브리드웹컨테이너는 웹개발의 단순함과 네이티브 디바이스의 파워를 가진다. 하이브리드 웹 컨테이너는 모바일 개발을 빠르게 진행되도록 도와주며 비즈니스적으로 비용을 줄일수 있다. \n\n모바일팀에서는 앱 중심으로 하이브리드앱에 대해서 설명을 할것으로 예상. 본 발표에서는 하이브리드앱을 만들기 위한 backend architecture에 대해서 이야기 한다. \n\nhybrid vs web vs native 에 대한 좋은 바룦자료:http://www.slideshare.net/fling/native-v-hybrid-v-web\n꼭 읽어볼것 : http://techcrunch.com/2010/04/30/joe-hewitt-web-development/ \n오! 레일스와 네이티브 어플리케이션의 통합 ; http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201008.html\n동기화 기술에 대해서 참고기 좋은 Google gears 문서 : http://code.google.com/apis/gears/architecture.html\n동기화 아키텍쳐 : http://www.squad16.com/download/2010/ACT!2010SynchronizationWhitepaper.pdf \n\n\n\n하이브리드이든 네이티브든 모바일앱이든 결국 네트워크상의 데이터를 핸들링해야 하는 것은 매한가지이기 때문에 \n모바일 웹에서의 개발 관련(성능, 개발방식,테스팅 방식) 등에 대해서 알아볼 것이다. \n\n\n\nhttp://xguru.net/593\n모바일에서 특히 중요한 HTML5요소들\n- 오프라인 지원 : Web database, LocalStorage, AppCache \n- 위치정보 : GeoLocatoin \n\nbetst phonegap app : https://docs.google.com/document/d/1SC-H5oZii9sHC-P6G2PaUmqx66TC1v14ixzXiv8XqCo/edit?hl=en&authkey=CPTVrPEM&pli=1 \n\n\n
  • 로딩 시간이 끼치는 영향에 대해서\n\n\nhttp://blog.kissmetrics.com/loading-time/ \nhttp://www.digitalbuzzblog.com/2011-mobile-statistics-stats-facts-marketing-infographic/\n\nwill increase their frustration\n
  • 여기서 성능이란 “로딩성능”뿐만 아니라 “UI성능”까지 포함한다.\n
  • 하이브리드이든 네이티브든 모바일앱이든 결국 네트워크상의 데이터를 핸들링해야 하는 것은 매한가지이기 때문에 \n모바일 웹에서의 개발 관련(성능, 개발방식,테스팅 방식) 등에 대해서 알아볼 것이다. \n\n\n아이폰에서의 웹킷의 제약사항들은 다음과 같은 것들이 있다. \niphone \n사파리모바일은 모바일 표준을 무시하고(WML지원X) 데탑과 같은 웹표준 지원을 고집한다. 실제 사파리데스톱과 같은 웹킷브라우저 엔진을 사용하기 때문이다. \n애플 개발자 페이지에(http://developer.apple.com/library/ios/#documentation/AppleApplications/Reference/SafariWebContent/) 모바일 사파리에 대한 자세한 사항이 있따. \n\n\n\n
  • 6. 네트워크 비용 최소화 \n----\n 6-4. browser concurrency : 브라우저에서 동시에 연결할 수 있는 HTTP connection에 대한 고려. HTTP연결을 최대한 줄이고(외부리소스통합) 가능한 많은 동시HTTP접속 활용하기. \nHTTP1.1표준(1999년)은 호스트당 2개 이내를 권장하지만 최근 브라우저는 보통 4개 이상에 계속 늘어나는 추세이므로 동시접속기능을 최대한 활용하는 것이 좋음. \n 동시접속을 무작정 못 늘리는 이유 : TCP slow start(3way Hand shake)에 취약, 리소스 갯수가 적을 경우 역효과, Keep alive로 인한 서버자원소진(NHN에서 웹서버에는 Keepalive금지) \n단일 도메인에서 이미지 20개 이상 로딩하는 경우 도메인 당 2개까지 무난하고 좋은 효과 있음\n\nbut \n\n 6-0 mobile은 기본적으로 낮은 Bandwidth를 가진다(3G망은 신호가 좋아야 1Mbyte/s(데탑은 그 이상에서 20Mbyte/s이다.) )\n\n\n\n
  • 6. 네트워크 비용 최소화 \n----\n 6-4. browser concurrency : 브라우저에서 동시에 연결할 수 있는 HTTP connection에 대한 고려. HTTP연결을 최대한 줄이고(외부리소스통합) 가능한 많은 동시HTTP접속 활용하기. \nHTTP1.1표준(1999년)은 호스트당 2개 이내를 권장하지만 최근 브라우저는 보통 4개 이상에 계속 늘어나는 추세이므로 동시접속기능을 최대한 활용하는 것이 좋음. \n 동시접속을 무작정 못 늘리는 이유 : TCP slow start(3way Hand shake)에 취약, 리소스 갯수가 적을 경우 역효과, Keep alive로 인한 서버자원소진(NHN에서 웹서버에는 Keepalive금지) \n단일 도메인에서 이미지 20개 이상 로딩하는 경우 도메인 당 2개까지 무난하고 좋은 효과 있음\n\nbut \n\n 6-0 mobile은 기본적으로 낮은 Bandwidth를 가진다(3G망은 신호가 좋아야 1Mbyte/s(데탑은 그 이상에서 20Mbyte/s이다.) )\n\n\n\n
  • 6. 네트워크 비용 최소화 \n----\n 6-4. browser concurrency : 브라우저에서 동시에 연결할 수 있는 HTTP connection에 대한 고려. HTTP연결을 최대한 줄이고(외부리소스통합) 가능한 많은 동시HTTP접속 활용하기. \nHTTP1.1표준(1999년)은 호스트당 2개 이내를 권장하지만 최근 브라우저는 보통 4개 이상에 계속 늘어나는 추세이므로 동시접속기능을 최대한 활용하는 것이 좋음. \n 동시접속을 무작정 못 늘리는 이유 : TCP slow start(3way Hand shake)에 취약, 리소스 갯수가 적을 경우 역효과, Keep alive로 인한 서버자원소진(NHN에서 웹서버에는 Keepalive금지) \n단일 도메인에서 이미지 20개 이상 로딩하는 경우 도메인 당 2개까지 무난하고 좋은 효과 있음\n\nbut \n\n 6-0 mobile은 기본적으로 낮은 Bandwidth를 가진다(3G망은 신호가 좋아야 1Mbyte/s(데탑은 그 이상에서 20Mbyte/s이다.) )\n\n\n\n
  • 데이터최적화 \n 6-1. 이미지 최적화 : PNG를 사용(압축대비 품질BEST)\n a 이미지 크기에 대한 지원 : static방법(저장 당시 변환 => 현재 미투데이. 좀처럼 변하지 않는 데이터들에 적합), \n b on-the-fly방법(e.g. GAIA transcoder - http://gaia-git.sourceforge.net 툴을 활용하여 요청 타임에 onthefly로 이미지를 생성/캐시/제공, 뉴스와 같은 동적으로 이곳 저곳에서 많이 보여질 이미지에 적합?)\nData connection과 Data transfer비용을 줄이기 위해서 “정말 거의” 변하지 않는 이미지의 경우는 img태그에 base64바이너리 데이터를 넣을 수도 있음(http://webcodertools.com/imagetobase64converter)\n c CSS에서는 image-spri Webkit te활용. \n\n 6-3. JS, CSS minify&compressing, 불필요부분 제거, me2day에서는 YUI를 사용하고 있음. 공백,line break등을 제거. inline CSS는 최대한 외부리소스로 빼고.\n----- \n\n
  • 6-5. 요청수의 최소화 \n-TCP MSS(Maximum Segment Size) : 일반적으로 TCP payload는 패킷당 1460byte, 3G망에서는 VPN header때문에 1360byte정도까지 줄어듬. 같은 용량에도 더 많은 왕복. 패킷 1개가 추가될때마다 0.1~0.2초 손실. \n- 3G망에서 GET요청시 DNSlookup+TCP handshake + HTTP response만 합쳐서 1건당 0.6초가 걸림. 따라서 불필요한 요청 최소화\n\n- 쿠키(네이버 로그인시 2Kbyte이상쿠키)최대한 제거, 정적파일은 cookie없는 도메인 이용(CDN은 static.naver.net사용)\n- 캐시도 조심 : GET-if-not-modified => 304not modified 될 때마다 0.6초가 소요되는 것임. 실제는평균적으로 0.7초소요. Redirect도마찬가지.\n\n\n\n
  • 6-5. 요청수의 최소화 \n-TCP MSS(Maximum Segment Size) : 일반적으로 TCP payload는 패킷당 1460byte, 3G망에서는 VPN header때문에 1360byte정도까지 줄어듬. 같은 용량에도 더 많은 왕복. 패킷 1개가 추가될때마다 0.1~0.2초 손실. \n- 3G망에서 GET요청시 DNSlookup+TCP handshake + HTTP response만 합쳐서 1건당 0.6초가 걸림. 따라서 불필요한 요청 최소화\n\n- 쿠키(네이버 로그인시 2Kbyte이상쿠키)최대한 제거, 정적파일은 cookie없는 도메인 이용(CDN은 static.naver.net사용)\n- 캐시도 조심 : GET-if-not-modified => 304not modified 될 때마다 0.6초가 소요되는 것임. 실제는평균적으로 0.7초소요. Redirect도마찬가지.\n\n\n\n
  • 6-5. 요청수의 최소화 \n-TCP MSS(Maximum Segment Size) : 일반적으로 TCP payload는 패킷당 1460byte, 3G망에서는 VPN header때문에 1360byte정도까지 줄어듬. 같은 용량에도 더 많은 왕복. 패킷 1개가 추가될때마다 0.1~0.2초 손실. \n- 3G망에서 GET요청시 DNSlookup+TCP handshake + HTTP response만 합쳐서 1건당 0.6초가 걸림. 따라서 불필요한 요청 최소화\n\n- 쿠키(네이버 로그인시 2Kbyte이상쿠키)최대한 제거, 정적파일은 cookie없는 도메인 이용(CDN은 static.naver.net사용)\n- 캐시도 조심 : GET-if-not-modified => 304not modified 될 때마다 0.6초가 소요되는 것임. 실제는평균적으로 0.7초소요. Redirect도마찬가지.\n\n\n\n
  • piggyback : 미투데이 개별글 페이지. 단순히 개발스팩 구현에 그치는 것이 아니라 \n사용자의 UX를 고려하고 개발해야 한다. 이런 백단의 고려까지 UX에서 해주진 않으니까.\n
  • piggyback : 미투데이 개별글 페이지. 한번 왼쪽으로 스와이프를 한 사용자는 한번 더 왼쪽으로 스와이프한 확률이 높으므로 \n미리 로딩을 해 놓는다. => 단순히 개발스팩 구현에 그치는 것이 아니라 \n사용자의 UX를 고려하고 개발해야 한다. 이런 백단의 고려까지 UX에서 해주진 않으니까.\n
  • piggyback : 미투데이 개별글 페이지. 한번 왼쪽으로 스와이프를 한 사용자는 한번 더 왼쪽으로 스와이프한 확률이 높으므로 \n미리 로딩을 해 놓는다. => 단순히 개발스팩 구현에 그치는 것이 아니라 \n사용자의 UX를 고려하고 개발해야 한다. 이런 백단의 고려까지 UX에서 해주진 않으니까.\n
  • piggyback : 미투데이 개별글 페이지. 한번 왼쪽으로 스와이프를 한 사용자는 한번 더 왼쪽으로 스와이프한 확률이 높으므로 \n미리 로딩을 해 놓는다. => 단순히 개발스팩 구현에 그치는 것이 아니라 \n사용자의 UX를 고려하고 개발해야 한다. 이런 백단의 고려까지 UX에서 해주진 않으니까.\n
  • piggyback : 미투데이 개별글 페이지. 한번 왼쪽으로 스와이프를 한 사용자는 한번 더 왼쪽으로 스와이프한 확률이 높으므로 \n미리 로딩을 해 놓는다. => 단순히 개발스팩 구현에 그치는 것이 아니라 \n사용자의 UX를 고려하고 개발해야 한다. 이런 백단의 고려까지 UX에서 해주진 않으니까.\n
  • piggyback : 미투데이 개별글 페이지. 한번 왼쪽으로 스와이프를 한 사용자는 한번 더 왼쪽으로 스와이프한 확률이 높으므로 \n미리 로딩을 해 놓는다. => 단순히 개발스팩 구현에 그치는 것이 아니라 \n사용자의 UX를 고려하고 개발해야 한다. 이런 백단의 고려까지 UX에서 해주진 않으니까.\n
  • HTTP pipelining(http://www.blaze.io/mobile/http-pipelining-big-in-mobile/)\n속도 최적화에 큰 성과를 볼 수 있는 HTTP1.1표준에도 있는 내용이지만 이를 도입한 브라우저들이 별로 없다.(데탑에서는 오파라mini만이 HTTP Pipelining을 제원하고 Firefox는 지원하지만 Default가 Disabled이다.)\n하지만 최근 모바일쪽에서 많이 적용하는 추세이다. 안드로이드는 이를 도입했다\n\nHTTP pipelining이 모바일에서 매력적인 이유는,\n 1. 모바일 네트워크는 데탑의 그것보다 더 큰 network latency를 가진다. => 따라서 RTT를 줄이는 것은 모바일에서 더 큰 의미가 있다. \n 2. 모바일 브라우저와 모바일 웹사이트들은 만들어진지 얼마 되지 않았다 => 좀더 좋은 기술을 도입하려는 방향을 가진다. \n\n따라서 모바일에서 오히려 HTTP pipelining을 활용하는 사례가 더 많다\nopera mini, opera mobile, android browser 모두 HTTP pipelining을 디폴트로 쓴다. 이 세가지를 합치면 전체 모바일 브라우징의 40%가 넘는다. \n\n\n\n
  • 서버에서 pipelining을 지원하기 위해서는 브라우저로부터의 응답에 두가지를 반드시 응답해주어야 한다. \n1. HTTP/1.1 프로토콜 사용. \n2. Connection: Keep-Alive 명시(특히 안드로이드에서는 필수) \n이 조건을 만족하지 않으면 브라우저는 단순히 HTTP pipelinig을 사용하지 않는다. \n이 조건을 만족하면 첫 커넥션 혹은 첫 도멘인에 데한 커넥션이 맺어지면 그 바로 다음 요청은 pipeline을 통해서 \n빠른 속도로 통신하게 된다. \n\nNHN 사내 표준안에서는 웹서버(아파치, Nginx)의 경우 KeepAlive를 비활성화 하도록 한다고 들었는데, \n이런 성능 향상을 위해서 실험적으로 충분히 해볼만 할것 같다. \n 지원하기 위해선 다음과 같은 체크사항들이 있다. \n- pipelining을 지원하는 웹서버를 쓰고 있는지(대부분의 웹서버(Nginx, Apache)에서 지원한다.)\n- Connection:Keep-Alive 헤더를 포함해서 반환해야. \n- 도메인 샤딩은 조심히 : 모바일에서 커넥션의 비용은 매우 크다. 여러 도메인에 대해서 커넥션을 맺는 것보다 한개의 커넥션에서 파이프라이닝을 하는 것이 훨씬 효과적일 수 있다. \n\n \n\npipeline을 적용한 좋은 사례 : http://www.brianp.net/2011/07/19/will-http-pipelining-help-a-study-based-on-the-httparchive-org-data-set/\n브라우저벤더들이 pipeline을 도입하지 않는(혹은 default로 하지 않는 이유) 이유 이슈 :http://www.subbu.org/blog/2011/02/can-pipelining-help \n
  • 7. 인풋에 대한 고려 : \n대부분의 스마트폰이 데탑과는 다른 좁은 화면에서 Touch기반의 입력을 받는다. 이를 기반으로 고려해야할 사항들은 다음과 같은 것들. \n- 버튼 :12px정도의 텍스트 크기는 터치를 통해서 정확히 선택하기가 힘들다. Apple에서는 터치장비에서의 버튼 크기를 44x44px를 권장한다. \n- Gesture활용 : 터치기반의 모바일 인터페이스에서는 gesture가 또 하나의 입력 방식이다(미투데이 개별페이지에서는 이미 활용)\n- mouse이벤트 사용 금지 : 데탑과 같이 마우스 입력을 받지 않기 때문에 mousehover,mouseenter, mouseout사용금지(미투데이ipad작업에서도 많이 수정됨)한다. \n- 입력할 것들 최소화 : 짧은 URL(me2day.net/mobile(X) => me2day.net/m(O)), Autocomplete(검색, 소환 등), 최대한 정보는 채워준다. 액션을 최소화(e.g. 안티pagination, pagination은 악몽 그자체이다. ) \n\n자제해야할 것들 : , 팝업창, 지나친Ajax(하려면 status bar에 load indicator를 보여주기), 자동새로고침, 자동리다이렉트(뒤에 Backend관련 이슈에서 더 논의), 수직스크롤,프레임\n\n\n\n야후의 7가지 카테고리에 대해서 35개 웹성능향상을 위한 팁 : http://developer.yahoo.com/performance/rules.html\nw3c mobile web best practice\n http://www.w3.org/2009/Talks/mwi-cambridge/session1.html#(18)\n
  • 1. 점진적 개발 : 컨텐츠 개발에 중점 => 프레젠테이션(CSS등)개선 => 최종적으로 (자바스크립트 등)클라이언트 스크립팅 추가. \n 미투데이의 WAP => 미투데이 모바일 WEB => 미투데이 웹서비스. BUT이미 레거시가 있는 거에는 큰 의미 없는 이야기.\nhumble javascript - fallback 처리.\nhttp://yozm.daum.net/gmarketstory/97283172#none => 우상단 사진 => 처리 안됨.\nhttp://me2day.net/21dara => 사진 클릭 => fallback처리 됨. GOOD \n\n\n-----------\n\n브라우저 엔진으로 2005년 애플이 프레임워크를 오픈소스로 공개함.\n- 아이폰웹뷰, 안드로이드 웹뷰, 노키아 등 모두 웹킷에 기초. 단 웹킷이라고 모두 100%동일한 렌더링 스펙을 가지고 있는 것은 아니다. \n\n대부분의 스마트폰이 아이폰과 안드로이드고 둘 다 webkit을 적용하였기 때문에 HTML5를 지원한다.\nIE가 HTML5지원에 소극적임에도 우리가 HTML5에 집중을 해야하는 이유가 바로 이때문이다. \n가트너 에서 발표한 2011년 11월 모바일 기기 동향 : http://www.gartner.com/it/page.jsp?id=1848514 \n모바일OS 인포그래픽 : http://www.winmatrix.com/forums/index.php?/topic/32443-android-vs-iphone-infographic/\n\nwebkit에서의 테스트 : http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html\n\n----\n\n
  • 1. 점진적 개발 : 컨텐츠 개발에 중점 => 프레젠테이션(CSS등)개선 => 최종적으로 (자바스크립트 등)클라이언트 스크립팅 추가. \n 미투데이의 WAP => 미투데이 모바일 WEB => 미투데이 웹서비스. BUT이미 레거시가 있는 거에는 큰 의미 없는 이야기.\nhumble javascript - fallback 처리.\nhttp://yozm.daum.net/gmarketstory/97283172#none => 우상단 사진 => 처리 안됨.\nhttp://me2day.net/21dara => 사진 클릭 => fallback처리 됨. GOOD \n\n\n-----------\n\n브라우저 엔진으로 2005년 애플이 프레임워크를 오픈소스로 공개함.\n- 아이폰웹뷰, 안드로이드 웹뷰, 노키아 등 모두 웹킷에 기초. 단 웹킷이라고 모두 100%동일한 렌더링 스펙을 가지고 있는 것은 아니다. \n\n대부분의 스마트폰이 아이폰과 안드로이드고 둘 다 webkit을 적용하였기 때문에 HTML5를 지원한다.\nIE가 HTML5지원에 소극적임에도 우리가 HTML5에 집중을 해야하는 이유가 바로 이때문이다. \n가트너 에서 발표한 2011년 11월 모바일 기기 동향 : http://www.gartner.com/it/page.jsp?id=1848514 \n모바일OS 인포그래픽 : http://www.winmatrix.com/forums/index.php?/topic/32443-android-vs-iphone-infographic/\n\nwebkit에서의 테스트 : http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html\n\n----\n\n
  • “사실상 Backend에는 모바일을 위한 최적화 기법이라는 게 특별히 없다. 기존 웹의 최적화 기법과 거의 유사하지만,\n 기존 데탑브라우저에서의 충분한 성능들로 관과 햇던 부분들에 대해 remind하는 차원의 의미가 있다. 그리고 아래 사항들을 개발 초기부터 하면 좋겠지만\n이미 레거시가 있는 경우가 대부분. 따라서 defect가 우선이 된다” \n
  • = 응답 압축 사용 = \n보통 gzip, deflate 압축알고리즘이 있지만 gzip을 주로 쓴다. \nJS, CSS, Makrup, JSON, XML등의 모든 동적 데이터는 웹서버에서 압축되어서 오는 게 좋다. \n일반적으로 오디오, 비디오, 이미지 등 의 멀티미디어는 응답 압축에 큰 이득이 없음(멀티미디어에서의 압축은 파일 자체 형식의 고유한 기능이기 때문)\n\n
  • = 캐싱 = \n- Date ; 서버의 응답시간. 클라이언트에서는 이 값을 가지고 파기여부를 결정. GMT로 표시 -\n- Last-Modified : 웹리소스가 마지막으로 수정된시간.정적문서에서는 웹서버 파일시스템에서 최근 수정한 날짜이고, 동적인 문서에서는 문서의 구성요소가 변경된 시간 혹은 현재시간이 됨. 생략하는 경우 GET-If-Modified-Since가 발생하여 무조건 GET이 발생되기 때문에 명시하는 것이 좋음. \n- Expire : 캐시가 언제 제거되어야 하는지 명시. 캐싱을 막기 위해서는 과거 시간이나 -1, 0과 같은 정수값을 넣으면 된다. 이 값보다 Cache-control헤더의 expire값이 더 우선순위가 높다. 대부분의 브라우저는 Expires순으로 캐시를 관리하기 때문 길수록 유리하다.\n- Cache-Control : 캐싱 지시자로서 핵심 헤더. 이는 클라이언트뿐만 아니라 downstream캐싱 프럭시 서버에서도 지켜져야 함을 지시하는 헤더값이다.\n- Cache-Control: no-cache, no-store, no-transform : 캐싱을 하지 않고, 저장하지 않으며, downstream 프록시에서 변형 하는것을 막는다는 의미. 기본적으로 앞에는 Public값(공개적인 데이터)가 들어가고 \n개인데이터(개인정보 등)를 캐싱할 경우에는 Private을 명시해주어야 한다.\n\n- Pragma : 캐시되지 말아야 할 경우를 위해서 Pragma: no-cache를 명시해준다. 하지만 Pragma는 HTTP1.1에서 optional로 정의하고 있기 때문에 이보다는 Cache-Control: no-cache를 쓰는 것이 좋다. - Vary : 해당 캐시 정책을 그룹핑할 때 사용한다. \n Vary: User-Agent, Accept => User-Agent와 Accept헤더와 동일한 값으로 요청하는 클라이언트들에 대해서만 캐시를 지정한다. \n- Etag : 생략되는 경우 GET-If-Not-Matched가 대신 적용되어 무조건 GET이 발생한다. 설정오류나 버그로 인해 문제가 있어서 사용은 추천하지 않는다. \nNHN권장사항 : Etag미사용, Last-Modified/Expires사용하자. \n\n-캐시 파기는 URL에 timestamp쿼리스트링을추가하거나 파일명을 바꾸자.(사내 CDN가이드는 파일명을 바꾸는 것으로 가이드) \n
  • 테스트에 대해 알아보는 거에 대한 당위성 : 하이브리드로 가든 네이티브로 가든! 가장 많은 리소스 비용이 드는 것은 바로 “테스트”이다!!!!!\n*****http://www.slideshare.net/fling/native-v-hybrid-v-web 83페이지 적극 인용*****\n\n\n기기를 잘 알아야 테스트가 가능하다. \n1. 기기의 커넥션 관련 성능 테스트 \n=브라우저 캐싱과 성능 테스트=\nhttp://cloudfour.com/mobile/ 페이지를 통해서, \n- 브라우저에서 가능한 동시 HTTP접속 수 \n- Gzip지원 여부\n- Expires가 먼 미래 혹은 정수(-1 or 0)일 경우 브라우저 영구 캐싱을 하는지 여부 \n등을 테스트해볼 수 있다.\n그 결과는 http://cloudfour.com/mobile/summary.php 에서 확인 가능\n\n2. 원격지에서의 디바이스 테스트\nhttp://deviceanywhere.com PerfectoMobile(http://perfectomobile.com) 이라는 온라인 서비스는 원격의 특정 지역에서 특정 모바일 기기를 통해서 테스트 가능 \n\n=에뮬/시뮬/브라우저 에서의 테스트 = \n- User-Agent switcher\n- window resizer \n- header modifier\n
  • \n“there is no WebKit on Mobile” \nwebkit에서의 테스트 : http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html\n테스트 결과 사파리4가 가장 잘 구현된 웹킷으로 나옴. \n\n
  • \n“there is no WebKit on Mobile” \nwebkit에서의 테스트 : http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html\n테스트 결과 사파리4가 가장 잘 구현된 웹킷으로 나옴. \n\n
  • \n“there is no WebKit on Mobile” \nwebkit에서의 테스트 : http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html\n\n=기기 테스트= \n각종 에뮬레이터, 시뮬레이터에서 테스트 가능, 에뮬/시뮬에서 테스틑 장비비용이 없고 기능분석 및 빠른 개발순환을 가지는데 도움이 되지만 \n에뮬레이터(특히 안드로이드)는 무겁고 시뮬레이터는 기능이 부족함. 컴퓨팅 리소스/네트워크대역폭등을 100%재현하는 것은 불가능 하고 \n주류를 이루고 있는 webkit도 개마다 구현이 다르기 때문에 가장 좋은 테스트 방법은 \n“실기에서 테스트 하는것이 갑” \n\n\n\n
  • =실기기에서의 테스트=\n- weinre활용 : 모바일 웹 inspect테스트(safrai/chrome의 web inspect같은)모\n http://www.youtube.com/watch?v=gaAI29UkVCc\n 장점 : PC 웹 디버깅과 유사한 디버깅 경험을 주고, 모든 OS및 단말에서 사용 가능, 실시간으로 모바일 페이지 변경 테스트 가능, \n 단점 : 스크립트로 무거워져서 성능테스트는 하기엔 무리가 있음. \n- console.log : iOS sarafi에서 console을 킬 수 있음. 안드로이드에서는 단말과 PC를 연결해서 Dalvik debug monitor를 통해서 가능. \n- CAProxy(윈도우)프록싱을 이용한 테스트\n\n\n\n
  • - console.log : iOS sarafi에서 console을 킬 수 있음. 안드로이드에서는 단말과 PC를 연결해서 Dalvik debug monitor를 통해서 가능. \n- CAProxy(윈도우)프록싱을 이용한 테스트\n\n\n\n
  • http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php\n\n7.5억명의 AU(Active User)\\, stmart폰에서 feature폰까지 무수한 client들에서 모두 가용하다. \n모바일 개발은 2006년에 시작, m.facebook.com/webkit터치인터페이스에서 HTML5까지 활용중. \nfacebook 스파르판 프로젝트(http://www.slashgear.com/facebook-project-spartan-leaks-unveil-tipped-monday-with-ipad-app-29183916/, http://www.bloter.net/archives/64419(ko) )\n(스파르탄프로젝트 : 애플을 정면 겨냥한 모바일 앱 플랫폼. 페이스북 앱을 애플 앱스토어가 아닌 사파리 웹 브라우저의 모바일 버전에서 돌아가게 끔 하는 것. 스파르탄 프로젝트의 목표는 앱배포와관련해 애플의 통제를 벗어나는 것.)\n====\n=지난 5년에 걸치 모바일표준의 변화(HTML중심)= \n2006년까지만 해도 HTML과 SMS에 기반한 WAP서비스를 제공하였지만 20067년 iphone이란 큰 패러다임의 변화가 생겼고, 2007년 Facebook Platform API를 공개함. 아이폰이 생기면서 CSS, Javascript 리치한 경험을 줄 수 있었음. 블랙베리, 윈도우폰 노키아 ,삼성 등등이 facebook API로 구현이 가능했음. \n2008년엔 아이폰이 앱스토어를 열었다. 그때 처음으로 아이폰용 facebook을 만들 수 있었다. 2009년엔 안드로이드. 이로써 다양한 완성도 높은 플랫폼(윈도,아이폰,안드로이드, 웹)위에서 페북을 서비스해야했다. \n\n====\n\n이때부터 개발자들의 고통은 시작되었다. 생산성이 저하되었다. 새로운 기능이 나오면 이 4개의 플랫폼에 동시 런칭이 힘들었고 런칭이 느려졌고, 코드는 안좋아져만 갔다. \n\n====\n\n=같은 기능을 4번이나 반복하지 않는 방법= \n그렇다면 우린 이를 어떻게 극복했나? 네가지 중에서 가장 배포하기 쉬운것은? 웹이다. 여기 우리는 배포를 touch.facebook.com, m.facebook.com으로 나누어 개발하였다. webkit기반의 폰이면 터치로 가고 그렇지 않으면 M으로 간다. \n\n이 방식이 모든 폰에 최적의 경험을 주지는 못했다. 화면 내에 inline image나 css의 버전, 등의 문제가 있었다. 우리는 이 문제를 해결해야만 했다. \nXSL post processing등을 썼으나 좋지 않았음. 쨌든, 한번에 코드를 작성할 수 있는 방법을 강구해야한다. \n\n====\n\n=Progressive Enhancement혁신적인개선= \n우리가 한방법은 다음과 같다. \n방법의 초석은 당신이 가지고 있는 폰이 무엇을 할수 잇는냐를 인식하는 것이다. 그 기기의 capa가 제대로된 경험을 줄수 있도록 시작되는 시발점이다. \nWURFL(Wireless Universal Resources File, http://wurfl.sourceforge.net/)프로젝트는 user-agent에 따른 각 기기의 capa를 작성하는 프로젝트였다.(예를 들어, 화면크기? JS는? cookies는? 등)모두 해결해야만 하는 중요한 문제들이었다. \n이런 UserAgent마다의 정보를 우리가 모두 수집하는 것은 어려웠기에 opensource로 개방하고 모두의 협조를 구했고, 또 개방하였다. 그것이 WURFL프로젝트이다. \n\n일단 useragent와 그 각각의 capa를 알면, 무엇을 해야하는지도 알게 되는 것이다. 페북의 버튼이 HTML이거나 Javascript의 블락으로 이루어져 있지 않아도 된다는 것. 홈페이지에서 당신이 원하는 것은 버튼을 그릴 수 있는 컴포저라는거. 따라서 진짜 필요한 것은 버튼이다. 무엇이 렌더링 되어야 하는지를 알아야만 한다. 만약에 폰이 low-end(피쳐폰같이)폰이면 post form을 그리면 될 것이고, 폰이CSS를 쓸 수 있는 mid-range폰이면 CSS layer를 사용할 수 있다. 하지만 high-end폰일 경우에는 Ajax스타일의 경험을 사용할수도 있다. 이 기술은 야후의 blueprint플랫폼 (http://www.slideshare.net/blueprintblog/bp-dev-tutorial-mm-presentation) 과 같이 이미 개척을 한 사례도있다. 따라서 top-level에서 low-end까지의 기술적인 얘기를 하는 것 대신에, 할 수 있는 것을 결정할 화면을 렌더링 하는 마크업 선언 안의 컴포넌트각각에 대해서 알아볼 것이다. 이는 폰에서 이상적인 경험을 구성하기 위해서 구성되었다. 이 기술을 progressive enhancement라고 부른다. \n\n이는 곧 웹이라면 어드든 write once run anywhere할 수 있도록 방향을 잡게 되었따. 그리고 웹은 진짜 그리할수 있어 보였다. 데탑에서는 이미 그리하고 있고, 모바일에서도 이와 마찬가지로 진행할 수 있을 터. 하지만 안드로이드나 아이폰유저들은 훌륭한 모바일브라우저를 통해서 접근할 수 있다는 것에도 불구하고 웹이야기를 하면 지겨워할지도 모른다. \n\n따라서 4개의 레이어에서 1개를 제외하고 멋진 3개에 대해서만 촛점을 맞춰보자. 하지만 물론 모두가 아이폰에 대해 얘기하길 원할것이다. 아이폰을 예로들면, \n아이폰에서의 경험을 주기 위해서 Objective-C를 사용해야하거나 해야한다. 그렇다면 facebook뉴스피드도 정말 그러한가? 상단에 탑바가 있고 캐시로부터 바로 렌더링하고, 그게 전부다. 다른 기기에서도 그래야 하는가? 아니다. 다 같다 .\n이 같은것을 매번 3차례 개발할 필요는 없다는 것이다. \n\n=상상 이상으로 미친짓=\n그렇다면, 앱 내에 진짜 브라우저를 넣으면 어떨까? 미친 아이디어였다. 그때당시만 해도 미친생각이었다. 앱 내에서 브라우저를 가져올수있는 경우도 드물었기 때문. 3가지는 적어도 WebKit을 잘 구현해놓았다. 따라서, 시도를 했으나 정말 쉽지 않았다. \n\n====\n\n=Iterate Dailiy= \n이는 매일 배포를 할 수 있다. 앱스토어의 승인을 받느라 기다리지 않아도 되고 사용자들이 download받아주길 기다리지 않아도 된다. 매일 배포할 수 있다. \n아이폰,안드로이드폰 개발팀이 분리되어 있지 않아도 된다. 모두 같은 문제를 직면하고 같이 문제를 해결한다. 4번 배포를 하지 않고 1번 집중해서 배포를 한다. \n\n이는 Project FaceWeb이라 불리고 progressive enhancement아이디어의 확장이다. Webkit브라우저에 렌더링한다고 말하는 대신에, 우리가 아이폰 앱 내의 WebKit에다가 렌더링 할 것이라고 할 수 있다. 따라서 우리가 해야할 일은 기기를 감지하고 동작할 수 있도록 Web코드를 스타일링하고 네이티브앱과 소통하기 위해서 Objective-C를 짜서 Javascript와 통신하여 HTML로 페북페이지를 렌더링하도록 하면 되는것이다. 따라서 네이티브구현은 최소화 하는 것이다. \n\n=The Answer : 네이티브 앱 안에 Facebook Mobile을 싼다= \n기술적으로 이게 어떻게 돌아가는가? 아이폰에서 news feed버튼을 누른다. 만약 FaceWeb 가능한 기기면, native Web controller로 매핑시키지 않고 m.facebook.com/home.php를 가져온다. 단순히 웹 뷰를 보여주는 것이다. 이 웹뷰가 어떻게 Objective-C와 통신하는지 알아야한다. 따라서 해당 프레임에서 요구하는 "platform extraction call layer"를 명시한 JS skeleton을 회신한다. 그러면 다른 동작을 하고 home.php와 JavaScript를 로드한다. \n이는 기본적으로 m.facebook.com사이트를 만들고 Javascript를 폰의 네이티브기능(카페라 등 )들을 사용할 수 있는 abstraction layer를 둔다는 것이다. \n\n그 bridge에서 해야만하는 것은? 분명sensor와 data같은 것들이다. \nGPS를 알고싶다면 HTML5에서는 지원하지만 다 지원하지 않기 때문에 각 기기의 accelerometer나 orientation lock같은 것들을 참고해야한다. \nJavascript < query >Native, Camera플로우 등은 Native를 써야만 한다.\n\n=stick point : Web vs Native Design=\nmutating components : <m:button /> \n폰갭은 위에 그 문제를 해결해 주었다. 문제는 보여줄 수 있는 버튼이 하나면 절대 native스럽지 않게 보인다는 것. 두번째는 네이티브 느낌을 못준다는 것, 세번째는 빠르지 않다는 것이다. 이 세가지가 폰갭에서 얻은 것이다. \n\n첫번째 위임은, 이 일들을 HTML로 하고 싶다는 것, 뉴스피드의 경우 HTML로 보여주는 것과 네이티브로 보여주는 것에는 차이점이 없다는 것을 재차 강조. 이는 단순히 비주얼이라는 큰문제로 끝나지 않는다. 웹과 앱은 서로 잘 동작한다. 우리가 앱에 브라우저를 넣었을 때 사용자들은 한 경우를 제외하고는 전혀 불평하지 않앗다. \n\n그 한가지는 페이스북과 친한 iPad앱이다. 이는 단순히 m.site를 감싼 거다. 어떤 사용자들은 페이스북이 m.site를 대충 고쳐서 복사해 찍어냈다고 말한다. 실제로 m.site를 썼고 좋았다. 따라서 사실은 네이티브같이 보이지 않아고, 그것이 큰 문제가 되지 않았다. \n\n아직도 연구해야할게 남았다. position fix와 overflow scroll이 가장 큰 문제였다. 안드로이드 2.1이하에서는 전혀 방법이 없었고, 2.2에서는 작업을 시작했고 iOS5에서는 이 모든것을 구현해주기로 했다. 따라서 지금 웹앱을 시작하는것은 10개월 전보다 훨씩 수월할 것이다. CSS 그라디언트도 문제였고 이미지도 문제였다. 그 외에도 더 몇가지가 있다. \n\n=Web vs Native Feel : scroll=\n다른 문제는 네이티브느낌이 나지 않는다는 것이고 이는 대부분 스크롤할때이다. \n예를 들어 지우기 위해서 swipe를 하고 싶을때, 스크롤이 되어버린다. 이는 별문제 아니다. 스크롤 관련해서 GPU나 파이프라이닝이 네이티브에서는 잘 되어 있지만 HTML에서는 구현하기가 매우 힘들다. 대부분의 사람들이 네이티브 느낌이 나지 않다고 말하는 것은 스크롤을 할 때이다. \n\n종종 스크롤을 구현한다. iScroll잘 동작하고 Hewitts도 잘 동작한다. 따라서, JS라이브러리를 쓸 수도 있다. 또한 브라우저내에서의 이미지 확대축소와같은 것은 GPU를 쓰기 때문에 무리없이 할 수 있다. 그리고 이런 자잘한 것들은 문서화되어 있지 않다. 예를 들어 안드로이드나 아이폰에서 키보드가 보여지고 닫혀지지 않ㄴ,ㄴ것등. 시스템에서 정해진 그런자잘한 것들이 좀 있다. \n\n\n=Issue of Speed =\n마지막으로 한가지는 충분히 빠르지 않다는 것. 아이폰 앱에서 천천히 내리면 확인해볼 수 있음. \n\n따라서 방법은 명확히 pre-cache만이 살길이라는거. news feeds를 렌더링 한다고 치면, 버튼을 누르자마자 보여야 하는데 이를위해, 웹뷰를 캐시하는것이다. 그것이 동작하지 않을 경우 가장 좋은 방법은 사용자들을 속이는 것이다. 적어도 준비가 될때가지. 뼈대를 렌더링하고 캐시된 컨텐트로 채우고 그 다음엔 해로운 컨텐트를 보여주는 것이다. 적어도 사용자는 첫 응답이 왔기 때문에 변화를 인지하면 기다린다. \n\n퍼포먼스는 당신이 얼마나 JS를 많이 쓰는가에 대한 거다. 단순히 데이터를 로딩할 뿐만 아니라 더 무거운 pre-rendered된 만크업을 로딩한다. HTTP cache와 같은 경우 그리고 app cache와 같은 경우 그것들은 UI Web view에서 동작한다고 하지만 종종 그렇지 않다. 따라서 그 리소스들이 모두 여기서 만들어지는 확신할 수 있어야만 한다. \n\n=Taking The Approach everywhere= \n하지만, 안드로이드에서 잘 동작했다. 따라서 m.site와 같은식으로 만들 수 잇었다. news feed가 변경되거나 news feed가 추가되거나 comment가 추가되거나 모두 low-end인 m.site에 뿌려지고 high-end m.site에 뿌려지고 아이폰패북, 안드로이드패북에도 다음날이면 적용되었다. \n따라서, 우리는 이렇게 했고, 페북경험의 요소를 가지게 됬고 모든 것들 안에 브라우저가 삽입되었다. 특히 new feed나 당신의 프로필 타임라인과 같은 가장 자주 변하는 것들에 대해서는HTML을 바로 사용하였다. \n\n=어떻게 진화했는가 : HTML5 =\niOS3.4와 3.5에서 동작한다. news feed와 profile feed는 m.site로부터 소스를 가져온 것이다. 따라서, m.site가 변경되고 피처가 추가되면 그것이 적용된다. m.site가 장애가 생기면 모든 것이 뻑난다. 장단점이 있다는 것이다. iOS4.0에서 는 requests, notifications, search, list-style content가 네이티브를 쓰지 않고 FaceWeb을 사용하였다. 안드로이드 1.6, 1.7에서도 동일하게 진행. 피드백과 디자인은 꽤 좋았지만 버그들이 좀 많았다. Javascript 버전등이 맞지 않는다거나 문제가 생기면 빨리 고칠수 있다. \n따라서,미션은 한개의 코드베이스로부터 동작하고 세상의 모든 브라우저에 적용하는 것이다. 이는 페이스북에서 말하는 것 같지만 사실은 HTML5의 구호이다. \n\nHTML5가 아마도 우리가 하고자 하는 것일거다. 이는 HTML5가 물밑에서 변화되고 있기에 써야한다. 하이브리드 앱을 만다는 초기에는 HTML5에 잇는 특정한 것들은 준비되지 않아씅ㄹ 수 있지만 잊어버리라고 말하고 있다. 계속 전진하고 있다. 네이트브 핸들링이나 렌더링을 html5를 통해서 더 잘 대체해내루도 있고 in-browser기술(기기 접근, 좋은 native framework, applicatio 그리고 display code. \n\nWhat has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?\n\n=Device Access= \n따라서, 기기 접근이다. 기기 내에 제한된 정보를 가져오는 것이 그 예. Geolocation, network connectivity, obviously very big for caching, 카메라, 연락처,. geo-location. 이는 HTML5로 할 수 있고, 반대로 m.facebook.com에서 Places와 Deals 스터프를 기반으로 사용한다; network connectivity는 최근 생겨났고 최신 브라우저에서는 HTML5를 통해서 알 수 있다. 카메라와 주소들은 아직. 하지만 가져올수 있고 없는 것을 알고 싶다면, PhoneGap.com을 참고하길. 이 모든것들이 아직 과도기. \n\n\n= History= \nHistory를 개발할 수 있는 프레임워크가 네이티브에 존재. 이는 매우weired하다. 왜냐면 native stack 에 쌓여있고 이는 브라우저의 history와는 매우 다르기 때문. 브라우저는 히스토리를 다루는 방식이 매우 다르고 그 모델도 매우 다름. 히스토리 관리, client-side , threading은 중요. threading은 특히 중요. \n\nHTML5는 이 모든것을 통합할 수도 있음. history 관리를 위해 HTML5에는 좋은 기능이 있음. IndexDB와 client-side storage는 더덕 좋은 기능. WebWorkers같은 것이 다시 생기면 HTML5 에서 쓸수 있을 거다. \n\n=앱이 웹기술만들오 만들어질 수 있나? = \n결론적으로 중요한것은 웹기술만드으로 앱을 만들 수 잇냐는것이다. \n실제 웹 기술이 사용되고 당신도 사용하고 있다. 스크롤/리프레시/fast stuff등은 네이티브핸들러를 쓴다. 하지만 scrolling은 iOS5가 scrolling, position fixed overflow scorll을 만들어준 덕분에 네이티브를 쓴ㄴ 것은 옛날얘기가 되었따. 고정위치 header와 good scrolling은 네이티브만의 것이라고 생각하지만 이는 잘만들어진 JS와 새로운 framework들 덕분에 극복해낼수 있다는거. \n\njS엔진이 계속 좋아지고 있고, V8과 Nitro는 full-fledged JS로 objective c나 자바를 쓰지 않고 그에 상응하는 앱을 만들 수 있는 것을보여줬다. Netflix는 이미 이를 상품화 했다. \n\n따라서 빅 브라우저 제조사달의 긴급한 투자는 정말 정말 좋은 JS를 만드는 것. \nAnd if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have\n\n-----------------------------------------------------------------------------------------------------\n
  • http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php\n\n7.5억명의 AU(Active User)\\, stmart폰에서 feature폰까지 무수한 client들에서 모두 가용하다. \n모바일 개발은 2006년에 시작, m.facebook.com/webkit터치인터페이스에서 HTML5까지 활용중. \nfacebook 스파르판 프로젝트(http://www.slashgear.com/facebook-project-spartan-leaks-unveil-tipped-monday-with-ipad-app-29183916/, http://www.bloter.net/archives/64419(ko) )\n(스파르탄프로젝트 : 애플을 정면 겨냥한 모바일 앱 플랫폼. 페이스북 앱을 애플 앱스토어가 아닌 사파리 웹 브라우저의 모바일 버전에서 돌아가게 끔 하는 것. 스파르탄 프로젝트의 목표는 앱배포와관련해 애플의 통제를 벗어나는 것.)\n====\n=지난 5년에 걸치 모바일표준의 변화(HTML중심)= \n2006년까지만 해도 HTML과 SMS에 기반한 WAP서비스를 제공하였지만 20067년 iphone이란 큰 패러다임의 변화가 생겼고, 2007년 Facebook Platform API를 공개함. 아이폰이 생기면서 CSS, Javascript 리치한 경험을 줄 수 있었음. 블랙베리, 윈도우폰 노키아 ,삼성 등등이 facebook API로 구현이 가능했음. \n2008년엔 아이폰이 앱스토어를 열었다. 그때 처음으로 아이폰용 facebook을 만들 수 있었다. 2009년엔 안드로이드. 이로써 다양한 완성도 높은 플랫폼(윈도,아이폰,안드로이드, 웹)위에서 페북을 서비스해야했다. \n\n====\n\n이때부터 개발자들의 고통은 시작되었다. 생산성이 저하되었다. 새로운 기능이 나오면 이 4개의 플랫폼에 동시 런칭이 힘들었고 런칭이 느려졌고, 코드는 안좋아져만 갔다. \n\n====\n\n=같은 기능을 4번이나 반복하지 않는 방법= \n그렇다면 우린 이를 어떻게 극복했나? 네가지 중에서 가장 배포하기 쉬운것은? 웹이다. 여기 우리는 배포를 touch.facebook.com, m.facebook.com으로 나누어 개발하였다. webkit기반의 폰이면 터치로 가고 그렇지 않으면 M으로 간다. \n\n이 방식이 모든 폰에 최적의 경험을 주지는 못했다. 화면 내에 inline image나 css의 버전, 등의 문제가 있었다. 우리는 이 문제를 해결해야만 했다. \nXSL post processing등을 썼으나 좋지 않았음. 쨌든, 한번에 코드를 작성할 수 있는 방법을 강구해야한다. \n\n====\n\n=Progressive Enhancement혁신적인개선= \n우리가 한방법은 다음과 같다. \n방법의 초석은 당신이 가지고 있는 폰이 무엇을 할수 잇는냐를 인식하는 것이다. 그 기기의 capa가 제대로된 경험을 줄수 있도록 시작되는 시발점이다. \nWURFL(Wireless Universal Resources File, http://wurfl.sourceforge.net/)프로젝트는 user-agent에 따른 각 기기의 capa를 작성하는 프로젝트였다.(예를 들어, 화면크기? JS는? cookies는? 등)모두 해결해야만 하는 중요한 문제들이었다. \n이런 UserAgent마다의 정보를 우리가 모두 수집하는 것은 어려웠기에 opensource로 개방하고 모두의 협조를 구했고, 또 개방하였다. 그것이 WURFL프로젝트이다. \n\n일단 useragent와 그 각각의 capa를 알면, 무엇을 해야하는지도 알게 되는 것이다. 페북의 버튼이 HTML이거나 Javascript의 블락으로 이루어져 있지 않아도 된다는 것. 홈페이지에서 당신이 원하는 것은 버튼을 그릴 수 있는 컴포저라는거. 따라서 진짜 필요한 것은 버튼이다. 무엇이 렌더링 되어야 하는지를 알아야만 한다. 만약에 폰이 low-end(피쳐폰같이)폰이면 post form을 그리면 될 것이고, 폰이CSS를 쓸 수 있는 mid-range폰이면 CSS layer를 사용할 수 있다. 하지만 high-end폰일 경우에는 Ajax스타일의 경험을 사용할수도 있다. 이 기술은 야후의 blueprint플랫폼 (http://www.slideshare.net/blueprintblog/bp-dev-tutorial-mm-presentation) 과 같이 이미 개척을 한 사례도있다. 따라서 top-level에서 low-end까지의 기술적인 얘기를 하는 것 대신에, 할 수 있는 것을 결정할 화면을 렌더링 하는 마크업 선언 안의 컴포넌트각각에 대해서 알아볼 것이다. 이는 폰에서 이상적인 경험을 구성하기 위해서 구성되었다. 이 기술을 progressive enhancement라고 부른다. \n\n이는 곧 웹이라면 어드든 write once run anywhere할 수 있도록 방향을 잡게 되었따. 그리고 웹은 진짜 그리할수 있어 보였다. 데탑에서는 이미 그리하고 있고, 모바일에서도 이와 마찬가지로 진행할 수 있을 터. 하지만 안드로이드나 아이폰유저들은 훌륭한 모바일브라우저를 통해서 접근할 수 있다는 것에도 불구하고 웹이야기를 하면 지겨워할지도 모른다. \n\n따라서 4개의 레이어에서 1개를 제외하고 멋진 3개에 대해서만 촛점을 맞춰보자. 하지만 물론 모두가 아이폰에 대해 얘기하길 원할것이다. 아이폰을 예로들면, \n아이폰에서의 경험을 주기 위해서 Objective-C를 사용해야하거나 해야한다. 그렇다면 facebook뉴스피드도 정말 그러한가? 상단에 탑바가 있고 캐시로부터 바로 렌더링하고, 그게 전부다. 다른 기기에서도 그래야 하는가? 아니다. 다 같다 .\n이 같은것을 매번 3차례 개발할 필요는 없다는 것이다. \n\n=상상 이상으로 미친짓=\n그렇다면, 앱 내에 진짜 브라우저를 넣으면 어떨까? 미친 아이디어였다. 그때당시만 해도 미친생각이었다. 앱 내에서 브라우저를 가져올수있는 경우도 드물었기 때문. 3가지는 적어도 WebKit을 잘 구현해놓았다. 따라서, 시도를 했으나 정말 쉽지 않았다. \n\n====\n\n=Iterate Dailiy= \n이는 매일 배포를 할 수 있다. 앱스토어의 승인을 받느라 기다리지 않아도 되고 사용자들이 download받아주길 기다리지 않아도 된다. 매일 배포할 수 있다. \n아이폰,안드로이드폰 개발팀이 분리되어 있지 않아도 된다. 모두 같은 문제를 직면하고 같이 문제를 해결한다. 4번 배포를 하지 않고 1번 집중해서 배포를 한다. \n\n이는 Project FaceWeb이라 불리고 progressive enhancement아이디어의 확장이다. Webkit브라우저에 렌더링한다고 말하는 대신에, 우리가 아이폰 앱 내의 WebKit에다가 렌더링 할 것이라고 할 수 있다. 따라서 우리가 해야할 일은 기기를 감지하고 동작할 수 있도록 Web코드를 스타일링하고 네이티브앱과 소통하기 위해서 Objective-C를 짜서 Javascript와 통신하여 HTML로 페북페이지를 렌더링하도록 하면 되는것이다. 따라서 네이티브구현은 최소화 하는 것이다. \n\n=The Answer : 네이티브 앱 안에 Facebook Mobile을 싼다= \n기술적으로 이게 어떻게 돌아가는가? 아이폰에서 news feed버튼을 누른다. 만약 FaceWeb 가능한 기기면, native Web controller로 매핑시키지 않고 m.facebook.com/home.php를 가져온다. 단순히 웹 뷰를 보여주는 것이다. 이 웹뷰가 어떻게 Objective-C와 통신하는지 알아야한다. 따라서 해당 프레임에서 요구하는 "platform extraction call layer"를 명시한 JS skeleton을 회신한다. 그러면 다른 동작을 하고 home.php와 JavaScript를 로드한다. \n이는 기본적으로 m.facebook.com사이트를 만들고 Javascript를 폰의 네이티브기능(카페라 등 )들을 사용할 수 있는 abstraction layer를 둔다는 것이다. \n\n그 bridge에서 해야만하는 것은? 분명sensor와 data같은 것들이다. \nGPS를 알고싶다면 HTML5에서는 지원하지만 다 지원하지 않기 때문에 각 기기의 accelerometer나 orientation lock같은 것들을 참고해야한다. \nJavascript < query >Native, Camera플로우 등은 Native를 써야만 한다.\n\n=stick point : Web vs Native Design=\nmutating components : <m:button /> \n폰갭은 위에 그 문제를 해결해 주었다. 문제는 보여줄 수 있는 버튼이 하나면 절대 native스럽지 않게 보인다는 것. 두번째는 네이티브 느낌을 못준다는 것, 세번째는 빠르지 않다는 것이다. 이 세가지가 폰갭에서 얻은 것이다. \n\n첫번째 위임은, 이 일들을 HTML로 하고 싶다는 것, 뉴스피드의 경우 HTML로 보여주는 것과 네이티브로 보여주는 것에는 차이점이 없다는 것을 재차 강조. 이는 단순히 비주얼이라는 큰문제로 끝나지 않는다. 웹과 앱은 서로 잘 동작한다. 우리가 앱에 브라우저를 넣었을 때 사용자들은 한 경우를 제외하고는 전혀 불평하지 않앗다. \n\n그 한가지는 페이스북과 친한 iPad앱이다. 이는 단순히 m.site를 감싼 거다. 어떤 사용자들은 페이스북이 m.site를 대충 고쳐서 복사해 찍어냈다고 말한다. 실제로 m.site를 썼고 좋았다. 따라서 사실은 네이티브같이 보이지 않아고, 그것이 큰 문제가 되지 않았다. \n\n아직도 연구해야할게 남았다. position fix와 overflow scroll이 가장 큰 문제였다. 안드로이드 2.1이하에서는 전혀 방법이 없었고, 2.2에서는 작업을 시작했고 iOS5에서는 이 모든것을 구현해주기로 했다. 따라서 지금 웹앱을 시작하는것은 10개월 전보다 훨씩 수월할 것이다. CSS 그라디언트도 문제였고 이미지도 문제였다. 그 외에도 더 몇가지가 있다. \n\n=Web vs Native Feel : scroll=\n다른 문제는 네이티브느낌이 나지 않는다는 것이고 이는 대부분 스크롤할때이다. \n예를 들어 지우기 위해서 swipe를 하고 싶을때, 스크롤이 되어버린다. 이는 별문제 아니다. 스크롤 관련해서 GPU나 파이프라이닝이 네이티브에서는 잘 되어 있지만 HTML에서는 구현하기가 매우 힘들다. 대부분의 사람들이 네이티브 느낌이 나지 않다고 말하는 것은 스크롤을 할 때이다. \n\n종종 스크롤을 구현한다. iScroll잘 동작하고 Hewitts도 잘 동작한다. 따라서, JS라이브러리를 쓸 수도 있다. 또한 브라우저내에서의 이미지 확대축소와같은 것은 GPU를 쓰기 때문에 무리없이 할 수 있다. 그리고 이런 자잘한 것들은 문서화되어 있지 않다. 예를 들어 안드로이드나 아이폰에서 키보드가 보여지고 닫혀지지 않ㄴ,ㄴ것등. 시스템에서 정해진 그런자잘한 것들이 좀 있다. \n\n\n=Issue of Speed =\n마지막으로 한가지는 충분히 빠르지 않다는 것. 아이폰 앱에서 천천히 내리면 확인해볼 수 있음. \n\n따라서 방법은 명확히 pre-cache만이 살길이라는거. news feeds를 렌더링 한다고 치면, 버튼을 누르자마자 보여야 하는데 이를위해, 웹뷰를 캐시하는것이다. 그것이 동작하지 않을 경우 가장 좋은 방법은 사용자들을 속이는 것이다. 적어도 준비가 될때가지. 뼈대를 렌더링하고 캐시된 컨텐트로 채우고 그 다음엔 해로운 컨텐트를 보여주는 것이다. 적어도 사용자는 첫 응답이 왔기 때문에 변화를 인지하면 기다린다. \n\n퍼포먼스는 당신이 얼마나 JS를 많이 쓰는가에 대한 거다. 단순히 데이터를 로딩할 뿐만 아니라 더 무거운 pre-rendered된 만크업을 로딩한다. HTTP cache와 같은 경우 그리고 app cache와 같은 경우 그것들은 UI Web view에서 동작한다고 하지만 종종 그렇지 않다. 따라서 그 리소스들이 모두 여기서 만들어지는 확신할 수 있어야만 한다. \n\n=Taking The Approach everywhere= \n하지만, 안드로이드에서 잘 동작했다. 따라서 m.site와 같은식으로 만들 수 잇었다. news feed가 변경되거나 news feed가 추가되거나 comment가 추가되거나 모두 low-end인 m.site에 뿌려지고 high-end m.site에 뿌려지고 아이폰패북, 안드로이드패북에도 다음날이면 적용되었다. \n따라서, 우리는 이렇게 했고, 페북경험의 요소를 가지게 됬고 모든 것들 안에 브라우저가 삽입되었다. 특히 new feed나 당신의 프로필 타임라인과 같은 가장 자주 변하는 것들에 대해서는HTML을 바로 사용하였다. \n\n=어떻게 진화했는가 : HTML5 =\niOS3.4와 3.5에서 동작한다. news feed와 profile feed는 m.site로부터 소스를 가져온 것이다. 따라서, m.site가 변경되고 피처가 추가되면 그것이 적용된다. m.site가 장애가 생기면 모든 것이 뻑난다. 장단점이 있다는 것이다. iOS4.0에서 는 requests, notifications, search, list-style content가 네이티브를 쓰지 않고 FaceWeb을 사용하였다. 안드로이드 1.6, 1.7에서도 동일하게 진행. 피드백과 디자인은 꽤 좋았지만 버그들이 좀 많았다. Javascript 버전등이 맞지 않는다거나 문제가 생기면 빨리 고칠수 있다. \n따라서,미션은 한개의 코드베이스로부터 동작하고 세상의 모든 브라우저에 적용하는 것이다. 이는 페이스북에서 말하는 것 같지만 사실은 HTML5의 구호이다. \n\nHTML5가 아마도 우리가 하고자 하는 것일거다. 이는 HTML5가 물밑에서 변화되고 있기에 써야한다. 하이브리드 앱을 만다는 초기에는 HTML5에 잇는 특정한 것들은 준비되지 않아씅ㄹ 수 있지만 잊어버리라고 말하고 있다. 계속 전진하고 있다. 네이트브 핸들링이나 렌더링을 html5를 통해서 더 잘 대체해내루도 있고 in-browser기술(기기 접근, 좋은 native framework, applicatio 그리고 display code. \n\nWhat has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?\n\n=Device Access= \n따라서, 기기 접근이다. 기기 내에 제한된 정보를 가져오는 것이 그 예. Geolocation, network connectivity, obviously very big for caching, 카메라, 연락처,. geo-location. 이는 HTML5로 할 수 있고, 반대로 m.facebook.com에서 Places와 Deals 스터프를 기반으로 사용한다; network connectivity는 최근 생겨났고 최신 브라우저에서는 HTML5를 통해서 알 수 있다. 카메라와 주소들은 아직. 하지만 가져올수 있고 없는 것을 알고 싶다면, PhoneGap.com을 참고하길. 이 모든것들이 아직 과도기. \n\n\n= History= \nHistory를 개발할 수 있는 프레임워크가 네이티브에 존재. 이는 매우weired하다. 왜냐면 native stack 에 쌓여있고 이는 브라우저의 history와는 매우 다르기 때문. 브라우저는 히스토리를 다루는 방식이 매우 다르고 그 모델도 매우 다름. 히스토리 관리, client-side , threading은 중요. threading은 특히 중요. \n\nHTML5는 이 모든것을 통합할 수도 있음. history 관리를 위해 HTML5에는 좋은 기능이 있음. IndexDB와 client-side storage는 더덕 좋은 기능. WebWorkers같은 것이 다시 생기면 HTML5 에서 쓸수 있을 거다. \n\n=앱이 웹기술만들오 만들어질 수 있나? = \n결론적으로 중요한것은 웹기술만드으로 앱을 만들 수 잇냐는것이다. \n실제 웹 기술이 사용되고 당신도 사용하고 있다. 스크롤/리프레시/fast stuff등은 네이티브핸들러를 쓴다. 하지만 scrolling은 iOS5가 scrolling, position fixed overflow scorll을 만들어준 덕분에 네이티브를 쓴ㄴ 것은 옛날얘기가 되었따. 고정위치 header와 good scrolling은 네이티브만의 것이라고 생각하지만 이는 잘만들어진 JS와 새로운 framework들 덕분에 극복해낼수 있다는거. \n\njS엔진이 계속 좋아지고 있고, V8과 Nitro는 full-fledged JS로 objective c나 자바를 쓰지 않고 그에 상응하는 앱을 만들 수 있는 것을보여줬다. Netflix는 이미 이를 상품화 했다. \n\n따라서 빅 브라우저 제조사달의 긴급한 투자는 정말 정말 좋은 JS를 만드는 것. \nAnd if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have\n\n-----------------------------------------------------------------------------------------------------\n
  • http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php\n\n7.5억명의 AU(Active User)\\, stmart폰에서 feature폰까지 무수한 client들에서 모두 가용하다. \n모바일 개발은 2006년에 시작, m.facebook.com/webkit터치인터페이스에서 HTML5까지 활용중. \nfacebook 스파르판 프로젝트(http://www.slashgear.com/facebook-project-spartan-leaks-unveil-tipped-monday-with-ipad-app-29183916/, http://www.bloter.net/archives/64419(ko) )\n(스파르탄프로젝트 : 애플을 정면 겨냥한 모바일 앱 플랫폼. 페이스북 앱을 애플 앱스토어가 아닌 사파리 웹 브라우저의 모바일 버전에서 돌아가게 끔 하는 것. 스파르탄 프로젝트의 목표는 앱배포와관련해 애플의 통제를 벗어나는 것.)\n====\n=지난 5년에 걸치 모바일표준의 변화(HTML중심)= \n2006년까지만 해도 HTML과 SMS에 기반한 WAP서비스를 제공하였지만 20067년 iphone이란 큰 패러다임의 변화가 생겼고, 2007년 Facebook Platform API를 공개함. 아이폰이 생기면서 CSS, Javascript 리치한 경험을 줄 수 있었음. 블랙베리, 윈도우폰 노키아 ,삼성 등등이 facebook API로 구현이 가능했음. \n2008년엔 아이폰이 앱스토어를 열었다. 그때 처음으로 아이폰용 facebook을 만들 수 있었다. 2009년엔 안드로이드. 이로써 다양한 완성도 높은 플랫폼(윈도,아이폰,안드로이드, 웹)위에서 페북을 서비스해야했다. \n\n====\n\n이때부터 개발자들의 고통은 시작되었다. 생산성이 저하되었다. 새로운 기능이 나오면 이 4개의 플랫폼에 동시 런칭이 힘들었고 런칭이 느려졌고, 코드는 안좋아져만 갔다. \n\n====\n\n=같은 기능을 4번이나 반복하지 않는 방법= \n그렇다면 우린 이를 어떻게 극복했나? 네가지 중에서 가장 배포하기 쉬운것은? 웹이다. 여기 우리는 배포를 touch.facebook.com, m.facebook.com으로 나누어 개발하였다. webkit기반의 폰이면 터치로 가고 그렇지 않으면 M으로 간다. \n\n이 방식이 모든 폰에 최적의 경험을 주지는 못했다. 화면 내에 inline image나 css의 버전, 등의 문제가 있었다. 우리는 이 문제를 해결해야만 했다. \nXSL post processing등을 썼으나 좋지 않았음. 쨌든, 한번에 코드를 작성할 수 있는 방법을 강구해야한다. \n\n====\n\n=Progressive Enhancement혁신적인개선= \n우리가 한방법은 다음과 같다. \n방법의 초석은 당신이 가지고 있는 폰이 무엇을 할수 잇는냐를 인식하는 것이다. 그 기기의 capa가 제대로된 경험을 줄수 있도록 시작되는 시발점이다. \nWURFL(Wireless Universal Resources File, http://wurfl.sourceforge.net/)프로젝트는 user-agent에 따른 각 기기의 capa를 작성하는 프로젝트였다.(예를 들어, 화면크기? JS는? cookies는? 등)모두 해결해야만 하는 중요한 문제들이었다. \n이런 UserAgent마다의 정보를 우리가 모두 수집하는 것은 어려웠기에 opensource로 개방하고 모두의 협조를 구했고, 또 개방하였다. 그것이 WURFL프로젝트이다. \n\n일단 useragent와 그 각각의 capa를 알면, 무엇을 해야하는지도 알게 되는 것이다. 페북의 버튼이 HTML이거나 Javascript의 블락으로 이루어져 있지 않아도 된다는 것. 홈페이지에서 당신이 원하는 것은 버튼을 그릴 수 있는 컴포저라는거. 따라서 진짜 필요한 것은 버튼이다. 무엇이 렌더링 되어야 하는지를 알아야만 한다. 만약에 폰이 low-end(피쳐폰같이)폰이면 post form을 그리면 될 것이고, 폰이CSS를 쓸 수 있는 mid-range폰이면 CSS layer를 사용할 수 있다. 하지만 high-end폰일 경우에는 Ajax스타일의 경험을 사용할수도 있다. 이 기술은 야후의 blueprint플랫폼 (http://www.slideshare.net/blueprintblog/bp-dev-tutorial-mm-presentation) 과 같이 이미 개척을 한 사례도있다. 따라서 top-level에서 low-end까지의 기술적인 얘기를 하는 것 대신에, 할 수 있는 것을 결정할 화면을 렌더링 하는 마크업 선언 안의 컴포넌트각각에 대해서 알아볼 것이다. 이는 폰에서 이상적인 경험을 구성하기 위해서 구성되었다. 이 기술을 progressive enhancement라고 부른다. \n\n이는 곧 웹이라면 어드든 write once run anywhere할 수 있도록 방향을 잡게 되었따. 그리고 웹은 진짜 그리할수 있어 보였다. 데탑에서는 이미 그리하고 있고, 모바일에서도 이와 마찬가지로 진행할 수 있을 터. 하지만 안드로이드나 아이폰유저들은 훌륭한 모바일브라우저를 통해서 접근할 수 있다는 것에도 불구하고 웹이야기를 하면 지겨워할지도 모른다. \n\n따라서 4개의 레이어에서 1개를 제외하고 멋진 3개에 대해서만 촛점을 맞춰보자. 하지만 물론 모두가 아이폰에 대해 얘기하길 원할것이다. 아이폰을 예로들면, \n아이폰에서의 경험을 주기 위해서 Objective-C를 사용해야하거나 해야한다. 그렇다면 facebook뉴스피드도 정말 그러한가? 상단에 탑바가 있고 캐시로부터 바로 렌더링하고, 그게 전부다. 다른 기기에서도 그래야 하는가? 아니다. 다 같다 .\n이 같은것을 매번 3차례 개발할 필요는 없다는 것이다. \n\n=상상 이상으로 미친짓=\n그렇다면, 앱 내에 진짜 브라우저를 넣으면 어떨까? 미친 아이디어였다. 그때당시만 해도 미친생각이었다. 앱 내에서 브라우저를 가져올수있는 경우도 드물었기 때문. 3가지는 적어도 WebKit을 잘 구현해놓았다. 따라서, 시도를 했으나 정말 쉽지 않았다. \n\n====\n\n=Iterate Dailiy= \n이는 매일 배포를 할 수 있다. 앱스토어의 승인을 받느라 기다리지 않아도 되고 사용자들이 download받아주길 기다리지 않아도 된다. 매일 배포할 수 있다. \n아이폰,안드로이드폰 개발팀이 분리되어 있지 않아도 된다. 모두 같은 문제를 직면하고 같이 문제를 해결한다. 4번 배포를 하지 않고 1번 집중해서 배포를 한다. \n\n이는 Project FaceWeb이라 불리고 progressive enhancement아이디어의 확장이다. Webkit브라우저에 렌더링한다고 말하는 대신에, 우리가 아이폰 앱 내의 WebKit에다가 렌더링 할 것이라고 할 수 있다. 따라서 우리가 해야할 일은 기기를 감지하고 동작할 수 있도록 Web코드를 스타일링하고 네이티브앱과 소통하기 위해서 Objective-C를 짜서 Javascript와 통신하여 HTML로 페북페이지를 렌더링하도록 하면 되는것이다. 따라서 네이티브구현은 최소화 하는 것이다. \n\n=The Answer : 네이티브 앱 안에 Facebook Mobile을 싼다= \n기술적으로 이게 어떻게 돌아가는가? 아이폰에서 news feed버튼을 누른다. 만약 FaceWeb 가능한 기기면, native Web controller로 매핑시키지 않고 m.facebook.com/home.php를 가져온다. 단순히 웹 뷰를 보여주는 것이다. 이 웹뷰가 어떻게 Objective-C와 통신하는지 알아야한다. 따라서 해당 프레임에서 요구하는 "platform extraction call layer"를 명시한 JS skeleton을 회신한다. 그러면 다른 동작을 하고 home.php와 JavaScript를 로드한다. \n이는 기본적으로 m.facebook.com사이트를 만들고 Javascript를 폰의 네이티브기능(카페라 등 )들을 사용할 수 있는 abstraction layer를 둔다는 것이다. \n\n그 bridge에서 해야만하는 것은? 분명sensor와 data같은 것들이다. \nGPS를 알고싶다면 HTML5에서는 지원하지만 다 지원하지 않기 때문에 각 기기의 accelerometer나 orientation lock같은 것들을 참고해야한다. \nJavascript < query >Native, Camera플로우 등은 Native를 써야만 한다.\n\n=stick point : Web vs Native Design=\nmutating components : <m:button /> \n폰갭은 위에 그 문제를 해결해 주었다. 문제는 보여줄 수 있는 버튼이 하나면 절대 native스럽지 않게 보인다는 것. 두번째는 네이티브 느낌을 못준다는 것, 세번째는 빠르지 않다는 것이다. 이 세가지가 폰갭에서 얻은 것이다. \n\n첫번째 위임은, 이 일들을 HTML로 하고 싶다는 것, 뉴스피드의 경우 HTML로 보여주는 것과 네이티브로 보여주는 것에는 차이점이 없다는 것을 재차 강조. 이는 단순히 비주얼이라는 큰문제로 끝나지 않는다. 웹과 앱은 서로 잘 동작한다. 우리가 앱에 브라우저를 넣었을 때 사용자들은 한 경우를 제외하고는 전혀 불평하지 않앗다. \n\n그 한가지는 페이스북과 친한 iPad앱이다. 이는 단순히 m.site를 감싼 거다. 어떤 사용자들은 페이스북이 m.site를 대충 고쳐서 복사해 찍어냈다고 말한다. 실제로 m.site를 썼고 좋았다. 따라서 사실은 네이티브같이 보이지 않아고, 그것이 큰 문제가 되지 않았다. \n\n아직도 연구해야할게 남았다. position fix와 overflow scroll이 가장 큰 문제였다. 안드로이드 2.1이하에서는 전혀 방법이 없었고, 2.2에서는 작업을 시작했고 iOS5에서는 이 모든것을 구현해주기로 했다. 따라서 지금 웹앱을 시작하는것은 10개월 전보다 훨씩 수월할 것이다. CSS 그라디언트도 문제였고 이미지도 문제였다. 그 외에도 더 몇가지가 있다. \n\n=Web vs Native Feel : scroll=\n다른 문제는 네이티브느낌이 나지 않는다는 것이고 이는 대부분 스크롤할때이다. \n예를 들어 지우기 위해서 swipe를 하고 싶을때, 스크롤이 되어버린다. 이는 별문제 아니다. 스크롤 관련해서 GPU나 파이프라이닝이 네이티브에서는 잘 되어 있지만 HTML에서는 구현하기가 매우 힘들다. 대부분의 사람들이 네이티브 느낌이 나지 않다고 말하는 것은 스크롤을 할 때이다. \n\n종종 스크롤을 구현한다. iScroll잘 동작하고 Hewitts도 잘 동작한다. 따라서, JS라이브러리를 쓸 수도 있다. 또한 브라우저내에서의 이미지 확대축소와같은 것은 GPU를 쓰기 때문에 무리없이 할 수 있다. 그리고 이런 자잘한 것들은 문서화되어 있지 않다. 예를 들어 안드로이드나 아이폰에서 키보드가 보여지고 닫혀지지 않ㄴ,ㄴ것등. 시스템에서 정해진 그런자잘한 것들이 좀 있다. \n\n\n=Issue of Speed =\n마지막으로 한가지는 충분히 빠르지 않다는 것. 아이폰 앱에서 천천히 내리면 확인해볼 수 있음. \n\n따라서 방법은 명확히 pre-cache만이 살길이라는거. news feeds를 렌더링 한다고 치면, 버튼을 누르자마자 보여야 하는데 이를위해, 웹뷰를 캐시하는것이다. 그것이 동작하지 않을 경우 가장 좋은 방법은 사용자들을 속이는 것이다. 적어도 준비가 될때가지. 뼈대를 렌더링하고 캐시된 컨텐트로 채우고 그 다음엔 해로운 컨텐트를 보여주는 것이다. 적어도 사용자는 첫 응답이 왔기 때문에 변화를 인지하면 기다린다. \n\n퍼포먼스는 당신이 얼마나 JS를 많이 쓰는가에 대한 거다. 단순히 데이터를 로딩할 뿐만 아니라 더 무거운 pre-rendered된 만크업을 로딩한다. HTTP cache와 같은 경우 그리고 app cache와 같은 경우 그것들은 UI Web view에서 동작한다고 하지만 종종 그렇지 않다. 따라서 그 리소스들이 모두 여기서 만들어지는 확신할 수 있어야만 한다. \n\n=Taking The Approach everywhere= \n하지만, 안드로이드에서 잘 동작했다. 따라서 m.site와 같은식으로 만들 수 잇었다. news feed가 변경되거나 news feed가 추가되거나 comment가 추가되거나 모두 low-end인 m.site에 뿌려지고 high-end m.site에 뿌려지고 아이폰패북, 안드로이드패북에도 다음날이면 적용되었다. \n따라서, 우리는 이렇게 했고, 페북경험의 요소를 가지게 됬고 모든 것들 안에 브라우저가 삽입되었다. 특히 new feed나 당신의 프로필 타임라인과 같은 가장 자주 변하는 것들에 대해서는HTML을 바로 사용하였다. \n\n=어떻게 진화했는가 : HTML5 =\niOS3.4와 3.5에서 동작한다. news feed와 profile feed는 m.site로부터 소스를 가져온 것이다. 따라서, m.site가 변경되고 피처가 추가되면 그것이 적용된다. m.site가 장애가 생기면 모든 것이 뻑난다. 장단점이 있다는 것이다. iOS4.0에서 는 requests, notifications, search, list-style content가 네이티브를 쓰지 않고 FaceWeb을 사용하였다. 안드로이드 1.6, 1.7에서도 동일하게 진행. 피드백과 디자인은 꽤 좋았지만 버그들이 좀 많았다. Javascript 버전등이 맞지 않는다거나 문제가 생기면 빨리 고칠수 있다. \n따라서,미션은 한개의 코드베이스로부터 동작하고 세상의 모든 브라우저에 적용하는 것이다. 이는 페이스북에서 말하는 것 같지만 사실은 HTML5의 구호이다. \n\nHTML5가 아마도 우리가 하고자 하는 것일거다. 이는 HTML5가 물밑에서 변화되고 있기에 써야한다. 하이브리드 앱을 만다는 초기에는 HTML5에 잇는 특정한 것들은 준비되지 않아씅ㄹ 수 있지만 잊어버리라고 말하고 있다. 계속 전진하고 있다. 네이트브 핸들링이나 렌더링을 html5를 통해서 더 잘 대체해내루도 있고 in-browser기술(기기 접근, 좋은 native framework, applicatio 그리고 display code. \n\nWhat has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?\n\n=Device Access= \n따라서, 기기 접근이다. 기기 내에 제한된 정보를 가져오는 것이 그 예. Geolocation, network connectivity, obviously very big for caching, 카메라, 연락처,. geo-location. 이는 HTML5로 할 수 있고, 반대로 m.facebook.com에서 Places와 Deals 스터프를 기반으로 사용한다; network connectivity는 최근 생겨났고 최신 브라우저에서는 HTML5를 통해서 알 수 있다. 카메라와 주소들은 아직. 하지만 가져올수 있고 없는 것을 알고 싶다면, PhoneGap.com을 참고하길. 이 모든것들이 아직 과도기. \n\n\n= History= \nHistory를 개발할 수 있는 프레임워크가 네이티브에 존재. 이는 매우weired하다. 왜냐면 native stack 에 쌓여있고 이는 브라우저의 history와는 매우 다르기 때문. 브라우저는 히스토리를 다루는 방식이 매우 다르고 그 모델도 매우 다름. 히스토리 관리, client-side , threading은 중요. threading은 특히 중요. \n\nHTML5는 이 모든것을 통합할 수도 있음. history 관리를 위해 HTML5에는 좋은 기능이 있음. IndexDB와 client-side storage는 더덕 좋은 기능. WebWorkers같은 것이 다시 생기면 HTML5 에서 쓸수 있을 거다. \n\n=앱이 웹기술만들오 만들어질 수 있나? = \n결론적으로 중요한것은 웹기술만드으로 앱을 만들 수 잇냐는것이다. \n실제 웹 기술이 사용되고 당신도 사용하고 있다. 스크롤/리프레시/fast stuff등은 네이티브핸들러를 쓴다. 하지만 scrolling은 iOS5가 scrolling, position fixed overflow scorll을 만들어준 덕분에 네이티브를 쓴ㄴ 것은 옛날얘기가 되었따. 고정위치 header와 good scrolling은 네이티브만의 것이라고 생각하지만 이는 잘만들어진 JS와 새로운 framework들 덕분에 극복해낼수 있다는거. \n\njS엔진이 계속 좋아지고 있고, V8과 Nitro는 full-fledged JS로 objective c나 자바를 쓰지 않고 그에 상응하는 앱을 만들 수 있는 것을보여줬다. Netflix는 이미 이를 상품화 했다. \n\n따라서 빅 브라우저 제조사달의 긴급한 투자는 정말 정말 좋은 JS를 만드는 것. \nAnd if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have\n\n-----------------------------------------------------------------------------------------------------\n
  • http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php\n\n7.5억명의 AU(Active User)\\, stmart폰에서 feature폰까지 무수한 client들에서 모두 가용하다. \n모바일 개발은 2006년에 시작, m.facebook.com/webkit터치인터페이스에서 HTML5까지 활용중. \nfacebook 스파르판 프로젝트(http://www.slashgear.com/facebook-project-spartan-leaks-unveil-tipped-monday-with-ipad-app-29183916/, http://www.bloter.net/archives/64419(ko) )\n(스파르탄프로젝트 : 애플을 정면 겨냥한 모바일 앱 플랫폼. 페이스북 앱을 애플 앱스토어가 아닌 사파리 웹 브라우저의 모바일 버전에서 돌아가게 끔 하는 것. 스파르탄 프로젝트의 목표는 앱배포와관련해 애플의 통제를 벗어나는 것.)\n====\n=지난 5년에 걸치 모바일표준의 변화(HTML중심)= \n2006년까지만 해도 HTML과 SMS에 기반한 WAP서비스를 제공하였지만 20067년 iphone이란 큰 패러다임의 변화가 생겼고, 2007년 Facebook Platform API를 공개함. 아이폰이 생기면서 CSS, Javascript 리치한 경험을 줄 수 있었음. 블랙베리, 윈도우폰 노키아 ,삼성 등등이 facebook API로 구현이 가능했음. \n2008년엔 아이폰이 앱스토어를 열었다. 그때 처음으로 아이폰용 facebook을 만들 수 있었다. 2009년엔 안드로이드. 이로써 다양한 완성도 높은 플랫폼(윈도,아이폰,안드로이드, 웹)위에서 페북을 서비스해야했다. \n\n====\n\n이때부터 개발자들의 고통은 시작되었다. 생산성이 저하되었다. 새로운 기능이 나오면 이 4개의 플랫폼에 동시 런칭이 힘들었고 런칭이 느려졌고, 코드는 안좋아져만 갔다. \n\n====\n\n=같은 기능을 4번이나 반복하지 않는 방법= \n그렇다면 우린 이를 어떻게 극복했나? 네가지 중에서 가장 배포하기 쉬운것은? 웹이다. 여기 우리는 배포를 touch.facebook.com, m.facebook.com으로 나누어 개발하였다. webkit기반의 폰이면 터치로 가고 그렇지 않으면 M으로 간다. \n\n이 방식이 모든 폰에 최적의 경험을 주지는 못했다. 화면 내에 inline image나 css의 버전, 등의 문제가 있었다. 우리는 이 문제를 해결해야만 했다. \nXSL post processing등을 썼으나 좋지 않았음. 쨌든, 한번에 코드를 작성할 수 있는 방법을 강구해야한다. \n\n====\n\n=Progressive Enhancement혁신적인개선= \n우리가 한방법은 다음과 같다. \n방법의 초석은 당신이 가지고 있는 폰이 무엇을 할수 잇는냐를 인식하는 것이다. 그 기기의 capa가 제대로된 경험을 줄수 있도록 시작되는 시발점이다. \nWURFL(Wireless Universal Resources File, http://wurfl.sourceforge.net/)프로젝트는 user-agent에 따른 각 기기의 capa를 작성하는 프로젝트였다.(예를 들어, 화면크기? JS는? cookies는? 등)모두 해결해야만 하는 중요한 문제들이었다. \n이런 UserAgent마다의 정보를 우리가 모두 수집하는 것은 어려웠기에 opensource로 개방하고 모두의 협조를 구했고, 또 개방하였다. 그것이 WURFL프로젝트이다. \n\n일단 useragent와 그 각각의 capa를 알면, 무엇을 해야하는지도 알게 되는 것이다. 페북의 버튼이 HTML이거나 Javascript의 블락으로 이루어져 있지 않아도 된다는 것. 홈페이지에서 당신이 원하는 것은 버튼을 그릴 수 있는 컴포저라는거. 따라서 진짜 필요한 것은 버튼이다. 무엇이 렌더링 되어야 하는지를 알아야만 한다. 만약에 폰이 low-end(피쳐폰같이)폰이면 post form을 그리면 될 것이고, 폰이CSS를 쓸 수 있는 mid-range폰이면 CSS layer를 사용할 수 있다. 하지만 high-end폰일 경우에는 Ajax스타일의 경험을 사용할수도 있다. 이 기술은 야후의 blueprint플랫폼 (http://www.slideshare.net/blueprintblog/bp-dev-tutorial-mm-presentation) 과 같이 이미 개척을 한 사례도있다. 따라서 top-level에서 low-end까지의 기술적인 얘기를 하는 것 대신에, 할 수 있는 것을 결정할 화면을 렌더링 하는 마크업 선언 안의 컴포넌트각각에 대해서 알아볼 것이다. 이는 폰에서 이상적인 경험을 구성하기 위해서 구성되었다. 이 기술을 progressive enhancement라고 부른다. \n\n이는 곧 웹이라면 어드든 write once run anywhere할 수 있도록 방향을 잡게 되었따. 그리고 웹은 진짜 그리할수 있어 보였다. 데탑에서는 이미 그리하고 있고, 모바일에서도 이와 마찬가지로 진행할 수 있을 터. 하지만 안드로이드나 아이폰유저들은 훌륭한 모바일브라우저를 통해서 접근할 수 있다는 것에도 불구하고 웹이야기를 하면 지겨워할지도 모른다. \n\n따라서 4개의 레이어에서 1개를 제외하고 멋진 3개에 대해서만 촛점을 맞춰보자. 하지만 물론 모두가 아이폰에 대해 얘기하길 원할것이다. 아이폰을 예로들면, \n아이폰에서의 경험을 주기 위해서 Objective-C를 사용해야하거나 해야한다. 그렇다면 facebook뉴스피드도 정말 그러한가? 상단에 탑바가 있고 캐시로부터 바로 렌더링하고, 그게 전부다. 다른 기기에서도 그래야 하는가? 아니다. 다 같다 .\n이 같은것을 매번 3차례 개발할 필요는 없다는 것이다. \n\n=상상 이상으로 미친짓=\n그렇다면, 앱 내에 진짜 브라우저를 넣으면 어떨까? 미친 아이디어였다. 그때당시만 해도 미친생각이었다. 앱 내에서 브라우저를 가져올수있는 경우도 드물었기 때문. 3가지는 적어도 WebKit을 잘 구현해놓았다. 따라서, 시도를 했으나 정말 쉽지 않았다. \n\n====\n\n=Iterate Dailiy= \n이는 매일 배포를 할 수 있다. 앱스토어의 승인을 받느라 기다리지 않아도 되고 사용자들이 download받아주길 기다리지 않아도 된다. 매일 배포할 수 있다. \n아이폰,안드로이드폰 개발팀이 분리되어 있지 않아도 된다. 모두 같은 문제를 직면하고 같이 문제를 해결한다. 4번 배포를 하지 않고 1번 집중해서 배포를 한다. \n\n이는 Project FaceWeb이라 불리고 progressive enhancement아이디어의 확장이다. Webkit브라우저에 렌더링한다고 말하는 대신에, 우리가 아이폰 앱 내의 WebKit에다가 렌더링 할 것이라고 할 수 있다. 따라서 우리가 해야할 일은 기기를 감지하고 동작할 수 있도록 Web코드를 스타일링하고 네이티브앱과 소통하기 위해서 Objective-C를 짜서 Javascript와 통신하여 HTML로 페북페이지를 렌더링하도록 하면 되는것이다. 따라서 네이티브구현은 최소화 하는 것이다. \n\n=The Answer : 네이티브 앱 안에 Facebook Mobile을 싼다= \n기술적으로 이게 어떻게 돌아가는가? 아이폰에서 news feed버튼을 누른다. 만약 FaceWeb 가능한 기기면, native Web controller로 매핑시키지 않고 m.facebook.com/home.php를 가져온다. 단순히 웹 뷰를 보여주는 것이다. 이 웹뷰가 어떻게 Objective-C와 통신하는지 알아야한다. 따라서 해당 프레임에서 요구하는 "platform extraction call layer"를 명시한 JS skeleton을 회신한다. 그러면 다른 동작을 하고 home.php와 JavaScript를 로드한다. \n이는 기본적으로 m.facebook.com사이트를 만들고 Javascript를 폰의 네이티브기능(카페라 등 )들을 사용할 수 있는 abstraction layer를 둔다는 것이다. \n\n그 bridge에서 해야만하는 것은? 분명sensor와 data같은 것들이다. \nGPS를 알고싶다면 HTML5에서는 지원하지만 다 지원하지 않기 때문에 각 기기의 accelerometer나 orientation lock같은 것들을 참고해야한다. \nJavascript < query >Native, Camera플로우 등은 Native를 써야만 한다.\n\n=stick point : Web vs Native Design=\nmutating components : <m:button /> \n폰갭은 위에 그 문제를 해결해 주었다. 문제는 보여줄 수 있는 버튼이 하나면 절대 native스럽지 않게 보인다는 것. 두번째는 네이티브 느낌을 못준다는 것, 세번째는 빠르지 않다는 것이다. 이 세가지가 폰갭에서 얻은 것이다. \n\n첫번째 위임은, 이 일들을 HTML로 하고 싶다는 것, 뉴스피드의 경우 HTML로 보여주는 것과 네이티브로 보여주는 것에는 차이점이 없다는 것을 재차 강조. 이는 단순히 비주얼이라는 큰문제로 끝나지 않는다. 웹과 앱은 서로 잘 동작한다. 우리가 앱에 브라우저를 넣었을 때 사용자들은 한 경우를 제외하고는 전혀 불평하지 않앗다. \n\n그 한가지는 페이스북과 친한 iPad앱이다. 이는 단순히 m.site를 감싼 거다. 어떤 사용자들은 페이스북이 m.site를 대충 고쳐서 복사해 찍어냈다고 말한다. 실제로 m.site를 썼고 좋았다. 따라서 사실은 네이티브같이 보이지 않아고, 그것이 큰 문제가 되지 않았다. \n\n아직도 연구해야할게 남았다. position fix와 overflow scroll이 가장 큰 문제였다. 안드로이드 2.1이하에서는 전혀 방법이 없었고, 2.2에서는 작업을 시작했고 iOS5에서는 이 모든것을 구현해주기로 했다. 따라서 지금 웹앱을 시작하는것은 10개월 전보다 훨씩 수월할 것이다. CSS 그라디언트도 문제였고 이미지도 문제였다. 그 외에도 더 몇가지가 있다. \n\n=Web vs Native Feel : scroll=\n다른 문제는 네이티브느낌이 나지 않는다는 것이고 이는 대부분 스크롤할때이다. \n예를 들어 지우기 위해서 swipe를 하고 싶을때, 스크롤이 되어버린다. 이는 별문제 아니다. 스크롤 관련해서 GPU나 파이프라이닝이 네이티브에서는 잘 되어 있지만 HTML에서는 구현하기가 매우 힘들다. 대부분의 사람들이 네이티브 느낌이 나지 않다고 말하는 것은 스크롤을 할 때이다. \n\n종종 스크롤을 구현한다. iScroll잘 동작하고 Hewitts도 잘 동작한다. 따라서, JS라이브러리를 쓸 수도 있다. 또한 브라우저내에서의 이미지 확대축소와같은 것은 GPU를 쓰기 때문에 무리없이 할 수 있다. 그리고 이런 자잘한 것들은 문서화되어 있지 않다. 예를 들어 안드로이드나 아이폰에서 키보드가 보여지고 닫혀지지 않ㄴ,ㄴ것등. 시스템에서 정해진 그런자잘한 것들이 좀 있다. \n\n\n=Issue of Speed =\n마지막으로 한가지는 충분히 빠르지 않다는 것. 아이폰 앱에서 천천히 내리면 확인해볼 수 있음. \n\n따라서 방법은 명확히 pre-cache만이 살길이라는거. news feeds를 렌더링 한다고 치면, 버튼을 누르자마자 보여야 하는데 이를위해, 웹뷰를 캐시하는것이다. 그것이 동작하지 않을 경우 가장 좋은 방법은 사용자들을 속이는 것이다. 적어도 준비가 될때가지. 뼈대를 렌더링하고 캐시된 컨텐트로 채우고 그 다음엔 해로운 컨텐트를 보여주는 것이다. 적어도 사용자는 첫 응답이 왔기 때문에 변화를 인지하면 기다린다. \n\n퍼포먼스는 당신이 얼마나 JS를 많이 쓰는가에 대한 거다. 단순히 데이터를 로딩할 뿐만 아니라 더 무거운 pre-rendered된 만크업을 로딩한다. HTTP cache와 같은 경우 그리고 app cache와 같은 경우 그것들은 UI Web view에서 동작한다고 하지만 종종 그렇지 않다. 따라서 그 리소스들이 모두 여기서 만들어지는 확신할 수 있어야만 한다. \n\n=Taking The Approach everywhere= \n하지만, 안드로이드에서 잘 동작했다. 따라서 m.site와 같은식으로 만들 수 잇었다. news feed가 변경되거나 news feed가 추가되거나 comment가 추가되거나 모두 low-end인 m.site에 뿌려지고 high-end m.site에 뿌려지고 아이폰패북, 안드로이드패북에도 다음날이면 적용되었다. \n따라서, 우리는 이렇게 했고, 페북경험의 요소를 가지게 됬고 모든 것들 안에 브라우저가 삽입되었다. 특히 new feed나 당신의 프로필 타임라인과 같은 가장 자주 변하는 것들에 대해서는HTML을 바로 사용하였다. \n\n=어떻게 진화했는가 : HTML5 =\niOS3.4와 3.5에서 동작한다. news feed와 profile feed는 m.site로부터 소스를 가져온 것이다. 따라서, m.site가 변경되고 피처가 추가되면 그것이 적용된다. m.site가 장애가 생기면 모든 것이 뻑난다. 장단점이 있다는 것이다. iOS4.0에서 는 requests, notifications, search, list-style content가 네이티브를 쓰지 않고 FaceWeb을 사용하였다. 안드로이드 1.6, 1.7에서도 동일하게 진행. 피드백과 디자인은 꽤 좋았지만 버그들이 좀 많았다. Javascript 버전등이 맞지 않는다거나 문제가 생기면 빨리 고칠수 있다. \n따라서,미션은 한개의 코드베이스로부터 동작하고 세상의 모든 브라우저에 적용하는 것이다. 이는 페이스북에서 말하는 것 같지만 사실은 HTML5의 구호이다. \n\nHTML5가 아마도 우리가 하고자 하는 것일거다. 이는 HTML5가 물밑에서 변화되고 있기에 써야한다. 하이브리드 앱을 만다는 초기에는 HTML5에 잇는 특정한 것들은 준비되지 않아씅ㄹ 수 있지만 잊어버리라고 말하고 있다. 계속 전진하고 있다. 네이트브 핸들링이나 렌더링을 html5를 통해서 더 잘 대체해내루도 있고 in-browser기술(기기 접근, 좋은 native framework, applicatio 그리고 display code. \n\nWhat has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?\n\n=Device Access= \n따라서, 기기 접근이다. 기기 내에 제한된 정보를 가져오는 것이 그 예. Geolocation, network connectivity, obviously very big for caching, 카메라, 연락처,. geo-location. 이는 HTML5로 할 수 있고, 반대로 m.facebook.com에서 Places와 Deals 스터프를 기반으로 사용한다; network connectivity는 최근 생겨났고 최신 브라우저에서는 HTML5를 통해서 알 수 있다. 카메라와 주소들은 아직. 하지만 가져올수 있고 없는 것을 알고 싶다면, PhoneGap.com을 참고하길. 이 모든것들이 아직 과도기. \n\n\n= History= \nHistory를 개발할 수 있는 프레임워크가 네이티브에 존재. 이는 매우weired하다. 왜냐면 native stack 에 쌓여있고 이는 브라우저의 history와는 매우 다르기 때문. 브라우저는 히스토리를 다루는 방식이 매우 다르고 그 모델도 매우 다름. 히스토리 관리, client-side , threading은 중요. threading은 특히 중요. \n\nHTML5는 이 모든것을 통합할 수도 있음. history 관리를 위해 HTML5에는 좋은 기능이 있음. IndexDB와 client-side storage는 더덕 좋은 기능. WebWorkers같은 것이 다시 생기면 HTML5 에서 쓸수 있을 거다. \n\n=앱이 웹기술만들오 만들어질 수 있나? = \n결론적으로 중요한것은 웹기술만드으로 앱을 만들 수 잇냐는것이다. \n실제 웹 기술이 사용되고 당신도 사용하고 있다. 스크롤/리프레시/fast stuff등은 네이티브핸들러를 쓴다. 하지만 scrolling은 iOS5가 scrolling, position fixed overflow scorll을 만들어준 덕분에 네이티브를 쓴ㄴ 것은 옛날얘기가 되었따. 고정위치 header와 good scrolling은 네이티브만의 것이라고 생각하지만 이는 잘만들어진 JS와 새로운 framework들 덕분에 극복해낼수 있다는거. \n\njS엔진이 계속 좋아지고 있고, V8과 Nitro는 full-fledged JS로 objective c나 자바를 쓰지 않고 그에 상응하는 앱을 만들 수 있는 것을보여줬다. Netflix는 이미 이를 상품화 했다. \n\n따라서 빅 브라우저 제조사달의 긴급한 투자는 정말 정말 좋은 JS를 만드는 것. \nAnd if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have\n\n-----------------------------------------------------------------------------------------------------\n
  • http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php\n\n7.5억명의 AU(Active User)\\, stmart폰에서 feature폰까지 무수한 client들에서 모두 가용하다. \n모바일 개발은 2006년에 시작, m.facebook.com/webkit터치인터페이스에서 HTML5까지 활용중. \nfacebook 스파르판 프로젝트(http://www.slashgear.com/facebook-project-spartan-leaks-unveil-tipped-monday-with-ipad-app-29183916/, http://www.bloter.net/archives/64419(ko) )\n(스파르탄프로젝트 : 애플을 정면 겨냥한 모바일 앱 플랫폼. 페이스북 앱을 애플 앱스토어가 아닌 사파리 웹 브라우저의 모바일 버전에서 돌아가게 끔 하는 것. 스파르탄 프로젝트의 목표는 앱배포와관련해 애플의 통제를 벗어나는 것.)\n====\n=지난 5년에 걸치 모바일표준의 변화(HTML중심)= \n2006년까지만 해도 HTML과 SMS에 기반한 WAP서비스를 제공하였지만 20067년 iphone이란 큰 패러다임의 변화가 생겼고, 2007년 Facebook Platform API를 공개함. 아이폰이 생기면서 CSS, Javascript 리치한 경험을 줄 수 있었음. 블랙베리, 윈도우폰 노키아 ,삼성 등등이 facebook API로 구현이 가능했음. \n2008년엔 아이폰이 앱스토어를 열었다. 그때 처음으로 아이폰용 facebook을 만들 수 있었다. 2009년엔 안드로이드. 이로써 다양한 완성도 높은 플랫폼(윈도,아이폰,안드로이드, 웹)위에서 페북을 서비스해야했다. \n\n====\n\n이때부터 개발자들의 고통은 시작되었다. 생산성이 저하되었다. 새로운 기능이 나오면 이 4개의 플랫폼에 동시 런칭이 힘들었고 런칭이 느려졌고, 코드는 안좋아져만 갔다. \n\n====\n\n=같은 기능을 4번이나 반복하지 않는 방법= \n그렇다면 우린 이를 어떻게 극복했나? 네가지 중에서 가장 배포하기 쉬운것은? 웹이다. 여기 우리는 배포를 touch.facebook.com, m.facebook.com으로 나누어 개발하였다. webkit기반의 폰이면 터치로 가고 그렇지 않으면 M으로 간다. \n\n이 방식이 모든 폰에 최적의 경험을 주지는 못했다. 화면 내에 inline image나 css의 버전, 등의 문제가 있었다. 우리는 이 문제를 해결해야만 했다. \nXSL post processing등을 썼으나 좋지 않았음. 쨌든, 한번에 코드를 작성할 수 있는 방법을 강구해야한다. \n\n====\n\n=Progressive Enhancement혁신적인개선= \n우리가 한방법은 다음과 같다. \n방법의 초석은 당신이 가지고 있는 폰이 무엇을 할수 잇는냐를 인식하는 것이다. 그 기기의 capa가 제대로된 경험을 줄수 있도록 시작되는 시발점이다. \nWURFL(Wireless Universal Resources File, http://wurfl.sourceforge.net/)프로젝트는 user-agent에 따른 각 기기의 capa를 작성하는 프로젝트였다.(예를 들어, 화면크기? JS는? cookies는? 등)모두 해결해야만 하는 중요한 문제들이었다. \n이런 UserAgent마다의 정보를 우리가 모두 수집하는 것은 어려웠기에 opensource로 개방하고 모두의 협조를 구했고, 또 개방하였다. 그것이 WURFL프로젝트이다. \n\n일단 useragent와 그 각각의 capa를 알면, 무엇을 해야하는지도 알게 되는 것이다. 페북의 버튼이 HTML이거나 Javascript의 블락으로 이루어져 있지 않아도 된다는 것. 홈페이지에서 당신이 원하는 것은 버튼을 그릴 수 있는 컴포저라는거. 따라서 진짜 필요한 것은 버튼이다. 무엇이 렌더링 되어야 하는지를 알아야만 한다. 만약에 폰이 low-end(피쳐폰같이)폰이면 post form을 그리면 될 것이고, 폰이CSS를 쓸 수 있는 mid-range폰이면 CSS layer를 사용할 수 있다. 하지만 high-end폰일 경우에는 Ajax스타일의 경험을 사용할수도 있다. 이 기술은 야후의 blueprint플랫폼 (http://www.slideshare.net/blueprintblog/bp-dev-tutorial-mm-presentation) 과 같이 이미 개척을 한 사례도있다. 따라서 top-level에서 low-end까지의 기술적인 얘기를 하는 것 대신에, 할 수 있는 것을 결정할 화면을 렌더링 하는 마크업 선언 안의 컴포넌트각각에 대해서 알아볼 것이다. 이는 폰에서 이상적인 경험을 구성하기 위해서 구성되었다. 이 기술을 progressive enhancement라고 부른다. \n\n이는 곧 웹이라면 어드든 write once run anywhere할 수 있도록 방향을 잡게 되었따. 그리고 웹은 진짜 그리할수 있어 보였다. 데탑에서는 이미 그리하고 있고, 모바일에서도 이와 마찬가지로 진행할 수 있을 터. 하지만 안드로이드나 아이폰유저들은 훌륭한 모바일브라우저를 통해서 접근할 수 있다는 것에도 불구하고 웹이야기를 하면 지겨워할지도 모른다. \n\n따라서 4개의 레이어에서 1개를 제외하고 멋진 3개에 대해서만 촛점을 맞춰보자. 하지만 물론 모두가 아이폰에 대해 얘기하길 원할것이다. 아이폰을 예로들면, \n아이폰에서의 경험을 주기 위해서 Objective-C를 사용해야하거나 해야한다. 그렇다면 facebook뉴스피드도 정말 그러한가? 상단에 탑바가 있고 캐시로부터 바로 렌더링하고, 그게 전부다. 다른 기기에서도 그래야 하는가? 아니다. 다 같다 .\n이 같은것을 매번 3차례 개발할 필요는 없다는 것이다. \n\n=상상 이상으로 미친짓=\n그렇다면, 앱 내에 진짜 브라우저를 넣으면 어떨까? 미친 아이디어였다. 그때당시만 해도 미친생각이었다. 앱 내에서 브라우저를 가져올수있는 경우도 드물었기 때문. 3가지는 적어도 WebKit을 잘 구현해놓았다. 따라서, 시도를 했으나 정말 쉽지 않았다. \n\n====\n\n=Iterate Dailiy= \n이는 매일 배포를 할 수 있다. 앱스토어의 승인을 받느라 기다리지 않아도 되고 사용자들이 download받아주길 기다리지 않아도 된다. 매일 배포할 수 있다. \n아이폰,안드로이드폰 개발팀이 분리되어 있지 않아도 된다. 모두 같은 문제를 직면하고 같이 문제를 해결한다. 4번 배포를 하지 않고 1번 집중해서 배포를 한다. \n\n이는 Project FaceWeb이라 불리고 progressive enhancement아이디어의 확장이다. Webkit브라우저에 렌더링한다고 말하는 대신에, 우리가 아이폰 앱 내의 WebKit에다가 렌더링 할 것이라고 할 수 있다. 따라서 우리가 해야할 일은 기기를 감지하고 동작할 수 있도록 Web코드를 스타일링하고 네이티브앱과 소통하기 위해서 Objective-C를 짜서 Javascript와 통신하여 HTML로 페북페이지를 렌더링하도록 하면 되는것이다. 따라서 네이티브구현은 최소화 하는 것이다. \n\n=The Answer : 네이티브 앱 안에 Facebook Mobile을 싼다= \n기술적으로 이게 어떻게 돌아가는가? 아이폰에서 news feed버튼을 누른다. 만약 FaceWeb 가능한 기기면, native Web controller로 매핑시키지 않고 m.facebook.com/home.php를 가져온다. 단순히 웹 뷰를 보여주는 것이다. 이 웹뷰가 어떻게 Objective-C와 통신하는지 알아야한다. 따라서 해당 프레임에서 요구하는 "platform extraction call layer"를 명시한 JS skeleton을 회신한다. 그러면 다른 동작을 하고 home.php와 JavaScript를 로드한다. \n이는 기본적으로 m.facebook.com사이트를 만들고 Javascript를 폰의 네이티브기능(카페라 등 )들을 사용할 수 있는 abstraction layer를 둔다는 것이다. \n\n그 bridge에서 해야만하는 것은? 분명sensor와 data같은 것들이다. \nGPS를 알고싶다면 HTML5에서는 지원하지만 다 지원하지 않기 때문에 각 기기의 accelerometer나 orientation lock같은 것들을 참고해야한다. \nJavascript < query >Native, Camera플로우 등은 Native를 써야만 한다.\n\n=stick point : Web vs Native Design=\nmutating components : <m:button /> \n폰갭은 위에 그 문제를 해결해 주었다. 문제는 보여줄 수 있는 버튼이 하나면 절대 native스럽지 않게 보인다는 것. 두번째는 네이티브 느낌을 못준다는 것, 세번째는 빠르지 않다는 것이다. 이 세가지가 폰갭에서 얻은 것이다. \n\n첫번째 위임은, 이 일들을 HTML로 하고 싶다는 것, 뉴스피드의 경우 HTML로 보여주는 것과 네이티브로 보여주는 것에는 차이점이 없다는 것을 재차 강조. 이는 단순히 비주얼이라는 큰문제로 끝나지 않는다. 웹과 앱은 서로 잘 동작한다. 우리가 앱에 브라우저를 넣었을 때 사용자들은 한 경우를 제외하고는 전혀 불평하지 않앗다. \n\n그 한가지는 페이스북과 친한 iPad앱이다. 이는 단순히 m.site를 감싼 거다. 어떤 사용자들은 페이스북이 m.site를 대충 고쳐서 복사해 찍어냈다고 말한다. 실제로 m.site를 썼고 좋았다. 따라서 사실은 네이티브같이 보이지 않아고, 그것이 큰 문제가 되지 않았다. \n\n아직도 연구해야할게 남았다. position fix와 overflow scroll이 가장 큰 문제였다. 안드로이드 2.1이하에서는 전혀 방법이 없었고, 2.2에서는 작업을 시작했고 iOS5에서는 이 모든것을 구현해주기로 했다. 따라서 지금 웹앱을 시작하는것은 10개월 전보다 훨씩 수월할 것이다. CSS 그라디언트도 문제였고 이미지도 문제였다. 그 외에도 더 몇가지가 있다. \n\n=Web vs Native Feel : scroll=\n다른 문제는 네이티브느낌이 나지 않는다는 것이고 이는 대부분 스크롤할때이다. \n예를 들어 지우기 위해서 swipe를 하고 싶을때, 스크롤이 되어버린다. 이는 별문제 아니다. 스크롤 관련해서 GPU나 파이프라이닝이 네이티브에서는 잘 되어 있지만 HTML에서는 구현하기가 매우 힘들다. 대부분의 사람들이 네이티브 느낌이 나지 않다고 말하는 것은 스크롤을 할 때이다. \n\n종종 스크롤을 구현한다. iScroll잘 동작하고 Hewitts도 잘 동작한다. 따라서, JS라이브러리를 쓸 수도 있다. 또한 브라우저내에서의 이미지 확대축소와같은 것은 GPU를 쓰기 때문에 무리없이 할 수 있다. 그리고 이런 자잘한 것들은 문서화되어 있지 않다. 예를 들어 안드로이드나 아이폰에서 키보드가 보여지고 닫혀지지 않ㄴ,ㄴ것등. 시스템에서 정해진 그런자잘한 것들이 좀 있다. \n\n\n=Issue of Speed =\n마지막으로 한가지는 충분히 빠르지 않다는 것. 아이폰 앱에서 천천히 내리면 확인해볼 수 있음. \n\n따라서 방법은 명확히 pre-cache만이 살길이라는거. news feeds를 렌더링 한다고 치면, 버튼을 누르자마자 보여야 하는데 이를위해, 웹뷰를 캐시하는것이다. 그것이 동작하지 않을 경우 가장 좋은 방법은 사용자들을 속이는 것이다. 적어도 준비가 될때가지. 뼈대를 렌더링하고 캐시된 컨텐트로 채우고 그 다음엔 해로운 컨텐트를 보여주는 것이다. 적어도 사용자는 첫 응답이 왔기 때문에 변화를 인지하면 기다린다. \n\n퍼포먼스는 당신이 얼마나 JS를 많이 쓰는가에 대한 거다. 단순히 데이터를 로딩할 뿐만 아니라 더 무거운 pre-rendered된 만크업을 로딩한다. HTTP cache와 같은 경우 그리고 app cache와 같은 경우 그것들은 UI Web view에서 동작한다고 하지만 종종 그렇지 않다. 따라서 그 리소스들이 모두 여기서 만들어지는 확신할 수 있어야만 한다. \n\n=Taking The Approach everywhere= \n하지만, 안드로이드에서 잘 동작했다. 따라서 m.site와 같은식으로 만들 수 잇었다. news feed가 변경되거나 news feed가 추가되거나 comment가 추가되거나 모두 low-end인 m.site에 뿌려지고 high-end m.site에 뿌려지고 아이폰패북, 안드로이드패북에도 다음날이면 적용되었다. \n따라서, 우리는 이렇게 했고, 페북경험의 요소를 가지게 됬고 모든 것들 안에 브라우저가 삽입되었다. 특히 new feed나 당신의 프로필 타임라인과 같은 가장 자주 변하는 것들에 대해서는HTML을 바로 사용하였다. \n\n=어떻게 진화했는가 : HTML5 =\niOS3.4와 3.5에서 동작한다. news feed와 profile feed는 m.site로부터 소스를 가져온 것이다. 따라서, m.site가 변경되고 피처가 추가되면 그것이 적용된다. m.site가 장애가 생기면 모든 것이 뻑난다. 장단점이 있다는 것이다. iOS4.0에서 는 requests, notifications, search, list-style content가 네이티브를 쓰지 않고 FaceWeb을 사용하였다. 안드로이드 1.6, 1.7에서도 동일하게 진행. 피드백과 디자인은 꽤 좋았지만 버그들이 좀 많았다. Javascript 버전등이 맞지 않는다거나 문제가 생기면 빨리 고칠수 있다. \n따라서,미션은 한개의 코드베이스로부터 동작하고 세상의 모든 브라우저에 적용하는 것이다. 이는 페이스북에서 말하는 것 같지만 사실은 HTML5의 구호이다. \n\nHTML5가 아마도 우리가 하고자 하는 것일거다. 이는 HTML5가 물밑에서 변화되고 있기에 써야한다. 하이브리드 앱을 만다는 초기에는 HTML5에 잇는 특정한 것들은 준비되지 않아씅ㄹ 수 있지만 잊어버리라고 말하고 있다. 계속 전진하고 있다. 네이트브 핸들링이나 렌더링을 html5를 통해서 더 잘 대체해내루도 있고 in-browser기술(기기 접근, 좋은 native framework, applicatio 그리고 display code. \n\nWhat has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?\n\n=Device Access= \n따라서, 기기 접근이다. 기기 내에 제한된 정보를 가져오는 것이 그 예. Geolocation, network connectivity, obviously very big for caching, 카메라, 연락처,. geo-location. 이는 HTML5로 할 수 있고, 반대로 m.facebook.com에서 Places와 Deals 스터프를 기반으로 사용한다; network connectivity는 최근 생겨났고 최신 브라우저에서는 HTML5를 통해서 알 수 있다. 카메라와 주소들은 아직. 하지만 가져올수 있고 없는 것을 알고 싶다면, PhoneGap.com을 참고하길. 이 모든것들이 아직 과도기. \n\n\n= History= \nHistory를 개발할 수 있는 프레임워크가 네이티브에 존재. 이는 매우weired하다. 왜냐면 native stack 에 쌓여있고 이는 브라우저의 history와는 매우 다르기 때문. 브라우저는 히스토리를 다루는 방식이 매우 다르고 그 모델도 매우 다름. 히스토리 관리, client-side , threading은 중요. threading은 특히 중요. \n\nHTML5는 이 모든것을 통합할 수도 있음. history 관리를 위해 HTML5에는 좋은 기능이 있음. IndexDB와 client-side storage는 더덕 좋은 기능. WebWorkers같은 것이 다시 생기면 HTML5 에서 쓸수 있을 거다. \n\n=앱이 웹기술만들오 만들어질 수 있나? = \n결론적으로 중요한것은 웹기술만드으로 앱을 만들 수 잇냐는것이다. \n실제 웹 기술이 사용되고 당신도 사용하고 있다. 스크롤/리프레시/fast stuff등은 네이티브핸들러를 쓴다. 하지만 scrolling은 iOS5가 scrolling, position fixed overflow scorll을 만들어준 덕분에 네이티브를 쓴ㄴ 것은 옛날얘기가 되었따. 고정위치 header와 good scrolling은 네이티브만의 것이라고 생각하지만 이는 잘만들어진 JS와 새로운 framework들 덕분에 극복해낼수 있다는거. \n\njS엔진이 계속 좋아지고 있고, V8과 Nitro는 full-fledged JS로 objective c나 자바를 쓰지 않고 그에 상응하는 앱을 만들 수 있는 것을보여줬다. Netflix는 이미 이를 상품화 했다. \n\n따라서 빅 브라우저 제조사달의 긴급한 투자는 정말 정말 좋은 JS를 만드는 것. \nAnd if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have\n\n-----------------------------------------------------------------------------------------------------\n
  • http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php\n\n7.5억명의 AU(Active User)\\, stmart폰에서 feature폰까지 무수한 client들에서 모두 가용하다. \n모바일 개발은 2006년에 시작, m.facebook.com/webkit터치인터페이스에서 HTML5까지 활용중. \nfacebook 스파르판 프로젝트(http://www.slashgear.com/facebook-project-spartan-leaks-unveil-tipped-monday-with-ipad-app-29183916/, http://www.bloter.net/archives/64419(ko) )\n(스파르탄프로젝트 : 애플을 정면 겨냥한 모바일 앱 플랫폼. 페이스북 앱을 애플 앱스토어가 아닌 사파리 웹 브라우저의 모바일 버전에서 돌아가게 끔 하는 것. 스파르탄 프로젝트의 목표는 앱배포와관련해 애플의 통제를 벗어나는 것.)\n====\n=지난 5년에 걸치 모바일표준의 변화(HTML중심)= \n2006년까지만 해도 HTML과 SMS에 기반한 WAP서비스를 제공하였지만 20067년 iphone이란 큰 패러다임의 변화가 생겼고, 2007년 Facebook Platform API를 공개함. 아이폰이 생기면서 CSS, Javascript 리치한 경험을 줄 수 있었음. 블랙베리, 윈도우폰 노키아 ,삼성 등등이 facebook API로 구현이 가능했음. \n2008년엔 아이폰이 앱스토어를 열었다. 그때 처음으로 아이폰용 facebook을 만들 수 있었다. 2009년엔 안드로이드. 이로써 다양한 완성도 높은 플랫폼(윈도,아이폰,안드로이드, 웹)위에서 페북을 서비스해야했다. \n\n====\n\n이때부터 개발자들의 고통은 시작되었다. 생산성이 저하되었다. 새로운 기능이 나오면 이 4개의 플랫폼에 동시 런칭이 힘들었고 런칭이 느려졌고, 코드는 안좋아져만 갔다. \n\n====\n\n=같은 기능을 4번이나 반복하지 않는 방법= \n그렇다면 우린 이를 어떻게 극복했나? 네가지 중에서 가장 배포하기 쉬운것은? 웹이다. 여기 우리는 배포를 touch.facebook.com, m.facebook.com으로 나누어 개발하였다. webkit기반의 폰이면 터치로 가고 그렇지 않으면 M으로 간다. \n\n이 방식이 모든 폰에 최적의 경험을 주지는 못했다. 화면 내에 inline image나 css의 버전, 등의 문제가 있었다. 우리는 이 문제를 해결해야만 했다. \nXSL post processing등을 썼으나 좋지 않았음. 쨌든, 한번에 코드를 작성할 수 있는 방법을 강구해야한다. \n\n====\n\n=Progressive Enhancement혁신적인개선= \n우리가 한방법은 다음과 같다. \n방법의 초석은 당신이 가지고 있는 폰이 무엇을 할수 잇는냐를 인식하는 것이다. 그 기기의 capa가 제대로된 경험을 줄수 있도록 시작되는 시발점이다. \nWURFL(Wireless Universal Resources File, http://wurfl.sourceforge.net/)프로젝트는 user-agent에 따른 각 기기의 capa를 작성하는 프로젝트였다.(예를 들어, 화면크기? JS는? cookies는? 등)모두 해결해야만 하는 중요한 문제들이었다. \n이런 UserAgent마다의 정보를 우리가 모두 수집하는 것은 어려웠기에 opensource로 개방하고 모두의 협조를 구했고, 또 개방하였다. 그것이 WURFL프로젝트이다. \n\n일단 useragent와 그 각각의 capa를 알면, 무엇을 해야하는지도 알게 되는 것이다. 페북의 버튼이 HTML이거나 Javascript의 블락으로 이루어져 있지 않아도 된다는 것. 홈페이지에서 당신이 원하는 것은 버튼을 그릴 수 있는 컴포저라는거. 따라서 진짜 필요한 것은 버튼이다. 무엇이 렌더링 되어야 하는지를 알아야만 한다. 만약에 폰이 low-end(피쳐폰같이)폰이면 post form을 그리면 될 것이고, 폰이CSS를 쓸 수 있는 mid-range폰이면 CSS layer를 사용할 수 있다. 하지만 high-end폰일 경우에는 Ajax스타일의 경험을 사용할수도 있다. 이 기술은 야후의 blueprint플랫폼 (http://www.slideshare.net/blueprintblog/bp-dev-tutorial-mm-presentation) 과 같이 이미 개척을 한 사례도있다. 따라서 top-level에서 low-end까지의 기술적인 얘기를 하는 것 대신에, 할 수 있는 것을 결정할 화면을 렌더링 하는 마크업 선언 안의 컴포넌트각각에 대해서 알아볼 것이다. 이는 폰에서 이상적인 경험을 구성하기 위해서 구성되었다. 이 기술을 progressive enhancement라고 부른다. \n\n이는 곧 웹이라면 어드든 write once run anywhere할 수 있도록 방향을 잡게 되었따. 그리고 웹은 진짜 그리할수 있어 보였다. 데탑에서는 이미 그리하고 있고, 모바일에서도 이와 마찬가지로 진행할 수 있을 터. 하지만 안드로이드나 아이폰유저들은 훌륭한 모바일브라우저를 통해서 접근할 수 있다는 것에도 불구하고 웹이야기를 하면 지겨워할지도 모른다. \n\n따라서 4개의 레이어에서 1개를 제외하고 멋진 3개에 대해서만 촛점을 맞춰보자. 하지만 물론 모두가 아이폰에 대해 얘기하길 원할것이다. 아이폰을 예로들면, \n아이폰에서의 경험을 주기 위해서 Objective-C를 사용해야하거나 해야한다. 그렇다면 facebook뉴스피드도 정말 그러한가? 상단에 탑바가 있고 캐시로부터 바로 렌더링하고, 그게 전부다. 다른 기기에서도 그래야 하는가? 아니다. 다 같다 .\n이 같은것을 매번 3차례 개발할 필요는 없다는 것이다. \n\n=상상 이상으로 미친짓=\n그렇다면, 앱 내에 진짜 브라우저를 넣으면 어떨까? 미친 아이디어였다. 그때당시만 해도 미친생각이었다. 앱 내에서 브라우저를 가져올수있는 경우도 드물었기 때문. 3가지는 적어도 WebKit을 잘 구현해놓았다. 따라서, 시도를 했으나 정말 쉽지 않았다. \n\n====\n\n=Iterate Dailiy= \n이는 매일 배포를 할 수 있다. 앱스토어의 승인을 받느라 기다리지 않아도 되고 사용자들이 download받아주길 기다리지 않아도 된다. 매일 배포할 수 있다. \n아이폰,안드로이드폰 개발팀이 분리되어 있지 않아도 된다. 모두 같은 문제를 직면하고 같이 문제를 해결한다. 4번 배포를 하지 않고 1번 집중해서 배포를 한다. \n\n이는 Project FaceWeb이라 불리고 progressive enhancement아이디어의 확장이다. Webkit브라우저에 렌더링한다고 말하는 대신에, 우리가 아이폰 앱 내의 WebKit에다가 렌더링 할 것이라고 할 수 있다. 따라서 우리가 해야할 일은 기기를 감지하고 동작할 수 있도록 Web코드를 스타일링하고 네이티브앱과 소통하기 위해서 Objective-C를 짜서 Javascript와 통신하여 HTML로 페북페이지를 렌더링하도록 하면 되는것이다. 따라서 네이티브구현은 최소화 하는 것이다. \n\n=The Answer : 네이티브 앱 안에 Facebook Mobile을 싼다= \n기술적으로 이게 어떻게 돌아가는가? 아이폰에서 news feed버튼을 누른다. 만약 FaceWeb 가능한 기기면, native Web controller로 매핑시키지 않고 m.facebook.com/home.php를 가져온다. 단순히 웹 뷰를 보여주는 것이다. 이 웹뷰가 어떻게 Objective-C와 통신하는지 알아야한다. 따라서 해당 프레임에서 요구하는 "platform extraction call layer"를 명시한 JS skeleton을 회신한다. 그러면 다른 동작을 하고 home.php와 JavaScript를 로드한다. \n이는 기본적으로 m.facebook.com사이트를 만들고 Javascript를 폰의 네이티브기능(카페라 등 )들을 사용할 수 있는 abstraction layer를 둔다는 것이다. \n\n그 bridge에서 해야만하는 것은? 분명sensor와 data같은 것들이다. \nGPS를 알고싶다면 HTML5에서는 지원하지만 다 지원하지 않기 때문에 각 기기의 accelerometer나 orientation lock같은 것들을 참고해야한다. \nJavascript < query >Native, Camera플로우 등은 Native를 써야만 한다.\n\n=stick point : Web vs Native Design=\nmutating components : <m:button /> \n폰갭은 위에 그 문제를 해결해 주었다. 문제는 보여줄 수 있는 버튼이 하나면 절대 native스럽지 않게 보인다는 것. 두번째는 네이티브 느낌을 못준다는 것, 세번째는 빠르지 않다는 것이다. 이 세가지가 폰갭에서 얻은 것이다. \n\n첫번째 위임은, 이 일들을 HTML로 하고 싶다는 것, 뉴스피드의 경우 HTML로 보여주는 것과 네이티브로 보여주는 것에는 차이점이 없다는 것을 재차 강조. 이는 단순히 비주얼이라는 큰문제로 끝나지 않는다. 웹과 앱은 서로 잘 동작한다. 우리가 앱에 브라우저를 넣었을 때 사용자들은 한 경우를 제외하고는 전혀 불평하지 않앗다. \n\n그 한가지는 페이스북과 친한 iPad앱이다. 이는 단순히 m.site를 감싼 거다. 어떤 사용자들은 페이스북이 m.site를 대충 고쳐서 복사해 찍어냈다고 말한다. 실제로 m.site를 썼고 좋았다. 따라서 사실은 네이티브같이 보이지 않아고, 그것이 큰 문제가 되지 않았다. \n\n아직도 연구해야할게 남았다. position fix와 overflow scroll이 가장 큰 문제였다. 안드로이드 2.1이하에서는 전혀 방법이 없었고, 2.2에서는 작업을 시작했고 iOS5에서는 이 모든것을 구현해주기로 했다. 따라서 지금 웹앱을 시작하는것은 10개월 전보다 훨씩 수월할 것이다. CSS 그라디언트도 문제였고 이미지도 문제였다. 그 외에도 더 몇가지가 있다. \n\n=Web vs Native Feel : scroll=\n다른 문제는 네이티브느낌이 나지 않는다는 것이고 이는 대부분 스크롤할때이다. \n예를 들어 지우기 위해서 swipe를 하고 싶을때, 스크롤이 되어버린다. 이는 별문제 아니다. 스크롤 관련해서 GPU나 파이프라이닝이 네이티브에서는 잘 되어 있지만 HTML에서는 구현하기가 매우 힘들다. 대부분의 사람들이 네이티브 느낌이 나지 않다고 말하는 것은 스크롤을 할 때이다. \n\n종종 스크롤을 구현한다. iScroll잘 동작하고 Hewitts도 잘 동작한다. 따라서, JS라이브러리를 쓸 수도 있다. 또한 브라우저내에서의 이미지 확대축소와같은 것은 GPU를 쓰기 때문에 무리없이 할 수 있다. 그리고 이런 자잘한 것들은 문서화되어 있지 않다. 예를 들어 안드로이드나 아이폰에서 키보드가 보여지고 닫혀지지 않ㄴ,ㄴ것등. 시스템에서 정해진 그런자잘한 것들이 좀 있다. \n\n\n=Issue of Speed =\n마지막으로 한가지는 충분히 빠르지 않다는 것. 아이폰 앱에서 천천히 내리면 확인해볼 수 있음. \n\n따라서 방법은 명확히 pre-cache만이 살길이라는거. news feeds를 렌더링 한다고 치면, 버튼을 누르자마자 보여야 하는데 이를위해, 웹뷰를 캐시하는것이다. 그것이 동작하지 않을 경우 가장 좋은 방법은 사용자들을 속이는 것이다. 적어도 준비가 될때가지. 뼈대를 렌더링하고 캐시된 컨텐트로 채우고 그 다음엔 해로운 컨텐트를 보여주는 것이다. 적어도 사용자는 첫 응답이 왔기 때문에 변화를 인지하면 기다린다. \n\n퍼포먼스는 당신이 얼마나 JS를 많이 쓰는가에 대한 거다. 단순히 데이터를 로딩할 뿐만 아니라 더 무거운 pre-rendered된 만크업을 로딩한다. HTTP cache와 같은 경우 그리고 app cache와 같은 경우 그것들은 UI Web view에서 동작한다고 하지만 종종 그렇지 않다. 따라서 그 리소스들이 모두 여기서 만들어지는 확신할 수 있어야만 한다. \n\n=Taking The Approach everywhere= \n하지만, 안드로이드에서 잘 동작했다. 따라서 m.site와 같은식으로 만들 수 잇었다. news feed가 변경되거나 news feed가 추가되거나 comment가 추가되거나 모두 low-end인 m.site에 뿌려지고 high-end m.site에 뿌려지고 아이폰패북, 안드로이드패북에도 다음날이면 적용되었다. \n따라서, 우리는 이렇게 했고, 페북경험의 요소를 가지게 됬고 모든 것들 안에 브라우저가 삽입되었다. 특히 new feed나 당신의 프로필 타임라인과 같은 가장 자주 변하는 것들에 대해서는HTML을 바로 사용하였다. \n\n=어떻게 진화했는가 : HTML5 =\niOS3.4와 3.5에서 동작한다. news feed와 profile feed는 m.site로부터 소스를 가져온 것이다. 따라서, m.site가 변경되고 피처가 추가되면 그것이 적용된다. m.site가 장애가 생기면 모든 것이 뻑난다. 장단점이 있다는 것이다. iOS4.0에서 는 requests, notifications, search, list-style content가 네이티브를 쓰지 않고 FaceWeb을 사용하였다. 안드로이드 1.6, 1.7에서도 동일하게 진행. 피드백과 디자인은 꽤 좋았지만 버그들이 좀 많았다. Javascript 버전등이 맞지 않는다거나 문제가 생기면 빨리 고칠수 있다. \n따라서,미션은 한개의 코드베이스로부터 동작하고 세상의 모든 브라우저에 적용하는 것이다. 이는 페이스북에서 말하는 것 같지만 사실은 HTML5의 구호이다. \n\nHTML5가 아마도 우리가 하고자 하는 것일거다. 이는 HTML5가 물밑에서 변화되고 있기에 써야한다. 하이브리드 앱을 만다는 초기에는 HTML5에 잇는 특정한 것들은 준비되지 않아씅ㄹ 수 있지만 잊어버리라고 말하고 있다. 계속 전진하고 있다. 네이트브 핸들링이나 렌더링을 html5를 통해서 더 잘 대체해내루도 있고 in-browser기술(기기 접근, 좋은 native framework, applicatio 그리고 display code. \n\nWhat has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?\n\n=Device Access= \n따라서, 기기 접근이다. 기기 내에 제한된 정보를 가져오는 것이 그 예. Geolocation, network connectivity, obviously very big for caching, 카메라, 연락처,. geo-location. 이는 HTML5로 할 수 있고, 반대로 m.facebook.com에서 Places와 Deals 스터프를 기반으로 사용한다; network connectivity는 최근 생겨났고 최신 브라우저에서는 HTML5를 통해서 알 수 있다. 카메라와 주소들은 아직. 하지만 가져올수 있고 없는 것을 알고 싶다면, PhoneGap.com을 참고하길. 이 모든것들이 아직 과도기. \n\n\n= History= \nHistory를 개발할 수 있는 프레임워크가 네이티브에 존재. 이는 매우weired하다. 왜냐면 native stack 에 쌓여있고 이는 브라우저의 history와는 매우 다르기 때문. 브라우저는 히스토리를 다루는 방식이 매우 다르고 그 모델도 매우 다름. 히스토리 관리, client-side , threading은 중요. threading은 특히 중요. \n\nHTML5는 이 모든것을 통합할 수도 있음. history 관리를 위해 HTML5에는 좋은 기능이 있음. IndexDB와 client-side storage는 더덕 좋은 기능. WebWorkers같은 것이 다시 생기면 HTML5 에서 쓸수 있을 거다. \n\n=앱이 웹기술만들오 만들어질 수 있나? = \n결론적으로 중요한것은 웹기술만드으로 앱을 만들 수 잇냐는것이다. \n실제 웹 기술이 사용되고 당신도 사용하고 있다. 스크롤/리프레시/fast stuff등은 네이티브핸들러를 쓴다. 하지만 scrolling은 iOS5가 scrolling, position fixed overflow scorll을 만들어준 덕분에 네이티브를 쓴ㄴ 것은 옛날얘기가 되었따. 고정위치 header와 good scrolling은 네이티브만의 것이라고 생각하지만 이는 잘만들어진 JS와 새로운 framework들 덕분에 극복해낼수 있다는거. \n\njS엔진이 계속 좋아지고 있고, V8과 Nitro는 full-fledged JS로 objective c나 자바를 쓰지 않고 그에 상응하는 앱을 만들 수 있는 것을보여줬다. Netflix는 이미 이를 상품화 했다. \n\n따라서 빅 브라우저 제조사달의 긴급한 투자는 정말 정말 좋은 JS를 만드는 것. \nAnd if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have\n\n-----------------------------------------------------------------------------------------------------\n
  • http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php\n\n7.5억명의 AU(Active User)\\, stmart폰에서 feature폰까지 무수한 client들에서 모두 가용하다. \n모바일 개발은 2006년에 시작, m.facebook.com/webkit터치인터페이스에서 HTML5까지 활용중. \nfacebook 스파르판 프로젝트(http://www.slashgear.com/facebook-project-spartan-leaks-unveil-tipped-monday-with-ipad-app-29183916/, http://www.bloter.net/archives/64419(ko) )\n(스파르탄프로젝트 : 애플을 정면 겨냥한 모바일 앱 플랫폼. 페이스북 앱을 애플 앱스토어가 아닌 사파리 웹 브라우저의 모바일 버전에서 돌아가게 끔 하는 것. 스파르탄 프로젝트의 목표는 앱배포와관련해 애플의 통제를 벗어나는 것.)\n====\n=지난 5년에 걸치 모바일표준의 변화(HTML중심)= \n2006년까지만 해도 HTML과 SMS에 기반한 WAP서비스를 제공하였지만 20067년 iphone이란 큰 패러다임의 변화가 생겼고, 2007년 Facebook Platform API를 공개함. 아이폰이 생기면서 CSS, Javascript 리치한 경험을 줄 수 있었음. 블랙베리, 윈도우폰 노키아 ,삼성 등등이 facebook API로 구현이 가능했음. \n2008년엔 아이폰이 앱스토어를 열었다. 그때 처음으로 아이폰용 facebook을 만들 수 있었다. 2009년엔 안드로이드. 이로써 다양한 완성도 높은 플랫폼(윈도,아이폰,안드로이드, 웹)위에서 페북을 서비스해야했다. \n\n====\n\n이때부터 개발자들의 고통은 시작되었다. 생산성이 저하되었다. 새로운 기능이 나오면 이 4개의 플랫폼에 동시 런칭이 힘들었고 런칭이 느려졌고, 코드는 안좋아져만 갔다. \n\n====\n\n=같은 기능을 4번이나 반복하지 않는 방법= \n그렇다면 우린 이를 어떻게 극복했나? 네가지 중에서 가장 배포하기 쉬운것은? 웹이다. 여기 우리는 배포를 touch.facebook.com, m.facebook.com으로 나누어 개발하였다. webkit기반의 폰이면 터치로 가고 그렇지 않으면 M으로 간다. \n\n이 방식이 모든 폰에 최적의 경험을 주지는 못했다. 화면 내에 inline image나 css의 버전, 등의 문제가 있었다. 우리는 이 문제를 해결해야만 했다. \nXSL post processing등을 썼으나 좋지 않았음. 쨌든, 한번에 코드를 작성할 수 있는 방법을 강구해야한다. \n\n====\n\n=Progressive Enhancement혁신적인개선= \n우리가 한방법은 다음과 같다. \n방법의 초석은 당신이 가지고 있는 폰이 무엇을 할수 잇는냐를 인식하는 것이다. 그 기기의 capa가 제대로된 경험을 줄수 있도록 시작되는 시발점이다. \nWURFL(Wireless Universal Resources File, http://wurfl.sourceforge.net/)프로젝트는 user-agent에 따른 각 기기의 capa를 작성하는 프로젝트였다.(예를 들어, 화면크기? JS는? cookies는? 등)모두 해결해야만 하는 중요한 문제들이었다. \n이런 UserAgent마다의 정보를 우리가 모두 수집하는 것은 어려웠기에 opensource로 개방하고 모두의 협조를 구했고, 또 개방하였다. 그것이 WURFL프로젝트이다. \n\n일단 useragent와 그 각각의 capa를 알면, 무엇을 해야하는지도 알게 되는 것이다. 페북의 버튼이 HTML이거나 Javascript의 블락으로 이루어져 있지 않아도 된다는 것. 홈페이지에서 당신이 원하는 것은 버튼을 그릴 수 있는 컴포저라는거. 따라서 진짜 필요한 것은 버튼이다. 무엇이 렌더링 되어야 하는지를 알아야만 한다. 만약에 폰이 low-end(피쳐폰같이)폰이면 post form을 그리면 될 것이고, 폰이CSS를 쓸 수 있는 mid-range폰이면 CSS layer를 사용할 수 있다. 하지만 high-end폰일 경우에는 Ajax스타일의 경험을 사용할수도 있다. 이 기술은 야후의 blueprint플랫폼 (http://www.slideshare.net/blueprintblog/bp-dev-tutorial-mm-presentation) 과 같이 이미 개척을 한 사례도있다. 따라서 top-level에서 low-end까지의 기술적인 얘기를 하는 것 대신에, 할 수 있는 것을 결정할 화면을 렌더링 하는 마크업 선언 안의 컴포넌트각각에 대해서 알아볼 것이다. 이는 폰에서 이상적인 경험을 구성하기 위해서 구성되었다. 이 기술을 progressive enhancement라고 부른다. \n\n이는 곧 웹이라면 어드든 write once run anywhere할 수 있도록 방향을 잡게 되었따. 그리고 웹은 진짜 그리할수 있어 보였다. 데탑에서는 이미 그리하고 있고, 모바일에서도 이와 마찬가지로 진행할 수 있을 터. 하지만 안드로이드나 아이폰유저들은 훌륭한 모바일브라우저를 통해서 접근할 수 있다는 것에도 불구하고 웹이야기를 하면 지겨워할지도 모른다. \n\n따라서 4개의 레이어에서 1개를 제외하고 멋진 3개에 대해서만 촛점을 맞춰보자. 하지만 물론 모두가 아이폰에 대해 얘기하길 원할것이다. 아이폰을 예로들면, \n아이폰에서의 경험을 주기 위해서 Objective-C를 사용해야하거나 해야한다. 그렇다면 facebook뉴스피드도 정말 그러한가? 상단에 탑바가 있고 캐시로부터 바로 렌더링하고, 그게 전부다. 다른 기기에서도 그래야 하는가? 아니다. 다 같다 .\n이 같은것을 매번 3차례 개발할 필요는 없다는 것이다. \n\n=상상 이상으로 미친짓=\n그렇다면, 앱 내에 진짜 브라우저를 넣으면 어떨까? 미친 아이디어였다. 그때당시만 해도 미친생각이었다. 앱 내에서 브라우저를 가져올수있는 경우도 드물었기 때문. 3가지는 적어도 WebKit을 잘 구현해놓았다. 따라서, 시도를 했으나 정말 쉽지 않았다. \n\n====\n\n=Iterate Dailiy= \n이는 매일 배포를 할 수 있다. 앱스토어의 승인을 받느라 기다리지 않아도 되고 사용자들이 download받아주길 기다리지 않아도 된다. 매일 배포할 수 있다. \n아이폰,안드로이드폰 개발팀이 분리되어 있지 않아도 된다. 모두 같은 문제를 직면하고 같이 문제를 해결한다. 4번 배포를 하지 않고 1번 집중해서 배포를 한다. \n\n이는 Project FaceWeb이라 불리고 progressive enhancement아이디어의 확장이다. Webkit브라우저에 렌더링한다고 말하는 대신에, 우리가 아이폰 앱 내의 WebKit에다가 렌더링 할 것이라고 할 수 있다. 따라서 우리가 해야할 일은 기기를 감지하고 동작할 수 있도록 Web코드를 스타일링하고 네이티브앱과 소통하기 위해서 Objective-C를 짜서 Javascript와 통신하여 HTML로 페북페이지를 렌더링하도록 하면 되는것이다. 따라서 네이티브구현은 최소화 하는 것이다. \n\n=The Answer : 네이티브 앱 안에 Facebook Mobile을 싼다= \n기술적으로 이게 어떻게 돌아가는가? 아이폰에서 news feed버튼을 누른다. 만약 FaceWeb 가능한 기기면, native Web controller로 매핑시키지 않고 m.facebook.com/home.php를 가져온다. 단순히 웹 뷰를 보여주는 것이다. 이 웹뷰가 어떻게 Objective-C와 통신하는지 알아야한다. 따라서 해당 프레임에서 요구하는 "platform extraction call layer"를 명시한 JS skeleton을 회신한다. 그러면 다른 동작을 하고 home.php와 JavaScript를 로드한다. \n이는 기본적으로 m.facebook.com사이트를 만들고 Javascript를 폰의 네이티브기능(카페라 등 )들을 사용할 수 있는 abstraction layer를 둔다는 것이다. \n\n그 bridge에서 해야만하는 것은? 분명sensor와 data같은 것들이다. \nGPS를 알고싶다면 HTML5에서는 지원하지만 다 지원하지 않기 때문에 각 기기의 accelerometer나 orientation lock같은 것들을 참고해야한다. \nJavascript < query >Native, Camera플로우 등은 Native를 써야만 한다.\n\n=stick point : Web vs Native Design=\nmutating components : <m:button /> \n폰갭은 위에 그 문제를 해결해 주었다. 문제는 보여줄 수 있는 버튼이 하나면 절대 native스럽지 않게 보인다는 것. 두번째는 네이티브 느낌을 못준다는 것, 세번째는 빠르지 않다는 것이다. 이 세가지가 폰갭에서 얻은 것이다. \n\n첫번째 위임은, 이 일들을 HTML로 하고 싶다는 것, 뉴스피드의 경우 HTML로 보여주는 것과 네이티브로 보여주는 것에는 차이점이 없다는 것을 재차 강조. 이는 단순히 비주얼이라는 큰문제로 끝나지 않는다. 웹과 앱은 서로 잘 동작한다. 우리가 앱에 브라우저를 넣었을 때 사용자들은 한 경우를 제외하고는 전혀 불평하지 않앗다. \n\n그 한가지는 페이스북과 친한 iPad앱이다. 이는 단순히 m.site를 감싼 거다. 어떤 사용자들은 페이스북이 m.site를 대충 고쳐서 복사해 찍어냈다고 말한다. 실제로 m.site를 썼고 좋았다. 따라서 사실은 네이티브같이 보이지 않아고, 그것이 큰 문제가 되지 않았다. \n\n아직도 연구해야할게 남았다. position fix와 overflow scroll이 가장 큰 문제였다. 안드로이드 2.1이하에서는 전혀 방법이 없었고, 2.2에서는 작업을 시작했고 iOS5에서는 이 모든것을 구현해주기로 했다. 따라서 지금 웹앱을 시작하는것은 10개월 전보다 훨씩 수월할 것이다. CSS 그라디언트도 문제였고 이미지도 문제였다. 그 외에도 더 몇가지가 있다. \n\n=Web vs Native Feel : scroll=\n다른 문제는 네이티브느낌이 나지 않는다는 것이고 이는 대부분 스크롤할때이다. \n예를 들어 지우기 위해서 swipe를 하고 싶을때, 스크롤이 되어버린다. 이는 별문제 아니다. 스크롤 관련해서 GPU나 파이프라이닝이 네이티브에서는 잘 되어 있지만 HTML에서는 구현하기가 매우 힘들다. 대부분의 사람들이 네이티브 느낌이 나지 않다고 말하는 것은 스크롤을 할 때이다. \n\n종종 스크롤을 구현한다. iScroll잘 동작하고 Hewitts도 잘 동작한다. 따라서, JS라이브러리를 쓸 수도 있다. 또한 브라우저내에서의 이미지 확대축소와같은 것은 GPU를 쓰기 때문에 무리없이 할 수 있다. 그리고 이런 자잘한 것들은 문서화되어 있지 않다. 예를 들어 안드로이드나 아이폰에서 키보드가 보여지고 닫혀지지 않ㄴ,ㄴ것등. 시스템에서 정해진 그런자잘한 것들이 좀 있다. \n\n\n=Issue of Speed =\n마지막으로 한가지는 충분히 빠르지 않다는 것. 아이폰 앱에서 천천히 내리면 확인해볼 수 있음. \n\n따라서 방법은 명확히 pre-cache만이 살길이라는거. news feeds를 렌더링 한다고 치면, 버튼을 누르자마자 보여야 하는데 이를위해, 웹뷰를 캐시하는것이다. 그것이 동작하지 않을 경우 가장 좋은 방법은 사용자들을 속이는 것이다. 적어도 준비가 될때가지. 뼈대를 렌더링하고 캐시된 컨텐트로 채우고 그 다음엔 해로운 컨텐트를 보여주는 것이다. 적어도 사용자는 첫 응답이 왔기 때문에 변화를 인지하면 기다린다. \n\n퍼포먼스는 당신이 얼마나 JS를 많이 쓰는가에 대한 거다. 단순히 데이터를 로딩할 뿐만 아니라 더 무거운 pre-rendered된 만크업을 로딩한다. HTTP cache와 같은 경우 그리고 app cache와 같은 경우 그것들은 UI Web view에서 동작한다고 하지만 종종 그렇지 않다. 따라서 그 리소스들이 모두 여기서 만들어지는 확신할 수 있어야만 한다. \n\n=Taking The Approach everywhere= \n하지만, 안드로이드에서 잘 동작했다. 따라서 m.site와 같은식으로 만들 수 잇었다. news feed가 변경되거나 news feed가 추가되거나 comment가 추가되거나 모두 low-end인 m.site에 뿌려지고 high-end m.site에 뿌려지고 아이폰패북, 안드로이드패북에도 다음날이면 적용되었다. \n따라서, 우리는 이렇게 했고, 페북경험의 요소를 가지게 됬고 모든 것들 안에 브라우저가 삽입되었다. 특히 new feed나 당신의 프로필 타임라인과 같은 가장 자주 변하는 것들에 대해서는HTML을 바로 사용하였다. \n\n=어떻게 진화했는가 : HTML5 =\niOS3.4와 3.5에서 동작한다. news feed와 profile feed는 m.site로부터 소스를 가져온 것이다. 따라서, m.site가 변경되고 피처가 추가되면 그것이 적용된다. m.site가 장애가 생기면 모든 것이 뻑난다. 장단점이 있다는 것이다. iOS4.0에서 는 requests, notifications, search, list-style content가 네이티브를 쓰지 않고 FaceWeb을 사용하였다. 안드로이드 1.6, 1.7에서도 동일하게 진행. 피드백과 디자인은 꽤 좋았지만 버그들이 좀 많았다. Javascript 버전등이 맞지 않는다거나 문제가 생기면 빨리 고칠수 있다. \n따라서,미션은 한개의 코드베이스로부터 동작하고 세상의 모든 브라우저에 적용하는 것이다. 이는 페이스북에서 말하는 것 같지만 사실은 HTML5의 구호이다. \n\nHTML5가 아마도 우리가 하고자 하는 것일거다. 이는 HTML5가 물밑에서 변화되고 있기에 써야한다. 하이브리드 앱을 만다는 초기에는 HTML5에 잇는 특정한 것들은 준비되지 않아씅ㄹ 수 있지만 잊어버리라고 말하고 있다. 계속 전진하고 있다. 네이트브 핸들링이나 렌더링을 html5를 통해서 더 잘 대체해내루도 있고 in-browser기술(기기 접근, 좋은 native framework, applicatio 그리고 display code. \n\nWhat has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?\n\n=Device Access= \n따라서, 기기 접근이다. 기기 내에 제한된 정보를 가져오는 것이 그 예. Geolocation, network connectivity, obviously very big for caching, 카메라, 연락처,. geo-location. 이는 HTML5로 할 수 있고, 반대로 m.facebook.com에서 Places와 Deals 스터프를 기반으로 사용한다; network connectivity는 최근 생겨났고 최신 브라우저에서는 HTML5를 통해서 알 수 있다. 카메라와 주소들은 아직. 하지만 가져올수 있고 없는 것을 알고 싶다면, PhoneGap.com을 참고하길. 이 모든것들이 아직 과도기. \n\n\n= History= \nHistory를 개발할 수 있는 프레임워크가 네이티브에 존재. 이는 매우weired하다. 왜냐면 native stack 에 쌓여있고 이는 브라우저의 history와는 매우 다르기 때문. 브라우저는 히스토리를 다루는 방식이 매우 다르고 그 모델도 매우 다름. 히스토리 관리, client-side , threading은 중요. threading은 특히 중요. \n\nHTML5는 이 모든것을 통합할 수도 있음. history 관리를 위해 HTML5에는 좋은 기능이 있음. IndexDB와 client-side storage는 더덕 좋은 기능. WebWorkers같은 것이 다시 생기면 HTML5 에서 쓸수 있을 거다. \n\n=앱이 웹기술만들오 만들어질 수 있나? = \n결론적으로 중요한것은 웹기술만드으로 앱을 만들 수 잇냐는것이다. \n실제 웹 기술이 사용되고 당신도 사용하고 있다. 스크롤/리프레시/fast stuff등은 네이티브핸들러를 쓴다. 하지만 scrolling은 iOS5가 scrolling, position fixed overflow scorll을 만들어준 덕분에 네이티브를 쓴ㄴ 것은 옛날얘기가 되었따. 고정위치 header와 good scrolling은 네이티브만의 것이라고 생각하지만 이는 잘만들어진 JS와 새로운 framework들 덕분에 극복해낼수 있다는거. \n\njS엔진이 계속 좋아지고 있고, V8과 Nitro는 full-fledged JS로 objective c나 자바를 쓰지 않고 그에 상응하는 앱을 만들 수 있는 것을보여줬다. Netflix는 이미 이를 상품화 했다. \n\n따라서 빅 브라우저 제조사달의 긴급한 투자는 정말 정말 좋은 JS를 만드는 것. \nAnd if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have\n\n-----------------------------------------------------------------------------------------------------\n
  • http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php\n\n7.5억명의 AU(Active User)\\, stmart폰에서 feature폰까지 무수한 client들에서 모두 가용하다. \n모바일 개발은 2006년에 시작, m.facebook.com/webkit터치인터페이스에서 HTML5까지 활용중. \nfacebook 스파르판 프로젝트(http://www.slashgear.com/facebook-project-spartan-leaks-unveil-tipped-monday-with-ipad-app-29183916/, http://www.bloter.net/archives/64419(ko) )\n(스파르탄프로젝트 : 애플을 정면 겨냥한 모바일 앱 플랫폼. 페이스북 앱을 애플 앱스토어가 아닌 사파리 웹 브라우저의 모바일 버전에서 돌아가게 끔 하는 것. 스파르탄 프로젝트의 목표는 앱배포와관련해 애플의 통제를 벗어나는 것.)\n====\n=지난 5년에 걸치 모바일표준의 변화(HTML중심)= \n2006년까지만 해도 HTML과 SMS에 기반한 WAP서비스를 제공하였지만 20067년 iphone이란 큰 패러다임의 변화가 생겼고, 2007년 Facebook Platform API를 공개함. 아이폰이 생기면서 CSS, Javascript 리치한 경험을 줄 수 있었음. 블랙베리, 윈도우폰 노키아 ,삼성 등등이 facebook API로 구현이 가능했음. \n2008년엔 아이폰이 앱스토어를 열었다. 그때 처음으로 아이폰용 facebook을 만들 수 있었다. 2009년엔 안드로이드. 이로써 다양한 완성도 높은 플랫폼(윈도,아이폰,안드로이드, 웹)위에서 페북을 서비스해야했다. \n\n====\n\n이때부터 개발자들의 고통은 시작되었다. 생산성이 저하되었다. 새로운 기능이 나오면 이 4개의 플랫폼에 동시 런칭이 힘들었고 런칭이 느려졌고, 코드는 안좋아져만 갔다. \n\n====\n\n=같은 기능을 4번이나 반복하지 않는 방법= \n그렇다면 우린 이를 어떻게 극복했나? 네가지 중에서 가장 배포하기 쉬운것은? 웹이다. 여기 우리는 배포를 touch.facebook.com, m.facebook.com으로 나누어 개발하였다. webkit기반의 폰이면 터치로 가고 그렇지 않으면 M으로 간다. \n\n이 방식이 모든 폰에 최적의 경험을 주지는 못했다. 화면 내에 inline image나 css의 버전, 등의 문제가 있었다. 우리는 이 문제를 해결해야만 했다. \nXSL post processing등을 썼으나 좋지 않았음. 쨌든, 한번에 코드를 작성할 수 있는 방법을 강구해야한다. \n\n====\n\n=Progressive Enhancement혁신적인개선= \n우리가 한방법은 다음과 같다. \n방법의 초석은 당신이 가지고 있는 폰이 무엇을 할수 잇는냐를 인식하는 것이다. 그 기기의 capa가 제대로된 경험을 줄수 있도록 시작되는 시발점이다. \nWURFL(Wireless Universal Resources File, http://wurfl.sourceforge.net/)프로젝트는 user-agent에 따른 각 기기의 capa를 작성하는 프로젝트였다.(예를 들어, 화면크기? JS는? cookies는? 등)모두 해결해야만 하는 중요한 문제들이었다. \n이런 UserAgent마다의 정보를 우리가 모두 수집하는 것은 어려웠기에 opensource로 개방하고 모두의 협조를 구했고, 또 개방하였다. 그것이 WURFL프로젝트이다. \n\n일단 useragent와 그 각각의 capa를 알면, 무엇을 해야하는지도 알게 되는 것이다. 페북의 버튼이 HTML이거나 Javascript의 블락으로 이루어져 있지 않아도 된다는 것. 홈페이지에서 당신이 원하는 것은 버튼을 그릴 수 있는 컴포저라는거. 따라서 진짜 필요한 것은 버튼이다. 무엇이 렌더링 되어야 하는지를 알아야만 한다. 만약에 폰이 low-end(피쳐폰같이)폰이면 post form을 그리면 될 것이고, 폰이CSS를 쓸 수 있는 mid-range폰이면 CSS layer를 사용할 수 있다. 하지만 high-end폰일 경우에는 Ajax스타일의 경험을 사용할수도 있다. 이 기술은 야후의 blueprint플랫폼 (http://www.slideshare.net/blueprintblog/bp-dev-tutorial-mm-presentation) 과 같이 이미 개척을 한 사례도있다. 따라서 top-level에서 low-end까지의 기술적인 얘기를 하는 것 대신에, 할 수 있는 것을 결정할 화면을 렌더링 하는 마크업 선언 안의 컴포넌트각각에 대해서 알아볼 것이다. 이는 폰에서 이상적인 경험을 구성하기 위해서 구성되었다. 이 기술을 progressive enhancement라고 부른다. \n\n이는 곧 웹이라면 어드든 write once run anywhere할 수 있도록 방향을 잡게 되었따. 그리고 웹은 진짜 그리할수 있어 보였다. 데탑에서는 이미 그리하고 있고, 모바일에서도 이와 마찬가지로 진행할 수 있을 터. 하지만 안드로이드나 아이폰유저들은 훌륭한 모바일브라우저를 통해서 접근할 수 있다는 것에도 불구하고 웹이야기를 하면 지겨워할지도 모른다. \n\n따라서 4개의 레이어에서 1개를 제외하고 멋진 3개에 대해서만 촛점을 맞춰보자. 하지만 물론 모두가 아이폰에 대해 얘기하길 원할것이다. 아이폰을 예로들면, \n아이폰에서의 경험을 주기 위해서 Objective-C를 사용해야하거나 해야한다. 그렇다면 facebook뉴스피드도 정말 그러한가? 상단에 탑바가 있고 캐시로부터 바로 렌더링하고, 그게 전부다. 다른 기기에서도 그래야 하는가? 아니다. 다 같다 .\n이 같은것을 매번 3차례 개발할 필요는 없다는 것이다. \n\n=상상 이상으로 미친짓=\n그렇다면, 앱 내에 진짜 브라우저를 넣으면 어떨까? 미친 아이디어였다. 그때당시만 해도 미친생각이었다. 앱 내에서 브라우저를 가져올수있는 경우도 드물었기 때문. 3가지는 적어도 WebKit을 잘 구현해놓았다. 따라서, 시도를 했으나 정말 쉽지 않았다. \n\n====\n\n=Iterate Dailiy= \n이는 매일 배포를 할 수 있다. 앱스토어의 승인을 받느라 기다리지 않아도 되고 사용자들이 download받아주길 기다리지 않아도 된다. 매일 배포할 수 있다. \n아이폰,안드로이드폰 개발팀이 분리되어 있지 않아도 된다. 모두 같은 문제를 직면하고 같이 문제를 해결한다. 4번 배포를 하지 않고 1번 집중해서 배포를 한다. \n\n이는 Project FaceWeb이라 불리고 progressive enhancement아이디어의 확장이다. Webkit브라우저에 렌더링한다고 말하는 대신에, 우리가 아이폰 앱 내의 WebKit에다가 렌더링 할 것이라고 할 수 있다. 따라서 우리가 해야할 일은 기기를 감지하고 동작할 수 있도록 Web코드를 스타일링하고 네이티브앱과 소통하기 위해서 Objective-C를 짜서 Javascript와 통신하여 HTML로 페북페이지를 렌더링하도록 하면 되는것이다. 따라서 네이티브구현은 최소화 하는 것이다. \n\n=The Answer : 네이티브 앱 안에 Facebook Mobile을 싼다= \n기술적으로 이게 어떻게 돌아가는가? 아이폰에서 news feed버튼을 누른다. 만약 FaceWeb 가능한 기기면, native Web controller로 매핑시키지 않고 m.facebook.com/home.php를 가져온다. 단순히 웹 뷰를 보여주는 것이다. 이 웹뷰가 어떻게 Objective-C와 통신하는지 알아야한다. 따라서 해당 프레임에서 요구하는 "platform extraction call layer"를 명시한 JS skeleton을 회신한다. 그러면 다른 동작을 하고 home.php와 JavaScript를 로드한다. \n이는 기본적으로 m.facebook.com사이트를 만들고 Javascript를 폰의 네이티브기능(카페라 등 )들을 사용할 수 있는 abstraction layer를 둔다는 것이다. \n\n그 bridge에서 해야만하는 것은? 분명sensor와 data같은 것들이다. \nGPS를 알고싶다면 HTML5에서는 지원하지만 다 지원하지 않기 때문에 각 기기의 accelerometer나 orientation lock같은 것들을 참고해야한다. \nJavascript < query >Native, Camera플로우 등은 Native를 써야만 한다.\n\n=stick point : Web vs Native Design=\nmutating components : <m:button /> \n폰갭은 위에 그 문제를 해결해 주었다. 문제는 보여줄 수 있는 버튼이 하나면 절대 native스럽지 않게 보인다는 것. 두번째는 네이티브 느낌을 못준다는 것, 세번째는 빠르지 않다는 것이다. 이 세가지가 폰갭에서 얻은 것이다. \n\n첫번째 위임은, 이 일들을 HTML로 하고 싶다는 것, 뉴스피드의 경우 HTML로 보여주는 것과 네이티브로 보여주는 것에는 차이점이 없다는 것을 재차 강조. 이는 단순히 비주얼이라는 큰문제로 끝나지 않는다. 웹과 앱은 서로 잘 동작한다. 우리가 앱에 브라우저를 넣었을 때 사용자들은 한 경우를 제외하고는 전혀 불평하지 않앗다. \n\n그 한가지는 페이스북과 친한 iPad앱이다. 이는 단순히 m.site를 감싼 거다. 어떤 사용자들은 페이스북이 m.site를 대충 고쳐서 복사해 찍어냈다고 말한다. 실제로 m.site를 썼고 좋았다. 따라서 사실은 네이티브같이 보이지 않아고, 그것이 큰 문제가 되지 않았다. \n\n아직도 연구해야할게 남았다. position fix와 overflow scroll이 가장 큰 문제였다. 안드로이드 2.1이하에서는 전혀 방법이 없었고, 2.2에서는 작업을 시작했고 iOS5에서는 이 모든것을 구현해주기로 했다. 따라서 지금 웹앱을 시작하는것은 10개월 전보다 훨씩 수월할 것이다. CSS 그라디언트도 문제였고 이미지도 문제였다. 그 외에도 더 몇가지가 있다. \n\n=Web vs Native Feel : scroll=\n다른 문제는 네이티브느낌이 나지 않는다는 것이고 이는 대부분 스크롤할때이다. \n예를 들어 지우기 위해서 swipe를 하고 싶을때, 스크롤이 되어버린다. 이는 별문제 아니다. 스크롤 관련해서 GPU나 파이프라이닝이 네이티브에서는 잘 되어 있지만 HTML에서는 구현하기가 매우 힘들다. 대부분의 사람들이 네이티브 느낌이 나지 않다고 말하는 것은 스크롤을 할 때이다. \n\n종종 스크롤을 구현한다. iScroll잘 동작하고 Hewitts도 잘 동작한다. 따라서, JS라이브러리를 쓸 수도 있다. 또한 브라우저내에서의 이미지 확대축소와같은 것은 GPU를 쓰기 때문에 무리없이 할 수 있다. 그리고 이런 자잘한 것들은 문서화되어 있지 않다. 예를 들어 안드로이드나 아이폰에서 키보드가 보여지고 닫혀지지 않ㄴ,ㄴ것등. 시스템에서 정해진 그런자잘한 것들이 좀 있다. \n\n\n=Issue of Speed =\n마지막으로 한가지는 충분히 빠르지 않다는 것. 아이폰 앱에서 천천히 내리면 확인해볼 수 있음. \n\n따라서 방법은 명확히 pre-cache만이 살길이라는거. news feeds를 렌더링 한다고 치면, 버튼을 누르자마자 보여야 하는데 이를위해, 웹뷰를 캐시하는것이다. 그것이 동작하지 않을 경우 가장 좋은 방법은 사용자들을 속이는 것이다. 적어도 준비가 될때가지. 뼈대를 렌더링하고 캐시된 컨텐트로 채우고 그 다음엔 해로운 컨텐트를 보여주는 것이다. 적어도 사용자는 첫 응답이 왔기 때문에 변화를 인지하면 기다린다. \n\n퍼포먼스는 당신이 얼마나 JS를 많이 쓰는가에 대한 거다. 단순히 데이터를 로딩할 뿐만 아니라 더 무거운 pre-rendered된 만크업을 로딩한다. HTTP cache와 같은 경우 그리고 app cache와 같은 경우 그것들은 UI Web view에서 동작한다고 하지만 종종 그렇지 않다. 따라서 그 리소스들이 모두 여기서 만들어지는 확신할 수 있어야만 한다. \n\n=Taking The Approach everywhere= \n하지만, 안드로이드에서 잘 동작했다. 따라서 m.site와 같은식으로 만들 수 잇었다. news feed가 변경되거나 news feed가 추가되거나 comment가 추가되거나 모두 low-end인 m.site에 뿌려지고 high-end m.site에 뿌려지고 아이폰패북, 안드로이드패북에도 다음날이면 적용되었다. \n따라서, 우리는 이렇게 했고, 페북경험의 요소를 가지게 됬고 모든 것들 안에 브라우저가 삽입되었다. 특히 new feed나 당신의 프로필 타임라인과 같은 가장 자주 변하는 것들에 대해서는HTML을 바로 사용하였다. \n\n=어떻게 진화했는가 : HTML5 =\niOS3.4와 3.5에서 동작한다. news feed와 profile feed는 m.site로부터 소스를 가져온 것이다. 따라서, m.site가 변경되고 피처가 추가되면 그것이 적용된다. m.site가 장애가 생기면 모든 것이 뻑난다. 장단점이 있다는 것이다. iOS4.0에서 는 requests, notifications, search, list-style content가 네이티브를 쓰지 않고 FaceWeb을 사용하였다. 안드로이드 1.6, 1.7에서도 동일하게 진행. 피드백과 디자인은 꽤 좋았지만 버그들이 좀 많았다. Javascript 버전등이 맞지 않는다거나 문제가 생기면 빨리 고칠수 있다. \n따라서,미션은 한개의 코드베이스로부터 동작하고 세상의 모든 브라우저에 적용하는 것이다. 이는 페이스북에서 말하는 것 같지만 사실은 HTML5의 구호이다. \n\nHTML5가 아마도 우리가 하고자 하는 것일거다. 이는 HTML5가 물밑에서 변화되고 있기에 써야한다. 하이브리드 앱을 만다는 초기에는 HTML5에 잇는 특정한 것들은 준비되지 않아씅ㄹ 수 있지만 잊어버리라고 말하고 있다. 계속 전진하고 있다. 네이트브 핸들링이나 렌더링을 html5를 통해서 더 잘 대체해내루도 있고 in-browser기술(기기 접근, 좋은 native framework, applicatio 그리고 display code. \n\nWhat has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?\n\n=Device Access= \n따라서, 기기 접근이다. 기기 내에 제한된 정보를 가져오는 것이 그 예. Geolocation, network connectivity, obviously very big for caching, 카메라, 연락처,. geo-location. 이는 HTML5로 할 수 있고, 반대로 m.facebook.com에서 Places와 Deals 스터프를 기반으로 사용한다; network connectivity는 최근 생겨났고 최신 브라우저에서는 HTML5를 통해서 알 수 있다. 카메라와 주소들은 아직. 하지만 가져올수 있고 없는 것을 알고 싶다면, PhoneGap.com을 참고하길. 이 모든것들이 아직 과도기. \n\n\n= History= \nHistory를 개발할 수 있는 프레임워크가 네이티브에 존재. 이는 매우weired하다. 왜냐면 native stack 에 쌓여있고 이는 브라우저의 history와는 매우 다르기 때문. 브라우저는 히스토리를 다루는 방식이 매우 다르고 그 모델도 매우 다름. 히스토리 관리, client-side , threading은 중요. threading은 특히 중요. \n\nHTML5는 이 모든것을 통합할 수도 있음. history 관리를 위해 HTML5에는 좋은 기능이 있음. IndexDB와 client-side storage는 더덕 좋은 기능. WebWorkers같은 것이 다시 생기면 HTML5 에서 쓸수 있을 거다. \n\n=앱이 웹기술만들오 만들어질 수 있나? = \n결론적으로 중요한것은 웹기술만드으로 앱을 만들 수 잇냐는것이다. \n실제 웹 기술이 사용되고 당신도 사용하고 있다. 스크롤/리프레시/fast stuff등은 네이티브핸들러를 쓴다. 하지만 scrolling은 iOS5가 scrolling, position fixed overflow scorll을 만들어준 덕분에 네이티브를 쓴ㄴ 것은 옛날얘기가 되었따. 고정위치 header와 good scrolling은 네이티브만의 것이라고 생각하지만 이는 잘만들어진 JS와 새로운 framework들 덕분에 극복해낼수 있다는거. \n\njS엔진이 계속 좋아지고 있고, V8과 Nitro는 full-fledged JS로 objective c나 자바를 쓰지 않고 그에 상응하는 앱을 만들 수 있는 것을보여줬다. Netflix는 이미 이를 상품화 했다. \n\n따라서 빅 브라우저 제조사달의 긴급한 투자는 정말 정말 좋은 JS를 만드는 것. \nAnd if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have\n\n-----------------------------------------------------------------------------------------------------\n
  • http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php\n\n7.5억명의 AU(Active User)\\, stmart폰에서 feature폰까지 무수한 client들에서 모두 가용하다. \n모바일 개발은 2006년에 시작, m.facebook.com/webkit터치인터페이스에서 HTML5까지 활용중. \nfacebook 스파르판 프로젝트(http://www.slashgear.com/facebook-project-spartan-leaks-unveil-tipped-monday-with-ipad-app-29183916/, http://www.bloter.net/archives/64419(ko) )\n(스파르탄프로젝트 : 애플을 정면 겨냥한 모바일 앱 플랫폼. 페이스북 앱을 애플 앱스토어가 아닌 사파리 웹 브라우저의 모바일 버전에서 돌아가게 끔 하는 것. 스파르탄 프로젝트의 목표는 앱배포와관련해 애플의 통제를 벗어나는 것.)\n====\n=지난 5년에 걸치 모바일표준의 변화(HTML중심)= \n2006년까지만 해도 HTML과 SMS에 기반한 WAP서비스를 제공하였지만 20067년 iphone이란 큰 패러다임의 변화가 생겼고, 2007년 Facebook Platform API를 공개함. 아이폰이 생기면서 CSS, Javascript 리치한 경험을 줄 수 있었음. 블랙베리, 윈도우폰 노키아 ,삼성 등등이 facebook API로 구현이 가능했음. \n2008년엔 아이폰이 앱스토어를 열었다. 그때 처음으로 아이폰용 facebook을 만들 수 있었다. 2009년엔 안드로이드. 이로써 다양한 완성도 높은 플랫폼(윈도,아이폰,안드로이드, 웹)위에서 페북을 서비스해야했다. \n\n====\n\n이때부터 개발자들의 고통은 시작되었다. 생산성이 저하되었다. 새로운 기능이 나오면 이 4개의 플랫폼에 동시 런칭이 힘들었고 런칭이 느려졌고, 코드는 안좋아져만 갔다. \n\n====\n\n=같은 기능을 4번이나 반복하지 않는 방법= \n그렇다면 우린 이를 어떻게 극복했나? 네가지 중에서 가장 배포하기 쉬운것은? 웹이다. 여기 우리는 배포를 touch.facebook.com, m.facebook.com으로 나누어 개발하였다. webkit기반의 폰이면 터치로 가고 그렇지 않으면 M으로 간다. \n\n이 방식이 모든 폰에 최적의 경험을 주지는 못했다. 화면 내에 inline image나 css의 버전, 등의 문제가 있었다. 우리는 이 문제를 해결해야만 했다. \nXSL post processing등을 썼으나 좋지 않았음. 쨌든, 한번에 코드를 작성할 수 있는 방법을 강구해야한다. \n\n====\n\n=Progressive Enhancement혁신적인개선= \n우리가 한방법은 다음과 같다. \n방법의 초석은 당신이 가지고 있는 폰이 무엇을 할수 잇는냐를 인식하는 것이다. 그 기기의 capa가 제대로된 경험을 줄수 있도록 시작되는 시발점이다. \nWURFL(Wireless Universal Resources File, http://wurfl.sourceforge.net/)프로젝트는 user-agent에 따른 각 기기의 capa를 작성하는 프로젝트였다.(예를 들어, 화면크기? JS는? cookies는? 등)모두 해결해야만 하는 중요한 문제들이었다. \n이런 UserAgent마다의 정보를 우리가 모두 수집하는 것은 어려웠기에 opensource로 개방하고 모두의 협조를 구했고, 또 개방하였다. 그것이 WURFL프로젝트이다. \n\n일단 useragent와 그 각각의 capa를 알면, 무엇을 해야하는지도 알게 되는 것이다. 페북의 버튼이 HTML이거나 Javascript의 블락으로 이루어져 있지 않아도 된다는 것. 홈페이지에서 당신이 원하는 것은 버튼을 그릴 수 있는 컴포저라는거. 따라서 진짜 필요한 것은 버튼이다. 무엇이 렌더링 되어야 하는지를 알아야만 한다. 만약에 폰이 low-end(피쳐폰같이)폰이면 post form을 그리면 될 것이고, 폰이CSS를 쓸 수 있는 mid-range폰이면 CSS layer를 사용할 수 있다. 하지만 high-end폰일 경우에는 Ajax스타일의 경험을 사용할수도 있다. 이 기술은 야후의 blueprint플랫폼 (http://www.slideshare.net/blueprintblog/bp-dev-tutorial-mm-presentation) 과 같이 이미 개척을 한 사례도있다. 따라서 top-level에서 low-end까지의 기술적인 얘기를 하는 것 대신에, 할 수 있는 것을 결정할 화면을 렌더링 하는 마크업 선언 안의 컴포넌트각각에 대해서 알아볼 것이다. 이는 폰에서 이상적인 경험을 구성하기 위해서 구성되었다. 이 기술을 progressive enhancement라고 부른다. \n\n이는 곧 웹이라면 어드든 write once run anywhere할 수 있도록 방향을 잡게 되었따. 그리고 웹은 진짜 그리할수 있어 보였다. 데탑에서는 이미 그리하고 있고, 모바일에서도 이와 마찬가지로 진행할 수 있을 터. 하지만 안드로이드나 아이폰유저들은 훌륭한 모바일브라우저를 통해서 접근할 수 있다는 것에도 불구하고 웹이야기를 하면 지겨워할지도 모른다. \n\n따라서 4개의 레이어에서 1개를 제외하고 멋진 3개에 대해서만 촛점을 맞춰보자. 하지만 물론 모두가 아이폰에 대해 얘기하길 원할것이다. 아이폰을 예로들면, \n아이폰에서의 경험을 주기 위해서 Objective-C를 사용해야하거나 해야한다. 그렇다면 facebook뉴스피드도 정말 그러한가? 상단에 탑바가 있고 캐시로부터 바로 렌더링하고, 그게 전부다. 다른 기기에서도 그래야 하는가? 아니다. 다 같다 .\n이 같은것을 매번 3차례 개발할 필요는 없다는 것이다. \n\n=상상 이상으로 미친짓=\n그렇다면, 앱 내에 진짜 브라우저를 넣으면 어떨까? 미친 아이디어였다. 그때당시만 해도 미친생각이었다. 앱 내에서 브라우저를 가져올수있는 경우도 드물었기 때문. 3가지는 적어도 WebKit을 잘 구현해놓았다. 따라서, 시도를 했으나 정말 쉽지 않았다. \n\n====\n\n=Iterate Dailiy= \n이는 매일 배포를 할 수 있다. 앱스토어의 승인을 받느라 기다리지 않아도 되고 사용자들이 download받아주길 기다리지 않아도 된다. 매일 배포할 수 있다. \n아이폰,안드로이드폰 개발팀이 분리되어 있지 않아도 된다. 모두 같은 문제를 직면하고 같이 문제를 해결한다. 4번 배포를 하지 않고 1번 집중해서 배포를 한다. \n\n이는 Project FaceWeb이라 불리고 progressive enhancement아이디어의 확장이다. Webkit브라우저에 렌더링한다고 말하는 대신에, 우리가 아이폰 앱 내의 WebKit에다가 렌더링 할 것이라고 할 수 있다. 따라서 우리가 해야할 일은 기기를 감지하고 동작할 수 있도록 Web코드를 스타일링하고 네이티브앱과 소통하기 위해서 Objective-C를 짜서 Javascript와 통신하여 HTML로 페북페이지를 렌더링하도록 하면 되는것이다. 따라서 네이티브구현은 최소화 하는 것이다. \n\n=The Answer : 네이티브 앱 안에 Facebook Mobile을 싼다= \n기술적으로 이게 어떻게 돌아가는가? 아이폰에서 news feed버튼을 누른다. 만약 FaceWeb 가능한 기기면, native Web controller로 매핑시키지 않고 m.facebook.com/home.php를 가져온다. 단순히 웹 뷰를 보여주는 것이다. 이 웹뷰가 어떻게 Objective-C와 통신하는지 알아야한다. 따라서 해당 프레임에서 요구하는 "platform extraction call layer"를 명시한 JS skeleton을 회신한다. 그러면 다른 동작을 하고 home.php와 JavaScript를 로드한다. \n이는 기본적으로 m.facebook.com사이트를 만들고 Javascript를 폰의 네이티브기능(카페라 등 )들을 사용할 수 있는 abstraction layer를 둔다는 것이다. \n\n그 bridge에서 해야만하는 것은? 분명sensor와 data같은 것들이다. \nGPS를 알고싶다면 HTML5에서는 지원하지만 다 지원하지 않기 때문에 각 기기의 accelerometer나 orientation lock같은 것들을 참고해야한다. \nJavascript < query >Native, Camera플로우 등은 Native를 써야만 한다.\n\n=stick point : Web vs Native Design=\nmutating components : <m:button /> \n폰갭은 위에 그 문제를 해결해 주었다. 문제는 보여줄 수 있는 버튼이 하나면 절대 native스럽지 않게 보인다는 것. 두번째는 네이티브 느낌을 못준다는 것, 세번째는 빠르지 않다는 것이다. 이 세가지가 폰갭에서 얻은 것이다. \n\n첫번째 위임은, 이 일들을 HTML로 하고 싶다는 것, 뉴스피드의 경우 HTML로 보여주는 것과 네이티브로 보여주는 것에는 차이점이 없다는 것을 재차 강조. 이는 단순히 비주얼이라는 큰문제로 끝나지 않는다. 웹과 앱은 서로 잘 동작한다. 우리가 앱에 브라우저를 넣었을 때 사용자들은 한 경우를 제외하고는 전혀 불평하지 않앗다. \n\n그 한가지는 페이스북과 친한 iPad앱이다. 이는 단순히 m.site를 감싼 거다. 어떤 사용자들은 페이스북이 m.site를 대충 고쳐서 복사해 찍어냈다고 말한다. 실제로 m.site를 썼고 좋았다. 따라서 사실은 네이티브같이 보이지 않아고, 그것이 큰 문제가 되지 않았다. \n\n아직도 연구해야할게 남았다. position fix와 overflow scroll이 가장 큰 문제였다. 안드로이드 2.1이하에서는 전혀 방법이 없었고, 2.2에서는 작업을 시작했고 iOS5에서는 이 모든것을 구현해주기로 했다. 따라서 지금 웹앱을 시작하는것은 10개월 전보다 훨씩 수월할 것이다. CSS 그라디언트도 문제였고 이미지도 문제였다. 그 외에도 더 몇가지가 있다. \n\n=Web vs Native Feel : scroll=\n다른 문제는 네이티브느낌이 나지 않는다는 것이고 이는 대부분 스크롤할때이다. \n예를 들어 지우기 위해서 swipe를 하고 싶을때, 스크롤이 되어버린다. 이는 별문제 아니다. 스크롤 관련해서 GPU나 파이프라이닝이 네이티브에서는 잘 되어 있지만 HTML에서는 구현하기가 매우 힘들다. 대부분의 사람들이 네이티브 느낌이 나지 않다고 말하는 것은 스크롤을 할 때이다. \n\n종종 스크롤을 구현한다. iScroll잘 동작하고 Hewitts도 잘 동작한다. 따라서, JS라이브러리를 쓸 수도 있다. 또한 브라우저내에서의 이미지 확대축소와같은 것은 GPU를 쓰기 때문에 무리없이 할 수 있다. 그리고 이런 자잘한 것들은 문서화되어 있지 않다. 예를 들어 안드로이드나 아이폰에서 키보드가 보여지고 닫혀지지 않ㄴ,ㄴ것등. 시스템에서 정해진 그런자잘한 것들이 좀 있다. \n\n\n=Issue of Speed =\n마지막으로 한가지는 충분히 빠르지 않다는 것. 아이폰 앱에서 천천히 내리면 확인해볼 수 있음. \n\n따라서 방법은 명확히 pre-cache만이 살길이라는거. news feeds를 렌더링 한다고 치면, 버튼을 누르자마자 보여야 하는데 이를위해, 웹뷰를 캐시하는것이다. 그것이 동작하지 않을 경우 가장 좋은 방법은 사용자들을 속이는 것이다. 적어도 준비가 될때가지. 뼈대를 렌더링하고 캐시된 컨텐트로 채우고 그 다음엔 해로운 컨텐트를 보여주는 것이다. 적어도 사용자는 첫 응답이 왔기 때문에 변화를 인지하면 기다린다. \n\n퍼포먼스는 당신이 얼마나 JS를 많이 쓰는가에 대한 거다. 단순히 데이터를 로딩할 뿐만 아니라 더 무거운 pre-rendered된 만크업을 로딩한다. HTTP cache와 같은 경우 그리고 app cache와 같은 경우 그것들은 UI Web view에서 동작한다고 하지만 종종 그렇지 않다. 따라서 그 리소스들이 모두 여기서 만들어지는 확신할 수 있어야만 한다. \n\n=Taking The Approach everywhere= \n하지만, 안드로이드에서 잘 동작했다. 따라서 m.site와 같은식으로 만들 수 잇었다. news feed가 변경되거나 news feed가 추가되거나 comment가 추가되거나 모두 low-end인 m.site에 뿌려지고 high-end m.site에 뿌려지고 아이폰패북, 안드로이드패북에도 다음날이면 적용되었다. \n따라서, 우리는 이렇게 했고, 페북경험의 요소를 가지게 됬고 모든 것들 안에 브라우저가 삽입되었다. 특히 new feed나 당신의 프로필 타임라인과 같은 가장 자주 변하는 것들에 대해서는HTML을 바로 사용하였다. \n\n=어떻게 진화했는가 : HTML5 =\niOS3.4와 3.5에서 동작한다. news feed와 profile feed는 m.site로부터 소스를 가져온 것이다. 따라서, m.site가 변경되고 피처가 추가되면 그것이 적용된다. m.site가 장애가 생기면 모든 것이 뻑난다. 장단점이 있다는 것이다. iOS4.0에서 는 requests, notifications, search, list-style content가 네이티브를 쓰지 않고 FaceWeb을 사용하였다. 안드로이드 1.6, 1.7에서도 동일하게 진행. 피드백과 디자인은 꽤 좋았지만 버그들이 좀 많았다. Javascript 버전등이 맞지 않는다거나 문제가 생기면 빨리 고칠수 있다. \n따라서,미션은 한개의 코드베이스로부터 동작하고 세상의 모든 브라우저에 적용하는 것이다. 이는 페이스북에서 말하는 것 같지만 사실은 HTML5의 구호이다. \n\nHTML5가 아마도 우리가 하고자 하는 것일거다. 이는 HTML5가 물밑에서 변화되고 있기에 써야한다. 하이브리드 앱을 만다는 초기에는 HTML5에 잇는 특정한 것들은 준비되지 않아씅ㄹ 수 있지만 잊어버리라고 말하고 있다. 계속 전진하고 있다. 네이트브 핸들링이나 렌더링을 html5를 통해서 더 잘 대체해내루도 있고 in-browser기술(기기 접근, 좋은 native framework, applicatio 그리고 display code. \n\nWhat has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?\n\n=Device Access= \n따라서, 기기 접근이다. 기기 내에 제한된 정보를 가져오는 것이 그 예. Geolocation, network connectivity, obviously very big for caching, 카메라, 연락처,. geo-location. 이는 HTML5로 할 수 있고, 반대로 m.facebook.com에서 Places와 Deals 스터프를 기반으로 사용한다; network connectivity는 최근 생겨났고 최신 브라우저에서는 HTML5를 통해서 알 수 있다. 카메라와 주소들은 아직. 하지만 가져올수 있고 없는 것을 알고 싶다면, PhoneGap.com을 참고하길. 이 모든것들이 아직 과도기. \n\n\n= History= \nHistory를 개발할 수 있는 프레임워크가 네이티브에 존재. 이는 매우weired하다. 왜냐면 native stack 에 쌓여있고 이는 브라우저의 history와는 매우 다르기 때문. 브라우저는 히스토리를 다루는 방식이 매우 다르고 그 모델도 매우 다름. 히스토리 관리, client-side , threading은 중요. threading은 특히 중요. \n\nHTML5는 이 모든것을 통합할 수도 있음. history 관리를 위해 HTML5에는 좋은 기능이 있음. IndexDB와 client-side storage는 더덕 좋은 기능. WebWorkers같은 것이 다시 생기면 HTML5 에서 쓸수 있을 거다. \n\n=앱이 웹기술만들오 만들어질 수 있나? = \n결론적으로 중요한것은 웹기술만드으로 앱을 만들 수 잇냐는것이다. \n실제 웹 기술이 사용되고 당신도 사용하고 있다. 스크롤/리프레시/fast stuff등은 네이티브핸들러를 쓴다. 하지만 scrolling은 iOS5가 scrolling, position fixed overflow scorll을 만들어준 덕분에 네이티브를 쓴ㄴ 것은 옛날얘기가 되었따. 고정위치 header와 good scrolling은 네이티브만의 것이라고 생각하지만 이는 잘만들어진 JS와 새로운 framework들 덕분에 극복해낼수 있다는거. \n\njS엔진이 계속 좋아지고 있고, V8과 Nitro는 full-fledged JS로 objective c나 자바를 쓰지 않고 그에 상응하는 앱을 만들 수 있는 것을보여줬다. Netflix는 이미 이를 상품화 했다. \n\n따라서 빅 브라우저 제조사달의 긴급한 투자는 정말 정말 좋은 JS를 만드는 것. \nAnd if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have\n\n-----------------------------------------------------------------------------------------------------\n
  • http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php\n\n7.5억명의 AU(Active User)\\, stmart폰에서 feature폰까지 무수한 client들에서 모두 가용하다. \n모바일 개발은 2006년에 시작, m.facebook.com/webkit터치인터페이스에서 HTML5까지 활용중. \nfacebook 스파르판 프로젝트(http://www.slashgear.com/facebook-project-spartan-leaks-unveil-tipped-monday-with-ipad-app-29183916/, http://www.bloter.net/archives/64419(ko) )\n(스파르탄프로젝트 : 애플을 정면 겨냥한 모바일 앱 플랫폼. 페이스북 앱을 애플 앱스토어가 아닌 사파리 웹 브라우저의 모바일 버전에서 돌아가게 끔 하는 것. 스파르탄 프로젝트의 목표는 앱배포와관련해 애플의 통제를 벗어나는 것.)\n====\n=지난 5년에 걸치 모바일표준의 변화(HTML중심)= \n2006년까지만 해도 HTML과 SMS에 기반한 WAP서비스를 제공하였지만 20067년 iphone이란 큰 패러다임의 변화가 생겼고, 2007년 Facebook Platform API를 공개함. 아이폰이 생기면서 CSS, Javascript 리치한 경험을 줄 수 있었음. 블랙베리, 윈도우폰 노키아 ,삼성 등등이 facebook API로 구현이 가능했음. \n2008년엔 아이폰이 앱스토어를 열었다. 그때 처음으로 아이폰용 facebook을 만들 수 있었다. 2009년엔 안드로이드. 이로써 다양한 완성도 높은 플랫폼(윈도,아이폰,안드로이드, 웹)위에서 페북을 서비스해야했다. \n\n====\n\n이때부터 개발자들의 고통은 시작되었다. 생산성이 저하되었다. 새로운 기능이 나오면 이 4개의 플랫폼에 동시 런칭이 힘들었고 런칭이 느려졌고, 코드는 안좋아져만 갔다. \n\n====\n\n=같은 기능을 4번이나 반복하지 않는 방법= \n그렇다면 우린 이를 어떻게 극복했나? 네가지 중에서 가장 배포하기 쉬운것은? 웹이다. 여기 우리는 배포를 touch.facebook.com, m.facebook.com으로 나누어 개발하였다. webkit기반의 폰이면 터치로 가고 그렇지 않으면 M으로 간다. \n\n이 방식이 모든 폰에 최적의 경험을 주지는 못했다. 화면 내에 inline image나 css의 버전, 등의 문제가 있었다. 우리는 이 문제를 해결해야만 했다. \nXSL post processing등을 썼으나 좋지 않았음. 쨌든, 한번에 코드를 작성할 수 있는 방법을 강구해야한다. \n\n====\n\n=Progressive Enhancement혁신적인개선= \n우리가 한방법은 다음과 같다. \n방법의 초석은 당신이 가지고 있는 폰이 무엇을 할수 잇는냐를 인식하는 것이다. 그 기기의 capa가 제대로된 경험을 줄수 있도록 시작되는 시발점이다. \nWURFL(Wireless Universal Resources File, http://wurfl.sourceforge.net/)프로젝트는 user-agent에 따른 각 기기의 capa를 작성하는 프로젝트였다.(예를 들어, 화면크기? JS는? cookies는? 등)모두 해결해야만 하는 중요한 문제들이었다. \n이런 UserAgent마다의 정보를 우리가 모두 수집하는 것은 어려웠기에 opensource로 개방하고 모두의 협조를 구했고, 또 개방하였다. 그것이 WURFL프로젝트이다. \n\n일단 useragent와 그 각각의 capa를 알면, 무엇을 해야하는지도 알게 되는 것이다. 페북의 버튼이 HTML이거나 Javascript의 블락으로 이루어져 있지 않아도 된다는 것. 홈페이지에서 당신이 원하는 것은 버튼을 그릴 수 있는 컴포저라는거. 따라서 진짜 필요한 것은 버튼이다. 무엇이 렌더링 되어야 하는지를 알아야만 한다. 만약에 폰이 low-end(피쳐폰같이)폰이면 post form을 그리면 될 것이고, 폰이CSS를 쓸 수 있는 mid-range폰이면 CSS layer를 사용할 수 있다. 하지만 high-end폰일 경우에는 Ajax스타일의 경험을 사용할수도 있다. 이 기술은 야후의 blueprint플랫폼 (http://www.slideshare.net/blueprintblog/bp-dev-tutorial-mm-presentation) 과 같이 이미 개척을 한 사례도있다. 따라서 top-level에서 low-end까지의 기술적인 얘기를 하는 것 대신에, 할 수 있는 것을 결정할 화면을 렌더링 하는 마크업 선언 안의 컴포넌트각각에 대해서 알아볼 것이다. 이는 폰에서 이상적인 경험을 구성하기 위해서 구성되었다. 이 기술을 progressive enhancement라고 부른다. \n\n이는 곧 웹이라면 어드든 write once run anywhere할 수 있도록 방향을 잡게 되었따. 그리고 웹은 진짜 그리할수 있어 보였다. 데탑에서는 이미 그리하고 있고, 모바일에서도 이와 마찬가지로 진행할 수 있을 터. 하지만 안드로이드나 아이폰유저들은 훌륭한 모바일브라우저를 통해서 접근할 수 있다는 것에도 불구하고 웹이야기를 하면 지겨워할지도 모른다. \n\n따라서 4개의 레이어에서 1개를 제외하고 멋진 3개에 대해서만 촛점을 맞춰보자. 하지만 물론 모두가 아이폰에 대해 얘기하길 원할것이다. 아이폰을 예로들면, \n아이폰에서의 경험을 주기 위해서 Objective-C를 사용해야하거나 해야한다. 그렇다면 facebook뉴스피드도 정말 그러한가? 상단에 탑바가 있고 캐시로부터 바로 렌더링하고, 그게 전부다. 다른 기기에서도 그래야 하는가? 아니다. 다 같다 .\n이 같은것을 매번 3차례 개발할 필요는 없다는 것이다. \n\n=상상 이상으로 미친짓=\n그렇다면, 앱 내에 진짜 브라우저를 넣으면 어떨까? 미친 아이디어였다. 그때당시만 해도 미친생각이었다. 앱 내에서 브라우저를 가져올수있는 경우도 드물었기 때문. 3가지는 적어도 WebKit을 잘 구현해놓았다. 따라서, 시도를 했으나 정말 쉽지 않았다. \n\n====\n\n=Iterate Dailiy= \n이는 매일 배포를 할 수 있다. 앱스토어의 승인을 받느라 기다리지 않아도 되고 사용자들이 download받아주길 기다리지 않아도 된다. 매일 배포할 수 있다. \n아이폰,안드로이드폰 개발팀이 분리되어 있지 않아도 된다. 모두 같은 문제를 직면하고 같이 문제를 해결한다. 4번 배포를 하지 않고 1번 집중해서 배포를 한다. \n\n이는 Project FaceWeb이라 불리고 progressive enhancement아이디어의 확장이다. Webkit브라우저에 렌더링한다고 말하는 대신에, 우리가 아이폰 앱 내의 WebKit에다가 렌더링 할 것이라고 할 수 있다. 따라서 우리가 해야할 일은 기기를 감지하고 동작할 수 있도록 Web코드를 스타일링하고 네이티브앱과 소통하기 위해서 Objective-C를 짜서 Javascript와 통신하여 HTML로 페북페이지를 렌더링하도록 하면 되는것이다. 따라서 네이티브구현은 최소화 하는 것이다. \n\n=The Answer : 네이티브 앱 안에 Facebook Mobile을 싼다= \n기술적으로 이게 어떻게 돌아가는가? 아이폰에서 news feed버튼을 누른다. 만약 FaceWeb 가능한 기기면, native Web controller로 매핑시키지 않고 m.facebook.com/home.php를 가져온다. 단순히 웹 뷰를 보여주는 것이다. 이 웹뷰가 어떻게 Objective-C와 통신하는지 알아야한다. 따라서 해당 프레임에서 요구하는 "platform extraction call layer"를 명시한 JS skeleton을 회신한다. 그러면 다른 동작을 하고 home.php와 JavaScript를 로드한다. \n이는 기본적으로 m.facebook.com사이트를 만들고 Javascript를 폰의 네이티브기능(카페라 등 )들을 사용할 수 있는 abstraction layer를 둔다는 것이다. \n\n그 bridge에서 해야만하는 것은? 분명sensor와 data같은 것들이다. \nGPS를 알고싶다면 HTML5에서는 지원하지만 다 지원하지 않기 때문에 각 기기의 accelerometer나 orientation lock같은 것들을 참고해야한다. \nJavascript < query >Native, Camera플로우 등은 Native를 써야만 한다.\n\n=stick point : Web vs Native Design=\nmutating components : <m:button /> \n폰갭은 위에 그 문제를 해결해 주었다. 문제는 보여줄 수 있는 버튼이 하나면 절대 native스럽지 않게 보인다는 것. 두번째는 네이티브 느낌을 못준다는 것, 세번째는 빠르지 않다는 것이다. 이 세가지가 폰갭에서 얻은 것이다. \n\n첫번째 위임은, 이 일들을 HTML로 하고 싶다는 것, 뉴스피드의 경우 HTML로 보여주는 것과 네이티브로 보여주는 것에는 차이점이 없다는 것을 재차 강조. 이는 단순히 비주얼이라는 큰문제로 끝나지 않는다. 웹과 앱은 서로 잘 동작한다. 우리가 앱에 브라우저를 넣었을 때 사용자들은 한 경우를 제외하고는 전혀 불평하지 않앗다. \n\n그 한가지는 페이스북과 친한 iPad앱이다. 이는 단순히 m.site를 감싼 거다. 어떤 사용자들은 페이스북이 m.site를 대충 고쳐서 복사해 찍어냈다고 말한다. 실제로 m.site를 썼고 좋았다. 따라서 사실은 네이티브같이 보이지 않아고, 그것이 큰 문제가 되지 않았다. \n\n아직도 연구해야할게 남았다. position fix와 overflow scroll이 가장 큰 문제였다. 안드로이드 2.1이하에서는 전혀 방법이 없었고, 2.2에서는 작업을 시작했고 iOS5에서는 이 모든것을 구현해주기로 했다. 따라서 지금 웹앱을 시작하는것은 10개월 전보다 훨씩 수월할 것이다. CSS 그라디언트도 문제였고 이미지도 문제였다. 그 외에도 더 몇가지가 있다. \n\n=Web vs Native Feel : scroll=\n다른 문제는 네이티브느낌이 나지 않는다는 것이고 이는 대부분 스크롤할때이다. \n예를 들어 지우기 위해서 swipe를 하고 싶을때, 스크롤이 되어버린다. 이는 별문제 아니다. 스크롤 관련해서 GPU나 파이프라이닝이 네이티브에서는 잘 되어 있지만 HTML에서는 구현하기가 매우 힘들다. 대부분의 사람들이 네이티브 느낌이 나지 않다고 말하는 것은 스크롤을 할 때이다. \n\n종종 스크롤을 구현한다. iScroll잘 동작하고 Hewitts도 잘 동작한다. 따라서, JS라이브러리를 쓸 수도 있다. 또한 브라우저내에서의 이미지 확대축소와같은 것은 GPU를 쓰기 때문에 무리없이 할 수 있다. 그리고 이런 자잘한 것들은 문서화되어 있지 않다. 예를 들어 안드로이드나 아이폰에서 키보드가 보여지고 닫혀지지 않ㄴ,ㄴ것등. 시스템에서 정해진 그런자잘한 것들이 좀 있다. \n\n\n=Issue of Speed =\n마지막으로 한가지는 충분히 빠르지 않다는 것. 아이폰 앱에서 천천히 내리면 확인해볼 수 있음. \n\n따라서 방법은 명확히 pre-cache만이 살길이라는거. news feeds를 렌더링 한다고 치면, 버튼을 누르자마자 보여야 하는데 이를위해, 웹뷰를 캐시하는것이다. 그것이 동작하지 않을 경우 가장 좋은 방법은 사용자들을 속이는 것이다. 적어도 준비가 될때가지. 뼈대를 렌더링하고 캐시된 컨텐트로 채우고 그 다음엔 해로운 컨텐트를 보여주는 것이다. 적어도 사용자는 첫 응답이 왔기 때문에 변화를 인지하면 기다린다. \n\n퍼포먼스는 당신이 얼마나 JS를 많이 쓰는가에 대한 거다. 단순히 데이터를 로딩할 뿐만 아니라 더 무거운 pre-rendered된 만크업을 로딩한다. HTTP cache와 같은 경우 그리고 app cache와 같은 경우 그것들은 UI Web view에서 동작한다고 하지만 종종 그렇지 않다. 따라서 그 리소스들이 모두 여기서 만들어지는 확신할 수 있어야만 한다. \n\n=Taking The Approach everywhere= \n하지만, 안드로이드에서 잘 동작했다. 따라서 m.site와 같은식으로 만들 수 잇었다. news feed가 변경되거나 news feed가 추가되거나 comment가 추가되거나 모두 low-end인 m.site에 뿌려지고 high-end m.site에 뿌려지고 아이폰패북, 안드로이드패북에도 다음날이면 적용되었다. \n따라서, 우리는 이렇게 했고, 페북경험의 요소를 가지게 됬고 모든 것들 안에 브라우저가 삽입되었다. 특히 new feed나 당신의 프로필 타임라인과 같은 가장 자주 변하는 것들에 대해서는HTML을 바로 사용하였다. \n\n=어떻게 진화했는가 : HTML5 =\niOS3.4와 3.5에서 동작한다. news feed와 profile feed는 m.site로부터 소스를 가져온 것이다. 따라서, m.site가 변경되고 피처가 추가되면 그것이 적용된다. m.site가 장애가 생기면 모든 것이 뻑난다. 장단점이 있다는 것이다. iOS4.0에서 는 requests, notifications, search, list-style content가 네이티브를 쓰지 않고 FaceWeb을 사용하였다. 안드로이드 1.6, 1.7에서도 동일하게 진행. 피드백과 디자인은 꽤 좋았지만 버그들이 좀 많았다. Javascript 버전등이 맞지 않는다거나 문제가 생기면 빨리 고칠수 있다. \n따라서,미션은 한개의 코드베이스로부터 동작하고 세상의 모든 브라우저에 적용하는 것이다. 이는 페이스북에서 말하는 것 같지만 사실은 HTML5의 구호이다. \n\nHTML5가 아마도 우리가 하고자 하는 것일거다. 이는 HTML5가 물밑에서 변화되고 있기에 써야한다. 하이브리드 앱을 만다는 초기에는 HTML5에 잇는 특정한 것들은 준비되지 않아씅ㄹ 수 있지만 잊어버리라고 말하고 있다. 계속 전진하고 있다. 네이트브 핸들링이나 렌더링을 html5를 통해서 더 잘 대체해내루도 있고 in-browser기술(기기 접근, 좋은 native framework, applicatio 그리고 display code. \n\nWhat has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?\n\n=Device Access= \n따라서, 기기 접근이다. 기기 내에 제한된 정보를 가져오는 것이 그 예. Geolocation, network connectivity, obviously very big for caching, 카메라, 연락처,. geo-location. 이는 HTML5로 할 수 있고, 반대로 m.facebook.com에서 Places와 Deals 스터프를 기반으로 사용한다; network connectivity는 최근 생겨났고 최신 브라우저에서는 HTML5를 통해서 알 수 있다. 카메라와 주소들은 아직. 하지만 가져올수 있고 없는 것을 알고 싶다면, PhoneGap.com을 참고하길. 이 모든것들이 아직 과도기. \n\n\n= History= \nHistory를 개발할 수 있는 프레임워크가 네이티브에 존재. 이는 매우weired하다. 왜냐면 native stack 에 쌓여있고 이는 브라우저의 history와는 매우 다르기 때문. 브라우저는 히스토리를 다루는 방식이 매우 다르고 그 모델도 매우 다름. 히스토리 관리, client-side , threading은 중요. threading은 특히 중요. \n\nHTML5는 이 모든것을 통합할 수도 있음. history 관리를 위해 HTML5에는 좋은 기능이 있음. IndexDB와 client-side storage는 더덕 좋은 기능. WebWorkers같은 것이 다시 생기면 HTML5 에서 쓸수 있을 거다. \n\n=앱이 웹기술만들오 만들어질 수 있나? = \n결론적으로 중요한것은 웹기술만드으로 앱을 만들 수 잇냐는것이다. \n실제 웹 기술이 사용되고 당신도 사용하고 있다. 스크롤/리프레시/fast stuff등은 네이티브핸들러를 쓴다. 하지만 scrolling은 iOS5가 scrolling, position fixed overflow scorll을 만들어준 덕분에 네이티브를 쓴ㄴ 것은 옛날얘기가 되었따. 고정위치 header와 good scrolling은 네이티브만의 것이라고 생각하지만 이는 잘만들어진 JS와 새로운 framework들 덕분에 극복해낼수 있다는거. \n\njS엔진이 계속 좋아지고 있고, V8과 Nitro는 full-fledged JS로 objective c나 자바를 쓰지 않고 그에 상응하는 앱을 만들 수 있는 것을보여줬다. Netflix는 이미 이를 상품화 했다. \n\n따라서 빅 브라우저 제조사달의 긴급한 투자는 정말 정말 좋은 JS를 만드는 것. \nAnd if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have\n\n-----------------------------------------------------------------------------------------------------\n
  • http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php\n\n7.5억명의 AU(Active User)\\, stmart폰에서 feature폰까지 무수한 client들에서 모두 가용하다. \n모바일 개발은 2006년에 시작, m.facebook.com/webkit터치인터페이스에서 HTML5까지 활용중. \nfacebook 스파르판 프로젝트(http://www.slashgear.com/facebook-project-spartan-leaks-unveil-tipped-monday-with-ipad-app-29183916/, http://www.bloter.net/archives/64419(ko) )\n(스파르탄프로젝트 : 애플을 정면 겨냥한 모바일 앱 플랫폼. 페이스북 앱을 애플 앱스토어가 아닌 사파리 웹 브라우저의 모바일 버전에서 돌아가게 끔 하는 것. 스파르탄 프로젝트의 목표는 앱배포와관련해 애플의 통제를 벗어나는 것.)\n====\n=지난 5년에 걸치 모바일표준의 변화(HTML중심)= \n2006년까지만 해도 HTML과 SMS에 기반한 WAP서비스를 제공하였지만 20067년 iphone이란 큰 패러다임의 변화가 생겼고, 2007년 Facebook Platform API를 공개함. 아이폰이 생기면서 CSS, Javascript 리치한 경험을 줄 수 있었음. 블랙베리, 윈도우폰 노키아 ,삼성 등등이 facebook API로 구현이 가능했음. \n2008년엔 아이폰이 앱스토어를 열었다. 그때 처음으로 아이폰용 facebook을 만들 수 있었다. 2009년엔 안드로이드. 이로써 다양한 완성도 높은 플랫폼(윈도,아이폰,안드로이드, 웹)위에서 페북을 서비스해야했다. \n\n====\n\n이때부터 개발자들의 고통은 시작되었다. 생산성이 저하되었다. 새로운 기능이 나오면 이 4개의 플랫폼에 동시 런칭이 힘들었고 런칭이 느려졌고, 코드는 안좋아져만 갔다. \n\n====\n\n=같은 기능을 4번이나 반복하지 않는 방법= \n그렇다면 우린 이를 어떻게 극복했나? 네가지 중에서 가장 배포하기 쉬운것은? 웹이다. 여기 우리는 배포를 touch.facebook.com, m.facebook.com으로 나누어 개발하였다. webkit기반의 폰이면 터치로 가고 그렇지 않으면 M으로 간다. \n\n이 방식이 모든 폰에 최적의 경험을 주지는 못했다. 화면 내에 inline image나 css의 버전, 등의 문제가 있었다. 우리는 이 문제를 해결해야만 했다. \nXSL post processing등을 썼으나 좋지 않았음. 쨌든, 한번에 코드를 작성할 수 있는 방법을 강구해야한다. \n\n====\n\n=Progressive Enhancement혁신적인개선= \n우리가 한방법은 다음과 같다. \n방법의 초석은 당신이 가지고 있는 폰이 무엇을 할수 잇는냐를 인식하는 것이다. 그 기기의 capa가 제대로된 경험을 줄수 있도록 시작되는 시발점이다. \nWURFL(Wireless Universal Resources File, http://wurfl.sourceforge.net/)프로젝트는 user-agent에 따른 각 기기의 capa를 작성하는 프로젝트였다.(예를 들어, 화면크기? JS는? cookies는? 등)모두 해결해야만 하는 중요한 문제들이었다. \n이런 UserAgent마다의 정보를 우리가 모두 수집하는 것은 어려웠기에 opensource로 개방하고 모두의 협조를 구했고, 또 개방하였다. 그것이 WURFL프로젝트이다. \n\n일단 useragent와 그 각각의 capa를 알면, 무엇을 해야하는지도 알게 되는 것이다. 페북의 버튼이 HTML이거나 Javascript의 블락으로 이루어져 있지 않아도 된다는 것. 홈페이지에서 당신이 원하는 것은 버튼을 그릴 수 있는 컴포저라는거. 따라서 진짜 필요한 것은 버튼이다. 무엇이 렌더링 되어야 하는지를 알아야만 한다. 만약에 폰이 low-end(피쳐폰같이)폰이면 post form을 그리면 될 것이고, 폰이CSS를 쓸 수 있는 mid-range폰이면 CSS layer를 사용할 수 있다. 하지만 high-end폰일 경우에는 Ajax스타일의 경험을 사용할수도 있다. 이 기술은 야후의 blueprint플랫폼 (http://www.slideshare.net/blueprintblog/bp-dev-tutorial-mm-presentation) 과 같이 이미 개척을 한 사례도있다. 따라서 top-level에서 low-end까지의 기술적인 얘기를 하는 것 대신에, 할 수 있는 것을 결정할 화면을 렌더링 하는 마크업 선언 안의 컴포넌트각각에 대해서 알아볼 것이다. 이는 폰에서 이상적인 경험을 구성하기 위해서 구성되었다. 이 기술을 progressive enhancement라고 부른다. \n\n이는 곧 웹이라면 어드든 write once run anywhere할 수 있도록 방향을 잡게 되었따. 그리고 웹은 진짜 그리할수 있어 보였다. 데탑에서는 이미 그리하고 있고, 모바일에서도 이와 마찬가지로 진행할 수 있을 터. 하지만 안드로이드나 아이폰유저들은 훌륭한 모바일브라우저를 통해서 접근할 수 있다는 것에도 불구하고 웹이야기를 하면 지겨워할지도 모른다. \n\n따라서 4개의 레이어에서 1개를 제외하고 멋진 3개에 대해서만 촛점을 맞춰보자. 하지만 물론 모두가 아이폰에 대해 얘기하길 원할것이다. 아이폰을 예로들면, \n아이폰에서의 경험을 주기 위해서 Objective-C를 사용해야하거나 해야한다. 그렇다면 facebook뉴스피드도 정말 그러한가? 상단에 탑바가 있고 캐시로부터 바로 렌더링하고, 그게 전부다. 다른 기기에서도 그래야 하는가? 아니다. 다 같다 .\n이 같은것을 매번 3차례 개발할 필요는 없다는 것이다. \n\n=상상 이상으로 미친짓=\n그렇다면, 앱 내에 진짜 브라우저를 넣으면 어떨까? 미친 아이디어였다. 그때당시만 해도 미친생각이었다. 앱 내에&#xC