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폴더가 생성되고 그 안에 실행파일을 볼 수있다

강원도 평창 오대산에 명상마을이 생겼다하여 한번 가보았습니다~

버스타고 진부 터미널 도착~

올림픽 때문에 새롭게 단장였네요

KTX도 개통이 되어 서울에서 1시간 정도면 오고, 정말 좋아졌어요

아래는 터미널에서 명상마을까지 가는 시간표!

버스를 타고 행선지를 말해야돼요!

아직 명상마을이 유명해지지 않았는지

행선지는 먹거리촌이라고 해야하네요!

입구를 잘못찾아 뒤로 들어가버렸네요..

가시는 분은 정문으로 들어가세요 ㅎㅎㅎ;;

그쪽에 주차장이랑 다 있네요

그래도 잘못들어선 덕분에 이런 길로도 가보네요!

생각보다 넓습니다!

생긴지 얼마 안되서 그런지 여기저기 공사 중이고,

나무와 꽃도 심고 있지만 풍성해지면

더욱 더 아름답겠어요.

고불고불한 길을 지나 로비에 도착!

여러 장식품들이 이목을 끄네요!

그 중에서 양이 제일 귀엽네요 ㅎㅎㅎ

이것은 옴뷔의 지도!

생각보다 넓죠?

지도 없으면 다니기 힘들어요..

저 탑 주위로 꽃모양의 길이 인상적이였어요.

(탑은 아직 설립이 안되있네요)

숙소는 저렇게 봄여름가을겨울 사계절로 테마가 나눠져 있네요~

여기는 로비 뒤편에 마련된 주차장이네요.

원래 저쪽으로 들어왔어야 했는데..

어느덧 벌써 노을이 지고 있네요

이것은 숙소 

이것은 침실에서 바라본 풍경입니다~

다음날 일어나서 찍었네요 ㅎㅎ

혼자서 명상할 수 있는 공간도 마련되어 있네요

낮에 풍경을 보며 하면 좋을듯!

이곳은 화장실!

시설들이 정말 호텔버금가네요 ㄷㄷ..

이곳은 식당!

현재 나무를 심고 있어서 휑하지만

나중되면 정말 이쁠듯하네요

식사는 정해진 시간대에 뷔페식으로 자유롭게 먹을 수 있네요~

저녁을 먹고 명상하러 ㄱㄱ싱

다리를 건너 명상홀로 향합니다!

하루에 프로그램 시간표가 있는데 그때 맞게 자유롭게 참여할 수 있습니다~

이곳은 명상홀!

한옥으로 정말 이쁘게 지어졌죠?

오랜만에 도심을 잠시 벗어나 명상을 하니 좋네요.

이날은 원장스님이 프로그램을 진행하셨는데

설명도 쉽게해주시고

재밌게 해주시네요!

시간나면 다음에 또 가서 힐링하러 가야겠어요

http://omv.co.kr/

자세한 것은 사이트 확인~

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

.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를 배우기 전에 반드시 알아야 할 것들 (루비페이퍼 저 무라야마 유키오 옮김 이해란)

에스프레소를 모르는 사람은 거의 없을 것입니다.
카페에 가면 기본적으로 있는 에스프레소

아메리카노 만들 때 물에 희석할 때 쓰이고
그냥 엄청 쓴 커피라는 인식이 있습니다.

오늘은 에스프레소에 대해 알아 보려고 해요~

어원은 이태리어로 빠르다라는 의미인 'Express'에서 와서
영어로는 'Espresso'라고 하는데요.

에스프레소다! 하려면 공식이 있다는 것은 알고 계시나요?

에스프레소라 불리기 위해선 과정을 거쳐야 하는데요~

한 잔 기준 7~8g의 원두로 커피머신을 이용하여 9bar 이상의 압력으로
25~30초 동안 25~30ml 의 양이 나와야 에스프레소 라고 부를 수 있답니다.

그보다 더 짧은 시간에 적은 양을 내리면 '리스트레토(Ristreto)'
그보다 더 긴 시간에 많은 양을 내렸다 하면 '롱고(Lungo)'라고 부릅니다.

에스프레소의 시작이라 할 수 있는 커피머신은 19세기 말
이태리에서 처음 나왔는데요.
산업혁명의 톱니바퀴와 역사를 같이 맞물립니다.

산업혁명 이후 일상은 완전히 바뀌어 버렸습니다.
사람들은 바빠지기 시작합니다.
그에 따라 바쁜 일상에 앉아서 수다떨며 커피 마시는 건 사치겠죠?

카페에 들려 신속하게 추출된 커피에 설탕 한스푼 넣어 휙휙 저어
한 잔을 입에 털어 넣고 바로 직장으로 향하게 됩니다~

많은 분들이 무슨 맛으로 에스프레소를 먹냐 하시겠는데
에스프레소를 맛있게 먹는 법을 알려 드릴게요.

에스프레소 한 잔 기준으로 설탕 한 스푼 혹은 봉지설탕 하나 정도를 넣고
스푼을 이용해 밑에서 부터 설탕이 잘 섞이게 천천히 튕기며 젓습니다.
이렇게 먹으면 달달하면서 향이 진한 에스프레소의 풍미를 즐기실 수 있습니다~

그 밖에 크림, 우유, 초콜릿, 술 까지 기호에 따라 다양하게 즐기실 수 있어요.

우리가 흔히들 마시는 아메리카노는 말 그대로 아메리카(America)
미국에서 즐겨 마시는 커피 인데요.

미국이 아메리카노를 마시된 계기는 '보스턴 차 사건'에서 시작 됩니다.
영국에서 차를 수입하던 미국은 갑자기 터무니 없이 높아진 관세로
차 대신 커피로 대체하게 됩니다.

그렇게 커피를 차 대신 마시면서 에스프레소에
물을 희석시켜 차 처럼 마시게 되는데요.

2차 세계대전에 미국이 참전하면서 유럽에서 미국 군인들은
자국에서 먹던 것처럼 커피를 마시게되면서 유럽에도 전파가 됩니다.

우리나라 또한 6.25 전쟁을 겪으면 미군의 주둔의 영향으로 커피가 대중들에게도 알려지고
시대가 지나면서 사람들 삶 속으로 들어오게 되었습니다.

카페에서 에스프레소를 마시면 뭔가 허세부리는 것 같고
무슨 맛인지 모르면서 먹는 느낌이 나겠지만
막상 드셔보시면 그 또한 매력이 있답니다.
한번 도전해보세요!