Always Awake

델파이에서 Project - Options - Orientation에서 Enable custom orientation에서 Landscape 를 체크 후

Mac OS 배포 시에 다음과 같은 에러가 난다면

ERROR ITMS-90474: "Invalid Bundle. iPad Multitasking support requires these orientations: 'UIInterfaceOrientationPortrait,UIInterfaceOrientationPortraitUpsideDown,UIInterfaceOrientationLandscapeLeft,UIInterfaceOrientationLandscapeRight'. Found 'UIInterfaceOrientationLandscapeRight' in bundle 'com.test.test'."

다음과 같이 해보자

Project - Options - Version Info에 들어가서 밑에 영역에서 오른쪽 키 클릭 - Add Key 

UIRequiresFullScreen 

UIRequiresFullScreen를 넣어 주고 True로 값을 준다

그리고 Save를 눌러 적용 시킨 후 다시 배포를 해보자.

IOS InappPurchase in delphi...

델파이 환경에서 IOS 비소모성 상품 인앱 결제를 구현해보겠습니다.

애플 App Store Connect 에서 앱을 등록 후 

앱 내 구입 - 관리에서 상품을 등록해줍니다.

여기서 제품 ID가 중요합니다.

테스트 하기 위해선 Sandbox에 등록을 해야 합니다.

이렇게 해야 과금 없이 테스트로 진행할 수 있습니다.

이것 역시 App Store Connet - 사용자 및 액세스 - 메뉴 하단 Sandbox - 테스터

사용자를 등록합니다. 단, 기존에 Apple 에 등록되어 있는 계정과 중복되어선 안됩니다!

위와 같이 등록을 해주시고 코드를 이제 살펴보겠습니다.

우선 델파이에서 인앱 컴포넌트를 추가합니다.

검색이 안되는 경우 맨위 상단 uses 절에 FMX.InAppPurchase을 추가합니다.

procedure TMainForm.iosInAppPurchase(Sender: TObject);
begin
  InAppPurchase1.ProductIDs.Add('Test'); // 등록한 제품 ID
  InAppPurchase1.OnSetupComplete := InAppPurchaseSetupComplete;
  InAppPurchase1.SetupInAppPurchase;
end;

procedure TMainForm.InAppPurchaseSetupComplete(Sender: TObject);
begin
  InAppPurchase1.QueryProducts;
  InAppPurchase1.RestorePurchasedProducts;
end;

저같은 경우 위와 같은 함수를 만들어서 처음 FormCreate 시 실행하게 하였습니다.

여기서 RestorePurchasedProducts을 참고하셔야 합니다.

안드로이드 같은 경우 알아서 재구매를 해주지만 IOS 같은 경우 비소모성 상품인 경우 위와 같이

RestorePurchasedProducts를 호출하여 결제 여부를 확인해줘서 이미 결제했을 경우 결제 처리가 됩니다.

{IFDEF IOS}
  try
    if InAppPurchase1.IsSetupComplete then
    begin
      if InAppPurchase1.IsProductPurchased('TEST') then
        begin
          결제 성공 시 이동
        end
      else
        begin
          if InAppPurchase1.CanMakeInAppPurchases then
             begin
                 InAppPurchase1.PurchaseProduct('TEST');
             end;
        end;
    end;
  except
    on e: Exception do
    begin
      ShowMessage(e.Message);
    end;
  end;
{ENDIF}

IsSetupComplete을 통해 Boolen값을 반환 받은 뒤

IsProductPurchased으로 이미 구입이 된 상품이면 다음을 처리하고 그렇지 않은 경우

CanMakeInAppPurchases 처리 후 PurchaseProduct('제품 ID')로 결제 루틴에 들어간다.

[참고] http://docwiki.embarcadero.com/RADStudio/XE7/en/Using_the_iOS_In-App_Purchase_Service#Prerequisites

[참고] http://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_the_iOS_In-App_Purchase_Service

델파이 환경에서 IOS 연동하여 개발을 할 수 있게 환경을 셋팅해보겠습니다.

우선 같은 네트워크 안에 있는 MacOS와 연결을 해야 합니다.

델파이 설치 경로에 있는 PAServer를 MacOS로 옮겨 맥북에서 설치를 하셔야합니다.

저 같은 경우에는 (C:\Program Files (x86)\Embarcadero\Studio\21.0\PAServer)에 PAServer21.0.pkg 파일을

옮겨서 맥북에서 설치를 하였습니다.

(※주의 MacOS와 PAServer 간의 버전이 일치하지 않을 시 Mac에서 프로그램이 반응하지 않을 수 있습니다.

이런 경우, 엠바카데로 사이트에가서 버전 호환을 체크해야 합니다.)

델파이 상단 메뉴 Tools - Options - Deployment - Connection Profile Manager 로 들어가서 Add를 누릅니다.

위와 같이 Profile name을 입력해 줍니다.

해당 MacOS IP번호가 Port번호를 입력 후 Test Connection해서 연결을 확인 합니다.

이렇게 성공이 되면 이제 기기를 연결해서 델파이에서 인식하게 해줘야 합니다.

이후에는 애플 개발자 사이트에서 사용자기기 등록 및 인증서 등록을 해줘야 델파이 쪽에서 인식해서 테스트 및 배포가 가능합니다!

[환경]

Window 10

Delphi 10.4.2

PAServer 21.0

macOS BigSur 11.2

자바 가상 머신인 JVM에 대해 간단히 알아보겠습니다~

(사진 출처 : https://www.guru99.com/java-virtual-machine-jvm.html)

자바의 큰 장점은 OS의 상관없이 플랫폼 위에서 작동을 한다는 것인데요.

OS위에 JVM이 있기 때문에 가능합니다.

이것은 JVM의 구조 입니다.

먼저 JVM을 사용하기 위해서는 JDK를 설치를 해야 하는데요.

오라클 홈페이지에서 다운을 받을 수 있습니다.

JDK는 JRE를 포함하여 자바개발도구와 자바컴파일러를 제공합니다.

JVM은 JDK에 포함된 JRE의 JVM과 Java API를 제공합니다.

1. 클래스 로더(Class Loader)

자바 프로그램의 확장자는 '.java'이며 이 파일이 자바 컴파일러에서 컴파일 과정을 거치면서 '.class' 파일이 생성됩니다.

즉 자바 소스가 JVM에 적재가 가능하도록 바이트 코드로 변환이 됩니다.

그러면 1번인 Class Loader가 클래스 로딩을 통해 Class 파일들을 JVM에 적재해 JVM은 클래스 파일을 읽고, 메모리를 할당해줍니다.

2. 메소드 영역(Method Area)

적재된 클래스 파일들은 2번 Method Area(메소드 영역)에 저장됩니다. 클래스 파일은 메소드와 클래스 변수로 구성되어 있고 메타정보라고 합니다.

JVM에서 클래스를 실행하면 메소드 영역에서 클래스 정보를 복사하고 힙 영역에서 메모리를 할당하여 실행합니다.

메소드 영역은 JVM 메모리 영역 중 가장 먼저 데이터가 저장 되는 곳!

3. 힙 영역(Heap Area)

메소드 영역에서 클래스 정보를 복사하면 이제 2번 Heap Area(힙 영역)에 메모리를 할당한다고 했습니다.

JVM의 영역 중에서 가장 중요한 역할을 담당 하는데요!

그 유명한 GC(Garbage Collection, 가비지 컬렉션)을 수행하는 영역입니다.

실행된 클래스를 객체라고 했을 때 이 객체가 힙 영역에 저장이 됩니다.

즉 힙 영역은 동적 데이터가 생성되고 소멸되는 영역이라 할 수 있겠습니다.

여기서 좀 더 깊게 들어가면 힙 영역에는 크게 3가지 영역이 더 있는데요.

Young Generation, Old Area, Permanent Area 가 있습니다. 그냥 참고 하시면 좋을 것 같습니다.

Young 영역은 다시 Eden, Servivor1, Servivor2 로 나눌 수 있어요.

Young 영역은 프로그램 내부에 새롭게 생긴 데이터가 저장되는 부분이고, 이 데이터가 계속해서 사용되면

Old 영역으로 가게됩니다. 즉 데이터의 목적과 수명에 따라 저장영역이 다릅니다.

Permanent 영역은 클래스의 정보를 저장하는 영역입니다.

3-1 가비지 컬렉터 (Garbage Collector)

가비지 컬렉터는 힙 영역에서 참조되지 않은 데이터를 삭제하는 역할을 합니다.

그로 인해 개발자들의 불편을 많이 덜어줍니다.

가비지 컬렉터가 데이터를 삭제하는 알고리즘은 힙의 영역에 따라 다른데요.

Young 영역은 새로운 데이터가 생성, 소멸되는 것이니 삭제의 속도가 주기가 빠른 편입니다.

그에 반에 Old 영역은 계속하여 사용하는 데이터다 보니 삭제의 속도 및 주기가 Young영역보다 비교적 느린편입니다.

4.Stack Area 

스택 영역은 호출된 메소드가 저장되는 영역입니다. 클래스의 실행은 메소드 호출을 의미하고,

메소드는 다른 메소드를 호출할 수 있습니다.  실행이 끝나면 저장된 메소드는 삭제됩니다.

데이터의 예로는 메소드가 실행 될 때마다 저장되는 매개변수, 지역변수, 복귀주소 등이 있습니다.

5. PC Register Area

레지스터 영역은 현재 JVM이 수행할 명령어의 주소를 저장하는 메모리 공간이며, 개발자가 크게 건들 일이 없다.

6. Native Method Stack Area (네이티브 메소드 스택 영역)

네이티브 메소드는 OS의 시스템 정보, 리소스를 사용하거나 접근하기 위한 코드로 주로 C, C++로 작성합니다.

자바 프로그램은 OS위에 JVM이 있기 때문에 OS 시스템에 직접 접근하기 어렵지만, JNI(Java Native Interface) API를 사용하면

OS시스템의 접근이 가능하다. 이 때 사용 되는 네이티브 메소드들이 대한 정보가 네이티브 메소드 스택 영역에 저장된다.

[참고 도서,자바를 다루는 도서 저 김병부, 길벗]

MFC로 시리얼 통신을 구현 후 데이터 전송을 하였는데

2Byte들어가서 무엇을 잘못했다 해맸다.

코드를 아무리 살펴봐도 문제가 없었다.

알고보니 설정을 잘못하였다.

유니코드 문자로 설정되어 있다면 멀티바이트 문자로 바꾸자

유니코드는 기본으로 2Byte를 차지하기 때문에 1Byte이후에 Null값이 들어올 수가있다.

MFC로 프로그램을 작성 후 다른 사람에게 보내줬는데

오류와 함께 프로그램이 실행되지 않는 다는 통보를 받았다.

mfc140ud.dll 에러가 발생하였다.

대처법은 다음과 같다.

해당 프로젝트의 속성에 들어간다.

프로젝트 속성에서 일반 - MFC사용에서 정적 라이브러리 MFC사용을 설정

코드생성 - 런타임 라이브러리 - 다중쓰레드(MT)설정 후 적용/확인한다.

마지막으로 빌드 시 Release로 하고 하게되면은 해당 프로젝트 폴더에 Release폴더가 생성되고 그 안에 실행파일을 볼 수있다

오랜만에 안드로이드 앱 점검을 위해 안드로이드를 실행 후 빌드하고 에뮬레이터를 실행했더니 다음과 같은 오류가 떳씁니다...

.gradle 파일도 삭제해보고 Virtual Device도 다시 설치해 보았지만 소용 없었습니다.

그래서 검색을 해보니 Tools - AVD Manager에 들어가서 연필 모양 아이콘을 눌러 해당 에뮬레이터의 속성을 들어갑니다.

Emulated Performance의 설정을 Software로 바꿔 주면 된다는 글을 발견 후 그대로 따라했지만 실패...

위 방법대로 안되시는 분은 다음 방법도 한번 추천해 드리겠습니다.

바로 에뮬레이터를 다시 설치하는데요!

_64가 붙은 ABI를 선택해서 설치해 보는 것입니다.

저는 이렇게해서 해당 오류 없이 잘 실행 됩니다~

프로세스와 스레드라는 것은 많이 들어 보셨을 텐데요.

우선 사전적 의미를 알아 볼게요~

Process [명사] 과정, 방법, 순서, 소송 수속 등...

Thread [명사] 실, 가는 것, 줄거리, 인간의 수명 등...

컴퓨터에서는 CPU가 프로그램을 실행하는 단위를 프로세스 및 스레드라고 합니다.

한번의 여러개의 프로세스나 스레드를 동작시키는 것을 멀티 프로세스, 멀티 스레드라고 해요.

CPU가 1개인 경우, 동시에 실행할 수 있는 프로그램은 1개 뿐인데요.

프로세스 및 스레드는 1개 입니다.

여러 프로그램이 실행된다는 것은 동시에 실행되는 것이 아니에요.

우리 눈에는 보이지 않을 정도로 굉장히 빠른 기계적 속도로 번갈아 교체되며 실행되는 것입니다.

예를들면 애니메이션 제작하는 것과 비슷하다 할 수 있죠

우리눈 에는 움직이는 것처럼 보이지만 한장한장의 그림들이 넘어가며 움직이는 것처럼 보이죠.

그렇다면 프로세스와 스레드는 대충 알겠는데 둘 차이가 뭐길래 이름이 다를까요?

그 이유는 바로 동일한 메모리 공간을 사용하는지 여부 입니다!

같은 메모리 공간을 공유하면 스레드(Thread)

다른 메모리 공간을 사용하면 프로세스(Process)

위의 구조를 함께 보시죠~

실제 메모리 주소 공간과 프로세스1, 프로세스2의 메모리 주소 공간이 다릅니다.

프로그램은 반드시 물리적인 메모리만을 사용하지 않는데요.

멀티 프로세스 시스템에서는 어플리케이션 프로그램이 사용하고 있는 주소와 실제 메모리 상의 주소가 다릅니다.

왜냐하면 각각의 프로세스가 다른 프로세스의 동작 내용에 상관없이 메모리 값을 읽거나 쓸 수 있도록 하기 위함입니다.

구체적으로 설명하자면,

위 그림의 프로세스 1의 0xC000번지와 프로세스 2의 0xC000번지는 실제 메모리 상에서는 다른 번지에 위치하고 있는데요.

프로세스 1이 0xC000번지의 값을 변경해도 프로세스 2의 0xC000번지의 값은 바뀌지 않습니다.

이 처럼 주소와 메모리상의 주소가 다른 것을 가상 기억이라고 해요.

가상 기억을 사용하면 프로그램이 정상적이지 않아도 다른 프로세스의 메모리 값을 바꾸는 일은 없어요.

가상 기억을 사용하는 시스템에서는 하드 디스크와 같은 보조 기억장치를 사용해서 물리적 메모리를 크게 보이게도 합니다.

반면 멀티 스레드 같은 경우에는 위 그림과 다르게 주소 공간을 공유하는데요.

즉, 1개의 스레드가 이상동작을 해서 메모리의 내용을 바꿔 버리면 주소 공간을 공유하고 있는

모든 스레드에 영향을 미칩니다.

이런 이유로 멀티 프로세스가 멀티 스레드보다 견고하다고 할 수 있습니다.

1개의 프로세스가 이상 동작을 해서 메모리의 내용이 바뀌었다고 하더라도 해당 프로세스만 이상 종료할 뿐

다른 프로세스나 오퍼레이팅 시스템에 아무런 영향을 미치지 않기 때문입니다.

그렇다고 해서 멀티 스레드는 안좋다라고 할 순 없는데요.

멀티 스레드는 메모리를 공유하고 있기 때문에 어떤 처리를 할 때에는 각 스레드의 연계가 수월합니다.

이상으로 프로세스와 스레드에 대한 설명을 마치겠습니다~

[참고] 도서, C를 배우기 전에 반드시 알아야 할 것들 (루비페이퍼 저 무라야마 유키오 옮김 이해란)

Misc Controls에 --c99 를 추가해주었다.

해당 프로젝트에 bin파일 생성

target-user-After Build/Rebuild Run#2에 아래 삽입

fromelf --bin -o "$L@L.bin" "#L"