분류 전체보기

SharedPreferences의 한계점 Datastore가 나오기 전까지 안드로이드에서는 가벼운 데이터를 key-value 쌍으로 저장하기 위해 SharedPreferences를 사용했다. SharedPreference는 다양한 한계점이 있었다. SharedPreference는 비동기 작업을 제대로 해주지 않으면 ANR을 발생시킬 수 있으며, 오류가 생길 시 확인이 불가능했으며, 런타임에 예외가 생기면 런타임 애러가 발생해 잘못 사용하면 앱이 강제 종료될 수도 있었다. 또한 strong consistency가 보장되는 api가 없어 다중 스레드 환경에서 다른 결과값이 생길 수 있었다. 이러한 문제 외에도 type safety가 보장되지 않아 어떤 데이터가 저장되고 추출되는지를 일일히 데이터로 type ..

JVM에서 Garbage Collection이 중요한 이유 JVM은 자동으로 메모리를 관리해주기 때문에 GC(Garbage Collection)가 성능상 매우 중요하다. 모든 머신들이 그렇듯 JVM 또한 사용되지 않는 객체들이 제때 메모리에서 정리되지 못하고 한 번에 정리되거나 한다면 앱이 버벅거리거나, 제대로 동작하지 않을 수 있다. 또한 만약 사용되지 않는 객체가 GC의 대상이 되지 못한다면 Out of Memory Error 로 인해 앱이 강제 종료될 수도 있다. 여기서 말하는 Memory는 Heap 영역이다. Stack 영역은 포인터만 저장하는 비교적으로 가벼운 저장 공간이기 때문에 성능 상 큰 이슈가 발생할 가능성이 적다. GC가 일어나는 방식과 Heap Memory JVM은 Heap 메모리 관..

GraphQL의 fragment 앞선 글들에서 사용되었던 방법으로는 GraphQL의 특정 블록들을 여러 번 재사용해야 하는 블록의 경우 매번 중복해서 써야한다. 예를 들어 다음 두개 Query들이 있다고 해보자. query QueryFilm1 { film(filmID: 1) { title director producers } } query QueryFilm2 { film(filmID: 2) { title director producers } } 위 쿼리들에서는 title, director, producers들이 중복해서 사용된다. 이 필드들을 하나로 묶어 하나의 필드처럼 쓸 수 있다면 중복을 줄일 수 있을 것이다. GraphQL의 fragment가 바로 이 역할을 한다. GraphQL의 fragment는..

지시문이 필요한 이유 앞서 Alias를 사용해 필드명을 변경시키는 방법을 살펴봤다. 하지만 Alias를 사용해 필드명을 변경시키는 것은 데이터를 처리하는데 충분하지 않다. 예를 들어 Kotlin의 sealed class를 상속하는 data class를 사용해 데이터를 받을 경우 특정 데이터를 받을 경우 특정 데이터가 포함되거나 되지 않는 경우를 처리하기 어렵기 때문이다. 예를 들어 다음과 같은 영화 정보를 담는 FilmInfo sealed class가 있다고 해보자. sealed class FilmInfo(){ data class BasicFilmInfo(val filmTitle : String) : FilmInfo() data class FilmInfoWithDirector(val filmTitle :..

서버 통신 시 Alias의 필요성 안드로이드 개발을 할 때 우리가 Retrofit + Gson(혹은 Moshi) 라이브러리를 사용해 서버와 통신할 때 서버의 이름이 우리가 쓰는 클래스의 필드명과 일치하지 않을 경우가 있다. 이런 경우 데이터 처리를 위해 @SerializedName("[서버의 필드명]")을 사용해 서버의 필드명을 클래스의 필드명에 대입시킨다. 이렇게 하는 이유는 서버의 필드명이 클라이언트의 필드명과 일치하지 않을 경우 데이터 처리가 복잡해지기 때문이다. 서버의 필드명이 강제되는 REST API와는 달리 GraphQL은 우리가 쿼리를 만들어 낼 수 있어 쿼리단에서 데이터의 필드명 자체를 변경할 수 있다. 따라서 아예 서버에서 데이터를 받아온 후 필드명을 바꿀 필요 없이 데이터를 받아올 때 ..