Dean83

보통 API 통신을 할떄 json 형식을 많이 쓰고, 클래스에 serialize를 이용하여 통신을 한다. 하지만, JsonObject를 생성하여 바로바로 key와 value를 넣고 통신해야 할 때도 있다. 그 경우는, - 자식-자식-자식... 이렇게 depth가 많아, 클래스를 만드는게 배보다 배꼽이 큰 경우 - 통신 횟수가 몇번 되지 않거나 중요도가 낮아 클래스를 만들기 애매한 경우 - 보내야 하는 내용들이 유동적으로 자주 바뀌는 경우 등등. 나의 경우 1, 3번에 해당이 되었고, 따라서 JSONObject 를 통해 바로 key value를 생성하였다. 그러나 통신시 통신 오류 문제가 발생했고, 로그를 확인해 보니 NameValuePairs 라는 항목이 json 에 붙어 있었다. 검색을 해보니, org..

화면을 구성하다 보면, 가끔 부모부의 영역을 넘어 자식뷰를 그려야 할 때가 있다. 즉, 부모뷰의 너비, 높이가 100 이고, 자식뷰가 200일 경우, 원래대로라면 자식뷰도 100,100 씩만 그리고 나머지 부분은 보이지 않는다. 자식뷰가 부모뷰의 100,100 영역을 벗어나 모두 그리려면, 부모layout에 clipchildren = false 로 설정하면 된다. 보통은, RecyclerView 에서도 사용하고 싶을때가 많을것이다. RecyclerView 의 item layout 에도 clipchildren 을 설정해야 하지만, RecyclerView 자체에도 설정을 해 주어야 한다. *clipchildren 은 만능이 아니다. 결국은 최 상단 레이아웃의 Canvas 영역을 벗어나서 그릴 수는 없다. 즉..

UseCase 라고 하면, 소프트웨어 공학에서 주로 사용되던 개념이다. FlowChart 나 Class Diagram 처럼 설계를 할때 사용되던 한 타입이었다. 주로 기능의 흐름을 표현하는 용도로 많이 사용되었다. 예를들면 사용자가 A 라는 동작을 했을때 처리, B 라는 동작을 했을때 처리 등... 안드로이드에도 UseCase 를 코드에 접목 시켜 처리한다는 글을 봤다. 해당 내용을 정리하고자 작성한다. 안드로이드에서 UseCase도 기본 맥락은 동일하다. 특정 요청이나 동작 별로 UseCase 클래스를 생성하고, 처리를 하는 방법이다. 예를들자면 유저 정보를 조회하는 요청에 대하여 UseCase를 생성하고, 내부에 유저 정보를 조회하여 리턴하는 코드를 작성한다. 사용처에서는 UseCase 함수를 호출하..

안드로이드 어플리케이션의 형태를 단순화 하여 보면, 이렇게 나눌 수 있다. '서버와 통신하여 결과값을 화면에 보여주는 형태' 좀 더 쪼개자면, - 화면부 - 통신부 가 있겠다. 화면부를 좀 더 쪼개자면, - UI를 표현하는 부분 - 로직에 따라 UI를 제어 하는 부분 으로 나눌 수 있겠다. 통신부분을 나누자면, - Request, Response 형태를 담는 부분 - 실제 통신 부분 이 있겠다. 위에서 맨 처음에 작성한 한줄짜리 문장을 다시 생각해보면, '결과값을 화면에 보여주는' 것이 중요하다. 이 말은, 화면부와 통신부가 연결이 되어야 한다는 뜻이 된다. 이를 구현하기 위해 여러 방법이 있겠다만, Repository 패턴을 기준으로 설명해 보려 한다. 이에 앞서 먼저 화면부를 보자. 1. UI 구성 ..

기기 설정값 등 특정 데이터를 로컬에 저장 - 불러오기 하고 싶을때 사용하는 기능. Unity에 비슷한 기능이 있었는데 기억이 안난다. bundle 처럼 사용하면 된다. val sharedPref : SharedPreferences = applicationContext.getSharedPreferences("이름", Context.MODE_PRIVATE) sharedPref.edit().putString(key, value).apply() 으로 저장하고, sharedPref.getString(key, defValue).toString() 으로 빼온다. int나 bool 값도 가능하다.

글을 작성하면서 틀릴 가능성이 매우 높다. 추후 수정 가능성 높음. 한가지 방법은 ktx를 이용한 방법이고, 한가지 방법은 koin 라이브러리를 이용한 방법이다. ktx를 이용한 방법이 보다 쉽게 생성할 수 있고, koin은 복잡하다. 단 koin의 경우 ViewModel 외에 Repository, Model 등도 관리하기 좋다. koin의 경우 DI 패턴을 이용한다. 1. KTX를 이용한 ViewModel 생성 - 종속성 추가 def archLifecycleVersion = '2.2.0' implementation "androidx.lifecycle:lifecycle-extensions:$archLifecycleVersion" kapt "androidx.lifecycle:lifecycle-compile..

계속해서 추가해갈 예정이다. ViewModel 생성법도 추후에 적을 예정이다. 1. Activity, Fragment 등 view 에 해당하는 context를 참조하지 말것 - 메모리 누수가 생긴다고 한다. - context가 필요한 경우, 만일 koin을 쓰고 있다면 생성자에 context를 추가하고, koin 에서 get()을 통해 념겨주기 또는, ViewModel Class 생성시 AndroidViewModel 을 상속받아 생성자에 포함된 application을 이용하자. 2. Fragment나 Activity를 ViewModel 에서 띄우지 말것. 한마디로 말해서, View 와 관련된 어떤것도 하지 말라는것이다. 요약하자면, 1. View 와 관련된 모든것 (UI 변경, Fragment나 Acti..

아직 모르는것이 많기 때문에 추후에 또 변경될 수 도 있다. 쓰지 말자 라고.. 지금껏 파악하기로는, 적극적으로 사용하는것을 권장한다. 일단 ViewModel 부터 정리하자면, 일반적으로 디자인패턴에서 말하는 ViewModel 과는 다르다. 물론 MVVM 패턴의 ViewModel을 내포할 수 있지만, 근본적으로는 다른 의미 이다. Livadata의 경우 C#의 Observable과 동일한 것으로 보이는데, 활용도가 완전히 다르다. 아무래도 안드로이드 특성이 윈도우와 다르다보니... C#에서는 한정적으로 사용하나, 안드로이드에선 여기저기 다 써도 무방해 보인다. (정확히 말하자면 C# 에서는 변수값이 변경되었을때 처리해야 할 일이 별로 없다. UI 정도..) 1. 안드로이드 에서의 ViewModel - 안..

C#에서의 MVVM 패턴은 사용성의 큰 필요성을 느끼지 못했다. MVVM을 쓰는 가장 큰 이유가 UI작업과 개발작업을 분리한다는 것이었는데, 한국은 보통 둘 다 개발자가 하므로... 분리 필요성을 느끼지 못했다. 그러나 안드로이드는 다르다. 안드로이드 개발하면서 느끼는 점은, C#이 얼마나 잘 만든 언어이고 시스템인지 뼈저리게 느끼고 있다. 안드로이드의 가장 큰 빌런은 리사이클러뷰. C#으로 따지면 리스트에 변수 연결할때 한줄이면 끝나는데, 이놈은 Adapter 클래스 만들고 ViewHolder 만들고, 필요에 따라 Decoration 클래스도 만들고...암튼 별짓거리를 다 한다;; 그러나 이것보다 가장 큰 문제점은!! 라이프사이클 정책에 따라서 Activity가 다시 생성될때 UI 상태등을 저장-복구 ..

Activity 에서 Fragment를 호출할때 인자값을 넘겨줘야 할 때가 있다. 왠만한 변수들은 put을 이용해 넘겨줄 수 있다. 그러나 data class 가 아닌, activity에 연결된 클래스 등을 넘겨줘야 할때도 있는데, 이 때는 put으로 넘겨주기가 힘들다. 또한 ArrayList 등을 넘길 때에도 Parcel을 이용하느냐, Serializable을 이용하느냐의 차이도 있는데, Serializable로 data class를 설정했을 경우에는 put으로 넘길때 오류가 생긴다. 이럴경우 보통 Fragment 생성자에 인자값을 넣어서 넘기는게 편하기 때문에 이렇게 구현하는 경우가 꽤 있었다. 문제는, activity가 재생성될때 - 가로모드에서 세로모드로 변경 등 - fragment 또한 재생성이..