[Javascript] Facebook History Manager 분석 (2)

저번 포스트에서 initialization 하는 부분 까지 봤습니다.
다른 부분들을 util 들이라고 보시면 되고, 그 다음 중요한 부분인 go 부분을 살펴보고 마무리 할까 합니다.

go 는 parameter로 c, e, f를 받아오는데요.
우선 History를 지원하는 최신 Browser의 경우는 입력된 c를 이용하여 이동을 하게 됩니다.(history back 같이) 이는 제일 간단히 가고 싶은 url로 이동하게 됩니다. h 등을 설정하고 하는 부분이 있는데요. 이 부분은 Facebook의 url에 관련되어있기 때문에 자신이 하고자하는 형태에 다라 변경 해줄 수 있습니다.

이제 지원하지 않는 Browser의 경우를 살펴보도록 하겠습니다.
ie 8 이하의 Browser의 경우엔 이미 만들어 놓은 iframe의 변화를 살펴야 하기 때문에 750ms 마다 url을 체크 하여, 변화가 있을 경우 그 url을 이용하여 사용자의 url을 변경 시킵니다.
그 외 Hash event를 지원하는 Browser의 경우는 변화에 따라 Hash를 분석하여 url을 변경 시켜줍니다.

위와 같이 전체적인 로직은 간단합니다.
이대로 마무리하면 재미가 없을 것이라 생각 되기 때문에, Facebook 개발자들이 작성한 재밌는 Point를 살펴보도록 하겠습니다.

먼저 "#!" 이 부분인데요. Twitter에서도 이 방식을 택했습니다. 왜 그런지는 정확히는 모르겠지만, 코드 상으로 볼때는 2중으로 검증을 하기 위해서가 아닐까 합니다. 기존의 라이브러리들은 대다수 # 만으로 구분을 하곤 했는데, 잘 못 되는 경우를 좀 더 보기 위해서 해놓은 의도적인 행위가 아닐까 합니다.  동료 분이 찾아주신 바에 의하면 크롤링이 가능한 Hash처리였네요. 공부가 부족했습니다.^_^ (참고 링크) 우선 #으로 뒤에 부분을 분리 후 !가 맞는지를 check하고, !는 확인 후 삭제 하여 의미 없게 처리가 됩니다.

그리고, 불필요한 double go back(?)을 방지하기 위한 팁으로 업데이트가 될 때마다, Lastchanged 시간을 기록하여 방지를 하고 있습니다. 이것이 이론적으론 한 400ms인가 봅니다. 이렇게 많이 check하고 있네요.

그 외에엔 시간을 들여서 오류가 나지 않도록 하는 Code들이라 찬찬히 읽어보시면 되지 않을까 합니다.^_^ 전 그럼 빠른 시간 내에 jQuery Ajax History를 작성하여 공개할 수 있도록 하겠습니다.

그럼~

[Javascript] Facebook History Manager 분석 (1)

요즘 SNS시대가 도래하고, 상하로 이동하는 Scroll Navigation의 형태를 지니는 사이트들이 많아지고 있습니다. Facebook/Twitter가 가장 대표적이고, me2Day, G+ 도 이와 같은 형태를 지니고 있습니다.

기존 Page Navigation에 비해서 마우스 스크롤로 간편하게 움직일 수 있는 이러한 형태는 치명적인 단점을 가지고 있는데요. 하단으로 상당히 내려간 후에, 그 페이지를 벗어난 경우 다시 돌아올 때 불편함을 가지게 될 수 있습니다.

이러한 단점을 극복하기 위해서 Facebook는 History Manager 라는 Object를 만들어 이러한 문제를 약간이나마 해결을 하였습니다. 기존에 photo 등을 클릭하면 End Page로 가던 것을 까만 배경의 Layer 형태로 바꿨었고, 이번 개편에서는 History Manager를 이용하여 Back에도 대응할 수 있도록 진행을 하였습니다. 사용자가 Url을 Copy하게 되면, 그 것이 바로 End Page로 갈 수 있게 하여 Share가 용이하게 되었다는 점에서도 상당히 좋은 선택이라고 보고 있습니다.

UX의 장단점에 대해서는 사용자들과 연구원들이 좀 더 판단 해줄 것이라 생각을 하고, 저는 기술쟁이 입장에서 History Manage에 대한 분석으로 접근하여, 이후 jQuery용 Ajax History Plugin을 제작/공개할까 합니다.(많이 써주실랑가 모르겠네요.^_^)

우선 전체 소스는 여기서 참고하시면 됩니다. (Source by jsFiddle)

첫 번째로 init에 대해서 보고 넘어갈 수 있도록 하겠습니다.

Facebook에서는 History를 위해서 pushStaus 를 이용합니다.

문서와 예제를 보시면 어떤 기능인지에 대한 이해에 도움이 될 것입니다.

현재 이 기능은 아직 널리 퍼진 기술이 아니므로 현대 Browser 외 에는 지원을 하지 않고 있습니다.

그 이전의 Browser 사용자들을 위해서 hashchange Event 와 iframe을 이용하여 history 기능을 구현 하였습니다.

pushStatus를 이용하게 되면, url이 변경 되지만 Page 가 replace되지 않으므로 간단히 List 위에 레이어를 띄울 수 있게 됩니다. 또한, 변경 된 url을 이용해 End Page link도 사용자에게 전달 할 수 있게 됩니다.

이제 지원되지 않는 Browser들을 위한 Logic을 살펴보도록 하겠습니다.

이제 IE 7 이하 의 "hashchange" 이벤트를 지원하지 않는 Browser와 지원하는 Browser 나뉘게 됩니다. (문서 참조)

일반적으로 화면이 변화 하지 않으면서도 사용자의 location 을 변경 하고 싶을 때 "#"hash를 사용하게 됩니다. 이를 이용한 방법이 제일 많이 사용되던 Ajax History 방식이였습니다.

이것이 변경 되는 것을 인지 할 수 있는 Browser들은 단순히 Event Listen을 하게 두었고, 지원하지 않는 Browser의 경우(IE 7 이하) iframe에 현재 정보를 전달 하여, onLoad Event를 사용하도록 하였습니다.

이것이 기본적인 History Manager가 동작을 하기 위한 기본 설정입니다.

다음 Post에서는 이 설정을 가지고 실제로 어떻게 진행이 되는지 살펴보도록 하겠습니다.^_^

그럼~

[Google Appengine] Flickr API 연동 하기

(주) 해당 내용은 제가 개인적으로 공부하는 것을 노트 하는 것이므로, 심도 깊은 내용을 기대하시긴 어렵습니다.

Flickr 와 연동 되는 Python library는 상당히 많습니다.
하지만, Google Appengine 에서 제약이 많이 있기 때문에 처음에 좀 당황했습니다.
그러다 찾은 것이 gaeflickrlib 입니다.
우선은 이 Library를 이용하고 이후에, 이 코드를 발전 시키던지 기존의 Library를 brach 해서 GAE에 맞게 만들어야 겠습니다.

우선은 Flickr에서 API key를 획득해야 합니다.
http://www.flickr.com/services/api/
이곳에 가면 한국어 버전도 있으니 이를 이용하면 될 듯 합니다.

가장 중요한 것은 API key / secret 을 획득하기 위해 자신의 APP을 만듭니다.
이후 API key / secret을 획득할 수 있습니다.

이후, gaeflickrlib를 이용하여 하고자 하는 작업을 진행 하면 됩니다.

예제는 다음과 같이 되어있습니다. (from Document)

from gaeflickrlib import GaeFlickrLib

flickr = GaeFlickrLib(api_key = 'some key',
                      api_secret = 'some secret',
                      token = 'some user\'s credentials')
photos = flickr.photos_search(text = '...')

다만 여기서 Token의 경우는 따로 받아서 진행 하는 경우에 설정 해주시면 되고, 할당을 받지 않은 경우는 api_key , api_secret 변수에 할당을 해주시면 작동은 됩니다. Token이 필요한 API의 경우에만 token을 설정 하면 됩니다.

금일은 소개 수준의 연동만 적고, 이후에 심화적으로 접근 해보도록 하겠습니다.
이 Library가 문서가 적어서 이거저것 만들어 봐야 겠네요. ^_^

그럼~