라떼는말이야

문제 설명 위 코드는 아이디, 비밀번호 입력 창에 필터를 적용해 입력받고자 하는 문자만 받는 기능을 한다. 코드 상으로 보면 아이디와 패스워드가 완전히 동일한 로직을 가지고 있다. 그러나 실행 결과를 보면 아이디의 경우 허용되지 않은 문자 입력 시 전체가 지워져버리고, 패스워드의 경우 허용되지 않은 문자 입력 시 입력을 무시하는 동작을 한다. 같은 로직에 다른 현상이 나타나는 것. 원인 파악 로그를 찍어보면 아이디의 source에는 아이디 입력 창에 입력한 전체 문자가 들어있었고, 패스워드의 source에는 패스워드 입력 창에 마지막으로 입력된 문자가 들어있었다. 왜 그럴까? 아이디를 입력하는 과정에서는 키보드 위에 입력한 문자들이 보이는 것을 알 수 있고, 패스워드는 그렇지 않았다. xml에서 아이디의..

토스트는 사용자에게 간단한 알림을 줄 수 있는 기능이다. 하지만 토스트가 중복으로 만들어지는 경우 위 사진처럼 계속해서 토스트가 나와 사용자가 즉각적인 피드백을 받지 못하거나 사용성이 아주 나빠질 수 있다. Toast 만들기 Toast.makeText(context, "토스트 메시지", Toast.LENGTH_SHORT).show() 보통 위와 같이 토스트를 띄울 것이다. 토스트의 생성과 show를 한 번에 하는 코드이다. 하지만 Toast는 객체화할 수 있고, 객체화된 Toast를 취소할 수도 있다. Toast 취소하기 val toast = Toast.makeText(applicationContext, "토스트 메시지", Toast.LENGTH_SHORT) toast.show() // 토스트 표시 to..

목표 설정 프로젝트 생성 시 일반적으로 Empty Activity로 생성해 앱을 만들지만 그 외에도 다양한 템플릿들을 지원해준다. 템플릿들은 구글에서 작성했거나 구글에 통과된 검증된(?) 코트일 테니 템플릿으로 생성해보고 어떻게 구성해놨을지 확인해보는 것도 도움이 될 듯해서 기록에 남기고자 한다. 이번엔 Login Activity를 확인해보려고 한다. 물론 로그인에 필요한 사용자 인증 로직이나 서버와의 통신 로직은 없다. 뷰와 뷰모델, 그리고 UI Controller인 액티비티에서는 어떻게 상호 작용하고, 로그인 상태에 따른 처리를 하는지 확인하는 것이 목표이다. 프로젝트의 구성 프로젝트 생성 시 LoginActivity를 선택하면 기본적으로 위와 같은 구성으로 프로젝트가 생성된다. 사실상 뷰는 로그인 ..

2명 이상 프로젝트를 협업하면 의사 소통과 더불어 가장 중요한 것이 일관성 있게 개발하는 것이라고 생각한다. 나는 자주 쓰는 속성이나 값들은 한 곳에 모아서 관리하고, 변경될 수 있는 값들은 상수로 관리하는 방식으로 진행했다. util 패키지 아래에 Constants.kt와 Extention.kt 파일을 만들었다. Constants.kt 여기서는 상수 값, enum class, object 들을 관리한다. 로그나 API 토큰 정보는 상수로 관리를 하고, 회원 가입 시 비밀 번호 입력 상태나 서버로부터의 응답 상태를 나타내는 enum class를 따로 빼냈고, API 라는 이름의 object로 네트워크와 통신 시 url 을 이 곳에서 따로 관리를 한다. 만약 하드 코딩 되어 있었다면 url에 변화가 생겼을..

로그인 전 & 후 로그인 전/후 화면을 테스트하기 위해 테스트용 버튼을 만들었다. (메뉴들 맨 위에) 물론 테스트이기 때문에 로그인 로직 없이 뷰만 전환한다. (viewModel의 loggedIn: Boolean 변수의 값에 따라 뷰를 전환한다) Material Design 적용 로그인 회원 가입 위 사진 중 맨 왼쪽의 사진은 와이어 프레임으로 짜여진 화면이다. 기존에는 가운데 사진처럼 와이어 프레임의 디자인에 맞춰 뷰를 작성했다. 하지만 좀 더 깔끔한 디자인과 사용성을 위해 메테리얼 디자인을 적용했다. 자세한 동작은 밑에서 이어 설명한다 로그인 화면 더 보기 탭에서 (로그 아웃 상태에서) 상단의 로그인하기 버튼을 누르면 로그인 화면을 띄운다. 아이디 & 비번 찾기 화면 회원 가입 화면

더보기 탭에서 학교 메일 정보는 없앴다. 회원 가입을 할 때 이메일도 해싱 대상이기 때문이다. 추후에 필요하다면 추가적인 정보가 더 들어갈 수는 있다. 그 외에 뷰에서의 변화는 없다. 하지만 껍데기 뿐이던(하드 코딩된) 화면을 뷰모델에서 데이터를 가져와 화면에 표시하는 구조로 변경하였다. Fragment class MoreFragment : Fragment() { private lateinit var viewModel: MoreViewModel private lateinit var viewModelFactory: MoreViewModelFactory private lateinit var binding: FragmentMoreBinding override fun onCreateView( inflater: ..

기존에 시간표 기능만 가지고 있던 앱이었기에 시간표를 보여주는 화면과 시간표 추가 화면 등 단순한 구조로만 이루어져 있던 앱을 기능 확장을 위해 구조를 바꿔야 했다. 이전에 내가 만들었던 앱은 바텀 네비게이션을 가진 프래그먼트 구조였고, 이런 구조를 가진 앱들이 상당히 많고 사용성이 좋다고 생각되어 바텀 네비게이션을 가진 프래그먼트 구조를 적용하기로 했다. 구조 변경 위 사진에서 볼 수 있듯이 기존엔 시간표가 화면을 꽉 채우는 구조였다. 하지만 탭을 만든 이후에는 시간표, 강의 평가, 더보기 탭으로 변경했다. 구조만 변경한 상태이기 때문에 화면은 아직 구성하지 않고, 간단한 텍스트와 배경 색으로 구분만 지어놓은 상태이다. 담당 파트 시간표와 강의 평가 부분은 다른 팀원이 맡기로 했고, 나는 더보기 탭과 ..

시작하기 전에... 로그를 남기는 방법이나 액티비티의 생명 주기에 관해서 아래의 링크에서 상세히 다뤘었다. 아직 액티비티의 생명 주기에 익숙하지 않다면 먼저 공부를 하고 오는 것을 추천한다. 프래그먼트의 생명 주기는 액티비티의 생명 주기와 비슷한 면이 많이 때문이다. 2021.12.09 - [Android] 실습으로 알아보는 액티비티 생명주기 : Android activity lifecycle [Android] 실습으로 알아보는 액티비티 생명주기 : Android activity lifecycle 시작하기 전에... 본 포스트에서 사용한 코드와 코드랩은 밑의 링크에서 다운 받아 사용할 수 있습니다. 단일 액티비티(MainActivity.kt)로 구성되어 있는 앱입니다. 직접 따라하며 익혀도 되고 빠르 l..