<div id="readability-page-1" class="page"><div>웹뷰 프로젝트를 진행하고있다. 
할때마다 느끼는건데, 웹뷰는 프론트만 잘 구현한다고 되는게 아닌 것 같다. 
회사별, Android, IOS 플랫폼별 웹뷰 정책이 너무 천차만별이라 어디선 되고 어디선 안되는게 너무 많다.
일단 진행하면서 경험한 이슈들을 정리해본다.
<h2 id="android-history-back-이슈">[Android] history back 이슈</h2>
 Android Webview 에서 사용자 액션에 의해 url hash가 추가되는 기능이 있었다. 
웹에서는 history back을 했을 때, 추가되었던 url hash가 정상적으로 제거되었으나, android webview에서는 history back이 먹통이었다.
 의아한건, history stack의 length가 2인 상태에서 추가되는 history state에 대해선 정상동작한다는 점이었다. 네이티브쪽에서는 back 이벤트 자체가 안잡힌다고하는데 참 의아하다.
일단은 일정이 급한관계로, 
꼼수로 페이지가 로드되었을때 임의로 history stack length를 하나 증가시켰다.
<pre><code>/**
 * 현재 Android Webview에서 처음 로드 시, history back이 제대로 동작하지 않는 이슈가 있다.
 * history stack length 가 3부터는 history back이 정상동작한다.
 * 
 * 일단 임시로, 로드된 후에 임의로 history stack을 1 증가시킴으로써 history back의 정상동작을 보장한다.
 * (loaded 라는 url hash 추가)
 */
export const useInitializePageForAndroidWebview = () =&gt; {
 const { isApp, isAOS } = useDevice();
 const { appendHash, hash } = useUrlHash();

 const initializePage = () =&gt; {
 if (isApp &amp;&amp; isAOS) {

 setTimeout(() =&gt; {
 if (!hash?.includes('loaded')) {
 appendHash('loaded');
 }
 }, 1000);
 }
 };

 useEffect(() =&gt; {
 initializePage;
 }, []);
};</code></pre>
<h2 id="ios-windowinnerheight-vh">[IOS] window.innerHeight, vh</h2>
일반적으로 <code>window.innerHeight === 100vh</code> 로 알고있고, 웹에서는 문제없이 동작한다. 
그러나 IOS에서 window.innerHeight과 100vh의 값이 다른경우가 있었다.
이것 또한 처음 웹뷰 로드시에만 발생했으며, 네이티브쪽에서도 원인은 밝혀내지 못했다. 
일단 100vh 를 직접계산해보고, innerHeight과 비교하여 큰 값으로 height을 세팅하도록 작업했다.
<pre><code>/**
 * 초기 뷰포트 사이즈를 가져온다.
 * 웹뷰에서 최초 렌더링 시, 100vh 보다 window.innerHeight의 값이 작은 경우가 있다.
 * 그 경우 100vh 값을 사용할 수 있도록 한다.
 * @returns number
 */
export const getInitialViewportHeight = () =&gt; {
 const viewportHeight = window?.visualViewport?.height ?? window.innerHeight;
 return viewportHeight &lt; getVhToPx(100) ? getVhToPx(100) : viewportHeight;
};</code></pre></div></div>

ginameee.log

Jangchun Lee

웹뷰 프로젝트를 진행하고있다.
할때마다 느끼는건데, 웹뷰는 프론트만 잘 구현한다고 되는게 아닌 것 같다.
회사별, Android, IOS 플랫폼별 웹뷰 정책이 너무 천차만별이라 어디선 되고 어디선 안되는게 너무 많다.
일단 진행하면서 경험한 이슈들을 정리해본다.
[Android] history back 이슈
 Android Webview 에서 사용자 액션에 의해 url hash가 추가되는 기능이 있었다.
 웹에서는 history back을 했을 때, 추가되었던 url hash가 정상적으로 제거되었으나, android webview에서는 history back이 먹통이었다.
 의아한건, history stack의 length가 2인 상태에서 추가되는 history state에 대해선 정상동작한다는 점이었다. 네이티브쪽에서는 back 이벤트 자체가 안잡힌다고하는데 참 의아하다.
일단은 일정이 급한관계로,
꼼수로 페이지가 로드되었을때 임의로 history stack length를 하나 증가시켰다.
/**
 * 현재 Android Webview에서 처음 로드 시, history back이 제대로 동작하지 않는 이슈가 있다.
 * history stack length 가 3부터는 history back이 정상동작한다.
 * 
 * 일단 임시로, 로드된 후에 임의로 history stack을 1 증가시킴으로써 history back의 정상동작을 보장한다.
 * (loaded 라는 url hash 추가)
 */
export const useInitializePageForAndroidWebview = () => {
 const { isApp, isAOS } = useDevice();
 const { appendHash, hash } = useUrlHash();
 const initializePage = () => {
 if (isApp && isAOS) {
 setTimeout(() => {
 if (!hash?.includes('loaded')) {
 appendHash('loaded');
 }
 }, 1000);
 }
 };
 useEffect(() => {
 initializePage;
 }, []);
};
[IOS] window.innerHeight, vh
일반적으로 window.innerHeight === 100vh 로 알고있고, 웹에서는 문제없이 동작한다.
그러나 IOS에서 window.innerHeight과 100vh의 값이 다른경우가 있었다.
이것 또한 처음 웹뷰 로드시에만 발생했으며, 네이티브쪽에서도 원인은 밝혀내지 못했다.
일단 100vh 를 직접계산해보고, innerHeight과 비교하여 큰 값으로 height을 세팅하도록 작업했다.
/**
 * 초기 뷰포트 사이즈를 가져온다.
 * 웹뷰에서 최초 렌더링 시, 100vh 보다 window.innerHeight의 값이 작은 경우가 있다.
 * 그 경우 100vh 값을 사용할 수 있도록 한다.
 * @returns number
 */
export const getInitialViewportHeight = () => {
 const viewportHeight = window?.visualViewport?.height ?? window.innerHeight;
 return viewportHeight < getVhToPx(100) ? getVhToPx(100) : viewportHeight;
};

2023.08.03

댓글