The Hitchhiker's Guide to The Galaxy

NavigationView을 사용할 때, 앱이 구동되는 내내 어디든지 혹은 두 곳(Activity) 이상에서 NavigationView를 사용(보이게)하려면 

크게 두 가지 방법이 있을 것이다.
하나는 최상단의 Layout을 L, NavigationView를 N, Fragment를 F, 아무것도 아닌 것을 X라고 했을 때에,
LFNL 처럼 되어서 LXNL이란 형식은 유지된 채, F부분만 다른 걸로 계속 replace를 해주는 방법.
이렇게 하면, 중복되는 부분(NavigationView)은 계속 재활용할 수 있게 된다.

다른 하나는 매 Layout마다 NavigationView를 만들어 작성하는 것이다.
이렇게 되면, NavigationView를 Layout 마다 만들어야 하므로 여러개 사용이 된다.
activity_main: LXNL
activity_setting: LXNL
...
와 같은 형태로 말이다.
이렇게 되면 XML에서 뿐만 아니라 Java에서도 코드가 계속 중복되게 된다.

결론적으로 redundant를 피하므로 전자가 낫다.

즉,
하나의 Layout에서 Fragment란 View를 사용하여 그 부분만 바뀌게끔 하면 된다.
(단, NavigationView이 접혔을 때에 기본으로 보여지는 각각에 화면에 맞는 여러개의 Layout은 원래 필요하다.
파일명은 fragment_xxx식으로 하나, 내용은 LFNL에서, F부분만 여러 파일로 나누므로 NavigationView나 기타 Fragment가 아닌 부분을 작성하지 않으므로 activity_xxx와 좀 살짝 다르다.)

MainActivity.java와 AFragment, BFragment가 있다고 하자.
AB화면에서도 NavigationView를 보여주고 싶으면 이 두 Fragment를 하나의 Activity로 묶어주고, 그 Activity가 NavigationView를 가지고 있는 상태에서 AFragment, BFragment로만 Fragment부분을 replace해주면 된다.

*Fragment는 android.support.v4.app.Fragment이다.

이런식으로 해주면 되겠다.
*Fragment는 onCreate, onCreateView, onActivityCreated 이렇게 기본적으로 세가지 중요한 메소드를 오버라이드해서 사용하게 된다.

MainActivity는 다음과 같이 하면 된다.

Fragment의 레이아웃은

이런식으로 내부에 원하는 데코레이션대로 만들면 된다.

Body로 data를 보내게 되면 깨지지 않는데에 반하여 URL로 data를 보내는 Query방식이면 보통 URL주소창에서 한글이 깨져 보이는 식으로 깨지게 된다. 예를들어, '@'는 '%40'처럼 보이는데, 이를 해결하기 위해서는 decodeURI()을 사용하면 해결할 수 있다. 그 반대는 encodeURI()이다.

* URL이 아니라 URI이다.

HUAWEI 폰에서만 나오는 에러로 폰 자체에서 발생하는 에러이기 때문에 어떻게 할 수가 없다.
히지만, 디버깅할 때 1초정도마다 계속 뜨는 것은 되게 annoying하다.

다른 폰이 있다면, 그것을 사용하는 게 낫겠지만, 그렇지 않다면 지금 상태에서 무엇을 해야할 것이다.

해결방법은 없으나 완화방법은 반복되는 로그들을 숨기는 것이다.

그럼 전부 사라지며 이후 나오는 에러도 눈에 보이지 않는다.

마음이 상쾌함...

혼자 Android 앱을 개발하는 사람들이 많다. 하지만, 세금문제라든지 관리 등 여러가지 검색을해도 잘 알지 못하는 것들이 많고 경험 공유나 노하우 같은 것도 부족하다. 하지만 다행히도 1인 개발자들(비 1인 개발자들에게도)에게 도움이 될만한 행사가 있다.

바로 여기...

https://ted.event-us.kr

하지만 행사가 흔하지 않다. 두 달에 한 번 꼴 하는 거 같고, 참가비는 아쉽게도  25000~30000원 정도로 유료다.  그렇지만 내용을 보면 그만한 값어치를 하고 오히려 값어치를 할 수 있을 것 같다.(아직 참관을 해보지 못해서 그냥 예상일뿐)

이런 곳에서 좋은 이야기를 서로 나누면 좋겠지만, '지식'이라기보다도 먹고 살기 위한 '노하우'이므로 이런 류의 강의는 자기 그릇을 챙기고 나서 남들이 알아도 상관없는 것들을 알려주는 것들이 대부분이라, 청자들의 시원한 곳을 긁어주지 못한 경우들이 어떤지는 모르겠지만, 주제만을 본다면, 낚시가 아니길 바란다.

기타, 개인앱개발 관련 정책이나 세금, 기타 정보가 궁금하시면 이 오픈채팅방에서 문의하시면 답변받을 수 있을 거다.
https://open.kakao.com/o/gzIgCbk 
참여코드: chope

모두 상업용도로 사용가능하다. 단, 폰트 자체만을 판매하는 것은 안 된다.

구글폰트(https://fonts.google.com)

네이버 나눔글꼴 - http://hangeul.naver.com/2017/nanum

라이센스(https://help.naver.com/support/contents/contents.nhn?serviceNo=1074&categoryNo=3497)

Stackoverflow 
gson type
!!! FAILED BINDER TRANSACTION !!!

등이 에러가 났다. 3일 동안 앱 진행을 못했다. 결국 해냈다. 정확한 원인은 모르겠지만, 다음과 같이 하면된다.

이전엔 이렇게 Gson을 선언 했었다.

여기에 excludeFieldsWithoutExposeAnnotation()를 추가해준다.

그리고 사용되는 파라미터들에 @Expose 어노테이션을 붙여준다.

일단, SearchItem은 이렇게 하지 않아도 되는데, UserItem에서 문제가 발생했기 때문에 다른 Item들도 바꿔줘야한다. UserItem에서 문제가 발생한 이유는 서버와 통신을 할 때 사용되지 않는 변수들이 있어서 그런 것 같다.

참고: https://github.com/Raizlabs/DBFlow/issues/121

1. 일반적으로 기본값은 일단, string-array의 첫번째 아이템으로 주면 된다.

2. 하지만, 0번째 아이템이 아닌 아이템을 default로 설정해줘야할 때가 있다. 그럴 때, 아이템 번호로 한다면 헷갈리므로 String으로 정하는 게 확실할 거다.

순서는 다음과 같다

default로 줄 item이름을 검색한다 > item의 position을 가져온다 > 해당 position을 default로 세팅한다.

일단 Context가 뭔가? 네이버 사전에 의하면 '맥락, 정황' 뭐 이런 뜻이다. (미국 발음으론 [칸텍스트], 영국식은 [컨텍스트])

Spring Framework를 배울 때도, getContextPath()라는 게 있었다. Spring에선 기본 주소를 의미했다.
이를 테면, www.naver.com 이 기본 주소고 www.naver.com/a/bc/d 뭐 이런식으로 뭐가 붙게 되면 기본 주소가 아니다.
프로젝트 폴더 안의 특정 위치에서 가져 오려면 절대 경로가 필요하고 그때 필요했던 것이 getContextPath()였다.
이를 테면,
-project
  -css
  -js
  -img
  -view
이런식으로 있다고 치자면, 현재의 위치는 view안의 jsp파일들이고, 그것을 기준으로 하게 되면 img파일이나 다른 리소스를 찾기가 힘들다. 그래서 getContextPath()/img 와 같은 방식으로 어디서나 현재의 경로에 상관없이 절대경로로 이미지 파일을 가져올 수 있었다.

그렇다면, Android Studio에서의 Context는 무엇일까?

한글 자료에서는 뭔가 명쾌한 해답을 얻지 못하고 오히려 헷갈리기에 영어 자료를 찾아보았다.

공식 문서에서의 설명은 다음과 같다.

즉, 앱에 대한 전반적인 정보를 가지고 있는 인터페이스(Java의 인터페이스가 아니라, 어떠한 두 가지를 연결해주는 역할을 뜻하는 듯하다. 안드로이드 OS와 Java를 뜻하는 거 같다.)이며 안드로이드 시스템으로부터 제공되는 추상클래스로 Activity를 띄워준다던가, Broadcast(안드로이드 4대요소)를 한다던가, Intent를 받는다 던가와 같은 것처럼 앱의 자원과 클래스에 접근을 하도록해준다. 

다음은 Stack Overflow의 내용이다.

여기서 context에 대해 물어봤는데 'It's context of ...'라는 식으로 설명하다니... '그래서 context가 뭔데?'란 생각이 잠시 들었지만, information이라고 해석하면 될 거 같다.

즉, 앱이나 객체의 현재 상태 정보인 셈.

그럼 왜 Context가 필요할까? (정확한 자료는 못 찾았지만, 사람들의 생각을 정리해보았다.)

1. 보안 문제
Context는 기억 장치의 입출력, 네트워크 자원과 그래픽에 대해 관장할 수 있다. 그러므로 context만 알게 되면 보안상에 문제가 발생될 수 있다. 자신의 앱에 접근하려는 앱의 Context를 알면 차단할 수도 있을 것.

2. 자바와 안드로이드의 연결 고리 역할
Device Location이나, 사진 찍기, 백그라운드 서비스를 돌리기 위해서 자바와 안드로이드 OS간에 연결 역할을 해주는 게 필요한 데, 이것이 context의 역할임.

그럼, 언제 사용할까??
위에서도 살짝 언급은 했지만, 이곳(Stack Overflow)을 통하면 다음과 같다고 설명한다.
- Loading a resource.
- Launching a new activity.
- Creating views.
- obtaining system service.

추가적으로 위에서 설명했듯이 다른 앱이나 자원(Device Location, Camera, Background Service)에 접근이 가능하다. 

Context를 얻는 종류는 어떻게 되며 언제 사용 될까?

일단, Context 클래스를 살펴보자. (클릭)

Document에서의 정보를 빌려본다면

상수

상수만 봐도 대략적으로 어떤 느낌인지 온다.

context를 얻는 방법은 다음과 같다고 한다.
getApplicationContext()
getContext()
getBaseContext() 
this (Application, Activity, Service and IntentService와 같은 Context를 상속 받은 클래스는 자기 자신을 지칭하여 context사용 가능).

여기서 this와 getContext()는 동일하다고 한다.

그럼 그들의 차이를 알기 위해 이번엔 메소드에 대해 살펴보자.

메소드를 살펴보니 대략, 정말, System, 패키지에 대한 내용부터 파일, 데이터베이스(SQLite를 의미하는 듯), sharedPreference, Service, Broadcat, Activity, Foreground, Intent 등와 같은 내용들이 들어 있었다.

대충, 어떤 느낌인지는 알겠지만, sharedPreference빼고는 그것들을 사용한 적이 없어서 잘 모르겠다.

그래. 대충 요런 놈이구나.

엥? 근데 getContext(), getApplicationContext(), getBaseContext()가 보이지 않는다. 왜 일까?
당연하다. 이게 Context자체니까. 그 메소드들을 사용하면 Context 객체를 얻는 거다.

getContext(), getApplicationContext(), getBaseContext()

그럼 이 세놈들은 어디에 속해있을까?

생각을 해보니, 개발을 할 때, 평소에 이 셋 중에 하나만 자동완성에 나와서 그냥 생각없이 사용했던 거 같다.
(개발을 하면서 잉? 왜 이번엔 getApplicationContext()지? 뭐, 같은 context라고 써져있으니 비슷한 놈이 겠거니 하고 썼었다.)

직접 확인해본 결과,

Activity - getApplicationContext(), getBaseContext()
Fragment, Adapter, View - getContext()

이렇게 나왔다. (아직 초보라서 다른 클래스는 모르겠다.)

왜 이 넷은 이렇게 다를까?
일단, 내가 알고 있는 한, Activity는 Fragment, View, Adapter를 포함할 수 있는(상위) 개념이다.
(그렇다고, 상속의 의미인 ancestor이란 의미는 아니고, Activity가 있어야 그 안에 구성(작업)할 수 있다는 것이다.) 

이 네 가지 클래스에 대해서 공식문서를 살펴보자.
Activity
getContext(), getApplicationContext(), getBaseContext()는 찾을 수 없었다.

그래서 Android Studio에서 분석해보기로 했다. 메소드를 생성한 후에 Ctrl를 누른 후 메소드를 클릭하는 식으로 역추적했다.

이런식으로 되어있었다.

ContextWrapper에 자리잡고 있었던 것. 그럼? ContextWrapper를 공식문서에서 찾아보자.

getApplicationContext()와 getBaseContext()가 있었다. 그 둘의 내용을 찾아보자면,

자세하게는...

getApplicationContext()는 이렇게 장황하게 설명되어있는 반면, getBaseContext()는

이렇게 밖에 써져있지 않았다.

이제 Stack Overflow에게 물어봐야지.

그러니까,
getContext()는 현재 실행된 View(보통(?) 활성화된 Activity의 View)의 Context를 반환한다.

getApplicationContext()는 앱에 대한 모든 것을 가진 context를 반환(모든 엑티비티). 하나의 Activity내에서 가 아니라, 앱의 Lifecycle에 context가 묶여 있는 경우, getApplicationContext()로 해야한다.

getBaseContext()는 다른 context안에서 또 다른 context에 접근을 하기 위해 ContextWrapper를 사용한다. 이를테면, ContextWrapper의 안쪽에서 참조될 Context는 getBaseContext()를 통해 접근된다. (말이 어렵네)

Acitivy는 getApplicationContext()를 가지고 있지 않았는데, 무슨 소리지???
하여간, ContextWrapper가 getApplicationContext()와 getBaseContext()를 가지고 있고, 쓰임새가 위와 같이 서로 다르다는 것.

뭐... 그렇단다. 
Fragment, Adapter, View를 역추적해서 찾아봤는데, 다음과 같이 생겼다.

따로 굳이 찾아볼 필요도 없을 것 같다. 그냥 현재의 Activity의 Context를 반환한다는 것이니까.

그리고,

결론을 지을만한(?) 자료를 찾았다.

출처 : http://www.kmshack.kr/2013/10/android-context-what-context/#comment-1195

이거에 맞춰서 조심스레 작업해야겠다.

결론적으로, 대한민국을 안드로이드 시스템, 앱을 하나의 종합 대학교라고 친다면, 액티비티는 단과 대학이고, 
ApplicationContext는 종합 대학교에 대한 정보.
Context는 단과 대학에 대한 정보.
BaseContext는 다른 대학에 갈 때 또 다른 대학에 대한 정보(?) 뭐 이런 느낌인 거 같다.

끝.