본문 바로가기

전체 글

(47)
[Android] Fragment 생명주기(Life-Cycle) Activity 생명주기와 비교했을 때 생성시 onCreateView() -> onViewCreated() -> onViewStateRestored() 추가 파괴시 onSaveInstanceState() -> onDestroyView() 추가 onCreate() : Fragment만 CREATED 된 상황으로, FragmentManager에 추가되었을 때 호출된다 onCreate() 이전에 onAttach() 먼저 호출된다! 아직 Fragment View가 생성되지 않은 시점으로, Fragment의 View 관련 작업은 부적절 Bundle 타입으로 savedInstanceState 파라미터가 함께 제공된다 : onSaveInstanceState() 콜백 함수에 의해 저장된 Bundle 값 파라미터는 Fr..
[Android] Activity 생명주기(Life-Cycle) 생명주기(Life Cycle) : 말 그대로 탄생-죽음에 이르기까지의 과정을 안드로이드 앱에서 적용한다 - Activity, Fragment, Service 총 세 가지 종류의 Lifecycle이 있다 Activity Lifecycle (액티비티 생명주기) : 액티비티가 시작되고 완전히 종료되기까지의 생명주기, 그 액티비티의 상태가 계속해서 변화한다. ex ) 다른 액티비티에 의해 가려짐 / 전화가 걸려와 액티비티가 가려짐 Lifecycle Callback Method 안드로이드 프레임워크에서 제공하는 콜백 메소드 : 액티비티의 상태가 변할 때마다 특정한 동작을 수행하도록 한다 이 수명주기 콜백 메소드를 적절히 구현하면 다양한 문제를 예방하고 앱이 안정적으로 동작하게 할 수 있다 : 꼭 구현해야 하는 메..
[Android] 4대 컴포넌트와 Intent 4대 컴포넌트 안드로이드 앱은 4대 컴포넌트로 이루어져 있다 각 컴포넌트 별 공통적인 특징은 1. 각 컴포넌트들은 하나의 독립적인 형태로 존재한다. 2. 각 컴포넌트들은 고유의 기능을 수행한다. 3. 각 컴포넌트들은 인텐트를 통해 서로 상호작용한다. 1. Activity (액티비티) : 사용자가 애플리케이션과 상호작용하는 단일화면 모든 안드로이드 애플리케이션은 액티비티로 구성되어 있다 사용자와의 상호작용을 담당하는 인터페이스 안드로이드 애플리케이션은 반드시 하나 이상의 액티비티를 포함하고 있고, 액티비티는 생명주기(Life Cycle) 관련 메서드들을 재정의 하여 원하는 기능을 구현할 수 있다 - Intent를 통해 다른 애플리케이션의 액티비티 호출 가능 - 2개 이상의 액티비티를 동시에 표기할 수 없다..
[Kotlin] 필드와 변수, 데이터 타입, 늦은 초기화 필드와 변수 val은 불변 필드! 필드의 타입이 필드 뒤에 오고, 콜론(:)으로 구분한다 val name: String = "아린 Kim" 타입 추론으로 더 간단하게 구현하기 타입을 지정하면 코틀린이 추론한 타입과 내가 예상한 타입이 다른지 검사할 수 있기 때문에 타입을 지정하는 게 좋다. val name2 = "아린 Kim" var는 가변 필드! 코틀린은 초기화하지 않은 참조를 쓸 수 없게 막는다. 변수 선언 + 값 지정 으로 초기화 하기 var name3 = "아린 Kim" name3 = "김아린" 변수 선언만 하고 사용하기 var name4: String name4 = "김아린" var 사용은 최대한 자제하는 것이 좋다. 참조 대상이 불변이면 프로그램을 추론하기 쉽기 때문 데이터 타입 Double ..
코틀린(Kotlin) 이모저모 공부[변수, 자료형, 형변환, 배열, 함수, 흐름제어, object] var : 일반적으로 통용되는 변수로, 언제든지 읽고 쓰기 가능 val : 선언시에만 초기화 가능하며, 중간에 값을 변경할 수 없다 * 코틀린은 변수를 초기화하지 않을 경우 문법 error! 변수 선언시 자료형 뒤에 물음표(?)를 붙이면 -> null을 허용하는 nullable 변수로 선언 그외,, 변수의 초기화를 늦추는 lateinit, laze 속성 Property(속성) : 클래스에 선언된 변수 Local Variable(로컬변수) : 이 외의 Scope 내에 선언된 변수 형변환 : 하나의 변수에 지정된 자료형을 호환되는 다른 자료형으로 변경하는 기능 형변환 함수 toInt() toString() ... to + 변환될 자료형 * a: Any Any 자료형 : 어느 자료형이든 상관없이 호환되는 코틀..
인터페이스(Interface)와 추상화(abstract) 인터페이스(Interface)란 무엇인가 클래스를 이용하여 다중 상속을 할 때 여러 문제가 발생할 수 있기에 자바에서는 인터페이스를 통해 다중 상속을 지원한다. 다른 클래스를 작성할 때 기본이 되는 틀을 제공 구현된 것은 아무것도 없는 기본 설계도와 같음 다른 클래스 사이의 중간 매개 역할까지 담당하는 일종의 추상 클래스 오로지 추상 메소드와 상수만을 포함 가능 인터페이스 선언하기 접근제어자 interface 인터페이스이름 { public static final 타입 상수이름 = 값; ... public abstract 메소드이름(매개변수목록); ... } 인터페이스의 모든 필드는 public static final 인터페이스의 모든 메소드는 public abstract 인터페이스 구현하기 인터페이스는 ..
코드리뷰와 테스트 코드리뷰의 목적? 성장을 목적으로 하는 코드리뷰! 함께 성장하기 위한 수단으로 리뷰를 활용하자. 버스팩터 (Bus Factor) : 팀원이 버스에 치였을 때 프로젝트가 망할 가능성에 대한 지수 이 지수는 프로젝트가 내포하고 있는 리스크를 의미하며, 지수가 낮을 수록 프로젝트가 특정인에게 쏠려있고 정보공유가 원활하지 않다 코드리뷰의 부작용 - 병목이 되는 코드리뷰 - 의미없는 코드리뷰 - 싸움이 되는 코드리뷰 - 책임 소재를 묻는 코드리뷰 성장을 목적으로 하는 것이 중요함 질문도 리뷰다 테스트 필수 Pre-commit Review : Github에 커밋되기 전 사전 리뷰 단계 테스트 일곱 테스트 원칙 1. 테스팅은 결함의 존재를 보여주는 것2. 완벽한 테스는 불가능3. 테스트 구성은 가능한 빠른 시기에 시..
Git-flow master 브랜치 : 언제나 실행 가능한 상태를 유지해야 한다 가장 최신 버전은 실행 가능한 상태. 실행 가능한 상태를 만들어가는 과정은 develop 브랜치에서 진행한다 git checkout -b develop 버그와 기능을 개선한 뒤 출시 준비를 하는 release 브랜치 git checkout -b release/0.2 release 브랜치에서 develop 브랜치와 병합하면서 충돌을 방지한다 최종적으로 정상적인 작동을 확인한다면 master 브랜치와 병합 -> merge commit을 남기는 방식으로 병합 git checkout master git merge --no--ff release/0.2 * --no-ff : fast forward를 하지 않게 함 commit 메시지를 의도적으로 남겨서..