콘텐츠
반응 형 웹 디자인이 몇 년 전 데스크톱과 모바일 사이트 사이의 격차를 좁혔 듯이, 현재 진보적 인 웹 앱 기술은 웹과 앱 세계 사이의 격차를 좁히고 있습니다. 데스크톱에서 모바일 앱으로의 사용자 경험이 빠르게 수렴됨에 따라 훨씬 더 세련되고 효율적인 인터넷이 진화하고있는 것처럼 보입니다. 기본 유전자 코드에 대한 상당한 변경 없이는 불가피합니다.
- 프로그레시브 웹 앱을 빌드하는 방법
분명히 이것을 추진하는 몇 가지 중요한 선택적 압력이 있습니다. 우선, 모든 틈새 시장을위한 네이티브 앱을 만드는 것이 반드시 리소스를 효율적으로 사용하는 것은 아닙니다. 사용자는 결국 수백 개의 큰 앱이 대역폭과 귀중한 디스크 공간을 낭비하게되며 기업은 포기할 앱을 만드는 데 막대한 돈을 소비합니다. 첫 번째 버전 이후. 그리고 이러한 앱의 대부분은 웹 서비스 또는 콘텐츠 관리 시스템에서 오는 정보와 같은 웹 콘텐츠에 의해 구동됩니다.
프로그레시브 웹 앱의 정의는 구체적이지 않습니다. PWA는 점진적 향상을 사용하여 웹 플랫폼에서 몇 가지 새로운 API와 기능을 사용하여 동일한 코드 기반으로 모든 플랫폼에서 앱과 같은 경험을 제공하는 웹 앱입니다. 사용자에게 우수한 앱과 같은 경험을 제공하는 모범 사례 및 API 사용에 가깝기 때문에 PWA가 있거나없는 것이 아닙니다. 귀하의 사이트가 다소 PWA 인 것 같습니다.
새로운 사이트 구축을 시작 하시겠습니까? 웹 사이트 빌더를 사용해보십시오. 또한 적절한 웹 호스팅 서비스에서 필요한 지원을 받으십시오. 또는 약간 다른 내용은 최고의 클라우드 스토리지 가이드를 참조하세요.
PWA의 상승
PWA라는 이름은 2015 년 Google에서 Chrome 팀을 위해 일하는 Alex Russell의 'Escaping Tabs Without Losing Our Soul'기사에서 만들어졌지만 실제로는 그곳에서 시작되지 않았습니다. 우리는 1999 년 Microsoft에서 만든 HTML 응용 프로그램 (HTA)과 Nokia, BlackBerry 및 기타 회사의 다른 많은 웹 응용 프로그램 플랫폼을 사용했습니다. 그런 다음 2007 년에 Steve Jobs는 원래 iPhone 용 앱을 만들 수있는 유일한 방법 인 PWA (이름은 다르지만)를 발표했습니다. Chrome은 거기서 시작하여 몇 년 후 API를 개선하고 PWA 이름을 발명했습니다.
웹 콘텐츠를 앱의 세계로 가져 오려는 이전의 실패한 경험이 너무 많았는데 지금은 왜 작동 할 것이라고 생각할까요? 우선, Microsoft, Google, Apple 및 Mozilla와 같은 PWA의 기반이되는 기술을 현재 작업하고 홍보하고있는 회사에 달려 있습니다. 또한 웹 플랫폼의 성능은 잘 설계된 PWA와 네이티브 앱을 비교할 때 차이가없는 지점에 도달했습니다. 이러한 조건은 이전에 존재하지 않았으며 웹 커뮤니티가 PWA의 시대가 왔다고 결정한 이유 중 하나입니다.
오늘날 실행중인 PWA
오늘날 PWA는 다음 위치에 완벽하게 작동하고 설치할 수 있습니다.
- 대부분의 브라우저가 탑재 된 Android, Chrome이 최고의 경험을 제공합니다.
- iOS와 Safari
- Chromebook
- Microsoft Store의 Windows 10
- Firefox OS의 포크 인 KaiOS가 탑재 된 피처 폰은 현재 주로 인도에서 수백만 명의 사용자가 사용할 수 있습니다.
올해 말 Chrome을 통해 macOS, Windows 및 Linux에도 지원이 제공됩니다. 지금 사용해보고 싶다면 실험용 플래그 인 '데스크톱 PWA'로 오늘 사용할 수 있습니다. 특정 시간 프레임이 정의되어 있지 않지만 저장소를 사용하지 않고 Windows on Edge에 설치하는 것도 나중에 제공 될 예정입니다.
목록을 다시 읽으면 모든 플랫폼이 다음 달에 완전히 설치 가능한 PWA를 지원하거나 지원할 예정임을 알 수 있습니다. PWA는 호환되는 브라우저에서만 활성화되는 기능을 갖춘 웹 사이트 일 뿐이므로 기본 기능에서 모든 브라우저와 호환된다고 말할 수도 있습니다.
또한 PWA는 현재 Angular 6+ CLI, React Create App, Polymer의 PWA Starter Kit 및 Preact CLI를 포함한 다양한 프레임 워크에 대한 대부분의 CLI에서 생성되고 있습니다. 마지막으로 Ionic Framework 팀은 모든 앱 스토어에서 기본 PWA를 가능하게하는 오픈 소스 Cordova 대체품 인 Capacitor에 대한 아이디어를 내놓았습니다.
설치
PWA의 중요한 측면 중 하나는 앱 설치입니다. 이 프로세스는 앱 파일의 다운로드 및 오프라인 저장과 OS의 아이콘 설치의 두 가지 선택적 단계로 수행됩니다. 두 단계 모두 선택 사항이므로 브라우저에서 오프라인 환경을 제공하거나 오프라인 설치없이 아이콘을 제공 할 수 있습니다. 그러나 진정한 PWA에는 두 가지가 모두 포함되어야합니다. HTTPS 하에서 TLS로 제공되어야하며 사용자는 브라우저에서 사용할지 아니면 자체 설치된 아이콘 내에서 사용할지 결정합니다.
오프라인 및 즉시 실행
PWA의 두뇌는 서비스 워커입니다. 사용자 기기에 설치된 자바 스크립트 파일은 앱 파일을 다운로드하고 캐시에 저장 한 다음 나중에 필요할 때 제공하는 역할을합니다. 서비스 워커가 설치되면 웹앱에 필요한 모든 리소스에 대한 네트워크 프록시 역할을합니다. 네트워크에서 가져 오거나 로컬 캐시에서 전달할 수 있습니다. 이렇게하면 앱을 오프라인에서 사용할 수 있고 사용자가 연결되어 있어도 몇 밀리 초 만에 네이티브 앱 실행을 에뮬레이트합니다.
서비스 워커를 설치하려면 HTML 문서에 다음과 같은 내용이 포함되어야합니다.
if (네비게이터의 'serviceWorker') navigator.serviceWorker.register ( "sw.js");
그러면 범위라고하는 개념 인 현재 도메인의 현재 폴더에 대한 사용자의 장치에 "sw.js"파일이 설치됩니다. 설치 후 범위 내의 모든 URL에 대한 다음 방문은 해당 서비스 워커가 관리합니다.
index.html, app.js, app.css 및 logo.png의 네 가지 파일이있는 PWA가 있다고 가정 해 보겠습니다. 첫 번째는 sw.js 파일의 캐시에 해당 파일을 설치하는 것입니다.
const resources = [ "index.html", "app.js", "app.css", "logo.png"]; 본인. addEventListener ( "install", event => {event. waitUntil (caches.open ( "myPWAcache") .then (cache => cache.addAll (resources)));});
그런 다음 PWA가 항상 캐시에서 제공 되려면 서비스 워커 내에서 가져 오기 이벤트를 수신하고 사용할 캐시 정책을 결정해야합니다 (예 : 다음 스 니펫으로 먼저 캐시).
self.addEventListener ( "fetch", e => e.respondWith (caches.match (e.request). then (res => res);
이 경우 사용자가 브라우저 나 설치된 아이콘 모두에서 PWA에 액세스 할 때마다 엔진은 캐시에서 파일을 가져옵니다. 기본 앱에 비해 PWA의 장점은 변경 사항이있을 때 기기가 모든 파일을 다시 다운로드 할 필요가없고 투명한 프로세스로 변경된 파일 만 다운로드 할 필요가 있다는 것입니다. 또한 요청시 앱의 일부를 계속 다운로드 할 수 있습니다.
하지만 문제는 서버에서 어떤 파일이 업데이트되었는지 어떻게 알 수 있으므로 캐시에서 대체 할 수 있다는 것입니다. 이를 관리하기 위해 낮은 수준의 서비스 워커를 작성하지 않으려는 경우 오픈 소스 라이브러리 Workbox를 사용하면 서비스 워커 및 리소스 매니페스트를 생성하여 설치된 패키지를 업데이트하는 데 도움이됩니다.
사용 가능한 경우 영구 저장소를 요청하지 않는 한 장치에 저장 공간이 부족하면 PWA의 파일이 삭제됩니다.
if (네비게이터의 '스토리지'& navigator.storage의 '지속') navigator.storage.persist ();
Chrome 및 대부분의 Android 브라우저에서 앱은 사용 가능한 공간의 5 % 이상을 사용할 수 없습니다. iOS에서는 호스트 당 50MiB (약 50MB)입니다. Edge에서는 총 메모리 크기에 따라 가변적이며 Windows Store에서는 무제한입니다.
일류 경험
우리는 두뇌를 가지고 있으며 이제 심장을위한 시간입니다. 웹 앱 매니페스트입니다. 웹 사이트를 PWA로 전환하는 목적은 웹 사이트를 빠르게 또는 오프라인 상태에서 사용할 수 있도록하는 것뿐만 아니라 OS에 자체 아이콘이 있고 설치된 다른 앱과 마찬가지로 완전히 독립형 환경을 제공 할 수 있도록하는 것입니다.
매니페스트는 설치 동작을 정의하기 위해 브라우저 또는 앱 스토어에서 사용하는 PWA에 대한 메타 데이터를 정의하는 JSON 파일입니다.
이 파일은 여러 속성을 PWA의 메타 데이터로 정의합니다. 각 OS는 이러한 속성을 읽고 선호하는 환경과 일치하도록 최선을 다합니다. 예를 들어 Android는 '디스플레이 : 독립형'을 읽고 일반적인 앱 환경을 만듭니다. 'display : minimal-ui'를 사용하면 보안에 민감한 앱에 유용한 URL과 TLS 인증서를 볼 수있는 환경을 만들 수 있습니다. '디스플레이 : 전체 화면'을 사용하면 상태 표시 줄이나 눈에 보이는 뒤로 버튼없이 완전히 몰입 형 앱을 만들 수 있습니다. 아이콘 및 색상 세트는 시작 화면 또는 제목 표시 줄이 앱 창에 표시되는 방식을 정의합니다.
웹 앱 매니페스트 생성기 또는 PWA 빌더와 같은 일부 매니페스트 생성기는 고해상도 해상도 (최소 512 픽셀)를 제공하는 경우 다른 해상도로 아이콘 크기를 조정합니다.
HTML 문서에 매니페스트 파일이 링크되어 있으면 사용자는 브라우저에 따라 일반적으로 홈 화면에 추가, 설치 또는 추가라고하는 다양한 기술을 사용하여 앱을 설치할 수 있습니다. Bing에서 PWA를 크롤링 할 수있는 경우 Microsoft는 자동으로 Microsoft Store에 추가하여 Windows 10 사용자가 여기에서 설치할 수 있습니다.
일부 운영 체제에서는 PWA가 링크를 캡처 할 수 있습니다. 즉, 사용자가 앱을 설치 한 후 매니페스트 범위 내의 모든 URL은 브라우저 또는 WhatsApp, Facebook과 같은 다른 앱에 표시되는지 여부에 관계없이 브라우저가 아닌 앱 경계 내에서 열립니다. 또는 이메일.
여기에서 정의한 PWA 요구 사항을 통과하면 일부 플랫폼에서 앰비언트 배지 (일반적으로 웹을 설치할 수 있음을 나타내는 URL 표시 줄에있는 작은 아이콘) 또는 웹 앱 배너를 제공합니다. 원하는 경우 다음 스 니펫을 사용하여 사용자 지정 설치 버튼을 추가 할 수도 있습니다.
window.addEventListener ( "beforeinstallpr ompt", function (e) {e.prompt (); // 설치 기본 프롬프트 표시})
PWA가 설치되어있는 경우’appinstalled’이벤트가 창 개체에서 실행되어이를 수신하는 통계를 추적 할 수 있습니다.
앱 스토어
브라우저에서 설치하는 것의 주요 이점 중 하나는 앱 스토어 승인 프로세스를 피하거나 게시자가되기 위해 비용을 지불해야한다는 것입니다. 즉석 게시, 회 사용 비공개 앱 만들기 또는 스토어에서 허용해서는 안되는 앱과 같은 분명한 이점이 있습니다.
그러나 일부 회사는 매장에 있기를 원합니다. 현재 공식적으로 PWA를 허용하는 유일한 상점은 Windows Store와 kaiOS Store입니다. 다행히 Capacitor (현재 Alpha 버전) 또는 PWA Builder와 같은 도구를 사용하여 다른 플랫폼 용 기본 패키지도 만들고 서명 할 수 있습니다.
Twitter Lite 및 Google Maps Go와 같은 Google Play 스토어에 이미 게시 된 일부 PWA가 현재 맞춤 구현 중입니다. Chrome은 신뢰할 수있는 웹 활동을 통해 Chrome 68의 솔루션을 제공합니다. 그 시점부터 PWA에 대한 런처가있는 Android 패키지 (APK)를 생성하여 스토어에 업로드 할 수 있습니다. Windows 10의 Microsoft Store의 경우 사이트 PWA Builder는 현재 APPX Windows 10 패키지 생성을 돕고 있습니다. 웹보기를 사용하면 App Store 용 iOS 앱을 수동으로 생성 할 수 있지만 스토어의 규칙에 매우주의해야합니다.
플랫폼 통합
점진적 향상 기술을 구현하면 푸시 알림, 카메라 및 마이크 액세스, 지리적 위치, 센서, 결제, 공유 대화 상자 및 오프라인 저장소를 포함한 많은 기능을 사용할 수 있습니다. 권한 대화 상자를 포함하여 이러한 모든 기능은 브라우저의 보안 모델 내에서 직접 실행됩니다.
또한 URL 또는 whatsapp : //와 같은 사용자 지정 URI를 통해 Twitter, YouTube 또는 WhatsApp 열기와 같은 URI 체계를 통해 다른 앱과 통신 할 수 있습니다.
마지막으로 Capacitor 또는 Microsoft Store를 사용하여 스토어에 게시되는 네이티브 PWA를 만들 때 거의 모든 네이티브 코드를 실행할 수있는 네이티브 API에 연결할 수 있습니다. Windows 10과의 통합에는 하드웨어 액세스뿐만 아니라 OS와의 통합도 포함되어 Pin to Start와 같은 옵션을 제공합니다. 예를 들어 Twitter PWA를 사용하면 모든 사용자를 시작 화면에 고정 할 수 있습니다.
디자인 및 UX 과제
PWA 설계에는 고유 한 과제가 있으므로 가능한 한 많이 조사하고 테스트하고 다음 사항을 고려하는 데 시간을 보내는 것이 중요합니다.
- 사용자는 앱과 같은 경험을 기대합니다.
- 설치 프로세스는 아직 새롭기 때문에 앱 설치 방법을 설명하기 위해 추가 노력이 필요합니다.
- 사용자 상호 작용없이 백그라운드에서 앱을 업데이트하는 것은 좋지만 UX에 몇 가지 문제가 추가됩니다.
- 데스크톱에서 반응 형 웹 디자인은 PWA 창이 모바일 뷰포트보다 훨씬 작을 수 있기 때문에 새로운 영역을 개척합니다. 즉, 오늘날 Chrome OS에서 볼 수 있듯이이 형식에 대한 특정보기 또는 작은 위젯을 만들어야합니다.
- 푸시 알림은 사용자에게만 가치를 부여해야하므로 적시에 요청하는 방법을 배우고 유용하지 않거나 흥미롭지 않은 메시지를 보낼 기회를 낭비하지 마십시오.
- 웹 성능과 오프라인 액세스를 위해 디자인해야합니다.
PWA의 해
올해 iOS와 데스크톱이 추가됨에 따라 PWA는 오늘날 어디에나 있습니다. 그러나 우리는 그들의 여정이 이제 막 시작되었다는 것을 기억해야합니다. 따라서 잦은 변화를 예상하고 플랫폼이 발전하는 동안 우수한 사용자 경험을 제공하기 위해 최신 기술과 아이디어를 지속적으로 업데이트해야합니다.
이 기사는 원래 308 호에 게시되었습니다. 그물, 웹 디자이너와 개발자를위한 세계에서 가장 많이 팔리는 잡지입니다. 여기서 308 호 구매 또는 여기에서 구독하세요.
