KEEP GOING!

안드로이드 프로젝트를 하면서 API 통신이 필요할 때 일반적으로 Retrofit 라이브러리를 사용하는데, 그 이유는 Retrofit의 응답 속도가 빠르고 구현 방법이 간단하기 때문이다. 이번 포스팅에서는 이렇게 많이 사용되는 Retrofit의 장점과 사용법에 대해 알아보려고 한다. Retrofit2 특징 Retrofit2는 Square사에서 만든 네트워킹 라이브러리로, 오래 전에 Retrofit이라는 라이브러리를 출시한 뒤 기존 라이브러리의 문제점을 개선해 현재의 Retrofit2가 만들어졌다. Retrofit2는 Retrofit의 업그레이드 된 버전이기 때문에 일반적으로 1과 2를 구분짓지 않고 Retrofit이라고 통용된다. 그렇기 때문에 포스팅 중에 Retrofit이라고 하는 것은 모두 Retrof..

프로그래머스 3xn 타일링의 문제 설명은 여기서 볼 수 있고 풀어볼 수도 있다. 이전에 2xn 타일링 문제를 풀어봤기 때문에 3n 타일링 문제에 도전해보았다. 원리는 비슷하고 조금 응용하면 되겠지.. 하고 쉽게 생각했지만 생각보다 그 응용이 쉽지 않았다.. 3xn 타일링도 2xn 타일링과 마찬가지로 DP로 풀 수 있는 문제였다. 문제 풀이를 시작하면, n이 홀수일 경우에는 크기가 2인 타일을 채울 수 없기 때문에 n이 짝수인 경우만 생각한다. 먼저 n=2인 경우 3가지 경우의 타일 모양이 나오고, 그 다음 단계로 진행할 때마다 아래와 같이 매번 2개씩 새로운 모양의 타일이 생긴다. f(n) = 가로의 길이가 n인 타일을 채울 수 있는 경우의 수 라고 하자. n = 4일 때는 이전 단계(n=2)에서 2칸이..

프로그래머스 카드게임은 DP로 분류된 문제로, 설명은 여기서 볼 수 있고 풀어볼 수도 있다. DP를 풀어본지 오래 돼서 풀어보려고 했으나 아이디어가 떠오르지 않아서 정답을 올려놓은 블로그 글을 참고했다. 그랬더니 DP를 푸는 방법에 대해 설명하는걸 보고 다시 DP에 공부했던 기억이 새록새록 떠올랐다. 다시 알게 된 김에 아래 3가지 방법 모두 구현해 보았다. Top-Down: 큰 문제들을 풀 때 작은 문제가 아직 풀리지 않았다면 작은 문제를 먼저 푸는 방식 ex) 재귀함수, Memoization Bottom-Up: 작은 문제부터 차근차근 풀어나가는 방식 이 문제의 기본 아이디어는 다음과 같다. i) 왼쪽 카드가 오른쪽 카드보다 크면, 오른쪽 카드를 버리고 점수를 높인다. ii) 그렇지 않으면, 왼쪽만 버..

이번 포스팅에서는 앱 개발을 하면서 한 번씩은 꼭 필요한 properties에서 값을 읽어오는 방법을 정리하려고 한다. 사실 이 기능이 필요할 때 종종 방법을 잊어버리기 때문에 검색하지 않고 한 번에 찾기 위함이다.. 개발을 하면서 API key와 같이 외부로 유출되면 안되는 정보를 코드에 넣어야 하는 경우가 있다. 특히 이런 코드를 GitHub에 올리려고 하면 곤란해지는데 이런 경우에는 그 정보를 직접 코드에 넣는것 보다는 따로 .properties 파일로 빼서 사용하면 좋다. 예를 들어 apikey.properties 라는 파일을 만들어서 프로젝트 루트 디렉토리에 넣어두고 .gitignore 파일에 추가하면 key 값이 외부에 노출될 걱정도 없고, key 값들을 하나의 파일에서 관리할 수 있어 좋다...

이번 포스팅에서는 알고리즘을 공부하면서 출제 빈도가 높은 BFS와 DFS 문제를 위한 기본 구현을 정리하려고 한다. BFS와 DFS는 이름에서부터 알 수 있듯 그래프 탐색 알고리즘이다. 탐색 알고리즘은 그래프 전체를 순회해야 하는 고비용 연산으로 효율적으로 코드를 짜는 것이 중요하다. BFS와 DFS 모두 시간 복잡도는 동일하다. 그래프는 인접 행렬과 인접 리스트 자료구조를 이용해 표현이 가능한데, 어떤 자료구조를 사용하느냐에 따라 시간 복잡도가 아래와 같이 달라진다. (V = Vertex, E = Edge) 인접 행렬: O(V^2) 인접 리스트: O(V+E) 최소 비용 문제나 이동에 가중치가 없는 미로탐색 문제는 BFS로 푸는 것이 유리하고, 이동에 제약이 있거나 이동마다 가중치가 붙는 미로탐색 문제는..

이전 2개의 포스팅에서 Covariance/Contravariance와 PECS 원칙에 대해 다루었다. 이번 포스팅에서는 마지막으로 Java와 Kotlin의 Covariance의 차이를 알아보려고 한다. 그러기 위해 먼저 Kotlin의 Collection과 MutableCollection을 알아보자. Kotlin에서는 List, Set, Map과 같이 앞에 “Mutable”로 시작하지 않는 Collection은 immutable하다. 즉, read-only라는 의미이다. 그렇기 때문에 각 인터페이스를 확인해 보면 immutable 자료형은 제네릭 타입 파라미터에 out 키워드가 붙어있는 것을 확인할 수 있다. public interface Collection : Iterable public interfa..

이전 포스팅에서 Covariance와 Contravariance에 대해 알아보았다. 이 포스팅을 읽기 전에 [Kotlin] Covariance & Contravariance을 먼저 보고 오면 이 글을 이해하는 데 도움이 될 것이다. 이번에는 이전 포스팅에서 언급했던 PECS 원칙과 read-only & write-only 제한에 대해 자세히 알아보자. 여기서 가장 중요한 부분은 자식 객체는 부모 객체로 바로 대입(치환, 변환)할 수 있지만, 부모 객체는 자식 객체로 바로 대입(치환, 변환)할 수 없다는 것이다. 바로 대입한다의 의미는 다음과 같다. Child 클래스란 Parent 클래스에서 더 나아가 구체화 되었다고 볼 수 있다. 그렇기 때문에 Parent 클래스에 있는 변수나 메서드는 Child 클래스..

Generic하면 빠질 수 없는게 Covariance와 Contravariance의 개념이다. 처음 이 개념을 Java의 Generic을 공부하면서 접했었는데, 그 때는 분명 다 이해했다고 생각하고 넘어갔지만 Kotlin을 공부하면서 다시 보니 헷갈리기 시작했다. 그래서 앞으로 몇 개의 포스팅에 걸쳐서 Covariance와 Contravariance의 개념에 대해 다시 공부해서 이해한 내용을 정리해 보려고 한다. Covariance는 간단하게 “a more derived type”이라고 표현하고, Contravariance는 “a less derived type”이라고 표현할 수 있다. more derived type이란, Parent Class와 Child Class가 있을 때 Child Class를 ..