이전 두 글에서 안드로이드 딥링크 구현 관련 내용을 다뤘었다. 당시 풀리지 않은 문제가 하나 있었다.웹 기록 챌린지 페이지(https://ohouse-web.vercel.app/record-challenge)에서 웹뷰 앱 기록 챌린지 탭(https://ohouse-web.vercel.app/record-challenge)으로 앱 링크 방식으로 딥링크를 구현하였지만, 두 url이 동일해서 그런지 앱 링크 설정이 잘 되었음에도 불구하고 웹에서 앱으로 넘어가지 못했다. 그래서 그때 내가 제시한 예상 해결 방안은 두 가지였는데,1. url 스킴 방식으로 해결 2. App Link 방식으로 하되 url에 웹과 앱 링크를 구분하기 위한 특정 매개변수 추가 1번 방식으로 일단 안드로이드 딥링크는 잘 동작하도록 구현은..

지난 글에서 안드로이드 딥링크 구현과 관련된 부분을 알아봤다.그때 앱 링크와 url 스킴에 대해서 알아봤었는데 그 외에도 알게 된 점이 많아서 그 부분을 좀 알아보려고 한다. OS, 브라우저 여부에 따른 분기 처리이 부분이 필요한 이유는 다음 이미지를 보면 알 수 있다. 왼쪽은 웹 기록 챌린지 페이지이고, 오른쪽은 앱 기록 탭이다. 물론 두 페이지는 동일한 웹페이지이다.즉, 왼쪽은 웹페이지를 그대로 안드로이드 에뮬레이터 크롬 창에서 접속한 거고, 오른쪽은 웹페이지를 웹뷰 앱에서 그대로 띄워준 거다.다만 브라우저에서 접속한 경우인지를 판단하여 분기 처리를 해주었다. 이렇듯, 우리는 웹과 앱에서 접속한 OS 환경 (Android, iOS 등), 브라우저 환경인지 여부에 따라 분기 처리를 해줄 수 있다.아래 ..

웹뷰 스터디를 진행하면서 딥링크도 구현해 볼 수 있는 기회를 얻었다. 이전부터 웹뷰 앱을 만든다면 정말 중요하게 생각할만한 포인트 중 하나가 딥링크라고 들었다. 이번에 딥링크를 공부해보니 신기하고 재밌었다. 근데 레퍼런스가 너무 없어서 정신 나갈 뻔.. 딥링크일단 딥링크에 대해서 알아보자. 딥링크란 특정 앱으로 이동시키는 동작을 의미한다. 우리가 무신사 앱에서 결제 버튼을 누르면 토스 앱으로 넘어가는 동작 같은 걸 상상하면 될 거 같다. 물론 앱뿐만 아니라 웹에서도 가능하다. 모바일 기기 브라우저에서 특정 버튼을 누르면 앱이 열리고 특정 앱 화면으로 전환이 되는 동작 같은 거 말이다. 이번에 내가 구현해본 동작은 웹페이지에서 앱으로 전환하는 동작이다. 아래 화면을 살펴보자. 오늘의 집 클론코딩한 페이지인..

이번에는 또 다른 스터디다. 살려주세요리액트 딥다이브 책 같이 읽은 분들과 아쉬워서 Next.js 공부도 살짝? 하고 결국 이 스터디까지 이어지게 됐다.이것저것 스터디라는 이름답게 진짜 이것저것 다 공부한다. 요즘 디자인 시스템 최적화와 관련된 전반적인 지식과 컴포넌트 개발만 하다 보니, 전체적인 구조를 설계하는 능력이 떨어짐을 몸소 느껴버렸다.이걸 회사 과제 테스트 보면서 느껴버려서 좀 더 많이 와닿았던 거 같기도?어쨌든 그래서 뭔가 특단의 대책 같은 게 필요했고, 단순히 기한에 맞춰서 제대로 된 설계도 없이 프로젝트 개발만 하는 거 말고, 좀 내부 구조도 생각해 보고 설계도 고민을 한참 해볼 수 있는 능력이 필요하다고 느꼈다. 그래서 나와 다른 스터디원들이 많이 부족하다고 느끼는 것들 위주로 한 주차..

이번에는 RNCWebViewManagerImpl 파일을 좀 더 자세히 살펴보자. 이전 글에서 설명했다시피 RNCWebViewManager에서는 UI와 관련된 기능 및 웹뷰 개별 인스턴스로 관리해야 하는 기능들이 들어가 있다고 했다.그래서 우리가 웹뷰 컴포넌트를 사용하며 너무나 자주 사용하는 injectJavascript, postMessage, onMessage와 같은 기능들이 다 여기 들어가 있는 것이다. 우리가 알아볼 코드는 아래 링크를 접속하면 볼 수 있다.https://github.com/react-native-webview/react-native-webview/blob/master/android/src/main/java/com/reactnativecommunity/webview/RNCWebVie..

이번엔 웹뷰 공부를 시작했다.사실 CMC 14기 스터디를 진행하면서 웹뷰 관련 과제를 진행해 본 적이 있었는데, 당시 너무 고통받았던 기억에 그 이후로 웹뷰 공부할 생각을 하지 않았다. 그런데 내가 생각하기에 웹뷰 공부를 꼭 해야하는 이유가 두 가지 있다.1. 토스, 당근, 캐치테이블 등 정말 많은 회사가 이미 구축되어 있는 웹을 기반으로 웹뷰 방식 앱을 사용하고 있다.2. 프론트엔드 전반적인 지식을 조금 더 활용해 볼 수 있는 환경이라고 생각한다. 사실 웹뷰를 사용하기만 해보면 의미가 없을 수 있는데, 웹뷰 내부 구조를 파고들면 파고들수록 새로운 개념이 나온다.이때, 웹에만 한정된 것이 아니라 모바일(aos, ios)까지 공부를 해보며 아키텍처나 동작 방식을 파악해 볼 수 있다.이 과정에서 배우는 점이..

이번 주 과제는 아이콘 자동화 피그마 플러그인 개발이었다.이거까지 하게 될 줄은 몰랐는데, 당근, 채널톡 코드들을 좀 살펴보니 그렇게까지 무리한 도전은 아닐 거 같아서 그냥 시작해 버렸다. 일단, 피그마 플러그인이 돌아가는 로직에 대한 가벼운 이해가 필요해 그거부터 알아보도록 하자. 피그마 플러그인 로직다음 사진은 피그마 플러그인이 돌아가는 로직을 한눈에 파악할 수 있는 좋은 레퍼런스이다.간단히 말하자면, 피그마 플러그인은 두 계층에서 동작한다.sandbox와 iframe인데 여기서 sandbox는 피그마 플러그인 관련 로직, 즉 비즈니스 로직 쪽과 관련이 있고, iframe은 우리가 보는 UI와 관련이 있다.중요한 점은 sandbox에서는 브라우저 API 같은 건 호출하지 못하고 플러그인 API는 호출..

컴포넌트 개발을 마치고 빌드 후 docs에서 테스트해 보면서 알게 된 사실이 있다. 바로,,, 타입 에러를 제대로 잡아주지 못한다는 것이었다. wow-ui의 기존 롤업 설정에서는 아래와 같이 절대 경로를 변환해 주는 플러그인을 도입해 놨기 때문에 문제가 없을 거라 생각했다. 그리고 이 플러그인을 도입했을 때 styled-system 경로도 잘 변환됐기 때문에 당연히 src/types 즉 공통 타입 파일들도 문제없이 변환해 줄 거라 생각했다.alias({ entries: [ { find: "@", replacement: path.join(__dirname, "./src") }, { find: "@styled-system", replacement: path.join(__dirname, "./styled-sy..