Review
-
과제 내에서는 의미가 없음
-
개발자의 의사결정 차원이다.
-
protected => 상속의 자식 클래스만 허용됩니다.
-
가급적 접근 범위를 줄여야 유지보수성에 좋음
-
너무 많은 곳과 연관될 수 있어
-
유지보수성 =
결합도와 많이 관련!
-
-
다형성? 왜? 결합도를 낮추기 위해서
- Super, 상위 타입을 사용하는 것과 같은 예시
-
Spring의 Core는 IoC 모듈 (모바일에선, Dagger, koin 등)
Android - View
- View 클래스를 Activity 코드에서 직접 생성
android:lines
android:maxLines
android:inputType
android:inputType="text" <!-- 한줄 입력 강제 -->View binding
- 이전까지의 방법이 너무 번거로움
//build.gradle
android {
viewBinding {
enabled = true
}
}
실습
-
프로젝트 res 폴더의 내부 구조도 용도에 따라 나누어져 있다
-
color, font 폴더 등이 들어갈 수 있다
-
이러한 리소스들을 어떻게 이용하는가? =>
R.layout.a,R.drawable.o -
R : 툴에 의해 자동으로 만들어지는 클래스 (Resource의 약어)
-
만들자마자 자동으로 경로에 추가된다.
-
변수명이 파일명으로 들어감(Java 명명규칙 위반 불가!)
- 숫자 우선 X, _만,
알파벳 대문자는 못씀
- 숫자 우선 X, _만,
-
-
이미지와 관련된 xml파일도 다 drawable
- 실제로는 resource 폴더 밑에 xml 파일이 정말 많아요
android:autoLink="web"
lateinit var button: Button
lateinit var editText: EditText-
위 코드를 작성하는 것은 너무 번거로움
-
View-Binding 기법을 이용하자
viewBinding {
enabled = true
}
뷰를 배치하는 레이아웃
-
LinearLayout, RelativeLayout, FrameLayout, GridLayout, ContraintLayout
-
개발자 선택사항입니다. => 배치이기 때문에
LinearLayout
RelativeLayout
GridLayout
FrameLayout
ConstraintLayout
-
안드로이드 플랫폼이 아니라, androidx에서 제공하는 라이브러리입니다.
-
RelativeLayout보다 훨씬 더 다양한 조건을 제공
-
build.gradle 파일에 dependencies에 implementation을 선언
dependencies {
implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
}-
androidx.constraintlayout.widget.ConstraintLayout와 같이 풀패키지 명이 필요함
- 클래스명만 주었다는 것은 표준이기 때문에
사용자 이벤트 처리하기
- 터치, 키 이벤트 / 뷰 이벤트
-
키 이벤트 : onKeyDown, onKeyUp, onKeyLongPress
-
홈 화면, 앱 위젯, 설정화면 모두 내부 어플리케이션
Jetpack
appcompat lib
-
구글에서 만들어준 안드로이드 관련 lib
-
하위 호환성을 보장
Fragment - Activity처럼 동작하는 View
-
androidx.fragment 라이브러리에서 제공
-
Fragment를 상속받아 작성하는 클래스
layoutinflater
-
xml을 화면으로 뿌리기 위해서 필요한 클래스
-
최소한으로 작성해야 하는 함수는 onCreateView
Fragment LifeCycle
-
하나의 Activity가 너무 커지는 것을 막을 수 있다는 Fragment의 장점
-
백 스택 : Fragment가 화면에 보이지 않는 순간 제거하지 않고 저장했다가 다시 이용할 수 있는 기능
-
백 스택을 사용하지 않으면 Fragment가 교체될 때 기존의 프래그먼트는 onDestroy까지 호출되어 제거됩니다.
-
백 스택을 사용하면 Fragment가 제거되지 않고 onDestroyView 함수까지만 호출됩니다.
-
-
Fragment를 만들면 관련된 xml파일을 자동으로 같이 만들어줍니다.
-
view를 핸들링한다고 하면 => view-binding이 필수
Recycler View
-
ListView보다 훨씬 더 Powerful
-
그래서 더 복잡합니다.
-
ViewHolder, Adapter, LayoutManager, ItemDecoration
-
ViewHolder : 항목에 필요한 뷰 객체
-
Adapter : 항목을 구성
-
LayoutManager : 항목을 배치
-
ItemDecoration(Optional) : 항목 꾸미기
-
ItemDecoration
-
Recycler View를 다양하게 꾸밀 때 사용
-
항목의 구분선을 출력해주는 DividerItem Decoration
-
onDraw, onDrawOver, getItemOffsets
View Pager - Swipe로 넘기는 화면 구성
Drawer Layout - 옆에서 열리는 화면 구성
Material Design Lib
AppBarLayout
-
앱바도 다양한 역할을 맡게 됩니다.
-
정보, 메뉴, 이미지 => 우리의 입력에 따라 조절하고 싶다면?
CoordinatorLayout
-
recycling => 화면에 같이 있는 다른 view가 같이 event 처리되려면?
- 일단은 불가능! => 이벤트 정보가 전달되지 않아
Tab Layout - Tab 버튼 구성
-
TabHost는 과거에 사용하던 방식
-
다양화 X : 등분만 가능!
-
ViewPager가 연동이 안 됨!
-
-
TabLayout : Tab button 다양화 처리목적 + ViewPager 연동
- button만 목적으로 하지만, 밑이 ViewPager면 연동을 해주겠다
-
TabLayoutMediator를 사용해서 ViewPage를 연동합니다!
Navigation View
- Drawer Content를 메인 컨텐츠로 하는 사람은 X
Floating Action Button
-
버튼은 버튼인데, 둥둥 떠다니는 UI를 가지는 버튼
-
가장 중요한 역할을 하는 1개의 버튼의 역할을 FAB가 처리하게 한다.
컴포넌트 이해하기
액티비트 컴포넌트
-
Intent : 다른 Component를 실행시키기 위해 시스템에 띄우는 메시지
-
의뢰해서, 시스템에서 해석 후 실행시키는 구조
-
내 코드에서 직접 실행시킨 것이 아닌데, 구지 알아야 하는가?
- 내 것이든 남의 것이든 다 실행시켜 버림
-
startActivity: 시스템에 intent를 발생시킴 -
intent는 쉽게 생각해서는 안 됨
-
화면 전환 API가 아님 => 마음먹고 하면 힘들다
-
Activity, Service, BroadCast intent 등이 존재합니다.
-
-
안드로이드에서 intent가 없는 Activity는 실행되지 않는다.
-
내부 정보를 보여주기 싫다는 예 => intent를 띄우기 전에 데이터를 담고 전달해줍니다.
- = extra data
-
외부 앱에서 다른 앱 기능을 실행 시 원하는 결과가 자동으로 돌아와야 한다?
-
과거에는...
-
startActivityForResult(intent) : 결과를 기대하겠다는 함수
- 되돌아왔을 때 사후처리할 것
-
최신 버전에서는 ActivityForResultLauncher를 사용합니다.
-
다른 어플리케이션에서는 클래스명을 알 수가 없음
-
앱을 까보면 된다? 우리 앱이 먼저 개발되었다면?
-
나중에 개발되었다고 해도, 클래스를 가지고 있는지 어떻게 알아
-
-
내부에서는 명시적 인텐트를 사용해라 (어떤 경우라도!)
-
외부에서는 클래스명으로는 부족하다 => 암시적 인텐트를 사용하자
-
전송되는 데이터 정보에 맞게 주어야 한다
-
안드로이드 전역에서, URL 객체는 uri로 표현됩니다.
