아 그 전에 질문 하나!

소프트웨어란 무엇인가?!

-> 컴퓨터 시스템을 효율적으로 운영하기 위해 개발된 프로그램

음... 듣고나니 여러가지 의문이 드네요 과연 시스템을 효율적으로 운영하기 위해 개발된 프로그램만이 소프트웨어일까요? 우리와 밀접한 관계를 가지고 있는 인스타그램, 유튜브, 페이스북은 소프트웨어가 아닌걸까요?

아닙니다. 그것들 또한 소프트웨어입니다. 우리의 삶을 아주 효율적으로 갉아먹으니까요!

엄마는 아들 믿어.jpg

그래도 헷갈리신다구요? 음... 조상님들이 하신 말씀중에 그런 말이 있죠

얼리어답터 을모씨

하드웨어가 아니면 소프트웨어다 - 을지문덕

아 응용프로그램도, 운영체제도, 모든게 다 소프트웨어구나. 깨우쳤습니다

잡소리가 길어졌네요 ㅎㅎ.. 제가 블로그 포스팅 경험이 없는지라.. 제 글은 제가 읽어봐도 지루하고 읽기 싫게 쓰더라구요 그래서 최대한 사진도 많이 넣고, 쓸데없는 드립도 조금씩 넣는데.. 불편하시다면 죄송합니다 ㅠㅠ 그럼에도 미숙한 제 포스팅 읽어주셔서 감사합니다. 균형있는 포스팅하도록 항상 노력하겠습니다!!

그럼 오늘의 주제에 대해 알아볼까요?

소프트웨어 방법론

1. 소프트웨어 방법론의 종류

소프트웨어 방법론에는 오늘 소개할 애자일 방법론을 제외하고도 많은 종류가 있습니다. 애자일 방법론에 대해 알아보기 전에 어떤 방법론들이 있는지, 그리고 그에 대한 간단한 설명입니다.

1) 구조적 방법론 구조, 흐름, 간결, 간단 이 네가지가 구조적 개발방법론의 특징

2) 정보공학 개발방법론 기업 전체 또는 주요부분을 계획, 분석, 설계 및 구축에 정형화된 기법들을 상호 연관성 있게 통합, 적용하는 데이터 중심 방법론

3) 객체지향 개발방법론 현실 세계의 개체를 속성과 메소드가 결합된 형태의 객체로 표현하며, 현실 세계에 존재하는 실체 및 개념들을 객체라는 독립된 단위로 구성하고 이 객체들이 메시지 교환을 통해 상호작용함으로써 전체 시스템이 운영되는 방법론

4) 컴포넌트 기반 개발방법론 개발된 소프트웨어 컴포넌트를 조립, 시스템을 개발하여 객체지향의 단점인 소프트웨어 재사용성을 극대화한 개발 방법론

본격적으로 오늘의 주제! 애자일 방법론에 대해 알아보겠습니다!

애자일 방법론

애자일 방법론이 뭔가요?

애자일 방법론은 영어로 Agile Methopology입니다.

Agile(민첩한) + Methopology(방법론)

말 그대로 민첩한 방법론입니다! 고객과의 소통에, 문서작성보다는 소프트웨어에, 철저한 계획보단 변화에 대한 민첩한 대응을 핵심가치로 두는 방법론이죠.

그럼 기존 방법론은 안그랬나요?

놀랍게도 그렇습니다. 무언가 실용적인것보다 겉보기에 좋아보이는게 중요하고, 무언가를 실제로 하는 것보다 그것을 문서로 작성하여 기록하는게 중요한, 변화보다 계획이 더 중요한.. 그런 방법론들이 대부분이였죠.

변화, 대응, 협업, 가치창출이 중요한 소프트웨어 개발에서는 그런 방법론을 지양합니다. 현재 모든 IT 기업들이 애자일 방법론을 기반으로 운영하는 이유도 그것에 있습니다. 방법론이라기보다는 개발 철학? 에 가깝다고 볼 수 있겠네요.

어찌보면 전쟁과 비슷하다고 할 수 있습니다.

분명 적군이 쳐들어올 것을 대비해 어느정도의 계획을 세워놨겠죠. 하지만 갑자기 비가 많이와서 강이 많이 불어난 것과 같은 환경적 요소, 갑작스레 나타난 지원군, 예상치 못한 공성병기 등 수많은 변수가 존재합니다.

따라서 그 순간마다 적절하게 대응하고 협력하는 것이 승패에 더 큰 영향을 미칩니다. 이렇듯 굉장히 변화에 민감한 이벤트이기 때문에 절차적인 요소들보다 '전쟁' 자체에 중점을 두는거죠.

애자일 또한 그렇습니다. 오랜 시간에 걸쳐 짜놓은 구체적이고 완벽한 계획보다 상황에 대한 발빠른 대처와 협력를 통해 변화에 민감한 소프트웨어 개발에 중점을 두는 것입니다.

애자일 방법론의 특징

• 문서화보다 소프트웨어의 개발 자체에 중점을 둠

• 고객과의 원활한 소통
• 요구사항 변경보다 대응을 목적으로 함
• 주기적인 회의를 수행함
• 빠른 출시 후 유지보수
• 변화에 발빠르게 대응함

아 이런 특징이 있군요. 근데 애자일 방법론이라는게 그 자체로 방법인가요?

방법이라기 보다는 지침서나 철학에 가깝습니다. 애자일 안에 여러 기법들이 포함되어 있고, 사상이라고 부르는 분들도 계십니다.

그럼 어떤 종류가 있나요?

애자일 방법론의 종류

1) 스크럼

스크럼.. 애자일하면 스크럼이라고 할 정도로 굉장히 응용 범위가 넓은 개발 기법입니다. 비단 소프트웨어 개발만이 아닌 다른 일반적인 프로그램, 프로젝트 관리에도 사용이 가능합니다.

진행 과정

1) 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정함 2) 프로젝트 책임자가 정한 제품의 우선순위에서 어디까지 작업할지 팀과 조율함 3) 조율 후 선정된 제품 백로그를 금번 스프린트의 목표로 설정함 4) 스프린트 목표를 구현 가능하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당함 5) 스프린트를 진행하는 동안 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 진행함 6) 매 스프린트가 종료될 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품에 대해 학습하고 이해함 7) 제품의 학습과 이해가 끝나면 스프린트 회고를 통해 팀 개발 프로세스에 대한 개선의 시간을 가짐 8) 스프린트 기간 중 다음 스프린트를 준비하기 위해 PO와 필요 인원이 모여 백로그를 준비함

2) 익스트림 프로그래밍

아 이 부분에 대해서 공부할수록 정처기 필기시험이 생각나서 어지러워요. 누구보다 빠르게 설명하고 도망가겠습니다.

익스트림 프로그래밍이란, 고객에게 <최고의 가치를 가장 빨리> 라는 목표를 가지는 방법입니다. 기능성, 퀄리티, 물론 다 중요하지만 이들은 속도에 미쳐있습니다. 속도 최대로!

• 빠른 개발

• 시장 대응 능력 향상
• 유연한 대처
• 생산성 향상

위와 같은 장점이 있는데, 이러한 장점들을 위한 여러가지 요소들 또한 존재합니다. 좋게 말하면 생산성이지만 팀원들에게는 힘들 수 있는..

• 계획을 빠르게 세운 뒤, 개발 중에 계획을 추가함

• 페어 프로그래밍을 통해 모든 코드가 리뷰됨
• 단거리 달리기처럼 짧게 개발하고 릴리즈하여 피드백을 수집함
• 인테그레이션을 자주한다. 물어보기전에 인테그레이션하고 물어보는 정도
• 지속적인 리팩토링을 통해 구조를 개선함

아직 경험해본 적은 없지만.. 단거리 달리기 선수들 같습니다. XP의 과정은 아래와 같습니다. 대규모 프로젝트에는 적용하기 힘든 방법이 분명하네요.

1) 유저 스토리 - 사용자의 요구사항을 적어놓은 것 2) 스파이크 - 기술적/설계적 위험을 미리 탐지하기 위해 프로젝트 시작전에 핵심 기능을 간단하게 구현해보는 것 3) 릴리즈 계획 - 릴리즈 시점에 대한 일정을 세우고 각 주기마다 개발할 스토리를 유저가 선택함 4) 주기 개발 - 유저 스토리와 스파이크를 활용하여 개발함(중도 추가, 업데이트 가능) 5) 인수 테스트 - 주기가 시작됨과 동시에 고객이 테스트 시나리오를 만듬. 사용자는 테스트 시나리오를 바탕으로 인수 테스트 코드를 작성하고 주어진 스토리가 인수 테스트를 통과하면 작은 릴리즈를 실시함

익스트림 프로그래밍은 릴리즈-주기-인수테스트를 거의 동시에 진행하며 반복됩니다. 만약 주기 개발중에 스토리가 업데이트되면 다시 릴리즈 계획 단계로 돌아가는 식으로!

3) 짝 프로그래밍

짝!

아 이 짝이 아닌가.. 당연히 아니지 사실 여기서 짝은! 신발도 짝이 있고 양말도 짝이 있고 내 에어팟은 짝이 없고...😥 할 때 그 짝입니다

두 사람이 짝이 되어서 한 사람은 코딩을 하고, 한 사람은 코드 리뷰를 담당하는거죠!

올바른 짝 프로그래밍

두 명이 한 쌍이 되어(?) 사이좋게 코드 리뷰를 하는 모습이 훈훈하네요. 인터넷에는 30분마다 역할을 교체한다고 나와있는데, 보통 삘 받으면 한두시간 정도는 훅 지나가더라구요 경험상..

둘이서 같이 하는데 분명 장점이 있겠죠? 이렇게 한 사람은 코딩을, 한 사람은 코드 리뷰를 하면

1) 코드에 대한 책임을 공유함(우리 이제 공범이야) 2) 비형식적 검토 수행 3) 코드 개선을 위한 리팩토링 장려 4) 생산성 증가(한 컴퓨터에서 같이 개발하지만 따로 개발하는 것에 비해 생산성이 저하되지 않음)

이러한 장점이 있습니다.

4) 테스트 주도 개발

테스트 주도 개발이란, 테스트 케이스를먼저 작성하고 이걸 통과하는 코드를 개발하는 것을 말합니다. 어? 보통 개발을 완료한 후에 테스트를 진행하지 않나요?

A: 그렇습니다. 하지만 테스크 주도 개발은 그 역순으로 진행한다는거!

그럼 어떤 순서로 진행되나요?

1) Task 별로 테스트 케이스 생성 2) 요구사항 - 스토리카드 - Task 3) 요구사항은 스토리 카드로 표현되고 스토리 카드는 Task들로 분해됨 4) 코드간의 관계가 명확해짐

이러한 순서로 진행됩니다! 어.. 생각보다 간단하네요 그럼 이 방법은 아무때나 써도 적용이 쉬운가요? 좋은가요? 어떤 효과가 있죠?

컴퓨터공학부 출신입니다. 수업 시간에 만든 학생 관리 프로그램 수가 제 이빨보다 많아요 그런데 제가 학생 관리 프로그램을 또 제작한다면.. 여기에 테스트 주도 개발을 적용하는게 효율적일까요?

아니죠. 눈감고도 할 수 있을 정도로 잘 아는 로직과 어떤 결과가 나올지 다 아는 상황에서 테스트 주도 개발 방법을 사용하는 것은 비효율적인 일입니다. 득보다 실이 많은 상황이 되는거죠.

즉, 불확실성이 높은 상황이라면 테스트 주도 개발을 적용하면 됩니다.

애자일 방법론의 장/단점

애자일 방법론의 공통적인 장/단점입니다.

1) 장점

• 프로젝트 계획에 들어가는 시간을 단축시킬 수 있음
• 계획/기능 등에 대한 유지보수가 유용함
• 요구사항에 빠르게 대응할 수 있음
• 우선적으로 출시한 후 개선해나갈 수 있음

2) 단점

• 계획에 들어가는 시간이 적은만큼 부실하여 그만큼 유지보수에 들어가는 시간이 증가함
• 반영할 수 없는 요구사항일 경우에 실현이 불가능하고
• 빠른 작업과 수정이 가능하지만 그만큼 굉장히 자주 반복적으로 해야함
• 숙련도가 낮은 팀원이라면 적응하기 힘들 수 있음

여러 장점이 많은만큼, 그에 따른 단점도 확실하게 따르는 것 같습니다. 하지만 현재 IT 시장의 변화는 빠르고, 예측이 어려우며 까다롭습니다. 그렇기에 애자일이라는 사상?철학?방법론?이 여러 기업들에게 매력적으로 느껴졌다고 생각하구요.

이번 포스팅을 진행하면서 한 편으로 느낀건, 애자일이 기업에는 결과적으로 이익을 가져다주지만 개발자들에게는 원수가 될 수도 있지 않을까..라는 그런?

미래에 취업하게 된다면 실무를 뛰며 느끼겠죠? 내심 얼른 그 날이 왔으면 좋겠다는 생각을 합니다. 그 때 되면 애자일은 아군인가 적군인가에 대한 포스팅을 할지도 모르겠네요.

오늘은 이렇게 애자일 방법론에 대해 알아봤는데요, 어떻게 이해가 잘 되셨는지 모르겠습니다..

요즘 포스팅하면서 느낀 점이라면 내 생각을 남에게 간단명료하게 전달하는 방법은 존재하지 않는다는 거 이거 단 하나입니다. 동영상을 아무리 잘 만들어도 인코딩하지 않으면 깨져버리는.. 그런 느낌이에요

오늘도 봐주셔서 감사하고, 앞으로 포스팅은 몇 일 간격으로 올라갈 것 같습니다. 프로젝트 진행예정인게 하나 있고, 토이 프로젝트도 만지고 여러가지 많이 하는중이라 시간 부족하네요. 그럼 다음에 만나yo 핐쓰~🤘

주춧돌이 정확하게 어떤 원리인지는 잘 모릅니다 사실..

그건 제가 건축가가 된다면 포스팅하도록 하겠습니다

안드로이드 컴포넌트

4대 컴포넌트

• 액티비티 (Activity)
• 서비스 (Service)
• 브로드캐스트리시버 (Broadcast Receiver)
• 콘텐츠프로바이더 (Content Provider)

안드로이드 4대 컴포넌트는 위와 같은 구성으로 이루어져있습니다 그리고 컴포넌트들 간의 제약조건은 다음과 같습니다.

• 각 컴포넌트들은 독립적인 형태로 존재한다.

• 각 컴포넌트들은 고유한 기능을 수행한다.
• 각 컴포넌트들은 인텐트를 통해 상호작용한다.

신호등에 비유하자면,

• 각 등은 독립적으로 점등된다.

• 각 등은 고유한 색깔을 가지고 있다.
• 각 등은 회로를 통해 상호작용한다.

라고 설명이 가능하겠네요. 다음으로 설명할 것들을 위해

위의 키워드 3개만 기억하시면 컴포넌트를 이해하는데 도움이 될지도..?!

자자 진정하시고 이제 본격적으로 안드로이드의 4대 컴포넌트에 대한 이야기를 시작하겠습니다.

1) 액티비티

아무말도 없이 내 돈을 가져가는 넷플릭스 정기결제와 같이 아무것도 하지 않아도 말도 없이 나타나는 녀석! 안드로이드 개발을 해본 남녀노소를 불문하고 모두가 제일 많이 들어본, 제일 친근한! 프로젝트를 생성하기만 해도 기본적으로 생성되는 바로 그것!

첫 번째 구성요소, 액티비티입니다. 액티비티는 UI 화면을 구성하는 '기본 단위'라고 할 수 있습니다. 하나 이상의 액티비티를 가져야하며, 그 위에 여러 View를 올릴 수 있죠.

액티비티의 대표적인 특징 몇가지를 설명하자면 아래와 같습니다.

• Activity 클래스를 상속받아 사용한다.

• 최소 하나 이상의 Activity를 가진다.
• 동시에 두 개 이상의 Activity를 DP할 수 없다.
• 다른 어플리케이션의 Activity도 Intent를 통해 불러낼 수 있다.
• Activity는 하나 이상의 View를 가질 수 있다.

2) 서비스

액티비티가 UI 화면에서 사용자와 직접적으로 상호작용하는 요소라면, 서비스는 그와 반대로 직접적으로 상호작용하지 않는 요소입니다.

일반적으로는 백그라운드에서 어떠한 작업을 처리하기 위해 사용합니다. 대표적인 예시로 음악을 들으며 카카오톡을 하는 것이 있습니다. 카카오톡을 하는 중이며 음악 프로그램은 백그라운드에서 수행되고 있는 것입니다.

서비스의 대표적인 특징은 다음과 같습니다.

• 모든 서비스는 Service 클래스를 상속받아 사용한다.

• DP되지 않으며 어플리케이션이 종료되어도 백그라운드에서 동작하는 컴포넌트이다.
• 네트워크를 통해 데이터를 받아올 수 있다.
• Activity와 같은 UI 스레드에서 실행된다.

3) 브로드캐스트 리시버

브로드캐스트 리시버는 안드로이드 OS로부터 발생하는 이벤트 정보를 받고 대응하는 컴포넌트입니다. 네트워크 오류, 앱 초기화, 재부팅 등 특수 이벤트 처리나 배터리 부족, 문자 수신, 전화 수신과 같은 정보를 받아 처리해야할 때 동작합니다.

어플리케이션이 백화점이라면 브로드캐스트 리시버는 안내방송에 비유할 수 있습니다. 브로드캐스트 리시버의 특징은 아래와 같습니다.

• 디바이스에서 발생하는 중요한 이벤트를 어플리케이션에게 알려준다.

• 리시버를 통해 디바이스 상황을 감지하고 대처한다.
• 대부분 UI를 가지지 않는다.
• 특수한 상황에 대응하기 위해 사용한다.
• 특정 상황을 제외하면 시스템에서 시작한다.

4) 콘텐츠 프로바이더

콘텐츠 프로바이더는 데이터를 관리하고 다른 어플리케이션의 데이터를 제공하는데에 사용되는 컴포넌트입니다. 특정 어플리케이션이 사용중인 DB를 공유하기 위해 사용하며 그것을 위해 표준화된 인터페이스를 제공합니다.

전화번호부 어플리케이션을 예시로 들자면,

전화번호부에 저장되어 있는 DB를 많은 어플리케이션들이 사용한다.(ex: 카카5톡, 페2스북) 각각 제조사도 다르고 독립적인 어플리케이션인데 엏떢계 DB를 공유하는걸까? -> 이 때 전화번호부 어플리케이션에서는 자신의 DB를 공유하기 위해 '콘텐츠 프로바이더'를 제공한다. 그렇게 되면 다른 어플리케이션에서는 컨텐츠 리솔버로 프로바이더가 제공하는 DB에 접근하여 데이터를 읽어올 수 있게 된다.

아래는 콘텐츠 프로바이더의 대표적인 특징입니다.

• File I/O, SQLiteDB, Web 등을 통해 데이터를 관리한다.

• 콘텐츠 프로바이더는 용량이 큰 데이터를 공유하는데 적합하다.

지금까지가 안드로이드의 4대 컴포넌트에 대한 설명이었습니다. 4대 컴포넌트는 독립적이며, 고유하고, 인텐트를 통해 상호작용한다고 말씀드렸었습니다. 지금부터 마지막으로 설명드릴 것은 그 중 컴포넌트 간의 상호작용을 위한 '인텐트'에 대한 것입니다.

5) 인텐트

인텐트란, 컴포넌트 간의 상호작용을 위한 통신수단의 역할을 합니다. 인텐트를 가장 많이 사용하는 대표적인 경우는 액티비티 간의 화면 전환이 있습니다. 또한 인텐트의 종류에는 명시적/암시적 두 가지가 있는데,

명시적 인텐트

• 호출할 컴포넌트가 무엇인지 직접적으로 인텐트 객체에 정의하여 해당 컴포넌트를 호출
• 어플리케이션 내부 컴포넌트를 호출할 때 사용

암시적 인텐트

• 처리할 작업, 데이터, 액션 등의 정보를 인텐트 객체에 정의하고 이것을 처리할 수 있는 컴포넌트를 찾도록 요청

위와 같으며 인텐트의 대표적인 특징은 아래와 같습니다.

• 서로 독립적이며 고유한 4대 컴포넌트간의 상호작용을 위한 장치이다.

• 컴포넌트에 액션, 데이터 등을 전달한다.
• 인텐트를 통해 다른 어플리케이션의 컴포넌트를 활성화시킬 수 있다.

제가 처음 안드로이드를 접했을 때가 생각나네요.

액티비티는 신이고 나는 무적이다

이런 느낌으로 액티비티 원툴라이프를 살았는데.. 이래서 머리가 나쁘면 고생하나봅니다 ㅎㅎ.. 다른 분들은 구글에서 정성껏 마련해둔 컴포넌트 잊지말고 잘 활용하셔서 건강하고 효율적인 코딩하셨으면 좋겠습니다.

오늘은 이렇게 안드로이드의 4대 컴포넌트에 대해 알아봤는데요! 어떻게.. 도움이 되셨는지 모르겠네요 안됐다면 유감입니ㄷ

그럼 이만 가볼게요 오늘도 글 읽어주셔서 감사합니다 (__)

MVP/MVVM/Clean Architecture 등 아키텍쳐 설계 혹은 적용 경험이 있으신 분

자격요건에 위 문구가 적혀있는 것을 본 적이 있을 것이다. 이게 대체 뭐길래 중요하다는 걸까?

하지만 절대 의문을 가져서는 안된다. 실무에서 중요하다고 하는건 다 이유가 있는법이고, 몰라서 좋을게 없다는 뜻도 된다.(사실 실무경험이 없어서 더욱 그렇게 생각한다..OTL)

그리하여 오늘 알아볼 것은 디자인 패턴이 무엇이며, 모바일 어플리케이션 개발에 자주 사용되는 디자인 패턴은 무엇인가?에 대한 내용이다.

디자인 패턴

1) 소프트웨어 공학

디자인 패턴을 공부하기 전에, 우선 소프트웨어 공학이라는 것을 알아야한다. 컴퓨터공학부 학생이라면 소프트웨어 공학과 관련된 수업을 들어본 적이 있을 것이다.

혹시 있을지 모를 비전공자들을 위해 설명하자면 소프트웨어 공학이란, 소프트웨어의 개발/운용/유지보수 등의 생명주기를 체계적이고 서술적이고 정ㄹ.... 그렇다고 한다.

그냥 간단하게 말하자면 공학을 소프트웨어에 적용함으로써 '건강한 소프트웨어'를 만들기 위한 학문이다.

2) 디자인 패턴

디자인 패턴 또한 소프트웨어 공학에서 특정 문맥에 공통적으로 발생하는 문제에 대해 재사용이 가능하게 만들어놓은 해결책이다.

개발자들이 어플리케이션/시스템을 디자인할 때 발생하는 공통된 문제들을 해결하기 위해 쓰인다. 단적으로는 '코드를 효율적으로 작성하기 위한 방법론', 궁극적으로는 건강한 소프트웨어 개발을 위한 방법론이라고 할 수 있다.

음... 설명만 들어서는 디자인 패턴이 어떻게 '체계적이고 건강한' 소프트웨어를 만드는데 도움이 되는지 도통 알 수가 없다. 이 설명을 듣던 내 건강이 나빠지는 기분이 막 들고 그런다.

3) 안드로이드 디자인 패턴

안드로이드 앱을 논리적 구성 요소들로 체계화하려는 노력은 지속되어 왔다. 가장 기초적인 MVC(Model View Controller) 패턴으로 시작하여 더 모듈화되고 테스트 가능한 패턴으로 발전해 왔다.

대표적으로 MVP(Model View Presenter), MVVM(Model View ViewModel)이 MVC를 대체하기 위해 가장 많이 쓰이는 방법론이다. 물론 둘 중에 어느게 더 낫다는 정답은 없다.

건너건너 들은 얘기지만 열정적인 개발자들을 모아 디자인패턴에 대한 토론을 시작하면, 방금 먹은 점심이 다 소화되고 어느덧 저녁시간이 되는 경우도 심심치 않다고 한다. 그만큼 각 디자인패턴의 특장점이 확실하고, 상황에 따른 방법론의 선택이 중요하다는 뜻이기도 하다.

1) MVC

• View (1) 사용자에게 보여지는 UI를 나타낸다. (2) Model로부터 data를 받아 사용자에게 보여준다.

• Model (1) 어플리케이션에서 사용되는 data와 그 data를 처리한다. (2) View에 의존적이지 않기 때문에 재사용이 가능하다.

• Controller (1) 사용자의 입력(Action)을 받고 처리한다. (2) 주로 Activity나 Fragment로 표현된다. (3) Model의 data 변화에 따라 View를 선택한다.

• 동작 (1) 사용자의 Action이 Controller에 들어온다. (2) Controller는 사용자의 Action을 확인하고, Model을 업데이트한다. (3) Controller는 Model을 나타내줄 View를 선택한다. (4) View는 Model을 이용하여 화면을 나타낸다.

• 특징 (1) Controller는 여러 개의 View를 선택할 수 있는 1:N 구조이다. (2) Controller는 View를 선택할 뿐 직접 업데이트하지 않는다.(View는 Controller를 모른다) (3) View와 Model을 완벽하게 분리하고, Model 테스트가 용이하다.

• 단점 (1) Controller가 Android API에 종속되어 테스트가 어렵다 (2) View를 변경하면 Controller도 변경해야 한다. (3) 많은 코드들이 Controller에 집중되면 성능이 저하되고 유지보수가 어려워진다.

2) MVP

• View (1) 기본적인 것들은 MVC와 동일하나, Activity/Fragment가 View에 포함된다. (2) View를 관리하는 Interface를 추가하여 Presenter를 독립적으로 만들어준다.

• Model (1) 어플리케이션에서 사용되는 data와 상태에 대한 business logic을 처리한다. (2) View에 의존적이지 않기 때문에 재사용이 가능하다.

• Presenter (1) View와 Model 사이에서 data를 가공하고 전달하는 역할을 수행한다. (2) View가 요청한 정보를 Model로부터 받고 가공하여 View에게 전달한다. (3) Controller와의 차이점은 Interface라는 점이다.

• 동작 (1) 사용자의 Action이 View를 통해 들어온다. (2) View는 data를 Presenter에게 요청한다. (3) Presenter는 Model에게 data를 요청한다. (4) Model은 Presenter에게 요청받은 data를 반환한다. (5) Presenter는 View에게 data를 반환한다.

• 특징 (1) Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 역할을 한다. (2) Presenter와 View는 1:1 관계이다. (3) 단순 Interface이기 때문에 테스트가 용이하고 모듈화/유연성 문제가 해결되었다.

• 단점 (1) View와 Presenter 간의 의존성이 높다. (2) Android API를 참조해서는 안된다.(권장) (3) Controller와 같이 코드가 집중되면 성능이 저하되고 유지보수가 어려워진다.

3) MVVM

• View (1) 기본적인 것들은 MVC와 동일하나, Activity/Fragment가 View에 포함된다. (2) ViewModel을 관찰하여 UI를 갱신한다. (3) Data Binding을 위해 gradle과 xml을 수정해야한다 (4) 이를 통해 View는 ViewModel에 의해 Model과 유연한 binding이 가능하게 된다.

• Model (1) MVC, MVP와 동일하다. (2) 기존 모델에 business logic을 추가하기 위해 MVVM에 SquareParams라는 Model을 추가했다. (3) DB 사용이나 Retrofit을 통한 백엔드 API 호출 등을 주로 수행한다.

• ViewModel (1) 기본적으로 View에 종속되지 않는다.(그래서는 안된다) (1) Model을 래핑하고 View에 필요한 Observable data를 준비한다. (2) View가 Model에 Event를 전달할 수 있도록 Hook(BindingAdapter)을 준비한다.

• 동작 (1) 사용자의 Action들은 View를 통해 들어오게 된다. (2) Command pattern으로 ViewModel에 Action을 전달한다. (3) ViewModel은 Model에게 data를 요청한다. (4) ViewModel은 응답받은 data를 가공하여 저장한다. (5) View는 ViewModel과 Data Binding하여 화면을 나타낸다.

• 특징 (1) Command Pattern과 Data Binding을 사용하여 구현한다. (2) View와 Model 사이의 의존성이 없다. (3) View와 ViewModel 사이의 의존성도 없다. (4) 위처럼 모든 부분이 독립적이므로 모듈화가 가능하다.

• 단점 (1) ViewModel의 설계가 어렵다.(당연한..) (2) View가 변수와 표현식 모두에 Binding될 수 있으므로 갈수록 presentation logic이 늘어나 XML이 방대해진다. 이것을 방지하려면 항상 ViewModel에서 직접 값을 가져오는 것이 좋다.

상당히 글자가 많고 읽기 싫게 생긴 설명이네요. 하지만 어쩔 수 없습니다. 디자인패턴을 공부해보니 이렇게 구구절절 설명되어 있는 포스팅도 보고, 코드를 실행해봄으로써 풀이해주는 포스팅도 같이 보는 것이 제일 도움이 되었습니다. 개발자라고 이론에 약해도 되는것은 아니니까요.

저는 요즘 핫하다는 MVVM을 적용하며 공부하고 있습니다. MVVM을 적용한 기업들이 대다수이기도 할 뿐더러, Data Binding의 편리함이 너무 크게 다가오더라구요.

공부하면 할수록 지금껏 얼마나 무지한 개발을 해왔는지 깨닫습니다. 원래는 하루빨리 첫 직장에 취업해서 일하고 싶었는데, 이 실력이라면 민폐만 끼칠게 분명하니 차근차근 내공을 쌓는것이 우선인 것 같습니다. 1일 1포스팅을 목표로 매일 열심히 공부하고 개발하다 보면 언젠가는 그런 날이 오겠죠?! ㅠㅜ

앞으로는더 정확한 정보전달과 학습을 위해 노력하겠습니다. 부족한 포스팅 읽어주셔서 감사합니다. (_ _)

열받지만 각설하고, 이번 포스팅에서는 안드로이드 4대 컴포넌트 중 하나인 Activity의 lifecycle에 대해 설명한다. 아주 기초적이지만 핵심적인 부분이라 백번 읽고 자다가 잠꼬대로 줄줄 뱉을 정도로 체득해야한다.

생명주기(Lifecycle)

1) 생명주기란 무엇인가?

Lifecycle은 Life + cycle의 합성어로, 삶의 순환이라고 직역할 수 있겠다. 말 그대로 탄생하고 성장하여 죽음에 이르기까지의 과정이라고 생각한다면, 이것을 안드로이드 앱에 적용한 것이 바로 Android Lifecycle이다. Activity, Fragment, Service 총 세가지 종류의 Lifecycle이 있으며 오늘은 그 중 Activity의 Lifecycle에 대해서만 포스팅하도록 하겠다.

2) 생명주기가 필요한 이유

예를 들어보자. 당신은 지금 여자친구와 카톡을 하고 있다. 그런데 갑자기 친구가 술먹자며 나오라고 전화를 했다. 당신이 전화를 받는순간 전화창이 화면에 보일 것이다. 그러다 약속을 잡고 전화를 끊고 다시 카톡을 실행하면 화면에 카톡창이 보일 것이다.

위 예시를 보자. 카톡 실행중 -> 카톡 닫고 전화 실행 -> 전화 실행중 -> 전화 끊고 카톡 실행 -> 카톡 실행중 위와 같은 로직이 나오게 된다. 사용자들은 그저 실행과 종료를 통해 해당 로직을 파악할 수 있지만, 우리의 안드로이드는 그러지 못한다. 그렇기에 Lifecycle이라는 개념을 넣어 안드로이드 프로그램의 상태 변화를 파악하고 반응할 수 있게 한 것이다.

액티비티 생명주기(Activity Lifecycle)

위 사진은 안드로이드 4대 컴포넌트 중 하나인 Activity의 Lifecycle 순서도이다.

1) onCreate()

• Activity가 생성되면 가장 먼저 호출됨
• 화면 Layout 정의, View 생성, Databinding 등은 이곳에 구현함
• 생명주기 통틀어서 단 한 번만 수행되는 메소드
• 따라서 Activity 최초 실행에 해야하는 작업을 수행하기에 적합함

  2) onStart()

• Activity가 화면에 표시되기 직전에 호출됨
• 화면에 진입할 때마다 실행되어야 하는 작업을 이곳에 구현함

  3) onResume()

• Activity가 화면에 보여지는 직후에 호출됨
• 현재 Activity가 사용자에게 포커스인 되어있는 상태

  4) onPause()

• Activity가 화면에 보여지지 않은 직후에 호출됨
• 현재 Activity가 사용자에게 포커스아웃 되어있는 상태
• 다른 Activity가 호출되기 전에 실행되기 때문에 무거운 작업을 수행하지 않도록 주의해야함
• 영구적인 Data는 이곳에 저장

  5) onStop()

• Activity가 다른 Activity에 의해 100% 가려질 때 호출되는 메소드
• 홈 키를 누르는 경우, 다른 액티비티로의 이동이 있는 경우가 있음
• 이 상태에서 Activity가 호출되면, onRestart() 메소드가 호출됨

  6) onDestroy()

• Activity가 완전히 종료되었을 때 호출되는 메소드
• 사용자: finish(), onBackPressed()(기존 액티비티의 onResume()까지 호출된 후 onDestroy() 호출)
• 시스템: 메모리부족(프로세스 종료)
• onStop(), onDestroy() 메소드는 메모리 부족이 발생하면 스킵될 수 있음

  7) onRestart()

• onStop()이 호출된 이후에 다시 기존 Activity로 돌아오는 경우에 호출되는 메소드
• onRestart()가 호출된 이후 이어서 onStart()가 호출됨
  
  

이어지는 간단한 예제풀이를 통해 애매한 부분을 깨닫고 확실하게 이해하시길 바랍니다.

생명주기 예제

1) LoginActivity에서 RegisterActivity를 호출했을 때 라이프 사이클 호출 순서를 나열하시오.

2) RegisterActivity 종료 후 다시 LoginActivity가 보여질 때 라이프사이클 호출 순서를 나열하시오.

답은 포스팅 맨 아래에 있습니다.

한번 자신이 얼마나 이해했는지 풀어보는게 도움이 많이 됩니다.

예시 1번 답

[login] onPause() [register] onCreate() [register] onStart() [register] onResume() [login] onStop()

• registerActivity를 호출하면 우선 loginActivity를 onPause()합니다.
• 그런 다음 registerActivity를 onCreate()하고,
• 생성된 registerActivity를 onStart()하고,
• 시작한 registerActivity를 onResume()합니다.
• registerActivity가 onResume()되며 포커스인 상태이기 때문에, 비로소 loginActivity는 onStop() 상태에 들어가게 됩니다.

예시 2번 답

[register] onPause() [login] onRestart() [login] onStart() [login] onResume() [register] onStop() [register] onDestroy()

• 다시 loginActivity를 호출하면 우선 registerActivity를 onPause()합니다.
• loginActivity는 onDestroy()되지 않고 onStop() 된채로 백그라운드에서 돌아가고 있기 때문에, onRestart()를 수행합니다.
• 그런 다음 onRestart()된 loginActivity를 onStart()하고,
• onStart() 상태의 loginActivity를 onResume()합니다.
• loginActivity가 onResume() 상태가 되어 사용자가 registerActivity로부터 포커스아웃 되었기 때문에 비로소 registerActivity는 onStop() 상태가 됩니다.
• registerActivity를 종료하면 onDestroy() 호출 후 완전히 종료됩니다.

오늘은 Android Lifecycle 중 가장 기초적인 Activity Lifecycle에 대해 알아봤습니다. 다음 포스팅에서는 Fragment Lifecycle에 대해 알아보겠습니다. 뭐든지 기초가 탄탄해야한다는 옛 말이 틀린게 하나 없네요. 특히나 안드로이드 공부하면서 더욱 크게 느끼는 것 같습니다.

컬렉션 프레임워크

1) 컬렉션 프레임워크란?

• 대량의 데이터를 쉽고 효과적으로 처리할 수 있는 표준화된 방법을 제공하는 클래스의 집합
• 데이터를 처리하는 알고리즘과 데이터를 저장하는 자료구조를 구조화하여 클래스로 구현한 것
• 데이터를 저장하는 자료 구조에 따라 List Interface, Set Interface, Map Interface로 나누어짐

  2) 컬렉션 프레임워크를 사용하는 이유

• 기존에는 많은 데이터들을 처리할 때에 배열을 사용했지만 그 크기가 고정되어 있고 삽입/삭제를 자주할 경우 성능이 저하되는 단점이 있었음
• 따라서 이것을 보완하기 위해 동적 배열의 개념을 탑재한 컬렉션 프레임워크를 제공하였음
• 이로 인해 자료의 삽입/검색/삭제에 의한 성능의 저하와 같은 단점이 해소되었음
• 자료형에 구애받지 않고 담을 수 있으며 크기가 동적으로 조절된다는 장점이 있음

1. List

1) 특징

• 순서가 있는 데이터의 집합
• 데이터의 중복을 허용함

  2) 종류

• ArrayList » 객체 내부에 있는 배열에 데이터를 저장 » 속도가 빠르고 크기를 마음대로 조절이 가능 » 단방향 포인터 구조로 자료에 대한 순차적인 접근이 가능 » 동기화를 보장하지 않기 때문에 가벼움
• LinkedList » Node와 Pointer를 이용한 리스트 » 양방향 포인터 구조로 데이터의 삽입, 삭제가 잦을 경우에 효율적 » 스택, 큐, 양방향 큐 등에 사용됨
• Vector » ArrayList와 동일하게 사용이 가능한 리스트로, 동기화 여부의 차이가 있음 » 동기화를 보장함(ArrayList와 반대)
• Stack » LIFO, 제일 마지막에 추가된 데이터가 가장 먼저 꺼내지는 자료구조

2. Set

1) 특징

• 순서를 유지하지 않는 데이터의 집합
• 데이터의 중복을 허용하지 않음

  2) 종류

• HashSet » 무작위로 값을 담는 Set(순서를 가지지 않음) » 효율이 좋음
• LinkedHashSet » 넣은 순서대로 값을 담는 Set(순서를 가짐)
• TreeSet » 자동정렬을 수행함으로써 값을 담는 Set(순서를 가지지 않음) » 가장 바쁜 Set

3. Queue

1) 특징

• FIFO 구조를 가짐
• 들어올때는 enqueue, 나갈때는 dequeue라고 함

  2) 종류

• PriorityQueue » 우선순위를 가지는 큐로 원소에 우선순위를 부여하여 높은순으로 먼저 반환함 » 이진트리 구조로 구현되어 있음
• ArrayDeque » 양쪽으로 삽입/삭제가 가능한 큐 자료구조

  4. Map

  

1) 특징

• Key & Value로 이루어진 데이터의 집합
• 순서를 유지하지 않음
• Key는 중복을 허용하지 않음
• Value는 중복을 허용함

  2) 종류

• HashMap » Key & Value가 무작위로 담기는 Map(순서를 가지지 않음)
• LinkedMap » Key & Value가 넣는 순서대로 담기는 Map(순서를 가짐)
• TreeMap » Key 값에 의해 정렬이 되는 Map(순서를 가지지 않음)

List, Set, Map 차이점

1) List / Set 차이점

• List는 순서가 있는 Collection이기 때문에 데이터를 넣는 순서가 보장되어 Index로 특정 아이템을 가져올 수 있지만 Set은 데이터를 넣는 순서가 보장되지 않아 불가능함
• List는 중복을 허용하지만, Set은 중복을 허용하지 않음

2) List / Map 차이점

• List는 순서가 있지만, Map은 순서가 없음
• Map은 Key, Value값을 저장함

3) Set / Map 차이점

• Set은 데이터 중복을 허용하지 않지만, Map은 Key 중복은 허용하지 않고, Value 중복은 허용함