델파이 코드 주석 추가 및 문서화 방안

2019. 5. 30. 17:09

주석은 코드를 더 읽기 쉽고, 유지보수하기 쉽게 할 수 있는 가장 기본적인 요소 중 하나입니다.

특히 팀단위로 개발하거나, 오랫동안 유지보수해야 하는 경우 진가를 발휘합니다.

 

이 글에서는 주석을 좀 더 효과적으로 달고, 내용을 문서화하는 방법을 소개합니다.

XMLDoc과 JavaDoc 주석의 특징과 추가 방법, 문서화 하는 방법을 알아봅니다.

 

XMLDoc과 JavaDoc 주석 추가

XMLDoc 주석

XMLDoc 주석의 특징

  • 3 중 슬래시(///)로 시작
  • XML 태그로 작성
  • 코드 에디터의 헬프 인사이트에 표시
  • XML 태그로 가독성이 다소 떨어짐

XML 주요 항목

  • <summary> 함수 또는 클래스에 대한 설명
  • <param name="파라메터 이름"> 파라메터에 대한 설명
  • <returns> 함수의 반환 값 설명
  • < exception cref="예외 유형"> 메소드에서 전달되는 예외

예시

XMLDoc의 특징

XML Doc 주석 추가 시 코드 에디터의 헬프 인사이트에 표시됩니다.

단, 선언부(interface 영역)에 XML Doc 추가 시에만 표시됩니다.

한가지 팁으로, 코드 템플릿에 템플릿을 추가하면 필요시 코드에디터에 주석을 쉽게 추가 할 수 있습니다.

(Ctrl + J > 키워드 입력 또는 키워드 입력 > Ctrl + J)

 

코드 템플릿 추가방법

View > Tool Windows > Templates 메뉴 선택

New Code Template 버튼 클릭

아래 코드 참고해 XML 태그 수정 후 저장(예> xmldoc.summary.xml)

xmldoc.summary.xml
0.00MB

 

또는 위 XML 태그로 xml 파일 생성(별도의 텍스트 에디터에서) 및 저장

템플릿 디렉토리에 xml 파일 복사

(10.3 기준 템플릿 디렉토리 : C:\Program Files (x86)\Embarcadero\Studio\20.0\ObjRepos\en\Code_Templates\Delphi)

 

JavaDoc 주석

자바의 주석 형식으로 주석을 작성하면, 별도 프로그램을 이용 문서화(HTML, CHM, PDF 등)가 가능합니다.

JavaDoc 주석의 특징

  • 블록 주성({** 시작 *}로 끝) 또는 한줄 주석(3 중 슬래시(///)로 시작)
  • 주석의 속성(태그)은 @으로 시작
  • XMLDoc에 비해 주석 가독성이 높음(짧음)

JavaDoc 주요 태그

  • 태그 없는 경우 함수에 대한 설명
  • @author 작성자
  • @version 버전
  • @param 메소드 파라메터 설명
  • @return 반환 값 설명
  • @throws 메소드에서 전달되는 예외

예시

 

주석 문서화

추가한 주석을 문서화(문서로 내보내기)하는 방법을 알아봅니다.

XMLDoc 주석 문서화

XMLDoc을 문서화 하기 위해서는 Model을 생성해야 합니다.

Projects 팬에서 Model View 탭을 선택 후 모델을 생성합니다.

Model View에서 문서화할 대상(프로젝트 또는 유닛) 선택 후 팝업메뉴에서 "Generate Documentation..." 메뉴를 선택 합니다.

문서화 범위(Scope) 및 옵션(Options)를 선택 후 [OK] 버튼을 클릭 합니다.

 

결과 예시

다음과 같이 XMLDoc 주석을 추가했습니다.

 

생성된 HTML은 다음과 같습니다.

JavaDoc 주석 문서화

JavaDoc 포맷의 주석을 문서화 하기 위해서는 별도의 프로그램을 이용해야 합니다.

이 글에서는 DelphiCodeToDoc를 이용해 문서화합니다.

 

DelphiCodeToDoc은 델파이로 제작된 오픈소스(GPL)로 자유롭게 설치하고 필요한 기능을 수정해 기여할 수 있습니다.

문서화 포맷으로 CHM, HTML, PDF를 지원합니다.(Configuration 화면의 Output options > Output Format에서 지정)

결과물이 썩 이쁘지는 않지만, 그렇게 나쁘지도 않습니다.

 

DelphiCodeToDoc(DCTD) 설치

DelphiCodeToDoc(DCTD) 실행

DelphiCodeToDoc.exe 실행 후 [New] 버튼 클릭(또는 File > New 메뉴 선택)

마법사 페이지에서 옵션 설정 및 대상 파일(또는 디렉토리) 선택 및 추가 후 [Finish]

메인화면에서 [Check and Build] 버튼 클릭(또는 Project > Check and Build 메뉴 선택)

빌드 시 CHM 도움말이 표시되고, 지정된 경로(Ouput Folder)에 지정된 포맷

 

결과 예시

DCTD에서 설정한 프로젝트 관련 내용 표시

프로젝트 이름을 한글로 설정 시 좌측 내용트리에 한글깨짐 현상이 있으나, 문서내에서는 정상출력 확인

 

프로시저에 대한 문서

@author, @version 태그 추가했지만, 문서에 표시되지 않음

웹으로 내보내기한 Unit에 대한 문서

총평

XMLDoc과 JavaDoc 주석을 추가하고 문서화 하는 내용을 살펴봤습니다.

 

XMLDoc은 주석에 XML 태그가 있어 코드내의 가독성은 떨어지지만, 헬프 인사이트에 표시된다는 장점이 있습니다.(단, 선언부에 주석을 달아야 합니다.

JavaDoc은 코드내 주석에 대한 가독성이 상대적으로 높지만, 헬프 인사이트 등으로 표시되지 않습니다.

 

문서의 결과물은 개인적으로 JavaDoc의 결과물이 더 다양하고 깔끔하다고 생각합니다.

또한 오픈소스여서 필요한 경우 직접 수정해 필요한 기능을 확장할 수 있습니다.(물론 쉽지 않습니다.)

 

위 내용을 종합적으로 판단한다면 저는 개인적으로 JavaDoc을 선호합니다. 이유는 XMLDoc은 선언부에 주석을 달아야 하기 때문에 구현부를 전체적으로 살펴볼때 JavaDoc의 주석 형식이 더 유용할 것으로 판단됩니다.

(또는 2개의 방식을 번갈아가며 사용해도 좋을 것 같습니다. 선언부는 XMLDoc, 구현부는 JavaDoc)

 

여러분들도 여러분들의 환경에 맞는 방식을 선택 해보시기 바랍니다.

 

참고로 위 방법 외에도 doxygen 등과 같은 주석 문서화하는 방법이 많습니다.

그리고 JavaDoc 주석을 문서화 하는 프로그램도 많을 것입니다.

혹시 아는 주석 문서화 방법이나 문서화 프로그램이 있다면 댓글로 알려주시면 감사하겠습니다.

 

참고 링크

험프리.김현수 Delphi/C++Builder DCTD, DelphiCodeToDoc, Javadoc, XMLDoc, 주석

[마이그레이션 사례] 워프비전(64-bit 애플리케이션)

2019. 5. 24. 14:34

수원 영통구에 위치한 워프비전은 반도체 및 디스플레이 필름등의 검사 장비를 제공하는 업체입니다.

최근 카메라의 발전으로 이미지 해상도가 높아지고, 윈도우 10 등의 최신 운영체제 지원을 위해 마이그레이션을 진행했습니다.

워프비전 - 마이그레이션 컨설팅

  • 프로젝트 기간 : 2019년 4월(1개월)
  • 지원 방법 : 마이그레이션 컨설팅
  • 델파이 버전 : 델파이 2007 32-bit > 델파이 XE7 32/64-bit
  • 업무 범위
    • 메인 프로그램 : 2개 프로젝트(약 100여개 소스코드)
    • 컴포넌트 : 자체제작 2개, 오픈소스 2개

워프비전은 반도체 및 디스플레이 필름등의 검사 장비를 제공하는 업체로, 설비를 제어하고 관리하는 소프트웨어가 델파이로 개발되었습니다. 

 

마이그레이션 진행

워프비전은 최근 카메라의 발전으로 고해상도 이미지를 32-bit 환경에서 운용 시 메모리 부족 현상이 발생했습니다.

32-bit 프로세스에서 4GB의 메모리로 대용량 이미지 처리에 한계가 있어, 64-bit 지원으로 대용량 이미지 처리가 필요했습니다.

 

또한, 납품을 위해 구입하는 PC의 운영체제가 대부분 윈도우 10 64-bit가 설치되어 윈도우 10 대응을 위한 목적도 있고, 중국, 일본등의 고객사에게 현지언어를 지원하기 위한 멀티-바이트 문자열 지원도 하나의 이유였습니다.

 

마이그레이션 컨설팅

설비 소프트웨어 프로젝트의 경우 실질적인 소스코드의 양이 많지 않아 자체적으로 진행이 가능할 것으로 보였지만,  마이그레이션이라는 생소한 작업을 기존 업무와 병행하며 진행한다는 것이 생각보다 쉽지 않습니다.

더군다나 델파이 버전 업그레이드와 64-bit 지원 2가지를 진행해야 했기에 전문가의 도움을 받아 진행하는 것이 효과적이라 판단해 데브기어의 마이그레이션 컨설팅 프로젝트를 선택해 주셨습니다.

 

참고로, 저는 데브기어를 통해 3가지 방식으로 마이그레이션 작업을 지원합니다. 하단의 참고 항목을 확인해주세요.

 

핵심 과제

마이그레이션 작업의 핵심과제는 다음과 같습니다.

  • 델파이 버전 업그레이드
  • 64-bit 지원(32-bit와 병행 지원)
  • 자체 제작 컴포넌트 마이그레이션
  • 데이터 엑세스 컴포넌트 변경(FIBPlust > FireDAC)

작업 절차

64-bit 지원이 실질적인 핵심과제입니다. 하지만, 64-bit를 지원하는 델파이 버전으로 업그레이드가 선행되어야 합니다.

 

작업 절차는

  1. 델파이 2007(32-bit)을 델파이 XE7 32-bit로 마이그레이션
  2. 델파이 XE7 32-bit를 64-bit로 빌드 및 실행되도록 업그레이드

1차 작업에서 마이그레이션 작업을 대부분 처리하게 됩니다. 컴포넌트 전환 및 데이터 엑세스 컴포넌트 변경도 1차에서 완료됩니다.

2차 작업에서는 XE7 32-bit로 1차 완성된 결과물로 64-bit 지원하도록 작업합니다.

 

컴포넌트 전환

이 프로젝트의 특이점은 대부분의 UI 컨트롤들을 자체제작해 사용했다는 것입니다. 하지만 대부분 기본 컨트롤에 기능을 추가한 정도였습니다. 델파이 2007에서 델파이 XE7 32-bit로 마이그레이션 하는 과정에서 큰 이슈는 없었습니다.

 

그외 써드파티 컴포넌트들은 XE7을 지원하는 것들은 업그레이드 했고, 이벤트의 파라메터 데이터 타입이 변경되는 등의 작업정도로 진행했습니다.

그중 이슈는 오픈소스인 Toolbar2000의 경우 XE7을 지원하지 않았지만, 소스코드를 보유하고 있었기 때문에 소스코드를 컴파일 하며 문제가되는 부분을 직접 수정했습니다.(이후 64-bit 지원하도록 수정해 64-bit에서도 사용했습니다.)

 

 

데이터 엑세스 컴포넌트 변경

고객사는 Firebird를 DBMS로 사용했고, 데이터 엑세스 컴포넌트로 FIBPlus를 사용했지만, 내장된 데이터 엑세스 컴포넌트인 FireDAC 사용을 원했습니다.

 

reFind(마이그레이션 자동화 도구)를 이용해 컴포넌트 및 속성, 메소드등을 자동전환 하는 패턴을 직접 만들어 일괄 변경했습니다.

 

이미지 라이브러리 교체

해당 프로젝트에서는 JPEG 라이브러리로 인텔사의 IJL을 사용했습니다.

하지만 IJL은 64-bit를 지원하지 않아 다른 JPEG 라이브러리가 필요했습니다.

델파이 내장 JPEG 라이브러리인 TJPEGImage를 시도해 봤지만, 저장 시 성능이 좋지 않아 JPEG 라이브러리 검토 후 libJPEG-Turbo로 교채했습니다.

 

64-bit 지원

대부분의 코드들은 64-bit에서도 정상 동작합니다.

하지만, 일부 데이터 타입의 경우 32-bit와 64-bit의 크기가 달라 문제가 생길 수 있습니다.

이번 프로젝트의 대표적인 문제는 다음과 같습니다.

  • 포인터로 사용하는 변수가 Integer(또는 LongInt)로 선언된 경우
  • 포인터로 사용하는 변수를 Integer(또는 LongInt)로 형변환 하는 경우
  • 윈도우(또는 소켓) 핸들을 Integer 또는 LongInt로 사용하는 경우

대응방법은

  • 포인터의 경우 데이터 타입을 Pointer 또는 NativeInt로 지정
    (NativeInt의 경우 32bit에서 4Byte, 64bit에서 8Byte로 사용 됨)
  • 윈도우의 핸들의 경우 THandle로 명시적으로 데이터 타입 지정
  • 소켓 핸들의 경우 TSocket으로 명시적으로 데이터 타입 지정

참고자료

 

기타 기능 추가

VCL 스타일 적용 : http://tech.devgear.co.kr/delphi_news/414834

다국어 지원 : http://tech.devgear.co.kr/delphi_news/408214

 

마지막으로, 

최근 사용자들은 윈도우10 등의 64-bit 운영체제를 많이 사용합니다.

64-bit 운영체제 환경이라도 32-bit 애플리케이션을 개발해 배포 및 사용해도 윈도우즈의 호환성 모드로 잘 동작합니다.

많은 메모리 사용 등의 이슈가 있는 경우에 한해 64-bit 애플리케이션 개발을 검토하시기 바랍니다.

 

참고

저는 데브기어를 통해 3가지 방식으로 마이그레이션을 지원합니다.

마이그레이션 무상 컨설팅

마이그레이션 체크리스트와 가이드 문서를 제공합니다. 작성 후 메일을 보내주시면 이메일과 방문을 통해 컨설팅을 지원합니다.

 

마이그레이션 워크샵(4일)

마이그레이션을 좀 더 효과적으로 직접 진행하고 싶다면, 워크샵 과정에 참석하세요. 마이그레이션 자동화 방안, 가이드 문서 작성 등을 배우고, 혼자 해결하기 어려운 부분을 멘토링을 통해 해결해 더 쉽고, 빠르게 마이그레이션 할 수 있습니다.

마이그레이션 컨설팅(유상)

마이그레이션 시의 위험요소 파악, 전환체계(자동화 방안, 마이그레이션 가이드 작성 등) 구축 등을 경험많은 마이그레이션 전문가를 통해 진행할 수 있습니다.

  • 별도로 요청해 주세요.. : ask@embarcadero.kr

험프리.김현수 마이그레이션

[VCL] 용량이 큰 JPEG 파일 다루기 - JPEG 라이브러리 조사

2019. 5. 23. 17:05

프로젝트 중 큰 용량의 JPEG 파일을 다룰 필요가 있어, 64-bit를 지원하는 JPEG 라이브러리를 조사한 내용 공유합니다.

 

고객사에서는 카메라에서 제공하는 이미지의 해상도가 높아짐(16384 x 29300)에 따라 64-bit 애플리케이션으로 마이그레이션을 계획했고, 성공적으로 완료했습니다.

JPEG 라이브러리

그 과정 중 검토한 JPEG 라이브러리는 다음과 같습니다.

  • TJPEGImage(VCL 내장 JPEG 라이브러리)
  • libJPEG-Turbo
  • Intel IJL / IPP(IJL 64-bit 미지원, IPP 상용)

고객사의 기존 프로젝트에서는 IJL을 이용해 JPEG을 다뤘지만, IJL은 개발이 중단되었고 64-bit를 지원하지 않아 검토 대상에서 제외되었습니다.(IPP로 통합되어 상용으로 판매 중)

 

TJPEGImage

TJPEGImage는 VCL에 내장된 라이브러리로 32-bit, 64-bit를 모두 지원합니다.

별도의 라이브러리 파일(*.dll 등)을 배포할 필요가 없고, 클래스 단위로 제공되고 매우 익숙합니다.

(단, 성능이 좋지 않다는 평가를 검색을 통해 확인하였습니다. 내부적으로 libJPEG으로 구현된 것으로 알고 있습니다.)

 

libJPEG-Turbo

libJPEG-Turbo는 SIMD 명령어를 사용해 JPEG 압축과 해제를 가속화 하는 JPEG 이미지 코덱입니다.

공식 웹사이트에서는 libJPEG 보다 2~6배 이상 빠르다고 합니다.

(크롬, 리눅스, 안드로이드 등에서 libJPEG 대신 libJPEG-Turbo를 사용)

 

델파이 연동은 아래 오픈소스들을 참고했습니다.

JPEG 라이브러리 성능 테스트

테스트 대상은 JPEG 파일 크기별 3종으로 진행했습니다.

  • 작은 사이즈(1600x1200)
  • 큰 사이즈(16384x12200)
  • 매우 큰 사이즈(16384x29300)

 

32-bit와 64-bit 애플리케이션으로 진행했습니다.(32-bit 애플리케이션에서 매우 큰 사이즈는 메모리 부족으로 진행할 수 없었습니다.)

기존 라이브러리와 비교하기 위해 32-bit에서 IJL도 진행했습니다.

 

테스트 코드는 JPEG 파일을 TBitmap으로 불러오거나 반대로 저장하도록 작성했습니다.(고객사에서 픽셀단위로 이미지 프로세싱 진행)

 

참고로, 

TJPEGImage의 Performace 속성을 jpBestSpeed로 설정했습니다. jpBestQuality로 설정 시 3~4배의 성능 차이가 발생합니다.)

JPEG 품질은 모두 75로 설정 했습니다.

테스트 환경

  • 개발도구 : 델파이 10.3.1
  • OS : 윈도우 10 64bit(MacOS의 VM위에서 운용)
  • 메모리 : 8GB

테스트 결과

JPEG 불러오기(Load)

Load 과정에서는 예상외로, TJPEGImage의 성능이 좋다는 결과를 확인했습니다.

 

32-bit 큰 이미지의 경우 libJPEG-Turbo 대비 40%(2028 : 1137) 성능향상을 확인 했습니다.

IJL과 libJPEG-Turbo은 약 10%의 성능차이를 확인할 수 있습니다.

 

64-bit 환경에서도 TJPEGImage가 libJPET-Turbo 대비 큰 이미지의 경우 30%, 매우 큰 이미지의 경우 약 17% 가량 성능이 좋은 것으로 확인했습니다.

 

JPEG 저장(Save)

저장하는 과정은 libJPEG-Turbo가 TJPEGImage 보다 속도가 빨랐습니다.

 

특히 32-bit의 큰 이미지의 경우, 유독 TJPEGImage의 성능이 매우 좋지 않은 결과가 나왔습니다.(libJPEG-Turbo 대비 약 5배의 시간 소요)

TJPEGImage의 내부 로직을 살펴본 결과 이미지의 행(Row)의 메모리를 한번에 복사하는 과정에서 시간을 많이 소요했습니다.(해결방법은 찾지 못했습니다.)

 

64-bit에서 저장은 libJPEG-Turbo가 TJPEGImage 대비 20~30% 속도가 빨랐습니다.

 

총평

JPEG 불러오기에서는 TJPEGImage가 JPEG 저장에서는 libJPEG-Turbo가 앞선 성능을 확인할 수 있었습니다.

 

문제는 32-bit 큰 이미지 저장 시 TJPEGImage가 매우 좋지 않은 성능을 보여, 최종 선택은 libJPEG-Turbo로 진행했습니다.

해당 이슈만 없다면, TJPEGImage도 좋은 선택일 것 같습니다.

 

만약, JPEG을 빠르게 다룰 필요가 있다면, 위 테스트 내용과 첨부된 테스트 코드를 이용해 여러분 환경에 맞도록 테스트 진행 후 선정해 보시기 바랍니다.

 

테스트 코드

JPEGPerformanceTest.zip
2.44MB

 

험프리.김현수 Delphi/C++Builder Delphi, JPEG, libJPEG-Turbo, TJpegImage

[FMX] 안드로이드 권한 모델 적용 방법

2019. 5. 17. 11:25

파이어몽키로 안드로이드 앱 개발 시 장치에 접근하는 기능(예, 카메라 이용, 블루투스 이용 등) 개발 시 권한 설정이 필요합니다.

 

기존에는 Project > Options > Uses Permissions에서 필요한 권한을 설정하는 방식이었지만, 

안드로이드 API 최신버전은 런타임 시 권한을 요청하는 매커니즘으로 변경되었습니다.

 

기존의 권한 모델은 설치 시 전체 권한을 승인하는 방식이었습니다. 새로운 권한 모델은 기능 사용 시 개별 권한을 묻는 방식으로, 사용자는 기능 별 허용 및 거부가 가능해졌습니다.

기존 권한 요청 방식 새로운 권한 요청 방식

새로운 권한 요청 방식은 RAD 스튜디오 10.3 부터 적용되며, 

기존에 작성했던 안드로이드 프로젝트는 권한 요청하는 로직을 추가하도록 업데이트 해야 합니다.

 

안드로이드의 권한 요청 로직

안드로이드 권한 요청은 System.Permissions.pas에 구현된 PermissionsService.RequestPermissions 메소드를 호출하는 것으로 시작합니다.

 

다음 코드는 델파이 샘플 중 Location(Object Pascal/Mobile Snippets/Location)의 일부입니다.

procedure TLocationForm.swLocationSensorActiveSwitch(Sender: TObject);
begin
{$IFDEF ANDROID}
  if swLocationSensorActive.IsChecked then
    PermissionsService.RequestPermissions([JStringToString(TJManifest_permission.JavaClass.ACCESS_FINE_LOCATION)],
      procedure(const APermissions: TArray<string>; const AGrantResults: TArray<TPermissionStatus>)
      begin
        if (Length(AGrantResults) = 1) and (AGrantResults[0] = TPermissionStatus.Granted) then
          { activate or deactivate the location sensor }
          LocationSensor1.Active := True
        else
        begin
          swLocationSensorActive.IsChecked := False;
          TDialogService.ShowMessage('Location permission not granted');
        end;
      end)
  else
{$ENDIF}
    LocationSensor1.Active := False;
end;

위코드에서는 TLocationsSensor 즉, GPS 연동하는 코드 전에 안드로이드인 경우({$IFDEF ANDROD}) 위치 권한(TJManifest_permission.JavaClass.ACCESS_FINE_LOCATION)을 요청하는 코드가 추가되었습니다.

 

RequestPermissions 메소드의 파라메터는 다음과 같습니다.

procedure RequestPermissions(const APermissions: TArray<string>;
  const AOnRequestPermissionsResult: TRequestPermissionsResultEvent;
  AOnDisplayRationale: TDisplayRationaleEvent = nil); overload; virtual;

첫번째 파라메터는 요청하는 권한 문자열 배열, 두번째는 권한 요청 결과를 받아볼 수 있는 메소드, 세번째는 사용자에게 권한에 대한 안내를 할 수 있는 메소드입니다.

 

델파이 샘플의 AccessCameraApp의 코드에는 권한요청하는 로직이 다음과 같이 구현되어 있습니다.

procedure TAccessCameraAppForm.btnTakePhotoClick(Sender: TObject);
begin
  PermissionsService.RequestPermissions(
    [FPermissionCamera, FPermissionReadExternalStorage, FPermissionWriteExternalStorage],
    TakePicturePermissionRequestResult,
    DisplayRationale
  )
end;

// Optional rationale display routine to display permission requirement rationale to the user
procedure TAccessCameraAppForm.DisplayRationale(Sender: TObject; const APermissions: TArray<string>; const APostRationaleProc: TProc);
var
  I: Integer;
  RationaleMsg: string;
begin
  for I := 0 to High(APermissions) do
  begin
    if APermissions[I] = FPermissionCamera then
      RationaleMsg := RationaleMsg + 'The app needs to access the camera to take a photo' + SLineBreak + SLineBreak
    else if APermissions[I] = FPermissionReadExternalStorage then
      RationaleMsg := RationaleMsg + 'The app needs to read a photo file from your device';
  end;

  // Show an explanation to the user *asynchronously* - don't block this thread waiting for the user's response!
  // After the user sees the explanation, invoke the post-rationale routine to request the permissions
  TDialogService.ShowMessage(RationaleMsg,
    procedure(const AResult: TModalResult)
    begin
      APostRationaleProc;
    end)
end;

procedure TAccessCameraAppForm.TakePicturePermissionRequestResult(Sender: TObject; const APermissions: TArray<string>; const AGrantResults: TArray<TPermissionStatus>);
begin
  // 3 permissions involved: CAMERA, READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE
  if (Length(AGrantResults) = 3)
      and (AGrantResults[0] = TPermissionStatus.Granted)
      and (AGrantResults[1] = TPermissionStatus.Granted)
      and (AGrantResults[2] = TPermissionStatus.Granted) then
    TakePhotoFromCameraAction1.Execute
  else
    TDialogService.ShowMessage('Cannot take a photo because the required permissions are not all granted')
end;

1) 3가지 권한을 요청합니다.

2) DisplayRationale 메소드에서 필요한 권한에 대해 설명합니다.

3) 요청결과 메소드에서 권한일 모두 허용한 경우 기능을 실행합니다.

 

위에서 주의할 점은, 

권한에 대한 설명 시(DisplayRationale 메소드) 메시지 호출 후 비동기로 APostRationaleProc 메소드를 호출해야 합니다.

그리고, 권한에 대한 설명 메소드는 옵션으로 생략할 수 있습니다.

 

위 내용을 참고해 권한이 필요한 기능을 개발하는 경우 해당 기능 호출 전 권한을 요청하도록 추가 및 기존 코드를 변경하시기 바랍니다.

해당 기능은 안드로이드 앱 개발 시 적용해야 하는 기능으로, 다른 플랫폼 앱 개발 시 생략할 수 있습니다.

 

엠바카데로에서 제공하는 내용과 이미 적용된 샘플 앱의 목록은 다음 링크에서 확인할 수 있습니다.

 

다음 글들이 안드로이드 권한 모델 적용 내용이 업데이트 되었습니다.

 

험프리.김현수 파이어몽키 FMX, 권한요청, 안드로이드