미니게임지옥

프로젝트 이름

미니 게임 지옥 (Java GUI AWT)

 

프로젝트 개요

프로젝트 설명

Java AWT으로 구현한 게임 프로젝트 입니다.

 

프로젝트 기획

CLI가 아닌 GUI를 통해 이용할 수 있는 간단한 프로그램 구현 및 프로그래밍 연습을 위한 프로젝트

프로젝트 환경

개발 환경

jdk 1.8

 

실행 환경

Mac OS | Window OS | jre 1.8

 

프로그래밍 언어

Java 1.8

 

라이브러리

AWT

 

프로젝트 예시

준비된 예시 종류

imageYoutube Video imageGithub Repository

 

유튜브 영상

미니게임지옥 링크

깃허브

깃허브 링크

프로젝트 특징

Thread

프로젝트를 진행하면서, 다른 두개의 일을 동시에 진행 해야하는 것이 있었다.

게임 플레이를 하면서 동시에 경과시간이 계속 흐르는 것과 또 하나는 배경의 눈이 계속 떨어져야 하는데, 이를 Thread를 통해 쉽게 구현할수 있었음.

 

페인팅 이벤트

Java AWT 환경에서 처음에 가장 오해하기 쉬운 부분 중 하나가 바로 페인팅 프로세스이다. 과거 한참 AWT 파고 있던 본인도 마찬가지의 실수를 범한 것이기도 하다.

Java 의 GUI 근간을 형성하는 Component 위에 원하는 형태를 그리려면 paint(Graphics) 메소드를 오버라이딩하여 원하는 것을 그려야 한다는 점은 익히 잘 알고 있으리라 생각한다. (update 메소드 및 Canvas 등에 대해서는 여기선 별도로 언급하지 않겠다) 그리고 이렇게 구현된 paint(Graphics) 메소드 및 컴포넌트의 기본적인 형태를 그리는 작업이 컴포넌트를 그려야만 하는 여러 가지 상황, 혹은 사용자의 요청에 의해서 수행된다는 것 역시도 기본적인 AWT 에 대한 지식이 있다면 잘 알고 있으리라 생각한다. 중요한 점은 이 페인팅 작업이 이벤트 큐잉을 통하여 처리되는 방식이라는 것이고, 이에 대해 제대로 이해하지 못하고 코딩을 수행할 경우 여러 가지 예상치 못한 결과를 가져오게 된다.

흔히 컴포넌트를 다시 그리는 작업을 수행할 때 사용되는 repaint() 메소드가 이러한 문제를 발생시키는 좋은 예이다. repaint() 를 호출하면 즉시 컴포넌트를 다시 그릴 것이라고 간주하고 이후 처리하게 코딩하는 경우가 많은데 실제로는 그렇게 동작하지 않으므로 난감한 상황에 이르는 경우가 많다.

이의 동작은 실제로는 아래와 같다.

img

즉 repaint() 메소드를 호출하면, 즉시 페인팅 작업을 수행하는 것이 아니라, 페인트 이벤트 발생으로 취급, AWT 이벤트 큐에 페인트 이벤트를 집어넣고 종료시킨다. 그리고 이벤트 큐에 먼저 얹어져 있던 이벤트들이 차곡차곡 처리되고 난 다음 비로소 페인트 이벤트가 수행되고, 이에 따라 해당 컴포넌트의 paint(Graphics) 메소드가 호출되는 것이다.

이런 이벤트 큐 형식으로 처리되기 때문에, repaint() 호출이 AWT 이벤트 처리기와 동일한 스레드, 즉 이벤트 핸들러로부터 동작되는 코드 흐름이었다면 해당 이벤트 핸들러로 시작된 코드 흐름이 완전히 종료되기 전까지는 절대 페인팅 이벤트가 처리되지 않을 것이므로, repaint() 호출 직후에 무슨 짓을 해도 paint(Graphics) 가 바로 호출되게 할 수는 없다. 이에 대해서는 아래의 그림을 참조하자

img

repaint() 의 호출이 이벤트 핸들 코드 흐름이 아닌 다른 스레드라 할 지라도 위의 구조로 인해 repaint() 와 실제로 paint(Graphics) 간의 거리를 확정하기 어렵고, 많은 경우 둘간의 간극은 꽤 느린 편이므로 repaint() 호출 직후에 뭔가 코드를 써 넣는다고 하더라도 paint(Graphics) 호출 뒤에 실행될 가능성은 매우 낮다.

따라서 이런 이벤트 처리 시퀀스와 독립적으로 페인팅 작업을 수행하려 한다면, 다른 메소드를 호출해야 한다. 이를 위해 제공되는 것이 바로 paintImmediately() 이다. 이 메소드는 호출하면 메소드 명칭 그대로 '즉시' 페인팅을 수행한다.

'Portfolio' 카테고리의 다른 글

ITHRer (IT분야에서 취업하는 사람들)  (0) 2019.04.26
ITHRer

프로젝트 이름

ITHRer - (IT + Human Resources + er)

(IT분야 에서 취업하는 사람들)

 

프로젝트 개요

프로젝트 설명

Spring Framework를 이용한 Server 개발 및 mvc 와 디자인 패턴 적용

아마존의 EC2, RDS를 활용한 클라우드 서비스 공부

Kakao Open i builder를 활용한 간단한 챗봇 구현

Websocket를 활용한 채팅 구현 및 폴링, 롱폴링 등에 대한 이해

 

프로젝트 기획

특정 분야로 제한된 정보로 사용자에게 양질의 정보를 제공

프로젝트 환경

개발 환경

jdk 1.8 | STS | AWS | Kakao i open builder | Oracle

 

실행 환경

Mac OS | Window OS | jre 1.8 | Google Chrome

 

프로그래밍 언어

Java 1.8 | HTML5 | JSP | JavaScript

 

프로젝트 예시

준비된 예시 종류

imageGithub Repository

 

깃허브

깃허브 링크

프로젝트 특징

팀프로젝트로 진행하면서 본인이 맡은 부분에 대한 정리를 말씀드리겠습니다.

 

EC2 , RDS

프로젝트를 진행하면서 대부분 서버를 로컬에서 수행했지만, 이번 프로젝트에서는 클라우드 서비스 AWS를 활용

Ubuntu 환경의 EC2를 활용했으며 이에 따라 기본적인 linux에 대한 복습 및 공부

그리고 로컬과 달리 FTP를 사용해야 하는 경우가 있어서 이 때 FileZilla를 활용

또한 디버깅 할 때, STS에서 Logger를 활용하여 Console에서 간단하게 확인을 했다면, EC2에서는 tomcat에서 catalina에서 로그 확인을 통해 디버깅을 해야했는데, 이 때 로그가 축적되어 감당하기 힘든 크기가 되어, 이를 하루 단위로 로그를 나누던가 다른 방법으론 주기적으로 로그를 초기화 해주는 조치가 필요

 

스케줄링

스케줄링의 사용법은 대표적으로 3가지

  1. 쿼츠
  2. xml에서 설정
  3. 어노테이션에서 스케줄러사용

그 중 가장 간단한 사용방법인 3번을 선택했고, 리눅스와 동일한 방법인 cron양식으로 설정하면 됨.

익명게시판의 경우 3일이 지난 게시물들을 자동으로 삭제해야하기 때문에 스케줄러를 사용하여 관리자가 직접 처리하지 않아도 되기 때문에 편리

image

 

챗봇

이번에 'Kakao i 오픈빌더'를 이용할 수 있는 기회가 있어 카카오 플러스친구를 활용하여

완벽하진 않지만, 챗봇을 만들어 보았다.

준비물 - STS + Kakao i openbuilder + kakao 플러스친구 관리자 계정 + EC2

자세한 내용은 링크를 통해 정리한 내용을 확인

카카오 아이 오픈빌더 + Java Spring 정리한 것!

image

 

JSP WebSocket (채팅 구현)

WebSocket을 이용해 유저간의 채팅을 구현한 부분인 것이였던 것입니다.

흐름

  1. 서버는 Socket 생성 후 Server Socket으로 등록 합니다. 이를 바인딩 이라고 합니다.

    그 다음 클라이언트의 접속 요청을 받기 위한 설정을 하는데 이를 listen 이라 칭합니다.

  2. 그 후 서버는 Server Socket은 클라이언트의 접속 요청을 하염없이 기다리는 것이였답니다. 이를 accept 상태라고 합니다

  3. 클라이언트 쪽에서 채팅을 마구마구 즐기기 위해 Socket을 만들고, WebServetEnd 포인트로 접근 을 요청합니다. 이 때 책 읽는 사람들은 TCP로 연결이 되는데 , TCP연결을 하기 위해선 3 way handshake를 해야합니다. 알맞게 연결이 되면 , 서버는 와 클라이언트는 서로 read/write 할 수 있고, 서로 물고 뜯고 마구마구 엉망진창이 될 수 있던 것입니다.

    이 때 서버는 또한 새로운 클라이언트의 접근을 확인할 수 있는 accept 상태인 것을 알고 계시면 됩니다.

    (여기서 ajax를 통해서도 채팅을 구현할 수 있는데, 웹소켓과 ajax로 채팅을 구현할 때 생기는 차이점을 설명드리자면, ajax로 채팅을 구현할 경우, 클라이언트가 서버쪽에 요청을 보내고 , 막 명령을 시킬 수 있는 것에서 끝나지만, WebSocket으로 구현 할 경우, 클라이언트가 서버쪽에 요청을 할 수 있는건 물론이고 , 서버쪽에서도 클라이언트를 부를 수 있다는것이 차이점입니다.

 

위에 내용에서 면접에 정말 많이 나오는 내용

  1. TCP / UDP 통신 차이

  2. 3 way handshake & 4 way handshake

  3. http / https 차이

image

이 쪽 소스는 웹소켓 통신할 때 쓰는 기본적인 소스인데 , onOpen 과 onClose 즉 클라이언트의 접속과 연결해제 할 때 onMessage를 호출 하는데 이 때 chat_user_CNT를 같이 보내 , 현재 이용자의 수를 모든 클라이언트들에게 쫙 보냅니다.

header.jsp를 보시면 서버쪽에 접근하기 위해 클라이언트 쪽에서 소켓을 만드는걸 보실 수 있습니다. 바로 요놈

url에 대한 부분은 스크린샷을 참고하삼

image

 

onOpen 부분은 클라이언트가 연결에 성공했을 때 실행

onMessage 부분은 서버에서 클라이언트에게 메시지를 보낼 때

send 부분은 클라이언트에서 서버로 메시지를 보내는 메소드 였던 것이였던 것입니다

BroadSocket.java

 

header.jsp

 

그외 내용 (링크)

JSP 중복 로그인 (세션바인딩리스너) 정리

'Portfolio' 카테고리의 다른 글

미니게임지옥 (Java awt)  (0) 2019.04.26

+ Recent posts