KR20140027507A

KR20140027507A - 웹 애플리케이션 아키텍처

Info

Publication number: KR20140027507A
Application number: KR1020147001839A
Authority: KR
Inventors: 라미로 칼보; 오나르 바이킹스타드; 윌리암 카케스; 찰스 에버렛 에드월; 후안 카밀로 핀존; 메간 프로스트; 재 우 장; 미샤 맥라클란; 에베랄도 코엘로
Original assignee: 애플 인크.
Priority date: 2011-07-26
Filing date: 2012-07-06
Publication date: 2014-03-06
Also published as: AU2012287409A1; EP2737402B1; JP2014522039A; JP5930236B2; US20130031462A1; CN103718161A; AU2012287409B2; CN103718161B; EP2737402A1; US9384101B2; WO2013015968A1; KR101702726B1

Abstract

웹 애플리케이션 아키텍처가 래퍼 애플리케이션을 이용하여 웹 브라우저 내에 가상 머신 환경을 제공할 수 있고 웹 애플리케이션들은 래퍼 애플리케이션 상에서 실행될 수 있다. 래퍼 애플리케이션은 웹 애플리케이션들에 대한 라이프 사이클 관리를 제공하고 환경 내의 웹 애플리케이션들 모두에 대한 로그인 및 로그아웃과 같은 다른 기능을 제공할 수 있다.

Description

웹 애플리케이션 아키텍처{WEB APPLICATION ARCHITECTURE}

본 출원은 2011년 7월 26일에 출원된 미국 특허 가출원 번호 61/511,938의 이득을 주장하고, 이 가출원은 참조로서 본 명세서에 통합된다.

본 발명은 웹 애플리케이션에 관한 것으로 특히 하나 이상의 웹 서버와 상호작용하여 특정 웹 서비스를 제공하는 클라이언트 장치 상의 웹 브라우저의 사용을 통해 이메일 서비스 또는 달력 서비스 또는 연락처 서비스 등과 같은 서비스들을 제공할 수 있는 웹 애플리케이션에 관한 것이다.

종래 기술에서의 웹 애플리케이션 시스템은 사용자가 웹 브라우저를 통해 이들의 이메일에 액세스하고 상호작용하도록 한다. 예를 들어, 웹 이메일은 사용자로 하여금 이메일 클라이언트보다는 표준 웹 브라우저의 사용을 통해 자신의 이메일을 보고 상호작용할 수 있게 한다. 예를 들어, 마이크로소프트사의 Exchange Server 상에서 유지되는 이메일 시스템들은 사용자로 하여금 네트워크에 연결될 수 있는 임의의 머신 상의 웹 브라우저를 통해 이들의 이메일, 달력, 및 연락처에 액세스할 수 있게 하여, 이메일 등에 액세스하는데 Entourage 또는 마이크로소프트 아웃룩을 사용할 필요가 없다. Comcast와 같은 인터넷 서비스 제공자, 구글 및 야후와 같은 인터넷 검색 제공자는 또한 기존의 웹 브라우저를 통해 사용자의 이메일 또는 다른 서비스로의 액세스를 가능하게 한다.

웹 애플리케이션 아키텍처의 다양한 실시예가 본 명세서에서 설명된다. 일 실시예에서, 웹 애플리케이션 아키텍처는 자신이 데이터 프로세싱 시스템의 오퍼레이팅 시스템 상에서 실행되는 표준 웹 브라우저 상에서 실행되도록 구성되는 래퍼(wrapper) 애플리케이션을 포함한다. 애플리케이션들의 세트는 래퍼 애플리케이션 상에서 실행되도록 구성되고(예컨대, 각 애플리케이션은 래퍼 애플리케이션의 아이프레임(iframe) 내에서 실행된다), 애플리케이션들의 세트 내의 각각의 애플리케이션은 데이터를 하나 이상의 웹 서버와 주고받도록 구성된다. 하나 이상의 웹 서버는 이메일 데이터, 달력 데이터, 연락처 데이터 및 기타 유형의 데이터를 저장할 수 있다. 래퍼 애플리케이션은 애플리케이션들의 세트 내의 각 애플리케이션에 대한 라이프 사이클 관리를 제공하도록 구성되고 애플리케이션들의 세트 내의 애플리케이션들 간의 전환을 제공할 수 있다. 래퍼 애플리케이션은 선점 다중 작업 오퍼레이팅 시스템(preemptive multitasking operating system)과 같은 또 다른 오퍼레이팅 시스템 상에서 자신이 실행되고 있는 웹 브라우저 상에서 실행되고 있는 가상 머신형 오퍼레이팅 시스템(virtual-machine-like operating system)으로 간주될 수 있다. 일 실시예에서, 애플리케이션들의 세트는 이메일 애플리케이션, 및 달력 애플리케이션, 및 연락처 또는 주소록 애플리케이션을 포함할 수 있다. 일 실시예에서, 세트 내의 각 애플리케이션이 표시되는 경우, 이는 실시예에 따라 가장 앞 애플리케이션으로 표시되고 다른 애플리케이션들은 완전히 가려지거나 부분적으로 희미해진다. 일 실시예에서, 각각의 애플리케이션은 표시되는 경우 웹 브라우저에 의해 제공되는 동일한 단일 웹 브라우저 윈도우 내에 표시된다. 일 실시예에서, 하나 이상의 애플리케이션 프로그래밍 인터페이스(Application Programming Interfaces; APIs)를 통해 래퍼 애플리케이션과 애플리케이션들의 세트 내의 각 애플리케이션 간에서 호출들이 전송될 수 있다. 이러한 호출들은 각 애플리케이션이 시작되는 경우 및 각각의 애플리케이션이 가장 앞에 있는 경우와 가장 앞에 있지 않은 경우 간에서 전환되는 경우 전송될 수 있다. 래퍼 애플리케이션에 의해 제공되는 라이프 사이클 관리는 애플리케이션들의 세트 내의 각각의 애플리케이션의 시작 및 종료를 포함할 수 있다. 더욱이, 래퍼 애플리케이션은 애플리케이션들의 세트 내의 각각의 애플리케이션의 실행을 지원하기 위해 래퍼 애플리케이션과 웹 브라우저 간에서 호출들을 전송할 수 있다. 일 실시예에서, 애플리케이션들의 세트 내의 각각의 애플리케이션이 맨 앞 상태에 있지 않은 경우(예컨대, 본 명세서에서 설명된 바와 같이 완전히 또는 부분적으로 가려지거나 유예(suspend)되는 경우) 실행되는 상태로 유지된다. 일 실시예에서, 래퍼 애플리케이션은 아이콘들의 세트를 표시할 수 있는데, 각 아이콘은 웹 브라우저로부터의 호출에 응답하여 애플리케이션들의 세트 내의 하나의 애플리케이션을 나타내고, 아이콘들의 세트는 선택하거나 전환할 이용가능한 애플리케이션들의 팔레트를 형성할 수 있다.

일 실시예에서, 본 발명에 따른 방법은 제1 오퍼레이팅 시스템을 실행하는 단계, 제1 오퍼레이팅 시스템 상에서 웹 브라우저를 실행하는 단계, 웹 브라우저 상에서 래퍼 애플리케이션을 실행하는 단계, 및 래퍼 애플리케이션에서 적어도 하나의 애플리케이션을 실행하는 단계를 포함할 수 있다. 래퍼 애플리케이션은 이메일 애플리케이션, 달력 애플리케이션, 연락처 또는 주소록 애플리케이션 등과 같은 애플리케이션들의 세트의 일부가 될 수 있는 적어도 하나의 애플리케이션을 위한 라이프 사이클 관리를 제공할 수 있다. 일 실시예에서, 방법은 또한 각 애플리케이션이 실행되거나 시작되거나 종료되는 경우 API를 통해 래퍼 애플리케이션과 애플리케이션들의 세트 내의 각각의 애플리케이션 간에서 적어도 하나의 호출을 전송하는 것을 포함할 수 있다. 더욱이, 방법은 또한 예컨대 제1 애플리케이션이 시작되는 경우 웹 브라우저와 래퍼 애플리케이션 간에서 적어도 하나의 호출을 전송하는 것을 포함할 수 있다. 적어도 하나의 호출의 전송은 API를 통해 호출 또는 소프트웨어 메시지의 발행, 개시, 불러오기 또는 수신 중 하나가 될 수 있다.

적어도 일부 실시예에서, 실행가능 프로그래밍 명령어들을 포함하는 머신 판독가능 비일시적 저장 매체가 본 명세서에서 설명된 방법들을 구현하는데 사용될 수 있다. 또한, 데이터 프로세싱 시스템이 본 명세서에서 설명된 바와 같이 작동하도록 구성될 수 있고, 이 데이터 프로세싱 시스템은 데스크탑 컴퓨터, 랩탑 컴퓨터, 태블릿 시스템, 스마트폰, 임베디드 디바이스, 및 기타 소비자 가전 제품과 같은 기타 전자 장치를 포함할 수 있다.

본 발명의 다른 특징은 첨부된 도면 및 아래의 상세한 설명을 통해 명백할 것이다.

위의 설명은 본 발명의 모든 양태 전체를 망라하는 목록을 포함하지 않는다. 본 발명은 위에서 설명되고 아래의 상세한 설명에 개시된 다양한 양태들의 모든 적절한 조합으로부터 실시될 수 있는 모든 시스템 및 방법을 포함하는 것이 고려된다.

본 발명은 제한적이지 않은 예로서 유사한 참조번호가 유사한 요소들을 나타내는 첨부된 도면들의 그림들에서 설명된다.
도 1은 웹 애플리케이션을 위한 소프트웨어 아키텍처의 예를 도시한 도면.
도 2는 본 발명의 일 실시예에 따른 흐름도 형태의 방법의 예를 도시한 도면.
도 3은 본 발명의 일 실시예에 따른 방법을 도시하는 흐름도.
도 4는 본 발명의 일 실시예를 나타내는 또 다른 흐름도.
도 5a 내지 5d는 본 발명의 일 실시예를 보여주는 또 다른 흐름도.
도 6은 하나 이상의 네트워크를 통해 하나 이상의 서버에 연결된 하나 이상의 클라이언트 장치로 웹 서비스를 제공하는 하나 이상의 네트워크를 통해 상호 연결된 복수의 시스템의 예를 도시한 도면.
도 7은 본 발명의 하나 이상의 실시예의 푸시 통지(push notification)를 구현하기 위한 방법의 예를 도시한 도면.
도 8a는 하나 이상의 웹 애플리케이션을 선택하는데 사용될 수 있는 일 실시예의 그래픽 사용자 인터페이스의 예를 도시한 도면.
도 8b는 하나 이상의 웹 애플리케이션을 선택하는데 사용될 수 있는 그래픽 사용자 인터페이스의 또 다른 예를 도시한 도면.
도 9는 하나 이상의 웹 애플리케이션을 선택하는데 사용될 수 있는 그래픽 사용자 인터페이스의 또 다른 예를 도시한 도면.
도 10은 하나 이상의 웹 애플리케이션을 선택하는데 사용될 수 있는 그래픽 사용자 인터페이스의 또 다른 예를 도시한 도면.
도 11은 이메일 웹 애플리케이션을 위한 그래픽 사용자 인터페이스의 예를 도시한 도면.
도 12는 연락처 또는 주소록 웹 애플리케이션을 위한 그래픽 사용자 인터페이스의 예를 도시한 도면.
도 13은 달력 웹 애플리케이션을 위한 그래픽 사용자 인터페이스의 예를 도시한 도면.
도 14는 지도 또는 지도 지원형(map assisted) 찾기 웹 애플리케이션을 위한 그래픽 사용자 인터페이스의 예를 도시한 도면.
도 15는 워드 프로세싱 문서, 프리젠테이션 문서, 및 스프레드시트 문서와 같은 사용자 문서로의 액세스를 허용하기 위한 그래픽 사용자 인터페이스의 예를 도시한 도면.
도 16은 본 발명의 다양한 실시예에서 사용될 수 있는 데이터 프로세싱 시스템의 예를 블록도 형태로 나타내는 도면.
도 17은 본 발명의 일부 실시예에서 사용가능한 소프트웨어 스택의 예시적인 실시예를 나타내는 도면.
도 18은 본 발명의 일부 실시예에서 사용가능한 예시적인 API 아키텍처의 블록도.

본 발명의 다양한 실시예 및 양태들이 아래에서 설명된 자세한 내용을 참조하여 설명되고, 첨부된 도면이 다양한 실시예를 나타낸다. 다음의 설명 및 도면은 본 발명의 예시적인 것이고 본 발명을 제한하는 것으로 해석되지 않는다. 다양한 구체적 사항들이 본 발명의 다양한 실시예들의 확실한 이해를 제공하기 위해 설명된다. 그러나, 특정 예에서, 본 발명의 실시예들의 간결한 설명을 제공하기 위해 공지의 또는 종래의 상세한 내용들은 설명되지 않는다.

본 명세서에서 "하나의 실시예" 또는 "일 실시예"라는 말은 실시예와 함께 설명된 특정 특징, 구조 또는 특성이 본 발명의 적어도 하나의 실시예에 포함될 수 있다는 것을 의미한다. 본 명세서의 다양한 부분에서 나오는 "일 실시예에서"라는 문구는 반드시 모두 동일한 실시예를 지시하지 않는다. 다음의 도면들에서 묘사된 프로세스들은 하드웨어(예컨대, 회로, 전용 로직 등), 소프트웨어 또는 이 둘의 조합을 포함하는 프로세싱 로직에 의해 수행된다. 프로세스들이 아래에서 일부 순차적인 동작으로 설명되지만, 설명된 일부의 동작들은 상이한 순서로 수행될 수 있음을 알 수 있다. 더욱이, 일부 동작들은 순차적이 아닌 병렬로 수행될 수 있다.

웹 애플리케이션 아키텍처는 가상 머신형 환경 또는 웹 브라우저 상에서 실행되는 오퍼레이팅 시스템을 제공할 수 있는 래퍼 애플리케이션을 활용할 수 있다. 이메일 애플리케이션 또는 달력 애플리케이션 또는 연락처 애플리케이션 또는 또 다른 애플리케이션과 같은 하나 이상의 웹 애플리케이션들의 세트가 애플리케이션들의 세트 내의 각각의 애플리케이션에 대한 라이프 사이클 관리를 제공할 수 있는 래퍼 애플리케이션의 위에서 실행될 수 있다. 래퍼 애플리케이션은 애플리케이션들의 세트 내의 애플리케이션들 간에서 전환되는 동안 애플리케이션들 각각이 그것들이 시작된 후에 계속해서 실행되도록 할 수 있고, 이것은 모두 단일 웹 브라우저 윈도우 내에서 수행될 수 있다. 래퍼 애플리케이션은 단일 로그인 포인트를 제공하여 애플리케이션들의 세트 내의 모든 웹 애플리케이션에 대해 사용자를 인증할 수 있고, 래퍼 애플리케이션은 로그아웃(또는 인증 시간의 만료)이 하나의 애플리케이션에서 발생하면 시작된 웹 애플리케이션들 전부에서의 자동 로그아웃을 제공할 수 있다. 이 아키텍처를 통해 생성된 이러한 환경은 예컨대 더 적은 윈도우가 오픈되면 되고 사용자가 단일 웹 브라우저 윈도우 내에 복수의 윈도우 또는 복수의 탭을 오픈할 필요 없이 애플리케이션들 간에서 전환하는 동안 각 실행 웹 애플리케이션의 상태 및 컨텍스트가 유지될 수 있기 때문에 사용자에게 더 나은 사용자 인터페이스를 제공할 수 있다. 이 환경은 또한 통지(예컨대, 푸시 통지)가 숨겨진 애플리케이션들에 대해 제공되도록 하고 애플리케이션 오류들이 다른 애플리케이션들에 영향을 주지 않고 고립되거나 회복되도록 할 수 있다.

도 1은 도 1에 도시된 소프트웨어 스택을 갖는 웹 애플리케이션 아키텍처의 예를 보여준다. 이 아키텍처(101)에서, 애플리케이션들의 세트(103)는 하나 이상의 API(106)를 통해 웹 브라우저(107) 상에서 실행되는 래퍼 애플리케이션(105)과 하나 이상의 API(104)를 통해 동작한다. 웹 브라우저(107)는 일 실시예에서 차례로 하나 이상의 API(108)를 통해 선점 다중 작업 오퍼레이팅 시스템(109) 상에서 실행되고; 또 다른 실시예에서 다중 작업 오퍼레이팅 시스템이 선점이 아니거나 다중 작업이 아닌 다른 공지의 오퍼레이팅 시스템으로 교체될 수 있다. 도 1의 소프트웨어 스택에 도시된 모든 소프트웨어는 데이터 프로세싱 시스템 상에서 동작하고, 특히 데이터 프로세싱 시스템(110)의 하드웨어 상에서 동작한다.

애플리케이션들의 세트(103)는 웹 이메일 애플리케이션, 웹 달력 애플리케이션, 웹 연락처 또는 주소록 애플리케이션, 웹 문서 애플리케이션(예컨대, iWork 문서들로의 액세스), 네비게이션을 위한 애플리케이션과 같은 지도 애플리케이션 또는 스마트폰 찾기와 같은 장치 찾기 애플리케이션, 및 하나 이상의 웹 서버와 통신하여 웹 애플리케이션과 하나 이상의 웹 서버 간에서 데이터를 교환하는 웹 브라우저를 통해 웹 애플리케이션으로 구현될 수 있는 기타 애플리케이션과 같은 웹 애플리케이션 또는 웹 서비스 애플리케이션일 수 있다. 이메일, 달력 데이터, 연락처 데이터 등과 같은 사용자 데이터는 하나 이상의 웹 서버에 저장될 수 있고 클라이언트 장치 상의 웹 브라우저를 통해 사용될 수 있다. 다양한 웹 애플리케이션을 위한 사용자 인터페이스의 예가 도 11 내지 15에 제공되고 아래에서 더 자세히 설명된다. 애플리케이션들의 세트 내의 이러한 애플리케이션들은 데이터 프로세싱 시스템 하드웨어(110)를 가질 수 있는 도 6에 도시된 클라이언트 장치(605)와 같은 하나 이상의 클라이언트 장치 상에서 동작할 수 있고, 클라이언트 장치는 도 16에 도시된 아키텍처를 가질 수 있으며 데스크탑 컴퓨터 또는 랩탑 컴퓨터 또는 태블릿 시스템 또는 스마트 폰, 또는 게임 콘솔과 같은 게임 장치 또는 기타 소비자 가전제품이 될 수 있다. 하나 이상의 API(104)가 애플리케이션들의 세트(103)와 래퍼 애플리케이션(105) 간에서의 기능 또는 동작을 위한 다양한 호출들을 제공할 수 있다. 도 4 및 5a 내지 5d는 이러한 API 및 이러한 API에 대한 호출의 예를 제공하고, API와 관련하여 추가적인 백그라운드 정보가 도 17 및 18과 함께 제공된다. 호출 또는 API와 관련한 "전송" 또는 "전송하는"이라는 용어는 API를 통해 호출 또는 소프트웨어 메시지를 발행 또는 개시 또는 불러오기 또는 수신하기 중 하나를 포함한다는 것이 이해될 것이다. 일 실시예에서, 애플리케이션들의 세트 내의 각각의 애플리케이션은 부분적으로 또는 전체가 자바스크립트로 작성될 수 있고, 일 실시예에서 각각의 애플리케이션은 일 실시예에서 자신이 적어도 부분적으로 자바스크립트로 작성될 수 있고 웹 브라우저(107) 상에서 실행되는 래퍼 애플리케이션(105) 내에서 실행되는 아이프레임 내에서 실행될 수 있다.

래퍼 애플리케이션(105)은 일 실시예에서 애플리케이션들의 세트(103)에 대한 가상 머신 환경을 제공할 수 있고 웹 브라우저(107) 상에서 실행될 수 있으며 래퍼 애플리케이션 및 웹 브라우저 간에서 API(106)를 통해 호출들을 전송할 수 있다. 도 5a 내지 5d는 API(106)를 통한 호출들의 일부 예를 제공한다. 일 실시예에서, 래퍼 애플리케이션은 웹 브라우저 내에 URL 텍스트 입력 필드를 가지고 웹 브라우저로의 호출들을 이용하여 URL 필드를 제어하며 웹 브라우저로의 호출들을 이용하여 제목 표시줄(title bar)을 제어한다; 예컨대, 래퍼 애플리케이션은 래퍼 애플리케이션 및 웹 브라우저 간의 호출들을 통해 현재의 가장 앞에 있는 애플리케이션을 반영하도록 제목 표시줄 내의 이름을 변경할 수 있다. 래퍼 애플리케이션이 어떻게 제목 표시줄 내의 이름을 제어하는지의 예가 도 11 내지 15에 도시된다. 래퍼 애플리케이션은 애플리케이션들의 세트 내의 각각의 애플리케이션에 대한 라이프 사이클 관리를 제공할 수 있다. 일 실시예에서, 이는 각각의 애플리케이션의 시작 및 종료를 포함할 수 있다. 더욱이, 래퍼 애플리케이션은 애플리케이션들 간에서의 전환 및 애플리케이션의 오류 처리(예컨대, 오작동 또는 고장난 애플리케이션 제거하기 및 사용자를 위한 애플리케이션 재시작 제공)를 포함하는 다른 특징, 기능 및 동작을 제공할 수 있다. 더욱이, 일 실시예에서 래퍼 애플리케이션은 비활성이거나 고장나거나 잘못 작동하는 애플리케이션을 강제 종료시킬 수 있다. 또한, 래퍼 애플리케이션은 사용자 및 애플리케이션들의 세트 내의 모든 애플리케이션에 대한 단일 로그인 및 단일 로그 아웃 포인트를 제공할 수 있다. 일 실시예에서, 래퍼 애플리케이션은 커널, 메모리 처리 및 프로세스 및 스레드의 동작 스케줄링과 같은 기존의 오퍼레이팅 시스템의 특정 기능을 포함하지 않을 수 있지만, 또 다른 실시예에서는, 래퍼 애플리케이션이 기존의 오퍼레이팅 시스템의 이러한 기능 또는 특징 또는 이러한 기능 또는 특징의 일부를 포함할 수 있다.

일 실시예에서, 래퍼 애플리케이션은 또한 애플리케이션들의 세트(103) 내의 하나 이상의 웹 애플리케이션에 대한 푸시 통지를 제공할 수 있고, 일 실시예에서 애플리케이션들의 세트(103) 내에서 가장 앞에 있는 애플리케이션 상의 사용자 인터페이스를 통해 가장 앞에 있지 않은 애플리케이션에 대한 푸시 통지가 표시되도록 할 수 있다. 일 실시예에서, 래퍼 애플리케이션 및 애플리케이션들의 세트(103)는 웹 브라우저의 메모리 공간에 의해 정의되는 메모리 공간에서 동작하고 래퍼 애플리케이션 및 애플리케이션들의 세트(103)가 실행되고 있는 웹 브라우저의 윈도우에 의해 정의되는 스레드 또는 프로세스 내에서 동작한다.

웹 브라우저(107)는 마이크로소프트의 인터넷 익스플로러, 또는 캘리포니아주 쿠퍼티노의 애플사의 사파리, 또는 파이어팍스 또는 오페라 또는 기타 알려진 웹 브라우저와 같은 종래의 웹 브라우저일 수 있다. 웹 브라우저는 HTML과 같은 마크업 언어로 인코딩된 웹 페이지를 프로세싱하는 소프트웨어 애플리케이션 프로그램이고; 웹 페이지는 하나 이상의 URL(Uniform Resource Locator)을 통해 웹 브라우저에 의해 검색된다. 일 실시예의 웹 브라우저는 웹 브라우저 내의 레이아웃 엔진을 이용하여 웹 페이지의 마크업 언어를 웹 페이지의 DOM(document object model)으로 프로세싱하도록 구성되고, 더욱이 웹 브라우저는 웹 페이지와 연관된 종속형 시트(cascading style sheet)를 프로세싱하여 웹 페이지를 표시하도록 구성될 수 있다. 일 실시예에서, 웹 브라우저(107)는 하나 이상의 API(108)를 이용하여 오퍼레이팅 시스템(109)과 상호작용할 수 있고, 이러한 API는 이 기술분야에 알려진 바와 같은 TCP/IP 등과 같은 윈도우 및 네트워크 기능을 위한 오퍼레이팅 시스템으로의 호출들을 지원할 수 있다.

도 2는 도 1에 도시된 소프트웨어 아키텍처와 함께 사용될 수 있는 방법의 예를 도시한다. 단계 201에서, 오퍼레이팅 시스템(109)과 같은 메인 오퍼레이팅 시스템이 시작되고 예컨대 도 6에 도시된 하나 이상의 클라이언트 장치가 될 수 있는 데이터 프로세싱 시스템(110) 상에서 실행되며 아래에서 설명된 도 16에 도시된 아키텍처를 가질 수 있다. 다음으로, 단계(203)에서 웹 브라우저가 메인 오퍼레이팅 시스템 상에서 실행되도록 웹 브라우저가 시작될 수 있는데; 웹 브라우저는 도 1에 도시된 오퍼레이팅 시스템(109) 상에서 실행되는 웹 브라우저(107)가 될 수 있다. 사용자는 공지의 웹 브라우저를 동작시켜 웹 페이지를 방문하거나, TV 쇼나 영화를 보거나 스포츠 이벤트 및 점수를 체크하거나 날씨나 주식을 체크하거나 알려진 기존의 웹 브라우저의 다른 사용을 할 수 있다. 또한, 사용자는 본 명세서에서 설명된 웹 메일 또는 기타 웹 서비스와 같은 웹 서비스를 이용하기로 결정할 수 있다. 이는 본 명세서에서 설명된 바와 같이 하나 이상의 웹 서비스에 대한 입력 포인트가 되는 특정 URL로 웹 브라우저를 보내 행해질 수 있다. 예를 들어, 일 실시예에서, 사용자는 웹 브라우저(107)의 URL 입력 필드에 "icloud.com"이라는 텍스트를 입력할 수 있다. icloud.com URL과 같은 이 명령의 입력에 응답하여, 래퍼 애플리케이션(105)이 시작되고 웹 브라우저(107) 상에서 실행되는데; 이는 도 2의 단계(205)로 나타난다. 도 2의 흐름도에서 래퍼 애플리케이션 및 이 애플리케이션 상에서 실행되는 애플리케이션들의 세트(103)는 이미 데이터 프로세싱 시스템에 설치되어 있는데; 예를 들어, 사용자는 이전에 이러한 웹 애플리케이션들을 사용하였고 이들은 도 5a 내지 5d와 관련하여 설명된 바와 같이 다운로드되었으며 웹 브라우저의 캐시들 내에 캐싱되었다. 본 명세서에서 설명된 바와 같이, 래퍼 애플리케이션 및 애플리케이션들의 세트(103) 내의 각각의 애플리케이션은 자바스크립트로 작성될 수 있다. 래퍼 애플리케이션이 단계(205)에서 시작된 후, 래퍼 애플리케이션은 단계(207)에서 웹 브라우저의 윈도우에 로그인 윈도우나 사용자 인터페이스를 표시하고; 사용자는 그 다음 예컨대 사용자 이름 및 사용자 패스워드와 같은 시스템이 필요로 하는 로그인 데이터를 입력할 수 있다. 그 다음, 시스템은 도 5a 내지 5d와 함께 설명된 방식으로 예컨대 도 6에 도시된 셋업 서비스(607)와 같은 셋업 서비스를 이용하여 사용자를 인증한다. 일 실시예에서, 단계(209)에서 래퍼 애플리케이션은 단일 로그인 프로세스를 통해 애플리케이션들의 세트(103)에서 실행되는 모든 애플리케이션에 대해 사용자를 인증하는데, 사용자나 사용자를 대신한 시스템에 의해 입력된 적절한 로그인 데이터에 응답하여 이렇게 인증한다. 또한, 일 실시예에서, 래퍼 애플리케이션은 래퍼 애플리케이션 및 셋업 애플리케이션들이 실행되고 있는 웹 브라우저의 윈도우가 예컨대 닫히는 경우 자동 로그아웃을 제공한다. 단계(211)에서, 인증 후에, 래퍼 애플리케이션은 일 실시예에서 사용가능한 애플리케이션들을 나타내는 아이콘들을 나타낼 수 있는데, 이들은 인증된 사용자가 이용가능한 애플리케이션들의 세트(103) 내의 애플리케이션들이다. 일 실시예에서, 이는 이메일 애플리케이션, 연락처 또는 주소록 애플리케이션, 달력 애플리케이션, 및 본 명세서에서 설명되거나 공지 기술의 기타 애플리케이션 또는 웹 애플리케이션을 포함할 수 있다. 단계(211)에서, 래퍼 애플리케이션은 웹 브라우저의 윈도우 내의 아이콘들을 나타내고, 사용자는 아이콘들 중 하나를 선택하여 애플리케이션들의 세트(103) 내의 해당하는 애플리케이션이 시작되고 이에 따라 실행되도록 할 수 있다. 선택적으로, 래퍼 애플리케이션은 애플리케이션들의 세트(103) 내의 가장 최근에 사용된 애플리케이션을 시작할 수 있고 아래에서 더 설명되는 바와 같이 애플리케이션들 간에서의 전환을 위해 사용될 수 있는 아이콘을 추가적으로 표시할 수 있다.

도 2는 도 1에 도시된 소프트웨어 스택을 작동시켜 실행되도록 하는데 사용될 수 있는 방법을 보여주고, 도 3은 그 소프트웨어 스택의 사용을 위한 일 실시예의 방법을 보여주는데, 이는 일 실시예에서 웹 브라우저(107) 상에서 자신이 실행되는 래퍼 애플리케이션(105) 내의 아이프레임에서 각각 실행되는 애플리케이션들의 세트(103) 내의 애플리케이션들 간의 전환을 포함한다. 단계(301)에서, 래퍼 애플리케이션(105)과 같은 래퍼 애플리케이션은 애플리케이션들의 세트(103) 내의 이용가능한 애플리케이션들을 나타내는 아이콘들을 웹 브라우저의 단일 윈도우 내의 사용자 인터페이스에 보여준다. 이러한 사용자 인터페이스의 예는 도 8a 및 도 8b에 도시된다. 이러한 아이콘들을 보여주는 다른 사용자 인터페이스가 또한 도 9 및 10에 도시된다. 사용자가 이 아이콘들 중 하나를 선택하는 경우, 이는 애플리케이션들의 세트(103) 내의 해당하는 애플리케이션이 이전에 시작되지 않은 경우 시작되도록 하고 이 애플리케이션이 가장 앞에 있도록 한다. 예를 들어, 단계(303)에서, 래퍼 애플리케이션은 단계(103)에서 제1 애플리케이션이라고 하는 아이콘들 중 하나의 선택을 수신한다. 선택은 사용자가 아이콘 상에 커서를 위치시키거나 사용자가 자신의 손가락 또는 공지 기술의 다른 입력 수단으로 아이콘을 탭핑하여 이루어질 수 있다. 이 선택에 응답하여 단계(305)에서, 래퍼 애플리케이션은 이전에 시작되지 않은 제1 앱 또는 애플리케이션을 시작하고 제1 앱이 가장 앞에 있는 앱 또는 애플리케이션이 되도록 한다. 가장 앞에 있지 않은 모든 다른 이용가능한 애플리케이션들은 사용자 인터페이스의 구현에 따라 완전히 가려지거나 부분적으로 희미해진다. 도 11 내지 15에 도시된 예에서, 가장 앞에 있지 않은 다른 이용가능한 애플리케이션들은 완전히 가려지고 사용자는 아이콘 또는 다른 명령을 선택하여 이들로 돌아가거나 전환할 수 있다. 일 실시예에서, 그 아이콘은 도 8a 및 8b 뿐만 아니라 도 11 내지 15에 도시된 아이콘(813)과 같은 전환 아이콘(switcher icon)이라고 할 수 있다. 그러한 아이콘의 선택은 도 8a 또는 8b에 도시된 아이콘들의 세트가 표시되도록 하거나, 각 아이콘이 인증된 사용자에 대한 이용가능한 애플리케이션들의 세트를 나타낸다. 제1 앱 또는 애플리케이션이 가장 앞에 있게 된 후에, 사용자는 이와 상호작용할 수 있다. 이는 단계(307)에 도시되는데, 여기서 제1 앱은 사용자 입력을 수신 및 처리하고 달력 서버 또는 이메일 서버 또는 연락처/주소록 서버 등과 같은 하나 이상의 웹 서버와 상호작용한다.

도 6은 하나 이상의 클라이언트 장치와 상호작용할 수 있는 이러한 웹 서버의 예를 도시한다. 사용자가 한 시점에서 사용자의 사무실에서의 사용자의 클라이언트 장치와 같은 하나의 클라이언트 장치를 사용하고 있을 수 있고, 또 다른 시점에서 사용자의 집에 있는 컴퓨터와 같은 또 다른 클라이언트 장치를 사용하고 있을 수 있으며, 각 경우 종래의 또는 표준 웹 브라우저가 웹 애플리케이션과 함께 사용되어 데이터에 액세스하고 도 6에 도시된 바와 같은 하나 이상의 웹 서버에 저장된 데이터와 상호작용할 수 있다.

일 실시예에서, 단계(307)에 도시된 바와 같이, 제1 앱은 웹 브라우저(107)에 의해 제공되는 웹 브라우저의 단일 윈도우 내에서 그 자신이 실행되고 있는 래퍼 애플리케이션(105) 내의 아이프레임 내에서 실행되고 있다. 제1 앱 사용 동안의 임의의 시점에서, 사용자는 애플리케이션들의 세트(103) 내의 이용가능한 다른 앱들 중 하나로 전환하기로 결정할 수 있고, 이는 단계(309)에 도시되는데 여기서 웹 브라우저는 일 실시예에서 애플리케이션을 전환하는 입력을 수신한다. 예를 들어, 웹 브라우저는 전환 아이콘(813)으로의 입력을 수신할 수 있고 호출을 통해 이 입력을 제1 앱으로 전달하고, 제1 앱은 순차적으로 래퍼 애플리케이션(105)을 호출하며, 래퍼 애플리케이션(105)은 그 다음 위에서 설명된 단계(301)에서와 같이 아이콘들을 표시한다. 예를 들어, 아이콘들의 세트가 다시 이용가능한 애플리케이션들의 세트를 나타내고 도 8a 또는 8b에 도시된 사용자 인터페이스나 도 9에 도시된 다른 사용자 인터페이스나 도 10에 도시된 다른 사용자 인터페이스에 표시될 수 있다. 단계(311)에 도시된 바와 같이, 래퍼 애플리케이션은 단계(309)에서 수신된 전환 입력에 응답하여 이전에 제1 앱을 디스플레이한 동일한 웹 브라우저의 단일 윈도우 내에 이용가능한 애플리케이션들의 아이콘들을 표시할 수 있다. 즉, 도 3의 방법은 동일한 단일 웹 브라우저 윈도우를 사용할 수 있다. 일 실시예에서, 래퍼 애플리케이션은 전환 아이콘의 선택 후에 아이콘들이 표시되는 경우 제1 앱을 완전히 감춘다. 예를 들어, 제1 앱이 도 11에 도시된 바와 같이 이메일 애플리케이션이고 사용자가 전환 아이콘(813)을 선택하면, 이는 도 8a에 도시된 아이콘들의 세트가 표시되도록 하고 이메일 애플리케이션(1101)은 더 이상 웹 브라우저의 단일 윈도우 내에 나타나지 않고 아이콘들의 세트가 표시되는 동안 완전히 시야에서 가려진다. 도 9는 애플리케이션들 간에서 전환하거나 애플리케이션들을 선택하는데 사용되는 아이콘들의 세트가 드로어(drawer) 영역이라고 할 수 있는 웹 브라우저의 윈도우 내의 영역에 디스플레이되는 동안 이전에 사용된 애플리케이션이 계속하여 표시되는 다른 사용자 인터페이스를 보여주고; 유사하게, 도 10은 도 3의 방법의 제1 앱과 같은 이전에 사용된 애플리케이션이 애플리케이션들의 세트(103) 내의 애플리케이션들 간에서 전환하거나 선택하는데 사용되는 아이콘들의 세트 뒤에 계속하여 표시되는 사용자 인터페이스의 예를 보여준다. 단계(313)에서, 시스템은 애플리케이션들의 세트(103) 내의 애플리케이션들 중 하나인 제2 앱이라고 할 수 있는 또 다른 애플리케이션의 선택을 수신한다. 이 선택에 응답하여, 래퍼 애플리케이션은 (이전에 시작되지 않은 경우) 제2 앱을 시작하고 제2 앱을 가장 앞에 있는 앱으로 만든다. 더욱이, 래퍼 애플리케이션은 모든 다른 실행되는 애플리케이션들이 적어도 부분적으로 가려지거나 희미해지도록 하는데, 이러한 다른 애플리케이션들은 일 실시예에서 여전히 저장된 컨텍스트 및 데이터로 실행중인 상태로 남을 수 있다. 따라서, 예를 들어, 만약에 사용자가 새로운 사람의 연락처 데이터를 입력하고 이 데이터를 입력하는 동안 달력 애플리케이션 또는 이메일 애플리케이션으로 전환하기로 결정한다면, 이 새로운 데이터 및 이 데이터의 컨텍스트는 적어도 부분적으로 숨겨져 있는 동안 저장된 상태로 남아 있고 이 숨겨진 애플리케이션들은 텍스트 입력 포커스의 컨텍스트 및 마지막 입력의 위치 뿐만 아니라 입력된 사용자 데이터를 포함하는 저장된 컨텍스트 및 데이터로 계속하여 실행한다. 일 실시예에서, 이는 마지막 실행된 애플리케이션 내에 표시된 모드 대화 상자(modal dialogue box)에도 적용될 수 있어 애플리케이션이 동일한 단일 웹 브라우저 윈도우 내에서 가장 앞에 있지 않은 동안에도 모드 대화 상자의 상태는 유지된다. 또한 단계(315)에서, 단계(311)에 의해 표시된 아이콘들의 세트는 또한 일 실시예에서 다른 앱들이 적어도 부분적으로 감추어지는 동안 사용자가 제2 애플리케이션 또는 제2 앱만을 보도록 제거될 수 있다.

단계 311, 313 및 315의 예가 이제 도 8b, 11 및 12를 참조하여 제공된다. 단계(311)는 일 실시예에서 인증된 사용자가 이용가능한 애플리케이션들의 세트(103)에 대한 아이콘들을 표시하는 도 8b에 도시된 사용자 인터페이스를 표시할 수 있다. 이러한 아이콘들의 표시는 전환 아이콘(813)을 선택하여 이루어질 수 있다. 사용자는 도 11에 도시된 이메일 웹 애플리케이션(1101)을 이전에 사용하고 있었고 애플리케이션들의 세트(103) 내의 연락처 웹 애플리케이션으로 전환하기로 결정하였다고 가정한다. 이는 전환 아이콘(813)을 선택하여 수행될 수 있다. 다른 실시예에서, 이는 풀다운 메뉴 또는 다른 메뉴 또는 공지 기술의 다른 사용자 인터페이스를 통해 애플리케이션들의 세트(103) 내의 이용가능한 애플리케이션들의 세트를 선택하여 수행될 수 있다. 전환 아이콘(813)의 선택은 사용자가 이전에 이메일 애플리케이션(1101)을 이용한 후에 도 8에 도시된 아이콘들을 표시하도록 한다. 그 다음 사용자는 도 8b에 도시된 연락처 아이콘을 선택하여 도 12에 도시된 연락처 애플리케이션(1201)의 사용자 인터페이스가 표시되도록 하는데, 이 연락처 애플리케이션은 단계(315)의 맥락에서 래퍼 애플리케이션(105)에 의해 시작되는 제2 앱이다. 이 시점에서 사용자는 닫기 명령을 선택하거나 도 8b에 도시된 닫기 버튼(807)을 선택하여 웹 브라우저 윈도우를 닫을 수 있다. 대안적으로, 사용자는 도 8b에 도시된 사인아웃 버튼(814)을 선택하여 로그아웃하거나 사인아웃하기로 결정할 수 있다. 이에 응답하여, 단계(317)에서, 래퍼 애플리케이션은 각 실행되는 애플리케이션이 자신의 데이터를 저장하도록 하고 그 다음 각 시작된 애플리케이션을 종료 및 해체(tear down)하고 각 시작된 애플리케이션에 대해 사용자를 로그아웃한다. 이러한 방법으로, 래퍼 애플리케이션은 단일 포인트를 제공하여 사용자가 모든 시작된 애플리케이션들을 처리하고 모든 시작된 애플리케이션들을 종료하며 각 웹 애플리케이션에 대한 웹 서비스로부터 로그아웃하도록 한다. 이러한 특정 실시예에서, 이는 사용자가 각 개별 웹 서비스로부터 로그아웃할 필요가 없기 때문에 사용자 인터페이스 및 사용자의 다양한 웹 서비스와의 상호작용을 단순화한다.

도 3에 도시된 방법은 애플리케이션들의 세트(103) 내의 두 애플리케이션의 사용을 보여주는데, 보다 많은 애플리케이션이 동시에 시작되어 사용될 수 있고, 이 모두는 일 실시예에서 탭 인터페이스 없이 동일한 웹 브라우저 윈도우 내에서 표시되고 이들 각각은 아이프레임으로서 실행되거나 동일한 웹 브라우저 윈도우 내의 웹 브라우저 상에서 실행되고 있는 래퍼 애플리케이션 내의 아이프레임 내에서 실행된다. 일 실시예에서, 그 웹 브라우저 윈도우의 메모리 공간이 또한 이 특정 웹 브라우저 윈도우에 할당된 메모리 공간 내에서 실행되도록 한정되는 래퍼 애플리케이션 및 애플리케이션들의 세트(103) 내의 각각의 애플리케이션으로 또한 할당된다.

도 4는 특정 호출들이 애플리케이션들의 세트(103) 내의 하나 이상의 애플리케이션 및 래퍼 애플리케이션(105) 간에서 전송되는 방법의 예를 도시한다; 이들 호출들은 본 명세서에서 설명된 하나 이상의 API(104)를 통해 이루어질 수 있다. 특정 API의 상세한 예가 또한 본 명세서에 포함된 제1 부록 및 제2 부록에 제공된다. 도 4에 도시되고 설명된 호출들은 또한 도 5a 내지 5d에 도시되고, 특히 도 5b 내의 스타트업 시퀀스(503) 및 백그라운드 시퀀스(505) 내에서 도시된다. 특히, 도 4에 도시된 방법은 도 5a 내지 5d에 도시된 흐름도에 따른 구현의 일 실시예의 스타트업 시퀀스 및 백그라운드 시퀀스로 수행되는 일부 호출들을 나타낸다. 단계(401)에서, 래퍼 애플리케이션은 도 4의 단계(401)에 도시된 호출을 하여 애플리케이션을 시작한다. 일 실시예에서, 이 호출은 그 다음 선택된 애플리케이션의 자바스크립트가 웹 브라우저(107)와 같은 웹 브라우저 상에서 실행되고 있는 래퍼 애플리케이션의 아이프레임 내에서 실행되도록 한다. 이 실시예에서, 시작된 앱은 래퍼 애플리케이션으로의 호출을 통해 앱이 준비되었다고 래퍼 애플리케이션에게 알린다; 도 4의 단계(403)는 이러한 호출의 예를 보여준다. 그 다음 단계(405)에서, 래퍼 애플리케이션은 이 앱이 가장 앞에 있게 된다고 알린다; 이러한 호출의 예는 도 4의 단계(405)에 도시된다. 일 실시예에서, 앱은 단계(407)까지 스타트업 시퀀스(503) 내에서 도시된 바와 같이 아이들(idle) 상태로 남아 있고 단계(407)에서 래퍼 애플리케이션은 예컨대 도 4의 단계(407)에서 도시된 바와 같이 래퍼 애플리케이션으로부터 앱으로의 호출에 의해 그 앱이 이제 가장 앞에 있다고 이 앱에 알린다. 이 시점에서, 사용자는 이제 가장 앞에 있는 앱과 상호작용할 수 있다. 예를 들어, 이 앱이 도 11에 도시된 이메일 앱(1101)과 같은 이메일 앱이면, 사용자는 예를 들어, 이메일을 읽고, 이메일에 응답하고, 이메일을 보내고, 새로운 이메일을 만들고, 이메일에 대한 새로운 폴더를 만들고, 폴더 내의 이메일을 볼 수 있다. 이메일 애플리케이션(1101)을 이용하는 프로세스 동안, 사용자는 자신의 달력 또는 자신의 주소록 등을 보려고 결정할 수 있는데, 이는 단계(409)에서와 같이 사용자가 또 다른 앱을 선택하도록 할 수 있다. 일 실시예에서, 이는 전환 아이콘(813)을 선택하거나 풀다운 메뉴 또는 다른 메뉴 구조 또는 공지 기술의 다른 사용자 인터페이스 내의 애플리케이션들의 메뉴로부터 또 다른 앱 또는 애플리케이션을 선택하여 수행될 수 있다. 이는 단계들(313 및 315)과 관련하여 설명된 바와 같이 다른 애플리케이션이 이전에 시작되지 않은 경우 시작되도록 한다. 더욱이, 단계들(401, 403, 405 및 407)이 단계(409)에서 선택된 또 다른 애플리케이션에 대해 반복될 수 있다. 반면, 래퍼 애플리케이션(105)은 단계(411)에서 이전에 시작되고 실행된 앱에게 백그라운드로 이동할 것이라고 알리는데, 이러한 호출의 예가 도 4에 도시된 단계(411)에서 제공된다. 백그라운드 상태는 완전히 또는 부분적으로 가려질 수 있다. 도 8b 및 11 내지 15와 관련하여 도시된 구현은 백그라운드 애플리케이션들이 완전히 숨겨지는 반면 가장 앞에 있는 애플리케이션이 웹 브라우저의 윈도우의 전체는 아니더라도 대부분을 차지하는 것으로 보이는 실시예를 수반한다. 단계(413)는 백그라운드로 이동되어 아이들 상태에 놓이는 임의의 애플리케이션이 계속하여 로딩되고 동작가능한 것을 보여주는데, 이의 실행가능한 코드 및 이 앱의 실행가능한 코드와 연관된 컨텍스트 및 데이터가 여전히 본 명세서에서 설명된 바와 같이 웹 브라우저에 의해 지정된 메모리 공간이 될 수 있는 메모리 내에 있다. 이는 사용자가 상이한 웹 서버들 상에 호스팅된 각각의 애플리케이션 간에서 전환하는 동안 상태 또는 로그인 또는 로그아웃을 저장할 필요없이 상이한 도메인 내의 상이한 웹 서버에 의해 호스팅되는 애플리케이션들 간에서 전환할 수 있게 한다. 이는 애플리케이션이 상이한 호스트 또는 웹 서버 상에서 가능하게는 복수의 서비스와 통신하도록 할 수 있다. 예를 들어, 세트(103) 내의 달력 웹 애플리케이션은 달력 웹 서버와 통신할 수 있지만, 일 실시예에서, 또한 동시에 연락처 웹 서버와 통신하여 연락처 웹 서버 상의 사용자의 주소록을 이용하여 달력 이벤트로의 초청객을 자동으로 완료할 수 있다. 일 실시예에서, 이는 애플리케이션들의 세트 내의 임의의 애플리케이션이 임의의 요청에 대한 응답으로 웹 서버들 중 어느 하나가 다르게 표시할 때까지 인증되는 사용자를 갖도록 보장하는 래퍼 애플리케이션(105)에 의해 달성될 수 있다. 일 실시예에서, 애플리케이션이 증명서 또는 인증 데이터가 무효라고 하는 응답을 웹 서버로부터 수신하면, 애플리케이션은 로컬 데이터와 캐시들을 없애고 래퍼 애플리케이션에게 사용자가 더이상 인증되지 않는다고 알려야 하며, 이 경우 래퍼 애플리케이션은 일 실시예에서 애플리케이션들의 세트 내의 모든 애플리케이션으로부터 사용자를 로그아웃할 수 있어, 사용자에게 사용자 이름 및 패스워드와 같은 인증 정보를 재입력하도록 요구한다.

도 5a 내지 5d의 흐름도는 도 1의 웹 브라우저(107)가 될 수 있는 웹 브라우저(517)를 실행하는 클라이언트 장치 및 하나 이상의 웹 서버와 같은 여러 기타 시스템 간의 상호작용을 보여준다. 특히, 인증 서버(515)는 도 6에 도시된 셋업 서비스(607)가 될 수 있고 앱 서버(521)는 도 6에 도시된 웹 서버(601A 또는 601B 또는 601C) 중 임의의 하나가 될 수 있다. 콘텐츠 분배 네트워크(519)는 서버들의 세트(601) 중 일부가 될 수 있거나 래퍼 애플리케이션 소프트웨어의 콘텐츠 및 래퍼 애플리케이션(105) 상에서 실행되는 애플리케이션들의 세트(103) 내의 애플리케이션들을 제공하도록 구성되는 별개의 서비스 또는 웹 서버가 될 수 있다. 애플리케이션 서버(521)는 예컨대 도 11에 도시된 이메일 애플리케이션(1101)을 위해 웹 메일을 제공하는 이메일 서버이거나 대안적으로 애플리케이션 서버(521)는 도 12에 도시된 연락처 애플리케이션(1201)을 위해 데이터를 제공하는 웹 서버가 될 수 있다는 것이 이해될 것이다. 따라서, 애플리케이션 서버(521)는 도 6의 이메일 서버(601A)가 될 수 있거나 도 6에 도시된 달력 서버(601)가 될 수 있거나 도 6에 도시된 연락처 서버(601B)가 될 수 있거나 웹 애플리케이션과 상호작용하는 기타 웹 서버가 될 수 있다. 도 5a 내지 5d에 도시된 방법은 사용자가 ULR www.icloud.com 또는 다른 URL을 도 1에 도시된 웹 브라우저(107)가 될 수 있는 웹 브라우저(517) 내의 URL 텍스트 입력 필드에 입력하면서 시작될 수 있다. 만약 애플리케이션들의 세트 및 래퍼 애플리케이션이 이전에 웹 브라우저의 캐시에 캐싱되지 않았다면, 도 5a에 도시된 바와 같이, 하나 이상의 GET 요청이 도 5a에 도시된 바와 같이 브라우저로 반환되는 애플리케이션들의 세트 및 래퍼 애플리케이션을 요청하는 브라우저에 의해 수행될 수 있다. 도 5a에 도시된 래퍼 애플리케이션은 로그인 사용자 인터페이스를 보여주고, 적절한 인증 로그인에 응답하여, 사용자가 제1 GET 요청에 응답하여 래퍼 애플리케이션을 얻은 후에 애플리케이션들의 세트를 얻을 수 있다. 사용자가 유효한 인증 또는 로그인 데이터를 표시한 후에, 브라우저(517)는 도 6에 도시된 셋업 서버(607)가 될 수 있는 인증 서버(515)와 통신한다. 특히, 도 6을 참고하면, 클라이언트 장치(605)는 인터넷(603)과 같은 하나 이상의 네트워크를 통해 사용자 이름 및 패스워드를 포함할 수 있는 로그인 정보를 제공하여 셋업 서비스(607)와 통신한다. 유효한 로그인 정보에 응답하여, 셋업 서버(607)는 하나 이상의 쿠키 형태일 수 있는 (SSL 및 HTTP로만 마킹되어 자바스크립트가 볼 수 없는) 인증 토큰과 웹 애플리케이션(103)이 사용하는 적절한 이메일 서버 및 다른 서버의 하나 이상의 주소를 돌려 보낸다; 일 실시예에서의 주소들은 도 5a 및 5c에 도시된 바와 같이 "백(bag)"이라고 할 수 있다. 적절한 웹 서버로부터 데이터를 수신한 후에, 세트(103) 내의 한 애플리케이션이 자신의 사용자 인터페이스를 표시한다(예컨대, 애플리케이션들의 세트(103) 내의 이메일 애플리케이션의 경우, 도 11에 도시된 바와 같은 이메일 앱(1101)이 웹 브라우저의 윈도우 내에 도시된다). 이는 도 5a의 로그인 시퀀스(501)에 도시된 로그인 프로세스를 완료한다. 다운로드된 애플리케이션들 및 다운로드된 래퍼 애플리케이션은 일 실시예에서 웹 브라우저의 캐시들 내에 유지될 수 있어 이들은 예를 들어, 브라우저가 재시작되거나 메인 오퍼레이팅 시스템이 재시작되거나 재가동될 때마다 반복하여 다운로드될 필요가 없다. 또 다른 실시예에서, 래퍼 애플리케이션 및 애플리케이션들의 세트(103) 내의 각각의 애플리케이션은 각 사용자 로그인시에 다운로드될 수 있다.

도 5a 내지 5d는 도 5a 내지 5d에서 "클라우드 OS"라고 하는 래퍼 애플리케이션 및 애플리케이션들의 세트(103) 내의 하나 이상의 애플리케이션 간에서의 특정 호출들의 예를 보여준다. 도 5a 내지 5d는 또한 클라우드키트(Cloudkit) API라고 할 수 있는 API로 이루어지는 호출들(예컨대, 도 5b에 도시된 "Cloudkit: GET/startup...")을 보여주고, 이 API는 애플리케이션들의 세트에 대한 소프트웨어 프레임워크를 제공한다. 클라우드 OS 래퍼 애플리케이션에 대한 특정 API의 예는 제1 부록에 제공된다. 클라우드키트 API에 대한 특정 API의 예는 제2 부록에 제공된다. 도 5a 내지 5d는 또한 앱 및 웹 브라우저에 의해 수행되는 동작 또는 호출을 나타낸다. 도 5c 내지 5d는 또한 시퀀스(507)로 도시된 401 시퀀스 및 종료 시퀀스(509)에서 발생하는 호출 및 동작의 예를 제공한다.

도 6은 본 명세서에서 설명된 웹 애플리케이션 아키텍처를 이용하는 동안 하나 이상의 네트워크를 통해 하나 이상의 클라이언트 장치와 동작할 수 있는 하나 이상의 웹 서버의 예를 보여준다. 애플리케이션들의 세트(103)는 래퍼 애플리케이션(105) 및 웹 브라우저(107)와 함께 하나 이상의 네트워크(603)에 연결된 클라이언트 장치(605) 상에서 실행되어 이에 따라 웹 서버(601A, 601B, 또는 601C) 또는 (지도 또는 네비게이션 서버 또는 iWork 문서 서버 또는 기타 웹 애플리케이션을 위한 웹 서버와 같은) 도시되지 않은 기타 웹 서버와 같은 하나 이상의 웹 서버와 통신할 수 있다. 클라이언트 장치는 동시에 이들 웹 서버 각각에 연결될 수 있고, 그것들의 해당하는 앱들 각각은 본 명세서에서 설명된 바와 같이 실행된다. 도 6에 도시된 웹 서버와 같은 웹 서버들의 세트는 상이한 도메인(예컨대, icloudemail.com과 같은 이메일 서버를 위한 하나의 도메인 및 icloudcalendar.com과 같은 달력 서버를 위한 또 다른 도메인)에 있을 수 있다; CORS(Cross-Origin Resource Sharing)를 지원하는 사파리 및 파이어폭스와 같은 웹 브라우저의 경우, CORS가 크로스 도메인 요청을 위해 사용될 수 있다. 다른 웹 브라우저의 경우, 아이프레임이 포스트메시지(postMessage)를 통해 부모 웹 브라우저 윈도우와 통신하는 XHR(XML HTTP Request)을 프록시하는데 사용될 수 있다. 셋업 서비스(607)는 도 5a 내지 5d에 도시된 인증 서버(515)와 함께 도시된 방법으로 작동할 수 있는 하나 이상의 셋업 서버(607)가 될 수 있다.

도 7은 통지를 하나 이상의 웹 서버로부터 래퍼 애플리케이션(105)의 아이프레임에서 실행되고 있는 특정 애플리케이션으로 송신하는데 푸시 통지가 사용될 수 있는 방식의 예를 도시한다. 푸시 통지는 이메일 서버(601) 또는 달력 서비스(601B) 또는 연락처 서버(601C)와 같은 웹 서버들 중 어느 하나에 의해 시작될 수 있어, 통지를 클라이언트 장치(605)와 같은 클라이언트 장치 상의 웹 브라우저(705)로 제공한다. 웹 브라우저는 호출을 통해 이를테면 API(106)를 통해 클라이언트 장치 상의 웹 브라우저에서 실행되고 있는 래퍼 애플리케이션(105)과 같은 래퍼 애플리케이션으로 통신할 수 있다. 래퍼 애플리케이션은 그 다음 이 통지를 앱으로 보내고 이 앱은 단계(709)에 도시된 바와 같이 푸시 통지를 보낸 적절한 웹 서버와 상호작용할 수 있다.

도 8a는 본 발명의 일 실시예에 따른 디스플레이 장치(801) 상의 사용자 인터페이스의 예를 도시한다. 디스플레이 장치(801)는 데이터 프로세싱 시스템 하드웨어(110)의 일부가 될 수 있는 도 16의 디스플레이(1670)가 될 수 있다. 사용자 인터페이스는 도 1에 도시된 소프트웨어 스택에 의해 생성될 수 있다. 도 8a에 도시되지 않은 다른 윈도우들이 또한 공지된 바대로 데스크탑(802) 내의 디스플레이 장치(801) 상에 디스플레이될 수 있음을 알 수 있다. 사용자 인터페이스는 디스플레이 장치(801)의 스크린의 맨 위에 보여지는 메뉴 바(803)를 포함할 수 있다; 스크린의 바닥 또는 윈도우(804)와 같은 각 윈도우의 내부 등의 메뉴 바의 대안적인 위치들이 사용될 수 있음을 알 수 있다. 도 8a에 도시된 예는 메뉴 바(803)가 스크린의 맨 위에 있는 Mac OS X로 알려진 매킨토시 오퍼레이팅 시스템의 사용자 인터페이스와 비슷하다. 웹 브라우저가 현재 실행되고 있는데, 이는 일 실시예에서 매킨토시 오퍼레이팅 시스템이 될 수 있는 오퍼레이팅 시스템(109) 상에서 실행되는 웹 브라우저(107)가 될 수 있고, 대안적으로 윈도우즈 등과 같은 다른 오퍼레이팅 시스템들이 이용될 수 있다. 웹 브라우저는 래퍼 애플리케이션(105) 및 애플리케이션들의 세트(103)가 실행될 수 있는 웹 브라우저 윈도우(804)를 나타내고 있다. 웹 브라우저 윈도우(804)는 URL 텍스트 입력 필드(806) 및 본 명세서에서 설명된 바와 같이 일 실시예에서 래퍼 애플리케이션(105)에 의해 소유되거나 제어되는 제목을 포함하는 제목 표시줄(805)을 포함한다. 웹 브라우저 윈도우(804)는 또한 닫기 버튼(807) 및 뒤로 및 앞으로 가기 버튼(808 및 809)을 포함한다. 뒤로 및 앞으로 가기 버튼(808 및 809)은 웹 브라우저에 사용되는 기존의 뒤로 및 앞으로 가기 버튼일 수 있다. 웹 브라우저 윈도우(804)는 또한 본 명세서에서 설명된 바와 같이 사용될 수 있는 전환 아이콘(813) 및 로그아웃 아이콘(814)을 디스플레이한다. 웹 브라우저 윈도우(804)에 의해 표시되는 사용자 인터페이스는 각각 애플리케이션들의 세트(103) 내의 하나의 애플리케이션을 나타내는 아이콘들의 세트를 포함한다. 예를 들어, 아이콘(810)은 애플리케이션들의 세트(103) 내에 있는 메일 또는 이메일 애플리케이션을 나타낼 수 있고 아이콘(811)은 애플리케이션들의 세트(103) 내의 연락처 애플리케이션을 나타낼 수 있으며, 아이콘(812)은 애플리케이션들의 세트(103) 내의 달력 애플리케이션을 나타낼 수 있다. 사용자가 이러한 아이콘들 중 하나를 선택하는 경우, 래퍼 애플리케이션(105)은 본 명세서에서 설명된 바와 같이 선택된 아이콘에 대응하는 선택된 애플리케이션이 (이전에 시작되지 않은 경우) 시작되도록 한다.

도 11 내지 15는 애플리케이션들의 세트(103) 내에 있는 특정 애플리케이션 또는 웹 애플리케이션의 예를 제공한다. 특히, 도 11은 제목 표시줄(805) 내에 "메일"이라는 단어에 의해 표시된 이메일 애플리케이션을 보여준다. 이전에 설명된 바와 같이, 래퍼 애플리케이션은 웹 브라우저와의 호출들의 세트를 통해(예컨대, API(106)를 통해) 제목 표시줄(805)을 제어하거나 소유하고 현재 가장 앞에 있는 애플리케이션에 대한 적절한 제목을 제공할 수 있다. 도 12는 일 실시예에서 애플리케이션들의 세트(103)의 일부인 연락처 또는 주소록 애플리케이션의 사용자 인터페이스의 예를 보여준다. 도 13은 일 실시예에서 애플리케이션들의 세트(103) 내의 하나의 애플리케이션인 달력 애플리케이션의 사용자 인터페이스의 예를 보여준다.

도 14는 스마트폰과 같은 장치를 찾는데 사용될 수 있는 지도 애플리케이션의 예를 보여주는데, 이는 일 실시예에 따라 애플리케이션들의 세트(103) 내의 하나의 애플리케이션이 될 수 있다. 도 15는 사용자로 하여금 프리젠테이션 문서, 워드 프로세싱 문서, 및 스프레드시트와 같은 문서의 집합에 액세스하고 및/또는 이들과 상호작용할 수 있게 하는 사용자 인터페이스의 예이다; 특히, 문서 애플리케이션(1501)은 사용자가 하나 이상의 웹 서버 상에 사용자에 의해 저장된 문서와 상호작용하도록 한다.

도 16은 본 발명의 일부 실시예에서 사용될 수 있는 컴퓨터 시스템과 같은 예시적인 데이터 프로세싱 시스템을 도시하는 블록도이다. 도 16이 컴퓨터 시스템의 다양한 구성요소들을 보여주는데, 이 구성요소들을 상호연결하는 임의의 특정 아키텍처 또는 방법은 본 발명에 밀접한 관련이 없기 때문에 자세히 설명하지는 않는다는 것이 이해되어야 한다. 더 적은 구성요소 또는 더 많은 구성요소를 갖는 기타 컴퓨터 시스템과 같은 기타 데이터 프로세싱 시스템이 또한 본 발명에 사용될 수 있다는 것을 알 것이다.

도 16에 도시된 바와 같이, 데이터 프로세싱 시스템의 형태인 시스템(1600)은 프로세싱 시스템(1620), 전원(1625), 메모리(1630) 및 비휘발성 메모리(1640)(예컨대, 하드 드라이브, 플래시 메모리, 위상 변화 메모리(Phase-Change Memory; PCM) 등)에 결합된 버스(들)(1650)를 포함한다. 버스(들)(1650)는 이 기술분야에 공지된 바와 같은 다양한 브릿지, 컨트롤러, 및/또는 어댑터를 통해 서로 연결될 수 있다. 프로세싱 시스템(1620)은 메모리(1630) 및/또는 비휘발성 메모리(1640)로부터 저장된 명령어(들)를 검색할 수 있고, 위에서 설명된 바와 같이 명령어들을 실행하여 동작을 수행할 수 있다. 버스(1650)는 위의 구성요소들을 함께 상호연결하고 또한 이러한 구성요소들을 선택적 도크(1660), 디스플레이 컨트롤러 및 디스플레이 장치(1670), 입력/출력 장치(1680)(예컨대, NIC(네트워크 인터페이스 카드), 커서 제어(예컨대, 마우스, 터치 스크린, 터치 패드 등), 키보드 등), 및 선택적 무선 송수신기(들)(1690)(예컨대, 블루투스, WiFi, 적외선, 셀룰라 전화 수신기 등)와 상호 연결한다. 데이터 프로세싱 시스템(1600)은 핸드헬드 컴퓨터, PDA(personal digital assistant), 모바일 전화, 휴대용 게임 시스템, 휴대용 매체 재생기, 태블릿 또는 모바일 전화, 매체 재생기, 및/또는 게임 시스템을 포함할 수 있는 핸드헬드 컴퓨팅 장치, 또는 기타 유형의 소비자 가전제품이 될 수 있다. 또 다른 예로, 데이터 프로세싱 시스템(1600)은 네트워크 컴퓨터 또는 또 다른 장치 내의 임베디드 프로세싱 장치가 될 수 있다.

하나 이상의 애플리케이션 프로그래밍 인터페이스(API)가 일부 실시예에서 사용될 수 있다. API는 프로그램 코드 구성요소 또는 하드웨어 구성요소(이하 "API-구현 구성요소")에 의해 구현되는 인터페이스인데, 이는 상이한 프로그램 코드 구성요소 또는 하드웨어 구성요소(이하 "API-호출 구성요소")가 하나 이상의 함수, 메소드, 절차, 데이터 구조, 클래스, 및/또는 API-구현 구성요소에 의해 제공되는 기타 서비스에 액세스하고 이를 이용하도록 한다. API는 API-호출 구성요소와 API-구현 구성요소 간에서 전달되는 하나 이상의 파라미터를 정의할 수 있다.

API는 (제3자 개발자가 될 수 있는) API-호출 구성요소의 개발자로 하여금 API-구현 구성요소에 의해 제공되는 구체적 특징을 레버리징할 수 있게 한다. 하나의 API-호출 구성요소가 존재할 수 있거나 하나보다 더 많은 그러한 구성요소가 존재할 수 있다. API는 애플리케이션으로부터의 서비스 요청을 지원하기 위해 컴퓨터 시스템 또는 프로그램 라이브러리가 제공하는 소스 코드 인터페이스가 될 수 있다. 오퍼레이팅 시스템(OS)은 복수의 API를 가져 OS 상에서 실행되는 애플리케이션들이 하나 이상의 이러한 API를 호출할 수 있게 하고, (프로그램 라이브러리와 같은) 서비스는 복수의 API를 가져 서비스를 이용하는 애플리케이션이 하나 이상의 이러한 API를 호출할 수 있게 한다. API는 애플리케이션이 만들어질 때 해석되거나 컴파일될 수 있는 프로그래밍 언어에 대해 구체화될 수 있다.

일부 실시예에서 API-구현 구성요소는 하나 보다 많은 API를 제공할 수 있는데, 이들 각각은 API-구현 구성요소에 의해 구현되는 기능의 상이한 양상들에 액세스하는 상이한 양상들의 상이한 시각 또는 상이한 양상들을 갖는 상이한 시각을 제공한다. 예를 들어, API-구현 구성요소의 하나의 API는 제1 세트의 기능을 제공할 수 있고 제3자 개발자에게 노출될 수 있으며, API-구현 구성요소의 또 다른 API는 (노출되지 않고) 숨겨질 수 있으며, 제1 세트의 기능들 중의 서브세트를 제공하고, 또한 또 다른 기능 세트, 이를테면 제1 기능 세트 내에 있지 않은 테스트 또는 디버그 기능을 제공할 수 있다. 다른 실시예들에서 API-구현 구성요소는 그 자체가 기저의 API를 통해 하나 이상의 다른 구성요소를 호출할 수 있고 따라서 API-호출 구성요소 및 API-구현 구성요소 양자가 될 수 있다.

API는 API-호출 구성요소들이 API-구현 구성요소의 특정 기능에 액세스하고 이를 사용하는 경우 사용하는 언어 및 파라미터를 정의한다. 예를 들어, API-호출 구성요소는 API에 의해 노출된 하나 이상의 API 호출 또는 불러오기(예컨대 함수 또는 메소드 호출에 의해 구체화됨)를 통해 API-구현 구성요소의 특정 기능에 액세스하고 API 호출 또는 불러오기를 통해 파라미터를 이용하여 데이터 및 제어 정보를 전달한다. API-구현 구성요소는 API-호출 구성요소로부터의 API 호출에 응답하여 API를 통해 값을 반환할 수 있다. API가 API 호출의 구문(syntax) 및 결과를 (예컨대, 어떻게 API 호출을 불러올지 및 API 호출이 무엇을 하는지) 정의하는 한편, API는 API 호출이 어떻게 API 호출에 의해 지정된 함수를 달성하는지를 드러내지 않을 수 있다. 다양한 API 호출들이 호출(API-호출 구성요소) 및 API-구현 구성요소 간의 하나 이상의 애플리케이션 프로그래밍 인터페이스를 통해 전송된다. API 호출들을 전송하는 것은 함수 호출 또는 메시지의 발행, 개시, 불러오기, 호출, 수신, 반환, 또는 이에 응답을 포함할 수 있다; 즉, 전송은 API-호출 구성요소 또는 API-구현 구성요소에 의한 동작들을 나타낼 수 있다. API의 함수 호출 또는 다른 불러오기는 파라미터 목록 또는 다른 구조를 통해 하나 이상의 파라미터를 보내거나 받을 수 있다. 파라미터는 상수, 키, 데이터 구조, 객체, 객체 클래스, 변수, 데이터 유형, 포인터, 어레이, 목록 또는 함수 또는 메소드로의 포인터 또는 API를 통해 전달될 데이터 또는 다른 아이템을 참조하는 다른 방식이 될 수 있다.

더욱이, 데이터 유형 또는 클래스는 API에 의해 제공되어 API-구현 구성요소에 의해 구현될 수 있다. 따라서, API-호출 구성요소는 변수를 선언하고, 포인터를 사용하며, API에 제공된 정의를 이용하여 이러한 유형 또는 클래스의 상수값을 사용하거나 인스턴스화(instantiate)할 수 있다.

일반적으로, API는 API-구현 구성요소에 의해 제공되는 서비스 또는 데이터로 액세스하거나 API-구현 구성요소에 의해 제공되는 동작 또는 계산의 수행을 개시하는데 사용될 수 있다. 예로서, API-구현 구성요소 및 API-호출 구성요소는 각각 오퍼레이팅 시스템, 라이브러리, 장치 드라이버, API, 애플리케이션 프로그램, 또는 기타 모듈 중 어느 하나가 될 수 있다(API-구현 구성요소 및 API-호출 구성요소는 동일한 유형의 모듈이거나 서로 상이한 유형의 모듈일 수 있다는 것이 이해되어야 한다). 일부 경우에서 API-구현 구성요소는 적어도 부분적으로 펌웨어, 마이크로코드 또는 기타 하드웨어 로직으로 구현될 수 있다. 일부 실시예에서, API는 클라이언트 프로그램이 소프트웨어 개발 키트(Software Development Kit; SDK) 라이브러리에 의해 제공되는 서비스들을 사용할 수 있게 한다. 다른 실시예에서 애플리케이션 또는 다른 클라이언트 프로그램은 애플리케이션 프레임워크에 의해 제공되는 API를 사용할 수 있다. 이러한 실시예에서 애플리케이션 또는 클라이언트 프로그램은 SDK에 의해 제공되고 API에 의해 제공되는 함수 또는 메소드로의 호출들을 통합할 수 있거나 SDK에 정의되고 API에 의해 제공되는 데이터 유형 또는 객체들을 사용할 수 있다. 애플리케이션 프레임워크는 이들 실시예에서 이 프레임워크에 의해 정의되는 다양한 이벤트에 응답하는 프로그램에 대한 메인 이벤트 루프를 제공할 수 있다. API는 애플리케이션이 애플리케이션 프레임워크를 이용하여 이벤트들 및 이 이벤트들에 대한 응답들을 특정할 수 있게 한다. 일부 실시예에서, API 호출은 애플리케이션에게 입력 성능 및 상태, 출력 성능 및 상태, 프로세싱 성능, 전력 상태, 저장 용량 및 상태, 통신 성능 등과 같은 양태들에 관련된 것들을 포함하는 하드웨어 장치의 성능 또는 상태를 리포트할 수 있고, API는 펌웨어, 마이크로코드 또는 하드웨어 구성요소 상에서 부분적으로 실행되는 기타 로우 레벨 로직에 의해 부분적으로 구현될 수 있다.

API-호출 구성요소는 네트워크 상에서 API를 통해 API-구현 구성요소와 통신하는 원격 구성요소(즉, API-구현 구성요소와는 다른 데이터 프로세싱 시스템 상의 구성요소) 또는 로컬 구성요소(즉, API-구현 구성요소와 동일한 데이터 프로세싱 시스템 상의 구성요소)가 될 수 있다. API-구현 구성요소는 또한 API-호출 구성요소로서 동작할 수 있고(즉, 이는 상이한 API-구현 구성요소에 의해 노출된 API로 API 호출들을 할 수 있고), API-호출 구성요소는 또한 상이한 API-호출 구성요소에 노출되는 API를 구현하여 API-구현 구성요소로서 동작할 수 있다.

API는 상이한 프로그래밍 언어로 작성된 복수의 API-호출 구성요소들이 API-구현 구성요소와 통신할 수 있게 한다(따라서 API는 API-구현 구성요소 및 API-호출 구성요소 간에서 호출 및 리턴을 번역하기 위한 특징을 포함할 수 있다); 그러나, API는 특정 프로그래밍 언어에 의해 구현될 수 있다. 일 실시예에서, API-호출 구성요소는 상이한 제공자로부터 API들, 이를테면 OS 제공자로부터의 API 세트, 플러그인 제공자로부터의 또 다른 API 세트 및 또 다른 제공자(예컨대, 소프트웨어 라이브러리의 제공자) 또는 또 다른 API 세트의 생성자로부터의 또 다른 API 세트를 호출할 수 있다.

도 18은 본 발명의 일부 실시예에서 사용될 수 있는 예시적인 API 아키텍처를 도시한 블록도이다. 도 18에 도시된 바와 같이, API 아키텍처(1800)는 API(1820)를 구현하는 API-구현 구성요소(1810)(예컨대, 오퍼레이팅 시스템, 라이브러리, 장치 드라이버, API, 애플리케이션 프로그램, 소프트웨어 또는 기타 모듈)를 포함한다. API(1820)는 API-호출 구성요소(1830)에 의해 사용될 수 있는 API-구현 구성요소의 하나 이상의 함수, 메소드, 클래스, 객체, 프로토콜, 데이터 구조, 포맷 및/또는 기타 특징을 명시한다. API(1820)는 API-구현 구성요소 내의 함수가 API-호출 구성요소로부터 파라미터를 수신하는 방식 및 함수가 결과를 API-호출 구성요소로 반환하는 방식을 명시하는 적어도 하나의 호출 기법을 지정할 수 있다. API-호출 구성요소(1830)(예컨대, 오퍼레이팅 시스템, 라이브러리, 장치 드라이버, API, 애플리케이션 프로그램, 소프트웨어 또는 기타 모듈)는 API(1820)를 통해 API 호출을 하여 API(1820)에 의해 지정된 API-구현 구성요소(1810)의 기능들에 액세스하고 이를 이용할 수 있다. API-구현 구성요소(1810)는 API 호출에 응답하여 API(1820)를 통해 값을 API-호출 구성요소(1830)로 반환할 수 있다.

API-구현 구성요소(1810)는 API(1820)를 통해 지정되지 않고 API-호출 구성요소(1830)가 이용할 수 없는 추가적인 함수, 메소드, 클래스, 데이터 구조 및/또는 기타 특징을 포함할 수 있다. API-호출 구성요소(1830)는 API-구현 구성요소(1810)와 동일한 시스템에 있을 수 있거나 원격으로 위치하여 네트워크를 거쳐서 API(1820)를 이용하여 API-구현 구성요소(1810)에 액세스할 수 있다. 도 18은 API(1820)와 상호작용하는 단일 API-호출 구성요소(1830)를 도시하는데, API-호출 구성요소(1830)와는 다른 언어(또는 동일한 언어)로 작성될 수 있는 다른 API-호출 구성요소가 API(1820)를 사용할 수 있다는 것이 이해되어야 한다.

API-구현 구성요소(1810), API(1820), 및 API-호출 구성요소(1830)는 머신 판독가능 비일시적 저장 매체에 저장될 수 있는데, 이 매체는 머신(예컨대, 컴퓨터 또는 기타 데이터 프로세싱 시스템)에 의해 판독가능한 형태로 정보를 저장하기 위한 임의의 메커니즘을 포함한다. 예를 들어, 머신 판독가능 매체는 자기 디스크, 광 디스크, 랜덤 액세스 메모리(random access memory), 리드 온니 메모리(read only memory), 플래시 메모리 장치 등을 포함하고, 로컬 저장 매체나 하나 이상의 네트워크에 의해 클라이언트 장치로 연결되는 원격 장치 상의 저장 매체일 수 있다.

도 17("소프트웨어 스택")에서, 예시적인 실시예로, 애플리케이션들이 여러 서비스 API를 이용하여 서비스 1 또는 2로 호출을 하고 여러 OS API를 이용하여 오퍼레이팅 시스템(OS)으로 호출을 할 수 있다. 서비스 1 및 2는 여러 OS API를 이용하여 OS로 호출을 할 수 있다.

서비스 2는 두 API를 갖는데, 이 중 하나(서비스 2 API 1)는 애플리케이션 1로부터 호출을 수신하고 이로 값을 반환하고 다른 하나(서비스 2 API 2)는 애플리케이션 2로부터 호출을 수신하고 이로 값을 반환한다는 것에 주목한다. 서비스 1(예컨대, 소프트웨어 라이브러리가 될 수 있음)은 OS API 1로 호출을 하고 이로부터 반환된 값을 수신하고, 서비스 2(예컨대 소프트웨어 라이브러리가 될 수 있음)는 OS API 1 및 OS API 2로 호출을 하고 이로부터 반환된 값을 수신한다. 애플리케이션 2는 OS API 2로 호출을 하고 이로부터 반환된 값을 수신한다.

본 명세서에서 "하나의 실시예" 또는 "일 실시예"라는 말은 실시예와 관련하여 설명된 특정 특징, 구조 또는 특성이 본 발명의 적어도 하나의 실시예에 포함되는 것을 의미한다. 본 명세서 내의 다양한 부분에서 나오는 "일 실시예에서"라는 문구는 반드시 모두 동일한 실시예를 지칭하는 것은 아니다.

앞의 명세서에서, 본 발명은 이의 구체적인 실시예를 참조하여 설명되었다. 그러나, 다양한 수정 및 변경이 본 발명의 더 넓은 사상 및 범위로부터 벗어나지 않으면서 이루어질 수 있음을 확실히 알 수 있다. 상세한 설명 및 도면은 따라서 제한적인 것이라기보다는 예시적인 것으로 고려되어야 한다.

API 부록 (래퍼 애플리케이션)

CloudOS

Extends: SC.Object

개요

CloudOS 애플리케이션은 모든 애플리케이션에 대한 크롬(chrome)이고 이들이 실행되는 환경을 제공.

CloudOS의 일부가 되는 애플리케이션들만이 이 애플리케이션에 노출된 API를 사용하고, 임의의 컨트롤러에 직접 도달해서는 안됨.

속성

·blockInputController

모달 판(modal pane)을 보여주어 사용자 입력의 차단 및 차단해제를 다룸.

이는 앱들이 아닌 CloudOS 만의 내부에 있음.

일반적으로 이를 직접 호출해서는 안됨. 대신, CloudOS.blockUserInput 및 CloudOS.unblockUserInput을 호출. 이는 네스팅된 호출들(nested calls)을 허용함.

·isCloudOSClient

CloudOS duck이 하는 것과 같이 진행(walk).

·supportedLocales

유형: Array

모든 CloudOS 애플리케이션에 대한 지원 로컬(locale)의 목록.

·localeDidLoad

유형: Boolean

로컬화된 스트링들이 로딩되었는지 여부를 계속 추적함.

·isPhotoPickerOpen

Photo Picker가 오픈인지 여부를 나타내는 속성.

·keyResponder

다른 곳에서 다루어지지 않은 모든 키보드 쇼트컷이 CloudOS의 전역 키보드 쇼트컷을 포함하는 이 key responder로 보내짐.

·moduleLocalizer

CloudOS.moduleLocalizer가 현재 로컬을 계속 추적하고, 만약 .changeLocale()이 호출되면, 모든 로컬화된 모듈들에 대해 MODULE_INFO를 멍키-패치(monkey-patch)하고 이 모듈들을 로딩되지 않은 것으로 마크함.

로컬화된 모듈의 목록은 localizedModules 어레이에 계속 있음.

·blockInputModalPane

언제 로컬을 변경할지 보여주는 모달 판(modal pane). 이는 앱을 흐리게 하고 스피너(spinner)를 놓음.

메소드

·applicationIsReady()

애플리케이션이 작동하고 실행되며 활성으로 될 준비가 될 때 호출됨. 주어진 타임프레임 내에서 이 메소드 호출에 실패하면, 애플리케이션이 활성으로 되는 것을 막고, CloudOS는 이를 디스에이블/에러 상태라고 간주함.

·blockUserInput()

unblockUserInput이 호출될 때까지 사용자 입력을 일시적으로 막음. 만약 프로세스가 너무 오래 걸리면, 피드백(예컨대, 스피너)이 사용자에게 보여짐.

네스팅될 수 있음.

·exit(Number statusCode)

애플리케이션을 나감. 이것은 예컨대 사용자가 애플리케이션을 계속해서 사용할 만큼 충분한 스타트업 데이터가 없거나 사용자가 남아있기를 원하지 않는 복구불가능한 상태에 있는 경우들에 유용하다.

statusCode 1 또는 2로 애플리케이션을 나가면 애플리케이션의 맨 위에 닫기, 재시도 또는 오류 신고에 대한 옵션을 갖는 다이얼로그를 표시한다.

이 호출은 전달될 statusCode를 필요로 한다: 0 - 비치명적 나가기(오류 신고 또는 다이얼로그를 사용자에게 보이지 않는다) 1- 치명적 오류("예상하지 못함" 제목과 함께 오류 다이얼로그를 표시) 2 - 부트스트랩/스타트업 오류("로드할 수 없음" 제목의 다이얼로그를 표시)

·getAccountPreferences()

현재 로그인된 사용자에 대한 어카운트 선호 객체를 반환

반환: CK.AccountPreferences

·getAppPreferences(String appName)

KeyValue 서비스로부터 오는 애플리케이션 특정 선호를 반환. 이 선호는 앱이 동의하고 COS.apps에 hasPreferences 속성을 추가한 경우에만 존재함.

디폴트로 이는 호출하는 애플리케이션의 선호를 반환하지만, appName을 지정하여 임의의 애플리케이션에 대한 앱 선호를 요청할 수 있음.

반환: Hash

·getCurrentlyActiveApplication()

현재 실행되는 애플리케이션의 스트링 표현을 반환(CK.Application에 대한 아래의 이름 속성에서와 동일함)

반환: String

·getRequestedStartupUrl()

앱에 대한 스타트업 요청인 url을 반환. 만약 CloudOS가 스타트업을 요청하지 않으면, 이는 null을 반환

반환: String

·getRoute()

앱에 대한 루트를 얻음, 이는 앱 앵커(app anchor) 다음의 무엇이든 될 수 있음.

따라서 예를 들어, 만약 URL이 현재 https://www.icloud.com/#calendar/invitation=456이면 getRoute는 invitation=456을 반환함. 별도로, 애플리케이션의 아이프레임 window.location.hash는 또한 #invitation=456이 됨.

반환: String

·getStartupUrl()

애플리케이션에 대해 현재 셋업된 스타트업 url을 얻음

반환: String

·getStatusForServiceName(String serviceName)

특정된 서비스 이름에 대한 상태를 반환.

active 서비스가 작동하고 이 사용자에 대해 실행되고 있음, inactive 서비스가 알려지지 않은 이유로 이 사용자에 대해 일시적으로 비활성임, inactive:maintenance 서비스가 보수 진행중이기 때문에 이 사용자에 대해 일시적으로 비활성임, disabled 서비스가 이 사용자에 대해 인에이블되지 않음(일시적 문제이기 보다는 환경 셋업(configuration)), disabled:noAccess 서비스가 사용자가 그에 대한 액세스를 갖지 않기 때문에 이 사용자에 대해 인에이블되지 않음

http://da.apple.com/confluence/display/NCWEB/Newcastle+Web+JSON+Bag+%28Setup+Service%29

반환: String

·getUrlForServiceName(String serviceName)

특정된 서비스 이름에 대한 URL 반환.

예: "연락처", "달력"

반환: String

·getUser()

통상적으로 백(bag)에 정의된 바와 같은 사용자 정보를 반환.

반환: CK.User

·mailTo(String to, String subject, String body, String cc, String bcc, String subject)

사용자가 메일을 인에이블하면 새로운 메일 작성 윈도우를 오픈함. 그렇지 않으면 컴퓨터가 셋업한 임의의 메일 클라이언트 내에 신규 작성 윈도우를 오픈하는 일반적인 mailto: call을 행함.

·refreshAppPreferences(Hash hash)

애플리케이션 특정 선호의 가장 최근 버전을 얻고 완료된 경우 콜백을 실행

·reload()

만약 애플리케이션이 재로딩될 필요가 있으면, 이 메소드가 아이프레임이 적절히 제거되고 나서 앱을 백지 상태에서 복귀시키도록 보장함.

·setAppPreferences(Hash hash, Function callback)

KeyValue 서비스에 저장할 애플리케이션 특정 선호를 셋업.

·setRoute(String route)

사용자가 URL의 앱 앵커 후에 나타나는 루트를 커스텀화(customize)할 수 있게 함.

예를 들어, Calendar app: setRoute('invitation=456')으로부터 이를 호출하면 다음의 URL을 생성한다: http://www.icloud.com/#calendar/invitation=456

사용자가 이러한 루트로 CloudOS를 입력하는 경우, 사용자는 (로그인 후에) 달력으로 곧바로 가게 되고 애플리케이션 아이프레임에는 자신의 location.hash를 위해 특정 루트 #invitation=456이 주어진다(따라서 SC.routes는 정상으로 작동한다).

·setStartupUrl(String url)

애플리케이션에 대한 새로운 스타트업 url을 셋업

·setTitle(String title)

현재 활성 애플리케이션인 경우에만 고려되는 원하는 브라우저 제목을 셋업. 만약 사용자가 애플리케이션을 전환하고 그 다음 반환하면, 제목은 이 메소드로의 마지막 호출 값으로 회복된다.

CloudOS는 애플리케이션의 제목을 디폴트 문서 제목으로 셋업하고, 따라서 자신의 디폴트 제목을 변경하고자 할 때에만 (예컨대, Mail이 읽지 않은 메시지의 수 등을 넣기를 원하는 경우) 이 메소드를 이용할 필요가 있다.

·showAppSwitcher()

appSwitcher/springboard를 보여주기를 원하는 경우 애플리케이션으로부터 호출되는데, 통상적으로 작은 "클라우드" 아이콘을 클릭하는 경우 트리거됨.

·showSecondaryAuth()

만약 애플리케이션이 제2 인증 패스를 요구하면, 이 메소드가 패스워드를 위한 입력과 함께 iOS 스타일 경고 박스를 제공함.

만약 2차 인증이 성공적이면 애플리케이션은 'secondaryAuthDidSucceed' 대리 호출(delegate call)을 수신함.

·switchToApplication(String toAppName, String route)

애플리케이션이 상이한 애플리케이션으로 전환되어야 한다고 애플리케이션이 CloudOS에 나타낼 수 있게 함. toAppName 파라미터는 전환할 애플리케이션의 스트링 표현이고, route(선택적)는 애플리케이션 내의 특정 위치로 가도록 주어질 수 있다.

·unblockUserInput()

사용자 입력을 차단 해제(여러번 차단되지 않은 경우. 여러번 차단된 경우 차단 해제는 같은 횟수만큼 호출되어야 함)

·userIsAuthenticated()

사용자가 현재 인증되었다면 YES를 반환

반환: Boolean

API 부록

파트 2(CK API)

_ global _

속성

·preferencesVersion

유형: String

이것은 키 값 저장소에 저장된 선호 객체의 선호 버전이다.

·isReady

유형: Boolean

애플리케이션이 준비되었는지 여부(CloudOS로 applicationIsReady()를 호출하였는지 아닌지를 의미함)

·isDisabled

유형: Boolean

애플리케이션이 디스에이블되었는지 여부

·requiredServices

유형: Array

이 애플리케이션에 의해 필요한 요구 서비스 이름의 목록. 하나가 백(bag)에 반환되지 않으면, 디스에이블됨.

·requrestedStartupUrl

유형: String

앱을 시작하는 경우 스타트업이 CloudOS에 의해 요청되면, 이 속성이 요청된 URL을 포함함.

·startupResponse

유형: SC.Response

애플리케이션이 CloudOS 내에서 스타트업 하기로 하면, 이것은 스타트업 응답이 반환되는 경우 스타트업 응답을 포함함.

·startupNotified

유형: Boolean

애플리케이션이 CloudOS 내에서 스타트업 하기로 하면, 이것은 애플리케이션 대표(application delegate)에 스타트업 응답이 통지된 후 YES로 토글링됨.

·url

유형: String

서비스와 통신하기 위해 사용되어야 하는 기본 URL. 통상의 애플리케이션은 이 url을 모든 아웃고잉 데이터 요청 앞에 붙임.

·isEnabled

이 서비스가 현재 사용자에 대해 활성인지 여부를 나타냄. 보통 비활성 서비스는 연관된 애플리케이션이 (하나 있는 경우) 자신의 것을 가져야 함을 의미함.

·OFFLINE_TYPE_SESSION_STORAGE

브라우저의 sessionStorage 지원을 나타내는 오프라인 유형

·OFFLINE_TYPE_LOCAL_STORAGE

브라우저의 localStorage 지원을 나타내는 오프라인 유형. 세션 저장과 다르게, 로컬 저장은 "영구적임".

·OFFLINE_TYPE_SQL_DATABASE

브라우저의 SQL 데이터베이스 지원을 나타내는 오프라인 유형.

·OFFLINE_REASON_NETWORKING_ERROR

장치가 오프라인이라고 브라우저가 알리는 경우. 이는 SC.device.isOffline 속성에 따라 사용되어야 함. 어카운트 메뉴에서 디스플레이를 위한 offlineReasons 우선순위 1.

·OFFLINE_REASON_TIMEOUT

애플리케이션이 서버와 통신하는 경우 너무 많은 타임아웃(애플리케이션 특정 판단)을 접해서 오프라인되는 경우. 어카운트 메뉴에서 디스플레이를 위한 offlineReasons 우선순위 2.

·OFFLINE_REASON_SERVER_ERROR

애플리케이션이 서버 오류들로 끝나는 너무 많은 요청(애플리케이션 특정 판단)을 접해서 오프라인되는 경우. 어카운트 메뉴에서 디스플레이를 위한 offlineReasons 우선순위 3.

·OFFLINE_REASON_STARTUP_WAIT

애플리케이션이 최초 데이터 세트("스타트업" 데이터)를 여전히 기다리고 있기 때문에 오프라인 되는 경우. 일부 애플리케이션들은 오프라인 모드로 시작하는 것이 유용하다고 판단하여, 사용자는 자신의 이전에 캐싱된 데이터를 보다 빠르게 얻을 수 있다. 어카운트 메뉴에서 offlineReasons NOT 디스플레이

·enabledInDevMode

유형: Boolean

이 캐처(catcher)가 전개 중 예외들에 트랩하는 특정 브라우저의 성능을 방해할 수 있기 때문에(FireFox, Chrome, IE), 생산 모드에 있는 경우에만 인에이블함.

·bubbleErrorsToCloudOS

예외들이 기존의 애플리케이션의 오류 캐처에 의해 다루어져야 하는지 또는 이들이 CloudOS로 전달되어야 하는지 여부를 나타냄.

·exceptionCallback

유형: Object

예외가 잡힌 경우 임의의 추가적인 정보를 제공하고 싶으면, 이 콜백을 지정하여 다음과 같이 임의의 해시를 받아들이는 함수를 참조한다:

CK.errorCatcher.set('exceptionCallback', function(hash){})

콜백은 해시를 변환하여 예외를 보고할 때 유용하다고 보는 임의의 추가적인 정보를 포함하도록 한다. (예를 들어, 애플리케이션의 현재 뷰 등이 될 수 있음).

주의: 예외가 오류 캐처에 의해 잡힌 경우, 이는 애플리케이션의 상태가 더 이상 신뢰될 수 없다는 것을 의미함. 따라서 어느 정보를 여기에 입력하는지에 대해 매우 주의해야 함: 자신이 신뢰할 수 있는 정보만을 입력.

추가: 추가적인 안전을 위해, 콜백은 트라이/캐치 핸들러 내부에서 호출되는데, 이것은 예외 리포터의 디스플레이를 막는 추가적인 예외를 원하지 않기 때문임. 따라서 핸들러를 조심하는 것이 바람직하지만, 너무 심하게 신경쓸 필요는 없음.

·namespacesToSymbolicate

유형: 어레이

잡힐 것이라고 생각하지 않는 오류를 보내려고 하면, 사파리 5 및 IE8과 같은 원래는 스택 트레이스들을 제공하지 않는 브라우저들 내에 스택 트레이스들을 제공하기 바로 전에 recordStack()을 호출할 수 있다. 추가적인 특징으로, ErrorCatcher는 스택이 기록되는 경우 - 이미 완료되지 않았다면 - 함수들을 명명하기를 시도한다.

불행히도, IE8에서 SC, CW 등과 같은 모든 전역 변수들을 반복하는 방법이 없다. 더욱이, 어느 전역 값들이 사실상 부호화되어야 하는 네임스페이스들인지를 추측하려는 것은 기능을 반드시 반복될 수 없는 전역들로 노출시키는 파이어폭스와 같은 일부 브라우저에서 매우 어렵고 오류가 나기 쉽다.

예: ['SC', 'CW', 'Cal']

이 값을 null로 두면, 심볼화(symbolication)를 얻지 못하는 것을 제외하고는 모든 것이 작동한다.

·isShowingDialog

유형: Boolean

복수의 오류 캐처 다이얼로그가 동시에 나타나는 것을 막음

·PAID-LAPSED

유형: Number

·PAID_NOT_CREATED_YET

유형: Number

·FREE_NOT_CREATED_YET

유형: Number

·INACTIVE

유형: Number

·PAID_ACTIVE

유형: Number

MobileMe Users

·FREE_QUALIFIED

유형: Number

iCloud users

·FREE_NOT_QUALIFIED

유형: Number

·stateKey

유형: String

어느 객체 속성 계층 상태 머신이 저장되어 있는지를 지정.

·initialStateKey

유형: String

어느 객체 속성이 계층 상태 머신의 초기 상태를 저장하는지를 지정

·MAX_RECENT_LOG_MESSAGES_SIZE

유형: Number

"Recent Log Messages" 섹션에 포함할 캐릭터의 최대 수를 지정. 만약 이것이 줄여지면(truncated), 이는 처음에 줄여짐.

이것이 null이면, 줄이기(truncation)는 발생하지 않음

·DEFAULT_EMAIL

유형: String

아무것도 사용되지 않으면 디폴트 이메일

·name

유형: String

애플리케이션의 이름

·path

유형: 스트링

현재 애플리케이션으로의 url 경로

·hasPreferences

유형: Boolean

이 애플리케이션이 CloudKit를 통해 KeyValue 저장소로 선호들을 저장하는지 여부

·preferences

유형: Hash

이 객체에 대한 선호. 이 앱에 대한 hasPreferences가 턴 온(turn on)된 경우에만 선호를 가짐.

이 값은 단지 해시임에 주목함. 개별 애플리케이션이 이 해시를 모델링함. 애플리케이션의 경우, 이들은 CloudOS 메소드: -getAppPreferences() - setAppPreferences(hash)를 이용해야 함.

메소드

·addStatechartObserver(String key, SC.Object target)

객체의 스테이트차트로 "propertyChanged" 이벤트를 보내는 옵서버(observer)를 추가

반환: Functionthe actual observer (나중에 제거되어야 함)

·create(Array styles)

CK.StyleSheet 객체에 대한 메소드를 생성

·displayExceptionDialog(Hash params)

이 함수는 에러 캐처 다이얼로그 판을 디스플레이하고 애플리케이션과의 추가적인 상호작용을 피하기 위해 사용됨.

·displayNameFor(String firstName, String familyName, String account,)

지정된 이름 및 성에 따라 적절한 "디스플레이용" 이름을 반환. 이름들의 순서는 사용자가 선택한 선호에 기초함.

할 일: 당분간, 디스플레이 순서는 현재 언어에 완전히 기초함. 일단 이름 디스플레이 순서에 대한 CloudOS에 걸친 사용자 선호를 가지면, 이를 따르게 됨.

별명 등을 지정할 수 있으면 또한 유용함.

반환: String

·exitErrorCatcher(Hash params, String applicationName)

Reload/OK를 클릭한 후에 또는 그 때, 에러 캐처가 나가면 코드를 클린업

·getCurrentLocaleInISOFormat()

ISO 639-1 언어 코드, ISO 3166-1 영역 코드로 포맷된 String.preferredLanguage에 반영된 현재 언어를 얻음. 이는 SC.Locale과 다른 포맷이고 많은 웹 브라우저가 사용함. 이는 자바 및 많은 다른 공통 플랫폼에 매칭됨.

예를 들어, "en-us" 대신 "enUS"가 되고 "ja-jp" 대신 "jaJP"가 됨.

이 ISO 표준에 대한 더 많은 정보는 이하에서 이용가능함:

http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPInternational/Articles/LanguageDesignations.html

반환: String

·handleException(Exception e)

에러 캐처가 잡히지 않은 예외를 다루도록 불러진 경우를 위한 콜백 메소드. 이는 예컨대 런루프(runloop)에 의해 호출됨.

반환: Boolenhandled

·init()

에러들을 찾기로 결정한 경우에만 찾도록 허용하는 패치들을 적용하여 시작함

·mailErrorReport(Hash errorHash, String applicatioName, Hash params)

주어진 errorHash 및 applicatioName으로 에러 리포트를 메일로 보냄

·moduleDidLoad(arg1, params)

이는 ErrorCatcher 모듈이 로딩된 경우 호출되는 제1 함수임

·performKeyEquivalent(String keystring, SC.Event evt)

존재하는 경우 이벤트를 객체의 스테이트차트(statechart)로 보내기를 시도. 그렇지 않으면, 디폴트 SC.View 구현과 동일한 행동(behavior)을 함.

반환: Boolean

·readCookie(String cookieName, Boolean isRegExp)

쿠키의 이름(또는 정규 표현)을 고려하여, 값을 읽고 반환

정규 표현을 주는 경우, 제1 매치의 쿠키값만을 반환함

반환: StringThe cookie value

·reloadApplication(String applicationName)

애플리케이션을 재로딩할 필요가 있는 경우. 이것은 에러가 isFatal로 마킹된 경우에만 발생하고 Reload 버튼을 클릭한 후 또는 보고서가 보내진 후에 발생할 수 있음.

·removeStatechartObserver(String key, SC.Object target, Function the)

"propertyChanged" 이벤트를 객체의 스테이트차트로 보내는 옵서버를 추가

반환: SC.Objectreceiver

·reportError(Hash params)

예외들과 동일한 방식이지만 커스텀화하고 Apple로 보내는 리포트 버튼으로 에러들을 리포트하도록 함.

이는 예컨대 서버 에러들 또는 반드시 JS 예외들이지는 않은 에러들을 리포트하여 되돌리는데 사용될 수 있다.

파라미터를 다음의 포맷의 해시로 취함(모든 속성은 선택적임):

반환: Booleanhandled

·RGBColor(color_string)

컬러 값들을 분석(parse)하는 클래스

·shouldTrace()

트레이싱이 인에이블되어야 하면 true, 아니면 false를 반환. 트레이스는 다음과 같이 인에이블/디스에이블됨.

a. 이 객체가 "트레이스"에 대해 값(즉, not SC.none)을 갖는가?

그렇다면, 이를 따름. b. 그렇지 않으면, Ck.Statechart.STATECHARTTRACE_ENABLED가 셋업됨.

반환: YES 또는 NO

·tryToPerform(String methodName, Object arg1, Object arg2)

존재하는 경우 이벤트를 객체의 스테이트차트로 보내기를 시도. 그렇지 않으면 디폴트 SC.Object 구현과 동일한 행동을 함.

반환: 처리된 경우 Boolean YES, 처리되지 않으면 NO

·writeCookie(String name, String val, String path, String domain)

쿠키에 대한 정보를 기재. 만료 시간이 브라우저 세션에 대해 셋업됨.

반환: 쿠키의 StringThe value.

Claims

실행가능한 명령어들을 포함하는 머신 판독가능 비일시적 저장 매체로서,
상기 실행가능한 명령어들은, 데이터 프로세싱 시스템에서 실행되는 경우, 상기 데이터 프로세싱 시스템으로 하여금,
제1 오퍼레이팅 시스템(Operating System; OS)을 실행하는 단계;
상기 제1 OS 상에서 웹 브라우저를 실행하는 단계;
상기 웹 브라우저 상에서 적어도 제1 애플리케이션에 대한 라이프 사이클 관리를 제공하는 래퍼 애플리케이션(wrapper application)을 실행하는 단계;
상기 래퍼 애플리케이션 상에서 상기 제1 애플리케이션을 실행하는 단계;
상기 제1 애플리케이션이 실행을 위해 시작되는 경우 상기 래퍼 애플리케이션과 상기 제1 애플리케이션 간에서 적어도 하나의 호출(call)을 전송하고 상기 제1 애플리케이션이 종료되는 경우 상기 래퍼 애플리케이션과 상기 제1 애플리케이션 간에서 적어도 하나의 호출을 전송하는 단계; 및
상기 제1 애플리케이션이 시작되는 경우 상기 웹 브라우저와 상기 래퍼 애플리케이션 간에서 적어도 하나의 호출을 전송하는 단계
를 포함하는 방법을 수행하도록 하는, 머신 판독가능 비일시적 저장 매체.
제1항에 있어서,
적어도 하나의 호출을 전송하는 것은 호출 또는 메시지의 발행, 개시, 불러오기, 또는 수신 중 하나를 포함하고, 상기 제1 OS는 선점 다중작업(preemptive, multitasking) OS이며, 상기 래퍼 애플리케이션의 메모리 공간은 상기 웹 브라우저의 메모리 공간에 의해 정의되는, 머신 판독가능 비일시적 저장 매체.
제2항에 있어서,
상기 웹 브라우저는 마크업 언어로 인코딩되고 하나 이상의 URL(Uniform Resource Locator)을 통해 상기 웹 브라우저에 의해 검색되는 웹 페이지를 프로세싱하는 소프트웨어 애플리케이션 프로그램이고, 상기 웹 브라우저는 상기 웹 브라우저 내의 레이아웃 엔진을 이용하여 상기 웹 페이지의 상기 마크업 언어를 상기 웹 페이지의 DOM(Document Object Model)으로 프로세싱하도록 구성되고, 상기 웹 페이지와 연관된 종속형 시트(cascading style sheet)를 프로세싱하여 상기 웹 페이지를 표시하도록 구성되는, 머신 판독가능 비일시적 저장 매체.
제2항에 있어서,
애플리케이션들의 세트는 상기 래퍼 애플리케이션에서 실행되고 상기 세트는 이메일 애플리케이션인 상기 제1 애플리케이션, 달력 애플리케이션인 제2 애플리케이션, 및 연락처 또는 주소록 애플리케이션인 제3 애플리케이션을 포함하며, 상기 세트 내의 각각의 애플리케이션은 가장 앞에 있는 경우 상기 웹 브라우저의 동일한 단일 윈도우 내에서 표시되는, 머신 판독가능 비일시적 저장 매체.
제4항에 있어서,
상기 래퍼 애플리케이션은 상기 애플리케이션들의 세트에 대한 오퍼레이팅 시스템으로서 동작하고 상기 세트 내의 각각의 애플리케이션은 적어도 부분적으로 자바스크립트로 작성되는, 머신 판독가능 비일시적 저장 매체.
제4항에 있어서,
상기 세트 내의 각각의 애플리케이션은 상기 웹 페이지의 해당하는 아이프레임(iframe) 내에서 실행되고, 상기 세트 내의 각 애플리케이션에 대한 상기 해당하는 아이프레임은 상기 래퍼 애플리케이션에 의한 액션을 통해 가장 앞에 있는 애플리케이션으로 표시되거나 가장 앞에 있는 애플리케이션으로 표시되지 않는, 머신 판독가능 비일시적 저장 매체.
제6항에 있어서,
상기 래퍼 애플리케이션은 상기 웹 브라우저 내의 동일한 단일 윈도우 내에서 제1 아이콘의 선택에 의해 발생하는 상기 웹 브라우저로부터의 호출에 응답하여 각각 상기 애플리케이션들의 세트 내의 한 애플리케이션을 표시하는 아이콘들의 세트의 디스플레이에 대한 데이터를 생성하는, 머신 판독가능 비일시적 저장 매체.
제7항에 있어서,
상기 제1 아이콘의 선택은 상기 애플리케이션들 간에서 전환하는데 사용되고 상기 웹 브라우저의 동일한 단일 윈도우 내에서 상기 아이콘들의 세트를 표시하도록 하는, 머신 판독가능 비일시적 저장 매체.
제8항에 있어서,
상기 애플리케이션들의 세트 내의 각각의 애플리케이션은 그것이 가장 앞의 애플리케이션으로부터 가장 앞이 아닌 상태로 전환된 후 컨텍스트(context) 및 상태가 저장된 채로 실행 상태로 남아 있는, 머신 판독가능 비일시적 저장 매체.
제9항에 있어서,
상기 컨텍스트는 텍스트 입력 포커스(focus)의 상태, 위치 및 입력된 사용자 데이터를 포함하고, 상기 웹 브라우저의 동일한 단일 윈도우는 탭 윈도우들(tabbed windows)을 포함하지 않으며, 상기 래퍼 애플리케이션은 상기 웹 브라우저의 동일한 단일 윈도우의 URL 텍스트 입력 필드 및 제목 표시줄을 갖는, 머신 판독가능 비일시적 저장 매체.
제9항에 있어서,
상기 래퍼 애플리케이션은 상기 애플리케이션들의 세트 내의 각각의 애플리케이션에 대해 사용자를 인증하고, 사용자가 상기 세트 내의 애플리케이션들 중 하나에서 로그아웃하거나 액세스가 상기 세트 내의 애플리케이션들 중 하나에서 만료되는 경우, 상기 래퍼 애플리케이션은 상기 애플리케이션들의 세트 내의 상기 애플리케이션들의 나머지로부터 상기 사용자를 로그아웃하는, 머신 판독가능 비일시적 저장 매체.
제9항에 있어서,
상기 래퍼 애플리케이션은 상기 애플리케이션들의 세트 내의 각각의 애플리케이션에 대해 개별적으로 오류들을 처리하고 상기 세트 내의 다른 애플리케이션들이 계속하여 실행되는 동안 상기 세트 내의 하나의 애플리케이션의 재시작을 허용하는, 머신 판독가능 비일시적 저장 매체.
제12항에 있어서,
상기 래퍼 애플리케이션은 적절한 사용자 인증 데이터를 셋업 서비스로 송신하는 것에 응답하여 상기 애플리케이션들의 세트 내의 각각의 애플리케이션을 위한 웹 서버들에 대한 주소 정보를 수신하는, 머신 판독가능 비일시적 저장 매체.
데이터 프로세싱 시스템에 의한 실행을 위한 실행가능한 명령어들을 포함하는 머신 판독가능 비일시적 저장 매체로서,
상기 명령어들은,
상기 데이터 프로세싱 시스템의 오퍼레이팅 시스템에서 실행되는 웹 브라우저 상에서 실행되도록 구성되는 래퍼 애플리케이션; 및
상기 래퍼 애플리케이션 상에서 실행되도록 구성되는 애플리케이션들의 세트
를 포함하고, 상기 애플리케이션들의 세트는 하나 이상의 웹 서버로부터의 데이터를 제공하고, 상기 래퍼 애플리케이션은 상기 애플리케이션들의 세트 내의 각각의 애플리케이션에 대한 라이프 사이클 관리를 제공하고 상기 애플리케이션들의 세트 내의 애플리케이션들 간에서의 전환을 제공하는, 머신 판독가능 비일시적 저장 매체.
제14항에 있어서,
상기 애플리케이션이 시작되는 경우 및 상기 애플리케이션이 가장 앞과 가장 앞이 아닌 위치 간에서 전환되는 경우 호출들이 상기 래퍼 애플리케이션과 각 애플리케이션 간에서 전송되고, 라이프 사이클 관리는 상기 애플리케이션들의 세트 내의 각각의 애플리케이션의 시작 및 종료를 포함하는, 머신 판독가능 비일시적 저장 매체.
제15항에 있어서,
상기 래퍼 애플리케이션 및 상기 애플리케이션들의 세트는 동일한 단일 웹 브라우저 윈도우 내에서 실행되도록 구성되고 상기 애플리케이션들의 세트 내의 각각의 애플리케이션은 가장 앞이 아닌 상태에 있는 경우 실행 상태로 남아 있으며, 상기 래퍼 애플리케이션은 상기 동일한 단일 웹 브라우저 윈도우 내에서 제1 아이콘의 선택에 의해 발생되는 상기 웹 브라우저로부터의 호출에 응답하여 각각 상기 애플리케이션들의 세트 내의 애플리케이션을 나타내는 아이콘들의 세트를 표시하며, 상기 제1 아이콘은 상기 애플리케이션들의 세트 내의 애플리케이션들 간에서 전환하는데 사용되는, 머신 판독가능 비일시적 저장 매체.
머신 구현 방법으로서,
제1 오퍼레이팅 시스템(OS)을 실행하는 단계;
상기 제1 OS 상에서 웹 브라우저를 실행하는 단계;.
상기 웹 브라우저 상에서 적어도 제1 애플리케이션에 대한 라이프 사이클 관리를 제공하는 래퍼 애플리케이션을 실행하는 단계;
상기 래퍼 애플리케이션 상에서 상기 제1 애플리케이션을 실행하는 단계;
상기 제1 애플리케이션이 실행을 위해 시작되는 경우 상기 래퍼 애플리케이션과 상기 제1 애플리케이션 간에서 적어도 하나의 호출을 전송하고 상기 제1 애플리케이션이 종료되는 경우 상기 래퍼 애플리케이션과 상기 제1 애플리케이션 간에서 적어도 하나의 호출을 전송하는 단계; 및
상기 제1 애플리케이션이 시작되는 경우 상기 웹 브라우저와 상기 래퍼 애플리케이션 간에서 적어도 하나의 호출을 전송하는 단계
를 포함하고, 적어도 하나의 호출을 전송하는 것은 호출 또는 메시지의 발행, 개시, 불러오기, 또는 수신 중 하나를 포함하고, 상기 제1 OS는 선점 다중작업 OS이며, 상기 래퍼 애플리케이션의 메모리 공간은 상기 웹 브라우저의 메모리 공간에 의해 정의되고, 상기 웹 브라우저는 마크업 언어로 인코딩된 웹 페이지를 프로세싱하는 소프트웨어 애플리케이션 프로그램이고, 상기 웹 페이지는 하나 이상의 URL(Uniform Resource Locator)을 통해 상기 웹 브라우저에 의해 검색되고, 상기 웹 브라우저는 상기 웹 브라우저 내의 레이아웃 엔진을 이용하여 상기 웹 페이지의 상기 마크업 언어를 상기 웹 페이지의 DOM(Document Object Model)으로 프로세싱하도록 구성되고 상기 웹 페이지와 연관된 종속형 시트를 프로세싱하여 상기 웹 페이지를 표시하도록 구성되는, 머신 구현 방법.
제17항에 있어서,
애플리케이션들의 세트는 상기 래퍼 애플리케이션에서 실행되고 상기 세트는 이메일 애플리케이션인 상기 제1 애플리케이션, 달력 애플리케이션인 제2 애플리케이션, 및 연락처 또는 주소록 애플리케이션인 제3 애플리케이션을 포함하며, 상기 세트 내의 각각의 애플리케이션은 가장 앞에 있는 경우 상기 웹 브라우저의 동일한 단일 윈도우 내에서 표시되고, 상기 래퍼 애플리케이션은 상기 애플리케이션들의 세트에 대한 오퍼레이팅 시스템으로서 동작하고 상기 세트 내의 각각의 애플리케이션은 적어도 부분적으로 자바스크립트로 작성되는, 머신 구현 방법.
데이터 프로세싱 시스템으로서,
제1 오퍼레이팅 시스템(OS)을 실행하기 위한 수단;
상기 제1 OS 상에서 웹 브라우저를 실행하기 위한 수단;
상기 웹 브라우저 상에서 적어도 제1 애플리케이션에 대한 라이프 사이클 관리를 제공하는 래퍼 애플리케이션을 실행하기 위한 수단;
상기 래퍼 애플리케이션 상에서 상기 제1 애플리케이션을 실행하기 위한 수단;
상기 제1 애플리케이션이 실행을 위해 시작되는 경우 상기 래퍼 애플리케이션과 상기 제1 애플리케이션 간에서 적어도 하나의 호출을 전송하고 상기 제1 애플리케이션이 종료되는 경우 상기 래퍼 애플리케이션과 상기 제1 애플리케이션 간에서 적어도 하나의 호출을 전송하기 위한 수단; 및
상기 제1 애플리케이션이 시작되는 경우 상기 웹 브라우저와 상기 래퍼 애플리케이션 간에서 적어도 하나의 호출을 전송하기 위한 수단
을 포함하는 데이터 프로세싱 시스템.
제19항에 있어서,
적어도 하나의 호출을 전송하는 것은 호출 또는 메시지의 발행, 개시, 불러오기, 또는 수신 중 하나를 포함하고, 상기 제1 OS는 선점 다중작업 OS이며, 상기 래퍼 애플리케이션의 메모리 공간은 상기 웹 브라우저의 메모리 공간에 의해 정의되며, 상기 웹 브라우저는 마크업 언어로 인코딩된 웹 페이지를 프로세싱하는 소프트웨어 애플리케이션 프로그램이고, 상기 웹 페이지는 하나 이상의 URL(Uniform Resource Locator)을 통해 상기 웹 브라우저에 의해 검색되고, 상기 웹 브라우저는 상기 웹 브라우저 내의 레이아웃 엔진을 이용하여 상기 웹 페이지의 상기 마크업 언어를 상기 웹 페이지의 DOM(Document Object Model)으로 프로세싱하도록 구성되고 상기 웹 페이지와 연관된 종속형 시트를 프로세싱하여 상기 웹 페이지를 표시하도록 구성되는, 데이터 프로세싱 시스템.