아래 이미지처럼 되는 효과를 없애기 위해 처음에 얼마나 애를 먹었는지 🥶 이걸 그림자효과로 봐야하는지 .. hover 등등을 검색했었지 .. 일단 이것을 ripple 효과라고 부르는걸 몰라서 검색하는 것도 힘들었다 ;; 어쨌든, Ripple 효과 없애기 !!! 아래 이미지처럼 app:itemBackground를 설정해주면 끝!! 끄읏!!!! 그럼 아래 그림처럼 터치할 때 ripple 효과가 사라진다 ㅎㅎ Ripple 효과를 쓰되, bottomNavigationView를 넘지 않게 하기 아래 이미지처럼 android:background를 설정해주면 끝!! 그럼 아래처럼 된다 나와 같이 고생하는 분들을 위해 글을 공유한다.

오늘의 개념: Fragment - 1/2 아래의 내용들은 구글 공식문서를 바탕으로 정리한 것이다🐱‍👤 등장 배경 및 디자인 철학 Android 3.0(API level 11)에 처음으로 도입 태블릿과 같은 대형 스크린에서 유연한 UI를 지원하기 위해 아래 그림에서와 같이 태블릿에서는 2개의 Fragment를 동시에 보여줄 수 있고, 모바일에서는 1개의 Fragment씩 보임 Fragment는 모듈식의 재사용 가능한 구조로 만들어야 함 => Fragment는 독립된 모듈로 재사용이 가능. 하나의 fragment에서 다른 fraagment를 직접 조작하게 만들면 안 된다 Fragment는 언제 사용할 수 있을까? 태블릿과 같은 큰 화면에서 Tab layouts BottomBar Navigation Dialo..

#오늘의 개념 : Koin DI 라이브러리란? 의존성 주입은 한 개체가 다른 개체의 의존성을 제공하는 기술입니다. "의존성"은 예를 들어 서비스로 사용할 수 있는 개체입니다. 사용할 서비스를 지정하는 클라이언트 대신 클라이언트가 사용할 서비스를 알려줍니다. -위키백과 우선 DI 란? DI : Dependency Injection(의존성 주입)의 준말 의존성 주입의 의미를 알아보자. 의존성이란, 나는 의존성의 관계를 아래와 같이 이해한다. 예를 들어, A와 B가 있다. 어떤 action이 행해져 A에 영향을 미쳤다. A가 영향을 받았기 때문에 B도 영향을 받는다. 이러한 A-B의 관계를 의존성이 있다고 본다. 주입이란, "밖에서 안으로 넣는다"라는 의미로 볼 수 있다. 즉, 소프트웨어에서의 의존성 주입이란..

#오늘의 개념: MVVM MVVM 패턴이란? Model(M) - View(V) - ViewModel(VM) View : UI. 사용자에게 보이는 화면 및 사용자의 입력 등 ViewModel : View에서 받은 사용자의 액션에 대한 business logic 처리. (액션에 필요한 데이터를 Model을 통해 업데이트하거나) Model : 데이터 처리 특징 1. View - ViewModel의 관계 위의 그림 1을 보면, ViewModel은 View의 존재를 모름. 이로써 플랫폼 의존성에서 벗어날 수 있게 해 준다 ViewModel은 계속해서 데이터를 방출하면, View는 ViewModel의 데이터를 계속 듣는 관계. 예) 교수님(ViewModel)은 강의 중 많은 학생(View)들을 대상으로 다양한 정보..

#오늘의 개념: Android Architectrue Pattern 이 글은 안드로이드 공식 홈페이지에서 소개한 App Architecture Guide를 바탕으로 작성되었습니다. Architecture Pattern - 코드의 설계. 즉, 개발 시 코드를 어떤 구조로 짤 것이냐. - 꼭 써야만 하는 것은 아님. - 현재는 구글에서도 아키텍쳐 사용을 권장 Architecture Pattern 사용 이유 (쓰지 않는다면?) - 하나의 액티비티/프래그먼트 파일 내에 수 많은 UI logic & 비즈니스 logic 등이 다 섞여있음 - 그럼 해당 액티비티가 재시작될 경우, 모든 로직 역시 새로 시작해야 함. - 코드가 복잡해지고 길어지게 됨 ==> 가독성이 떨어짐. - 파일 내 구조 파악이 힘들어짐. - 유닛..

구글에서 권장하는 성능 개선 방법 #2가지 기본 규칙 불필요한 것은 하지 않기 가능하다면 메모리 할당하지 않기 1. 불필요한 Object 생성 피하기 가능한 한 단기 임시 객체를 만들지 않는 것이 좋다. 생성되는 객체가 적을수록 사용자 환경에 직접적인 영향을 미치는 가비지 컬렉션의 빈도가 낮아진다. 2. 적절한 Static 사용하기 개체의 필드에 접근할 필요가 없는 경우, 매소드를 static으로 만드는 것을 권장한다. 그러면 호출이 약 15~20% 빨라진다고 한다. 3. 상수에는 static final 사용하기 4. 향상된 for 루프(for-each) 사용하기 아래의 예에서 기본 for 문과 for-each 문의 차이를 보자. 속도는 zero() < one()