어쩌다 개발자

https://school.programmers.co.kr/learn/courses/30/lessons/118666

class Solution {
    fun solution(survey: Array<String>, choices: IntArray): String {
        var answer: String = ""
        
        var person: CharArray = charArrayOf('R', 'T', 'C', 'F', 'J', 'M', 'A', 'N')
        var score: IntArray = IntArray(8) { 0 }

        for (i in survey.indices) {
            score[person.indexOf(survey[i][1])] += choices[i] - 4
        }

        for (i in 0..7 step 2) {
            if (score[i] >= score[i + 1]) answer += person[i]
            else answer += person[i + 1]
        }
        return answer
    }
}

나와 같은 방식으로 푸신 분의 깔끔한 코드를 가져와봤다.

분석을 하면서 공부하고 내 것으로 만들어야겠다.

우선 동점일 경우 알파벳순으로 리턴해주기에 알파벳순으로 charArray에 담아주고 그 크기에 따른 정수 배열도 만들어준다.

그리고 어차피 choices의 숫자를 통해 알파벳들의 숫자 비교를 위한 것이므로 점수에 4를 빼주고 값을 score에 넣어준다.

'CF"일 때 choices가 3이었다면 F를 가져와서 -1을 넣어주면 사실상 C가 1득점한 것과 같은 효과이다.

이후 for문으로 score값들을 step2로 2씩 띄어서 값들을 비교해주고 동점이거나 높으면 우선순위가 높은 알파벳을 리턴해주고 반대는 뒤에 알파벳을 리턴한다.

맵 컬렉션을 좀 더 공부하고 맵을 이용해서 풀어 봐야겠다.

https://school.programmers.co.kr/learn/courses/30/lessons/133502

class Solution {
    fun solution(ingredient: IntArray): Int {
        var answer: Int = 0
        var stack = mutableListOf<Int>()
        
        for (i in ingredient) {
            stack.add(i)
            if ( stack.size >= 4 && stack.slice(stack.size-4 until stack.size) == listOf(1,2,3,1) ) {
                repeat(4) {stack.removeLast()}
                answer++
            }
        }
        return answer
    }
}

알고리즘 문제를 풀면서 처음으로 Stack 자료 구조를 사용해봤다.

코틀린에선 스택이 구현되어있지 않아서 사용하려면 자바에서 가져오거나 스스로 구현해야한다.

자바에서 가져올 땐 java.util.Stack으로 가져오면 된다.

그럼 var stack = Stack<Int>() 이런 형태로 사용가능하다.

위 문제는 배열의 숫자를 스택에 넣어서 스택 안에 1,2,3,1 형태로 완전한 버거형태가 들어오면 카운트해주고 스택에서 하나씩 제거해주면 해결된다.

https://school.programmers.co.kr/learn/courses/30/lessons/155652

class Solution {
    fun solution(s: String, skip: String, index: Int): String {
        var answer: String = ""
        val alphabet = mutableListOf('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z')
        alphabet.removeAll { skip.contains(it) }
        answer = s.map {
            alphabet[(alphabet.indexOf(it) + index) % alphabet.size]
        }.joinToString("")
        return answer
    }
}

나는 이런식으로 알파벳을 모두 리스트에 넣고 removeAll을 통해서 삭제시킨 다음 시작했다.

근데 더 깔끔한 방법이 있었다.

class Solution {
    fun solution(s: String, skip: String, index: Int): String {
        val alphabet = ('a'..'z').filter{ it !in skip }
        return s.map { alphabet[(alphabet.indexOf(it) + index) % alphabet.size] }.joinToString("")
    }
}

저런식으로도 되는구나...

맵 안에를 설명하자면 간단하다.

s 안을 순회하며 it이 알파벳의 몇번째 인덱스에 속하는지 값과 건너뛰어야 하는 index값을 더하고 알파벳 배열인덱스를 초과할 수 있기 때문에 배열 사이즈로 나머지 연산을 해준다. 이후 리턴 타입이 스트링이므로 joinToString()을 통해 타입을 맞춰준다.

회원 가입 기능을 구현하면서 사용자 입력값에 대한 유효성 검사를 해야할 때가 생겼다.

이름과 아이디 비밀번호 등을 입력 받으면서 이름에는 숫자, 특수문자가 들어가면 안되고 아이디는 이메일 형식으로 받아야 하고 비밀번호는 영문 숫자 특수문자 3가지 조합이 들어가야 한다. 

이런 유효성 검사 같이 Text 실시간 처리를 할 때 유용한 클래스가 있다.

바로 addTextChangedListener 와 TextWatcher이다.

addTextChangedListener 는 EditText 위젯에 TextWatcher를 추가하는 메소드이며 사실상 TextWatcher가 이벤트를 감지하고 처리하는데 쓰이는 주인공이다.

적용방법은 아래와 같다.

EditText.addTextChangedListener( object : TextWatcher {
            override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) {
                TODO("Not yet implemented")
            }

            override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) {
                TODO("Not yet implemented")
            }

            override fun afterTextChanged(s: Editable?) {
                TODO("Not yet implemented")
            }

        })

TextWatcher 는 세 가지 메서드를 정의하는 인터페이스이다.

차례대로 설명하겠다.

beforeTextChanged 는 텍스트가 변경되기 전에 호출되어 변경 전 처리해야할 작업을 넣어주면 된다.

매개변수를 살펴보면 s는 변경 전 텍스트를 가지고 있고 start는 변경이 시작되는 인덱스 before은 변경 전에 제거되는 문자의 수, count는 변경으로 인해 추가되는 문자의 수를 감지한다.

이를 통해 특정 문자의 입력을 제한하거나 수정 전에 기존 텍스트를 저장할 때 유용하게 쓸 수 있다. 예를 들어 사용자가 금지된 단어를 입력했을 때 변경을 취소하고 그 전의 텍스트로 복원시키기가 가능하다.

onTextChanged 는 텍스트가 변경될 때 호출되어 입력 중에 특정 패턴을 검사하거나 실시간으로 입력 내용을 반영하고자 할 때 유용하다.

afterTextChanged는 텍스트가 변경된 후에 호출되어 변경이 완료된 후 처리해야하는 작업이 있을 때 유용하다.

간단하게 로그를 찍어 살펴보자.

숫자를 빠르게 1234를 입력했다. 한 글자를 입력할 때마다 3개의 메소드가 차례대로 호출된다.

주의할 점은 before은 텍스트 변경 전 시점에 호출되기에 on과 after와 다른 값을 가지고 있다는 것이다.

다음은 굳이 3개의 메소드를 다 오버라이드해서 사용안할 분들은 위한 팁이다.

EditText.addTextChangedListener(@SuppressLint("RestrictedApi")
        object : TextWatcherAdapter() {
            override fun onTextChanged(s: CharSequence, start: Int, before: Int, count: Int) {
                
        })

TextWatcherAdapter를 통해서 원하는 메소드만 오버라이드해서 사용 가능하다. 

대신 @SuppressLint("RestrictedApi") 어노테이션을 통해 오류메시지를 강제적으로 무시해주어야 한다.

@SuppressLint("RestrictedApi") 어노테이션은 Android Studio에서 Lint 경고를 무시하도록 하는 역할을 한다.

Lint는 코드에서 잠재적인 문제를 찾아내고 경고 메시지를 통해 문제점을 알려주는 녀석이다.

즉, 해당 코드 라인에서 발생하는 RestrictedApi 경고를 무시하라는 의미로 해당 코드에 대한 경고를 의도적으로 무시하고자 할 때 쓰는 방법이다.

이 방법말고 doBeforeTextChaged, doOnTextChaged, doAfterTextChaged 도 있다.

유효성 검사를 한 방법에 대해서 조금 남겨본다.

pwdEditText.addTextChangedListener(@SuppressLint("RestrictedApi")
        object : TextWatcherAdapter() {
            override fun onTextChanged(s: CharSequence, start: Int, before: Int, count: Int) {
                pwdFlag = isValidPwd()
                signUpBtn.isEnabled = (nameFlag && ageFlag && mbtiFlag && idFlag && pwdFlag && pwdCheckFlag)
            }
        })
        
        
 fun isValidPwd() : Boolean {
        val pwdEditText = findViewById<EditText>(R.id.pwdTextInputEditText)
        val pwd = pwdEditText.text.toString()
        val pwdPattern = Regex("^(?=.*[A-Za-z])(?=.*[0-9])(?=.*[\$@\$!%*#?&.])[A-Za-z[0-9]\$@\$!%*#?&.]{8,16}\$")
        return if (pwdEditText.text.isEmpty()) {
            pwdEditText.error = "비밀번호를 입력해주세요."
            false
        } else if (!pwd.matches(pwdPattern)){
            pwdEditText.error = "영문, 숫자, 특수문자를 모두 포함하여 주세요."
            false
        } else {
            pwdEditText.error = null
            true
        }
    }

정규표현식을 통해 실시간으로 입력받는 값을 처리해주고 있다. 영문 숫자 특수문자를 모두 포함하여야 에러텍스트가 null이되면서 통과하는 형식이다.

프래그먼트란?

안드로이드 앱의 사용자 인터페이스(UI) 일부를 나타내는 모듈화된 컴포넌트이다. 라고 하면 확 와닿지 않는다.

내 개인적인 이해를 가지고 예시를 들어 설명을 하자면, 퍼즐과 비슷한 것 같다.

액티비티가 한 폭의 그림이 담긴 큰 틀이라고 한다면, 프래그먼트는 그 그림을 이루는 퍼즐 조각같은거다.

우선 프래그먼트라는 개념이 나오게 된 배경을 알아보자.

예전에는 핸드폰이 나왔을 때 대부분 비슷비슷한 화면이었다. 근데 지금을 보자면 핸드폰 자체도 화면 크기가 굉장히 다양하다. 갤럭시 노트와 아이폰 미니만 비교해봐도 꽤나 큰 차이다. 그런데 폴드니,, 플립이니,, 뭐니 제각각 개성을 갖춘 녀석들이 등장하기도 하고 태블릿, 스마트TV, 스마트워치 등이 등장하면서 다양한 화면 크기에 대응해야하는 시기가 와버린 것이다. 

다양한 화면 크기에 대응하기 위해서는 화면을 동적으로 조절하고 유연하게 대응해야 할 필요가 있다. 이와 더불어 개발 측면에서도 기능을 모듈화시키고 각각 따로 떼어내는 추세이기에 그에 따라 화면도 여러개로 나누어 조합하여서 다양한 레이아웃을 생성할 수 있도록 하는 모듈화와 재사용성을 높일 필요가 있었다. 이러한 요구사항에 부합하도록 도입된 것이 프래그먼트이다.

요새 앱 환경도 웹의 SPA(Single Page Application) 같이 메인 액티비티 1~2개에 여러 개의 프래그먼트를 사용해서 화면을 구현하는 편이라고 한다.

프래그먼트 특징

1. Jetpack Library Navigation / Viewpager 와 같은 아주 유용한 라이브러리들이 프래그먼트로 사용하도록 설계되어서 함께 사용하면 아주 편리하게 화면을 구성할 수 있다.

2. 액티비티 내에서 여러 프래그먼트가 동작할 때, 각 프래그먼트 간에는 직접적인 통신이 가능하다. 이를 통해 모듈 간의 상호작용이 가능하다.

3. 화면을 여러개의 프래그먼트로 나눠서 다양한 레이아웃을 생성 가능하고 여기 저기 쓸 수 있으니 재사용성에도 기여한다. (화면이 작은 디바이스면 프래그먼트 하나 딱 보여주고 화면이 크면 프래그먼트 여러 개 띄어서 보여준다.) + 동적인 UI 업데이트

4. 액티비티는 안드로이드 시스템에서 직접 관리하지만 프래그먼트는 프래그먼트 매니저가 간접적으로 관리한다.

이를 통해 메모리 리소스가 상대적으로 덜 소모된다고 한다.

5. 액티비티안에 종속되지만 자체적인 생명주기를 가지고 있다.

프래그먼트의 생명주기를 왜 이해해야하는가?

이 정도 대충 읽으면 프래그먼트가 대세구만! 하는 느낌이 온다. 그럼 이제 잘 사용하고 싶어진다. 프래그먼트를 잘 사용하려면 프래그먼트의 생명주기를 잘 이해해야한다.

또한, 메모리 누수를 방지하기 위해서 프래그먼트의 각 단계별 상황에서 어떤 적절한 액션을 취해서 대처해야할지 알아야 하기에 잘 이해해놓아야 한다.

메모리 누수(Memory Leak) 란 한정된 자원을 가진 프로그램이 할당한 메모리를 제대로 해제하지 않아 발생하는 현상이다.

즉, 일꾼들에게 작업공간을 주고서 작업이 다 끝났으면 다시 다른 일꾼에게 그 공간을 잘 할당해주어야 하는데 노는 공간이 많이 발생하면서 계속 누적되고 시스템 자원이 낭비되고 결국 성능에 악영향을 끼치는 현상이다.

우리가 객체를 참조하고 더 이상 쓰지 않거나 필요하지 않은 시점에선 적절하게 메모리를 해제시켜야 성능과 안정성을 높일 수 있다. 그런 시점을 알려면? 생명주기 이해 해야한다!

위 그림은 안드로이드 공식 문서에서 제공한 그림이다. 보면 프래그먼트의 자체의 생명주기(왼쪽)와 프래그먼트 뷰의 생명주기를 구분해서 표현한다. 이 둘 주기의 차이점을 잘 파악해두면 메모리 누수나 런타임 오류를 방지할 수 있다.

우선 액티비티 생명주기와의 콜백함수 차이점을 보면 onCreateView() onCreatedView(), onViewStateRestored() 와 onSaveInstanceState(), onDestroyView()가 있다.

차이점만 인지하고 이제 생명주기를 알아보자.

onAttach() & onCreate()

(+내 메모리에 잘 넣기 위해서 조금 각색해보았다. 정확한 표현이 아닐 수 있기에 (?) 표시해두었다.)

Fragment의 압축파일(?) 같은 녀석이 프래그먼트 매니저를 통해서 호스트 액티비티에 attach되고, onAttach() 작업이 완료되면 onCreate()에서 프래그먼트 자체가 압축해제(?) 되어 생성된다.

생명주기 그림을 보면 알겠지만 아직 프래그먼트 뷰 생성 전이므로 뷰와 관련된 작업을 이 메소드에서 진행하는건 적절하지 않다.

한줄 요약

onAttach() -> 프래그먼트가 호스트 액티비티에 attach 된다.

onCreate() -> attach된 프래그먼트 자체가 생성된다.

onCreateView & onViewCreated()

onCreateView에서 프래그먼트 뷰가 초기화되고 완료됨과 동시에 onViewCreated()를 호출하여 완전히 생성된 뷰 객체를 반환한다. onCreateView에서 레이아웃을 inflate 하기에 뷰 객체들을 참조할 수 있지만, 안정적으로 뷰 객체의 생성이 보장이 된 onViewCreated에서 참조하는 것이 안전하다. (+ 여기에서 findViewById, 뷰 바인딩, LiveData 옵저빙, 각종 어댑더 세팅하면 된다.)

이제 슬슬 생명주기를 왜 알아야하는지 감이 오기 시작하죠?? (어디서 어떤 처리를 해야하는지 알겠죠?)

onCreateView() - > 프래그먼트 뷰 초기화 + 뷰 객체 반환

onViewCreated() -> 뷰의 생성 완료를 보장

onViewStateRestored() 

프래그먼트의 상태를 복원할 때 호출된다. 프래그먼트의 뷰 계층 구조와 연관된 상태를 복원하는데 사용된다.

많은 블로그에서 이렇게 설명한다. 사실 이렇게 들으면 초보입장에서는 알아듣기 힘든 것 같다.

우선, 이 콜백메소드는 일반적으로 프래그먼트가 소멸되고 다시 생성될 때 호출된다.

쉽게 이야기하자면, 우리가 앱을 보다가 잠시 떠났다가 들어왔을 때 다 초기화되어있을 수도 있지만 요즘 앱들은 내가 나갔다가 와도 내가 보던 그 화면 위치, 내가 작성하던 텍스트 등 포커싱 아웃 전 내 UI 현재 상태를 유지하고 있다.

그 상태들을 복원시킬 때 쓰이는게 이 메소드다. 

onViewStateRestored()  - > 소멸된 프래그먼트 상태 복원

onStart()

프래그먼트가 사용자에게 보여질 수 있을 때 호출되며 이 때부터 사용자에게 프래그먼트 뷰가 보이게 된다. 이 시점부터 프래그먼트는 자식 프래그먼트매니저를 통해 프래그먼트의 추가, 교체, 제거 등의 작업으로 관리되어진다.

onResume()

액티비티와 마찬가지로 onResume() 부터 사용자와 상호작용할 수 있는 상태이다. 이 때 상호작용에 필요한 작업을 수행하면 된다. 

onPause()

프래그먼트가 일시 중지될 때 호출된다.

onPause()에서는 사용자와의 상호작용이 중단되는 시점에서 필요한 작업을 수행한다.

onStop()

프래그먼트가 사용자에게 더 이상 표시되지 않을 때 호출된다.

onStop()에서는 UI 업데이트 및 리소스 정리와 같은 작업을 수행한다.

onSaveInstanceState()

프래그먼트가 소멸되기 전에 호출되며, 프래그먼트의 현재 상태를 저장하는 데 사용됩니다. 주로 화면 회전이나 다른 구성 변경 시에 발생하는 프로세스의 재시작으로부터 데이터를 보존하고 복원하는 데 활용됩니다. 

onDestroyView()

프래그먼트의 뷰 계층 구조가 소멸될 때 호출됩니다.

onDestroyView()에서는 UI와 관련된 자원을 해제하는 작업을 수행합니다.

onDestroy()

프래그먼트가 소멸될 때 호출됩니다.

onDestroy()에서는 필요한 자원을 해제하고 정리하는 작업을 수행합니다.

onDetach()

프래그먼트가 액티비티에서 분리될 때 호출됩니다.

onDetach()에서는 프래그먼트가 속한 액티비티에 대한 참조를 해제하는 작업을 수행합니다.

https://school.programmers.co.kr/learn/courses/30/lessons/160586

class Solution {
    fun solution(keymap: Array<String>, targets: Array<String>): IntArray =
        targets.map { str ->
            str.map { c -> keymap.map { it.indexOf(c) + 1 }
                .filterNot { it < 1 }
                .let { list ->
                    if (list.isEmpty()) -1
                    else list.minOf { it }
                }
            }.let { if ( it.contains(-1)) -1 else it.sum() }
        }.toIntArray()
}

좋은 코드를 짜려면 좋은 코드를 많이 보라는 말에 따라 오늘부터 코틀린스러운 문제 해결법에 집중해서 다른 분의 코드를 분석하고 내 것으로 만드는 과정을 시작해보려 한다. 위 코드를 통해 코틀린의 각종 확장함수와 함수 표현식을 알 수 있다.

위의 코드는 프로그래머스 최용건님의 코드이다. 안에 내용을 안과 밖을 구분해서 분석해보자.

targets.map { str ->
str.map { c -> keymap.map { it.indexOf(c) + 1 }
                .filterNot { it < 1 }
                .let { list ->
                    if (list.isEmpty()) -1
                    else list.minOf { it }
                }

분석해보자면 .map으로 타겟 배열을 스트링 그리고 문자로 나눠서 그 문자가 keymap배열의 몇번째 인덱스에 있는지 확인한다.

이 후 .filterNot을 통해 인덱스가 1보다 작은 것들은 빼고 배열형태로 반환한다.

그리고 리스트안에 만약 문자가 없으면 -1 을 보내고 여러개 있는데 그 중 우리는 최솟값을 찾는 것이기에 minOf를 통해 작은 값을 보낸다.

targets.map { str ->

				...
                
}.let{ if(it.contains(-1)) -1 else it.sum() }

나온 리스트안에 -1이 포함되어있으면 -1을 내보내고 아니라면 리스트안에 원소들을 모두 .sum()을 통해 합한다.

내가 생각하기엔 코틀린스럽다는 말이 이제 조금 와닿고 있다. 아무래도 이 문제에 최적화된 코드는 아니지만 문제가 좀 더 꼬여있을 때를 생각하면 좀 더 확장성 있게 잘 짠 코드인 것 같다.