- Service Scope: Web / Android / IOS
- Android / IOS 앱은 3월 중 출시 예정
- Application Developing Tool: Flutter / Android Studio / X Code
- Server Configuration: Ubuntu / AWS
- BackEnd Developing Tool: PHP / PHPMyAdmin (RDBMS) / 고객사 솔루션
- Native App Performance
- inApp Push Service: Firebase Cloud Messaging
- GPS: Geolocator
- 만보기: Pedometer / WorkManager
- inAppWebView PG 결제: Toss Payments SDK
- cupertino_icons: ^1.0.2
- geolocator: ^10.1.0
- permission_handler: ^11.0.1
- geocoding: ^2.1.1
- shared_preferences: ^2.2.2
- url_launcher: ^6.2.1
- package_info: ^2.0.2
- flutter_webview_pro: ^3.0.1+4
- webview_cookie_manager: ^2.0.6
- firebase_core: ^2.22.0
- firebase_crashlytics: ^3.4.4
- firebase_analytics: ^10.6.4
- firebase_messaging: ^14.7.4
- flutter_local_notifications: ^9.1.5
- get: ^4.6.6
- get_storage: ^2.1.1
- http: ^1.1.0
- geolocator_android: ^4.4.0
- geolocator_apple: ^2.3.2
- fluttertoast: ^8.2.4
- pedometer: ^4.0.1
- tosspayments_widget_sdk_flutter: ^1.0.2
- intl: ^0.18.1
- font_awesome_flutter: ^10.6.0
- device_info_plus: ^9.1.1
- android_id: ^0.3.6
- fk_user_agent: ^2.1.0
- workmanager: ^0.5.2
1. 소프트 키보드가 차지한 영역만큼 화면이 밀려 올라가지 않는 문제
2. 사용자가 선택한 TextField 위치로 Focusing이 되지 않는 문제
문제를 바라보는 관점에 따라 접근 방법 역시 달라진다.
1번 문제라면 네이티브 앱에서만 취할 수 있는 조치들이 있다.
2번 문제라면 웹 서버에서 취할 수 있는 조치와 연관지어서 접근해야 한다.
1) SingleChildScrollView
대부분의 상황에서는 SingleChildScrollView 위젯을 사용하면 해결된다.
화면 전체를 자연스럽게 스크롤이 가능한 영역으로 잡는다는 접근방식이다.
TextField 위젯이 소프트 키보드에 가려질 때 가장 먼저 시도 해볼만 하다.
기본적으로 List 객체에 담긴 데이터 값들을 Row에서 렌더링할 때 쓰는 방법이다.
결과적으로는 문제를 해결하지 못했다.
2) Adjust Resize
안드로이드 설정 자체를 건드리는 방법도 있다.
'AndroidManifest.xml' 파일에서 'activity' 설정 값을 변경하는 것이다.
보통 'android:windowSoftInputMode' 값을 'adjustResize'로 설정한다.
디버깅 결과, 효과가 전혀 없는 것은 아니었다.
결과적으로는 TextField를 터치하였을 때, 키보드 영역만큼 화면이 밀려 올라가기는 했다.
문제는 이 동작이 열 번이면 열 번 전부 동일하게 작동하지는 않았다는 것이다.
짐작하기로는 MediaQuery가 안드로이드 웹뷰에서 완벽하게 동기화되지 않는 것 같다.
다만, 이제는 접근 방법을 달리 해볼 필요가 있다는 것이다.
문제의 원인을 웹 서버에서 찾으려고 한다면 관점이 살짝 달라진다.
소프트 키보드가 차지한 영역만큼 화면이 밀려 올라가는 것과,
사용자가 터치한 TextField 위치로 시점이 전환되는 것은 어감에서 오는 느낌부터가 사뭇 다르다.
부럽 앱은 기본적으로 반응형 웹을 패키징한 구조이기 때문에 이 부분은 JavaScript로 해결할 수 있다.
해당 라인을 참조 바란다.
위, 아래 TextField (input, textArea) 어디를 터치하든지 간에 자연스럽게 시점이 이동한다.
또한, 네이티브 앱과 유사한 경험을 제공하기 위해 500ms 정도의 Interval을 두고 작동한다.
기구축된 Toss Payments PG결제가 앱에서 정상작동 하지 않는 문제
Toss Payments는 다양한 플랫폼에서의 간편 결제 서비스를 지원한다.
특히 One Touch 결제가 가능한 네이버, 카카오페이 등이 서비스의 핵심이다.
문제는 플랫폼마다 서로 다른 URL 스키마를 결과값으로 반환한다는 것이다.
가령, 카카오페이의 경우는 'kakao://'와 같은 포맷으로 결제를 요청한다.
각종 카드사들은 더 말할 것도 없을 것이다.
물론, TOSS사의 백엔드 개발자들이 이 점을 간과했을 리가 없다.
그 증거로 Toss Payments 제공하는 PG결제는 모두 일관된 URL 타입으로 파싱이 된 상태이다.
네이버페이의 경우, cardCode의 GET값이 'NAVERPAY', 토스페이는 'TOSSPAY' 와 같은 식이다.
하지만 TOSS 개발자들의 세심한 안배는 딱 거기까지이다.
Flutter 앱에서 간편 결제를 진행하였을 때는 여전히 URL Scheme 에러가 발생하지만...
스마트폰에 설치된 크롬 내지 사파리 브라우저는 해당사항이 없었기 때문이다.
아쉽지만 이러한 조치는 Mobile Web 환경까지만 고려한 것 같다.
그래도 여기까지 접근했다면 문제를 거의 해결한 것과 진배하다.
TOSS 개발자들이 그러하였듯이 앱에서도 동일하게 외부 URL을 파싱하는 것이다.
사실, 호언장담 했던 것만큼 간단한 작업은 아니다.
Scheme 에러를 발생시킬 법한 요소를 찾아내어 필터링 하는 과정이 필요하다.
특정 패턴의 문자열을 분리하거나 대체하는 등의 가공 처리 말이다.
필자의 역량으로는 여기까지가 한계였다.
하지만 Flutter에는 한계가 없나보다.
Toss Payments PG결제만을 위한 플러그인이 따로 있을 줄이야?
필자가 필요로 하는 모든 요구사항이 플러그인에 내장되어 있으니 가져다 쓰기만 하면 되는 것이다.
상세한 작업 내용은 링크를 참조 바란다.
그래도 간략하게나마 로직을 설명해보도록 하겠다.
우선 프로젝트에서 'tosspayments_url.dart' 패키지를 import 해주는 것이 첫 걸음이다.
다음으로 WebView 위젯 내부 'navigationDelegate' 프로퍼티에서 ConvertUrl() 플러그인 클래스를 호출한다.
이 ConvertUrl() 클래스 내부에 위치한 isAppLink() 메서드에서 URL 파싱 작업이 이루어진다고 보아도 무방하다.
그리고, 최종적으로는 launchApp() 메서드에서 PG결제 처리를 진행하는 것이다.
여담이지만 PG결제 페이지만큼은 증권사와의 API 연동 문제 때문에 WebView로 렌더링하는 경우가 많다고 한다.
고객사에서 직접 제작을 의뢰한 네이티브 기능중에 하나가 바로 만보기이다.
시중에 널리 사용중인 'Cash Walk' 종류의 앱들처럼 사용자의 걸음수를 클라이언트에서 직접 측정한 다음, 서버로 전송하는 것이다.
물론 의뢰 내용 자체는 도전을 불러일으킬 만큼 어렵지는 않았다.
Flutter는 안드로이드와 IOS 모두 사용 가능한 플러그인을 당연히 제공하기 때문이다.
서버와의 통신 역시 'http' 패키지를 사용하면 간단하다.
클라이언트와 서버 사이에서 이루어지는 HTTP 통신 절차는 링크1과 링크2를 참조 바란다.
진짜 문제는 UX와 운영 시스템 사이에서 발생하는 괴리에 있다.
우선 UX 관점에서 문제를 직시할 필요가 있다.
만보기는 중요한 기능이기는 하지만 앱의 핵심 컨텐츠라고 할 정도는 아니다.
가령, 사용자는 여행지의 관광정보 및 파생상품을 찾아보기 위해 앱을 사용하는 것이 최우선 목표이다.
그 다음에 오늘 하루 얼마동안 걸었는지를 확인할 수도 있고, 안할 수도 있는 것이다.
그런데 사용자는 이 시점에서 부자연스러움을 느낄 수가 있다.
예컨대, 어제 하루만 총 1만 걸음을 걸었다고 가정해보자.
그리고 오늘 정오 즈음에 문득 앱을 확인해봤는데, 1만 2천 걸음 정도가 찍혀있는 것이다.
비슷한 종류의 앱을 다수 경험한 사용자라면 여기서 이런 생각을 가질 수도 있다.
'이제 겨우 점심 시간인데 오전 사이에 1만보 넘게 걸었다고? 기록이 제대로 갱신된 게 맞아?'
결과적으로 사용자의 의심은 합리적이고, 하룻밤만 더 지나면 확신으로 바뀔 것이다.
오픈 초기부터 서비스에 대한 신뢰도가 어떻게 될지는 불 보듯 뻔한 일이다.
그렇다면 이제는 운영 시스템 측에 문제가 있는지 살펴보아야 한다.
앞서 설치한 Flutter Pedometer 플러그인은 OS를 기반으로 작동하기 때문이다.
정확히는 기기에 내장된 신체활동 감지 센서에 기록된 '총 걸음 수'를 리얼타임으로 구독하는 게 기능의 전부이다.
즉, 패키지 자체적으로는 '총 걸음 수' 관련 데이터만 읽어올 뿐, 이것들을 일일 단위로 초기화하거나 관리할 수는 없다.
그래서 필자는 해당 이슈를 UX와 OS 사이에서 발생하는 괴리, 즉 기술적인 한계로 일축한 것이다.
매일밤 자정이 지날 때마다 다시 0부터 걸음 수를 집계하는 것이 사용자에게는 경험적으로 익숙하다.
물론, 다른 플러그인을 찾아볼 법도 하지만 공식에 비해 버그가 많은 것이 사실이다.
그렇다면 남은 선택지는 딱 하나다.
필요한 기능을 직접 만들어서 쓰는 수밖에 없다.
Pedometer 컨트리뷰터들 역시 그것을 권장하고 있고 말이다.
요구사항은 복잡한 것 같으면서도 단순하다.
1. 걸음 수는 하루 단위로 측정 / 기록될 것
2. 매일밤 자정이 지나면 자동으로 걸음 수가 0으로 초기화 될 것
우선 1번 요구사항은 약간의 트릭이 필요할 수도 있다.
예컨대, 지난 하루는 총 7천 걸음을 걸었다고 가정해보자.
그리고 오늘 자정에 걸음 수를 다시 확인해보니 총 2만 걸음이 집계된 것이다.
그렇다면 오늘 하루는 약 1만 3천 걸음 정도를 걸은 셈이 된다.
그저 간단한 산수이다.
다만 간단하게나마 걸음 수를 저장할 공간이 필요하기는 하다.
그래야 금일과 익일을 구분해서 계산식을 세울 수 있지 않겠는가?
물론, 직접적인 데이터 관리는 서버에서 수행하기 때문에 내부 스토리지에 값을 저장할 필요는 없다.
대신, 데이터를 마치 Cache와 같은 개념으로 처리할 수 있는 'shared_preferences'를 사용하여 '오늘'의 걸음 수를 저장하기로 한다.