게으름으로 인하여 두 번째 상추 재배는 수확까지 끝난 다음에야 포스팅을 하게 되었습니다. 두 번째 상추 재배는 새로운 그로잉스펀지와 재배기에 심을 수 있는 12포트 중에서 4포트만 사용하여 상추를 재배했습니다. 그리고, TDS 측정기를 이용하여 양액의 농도 측정도 하면서 재배를 하였습니다. 수경 재배기를 살 때 포함되어 왔던 그로잉스펀지는 지난번 상추 재배로 인하여 모두 소비되어서 알리에서 새로운 스펀지를 주문했습니다. 주문하면서 실수로 동그란 스펀지가 아닌 네모 스펀지를 주문하는 바람에 포트에 넣었을 때 약간의 공간이 생깁니다만 크게 문제가 되지는 않습니다. 그런데 이번에 스펀지는 번들 스펀지에 비해서 밀도가 높다라고 해야할지 스펀지에 구멍이 적은 것 같습니다. 상추 뿌리가 스펀지를 뚫고 나오는데 지난번 보다 오래 걸린것 같습니다. 다음에 주문할 때에는 이런 부분을 좀 주의해야 할 것 같습니다. 그리고, 스펀지와 함께 TDS 측정기도 함께 구매해서 양액의 농도도 측정하였습니다. 상추의 경우 560 ~ 840 정도의 TDS 범위로 양액을 맞춰주라고 하는데, 수경 재배기에 번들된 양액을 12포트 분량으로 혼합하면 이 범위를 만족합니다. 지난번 재배에서는 이 값을 몰라서 싹을 틔우는 시기와 어린 시기에 양액 농도를 낮게 했었는데 그럴 필요는 없었던 것 같습니다. 약 5주 가량 길러서 수확하기 직전의 상태입니다. 12포트를 키울 떄 보다 빛을 잘 받아서 그런지 웃자람도 없고, 상치 잎의 크기도 지난번보다 상대적으로 컸습니다. 보통 상추를 키울때, 잎이 커지면 일부를 따 먹으면서 계속 키우는데 4포트만 키우게 되면 잎을 따 먹기에는 양이 너무 적어서 다 키워서 한번에 수확을 해야 했습니다. 그래서 다음 재배는 포트수를 조금 더 늘려서 시도해보겠습니다.
개발하고 있는 앱에서 다른 사용자를 앱으로 초대하는 기능을 추가하게 되어 앱에 deep link 기능을 앱에 구현하게 되었습니다. 구현에 필요한 자료는 이미 더 잘 정리되어 있는 많은 자료들이 있으니 그것들을 참고하면 될 것 같아서 여기에서는 특별히 설명하지 않습니다. 다만 내 앱에 해당 기능을 넣기 위해서 자료를 찾고 구현하는 과정에서 헷갈렸던 것들과 구현중 문제가 있었던 부분에 대해서 프로젝트를 정리하는 차원에서 메모를 남기기로 해서 글을 쓰고 있습니다.
참고:
- https://itnext.io/deep-linking-in-flutter-boost-user-experience-in-apps-29dd25842757
- https://docs.flutter.dev/ui/navigation/deep-linking
용어
deep link는 보통 웹에서 인덱스 페이지가 아닌 상세 페이지에 대한 다이렉트 링크를 생성하는 것을 말합니다. 예를 들어서 어떤 웹페이지를 사용하기 위해서는 홈 화면에서 로그인을 하고 몇 단계를 거쳐서 특정 페이지로 들어가야하는데, 이 기능에 대한 지름길을 만드는걸 deep link로 이해하면 되겠습니다. 그리고 deep link 구현관련하여 모바일에서는 OS에 따라서 custom scheme(url scheme), universal link, app link 등의 용어가 튀어 나오는데, 표준 URI 형식을 이용하여 앱을 실행시키기 위한 방법을 말한다고 이해하면 간단하겠다. 기술에 대한 상세로 들어가면 약간의 차이가 있으나 큰 틀에서 차이는 없기 때문에 deep link를 구현하기 위해서 app을 실행(lunch)하기 위한 기술이라고 보면 됩니다.
그리고, 검색하다가 보면 dynamic link라는 용어가 나오는데, firebase에서 제공하던 서비스인데 현재는 서비스 종료되었으니 무시하면 됩니다.
Navigator / Router
flutter로 deep link를 구현할 때 현재 앱이 Navigator를 이용하여 화면 전환을 처리하느냐, Router를 사용하여 화면 전환을 처리하느냐에 따라서 구현하는 방법의 차이가 발생합니다. 그리고 flutter에서 제공하는 기본 가이드에서는 router를 사용하는 방법으로 설명하고 있습니다. 그리고, 인터넷에서 검색되는 자료들이 대체로 router를 이용하는 방법을 설명하고 있습니다. 또 flutter로 웹 개발하는 경우를 기준으로 설명하고 있고, 또 router 가 더 편하기(?) 때문에 router를 이용하는 방법으로 설명을 하고 있는 것 같습니다.
저의 경우에는 원래 개발은 Navigator를 이용하고 있어서, 처음에는 app_links 패키지를 이용하여 개발하려고 했으나, 기존에 구현되어 있던 코드의 초기화 부분과 context 관련 문제로 인하여 단순히 app_links를 사용하여 적용할 수 없어서 go_router 패키지를 도입해서 전체적으로 화면 전환 처리를 변경하였습니다.
go_router와 같은 router 를 이용하면 deep link를 이용하여 페이지 전환은 패키지 차원에서 지원이 되기 때문에 처리가 매우 간단해 집니다.
하지만 개발이 끝난 시점에 다시 생각하면 router 방식으로 변경하는 과정은 반드시 필요한 과정은 아니었습니다. 기존 코드에 app_links를 적용시 문제가 되었던 부분은 router로 전환하는 과정에서의 리팩토링과 테스트 과정에서 발생한 문제로 인한 app_links로 다시 전환하는 과정에서 추가적인 처리로 해결이 가능했습니다.
그리고, 제가 개발과정에서 혼돈이 있었던 부분중 하나가 용어 상의 문제가 있었습니다. "https://app.com/path" 와 같이 문자열 형태의 경로를 이용하는 deep link와 flutter에서 말하는 named route 가 같은 것으로 이해하여 문서를 읽고, 구현하면서 혼란을 겪었습니다. path와 named route 이 두개는 모양은 비슷하나 별개라고 생각해야 합니다.
다시 app_links 로..
iOS에서 앱이 실행되어 있지 않은 상태에서 deep link를 통하여 앱이 실행되는 경우에 앱은 deep link 지정된 경로를 바로 받는것이 아니고, initalRoute 경로(보통 '/')를 먼저 수신하고, 그 다음에 deep link에 지정된 경로를 수신하게 됩니다. 그로 인해, 저의 경우에는 초기화 처리 부분과 화면 전환 처리에 문제가 발생하였습니다. 이런 문제가 발생하는 이유는 flutter에서 deep link를 직접 받아서 router로 전달하면서 발생하는 문제인데 안드로이드에서는 발생하지 않습니다.
이를 해결하기 위해서 FlutterDeepLinkingEnabled 설정 값을 false로 변경하여, flutter에서 직접 deep link를 처리하지 않도록 설정을 변경해야 합니다.
이렇게 되면 go_router에서 deep link 경로를 자동으로 수신하지 않게 됩니다. 그래서 다시 app_links 패키지를 가져와서 universal link/app link/custom scheme 에 의하여 전달되는 경로를 수신하도록 변경하고,수신한 경로에 대한 화면 전환 처리를 별도로 수행하도록 변경하여 해결하였습니다.
deep link 자체 구현은 어렵지 않으나 내 앱에 해당 기능을 녹여 넣는 과정이 테스트 해야하는 케이스가 많아서 개발이 전체적으로 오래 걸렸습니다.
테스트 관련해서는 다음 링크를 참고하시면 케이스들에 대한 설명이 잘되어 있습니다.
참고 : https://help.dfinery.io/hc/ko/articles/360039757433-%EB%94%A5%EB%A7%81%ED%81%AC-Deeplink-URI%EC%8A%A4%ED%82%B4-%EC%9C%A0%EB%8B%88%EB%B2%84%EC%85%9C-%EB%A7%81%ED%81%AC-%EC%95%B1%EB%A7%81%ED%81%AC-%EA%B5%AC%EB%B6%84%EA%B3%BC-%EC%9D%B4%ED%95%B4
댓글
댓글 쓰기