방법: ASP.NET Web Forms/MVC 애플리케이션에 모바일 페이지 추가

아티클
07/13/2023

적용 대상

ASP.NET Web Forms 버전 4.0

ASP.NET MVC 버전 3.0

요약

이 방법에서는 ASP.NET Web Forms/MVC 애플리케이션에서 모바일 디바이스에 최적화된 페이지를 제공하는 다양한 방법을 설명하고 광범위한 디바이스를 대상으로 할 때 고려해야 할 아키텍처 및 디자인 문제를 제안합니다. 이 문서에서는 ASP.NET 2.0에서 3.5까지의 ASP.NET Mobile Controls가 이제 사용되지 않는 이유를 설명하고 몇 가지 최신 대안에 대해 설명합니다.

콘텐츠

개요
아키텍처 옵션
브라우저 및 디바이스 검색
ASP.NET Web Forms 애플리케이션이 모바일 관련 페이지를 표시할 수 있는 방법
ASP.NET MVC 애플리케이션이 모바일 관련 페이지를 표시할 수 있는 방법
추가 리소스

ASP.NET Web Forms 및 MVC에 대한 이 백서의 기술을 보여 준 다운로드 가능한 코드 샘플은 ASP.NET 있는 Mobile Apps & 사이트를 참조하세요.

개요

스마트폰, 피처폰, 태블릿 등 모바일 장치는 웹에 액세스하기 위한 수단으로 계속 인기를 끌고 있습니다. 많은 웹 개발자와 웹 지향 비즈니스의 경우 이러한 디바이스를 사용하는 방문자에게 훌륭한 검색 환경을 제공하는 것이 점점 더 중요해지고 있습니다.

이전 버전의 ASP.NET 지원되는 모바일 브라우저

ASP.NET 버전 2.0~3.5에는 ASP.NET Mobile Controls( System.Web.Mobile.dll 어셈블리의 모바일 디바이스에 대한 서버 컨트롤 집합 및 System.Web.UI.MobileControls 네임스페이스가 포함되어 있습니다. 어셈블리는 여전히 ASP.NET 4에 포함되어 있지만 더 이상 사용되지 않습니다. 개발자는 이 논문에 설명된 것과 같이 보다 현대적인 접근 방식으로 마이그레이션하는 것이 좋습니다.

ASP.NET Mobile Controls가 사용되지 않는 것으로 표시된 이유는 디자인이 2005년 이전의 일반적인 휴대폰을 중심으로 했기 때문입니다. 컨트롤은 주로 해당 시대의 WAP 브라우저에 대해 WML 또는 cHTML 태그(일반 HTML 대신)를 렌더링하도록 설계되었습니다. 그러나 WAP, WML 및 cHTML은 이제 HTML이 모바일 및 데스크톱 브라우저 모두에 대한 유비쿼터스 태그 언어가 되었기 때문에 대부분의 프로젝트와 더 이상 관련이 없습니다.

현재 모바일 디바이스 지원의 과제

모바일 브라우저는 이제 거의 보편적으로 HTML을 지원하지만 훌륭한 모바일 검색 환경을 만드는 것을 목표로 할 때 여전히 많은 문제에 직면하게 될 것입니다.

화면 크기 - 모바일 장치는 형태가 매우 다르며 화면이 데스크톱 모니터보다 훨씬 작은 경우가 많습니다. 따라서 완전히 다른 페이지 레이아웃을 디자인해야 할 수 있습니다.
입력 방법 – 일부 디바이스에는 키패드가 있고, 일부는 스타일러스가 있고, 다른 디바이스는 터치를 사용합니다. 여러 탐색 메커니즘 및 데이터 입력 방법을 고려해야 할 수 있습니다.
표준 준수 – 대부분의 모바일 브라우저는 최신 HTML, CSS 또는 JavaScript 표준을 지원하지 않습니다.
대역폭 – 셀룰러 데이터 네트워크 성능은 크게 다르며 일부 최종 사용자는 메가바이트 단위로 요금을 부과합니다.

한 가지 크기에 맞는 솔루션은 없습니다. 애플리케이션은 액세스하는 디바이스에 따라 다르게 보고 동작해야 합니다. 원하는 모바일 지원 수준에 따라 데스크톱 "브라우저 전쟁"보다 웹 개발자에게 더 큰 도전이 될 수 있습니다.

처음으로 모바일 브라우저 지원에 접근하는 개발자는 개발자가 종종 개인적으로 이러한 장치를 소유하기 때문에 최신의 가장 정교한 스마트 폰 (예 : Windows Phone 7, iPhone 또는 Android)을 지원하는 것이 중요하다고 생각합니다. 그러나 저렴한 전화는 여전히 매우 인기가 있으며, 소유자는 특히 휴대 전화가 광대역 연결보다 쉽게 얻을 수있는 국가와 지역에서 웹을 검색하는 데 사용합니다. 비즈니스는 고객을 고려하여 지원할 디바이스 범위를 결정해야 합니다. 고급 헬스 스파를 위한 온라인 브로셔를 빌드하는 경우 고급 스마트폰을 대상으로 하는 비즈니스 결정을 내릴 수 있는 반면, 영화관 티켓 예약 시스템을 만드는 경우 덜 강력한 피처 폰을 사용하는 방문객을 고려해야 할 수 있습니다.

아키텍처 옵션

ASP.NET Web Forms 또는 MVC의 특정 기술 세부 정보를 알아보기 전에 웹 개발자는 일반적으로 모바일 브라우저를 지원하기 위한 세 가지 기본 가능한 옵션이 있습니다.

아무 것도 수행하지 않음 – 단순히 표준 데스크톱 지향 웹 애플리케이션을 만들고 모바일 브라우저를 사용하여 허용하도록 렌더링할 수 있습니다.
- 이점: 구현 및 유지 관리가 가장 저렴한 옵션이며 추가 작업 없음
- 단점: 최악의 최종 사용자 환경을 제공합니다.
  - 최신 스마트 폰은 데스크톱 브라우저뿐만 아니라 HTML을 렌더링 할 수 있지만 사용자는 여전히 축소하고 작은 화면에서 콘텐츠를 소비하기 위해 가로 및 세로로 스크롤해야합니다. 이것은 최적과는 거리가 멀다.
  - 이전 디바이스 및 기능 전화는 만족스러운 방식으로 태그를 렌더링하지 못할 수 있습니다.
  - 최신 태블릿 장치(화면이 노트북 화면만큼 클 수 있음)에서도 다양한 상호 작용 규칙이 적용됩니다. 터치 기반 입력은 더 큰 단추와 링크가 더 멀리 떨어져 있는 경우 가장 잘 작동하며 플라이아웃 메뉴 위에 마우스 커서를 놓을 방법이 없습니다.
클라이언트에서 문제 해결 – CSS를 신중하게 사용하고 점진적으로 개선하면 실행 중인 브라우저에 맞게 조정되는 태그, 스타일 및 스크립트를 만들 수 있습니다. 예를 들어 CSS 3 미디어 쿼리를 사용하면 화면이 선택한 임계값보다 좁은 디바이스에서 단일 열 레이아웃으로 변환되는 다중 열 레이아웃을 만들 수 있습니다.
- 이점: 사용 중인 특정 디바이스에 대한 렌더링을 최적화합니다. 어떤 화면 및 입력 특성에 따라 알 수 없는 향후 디바이스에도 적합합니다.
- 이점: 모든 디바이스 유형에서 서버 쪽 논리를 쉽게 공유할 수 있습니다. 코드 또는 작업 중복을 최소화합니다.
- 단점: 모바일 디바이스는 데스크톱 디바이스와 너무 다르기 때문에 모바일 페이지가 데스크톱 페이지와 완전히 다르고 다른 정보를 표시하기를 원할 수 있습니다. 이러한 변형은 CSS만을 통해 강력하게 달성할 수 없거나 비효율적일 수 있으며, 특히 일관되지 않은 이전 디바이스가 CSS 규칙을 해석하는 방법을 고려할 때 특히 그렇습니다. 이는 CSS 3 특성에서 특히 그렇습니다.
- 단점: 다양한 디바이스에 대한 다양한 서버 쪽 논리 및 워크플로를 지원하지 않습니다. 예를 들어 CSS만을 통해 모바일 사용자를 위한 간소화된 쇼핑 카트 체크 아웃 워크플로를 구현할 수는 없습니다.
- 단점: 비효율적인 대역폭 사용. 대상 디바이스가 해당 정보의 하위 집합만 사용하더라도 서버는 가능한 모든 디바이스에 적용되는 태그 및 스타일을 전송해야 할 수 있습니다.
서버의 문제 해결 – 서버에서 액세스하는 디바이스 또는 화면 크기 및 입력 방법과 같은 해당 디바이스의 특성 및 모바일 디바이스인지 여부를 알고 있는 경우 다른 논리를 실행하고 다른 HTML 태그를 출력할 수 있습니다.
- 이점: 최대 유연성. 모바일용 서버 쪽 논리를 변경하거나 원하는 디바이스별 레이아웃에 맞게 태그를 최적화할 수 있는 정도에는 제한이 없습니다.
- 이점: 효율적인 대역폭 사용. 대상 디바이스에서 사용할 태그 및 스타일 지정 정보만 전송하면 됩니다.
- 단점은: 때로는 노력이나 코드를 강제로 반복합니다(예: Web Forms 페이지 또는 MVC 보기의 유사하지만 약간 다른 복사본을 만들 수 있음). 가능한 경우 공통 논리를 기본 계층 또는 서비스로 팩터링하지만 여전히 UI 코드 또는 태그의 일부를 복제한 다음 병렬로 유지 관리해야 할 수 있습니다.
- 단점은: 디바이스 검색은 간단하지 않습니다. 알려진 디바이스 유형 및 특성(항상 완벽하게 최신이 아닐 수 있음)의 목록 또는 데이터베이스가 필요하며 들어오는 모든 요청과 정확하게 일치하도록 보장되지는 않습니다. 이 문서에서는 몇 가지 옵션과 해당 문제를 나중에 설명합니다.

최상의 결과를 얻으려면 대부분의 개발자는 옵션(2) 및 (3)을 결합해야 합니다. 사소한 스타일 차이는 CSS 또는 JavaScript를 사용하여 클라이언트에 가장 적합하지만 데이터, 워크플로 또는 태그의 주요 차이점은 서버 쪽 코드에서 가장 효과적으로 구현됩니다.

이 문서에서는 서버 쪽 기술에 중점을 둡니다.

ASP.NET Web Forms 및 MVC는 주로 서버 쪽 기술이므로 이 백서는 모바일 브라우저에 대해 서로 다른 태그 및 논리를 생성할 수 있는 서버 쪽 기술에 중점을 줍니다. 물론 이를 클라이언트 쪽 기술(예: CSS 3 미디어 쿼리, 점진적 개선 JavaScript)과 결합할 수도 있지만, 이는 ASP.NET 개발보다 웹 디자인의 문제입니다.

브라우저 및 디바이스 검색

모바일 디바이스를 지원하기 위한 모든 서버 쪽 기술의 주요 필수 구성 요소는 방문자가 사용하는 디바이스를 아는 것입니다. 사실, 해당 디바이스의 제조업체 및 모델 번호를 아는 것보다 더 나은 것은 디바이스의 특성을 아는 것입니다. 특징은 다음과 같습니다.

모바일 디바이스인가요?
입력 방법(마우스/키보드, 터치, 키패드, 조이스틱, ...)
화면 크기(물리적 및 픽셀)
지원되는 미디어 및 데이터 형식
기타

모델 번호보다 특성에 따라 의사 결정을 내리는 것이 좋습니다. 그러면 향후 디바이스를 더 잘 처리할 수 있기 때문입니다.

ASP 사용. NET의 기본 제공 브라우저 검색 지원

ASP.NET Web Forms 및 MVC 개발자는 Request.Browser 개체의 속성을 검사하여 방문 브라우저의 중요한 특성을 즉시 검색할 수 있습니다. 예를 들어 다음을 참조하세요.

Request.Browser.IsMobileDevice
Request.Browser.MobileDeviceManufacturer, Request.Browser.MobileDeviceModel
Request.Browser.ScreenPixelsWidth
Request.Browser.SupportsXmlHttp
…그 외 다수

백그라운드에서 ASP.NET 플랫폼은 들어오는 UA( User-Agent ) HTTP 헤더를 브라우저 정의 XML 파일 집합의 정규식과 일치합니다. 기본적으로 플랫폼에는 많은 일반적인 모바일 디바이스에 대한 정의가 포함되어 있으며 인식하려는 다른 사용자에 대한 사용자 지정 브라우저 정의 파일을 추가할 수 있습니다. 자세한 내용은 MSDN 페이지 ASP.NET 웹 서버 컨트롤 및 브라우저 기능을 참조하세요.

51Degrees.mobi Foundation을 통해 WURFL 디바이스 데이터베이스 사용

ASP 동안. NET의 기본 제공 브라우저 검색 지원은 많은 애플리케이션에 충분하며, 충분하지 않을 수 있는 두 가지 기본 사례가 있습니다.

최신 디바이스를 인식하려고 합니다(브라우저 정의 파일을 수동으로 만들지 않음). .NET 4의 브라우저 정의 파일은 Windows Phone 7, Android 휴대폰, Opera Mobile 브라우저 또는 Apple iPad를 인식하기에 충분하지 않습니다.
디바이스 기능에 대한 자세한 정보가 필요합니다. 디바이스의 입력 방법(예: 터치 대 키패드) 또는 브라우저에서 지원하는 오디오 형식에 대해 알아야 할 수 있습니다. 이 정보는 표준 브라우저 정의 파일에서 사용할 수 없습니다.

WURFL(무선 유니버설 리소스 파일) 프로젝트는 현재 사용 중인 모바일 디바이스에 대한 훨씬 더 최신 정보와 자세한 정보를 유지 관리합니다.

.NET 개발자에게 좋은 소식은 ASP입니다. NET의 브라우저 검색 기능은 확장 가능하므로 이러한 문제를 해결하기 위해 이를 향상시킬 수 있습니다. 예를 들어 오픈 소스 51Degrees.mobi Foundation 라이브러리를 프로젝트에 추가할 수 있습니다. WURFL 데이터를 직접 읽고 ASP에 연결하는 ASP.NET IHttpModule 또는 브라우저 기능 공급자(Web Forms 및 MVC 애플리케이션 모두에서 사용할 수 있음)입니다. NET의 기본 제공 브라우저 검색 메커니즘. 모듈을 설치하면 Request.Browser 에 훨씬 더 정확하고 자세한 정보가 갑자기 포함됩니다. 앞에서 언급한 많은 디바이스를 올바르게 인식하고 해당 기능(입력 방법과 같은 추가 기능 포함)을 나열합니다. 자세한 내용은 프로젝트의 설명서를 참조하세요.

Web Forms 애플리케이션이 모바일 관련 페이지를 표시할 수 있는 방법

기본적으로 새로운 Web Forms 애플리케이션이 일반적인 모바일 디바이스에 표시되는 방법은 다음과 같습니다.

Windows Phone 7 및 Opera Mobile에 표시된 두 Web Forms 애플리케이션의 스크린샷

두 레이아웃 모두 모바일에 매우 친숙해 보이지 않습니다. 이 페이지는 작은 세로 지향 화면이 아니라 가로 방향의 대형 모니터용으로 설계되었습니다. 그래서 당신은 그것에 대해 무엇을 할 수 있습니까?

이 문서의 앞부분에서 설명한 것처럼 모바일 디바이스에 맞게 페이지를 조정하는 방법에는 여러 가지가 있습니다. 일부 기술은 서버 기반이고 다른 기술은 클라이언트에서 실행됩니다.

모바일 관련 master 페이지 만들기

요구 사항에 따라 모든 방문자에게 동일한 Web Forms 사용할 수 있지만 데스크톱 방문자용 페이지와 모바일 방문자를 위한 두 개의 개별 master 페이지가 있습니다. 이렇게 하면 페이지 논리를 강제로 복제하지 않고 모바일 디바이스에 맞게 CSS 스타일시트 또는 최상위 HTML 태그를 유연하게 변경할 수 있습니다.

이것은 쉽게 할 수 있습니다. 예를 들어 다음과 같은 PreInit 처리기를 웹 양식에 추가할 수 있습니다.

protected void Page_PreInit(object sender, EventArgs e)
{
    if (Request.Browser.IsMobileDevice)
        MasterPageFile = "~/Mobile.Master";
}

이제 애플리케이션의 최상위 폴더에 Mobile.Master라는 master 페이지를 만들고 모바일 디바이스가 검색될 때 사용됩니다. 필요한 경우 모바일 master 페이지에서 모바일 관련 CSS 스타일시트를 참조할 수 있습니다. 데스크톱 방문자는 모바일 페이지가 아닌 기본 master 페이지를 계속 볼 수 있습니다.

독립적인 모바일 관련 Web Forms 만들기

유연성을 극대화하기 위해 다양한 디바이스 유형에 대해 별도의 master 페이지를 갖는 것 이상으로 훨씬 더 멀리 나아갈 수 있습니다. 완전히 별도의 두 Web Forms 페이지 집합을 구현할 수 있습니다. 하나는 데스크톱 브라우저용 집합, 다른 하나는 모바일용 집합입니다. 이는 모바일 방문자에게 매우 다른 정보 또는 워크플로를 제공하려는 경우에 가장 적합합니다. 이 섹션의 나머지 부분에서는 이 방법을 자세히 설명합니다.

데스크톱 브라우저용으로 설계된 Web Forms 애플리케이션이 이미 있다고 가정할 때 진행하는 가장 쉬운 방법은 프로젝트 내에 "Mobile"이라는 하위 폴더를 만들고 모바일 페이지를 빌드하는 것입니다. 다른 Web Forms 애플리케이션에 사용하는 것과 동일한 모든 기술을 사용하여 고유한 master 페이지, 스타일시트 및 페이지를 사용하여 전체 하위 사이트를 생성할 수 있습니다. 데스크톱 사이트의 모든 페이지에 해당하는 모바일을 생성할 필요는 없습니다. 모바일 방문자에게 적합한 기능의 하위 집합을 선택할 수 있습니다.

원하는 경우 모바일 페이지에서 일반 정적 리소스(예: 이미지, JavaScript 또는 CSS 파일)를 일반 페이지와 공유할 수 있습니다. "모바일" 폴더는 IIS에서 호스트될 때 별도의 애플리케이션으로 표시되지 않으므로(Web Forms 페이지의 간단한 하위 폴더일 뿐) 데스크톱 페이지와 동일한 구성, 세션 데이터 및 기타 인프라도 모두 공유합니다.

참고

이 방법은 일반적으로 코드의 일부 중복을 포함하므로(모바일 페이지는 데스크톱 페이지와 몇 가지 유사성을 공유할 수 있음) 공통 비즈니스 논리 또는 데이터 액세스 코드를 공유 기본 계층 또는 서비스로 제외하는 것이 중요합니다. 그렇지 않으면 애플리케이션을 만들고 유지 관리하는 노력을 두 배로 늘릴 수 있습니다.

모바일 방문자를 모바일 페이지로 리디렉션

다음과 같은 이유로 모바일 방문자를 검색 세션의 첫 번째 요청에만 모바일 페이지로 리디렉션하는 것이 편리합니다(세션의 모든 요청이 아님).

그런 다음 모바일 방문자가 원하는 경우 데스크톱 페이지에 쉽게 액세스할 수 있도록 허용할 수 있습니다. "데스크톱 버전"으로 이동되는 master 페이지에 링크를 배치하면 됩니다. 방문자는 더 이상 세션의 첫 번째 요청이 아니므로 모바일 페이지로 다시 리디렉션되지 않습니다.
사이트의 데스크톱 및 모바일 부분 간에 공유되는 동적 리소스에 대한 요청을 방해할 위험을 방지합니다(예: 사이트의 데스크톱 및 모바일 부분이 모두 IFRAME 또는 특정 Ajax 처리기에 표시되는 일반적인 웹 양식이 있는 경우).

이렇게 하려면 리디렉션 논리를 Session_Start 메서드에 배치할 수 있습니다. 예를 들어 Global.asax.cs 파일에 다음 메서드를 추가합니다.

void Session_Start(object sender, EventArgs e)
{
    // Redirect mobile users to the mobile home page
    HttpRequest httpRequest = HttpContext.Current.Request;
    if (httpRequest.Browser.IsMobileDevice)
    {
        string path = httpRequest.Url.PathAndQuery;
        bool isOnMobilePage = path.StartsWith("/Mobile/", 
                               StringComparison.OrdinalIgnoreCase);
        if (!isOnMobilePage)
        {
            string redirectTo = "~/Mobile/";

            // Could also add special logic to redirect from certain 
            // recognized pages to the mobile equivalents of those 
            // pages (where they exist). For example,
            // if (HttpContext.Current.Handler is UserRegistration)
            //     redirectTo = "~/Mobile/Register.aspx";

            HttpContext.Current.Response.Redirect(redirectTo);
        }
    }
}

모바일 페이지를 준수하도록 양식 인증 구성

Forms Authentication은 인증 프로세스 도중 및 후에 방문자를 리디렉션할 수 있는 위치에 대해 특정 가정을 합니다.

사용자를 인증해야 하는 경우 양식 인증은 데스크톱 또는 모바일 사용자인지에 관계없이 데스크톱 로그인 페이지로 리디렉션합니다( 하나의 로그인 URL 개념만 있기 때문). 모바일 로그인 페이지의 스타일을 다르게 지정하려는 경우 모바일 사용자를 별도의 모바일 로그인 페이지로 리디렉션하도록 데스크톱 로그인 페이지를 개선해야 합니다. 예를 들어 데스크톱 로그인 페이지 코드 숨김에 다음 코드를 추가합니다.

public partial class Login : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        // Ensure that if Forms Authentication forces a mobile user 
        // to log in, we display the mobile login page
        string returnUrl = Request.QueryString["ReturnUrl"];
        if (!String.IsNullOrEmpty(returnUrl) && returnUrl.StartsWith("/Mobile/",
                                                StringComparison.OrdinalIgnoreCase)) 
        {
            Response.Redirect("~/Mobile/Account/Login.aspx?ReturnUrl=" 
                              + HttpUtility.UrlEncode(returnUrl));
        }

        RegisterHyperLink.NavigateUrl = "Register.aspx?ReturnUrl=" 
                                        + HttpUtility.UrlEncode(returnUrl);
    }
}

사용자가 성공적으로 로그인하면 양식 인증은 기본적으로 데스크톱 홈페이지로 리디렉션됩니다( 하나의 기본 페이지 개념만 있기 때문). 성공적으로 로그인한 후 모바일 홈페이지로 리디렉션되도록 모바일 로그인 페이지를 개선해야 합니다. 예를 들어 모바일 로그인 페이지 코드 숨김에 다음 코드를 추가합니다.

public partial class Login : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        // Ensure that after logging in, mobile users stay on mobile pages
        string returnUrl = Request.QueryString["ReturnUrl"];
        if (String.IsNullOrEmpty(returnUrl))
        {
            returnUrl = "~/Mobile/";
        }
        LoginUser.DestinationPageUrl = returnUrl;

        // (the following line is already present by default)
        RegisterHyperLink.NavigateUrl = "Register.aspx?ReturnUrl=" 
                                        + HttpUtility.UrlEncode(returnUrl);
    }
}

이 코드는 기본 프로젝트 템플릿과 같이 페이지에 LoginUser라는 로그인 서버 컨트롤이 있다고 가정합니다.

출력 캐싱 작업

출력 캐싱을 사용하는 경우 기본적으로 데스크톱 사용자가 특정 URL(출력이 캐시됨)을 방문한 다음 캐시된 데스크톱 출력을 받는 모바일 사용자가 방문할 수 있음을 주의하세요. 이 경고는 디바이스 유형별로 master 페이지를 변경하거나 디바이스 유형별로 완전히 별도의 Web Forms 구현하는지에 관계없이 적용됩니다.

문제를 방지하려면 방문자가 모바일 디바이스를 사용하는지 여부에 따라 캐시 항목을 변경하도록 ASP.NET 지시할 수 있습니다. 다음과 같이 페이지의 OutputCache 선언에 VaryByCustom 매개 변수를 추가합니다.

<%@ OutputCache VaryByParam="*" Duration="60" VaryByCustom="isMobileDevice" %>

다음으로 Global.asax.cs 파일에 다음 메서드 재정의를 추가하여 isMobileDevice 를 사용자 지정 캐시 매개 변수로 정의합니다.

public override string GetVaryByCustomString(HttpContext context, string custom)
{
    if (string.Equals(custom, "isMobileDevice", StringComparison.OrdinalIgnoreCase))
        return context.Request.Browser.IsMobileDevice.ToString();

    return base.GetVaryByCustomString(context, custom);
}

이렇게 하면 페이지의 모바일 방문자가 데스크톱 방문자가 이전에 캐시에 넣은 출력을 받지 않습니다.

작업 예제

이러한 기술이 작동하는지 확인하려면 이 백서의 코드 샘플을 다운로드합니다. Web Forms 샘플 애플리케이션은 모바일이라는 하위 폴더의 모바일 특정 페이지 집합으로 모바일 사용자를 자동으로 리디렉션합니다. 다음 스크린샷에서 볼 수 있듯이 이러한 페이지의 태그 및 스타일 지정은 모바일 브라우저에 더 잘 최적화되어 있습니다.

Windows Phone 7 및 Opera Mobile에 표시된 두 개의 모바일 Web Forms 애플리케이션 스크린샷

모바일 브라우저에 대한 태그 및 CSS 최적화에 대한 자세한 팁은 이 문서의 뒷부분에 있는 "모바일 브라우저용 모바일 페이지 스타일 지정" 섹션을 참조하세요.

ASP.NET MVC 애플리케이션이 모바일 관련 페이지를 표시할 수 있는 방법

Model-View-Controller 패턴은 애플리케이션 논리(컨트롤러)를 프레젠테이션 논리(보기)와 분리하므로 서버 쪽 코드에서 모바일 지원을 처리하는 다음 방법 중에서 선택할 수 있습니다.

데스크톱 및 모바일 브라우저 모두에 대해 동일한 컨트롤러와 보기를 사용하지만 디바이스 유형에 따라 다른 Razor 레이아웃으로 보기를 렌더링합니다. 이 옵션은 모든 디바이스에 동일한 데이터를 표시하지만 다른 CSS 스타일시트를 제공하거나 모바일용 몇 가지 최상위 HTML 요소를 변경하려는 경우에 가장 적합합니다.
데스크톱 및 모바일 브라우저 모두에 동일한 컨트롤러를 사용하지만 디바이스 유형에 따라 다른 보기를 렌더링합니다. 이 옵션은 거의 동일한 데이터를 표시하고 최종 사용자에게 동일한 워크플로를 제공하지만 사용 중인 디바이스에 맞게 매우 다른 HTML 태그를 렌더링하려는 경우에 가장 적합합니다.
데스크톱 및 모바일 브라우저에 대해 별도의 영역을 만들고 각각에 대한 독립 컨트롤러 및 보기를 구현합니다. 이 옵션은 서로 다른 정보를 포함하고 디바이스 유형에 최적화된 다양한 워크플로를 통해 사용자를 이끄는 매우 다른 화면을 표시하는 경우에 가장 적합합니다. 이는 코드의 일부 반복을 의미할 수 있지만 공통 논리를 기본 계층 또는 서비스로 팩터링하여 이를 최소화할 수 있습니다.

첫 번째 옵션을 사용하고 디바이스 유형별로 Razor 레이아웃만 변경하려는 경우 매우 쉽습니다. 다음과 같이 _ViewStart.cshtml 파일을 수정하기만 하면 됩니다.

@{
    Layout = Request.Browser.IsMobileDevice ? "~/Views/Shared/_LayoutMobile.cshtml"
                                            : "~/Views/Shared/_Layout.cshtml";
}

이제 페이지 구조와 모바일 디바이스에 최적화된 CSS 규칙을 사용하여 _LayoutMobile.cshtml이라는 모바일 관련 레이아웃을 만들 수 있습니다.

방문자의 디바이스 유형에 따라 완전히 다른 보기를 렌더링하는 두 번째 옵션을 사용하려면 Scott Hanselman의 블로그 게시물을 참조하세요.

이 문서의 나머지 내용은 세 번째 옵션인 모바일 디바이스에 대한 별도의 컨트롤러 및 보기를 만드는 데 중점을 두므로 모바일 방문자에게 제공되는 기능의 하위 집합을 정확하게 제어할 수 있습니다.

ASP.NET MVC 애플리케이션 내에서 모바일 영역 설정

일반적인 방법으로 기존 ASP.NET MVC 애플리케이션에 "Mobile"이라는 영역을 추가할 수 있습니다. 솔루션 탐색기 프로젝트 이름을 마우스 오른쪽 단추로 클릭한 다음, 영역 추가를 선택합니다. 그런 다음 ASP.NET MVC 애플리케이션 내의 다른 영역과 마찬가지로 컨트롤러 및 뷰를 추가할 수 있습니다. 예를 들어 모바일 영역에 HomeController라는 새 컨트롤러를 추가하여 모바일 방문자를 위한 홈페이지 역할을 합니다.

URL /Mobile이 모바일 홈페이지에 도달하는지 확인

URL /Mobile이 모바일 영역 내 HomeController의 인덱스 작업에 도달하려면 라우팅 구성을 두 가지 작은 변경해야 합니다. 먼저 다음 코드와 같이 HomeController가 모바일 영역의 기본 컨트롤러가 되도록 MobileAreaRegistration 클래스를 업데이트합니다.

public override void RegisterArea(AreaRegistrationContext context)
{
    // By default there is no "controller" parameter in the following line. 
    // Add one referencing "Home" as shown.
    context.MapRoute(
        "Mobile_default",
        "Mobile/{controller}/{action}/{id}",
        new { controller = "Home", action = "Index", id = UrlParameter.Optional }
    );
}

즉, 이제 "Home"이 모바일 페이지의 암시적 기본 컨트롤러 이름이기 때문에 모바일 홈페이지가 /Mobile/Home이 아닌 /Mobile에 배치됩니다.

다음으로, 애플리케이션에 두 번째 HomeController를 추가하여(즉, 기존 데스크톱 하나 외에도 모바일) 일반 데스크톱 홈페이지를 끊을 수 있습니다. "'Home'이라는 컨트롤러와 일치하는 여러 형식이 발견되었습니다."라는 오류와 함께 실패합니다. 이를 resolve 위해 최상위 라우팅 구성(Global.asax.cs)을 업데이트하여 모호성이 있을 때 데스크톱 HomeController가 우선적으로 적용되도록 지정합니다.

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default",
        "{controller}/{action}/{id}",
        new { controller = "Home", action = "Index", id = UrlParameter.Optional },
        // Add the namespace of your desktop controllers here
        new[] { "YourApplication.Controllers" } 
    );
}

이제 오류가 사라지고 URL http:// yoursite/가 데스크톱 홈페이지에 도달하고 http:// yoursite/mobile/이 모바일 홈페이지에 도달합니다.

모바일 방문자를 모바일 영역으로 리디렉션

ASP.NET MVC에는 다양한 확장성 지점이 있으므로 리디렉션 논리를 삽입할 수 있는 여러 가지 방법이 있습니다. 한 가지 깔끔한 옵션은 다음 조건이 충족되는 경우 리디렉션을 수행하는 필터 특성 [RedirectMobileDevicesToMobileArea]을 만드는 것입니다.

사용자 세션의 첫 번째 요청입니다(예: Session.IsNewSession은 true임).
요청은 모바일 브라우저에서 제공됩니다(즉, Request.Browser.IsMobileDevice는 true와 같음).
사용자가 모바일 영역에서 리소스를 아직 요청하지 않았습니다(즉, URL의 경로 부분이 /Mobile로 시작되지 않음).

이 백서에 포함된 다운로드 가능한 샘플에는 이 논리의 구현이 포함되어 있습니다. AuthorizeAttribute에서 파생된 권한 부여 필터로 구현됩니다. 즉, 출력 캐싱을 사용하는 경우에도 올바르게 작동할 수 있습니다(그렇지 않으면 데스크톱 방문자가 먼저 특정 URL에 액세스하는 경우 데스크톱 출력이 캐시된 다음 후속 모바일 방문자에게 제공될 수 있습니다).

필터이므로 특정 컨트롤러 및 작업(예: )에 적용하도록 선택할 수 있습니다.

public class HomeController : Controller
{
    [RedirectMobileDevicesToMobileArea] // Applies just to this action
    public ActionResult Index()
    {
        // ...
    }
}

… 또는 Global.asax.cs 파일에서 MVC 3 전역 필터 로 모든 컨트롤러 및 작업에 적용할 수 있습니다.

protected void Application_Start()
{
    // (rest of method unchanged)

    // Using "order" value 1 means it will run after unordered filters
    // associated with specific controllers or actions, so the redirection 
    // location can be overridden for specific actions
    GlobalFilters.Filters.Add(new RedirectMobileDevicesToMobileAreaAttribute(), 1);
}

다운로드 가능한 샘플은 모바일 영역 내의 특정 위치로 리디렉션되는 이 특성의 서브클래스를 만드는 방법도 보여 줍니다. 예를 들어 다음을 수행할 수 있습니다.

모바일 방문자를 기본적으로 모바일 홈페이지로 보내는 전역 필터를 위와 같이 등록합니다.
또한 모바일 방문자가 요청한 제품 페이지의 모바일 버전으로 이동하는 "제품 보기" 작업에 특수 [RedirectMobileDevicesToMobileProductPage] 필터를 적용합니다.
또한 필터의 다른 특수 서브클래스를 특정 작업에 적용하여 모바일 방문자를 해당하는 모바일 페이지로 리디렉션합니다.

모바일 페이지를 준수하도록 양식 인증 구성

Forms Authentication을 사용하는 경우 사용자가 로그인해야 할 때 사용자를 단일 특정 "로그온" URL로 자동으로 리디렉션합니다. 이 URL은 기본적으로 /Account/LogOn입니다. 즉, 모바일 사용자가 데스크톱 "로그온" 작업으로 리디렉션될 수 있습니다.

이 문제를 방지하려면 모바일 사용자를 모바일 "로그온" 작업으로 다시 리디렉션하도록 데스크톱 "로그온" 작업에 논리를 추가합니다. 기본 ASP.NET MVC 애플리케이션 템플릿을 사용하는 경우 다음과 같이 AccountController의 LogOn 작업을 업데이트합니다.

public ActionResult LogOn()
{
    string returnUrl = Request.QueryString["ReturnUrl"];
    if ((returnUrl != null) && returnUrl.StartsWith("/Mobile/", 
                               StringComparison.OrdinalIgnoreCase)) 
    {
        return RedirectToAction("LogOn", "Account", 
                                new { Area = "Mobile", ReturnUrl = returnUrl });
    }
    return View();
}

… 그런 다음 모바일 영역의 AccountController라는 컨트롤러에서 적절한 모바일 관련 "로그온" 작업을 구현합니다.

출력 캐싱 작업

[OutputCache] 필터를 사용하는 경우 캐시 항목이 디바이스 유형에 따라 달라지도록 강제해야 합니다. 예를 들어 다음을 작성합니다.

[OutputCache(Duration = 60, VaryByParam = "*", VaryByCustom = "isMobileDevice")]

그런 다음 Global.asax.cs 파일에 다음 메서드를 추가합니다.

public override string GetVaryByCustomString(HttpContext context, string custom)
{
    if (string.Equals(custom, "isMobileDevice", StringComparison.OrdinalIgnoreCase))
        return context.Request.Browser.IsMobileDevice.ToString();

    return base.GetVaryByCustomString(context, custom);
}

이렇게 하면 페이지에 대한 모바일 방문자가 데스크톱 방문자가 이전에 캐시에 넣은 출력을 받지 못합니다.

작업 예제

이러한 기술이 작동하는지 확인하려면 이 백서의 코드 관련 샘플을 다운로드합니다. 이 샘플에는 위에서 설명한 방법을 사용하여 모바일 디바이스를 지원하도록 향상된 ASP.NET MVC 3(릴리스 후보) 애플리케이션이 포함되어 있습니다.

추가 지침 및 제안

다음 설명은 이 문서에서 다루는 기술을 사용하는 Web Forms 및 MVC 개발자 모두에 적용됩니다.

51Degrees.mobi Foundation을 사용하여 리디렉션 논리 향상

이 문서에 표시된 리디렉션 논리는 애플리케이션에 완벽하게 충분할 수 있지만 세션을 사용하지 않도록 설정해야 하거나 쿠키를 거부하는 모바일 브라우저(세션이 있을 수 없음)에서 작동하지 않습니다. 지정된 요청이 해당 방문자의 첫 번째 요청인지 알 수 없기 때문입니다.

오픈 소스 51Degrees.mobi Foundation이 ASP의 정확도를 개선하는 방법을 이미 배웠습니다. NET의 브라우저 검색. 또한 모바일 방문자를 Web.config 구성된 특정 위치로 리디렉션하는 기본 제공 기능이 있습니다. 방문자의 HTTP 헤더 및 IP 주소 해시에 대한 임시 로그를 저장하여 ASP.NET 세션(및 따라서 쿠키)에 따라 작업할 수 있으므로 각 요청이 지정된 vistor의 첫 번째 요청인지 여부를 알 수 있습니다.

web.config 파일의 fiftyOne 섹션에 추가된 다음 요소는 검색된 모바일 디바이스의 첫 번째 요청을 ~/Mobile/Default.aspx 페이지로 리디렉션합니다. 모바일 폴더 아래의 페이지에 대한 모든 요청은 디바이스 유형에 관계없이 리디렉션 되지 않습니다 . 모바일 디바이스가 20분 이상 비활성 상태인 경우 디바이스는 잊혀지고 후속 요청은 리디렉션을 위해 새 요청으로 처리됩니다.

<redirect firstRequestOnly="true"
          mobileHomePageUrl="~/Mobile/Default.aspx"
          timeout="20"
          devicesFile="~/App_Data/Devices.dat"
          mobilePagesRegex="/Mobile/" />

자세한 내용은 51degrees.mobi Foundation 설명서를 참조하세요.

참고

ASP.NET MVC 애플리케이션에서 51Degrees.mobi Foundation의 리디렉션 기능을 사용할 수 있지만 라우팅 매개 변수 또는 작업에 MVC 필터를 배치하는 것이 아니라 일반 URL 측면에서 리디렉션 구성을 정의해야 합니다. 이는 51Degrees.mobi Foundation이 필터 또는 라우팅을 인식하지 못하기 때문입니다.

트랜스코더 및 프록시 서버 사용 안 함

모바일 네트워크 운영자는 모바일 인터넷에 대한 접근 방식에서 다음과 같은 두 가지 광범위한 목표를 가지고 있습니다.

가능한 한 많은 관련 콘텐츠 제공
제한된 라디오 네트워크 대역폭을 공유할 수 있는 고객 수 최대화

대부분의 웹 페이지는 대형 데스크톱 크기의 화면과 빠른 고정 회선 광대역 연결을 위해 설계되었으므로 많은 운영자는 웹 콘텐츠를 동적으로 변경하는 트랜스코더 또는 프록시 서버를 사용합니다. 더 작은 화면에 맞게 HTML 태그 또는 CSS를 수정할 수 있으며(특히 복잡한 레이아웃을 처리할 수 있는 처리 능력이 부족한 "기능 전화"의 경우) 페이지 배달 속도를 향상시키기 위해 이미지를 다시 압축(품질 저하)할 수 있습니다.

그러나 모바일에 최적화된 버전의 사이트를 만들기 위해 노력한 경우 네트워크 운영자가 더 이상 방해하지 않기를 원할 것입니다. ASP.NET 웹 양식의 Page_Load 이벤트에 다음 줄을 추가할 수 있습니다.

Response.Cache.SetNoTransforms();

또는 ASP.NET MVC 컨트롤러의 경우 해당 컨트롤러의 모든 작업에 적용되도록 다음 메서드 재정의를 추가할 수 있습니다.

protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
    filterContext.HttpContext.Response.Cache.SetNoTransforms();
}

결과 HTTP 메시지는 W3C 규격 트랜스코더 및 프록시에 콘텐츠를 변경하지 않도록 알릴 수 있습니다. 물론 모바일 네트워크 운영자가 이 메시지를 준수할 것이라는 보장은 없습니다.

모바일 브라우저용 모바일 페이지 스타일 지정

이 문서의 scope 넘어 어떤 종류의 HTML 태그가 올바르게 작동하는지 또는 특정 디바이스에서 유용성을 최대화하는 웹 디자인 기술을 자세히 설명합니다. 신뢰할 수 없는 HTML 또는 CSS 위치 지정 요령을 사용하지 않고 모바일 크기 화면에 최적화된 충분히 간단한 레이아웃을 찾을 수 있습니다. 그러나 언급할 만한 중요한 기술 중 하나는 뷰포트 메타 태그입니다.

특정 최신 모바일 브라우저는 데스크톱 모니터를 위한 웹 페이지를 표시하기 위해 "뷰포트"라고도 하는 가상 캔버스에 페이지를 렌더링한 다음(예: 가상 뷰포트는 iPhone에서 너비가 980픽셀이고 Opera Mobile에서는 기본적으로 너비가 850픽셀임) 화면의 실제 픽셀에 맞게 결과를 축소합니다. 그런 다음 사용자가 해당 뷰포트를 확대하여 이동하면 이렇게 하면 브라우저에서 페이지를 의도한 레이아웃으로 표시할 수 있다는 장점이 있지만, 확대/축소 및 이동이 강제로 적용되어 사용자에게 불편하다는 단점도 있습니다. 모바일용으로 디자인하는 경우 확대/축소 또는 가로 스크롤이 필요하지 않도록 좁은 화면으로 디자인하는 것이 좋습니다.

모바일 브라우저에 뷰포트의 너비를 알려주는 방법은 비표준 뷰포트 메타 태그를 사용하는 것입니다. 예를 들어 페이지의 HEAD 섹션에 다음을 추가하는 경우

<meta name="viewport" content="width=480">

… 그런 다음, 지원 스마트폰 브라우저는 480픽셀 너비의 가상 캔버스에 페이지를 배치합니다. 즉, HTML 요소가 너비를 백분율로 정의하는 경우 백분율은 기본 뷰포트 너비가 아닌 이 480픽셀 너비와 관련하여 해석됩니다. 따라서 사용자는 가로로 확대/축소 및 이동해야 할 가능성이 적어 모바일 검색 환경이 상당히 향상됩니다.

뷰포트 너비가 디바이스의 실제 픽셀과 일치하도록 하려면 다음을 지정할 수 있습니다.

<meta name="viewport" content="width=device-width">

이 작업이 올바르게 작동하려면 요소가 해당 너비를 초과하도록 명시적으로 강제해서는 안 됩니다(예: 너비 특성 또는 CSS 속성 사용). 그렇지 않으면 브라우저가 더 큰 뷰포트를 사용해야 합니다. 또한 비표준 뷰포트 태그에 대한 자세한 내용을 참조하세요.

대부분의 현대 스마트 폰은 이중 방향을 지원합니다 : 그들은 세로 또는 가로 모드 중 하나에서 개최 할 수 있습니다. 따라서 화면 너비를 픽셀 단위로 가정하지 않는 것이 중요합니다. 사용자가 페이지에 있는 동안 디바이스의 방향을 변경할 수 있으므로 화면 너비가 고정되어 있다고 가정하지 마세요.

이전 Windows Mobile 및 Blackberry 디바이스는 페이지 헤더에서 다음 메타 태그를 수락하여 콘텐츠가 모바일에 최적화되어 있으므로 변환해서는 안 됨을 알릴 수도 있습니다.

<meta name="MobileOptimized" content="width" />
<meta name="HandheldFriendly" content="true" />

추가 리소스

모바일 ASP.NET 웹 애플리케이션을 테스트하는 데 사용할 수 있는 모바일 디바이스 에뮬레이터 및 시뮬레이터 목록은 테스트를 위해 인기 있는 모바일 디바이스 시뮬레이션 페이지를 참조하세요.

크레딧

기본 저자: 스티븐 샌더슨
검토자 / 추가 콘텐츠 작성자: James Rosewell, Mikael Söderström, Scott Hanselman, Scott Hunter

다음을 통해 공유

방법: ASP.NET Web Forms/MVC 애플리케이션에 모바일 페이지 추가

콘텐츠

개요

이전 버전의 ASP.NET 지원되는 모바일 브라우저

현재 모바일 디바이스 지원의 과제

아키텍처 옵션

이 문서에서는 서버 쪽 기술에 중점을 둡니다.

브라우저 및 디바이스 검색

ASP 사용. NET의 기본 제공 브라우저 검색 지원

51Degrees.mobi Foundation을 통해 WURFL 디바이스 데이터베이스 사용

Web Forms 애플리케이션이 모바일 관련 페이지를 표시할 수 있는 방법

모바일 관련 master 페이지 만들기

독립적인 모바일 관련 Web Forms 만들기

모바일 방문자를 모바일 페이지로 리디렉션

모바일 페이지를 준수하도록 양식 인증 구성

출력 캐싱 작업

작업 예제

ASP.NET MVC 애플리케이션이 모바일 관련 페이지를 표시할 수 있는 방법

ASP.NET MVC 애플리케이션 내에서 모바일 영역 설정

URL /Mobile이 모바일 홈페이지에 도달하는지 확인

모바일 방문자를 모바일 영역으로 리디렉션

모바일 페이지를 준수하도록 양식 인증 구성

출력 캐싱 작업

작업 예제

추가 지침 및 제안

51Degrees.mobi Foundation을 사용하여 리디렉션 논리 향상

트랜스코더 및 프록시 서버 사용 안 함

모바일 브라우저용 모바일 페이지 스타일 지정

추가 리소스

크레딧

피드백

피드백

추가 리소스