프로그래머라면 다음과 같은 코드를 만들어야한다."Clean code that works!"TDD(Test Driven Development)는 이것을 추구하는 가장 현실적인 방법이다.수많은 하드웨어와 소프트웨어, 언어와 개발방법론, 프레임워크 등 끊임없이 쏟아져 나오는 IT업계의 신기술은 이 시대의 프로그래머에게 마냥 좋은 소식만은 아닌 것 같다. 프로그래머란 변화를 수용하지 않고는 가까운 미래마저 보장받기 어려운 직업이기 때문이다. 항상 새로운 것을 배우고 개척해야만 뒤쳐지지 않을 것이라는 부담이 우리를 억누르고 있고, 또한 일정한 나이가 지나면 지금껏 쌓아온 지식과 경험이 대부분 쓸모없는 것이 되어 버릴 것이라는 불안감이 늘 함께한다. 필자의 주관적인 느낌이지만, 여러분이 프로그래머라면 공감하는 부분..

Overview프로그램 소스의 가독성을 위해 이름 규칙은 중요하다. 자바언어에서 사용되는 이름들은 의미있고 모호하지 않는 이름을 사용하여야 한다. * 카페에 질문시 소스를 첨부하는 경우 이런 명명규칙도 지켜지지 않은 경우가 많다. 난 이런 소스를 "쓰레기"라 부른다. 그리고 분석이 불가능하기에 답변할 가치도 없다고 느낀다. ....결국은 혼자서 짜증을 내며 답변을 하게 되지만 --;1. 클래스 이름클래스 이름은 명사를 사용한다. 첫번째 단어의 첫글자는 대문자로 시작하고, 두단어이상의 명사가 사용되는 경우는 읽기 쉽도록 두번째 단어의 첫글자를 대문자로 사용하는 카멜표현식을 사용한다.public class String{...}public class ApplicationContext{...}2. 인터페이스 이..

- Activity 가 stop 된 상태에서는 WindowManager 에서 detach 된 상태.- system 이 메모리가 없어서 process를 죽일 때, onPause() 는 반드시 불리지만, onStop() 이나 onDestory() 는 불린다는 보장이 없다. 따라서 onPause()에서 isFinish() 를 통해 해당 앱이 실제 종료되는건지, 잠시 pause 되는건지, 확인해주는 작업이 필요할 수 있다.- onSaveInstanceState() 는 activity 종료전에 반드시 불리지 않을 수도 있다. 예를 들어 유저가 Back button 을 눌러서 나갈 때에는 상태유지가 필요가 없다. System 이 이 녀석을 부를때는 onStop() 전이나, onPause() 전에 부른다. 어떤 경우..

ART, Android Runtime from Kitkat( 4.4 )기존의 안드로이드에서는 DEX file 을 Dalvik machine 위에 올리는 방식이었는데,Kitkat ( 4.4 ) 부터는 ART machine 위에서 OAT file 을 돌리는 것이 가능해졌다.기존의 dex 파일을 dex2oat 라는 converter 를 이용해서 converting 하여 생성하고 run 한다.Dalvik 은 앱 코드를 네이티브 기계어 코드로 변환한다.사용자가 앱을 실행할 때마다 이 변환 절차가 필요한데 이를 JIT( just-in-time ) 컴파일이라고 한다.이 방식은 다양한 하드웨어나 아키텍쳐에서 실행할 수 있는 장점이 있지만,이 과정이 성능과 배터리에 나쁜 영향을 준다.ART 는 Android RunTim..

ContentProvider 가 뭐하는 거야?ContentProvider 는 Database를 정해진 Interface 로 외부 package 에 노출하는 방법입니다.즉, 한 Application 에서 관리하는 Database 를 다른 Application 에서 사용할 수 있도록 하는 방법이죠.Interface도 제공하기 때문에 외부 Application 에서 쉽게 사용할 수 있습니다. ( 물론 제한적인 부분도 있지요. )URIContentProvider 에 접근하기 위해서는 URI 를 사용합니다.format) content://authority/path/idcontent:// : provider 접근임을 명시하는 것으로 반드시 들어가야 함.authority : 접근하는 provider 를 명시하는 것으..

다음의 디자인 issue들은 사용자에게 문제를 야기시킬 수 있다. 1. 다른 어플리케이션이나 다이얼로그의 예상치 못한 타이밍의 팝업. 2. 계획되지 않은 상호작용 3. 데이터의 부주의한 손실 4. 의도되지 않은 멈춤 무결성을 위한 디자인 고려사항. 다이얼로그 팝업을 피하라. 일반적인 무결성 문제는 서비스 또는 브로드캐스트 리시버 등이 어떤 이벤트에 응답하여 다이얼로그를 팝업할 때 발생합니다.이것은 실제 디바이스 상에서 다른 어플리케이션이 많이 설치되어 있는 환경에서 자주 발생합니다.다이얼로그를 띄우는 시점에서 focus를 가지지 못하는 상황도 발생하곤 하죠.따라서 무언가를 알리기 위해서는 다이얼로그보다는 최대한 Notification을 사용하는 것이 좋습니다. (focus 방해 최소화하기 위해서) Act..