KEEP GOING!

[GitHub] SSH 방식으로 통신하기

[Ellie] — Sun, 15 Aug 2021 08:35:45 +0900

평소 GitHub을 사용할 때 아무 생각 없이 HTTPS로 remote를 설정하거나 clone 받아서 사용하고 있었는데, 최근 GitHub에서 보안을 강화하겠다고 password 인증 방식을 없애버렸고, 그 에러를 해결하면서 SSH 인증 방식에 대해 알게 되었다.

이번 포스팅에서는 이 과정에서 알게된 SSH 방식으로 통신하도록 설정하는 방법을 정리하려고 한다.

로컬 Git을 GitHub과 연결하기 위해서는 어떤 방식으로 원격 저장소와 통신할 것인지를 설정해 주어야 한다.

그 방식으로는 현재 아래 3가지가 있다.

HTTPS 방식
SSH 방식
GitHub CLI 방식

※ 기존에는 1, 2번 방식만 있었는데 마이크로소프트가 GitHub을 인수하면서 GitHub CLI 방식이 추가 되었다.
GitHub CLI는 GitHub의 기능들(PR, 이슈, Repository 등)을 커맨드 라인으로 쓸 수 있도록 도와주는 CLI 도구이다.

여기서 통신 방법을 설정할 수 있는 케이스는 아래 3가지 정도로 요약할 수 있다.

1. 처음 프로젝트를 만들어서 원격 저장소에 올리려고 하는 경우

$ git remote add origin [URL]

2. 원격 저장소에 있는 코드를 로컬로 받아오려는 경우

$ git clone [URL]

3. 통신 방식을 바꾸려는 경우 (HTTPS → SSH)

$ git remote set-url origin [URL]

위에서 [URL]에 들어가는 url에 따라 통신 방식이 결정된다.

# HTTPS 방식
> https://github.com/USERNAME/REPOSITORY.git

# SSH 방식
> git@github.com:USERNAME/REPOSITORY.git

현재 자신의 프로젝트는 어떤 방식으로 통신하는지 확인하기 위해서는 아래 명령어를 실행 해 보자.

$ git remote -v

이 결과가 https://github.com/~~~ 이라면 HTTPS 방식으로, git@github.com:~~~ 이라면 SSH 방식으로 통신하고 있는 것이다.

이제 본론으로 ...

여기서 SSH(=Secure Shell)는 네트워크 프로토콜로, SSH를 사용해 안전하게 네트워크 통신을 할 수 있다.

SSH 프로토콜은 사용자 인증 방식을 필요로 하는데, GitHub에서는 공개 키(Public Key) 인증 방식을 사용한다.

공개 키 인증 방식은 사용자 컴퓨터에 등록 되어 있는 공개 키(Public Key)-개인 키(Private Key) 쌍과 GitHub 서버에 등록 되어 있는 공개 키를 비교해 올바른 사용자인지 인증하는 방식이다.

GitHub에 공개 키가 등록 되어있는지 확인하는 가장 간단한 방법은 아무 리포지토리에 들어가서 clone을 클릭해서 SSH 탭을 들어갔을 때 SSH Key가 없는 경우 아래 노란색 박스 경고창이 뜬다.

경고창이 없으면 이미 키가 등록 되어 있는 것이다.

※ 만약 키가 있는데 컴퓨터의 키와 다른 경우, 네트워크 통신 시도 시 ssh permission denied (publickey)에러가 뜬다.

이 때는 컴퓨터의 키로 GitHub에 등록된 키를 업데이트 해 주어야 한다.

키가 등록되어 있지 않은 경우, 일단 컴퓨터에 이미 SSH 키 쌍이 존재하는지 확인해야 한다.

컴퓨터에 이미 SSH 키 쌍이 존재한다면 그 중 공개 키를 GitHub에 등록하면 되고, 없다면 먼저 키 쌍을 생성해야 한다.

컴퓨터에서 SSH 키 존재 여부 확인

일반적으로 사용자 키 파일은 ~/.ssh 경로에 존재한다.

키를 확인하기 위해 터미널에 아래 명령어를 실행해 보자.

$ ls -al ~/.ssh

키 생성

이렇게 아무것도 없으면 키를 생성해 주어야 한다.

키는 ed25519 방식으로 생성할 수 있고, rsa 방식으로 생성할 수도 있다.

# ed25519 
$ ssh-keygen -t ed25519 -C "your_email@example.com"

# rsa 
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

ed25519 방식 키 생성

rsa 방식 키 생성

여기서 .pub로 끝나는 파일이 공개 키 이고 없는 파일이 개인 키이다.

키 조회

cat 명령어로 공개 키를 조회해 보자.

# ed25519 
$ cat ~/.ssh/id_ed25519.pub 

# rsa 
$ cat ~/.ssh/id_rsa.pub

조회한 값이 ssh-ed25519 또는 ssh-rsa로 시작하면 올바른 공개 키라고 볼 수 있다.

발급 받은 키 GitHub에 등록

프로필을 클릭해서 [Settings]에 들어간다.

2. [SSH and GPG keys] 탭에 들어가서 [New SSH key]를 클릭한다.

3. Key 탭에 위에서 조회한 키를 넣고 추가한다.

끝!

다시 아무 리포지토리 Clone에 들어가 보면 노란 경고창이 사라진 것으로 GitHub에 공개 키가 등록 되었음을 간접적으로 확인할 수 있다.

이제 SSH URL을 통해 GitHub과 통신할 수 있다!

[GitHub] personal access token으로 인증하기 (for MacOS)

[Ellie] — Sat, 14 Aug 2021 16:34:47 +0900

오늘도 여느 때와 같이 터미널에서 Github으로 push를 하려고 하는데 갑자기 아래와 같은 에러가 발생했다.

remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.

에러 메시지를 확인해 보니 어제(8/13)부로 Https 통신할 때 사용하던 password 인증 방식을 지원하지 않는다고 한다.

즉, 이제는 무조건 personal access token을 사용해 인증해야 한다는 것이다.

이렇게 토큰을 이용해 추가 인증을 하는 방식을 2FA(Two-Factor Authentication)라고 하는데, GitHub에서 이를 통해 보안을 강화하려고 하는 것 같다.

해결 방법

1. personal access token 발급 받기

토큰 생성 방법은 여기에 사진과 함께 자세한 설명이 나와 있다.

2. password 값을 발급 받은 토큰으로 업데이트 (in MacOS)

MacOS는 GitHub에서 사용하는 username, password 등의 credential 정보를 컴퓨터에 캐싱해 두고 사용하기 때문에 이 캐싱된 값을 변경해 주어야 한다.

먼저, keychain access 앱을 열어서 "github.com"으로 검색한 두 [종류]가 '인터넷 암호'로 되어 있는 아이템을 찾는다.

해당 아이템에 들어가서 [암호 보기]를 체크한 뒤 발급 받은 토큰을 입력하고 변경사항을 저장한다.

성공!

[Android] ExoPlayer blink(깜빡임 현상) 제거하기

[Ellie] — Wed, 19 May 2021 21:34:04 +0900

ExoPlayer는 구글에서 만든 동영상 재생 라이브러리이다. MediaPlayer보다 훨씬 안정적이고 다양한 기능을 지원하기 때문에 유튜브나 인스타그램 등 많은 곳에서 ExoPlayer를 사용한다.

그래서 진행중인 프로젝트에서 ExoPlayer를 사용해 동영상이 준비되기 전에는 썸네일 이미지를 보여주고, 준비가 완료되면 자연스럽게 동영상을 재생하려고 했는데 재생 직전 검은 화면으로 깜빡이는 현상을 확인했다.

이번 포스팅에서는 이 문제의 원인과 해결 방법을 공유하려고 한다.

ExoPlayer는 동영상을 재생하는 Player가 있고, 화면에 보여주는 PlayerView에 Player를 등록해서 사용한다.

그런데 PlayerView는 동영상을 재생하는 View이기 때문에 background 속성이 없고, 썸네일을 위한 기능은 없는 것 같았다.

artwork라는 속성으로 PlayerView의 백그라운드를 drawable로 지정할 수는 있지만 Bimap 이미지로는 설정할 수 없었다.

그렇기 때문에 동영상을 재생하기 위한 PlayerView와 크기가 동일한 ImageView를 위에 두고 PlayerView가 준비되기 전에는 ImageView로 썸네일 이미지를 보여주고 동영상 재생 준비가 되었을 때 ImageView를 invisible 시켜 PlayerView를 보여주는 방식을 사용했다.

그런데, Player에서 재생 준비가 된 시점에서 PlayerView를 보여주면 잠시 검은 화면이 보이면서 깜빡이는 현상이 있었다.

artwork를 지정하면 검은 화면이 아닌 지정한 artwork가 나온다. 그래서 artwork를 투명한 색상으로 설정해 봤지만 여전히 검은 화면이 나왔다..

이 문제를 해결하기 위해 여러 삽질을 했지만 결국 이 문제의 궁극적인 원인은 동영상을 재생할 때 첫 프레임이 그려지기 전까지 잠깐 동안 검은 화면이 보이게 되는 것이었다.

이를 위해 ExoPlayer에서는 첫 프레임이 그려진 뒤 호출되는 콜백 함수가 있었고, 이를 이용해 첫 프레임이 그려진 뒤에 ImageView를 invisible 시켜 PlayerView를 보여주는 것으로 해결했다.

simpleExoPlayer.addVideoListener(object : VideoListener {
    override fun onRenderedFirstFrame() {
        super.onRenderedFirstFrame()
        
        // 첫 프레임이 그려진 뒤에 썸네일 이미지뷰를 없앤다. (재생 전 깜빡이는 현상 방지)
        binding.thumbnailView.visibility = View.GONE
    }
})

Android Studio 자주 쓰는 단축키 모음

[Ellie] — Fri, 11 Sep 2020 17:57:12 +0900

For Windows

단축키	설명
Shift + F6	동일하게 연결 되어 있는 변수명 변경
Shift 2번	프로젝트 내 클래스/파일/심볼/액션 찾기
Ctrl + F4	탭 닫기
Ctrl + B Ctrl + Click	선언부로 이동
Ctrl + Alt + B	구현부로 이동
Ctrl + Shift + I	선언부 팝업창으로 보기
Ctrl + F	현재 파일에서 찾기 (Find)
Ctrl + Shift + F	전체 파일에서 찾기 (Find)
Ctrl + R	현재 파일에서 바꾸기 (Replace)
Ctrl + Shift + R	전체 파일에서 바꾸기 (Replace)
Ctrl + D	라인 or 블럭 복제 (Duplication)
Alt + 드래그	세로로 블럭 지정해서 한 번에 수정하기
Ctrl + H	클래스 계층(Hierarchy) 보기
Ctrl + I	Implement methods 구현
Ctrl + O	Override mothods 구현
Ctrl + Alt + I	자동 indentation
Ctrl + Alt + O	사용하지 않는 import 제거
Alt + F7	사용처 찾기 (프로젝트 계층 단위로 볼 수 있음)
Ctrl + Alt + 위/아래	사용처 찾기 모드에서 위/아래 사용처로 이동
Ctrl + Alt + 좌/우	이전/이후 커서 위치로 이동 (with 파일 간 이동)
Ctrl + "+/-"	현재 스코프 펴기/접기
Ctrl + Shift + "+/-"	파일 전체 펴기/접기
Ctrl + Shift + T	테스트 코드 만들기
Shift + Delete Ctrl + X	해당 라인 잘라내기
Alt + 숫자키(1~9)	해당 패널 열고 닫기 (Alt + 7 : Code Structure)
Alt + 위/아래	method 간 이동

+ 단말 내부 파일 구조 확인: View > Tool Windows > Device File Explorer

For Mac

단축키	설명
shift + F6	동일하게 연결 되어 있는 변수명 변경
shift 2번	프로젝트 내 클래스/파일/심볼/액션 찾기
Ctrl + F4	탭 닫기
command + B command + Click	선언부로 이동
command + option + B	구현부로 이동
option + space command + Y	선언부 팝업창으로 보기
command + F	현재 파일에서 찾기 (Find)
command + shift + F	전체 파일에서 찾기 (Find)
command + R	현재 파일에서 바꾸기 (Replace)
command + shift + R	전체 파일에서 바꾸기 (Replace)
command + D	라인 or 블럭 복제 (Duplication)
option + 드래그	세로로 블럭 지정해서 한 번에 수정하기
control + H	클래스 계층(Hierarchy) 보기
control + I	Implement methods 구현
control + O	Override mothods 구현
control + option + I	자동 indentation
control + option + O	사용하지 않는 import 제거
command + option + 좌/우	이전/이후 커서 위치로 이동 (with 파일 간 이동)
command + shift + "+/-"	파일 전체 펴기/접기
command + shift + T	테스트 코드 만들기
command + delete	해당 라인 지우기
command + X	해당 라인 잘라내기
command + 숫자키(1~9)	해당 패널 열고 닫기

Android Studio 내부 소스 코드 보는 방법

[Ellie] — Sat, 18 Jul 2020 16:06:41 +0900

안드로이드 스튜디오에서 내부 소스 코드를 보려고 할 때 위 처럼 모든 구현부가 RuntimeException을 던지는 파일이 나올 때가 있다.

throw new RuntimeException("Stub!");

메시지 내용은 다음과 같다.

Decompiled .class file, bytecode version: 52.0 (Java 8)
Sources for 'Android API 30 Platform' not found.

이 문제는 안드로이드 API 버전에 해당하는 Source가 다운로드 되어 있지 않아서 발생한 것이다.

여기서 두 번째 "Sources for 'Android API 30 Platform' not found." 메시지는 안드로이드 API 30 버전의 Source가 없으니 다운로드를 하라는 메시지이다. 하지만 현재 30 버전의 소스코드는 공개되지 않은 상태이기 때문에 다운로드 받을 수 없다.

이를 위해 Android 버전을 29로 내려야 한다.

그 방법은 앱 모듈의 gradle 파일 - build.gradle(Module: app) - 의 compileSdkVersion을 29로 설정한다.

그 때 아래와 같이 컴파일 에러가 발생할 수도 있다.

이는 targetSdkVersion보다 compileSdkVersion이 낮을 수 없기 때문인데, 이는 Gradle 호환성과 관련이 있다. 해결 방법은 2가지가 있다.

첫 번째 방법은 targetSdkVersion을 맞춘다.

android {
    compileSdkVersion 29
    ...
    defaultConfig {
        ...
        targetSdkVersion 29
        ...
    }

    ...
}

두 번째 방법은 주석을 추가해서 Gradle 호환성 문제를 검사하지 말라고 컴파일러에게 알려준다.

android {
    // noinspection GradleCompatible
    compileSdkVersion 29
    
    ...

}

이제 API 29에 해당하는 Source가 있는지 확인한다.

안드로이드 스튜디오에 [Preferences] (Windows에서는 [Settings]) 에서 [Android Sdk]로 들어간다.

아래 체크박스에 show Package Details 체크해서 Sources for Android 29가 Installed 되었는지 확인한다.

이렇게 하면 API 29에 대한 내부 소스 코드를 볼 수 있다!

[Android] ListAdapter로 리스트 효율적으로 관리하기 (with DiffUtil)

[Ellie] — Fri, 12 Jun 2020 01:24:39 +0900

이전 포스팅에서 RecyclerView의 아이템을 LiveData로 관리하는 방법에 대해 알아보았다. 이 때 함께 사용하면 좋은 ListAdapter에 대해 소개하려고 한다.

RecyclerView를 사용하다보면 아이템을 변경할 일이 많고, 이럴 때 기존에는 notifyDataSetChanged()로 모든 아이템을 업데이트 하는 방법을 사용해 왔다. 하지만 이 방법은 아이템 개수가 많아질수록 비효율적일 수 밖에 없다. 물론 아래 notify- 메서드를 잘 이용하면 전체 데이터를 바꿀 필요가 없지만 position을 가지고 수동으로 관리해 주어야 하는 불편함이 있을 수 있고, 아이템의 정해진 순서가 없을 때는 이 기능을 사용할 수 없다.

RecyclerView 아이템의 변경사항을 notify하는 메서드들

이런 문제를 알고 구글에서는 DiffUtil이라는 매우 편리한 유틸리티 클래스를 만들었는데, 이 클래스는 두 리스트의 차이점을 찾아 업데이트 되어야 할 목록을 반환 해 줘서 RecyclerView 어댑터에 대한 업데이트를 알리는데 사용된다.

DiffUtil 사용하기

DiffUtil을 사용하는 방법은 다음과 같다. 먼저 DiffUtil.Callback을 구현한 클래스를 만들어야 한다.

class PersonDiffCallback(
    private val oldList: List<Person>,
    private val newList: List<Person>
) : DiffUtil.Callback() {
    override fun getOldListSize() = oldList.size

    override fun getNewListSize() = newList.size

    override fun areItemsTheSame(oldItemPosition: Int, newItemPosition: Int) =
        oldList[oldItemPosition].id == newList[newItemPosition].id

    override fun areContentsTheSame(oldItemPosition: Int, newItemPosition: Int) =
        oldList[oldItemPosition] == newList[newItemPosition]
}

이 Callback 클래스를 RecyclerView의 리스트 업데이트 하는 함수에 아래와 같이 코드를 추가한다.

class PersonDiffAdapter : RecyclerView.Adapter<PersonViewHolder>() {
    private val people = mutableListOf<Person>()
    
    ...
    
    fun replaceItems(newPeople: List<Person>) {
        val diffCallback = PersonDiffCallback(people, newPeople)
        val diffResult = DiffUtil.calculateDiff(diffCallback)
        
        people.clear()
        people.addAll(newPeople)
        
        diffResult.dispatchUpdatesTo(this)
    }
}

DiffUtil의 메서드의 역할은

calculateDiff()에서 diff 알고리즘을 통해 변경된 아이템을 감지하고,
dispatchUpdatesTo()에서 지정된 Adapter로 업데이트 이벤트를 전달한다.

추가로...

DiffUtil은 dispatchUpdatesTo()에서 변경사항을 리스트에 적용할 때 추가 및 삭제 애니메이션을 제공한다.
DiffUtil은 아이템 개수가 많을 경우 calculateDiff()의 diff 계산 시간이 길어질 수 있기 때문에 백그라운드 스레드에서 처리하는 것이 좋다.
dispatchUpdatesTo()로 RecyclerView에 변경 사항을 적용하기 전에 원본 리스트를 새로운 리스트로 교체하는 작업을 해 줘야 한다.

여기서 3번에 대해 부가 설명을 하려고 한다. 이 부분은 이유를 알아보기 전에 일단 dispatchUpdatesTo()에서 하는 일을 알아야 한다. dispatchUpdatesTo()에서는 diff 계산에서 반환된 DiffResult 객체가 변경사항을 Adapter에 전달하고 Adapter가 변경 사항에 대해 알림을 받는다. 이 알림은 위에서 소개한 notify- 메서드로 변경 사항에 대해 리스트의 아이템이 업데이트 된다.

아래 코드는 DiffUtil에서 Adapter로 변경 사항을 notify 메서드로 알리는 부분이다.

DiffUtil에서 사용하는 notify- 메서드

아래 글은 DiffUtil 공식 문서에 나와 있는 dispatchUpdatesTo()에 대한 설명이다.

DiffUtil 공식 문서의 dispatchUpdatesTo() 설명

위 글을 읽어 보면, 리스트를 교체한 직후 업데이트 이벤트를 어댑터로 전송하고 그 이후에 RecyclerView가 리스트에 접근해야 하기 때문에 dispatchUpdatesTo()를 호출하기 전에 리스트를 변경해야 한다고 한다. 즉, dispatchUpdatesTo()에서는 데이터를 변경할 때 notify- 메서드로 즉시 어댑터로 업데이트 이벤트를 전달하기 때문에 그 전에 새로운 리스트로 교체를 해야 RecyclerView에 제대로 적용이 된다는 것이다.

또한 어댑터에서 사용하는 리스트는 MutableList로 만들어야 제대로 동작한다.

AsyncListDiffer 사용하기

DiffUtil 클래스를 사용하기 위해 개발자는 직접 백그라운드 스레드에서 비교 처리를 수행하고 결과를 메인 스레드에서 처리하는 코드를 작성해야 했다. 하지만 AsyncListDiffer 클래스는 이런 boiler plate 작업을 줄이기 위해 내부적으로 diff 계산을 백그라운드 스레드로 처리한 뒤 리스트 업데이트까지 해 준다. 덕분에 우리는 스레드를 신경쓰지 않고 DiffUtil을 훨씬 편하게 사용할 수 있게 되었다.

사용하는 방법 DiffUtil보다 훨씬 간단하다. 먼저 DiffUtil.ItemCallback을 구현한 클래스를 만들어야 한다.

class PersonDiffItemCallback : DiffUtil.ItemCallback<Person>() {
    override fun areItemsTheSame(oldItem: Person, newItem: Person) =
        oldItem.id == newItem.id

    override fun areContentsTheSame(oldItem: Person, newItem: Person) =
        oldItem == newItem
}

그리고 RecyclerView Adapter에서 AsyncListDiffer를 생성해 아래처럼 사용하기만 하면 된다.

class PersonAsyncDifferAdapter : RecyclerView.Adapter<PersonViewHolder>() {
    private val asyncDiffer = AsyncListDiffer(this, PersonDiffItemCallback())

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int) = PersonViewHolder(
        ItemPersonBinding.inflate(LayoutInflater.from(parent.context), parent, false)
    )

    override fun onBindViewHolder(holder: PersonViewHolder, position: Int) =
        holder.bind(asyncDiffer.currentList[position])

    override fun getItemCount() = asyncDiffer.currentList.size

    fun replaceItems(newPeople: List<Person>) {
        asyncDiffer.submitList(newPeople)
    }
}

AsyncListDiffer에서

submitList()를 호출하면 diffing 작업과 리스트 변경까지 진행하고,
currentList로 현재 리스트의 아이템들을 확인할 수 있다.

AsyncListDiffer에서 넘어오는 currentList는 READ ONLY 리스트로 변경이 불가능하다. 그렇기 때문에 currentList의 아이템을 변경하기 위해서는 submitList()를 통해서만 가능하다.

ListAdapter 사용하기

AsyncListDiffer를 내부적으로 사용하고 있는 클래스가 바로 ListAdapter 클래스이다. 우리는 이제 그저 ListAdapter를 상속한 클래스를 만든 것 만으로도 AsyncListDiffer를 사용할 수 있게 되었다.

ListAdapter는 추상클래스로 아래 구현부 코드를 보면 우리가 AsyncListDiffer를 사용했을 때 코드처럼 RecyclerView의 Adapter를 상속하고, AsyncListDiffer를 만들어서 사용하고 있다. 그렇기 때문에 AsyncListDiffer의 submitList()와 currentList도 그대로 사용할 수 있다.

ListAdapter 구현부 코드 스니펫

ListAdapter를 사용한 RecyclerView Adapter는 아래처럼 만들 수 있다.

class PersonListAdapter : ListAdapter<Person, PersonViewHolder>(diffUtil) {

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int) = PersonViewHolder(
        ItemPersonBinding.inflate(LayoutInflater.from(parent.context), parent,false)
    )

    override fun onBindViewHolder(holder: PersonViewHolder, position: Int) {
        holder.bind(getItem(position))
    }

    fun replaceItems(items: List<Person>) {
        submitList(items)
    }

    companion object {
        val diffUtil = object: DiffUtil.ItemCallback<Person>() {
            override fun areContentsTheSame(oldItem: Person, newItem: Person) =
                oldItem == newItem

            override fun areItemsTheSame(oldItem: Person, newItem: Person) =
                oldItem.name == newItem.name
        }
    }
}

위의 코드를 보면 기존 RecyclerView Adapter를 상속하는 방식과 달라진 점을 볼 수 있다.

getItemCount() 오버라이딩 메서드가 없다.
getItem(position) 메서드가 생겼다.

ListAdapter 내부에서 리스트 아이템을 관리하면서 getItemCount() 메서드가 재정의 되어 있고, 리스트의 아이템을 가져오는 getItem() 메서드가 생긴 것이다.

마무리

정리를 해 보자면, ListAdapter를 사용하면 변경 된 아이템만 UI를 업데이트 할 수 있고, 이를 위한 boiler plate 코드도 엄청나게 줄여주며, 스레드 작업과 애니메이션 작업까지 알아서 다 해준다.

약간의 불편한 점이라고는 리스트가 내부적으로 READ ONLY라서 변경을 위해서는 별도의 리스트를 두고 관리해야 한다는 정도지만, 이것도 RecyclerView의 데이터를 LiveData로 관리하는 경우에는 오히려 시너지를 내기 때문에 단점이라고 보기는 힘들 것 같다.

결론, ListAdapter를 사용하자!

[참고한 사이트]

[Android] Context 제대로 알고 사용하자!

[Ellie] — Wed, 10 Jun 2020 15:23:58 +0900

안드로이드에서 Context는 가장 많이 등장하고, 그만큼 핵심이 되는 개념이기 때문에 제대로 알고 사용하는 것이 좋다. 이번 포스팅에서는 Context의 역할 및 종류와 언제 사용하면 좋은지 알아 보려고 한다.

Context란?

Context는 어플리케이션 환경에 관한 전체 정보를 받을 수 있는 추상 클래스로 액티비티, 브로드캐스트, 서비스를 시작할 때도 사용되고 리소스에 접근할 때도 Context가 사용된다. 이처럼 어플리케이션과 관련된 정보에 접근하고자 하거나 어플리케이션과 연관된 시스템 레벨의 함수를 호출하고자 할 때 Context가 필요하다.

안드로이드는 어플리케이션 관련 정보를 ActivityManagerService에서 관리하고 있고, 어플리케이션과 관련된 정보에 접근하려고 할 때 해당 어플리케이션에 대한 식별자가 필요한데 그 역할을 하는 것도 Context이다.

ContextWrapper와 ContextImpl

Context는 추상 클래스이기 때문에 이를 사용하기 위해서는 구현체가 있어야 한다. 기본 구현체는 ContextImpl이고, 이 구현체는 사용자에게 노출하지 않고 ContextWrapper로 감싸져 있다.

[참고 사항]

ContextImpl 클래스는 앱에서 직접 사용할 수 있는 클래스가 아니기 때문에 소스코드로만 확인할 수 있다.
앞으로 "Context 구현체"라는 용어가 등장하는데, 이는 ContextWrapper가 wrapping하는 Context 구현체가 ContextImpl이 아닐 수 있기 때문에 ContextImpl과 용어를 구분하기 위함이다.

Context의 클래스 구조는 아래 그림과 같다.

Context 클래스 구조

ContextWrapper 클래스는 생성자로 Context 구현체를 받아서 Context 동작을 Context 구현체의 동작으로 위임한다. 즉, ContextWrapper를 상속하는 Activity, Service, Application과 같은 컴포넌트에서 ContextWrapper의 함수를 호출하면 Context 구현체의 동작을 수행하게 하는 것이다. 이를 Proxy 패턴이라고 하는데, 이 패턴을 사용하면 Context 구현체와 이를 사용하는 쪽의 결합도가 낮아져 쉽게 Context 구현체를 변경할 수 있다는 장점이 있다. 이를 공식 문서에서는 원본 Context의 변경 없이 Context 동작을 수정할 수 있다고 설명하고 있다.

더 자세한 이해를 위해 ContextWrapper 클래스의 코드를 보면 아래와 같다.

ContextWrapper 코드 스니펫

ContextWrapper 코드 스니펫 2

코드에서 볼 수 있듯이 ContextWrapper는 생성자로 Context의 구현체를 받는다. 그리고 Context의 모든 동작을 Context 구현체의 함수로 위임한다.

이 구조가 좋은 점은 앞서 언급한 것 처럼 Context 구현체를 바꾸어도 Context를 사용하던 코드는 변경하지 않아도 된다는 것이다. ContextWrapper에서 Context 구현체를 바꾸는 메서드가 attachBaseContext(Context base)이다.

Context의 종류

위의 Context 구조에서 볼 수 있듯이 ContextWrapper를 상속하는 컴포넌트는 Activity, Service, Application이다. Broadcast Reciever나 Content Provider는 ContextWrapper를 상속하지 않는다.

여기서 Acitvity, Service, Application 컴포넌트는 각각 ContextImpl을 생성하고 ContextWrapper에서 getBaseContext()와 getApplicationContext() 메서드를 사용해 Context를 반환한다.

Application Context

- 싱글톤 객체로 어플리케이션의 생명주기를 따른다. 즉, 앱의 시작 시 부터 종료 시 까지 살아있다.
Activity Context

- Activity 자체가 Context를 상속하고 있기 때문에 Activity 인스턴스 자체가 Context 역할을 한다.
- 그렇기 때문에 Activity Context는 액티비티 생명주기를 따른다.

Context Type

Application - 싱글톤으로 어플리케이션 객체가 생성될 때 함께 Application Context가 생성되기 때문에 Application Context는 동일한 앱 안에서 항상 동일한 인스턴스를 반환한다.
Activity / Service - 액티비티나 서비스가 생성될 때마다 각자의 Context 인스턴스가 생성된다.
Broadcast Receiver - 자기 자신이 Context는 아니다. 리시버가 브로드캐스트 처리를 할 때마다 Context를 onReceive()의 인자로 전달 받아서 사용한다. 전달 받은 Context의 생명주기를 따르기 때문에 액티비티 컨텍스트로 브로드캐스트 실행 시 액티비티가 종료되면 브로드캐스트도 함께 종료된다.
Content Provider - 자기 자신이 Context는 아니다. 동일한 응용 프로그램에 대해 호출 시 동일한 싱글톤 Context 객체를 반환하고, 서로 다른 응용 프로그램에 대해 호출 시 다른Context 객체를 반환한다.

Context 참조 방법

ActivityName.this
- Activity Context를 반환한다. Activity Scope 안에서 사용할 때는 this만으로도 가져올 수 있다.

Java에서는 Activity의 Inner Class와 같이 Activity Scope를 벗어난 곳에서 액티비티 인스턴스를 참조하고 싶을 때 ActivityName.this로 가져올 수 있다.
마찬가지로 Kotlin에서는 higher order function을 많이 사용하기 때문에 Activity의 Scope를 벗어나는 경우가 자주 있는데 해당 Scope에서 액티비티 인스턴스를 가져오고 싶을 때 this@ActivityName을 이용해 가져올 수 있다.

getApplicationContext()
- Application Context를 반환한다.

getApplication()
- Application 인스턴스를 반환한다. Application도 Context의 자식 클래스이므로 Context처럼 사용할 수 있다.
- 하지만 Application과 Application Context가 항상 동일한 인스턴스라는 보장이 없고, Application은 Activity나 Service 내부에서만 참조가 가능하다는 차이점도 있다.

getBaseContext()
- ContextWrapper의 Context 인스턴스를 반환한다. 다른 Context를 참조해야 하는 경우, 그 ContextWrapper 안에 있는 context를 getBaseContext()로 가져와 사용한다. 이는 Activity Context의 일종이다.

View의 getContext()
- View에도 getContext() 메서드가 있어 Context를 가져올 수 있는데, View를 생성할 때 생성자의 인자로 들어가는 Context가 getContext()의 결과로 반환된다. 일반적으로 View가 속해 있는 Activity의 Context가 해당 View의 Context가 된다.

Context의 생명주기가 다르기 때문에 Activity와 분리된 작업에 Activity Context를 사용하면 예상치 못한 동작이 발생할 수 있다. 반대로 Activity에 종속된 작업을 Application Context를 이용하면 Activity가 종료되어도 Context를 이용한 작업이 종료되지 않아 memory leak이 발생할 수도 있다. 그렇기 때문에 Context를 사용할 때 각 Context의 특징과 Context가 필요한 작업의 특성을 고려해 Context를 알맞게 선택해 사용해야 한다.

[참고한 사이트]

[Android, Context] Context 넌 무엇이더냐?

[MSSQL] sa 계정 비밀번호 변경 방법

[Ellie] — Thu, 4 Jun 2020 00:15:58 +0900

SQL Server 인스턴스를 만들 때 인증 방식을 혼합 모드로 만들어서 sa 계정을 만들어 놓고 그 뒤로 윈도우 인증 방식으로만 접속하다보니 sa 계정 비밀번호를 잊어버리는 사태가 발생한 적이 있었다.. 이 때 sa 계정이 필요했던 이유는 윈도우 인증 방식이 [컴퓨터 이름]\[인스턴스 이름]으로 인증하기 때문에 컴퓨터 이름을 변경하면서 사용할 수 없어졌기 때문이다.

이번 포스팅은 sa 계정 비밀번호를 변경하기 위해 여러 번의 구글링과 몇 번의 오류를 해결한 뒤에 성공했던 여정을 기록한 글이다.

시작!

먼저, 컴퓨터 이름을 다시 기존 이름으로 바꾼 뒤 윈도우 인증 방식으로 SQL Server에 접속한다.

[개체 탐색기]에서 서버 이름을 우클릭한 뒤 [속성] > [보안] > [서버 인증]에 들어가서 [SQL Server 및 Windows 인증모드(S)]로 인증 방법을 변경한다.

이제 [개체 탐색기]에 있는 서버의 하위 목록인 [보안] > [로그인] 으로 들어가면 sa가 있는데 이를 더블클릭하면 아래 화면이 나온다. 여기서 암호를 변경한 뒤 SQL Server 구성관리자에서 인스턴스를 재시작하면 된다.

이후에 변경한 sa 계정으로 접속해도 "접속할 수 없다"라는 오류가 발생하는 경우, 암호가 제대로 변경되지 않을 수도 있기 때문에 cmd를 관리자모드로 실행 후 아래 명령어를 통해 암호를 변경해 줘야 한다.

osql -E 는 윈도우 인증 방식으로 SQL Server 인스턴스 접속하라는 명령어이다.

  > osql -E
  > EXEC sp_password NULL, '원하는 패스워드', 'sa'
  > GO

이렇게 해서 성공하면 좋겠지만 내 경우에는 접속을 시도하니 아래와 같은 오류가 발생했다.

"서버에는 연결했지만 로그인 하는 동안 오류가 발생했습니다. (provider: 공유메모리 공급자. error: 0 - 파이프의 다른 끝에 프로세스가 없습니다.)"

이를 해결하기 위해 SQL Server 구성관리자에 들어가서 아래 화면과 같이 네트워크 구성 > 프로토콜 > TCP/IP를 "사용" 으로 변경한 뒤 SQL Server 구성관리자에서 인스턴스를 재시작했다.

이렇게까지 했는데도 위와 동일한 오류가 발생한다면, cmd 관리자모드에서 아래 명령어를 입력한다. 이는 인터넷 연결 문제가 있을 때 TCP/IP 설정 정보들을 초기상태로 돌리는 작업이다.

> netsh Winsock reset

그리고 나서 컴퓨터를 재부팅한 후 또 다시 SQL Server 구성관리자에서 인스턴스를 재시작한다.

그렇게 다시한번 sa 계정으로 접속해 보았으나 다음의 오류가 발생했다.

"[ 오류 : 18470 ] 계정을 사용할 수 없습니다."

이는 sa 계정으로 로그인이 비활성화 되었기 때문에 발생하는 오류로, SQL Server에 윈도우 인증방식으로 접속 후 쿼리 창에 아래 쿼리를 실행해 sa계정을 활성화 하면 된다.

ALTER LOGIN [sa] ENABLE

이렇게 하고 다시 sa 계정으로 로그인하니 그제서야 접속에 성공했다!!

SQLD 과목 II 정리 노트

[Ellie] — Thu, 28 May 2020 15:01:53 +0900

작년에 SQLD 자격증을 준비하면서 과목 II 파트를 에버노트에 열심히 정리해 놓은 걸 보니 뭔가 아까운 마음에 공유하려고 한다. (과목 I 파트 정리본도 있지만 그 파트는 공부를 시작하면서 패기롭게 노트에 직접 수기로 정리했기 때문에 공유하고 싶어도 참 어렵다...ㅎ) 이는 내용에 대한 설명 보다는 요약 및 정리가 많기 때문에, 전체적인 공부를 끝낸 후에 시험 범위에 대한 내용을 상기시키는 용도로 활용하면 좋을 것 같다.

[MSSQL] OUTPUT, APPLY 문법 정리

[Ellie] — Wed, 27 May 2020 13:24:51 +0900

저번 포스팅에 이어 OUTPUT과 APPLY에 대해 정리하고 마무리 하려고 한다.

OUTPUT

OUTPUT은 INSERT, UPDATE, DELETE, MERGE문에 의한 데이터 변경 작업의 결과를 작업과 동시에 확인할 수 있다. 원래 SELECT를 해야 작업 결과를 볼 수 있고 다른 DML문(INSERT/UPDATE/DELETE/MERGE)은 영향 받은 행의 숫자만 알려주고 영향 받은 데이터는 보여 주지 않는다. 하지만 OUTPUT 키워드와 inserted, deleted 테이블을 사용하면 영향 받은 데이터도 볼 수 있다.

inserted, deleted 테이블

OUTPUT이나 Trigger에서 DML을 사용할 때 자동으로 변경되는 시스템 테이블로, 기존 테이블과 구조가 동일하다.

INSERT/UPDATE/DELETE/MERGE문 작업을 할 때마다 inserted/deleted 테이블이 새로 만들어진다. 하지만 이 테이블은 메모리에만 존재하기 때문에 금방 사라진다.

inserted, deleted 테이블에 들어가는 데이터

사용 예시

INSERT 
    INTO TABLE_A (name, score) 
    OUTPUT inserted.*
    VALUES ('John', 97)

MERGE문은 마지막에 OUTPUT을 추가하면 영향 받은 데이터가 출력으로 나온다.

MERGE TARGET_T target
    USING SOURCE_T AS source (code, name)  
    ON (target.code = source.code)
    WHEN MATCHED THEN
        UPDATE SET name = source.name  
    WHEN NOT MATCHED THEN  
        INSERT (code, name)  
        VALUES (source.code, source.name)  
    OUTPUT deleted.*, inserted.*

참고로, MERGE에서 OUTPUT절을 사용하면 대상 테이블(target table)의 변경 내용을 임의의 순서로 반환한다.

INTO

OUTPUT으로 얻은 결과를 INTO [테이블]로 테이블에 넣을 수 있다. 여기서 결과를 넣을 테이블은 이미 존재하는 테이블이어야 한다. OUTPUT 결과를 INTO로 테이블에 넣으면 OUTPUT 결과는 나오지 않고, INTO를 사용하지 않으면 OUTPUT의 결과가 출력된다. 즉, OUTPUT을 사용하면 트리거(Trigger) 없이도 데이터의 변경 사항을 기록할 수 있다.

아래 쿼리는 TABLE_A에 데이터를 넣으면 변경된 값을 LOG_TABLE에 추가하는 쿼리로, 변경 사항이 결과로 출력되지 않고 LOG_TABLE에 저장된다. LOG_TABLE은 이미 존재하는 테이블이어야 하므로 미리 테이블을 만들어 놓아야 한다.

INSERT 
    INTO TABLE_A (name, score) 
    OUTPUT inserted.* INTO LOG_TABLE
    VALUES ('John', 97)

APPLY

테이블에서 얻은 행에 대해 테이블 반환 함수나 하위 쿼리를 반복해서 호출할 수 있다. 즉, 행 마다 테이블 반환 함수 또는 하위 쿼리를 적용한다는 의미이다.

CROSS APPLY

테이블 반환 함수 또는 하위쿼리의 결과가 있는 행만 출력한다. (=INNER JOIN)

OUTER APPLY

테이블 반환 함수 또는 하위쿼리의 결과가 없는 행도 모두 출력한다. (=LEFT JOIN)

장점

JOIN문과 다르게 오른쪽 테이블이 왼쪽 테이블의 열을 참조할 수 있다.
NL Join 형태로 동작하기 때문에 아래 예제에서 볼 수 있듯, TOP N문을 사용하여 저장된 데이터량에 상관없이 늘 동일한 비용이 들어간다.
NL Join에 대해 알고 싶다면 여기에 정리해 놓았으니 참고하길 바란다.

단점

NL Join 형태로 동작하기 때문에 대량 데이터 처리 시 비용이 높다.
Join으로 처리가 가능한 경우는 굳이 APPLY 사용을 추천하지 않고, 반드시 필요한 경우에만 제한적으로 사용하기를 권장한다.

사용 예시

어떤 글에 대한 정보를 가진 Article 테이블과 글에 달린 댓글에 대한 Article_comment 테이블이 있을 때, 어떤 글을 comment가 가장 많은 순으로 정렬해서 3개만 보여주는 쿼리는 CROSS APPLY를 사용하면 INNER JOIN을 사용했을 때 보다 쿼리 길이도 짧아지고 빠른 성능을 낼 수 있다.

두 테이블 구조는 다음과 같다. Article 테이블은 articleNo 인덱스가 있고, Article_comment 테이블은 articleNo, commentNo 인덱스가 있다.

CREATE TABLE Article (
           articleNo  int IDENTITY (1,1),
           title      varchar(1000),
           contents   varchar(1000)
)

CREATE TABLE Article_comment (
           articleNo      int NOT NULL,
           commentNo      int IDENTITY(1,1),
           comments       varchar(1000)
)

CROSS APPLY 구문

-- CROSS APPLY
SELECT a.articleNo, a.title, b.commentNo, b.comments
FROM Article a
CROSS APPLY
	( SELECT TOP 3 b.*
		FROM Article_comment b
		WHERE b.articleNo = a.articleNo
		ORDER BY b.commentNo DESC ) b
WHERE a.articleNo < 3

INNER JOIN 구문

-- INNER JOIN
SELECT articleNo, title, commentNo, comments
FROM(
	SELECT a.articleNo, a.title, b.commentNo, b.comments, RANK() OVER(PARTITION BY a.articleNo ORDER BY commentNo DESC) rownum
	FROM Article a
	INNER JOIN(
		 SELECT * FROM Article_comment
	) b
	ON a.articleNo = b.articleNo
) o
WHERE rownum <= 3 AND articleNo < 3
ORDER BY articleNo, rownum