한빛출판네트워크

제공 : 한빛 네트워크
저자 : David Tucker
역자 : 유일호
원문 : Advanced Flex Deep Linking with URLKit

RIA(rich internet application) 를 구현함에 있어 어련운점의 한가지는 사용자에 대한 전통적인 브라우저 경험을 보존하려고 하는 것이다. Flex 애플리케이션에서는 이런 시도를 하기 위해서 몇가지 장벽이 존재한다. 첫째로, 사용자들은 사이트를 이동하기 위해 뒤로가기 및 앞으로가기 버튼을 사용하곤 한다. 두번째로, 사용자들은 애플리케이션의 상태가 URL에 반영되는 것을 당연한 것으로 생각한다. 세번째로, 사용자들은 애플리케이션의 특정상태를 북마크하고 나중에 다시 이용하는 것을 당연한 것으로 생각한다. URLKit 은 Flex 2/3 애플리케이션에서 이러한 사항들에 대해 이야기했고, 이것은 Flex 3 딥링킹 지원의 기초적인 모태가 되었다. 만약 여러분이 Flex 개발자라면 이 도구가 분명 친숙할 것이다.

[참고] URLKit 은 NoteFlight 의 Joe Berkovitz 와 Adobe Systems 의 Todd Rein 에 의해 개발되었다.

URLKit 소개

Flex 2는 히스토리 관리 기능을 제공했었다. 어째서 이것이 가능한 많은 부분의 전통적 브라우저 경험을 보존해야될 필요가 있는 응용프로그램에 대해 완전한 해결책이 될수 없는지에는 몇가지 이유가 있다. 개발자는 응용프로그램의 특정상태와 URL이 맵핑될수 있도록 약간의 조작이 필요했다.(URL은 Flex 응용프로그램에 의해 자동으로 생성되었다.). 이것은 다음버전의 애플리케이션에 대해 URL 구조를 유지하는 것을 상당히 어렵게 만든다.

URLKit 은 응용프로그램의 상태와 URL 사이의 관계를 개발자가 매끈하게 양방향 제어를 할수 있는 이런형태의 기술을 확장할수 있는 방법을 찾았다. 그것은 MXML에 응용프로그램의 상태를 URL 맵핑을 통해 정의할 수 있도록 해주는 것이다. Flex 내부에서 이것이 어떻게 동작하는지 이해하려면, URLKit으로 만들어진 다음 응용프로그램 샘플을 보면 된다. :

URLKit Sample Application (Joe Berkovitz 과 Todd Rein 이 개발)

URLKit 배경이론

만약 여러분이 Flex/Flash 딥링킹 기술이 익숙하지 않다면, 이런 개념은 어쩌면 생소하게 느껴질 것이다. 전체 Flex 응용프로그램을 리로딩 하지 않고도 어떻게 url 을 바꿀수 있는것일까? 사실은 URL 또는 쿼리문을 바꾸면 전체 응용프로그램은 리로드 되게 된다. 그러나, 바꿀수 있는 URL 요소가 있는데 – 페이지는 리로드하지 않게 된다: # 기호 이후에 있는 것이 그것이다. 일반적으로 HTML에서는 이것을 ‘명명된 앵커(named anchors)’ 라고 부르지만, 이 경우에는 이 문자열들을 Flex 응용프로그램의 상태 맵핑에 이용할 수가 있다. 다음 URL들을 살펴 보자.:

http://www.davidtucker.net/SampleApplication.html
http://www.davidtucker.net/SampleApplication.html#/state1/product1

각각의 URL들은 같은 페이지를 띄운다. 또한, 누군가 첫번째 URL을 방문하고, 이어서 두번째 URL을 방문한다면 – 페이지는 리로드 되지 않을것이다. 이것이 바로 URLKit과 연계한 딥링킹의 핵심 아이디어 이다. 덧붙이자면, Flex 응용프로그램과 브라우져 사이에 양방향 커뮤니케이션을 관리하는 자바스크립트층이 존재한다. 이런것들을 적절히 배치하면, Flex 의 딥링킹은 전통적인 브라우저 경험을 관리하기 위한 효과적인 기준을 마련할 수가 있다.

URLKit을 활용한 응용프로그램 준비하기

URLKit 은 Flex 2와 Flex 3에서 동작하지만, 환경을 설정하는 절차는 다르다. 만약 Flex 2를 사용한다면, 본 강좌의 맨뒤에 있는 “Flex 2에서 Flex3의 딥링킹 기능 사용하기” 를 참고하기 바란다.

먼저 URLKit을 여기 에서 받아야 한다. 파일을 받아서 압축을 풀면, urlkit/bin 디렉토리 안에 있는 urlkitFlex3.swc 파일을 찾아야 한다. 이 파일은 URLKit이 제기능을 하기위해 프로젝트의 빌드 path 에 추가되어야 한다. 그렇게 응용프로그램에 추가했다면, URLKit를 사용할 준비가 된 것이다.

기본적인 예제

이것으로, 여러분은 이 기능을 설명하게 될 아주 단순한 예제를 만들어 낼수있다. URLKit는 URL을 응용프로그램의 상태와 맵핑하기 위해 4가지 규칙을 가진다. 나중에 자세히 다루겠지만 이번 예제를 위해서 UrlValueRule 을 사용할 것이고, 이 규칙은 응용프로그램 내부의 프로퍼티에 URL 의 단일값을 맵핑한다.

어떤 URLKit 규칙이든지 동작을 위해서는 응용프로그램 내부에 URLBrowserManager 컴포넌트의 단일 인스턴스가 필요하다. 이것은 URLKit 을Flex3 내부의 BrowserManager 로 연결해 주는 컴포넌트이며 이것 없이는 규칙이 제대로 동작하지 않을것이다.

다음 예제에서, 나는 ViewStack을 사용해 응용프로그램을 만들었다. 이 ViewStack 은 6개의 Box 컴포넌트를 포함한다. 나는 URL안에 있는 selectedIndex를 ViewStack 상에 맵핑하기를 원한다. 그러므로 우리는 UrlValueRule(나중에 이런상황에서 좀더 효율적일 수 있는 다른룰에 대해 배울게 될것이다.) 을 사용하면, URL안의 값을 프로퍼티에 맵핑할수 있다.

Sample Application (소스 보기 가능)

다른 규칙들

앞에서 언급했듯이, UrlValueRule 은 URLKit이 사용할수 있는 규칙의 전부가 아니다. 기본적으로, URLKit 은 4가지 규칙들을 제공한다:

• UrlValueRule - 앞서 본것과 같이, 개발자가 URL의 일부를 응용프로그램의 프로퍼티에 맵핑할 수 있도록 해준다. UrlValueRule을 이런 방식으로 쓸 경우에는, 두가지 값은 서로 엮어 지게 되며, 이것이 의미하는 바는 한쪽이 바뀌면 다른 한쪽도 바뀌게 됨을 의미한다. 만약에 두가지 값이 서로 엮이게 되는 것을 원하지 않는다면, UrlValueRule 은 변경(change) 이벤트를 처리할수 있으며 이것은 상태가 변할 때 트리거(trigger)로 사용할 수가 있다.
• UrlNavigatorRule - 앞에서 우리의 응용프로그램은 UrlValueRule 대신에 다른 규칙으로 이득을 얻을수 있다고 언급했었다. UrlNavigatorRule 은 Accordian, NavBar, TabNavigator 및 ViewStack들과 함께 동작하도록 특별히 디자인 되었다. 그래서. URL 값을 selectedIndex 프로퍼티에 맵핑하는대신, 간단히 어떤 네비게이터가 필요로하는지 알려주기만 하면 된다. 그러면 알아서 처리한다. Sample UrlNavigatorRule Example (소스 보기 가능)
• UrlDelegateRule - 이 규칙은 개발자가 URL맵핑의 일부분을 다른 규칙(또는 규칙 집합)으로 위임할수 있도록 해준다. 이 규칙은 일반적으로 메인 응용프로그램이 자식 컴포넌트에게 맵핑의 일부를 위임할수 있도록 하기위해 사용된다. 이 경우에는 URL은 중첩된 컴포넌트의 상태를 반영할 수가 있다. 이 규칙이 올바르게 작동하기 위해서는, UrlRuleSet 이라는 다음 규칙일 필요할 것이다.
• UrlRuleSet - 이 규칙은 다수의 규칙들을 그룹화 할수 있도록 허용하기 때문에 단일 URL은 여러값으로 분석될 수가 있다. 또한 어떤 방식으로 원하는 자식 규칙들을 URL에 매칭하도록 할지 정할수 있도록 허용한다.

이런 규칙들에 의하여, 세련된 딥링킹을 Flex 내부의 다양한 복합 컴포넌트를 통하여 완성할수 있다.

다수의 규칙 사용하기

UrlRuleSet은 다수의 규칙을 서로 연결할수 있도록 해준다.: 각각의 규칙은 그것들과 함께 동작하는 URL 을 가진다. 이것을 설명하기 위해, 나는 앞의 예제를 확장한 간단한 예제를 만들었다. 이제, ViewStack의 선택된 자식과 그것들의 자식들의 색상(color)이 URL과 연결되었다. UrlRuleSet은 다음과 같이 정의되었다:

응용프로그램은 또한 밑부분에 색상선택기(color picker)를 포함하며 사용자가 색상을 선택할 수 있도록 해준다. 색상이나 뷰가 바뀌면, URL에도 반영된다.

이 예제에서는 – 제작에 있어 한가지 중요한 차이점이 존재한다. 아래의 두 링크는 모두 똑같은 색상값을 가진다. 모든게 잘 동작하면, 이 예제들은 검붉은색 배경을 띄어야 한다. 다음 URL을 방문하면, 예상대로 잘 동작한다:

http://www.davidtucker.net/staging/urlkit/three/#;view=View0;color=10027008

그러나 다음 링크는 제대로 동작하지 않는다.

http://www.davidtucker.net/staging/urlkit/three/#;color=10027008

이유는 UrlRuleSet의 type 프로퍼티에 있다. UrlRuleSet은 URL을 매칭하기 위해 다음 세가지 중 한가지를 사용할 수 있기 때문이다.

• all (default) - Type 프로퍼티가 ‘all’로 되어 있다면 UrlRuleSet 내부의 모든 규칙은 URL과 반드시 모두 매칭 되어야 한다. 만약 단 하나의 규칙이라도 URL과 매칭되지 않는다면 모든 규칙이 맵핑되지 않는다.
• any - Type 프로퍼티가 ‘any’ 라면, 자식 규칙들중 어느 하나만이라도 맵핑된다면 다른것들은 맵핑되지 않아도 된다.
• one - Type 프로퍼티가 ‘one’ 이라면, UrlRuleSet 안의 첫번채 규칙이 URL과 맵핑 될 것이다.

이것이 바로 앞서 보여준 두번째 예제가 제대로 동작하지 않는 이유이다. 만약에 색상만 넘겼다면 viewRule은 매칭되지 않는다. 그럼에도 불구하고, 색상은 기본값을 가지기 때문에 view만 넘겨도 규칙들은 맵핑될 것이다. 다음 예제를 살펴보자:

URL: /index.html#/view1;minValue=2;maxValue=10

앞의 UrlRuleSet에는 4개의 자식 규칙들이 존재한다. 이 예제에서는 UrlRuleSet의 type 프로퍼티는 ‘all’ 이다. 이게 의미하는 바는 모든 규칙들이 맵핑되기 위해 반드시 매칭되어야 한다는 것을 의미한다. 이 경우에는 (앞서 적어놓은 URL 을 보면), 아무런 규칙들도 맵핑이 되지 않는다. 만약에 type 프로퍼티를 ‘any’로 설정하면 처음 3가지 규칙들은 URL과 매칭되어 실행될 것이다. 마지막으로, type 프로퍼티를 ‘one’ 으로 설정하면, 오직 첫번째 규칙만이 실행된다.(UrlRuleSet 의 첫번째 자식 규칙까지만 URL과 매칭된다.)

앞의 예제를 증거삼아보면, defaultValue 프로퍼티가 매우 중요할 수 있다는 것을 알수 있다. 그것은 URL을 분석하는 방법에 직접적인 영향을 미칠 수 있다. 만약 URL의 일부가 매칭되지 않는다면 그것은 defaultValue 로 대치될 것이다. 모든 규칙을 ‘선택사항’ 이라고 생각하거나 URL의 모든 값이 항상 반영되기를 원하진 않을것이다. – 꼭 devaultValue 를 사용하도록 한다. 또한, 응용프로그램에 디폴트 상태가 존재한다면, 아마도 그것은 URL 맵핑 규칙 지정이 필요할 것이다.

책임 위임

일찍이 언급했듯이, URLKit 는 root 파일내부가 아니더라도 자식 컴포넌트내에서 상태를 맵핑할 수가 있다. 이것을 가능하게 하기 위해서는, urlDelegateRule 을 사용해야 한다. UrlDelegateRule 은 대부분의 경우에 ‘rule’ 이라는 오직 한가지의 파라미터만이 필요한데 이것은 위임할 대상으로 맵핑할수 있는 규칙이다.

UrlNavigatorRule 과 같이 사용하면 UrlDelegateUrle의 속성을 사용하기가 쉽다. URLKit 문서에 의하면, “navigatorChildRule 은 UrlNavigatorRule 상의 특별하고, 결합가능한 프로퍼티이며 자식의 URL 규칙을 반환한다. Navigator의 선택된 자식에 변화가 생기면 언제든지 새롭게 갱신한다.” 개발자는 또한 navigatorChildRule에 사용할 표현을 선택할 수가 있다. (UrlNavigatorRule 이외의 다른 규칙을 사용한다면 이것은 필수적일 것이다) 하지만, 올바른 동작을 위해서는, 자식 컴포넌트들 각각의 UrlRuleSet 은 그들의 id 로 ‘urls’ 를 가져야만 한다.

다음 예제에는, 응용프로그램안에 3단계의 중첩된 구조가 있다:

• Main.mxml - 응용프로그램의 최상층은 TabNavigator 와 SampleView 로 기입된 3가지의 자식 컴포넌트를 가지고 있다. 그것은 URL의 첫번째 부분을 가지는 UrlRuleSet을 가지고, URL의 나머지 부분을 TabNavigator 의 현재 선택된 자식 컴포넌트로 위임한다.
• SampleView.mxml - 이 컴포넌트는 ChildView 라고 기입된 3개의 자식 컴포넌트와 함께 다른 TabNavigator를 포함한다. 그것은 UrlRuleSet을(‘urls’ id 와 함께) 포함한다. 규칙 세트는 URL의 첫번째 부분을 맵핑하는 UrlNavigatorRule을 포함한다. URL의 나머지 부분은 TabNavigator의 현재 선택된 자식에게 위임된다.
• ChildView.mxml - 이 컴포넌트는 HBox라고 기입된 3개의 자식 컴포넌와 함께 Accordian 을 포함한다. 그것은 URL의 마지막 부분을 Accordian에 맵핑하는 단일 UrlNavigatorRule 을 가진다.

[그림1] UrlDelegateRule 응용프로그램 샘플

Sample Application (소스 보기 가능)

결론

원컨대, URLKit 만큼 강력한 딥링킹 도구가 가지고 있는 가치가 무엇인지 깨달았다면 좋겠다. 만약에 URLKit이 여러분이 원했던 것 이상이라면, 아마도Flex 3 의 기본적인 딥링킹 기능을 확인해 보고 싶어 할것이다. 밑에 기능적인 부분 및 부가정보를 얻을 수 있도록 LiveDocs 링크를 포함해 두었다.

참고자료

URLKit at Google Code
URLKit Documentation
Using Flex 3’s Deep Linking Features in Flex 2
Flex 3 - Using the BrowserManager
Flex 3 Language Reference - BrowserManager