블록체인하는 만두아빠

Flutter로 앱을 제작하다가 AVD, iOS Simulator 등으로 디버깅할 때 뜨는 Debug 라벨 제거 방법입니다.

아래와 같이 Appbar를 사용하지 않는 앱을 개발할 때 특히 Debug 라벨이 더 거슬리기도 하는데, 제거 방법은 매우 간단합니다.

stl 혹은 stf Widget에서 return되는 MaterialApp 안에 다음의 명령어 한 줄이면 됩니다.

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
        debugShowCheckedModeBanner: false,
        ...
        )
   }

debug 라벨을 제거하면 다음과 같이 깔끔한 디버깅 환경에서 테스트를 해볼 수 있습니다.

debug 라벨을 제거하지 않더라도 실제 Release 때는 라벨이 자동으로 제거가 되니 너무 걱정하지 않으셔도 됩니다.

일반적으로 main.dart 안에서만 모든 Widget을 구성한 경우가 아니라면 라벨을 제거하고 싶은 MaterialApp 마다 Debug 라벨 제거를 직접 해주셔야 합니다.

Flutter에서 앱을 작성하고, 구글 플레이스토어에 심사를 제출하기 전에 필요한 내용들을 정리.

(추후에 스크린샷을 추가하여 수정할 예정)

1. 앱 서명하기

Mac 기준 keystore 만드는 명령어.

keytool -genkey -v -keystore ~/key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias key

여기서 생성된 파일은 공개 저장소에 올리지 말 것.

2. app/build.gradle 에서

• version Code 설정
• applicationID 작성
• signingConfigs 만들고 buildTypes를 debug에서 release로 변경
• keystoreProperties 작성
• 2021.12월 기준 TargetSdkVersion은 30 이상으로 작성되어야함

3. android 폴더에서

• key.properties 작성

터미널에서 flutter build appbundle 입력하여 aab파일 생성 → build/app/outputs/bundle/release에 app-release.aab 파일 있음

4. 개인정보처리방침 만들기

개인적으로 제작할 경우 관련 사이트(개인정보보호 포털)를 사용하고 이미 있는 경우 링크를 등록

5. 추가 필요한 내용

• 앱 액세스 권한
• 광고
• 컨텐츠 등급
• 타겟층
• 뉴스 앱
• 코로나19 접촉자 추적 앱 및 검사 결과 공유 앱
• 데이터 보안
• 웹 카테고리 선택 및 세부정보 제공
• 스토어 등록정보 설정
  • 앱 이름, 80자 설명, 4000자 자세한 설명.
  • 그래픽
    • 앱 아이콘(512x512)
    • 그래픽 이미지(1024x500)
    • 스크린샷 16:9 비율 320px~3840px, 2~8장
    • 7인치 태블릿 스크린샷(16:9 320x3840)
    • 10인치 태블릿 스크린샷(16:9 320x3840)

React 프로젝트 빌드 시 Expected linebreaks to be 'LF' but found 'CRLF' 에러가 발생할 경우 처리 방법 2가지!

Windows와 Mac 환경에서 번갈아가며 작업하는 등의 경우 간헐적으로 발생하는 에러로 Windows의 경우 캐리지 리턴(CR) 이후에 줄바꿈(LF)을 사용하여 CRLF가 되는 반면, Linux의 경우 단순 줄 바꿈(LF)의 형태를 사용하기에 나타나는 문제입니다.

1. 소스 코드 내에 직접 규칙을 작성하는 방법

   - Windows PC의 경우

/* eslint linebreak-style: ["error", "windows"] */

   - Unix의 경우

/*eslint linebreak-style: ["error", "unix"]*/

2. .eslintrc.js 파일에 규칙 직접 추가하는 방법

...

rules: 
	{
      'linebreak-style': 0,
    }
    
...

위의 방법 중 어느 것을 선택하든 쉽게 오류를 처리할 수 있습니다. 다만 컴포넌트의 갯수가 많은 경우 일일이 소스코드 내에 규칙을 작성해주는 것보다, 2번의 방법이 훨씬 편리할 것입니다.

열심히 만든 어플리케이션을 Apple App Store에 배포하기전 내부 테스트를 진행할 수 있도록 돕는 TestFlight를 사용해봅시다. Google Play Store에서는 자체적인 링크를 통해서 내부 테스팅을 진행할 수 있게 하는데, App Store에서는 TestFlight라는 별도의 앱을 통해서 코드를 받고, 코드 교환을 통해서 내부 테스트용 앱을 설치해볼 수 있도록 하고 있습니다.

우선 테스트할 앱을 빌드하고나서 developer.apple.com을 통해 App Store Connect로 들어갑니다.

사용자 및 액세스에 접속해서 내부 테스팅을 할 유저를 추가해줍니다. 참여할 내부 테스터의 Apple ID를 입력해주세요.

테스팅할 앱을 선택하고 TestFlight로 갑니다.

TestFlight에서 내부 테스팅에 + 를 눌러 테스팅 그룹을 먼저 추가해줍니다.

내부 그룹을 생성하셨으면 이제 테스터를 등록해줄 수 있습니다.

초대가 진행이되면 노란색으로, 초대가 정상적으로 되어 설치가 되면 설치되었다는 진행 상태가 표시됩니다. 테스터로 등록되어 초대받은 분에게는 해당 apple 계정에 등록된 메일주소로 다음과 같은 메일이 발송됩니다.

Accept invitation을 통해 Apple Developer 사이트로 넘어가서 로그인을 해줍니다. 등록이 정상적으로 진행이 되면 새로운 메일이 하나 더 메일주소로 오게됩니다.

해당 어플리케이션을 TestFlight에서 설치할 수 있는 코드를 담은 메일입니다. 이제 View in TestFlight를 통해 코드를 받고, TestFlight 앱에서 내부 테스팅을 진행할 수 있습니다!

열심히 작업한 모바일 어플리케이션을 구글 플레이스토어에 배포하기 전, 내부 테스트를 진행할 수 있습니다. 내부 테스트를 통해 실제 배포 이전에 버그나 최적화 등을 테스트해볼 수 있습니다. 우선 내부 테스트를 업로드하기 전에 테스트 환경을 설정해보도록 합시다.

테스트를 진행하고자하는 테스터는 우선 구글 플레이 모바일 앱으로 접속합니다. 프로필을 클릭하고 설정으로 들어갑니다.

가장 아래쪽에 정보를 클릭합니다.

Play 스토어 버전을 연속으로 계속 클릭해주세요. 개발자 모드가 열립니다.

완료되면 일반 탭에 가셔서 내부 앱 공유를 열어주실 수 있습니다. 

이제 내부 테스트 링크를 통해 어플리케이션을 미리 설치해서 내부 테스트를 진행할 수 있습니다.