Keep the Experience Natural, Easy, Light

#1 알고리즘#1-1 직관적인 풀이와 그 한계#3-1에 있는 50점 짜리 코드는 누구나 생각할만한 직관적인 풀이다. 문제는, L이 큰 경우다. L이 큰 경우는 나머지 연산을 연산 중간 중간에 끼워서 수가 너무 커지지 않게 조절해야 한다. 하지만, 예를 들어 L이 30이라면 3130라는 엄청나게 큰 수를 계산해야하는데 이건 말이 안 된다. 따라서 이 문제는 #3-1에 있는 직관적인 풀이가 아닌 새로운 방식으로 풀어야 한다는 분위기를 풍긴다. 다행히, 문제의 힌트에서 무언가가 보인다. #1-2 힌트abcde의 해시 값은 1 × 310 + 2 × 311 + 3 × 312 + 4 × 313 + 5 × 314 = 1 + 62 + 2883 + 119164 + 4617605 = 4739715이다.반복되는 숫자가 눈에..

#1 문제#1-1 문제 상황정렬된 아이템이기에, 각 아이템의 시각은 위에서 아래로 갈수록 작아져야한다. 그러나, mealId 41인 아이템과 mealId 50인 아이템을 보면 이상한 점이 보인다. 바로 mealId 50인 아이템의 시각은 18:01:14...로, 17:09:03...인 mealId 50보다 큰 것이다. #1-2 문제 코드...@Composablefun NutrientScreen( ...) { LaunchedEffect(key1 = true) { ... } LaunchedEffect(key1 = true) { ... } LaunchedEffect(key1 = viewModel.isInitialized.value) { if..

#1 개요이전 게시글의 Commit은 앱 실행이 안되는 버그가 있다. 해당 버그를 발생시킨 근본적인 부분을 찾아간다. 특히, 세번째 에러는 Room의 무결성과 관련된 에러로 해결까지 꽤 시간이 소요됐으며, 동시에 Room 구현에 있어 DAO를 경솔히 작성해서는 안된다는 교훈을 내게 주었다. #2 코드 - 첫번째 에러#2-1 NoSuchElementExceptionFATAL EXCEPTION: main (Ask Gemini)Process: com.example.nutri_capture_new, PID: 7679java.util.NoSuchElementException: List is empty. at kotlin.collections.CollectionsKt___CollectionsKt.last(_C..

#1 개요이전 게시글에서 채팅 UI 도입을 위해 가상 테이블 DayMealView를 만들었다. 백엔드 작업이 끝났으므로, Day 테이블 및 Meal 테이블을 참조하던 프론트가 이제는 DayMealView 테이블을 참조하도록 만들어야 한다. #2 코드 - 백엔드 깨알 변경 사항#2-1 DAO에서 getAllDayMeals(limit: Int) 선언...@Daointerface MainDAO { ... @Query("SELECT * FROM DayMealView LIMIT :limit") suspend fun getAllDayMeals(limit: Int): List ...}존재하는 모든 레코드를 가져오는 getAllDayMeals()의 메소드 오버로딩이다. getAllDayMeals(..

#1 알고리즘#1-1 '최단 거리'의 의미이 문제에서 '최단 거리'란, '목표 지점(2)으로부터 한번 움직일 때마다 +1한 값'이다. 1차원에서는 간단하다. 검은색 선의 길이와 '최단 거리'가 비례하기 때문이다 (이미 방문한 지역은 다시 방문하지 않는다). 2차원이라면 문제가 복잡해진다. 선의 길이와 '최단 거리'가 비례하지 않는다. 2에서 1로 가는 빨간색 선은 '최단 거리'면서 동시에 '목표 지점(2)으로부터 한번 움직일 때마다 +1한 값'이다. 초록색 선은 '최단 거리'는 아니지만, 빨간색 선과 마찬가지로 '목표 지점(2)으로부터 한번 움직일 때마다 +1한 값'이다. 정리하면, 2차원에서 '최단 거리'는 반드시 '목표 지점(2)으로부터 한번 움직일 때마다 +1한 값'이지만, 역으로 '목표 지점(2)..

#1 개요#1-1 우아함이전 게시글에서 만든, 가상 테이블을 참조하는 DAO 함수는 가상 테이블의 모든 레코드를 통째로 가져오는 방식이었다. 하지만 이는 우아함과는 거리가 있는 방식이다. 처음에는 화면을 가득 채울 정도의 레코드만 가져오고, 무한 스크롤을 통해서 필요한 만큼만 또 가져오는 방식을 구현할 것이다. "View가 보유한 마지막 레코드가 무엇인지 알고, 해당 레코드를 기반으로 (테이블 위치 상) 더 뒤에 있는 레코드들을 뽑아오면 될 것이다."라고 처음에는 간단하게만 생각했다. 그러나 시행착오를 겪으며 시간이 오래 걸렸다 (고작 DAO 함수하나 만드는 건데 이전 게시글과 별도의 게시글로 분리할 이유기도 하다). #1-2 첫 시도: Cursor Room DAO를 사용하여 데이터 액세스  |  And..

#1 알고리즘#1-1 그리디 알고리즘을 적용할 수 있는가? 그리디 알고리즘 (Greedy Algorithm)#1 알고리즘#1-1 개요while(정답 도출) { 현 시점 가장 좋아 보이는 선택}눈 앞의 이익만 추구(= Greedy(탐욕스러운, 욕심 많은))하는 방식의 접근법을 말한다. 위 코드의 형식을 갖추기만 하면 그리디kenel.tistory.com위와 같은 그리디 알고리즘을 구현하면 일단 (정답인지 아닌진 몰라도) 일단 풀리긴할 것 같이 생긴 문제다. 하지만, 그리디 알고리즘을 적용할 수 있는 지에 대한 확신이 들지 않는다. 이 문제가 그리디 알고리즘임을 증명할 수 있다면, 마음 편히 그리디 알고리즘을 적용해 풀 수 있을테다. 따라서, 이 문제에서 최선의 선택이 곧 최적해가 되는 지의 여부를 증명해보..

#1 개요#1-1 채팅 UI 구현을 위한 첫 걸음'채팅 UI'에서 표시할 데이터를 하나의 레코드로서 가지는 가상 테이블을 선언한다. #1-2 가상 테이블 (SQLite)SELECT day_table.day_id AS day_id, meal_table.meal_id AS meal_id, day_table.day_date AS day_date, meal_table.meal_time AS meal_time, meal_table.meal_name AS meal_name, /* NutritionInfo의 Column 시작 */ meal_table.overeating_excess AS overeating_excess, meal_table...

#1 알고리즘#1-1 '정렬' 문제결국 제일 작은 원소는 0이라는 값으로 '압축'될 것이고, 그 다음 순서로 큰 원소는 1이 된다. 즉, 이 문제는 순서 문제고 순서를 부여하기 위해선 정렬이 요구된다. 따라서 이 문제는 정렬 문제다. #1-2 병합 정렬 정렬 - 병합 정렬 (Merge Sort)#1 알고리즘#1-1 #1-2 #1-3 #1-4 #1-5병합 정렬의 총 비교 횟수는, 최악의 경우 nlog2n이다 #2 코드#2-1 자바public static void mergeSort(int[] array, int startIndex, int endIndex) { // (startIndex #2-2 코틀린fun mergeSort(arrakenel.tistory.com정렬 알고리즘으로 병합 정렬을 사용했다. #1..

#1 기존 UI 비판#1-1 스크린샷지금까지 진행한 프로젝트의 스크린샷이다. 아래는 이 화면의 문제점들이다. #1-2 중첩된 Container'날짜 카드' Container 안에는 '식단' Container가 들어가는데, 이렇게 포장지가 2중으로 들어가면 사용자 입장에서 피로감이 생기기 쉽다.  #1-3 '0으로 처리된' 여백'식단'이 없는 '날짜'도 Container가 생긴다. 그러한 '날짜' Container는 아무런 정보 없이 (정확히는 해당 날짜에 기록된 '식단'이 없다는 정보를 제외하고) 자리만 차지한다. 이른바 '0으로 처리된' 여백이다. 정보가 없으면 생략(null)하면 됨에도, 생략하지 않았다(0)는 의미다. #1-4 낯선 스키마(Schema)낯설다. 제일 단순하면서도 제일 주요한 단점이다..