invoke란?

• invoke는 클래스의 인스턴스가 마치 함수인 것처럼 호출될 수 있게 하는 특수 함수입니다. 주입 가능한 생성자를 사용하여 클래스를 함수로 변환하여 주는데 이를 통해 표준 함수 호출 구문을 사용하여 ViewModel에서 usecase를 계속 호출할 수 있도록 합니다.

class LoginUseCase @Inject constructor(private val authRepository: AuthRepository) {
    suspend operator fun invoke(email: String, password: String) : Flow<String> {
        return authRepository.login(email, password)
    }
}

• 저는 다음과 같이 로그인을 하는 usecase에서 repository를 생성자로 가지고 repository에서 login 함수를 호출하는 것으로 코드를 작성하였습니다. 다음 usecase를 ViewModel에서 다음과 같이 사용할 수 있습니다.

clase LoginViewModel(
    private val loginUseCase: LoginUseCase
): ViewModel() {

    fun login(email: String, password: String) {
        viewModelScope.launch() {
            val getLoginInfo = loginUseCase(email, password)
            ...
        }
    }
}

• 이렇게 LoginUseCase의 invoke 메서드를 이름을 생략하여 호출할 수 있었습니다. 원래는 "객체명.함수명()"의 형태로 호출하여야 하지만 "객체명()" 형태로도 그 객체의 함수를 호출할 수 있다는 것이 편하고 코드의 가독성을 올려주는 것 같았습니다.

결론

• operator fun과 invoke 키워드는 모두 연산자 오버로딩을 사용하기 위한 키워드입니다. (연산자 오버로딩이란 다양한 연산자들(+, -, *, / 등등)을 재정의해서 사용할 수 있게 해주는 방법이라고 생각하시면 됩니다. )

• 코드의 간결함과 가독성을 높여주고 호출의 유연성이 생깁니다. (loginUseCase() vs loginUseCase.invoke)

. . .

참고

https://onlyfor-me-blog.tistory.com/837

https://velog.io/@spdlqjfire/Kotlin-invoke

서버와의 통신

웹 애플리케이션 개발에서 클라이언트와 서버 간의 통신은 필수적인 요소인데 이를 위해 주로 사용되는 두 가지 프로토콜이 HTTP(HyperText Transfer Protocol)와 웹소켓(WebSocket)입니다.

HTTP 프로토콜 통신

• 기존에는 HTTP 프로토콜 통신이란 HTML 파일을 전송하는 프로토콜의 의미를 가졌다.(Hyper Text Transfer Protocol)

• 웹 브라우저에서의 통신은 초기 대부분 HTML 파일을 전송하는 목적이였기 때문이었는데 현재는 JSON, Image 등 다양한 형식의 파일들을 전송할 수 있습니다.

• HTTP 통신은 클라이언트에서 서버로 요청을 보내고, 서버가 이에 응답하는 방식으로 통신이 이루어집니다. 여기서 응답은 클라이언트의 요청에 따른 결과를 반환한 것입니다. (단방향 통신)

• 서버의 응답에는 응답 코드(202, 404 ...)가 같이 전송되며 사용자는 응답 코드와 메시지 응답으로부터 오는 메시지 바디를 통해 요청 값을 전달 받습니다.

WebSocket(웹소켓)

• 웹소켓(Web Socket) 프로토콜은 HTTP와는 다른 통신 프로토콜로 웹 서버와 웹 브라우저가 서로 실시간 메시지를 교환하는 데 사용됩니다.

• 웹소켓은 연결을 위한 첫 번째 핸드셰이크를 주고 받은 이후 지속적으로 연결이 유지되는 것이 특징이며 매번 메시지 전송 시에 새롭게 연결을 맺을 필요가 없어 빠르고 효율적입니다.

• 웹소켓을 이용한 실시간 통신 구현은 클라이언트와 서버 모두에서 웹소켓 API를 사용하여 이루어집니다. 클라이언트는 JavaScript의 WebSocket 객체를 사용하여 서버와의 연결을 수립하고 서버는 웹소켓 프로토콜을 지원하는 라이브러리를 이용하여 이를 처리합니다.

• 웹소켓은 TCP 소켓과 이름만 유사할 뿐 브라우저의 소켓이며 웹소켓 프로토콜은 HTTP와 동일하게 애플리케이션 계층에서 동작합니다. 그리고 평문 메시지 전송 방식이므로 SSL/TLS 보안 계층으로 암호화되어야 데이터 탈취를 방지할 수 있습니다.

• 웹소켓은 사용할 때는 네트워크 지연시간, 데이터 압축, 보안 등을 고려하여 애플리케이션의 요구 사항에 맞게 세심하게 설계되어야 합니다.

두 가지 프로토콜의 차이점?

여기서 두 가지 프로토콜의 차이점이 있는데 HTTP는 요청/응답(Request/Response) 모델을 기반으로 하는 비연결성(단방향) 프로토콜 입니다. 클라이언트가 서버에 요청을 보내고, 서버는 이에 대한 응답을 보내줍니다. HTTP는 각 요청이 독립적이며 상태를 유지하지 않기 때문에 이러한 형태를 띄고 있다고 합니다. 반면 웹소켓은 클라이언트와 서버 간에 지속적인 연결을 유지하는 양방향 통신 프로토콜입니다. 이를 통해 실시간으로 데이터를 주고 받을 수 있습니다. (아무래도 채팅을 구현하기에는 웹소켓이 더 적당하지 않을까 생각합니다.)

차이점 정리

HTTP

• 비연결성(단방향) 프로토콜로 각 요청이 독립적이며 상태를 유지하지 않음
• 매번 연결을 맺고 끊는 과정의 비용이 많이듭니다.
• 요청(Request) - 응답(Response)의 구조를 지닙니다.
• 기본적인 웹 애플리케이션에 적합

웹소켓

• 연결성(양방향) 프로토콜로 클라이언트와 서버 간에 지속적인 연결을 유지하는 통신 프로토콜
• 한번 연결을 맺은 뒤 계속 유지되는 실시간성을 보장합니다.
• 연결지향적인 특징을 지닙니다.
• 실시간 통신이 필요한 애플리케이션에 필수적

. . .

(번외) TCP/IP 소켓과 웹소켓의 차이

TCP/IP Socket

• 네트워크상 서버와 클라이언트 두 개의 프로그램이 특정 포트를 통해 양방향 통신이 가능하도록 만들어주는 소프트웨어 장치입니다.

• intranet 바운더리(조직 내 네트워크)에서 작업하는 경우에는 해당 네트워크의 컴퓨터를 제어하고 TCP 연결에 적합한 포트를 열 수 있기 때문에 TCP 소켓을 통해 통신하는 것이 더 쉽습니다.

• TCP/IP Socket은 인터넷을 통한 통신을 위한 프로토콜이기 때문에 소켓을 이용하여 양 끝단의 IP/Port 번호를 이용해 연결을 수립하고 데이터를 주고 받고 데이터의 신뢰성을 보장합니다.

• 하나의 TCP 접속에 있는 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜입니다.

Web Socket

• HTTP 프로토콜 위에 실시간 양방향 통신 기능을 추가한 프로토콜로 ws/wss 프로토콜 위에서 동작합니다.

• 웹소켓은 HTTP에서 실시간 통신을 할 수 없다는 문제를 해결하기 위해 나온 기술로 HTTP의 헤더를 업그레이드해서 동작하기 때문에 서버나 클라이언트는 전이중 양방향 통신을 수행하며 언제든지 메시지를 보낼 수 있다.

• 웹소켓은 연결지향으로 한 번 연결을 맺은 뒤 유지되며 핸드쉐이크 과정에서는 헤더의 비중이 크지만, 한 번 연결이 되면 간단한 메시지들만 오고가기에 굉장히 경제적입니다.

• HTTP나 HTTPS 위에서 동작하도록 설계되었으며 포트를 80번, 443번 사용합니다.

참고

https://velog.io/@sangje112/http-vs-WebSocket-http-%ED%86%B5%EC%8B%A0%EA%B3%BC-WebSocket%EC%9D%98-%EC%9E%A5%EB%8B%A8%EC%A0%90

https://jerecord.tistory.com/155

Collection의 주요 인터페이스에는 List와 Map, Set이 있는데 이 세가지 자료구조의 특징을 한번 알아보겠습니다.

List

• 순서가 있으며 데이터의 중복을 허용하는 자료구조입니다.

• 크기가 가변적이며 비어있는 데이터가 없습니다.

• 인덱스를 통해 저장 데이터에 접근이 가능합니다.

• 만약 원하는 데이터가 뒤쪽에 있을 경우 속도가 떨어집니다. (리스트를 순회해야 하기 때문에)

List 인터페이스의 주요 구현체

ArrayList

• 단방향 포인터 구조로 데이터 순차적 접근에 강점을 가집니다.

• 배열을 기반으로 데이터를 저장합니다.

• 데이터 삽입, 삭제가 느리고 데이터 검색이 빠릅니다.

LinkedList

• 양방향 포인터 구조로 데이터 삽입, 삭제가 빠릅니다.

• ArrayList 보다 검색이 느립니다.

. . .

Array와 ArrayList의 차이

• Array의 경우 길이가 고정되어 변경이 불가능하지만 ArrayList의 경우 Array를 이용해 만든 List형 자료구조입니다. Array와 다르게 길이를 할당하지 않지만 데이터 추가시 배열의 최대 크기가 넘으면 2배 크기의 배열을 만들고 원본을 복사하여 재생성 합니다.

• ArrayList는 배열을 이용하여 리스트를 구현한 것 입니다. 다만 배열을 가변적으로 사용하며 리스트가 가지는 특성인 저장순서 유지와 중복 허용의 특징을 가지고 있습니다. ArrayList는 클래스이기 때문에 배열을 추가, 삭제 할 수 있는 기능을 함께 포함하고 있습니다.

• Array는 동적으로 사이즈 변경이 안되지만 ArrayList의 경우에는 가능합니다.

Map

• Key와 Value의 한쌍으로 이루어진 데이터의 집합 입니다.

• Key에 대한 중복이 없으며 순서를 보장하지 않습니다. (데이터는 중복을 허용합니다.)

• 뛰어난 검색 속도를 가지고 인덱스가 따로 존재하지 않습니다.

HashMap

• 내부적으로 배열을 만들어 관리하며 Key 값으로 넘겨준 객체의 해시 코드를 계산하여 배열의 접근 인덱스로 사용합니다.

• Key와 Value 값으며 NULL을 허용합니다.

• 동기화가 보장되지 않습니다.

• 검색에 가장 뛰어난 성능을 가집니다.

TreeMap

• Key와 Value 쌍을 내부적으로 RedBack Tree (이진 탐색 트리)로 저장하여 관리합니다.

• Key 값을 기준으로 오름차순 정렬되고 빠른 검색이 가능합니다.

• 저장 시 정렬을 하기 때문에 시간이 다소 오래 걸립니다.

LinkedHashMap

• 데이터의 입력 순서를 기억합니다.

Set

• 데이터의 집합이며 순서가 없고 중복된 데이터를 허용하지 않습니다.

• 중복되지 않은 데이터를 구할 때 유용합니다.

• 빠른 검색 속도를 가지고 인덱스가 따로 존재하지 않습니다.

HashSet

• HashSet은 객체들을 순서없이 저장하고 동일한 객체는 중복 저장하지 않습니다.

• NULL 값을 허용하고 TreeSet 보다 삽입, 삭제가 빠릅니다.

TreeSet

• 이진 탐색 트리(Red Black Tree)를 기반으로 합니다.

• 데이터들이 오름차순으로 정렬됩니다.

• 데이터 삽이브 삭제에는 시간이 걸리지만 검색과 정렬이 빠릅니다.

LinkedHashSet

• HashSet과 동일하지만 입력된 순서를 저장하고 관리합니다.

정리해보기

• List는 데이터들이 순서대로 저장되며 데이터의 중복이 허용됩니다.

• (순서 O, 데이터 중복 O)*

• Set은 순서가 보장되지 않는 데이터의 집합으로 데이터의 중복이 허용되지 않습니다.

• (순서 X, 데이터 중복 X)*

• Map은 순서가 보장되지 않고 Key 값의 중복은 허용하지 않지만 Value 값의 중복은 허용됩니다.

• (순서 X, 키는 중복 X, 값은 중복 O)*

참고

https://velog.io/@kwj2435/%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0-list-map-set-%EC%B0%A8%EC%9D%B4

https://studywithus.tistory.com/68

생각보다 신경쓸 부분이 많아서 오래걸렸지만 차근차근 작성해 보겠습니다.

데이터 모델 설정

data class ChatRoomDataEntity(
    val chatRoomId: String,
    val lastMessageData: LastMessageDataEntity,
    val unReadMessage: Int,
    val participant: List<String>,
    val chatRoomSession: List<Map<String, Boolean>>
)

data class LastMessageDataModel(
    val lastMessage: String,
    val lastSendAt: String,
    val lastMessageSender: String
)

• 채팅방에 대한 데이터는 채팅방 고유 ID, 마지막으로 받은 메시지(시간, 내용), 안읽은 메시지 갯수, 참여자, 채팅방에 지금 들어와 있는지 이렇게 구성되어 있습니다.

• 마지막으로 받은 메시지에 대한 내용을 가지고 오는 것보다 더 간단할 것 같아서 메시지를 보낼 때 Firebase에서 update 할 수 있도록 구성했고, 채팅방에 현재 상대방이 들어와 있는지 없는지 Boolean 타입으로 나타내어 false일 경우에는 안읽은 메시지로 나타내고 true일 경우에는 읽은 메시지로 나타낼 수 있도록 하였습니다.

• 채팅방 List에서 안읽은 메시지를 나타낼 수 있도록 Firebase의 snapshotListener를 이용하여 실시간으로 갱신되어 update 할 수 있도록 unReadMessage를 구성했습니다.

  chatRoomDB.collection(COLLECTION_CHAT_MESSAGE)
    .whereArrayContains("read", mapOf(recipientUid to false))
    .addSnapshotListener { unReadMessage, e ->
        chatRoomDB.update("unReadMessage", unReadMessage?.size())
  }
  

// * unReadMessage 갯수 갱신

----

data class MessageDataModel( val uid: String, val chatRoomId: String, val messageId: String, val message: String?, val imageList: List?, val sendAt: String, val read: List<Map<String, Boolean>>, val type: MessageViewType )

enum class MessageViewType(val messageType: Int) { TEXT_MESSAGE(0), IMAGE_MESSAGE(1) }

- 메시지는 보낸 사람의 uid(고유 id를 통해서 그 사람의 프로필 정보를 가져옴) 메시지 고유 id, 보낸 시간, 읽음 여부, 메시지 타입(imageType or textType)을 담았습니다.

- 이미지 타입과 텍스트 타입 두가지 타입의 메시지를 보낼 수 있는데 메시지 타입일 때는 enum class로 타입을 나누어 multiView로 recyclerView를 나타낼 수 있도록 하였고 imageType일 때는 message 내용을 null로, textType일 때는 imageList를 null로 Firebase 채팅방에 보내줍니다.

----
채팅방과 채팅방을 구성하는 메시지에 대한 데이터 모델은 이렇게 설정하였습니다. 생각보다 처음 만들어보는 채팅이라서 그런지 생각해야할 부분이 많아서 데이터 모델만 해도 계속 추가하고 수정했었던 것 같습니다.
.
.
.
### 코드 구성

- 메시지를 보낼 때 생각할 경우의 수가 있는데 기존에 첫번째 메시지를 보내서 채팅방이 존재하는지 아닌지 체크를 해서 채팅방이 존재한다면 메시지만 보내야 하는 경우의 수가 있고 채팅방이 없다면 메시지를 보내기 전에 채팅방을 형성해주고 보내야 한다는 경우의 수가 있습니다.

#### 기존 채팅방이 없을 경우 (처음 메시지를 보낼 때)
![](https://velog.velcdn.com/images/one_coin/post/9380628d-7463-4c6b-a645-45f8e9bae1bf/image.png)
- 기존 채팅방이 없는 경우 서로 친구일 경우에 다음과 같이 상단에 친구 목록이 나타나게 되는데 채팅을 시작할 친구를 눌러서 채팅을 시작할 수 있습니다.

- 채팅방을 들어가면 먼저 채팅방이 있는지 없는지 Boolean으로 확인을 하고 채팅방이 없다면 false를 반환, 있다면 true를 반환하게 합니다.

- 채팅방이 있는지 없는지 체크하는 메서드는 LiveData로 observe하여 첫 메시지를 보내고 난 후 채팅방이 감지되면 바로 true를 반환합니다.

- 체크 메서드가 false로 결과 값을 반환하는 경우에 첫 메시지를 보내면 다음과 같이 Firebase에 채팅방에 대한 데이터가 set 됩니다.

![](https://velog.velcdn.com/images/one_coin/post/70688f0a-7936-4a99-aa1f-594450fdbce6/image.png)

---

#### 기존 채팅방이 있는 경우

- 기존 채팅방이 있는 경우는 간단합니다. 기존 채팅방의 고유 id를 받아와서 하위 document에 데이터를 set 해주는 것으로 처리합니다.

![](https://velog.velcdn.com/images/one_coin/post/f1e482c6-3ff3-463b-b0a1-64eb444734e3/image.png)

- 여기서 신경써야할 부분은 상대방이 지금 채팅방 안에 들어와 있는지 체크하여 Boolean 타입으로 반환시켜 줍니다. true일 경우는 상대방이 채팅방에 들어와 있는 경우로 생각하여 read의 value 값을 true로 서버에 업로드 시켜줍니다. 그럼 상대방은 메시지를 바로 읽었다고 값을 받게 되므로 바로 읽은 상태의 메시지가 채팅방에 나타납니다. 반대의 경우에는 value가 false이므로 읽지 않은 메시지로 채팅방에 표시됩니다.

---

#### 신경쓰지 못한 점

- 상대방이 채팅을 읽는 경우를 생각하지 못해서 데이터 모델도 다시 고치고 시간이 좀 걸렸던 것 같습니다. 

- 원래는 시간을 현재 사용하는 기기 시간인 LocalDateTime을 사용하여 작업을 진행하였는데 sortedDescending 이용하여 메시지 리스트를 adapter에 submitList하였을 때 순서대로 나오지 않는 경우가 발생하였습니다. 이 부분을 고치고자 한국 표준시를 이용하였고 이 부분에서 조금 아쉬웠던 점은 UTC를 활용하여 하지 못한 것 같아 다음에는 UTC+09와 같이 적용을 해볼까 생각하고 있습니다.

fun chatDateFormat() : String { val formatter = SimpleDateFormat("yyyy-MM-dd HH:mm:ss:SSS", Locale.KOREAN) formatter.timeZone = TimeZone.getTimeZone("Asia/Seoul") return formatter.format(Date().time) } // * 한국 표준 시를 가져오는 코드

```

• 개인적으로 채팅이 정말 신경쓸 부분이 많은 작업이라고 들었는데 실제로 멀티뷰타입, 채팅방이 존재하는지, 상대방이 채팅방에 들어와 있는지 등등 생각할 부분이 많았다고 생각합니다. 덕분에 조금 좋은 경험이었다고 생각합니다.

컴포넌트(Component)란?

• 먼저 컴포넌트란 독립된 모듈로, 사용자 인터페이스의 기본적인 형태를 말합니다. 즉, 안드로이드에서의 컴포넌트란 안드로이드 앱을 구성하는 필요한 4개의 요소를 뜻합니다. 독립된 모듈이기 때문에 재사용이 가능하고 추후에 교환될 수도 있습니다.

그럼 안드로이드의 4대 컴포넌트는?

• 안드로이드의 4대 컴포넌트에는 액티비티(Activity), 서비스(Service), 방송 수신자(BroadCast Receiver), 콘텐츠 제공자(Content Provider)가 있습니다. 각 컴포넌트는 독립적인 형태로 존재하며 인텐트(Intent)를 통해서 상호작용합니다.

각 컴포넌트는 어떤 역할을 하나요?

액티비티 (Activity)

• 액티비티는 사용자가 Application과 상호작용하며 실제로 사용자에게 보이는 화면을 의미합니다. Application에 화면이 없다면 사용자와 상호작용 할 수 없다는 의미와 같으므로 반드시 하나의 액티비티는 존재해야 합니다.

• 다른 Application의 액티비티 역시 인텐트를 통해 불러올 수 있으며 액티비티는 생명주기(Life Cycle) 관련 메서드를 재정의하여 원하는 기능들을 구현할 수 있습니다.

• 2개 이상의 액티비티를 동시에 Display 할 수 없고 1개 이상의 View 또는 ViewGroup을 포함합니다.

서비스 (Service)

• 서비스는 액티비티처럼 사용자와 직접적으로 상호작용하는 요소는 아닙니다. 백그라운드(Background)에서 어떠한 작업을 처리하기 위해서 서비스를 사용하는데, 만약 Application이 종료되어도 백그라운드(Background)에서 동작하는 컴포넌트가 서비스이다.

• 대표적으로 음악 앱과 타이머 앱처럼 Background에서 계속 음악이 재생되거나 타이머가 작동되기 때문에 이 기능은 서비스에 해당됩니다.

• 서비스 같은 경우가 사용자의 인터페이스(UI, 화면)를 방해하지 않고 눈에 보이지 않는 곳에서 작업을 처리하기 때문에 별도의 스레드(Thread)에서 동작한다고 생각할 수 있지만, 서비스는 엄연히 메인 스레드(Main Thread) 에서 동작하기 때문에 서비스 내에서 별도의 스레드를 생성하여 작업을 처리해야 합니다.

• 서비스는 네트워크와 연동이 가능하고 별도의 UI를 가지지 않으며 액티비티와 서비스는 UI스레드라고 불리는 동일한 애플리케이션 스레드(Thread)로 실행됩니다.

방송 수신자 (BroadCast Receiver)

• 방송 수신자 (BroadCast Receiver)는 안드로이드 OS로부터 발생하는 각종 이벤트와 정보를 받아와 핸들링하는 컴포넌트입니다. 간단하게 말하면 안드로이드 시스템이나 다른 앱으로부터 전송되는 브로드캐스트 메시지를 수신하는 컴포넌트입니다.

• 사용자 안드로이드 디바이스의 시스템 부팅시 앱 초기화, 네트워크 끊김 등 특수한 이벤트에 대한 처리나 배터리 부족 알림, 문자 수신과 같은 정보를 받아 처리를 해야 할 필요가 있을 때 동작합니다. 즉, 안드로이드 OS에서 메신저 앱 또는 문자 메시지가 오면 모든 앱에 메시지에 대한 정보를 방송(BroadCast)을 합니다. 이 메시지를 받기 위해 브로드캐스트 리시버(BroadCast Receiver)를 구현하면 되고 해당 정보가 오면 특정 이벤트를 처리할 수 있습니다.

• 브로드캐스트 리시버(BroadCast Receiver)는 대부분 UI를 가지지 않으며 안드로이드 디바이스의 특수한 상황에 대응하기 위해 사용됩니다.
  • Broadcast (브로드 캐스트란)? 브로드 캐스트(Broadcast)는 컴퓨터 네트워크에서 전송되는 메시지를 일방적으로 모든 연결된 장치에게 보내는 통신 방식입니다.. 이 방식은 단일 송신자가 여러 수신자에게 동시에 메시지를 보낼 수 있도록 합니다.

콘텐트 제공자 (Content Provider)

• 콘텐트 제공자(Content Provider)는 데이터를 관리하고 다른 애플리케이션의 데이터를 제공하는데 사용되는 컴포넌트입니다. 특정한 애플리케이션이 사용하고 있는 데이터베이스(DB)를 공유하기 위해 사용하며 애플리케이션 간의 데이터 공유를 위해 표준화된 인터페이스를 제공합니다.

• 외부 애플리케이션이 현재 실행 중인 애플리케이션 내에 있는 데이터베이스(DB)에 함부로 접근하지 못하게 할 수 있으면서 나 자신이 공개하고 공유하고 싶은 데이터만 공유할 수 있도록 도와줍니다.

• 작은 데이터들은 인텐트(Intent)로 애플리케이션끼리 데이터를 서로 공유가 가능하지만 콘텐트 제공자(Content Provider)는 음악 또는 사진 파일 등과 같이 용량이 큰 데이터들을 공유하는데 적합합니다.

• 데이터베이스에서 흔히 사용되는 CRUD(Create, Read, Update, Delete) 원칙을 준수합니다.

. . .

인텐트 (Intent)

• 인텐트란 애플리케이션 컴포넌트 간에 작업 수행을 위한 정보를 전달하는 역할을 하며 통신수단이라고 보면 됩니다. 인텐트를 가장 많이 사용하는 예로는 액티비티 간의 화면 전환(이동)이 있습니다.

• 서로 독립적으로 동작하는 4가지 컴포넌트들 간의 상호 통신을 위한 장치로 컴포넌트에 액션(Action), 데이터(Data) 등을 전달합니다. 또한 인텐트(Intent)를 통하여 다른 애플리케이션의 컴포넌트를 활성화시킬 수 있습니다.

카카오 지도 api

• 카카오 지도 api는 다음과 같은 기능을 지원합니다.

여기서 쿼리에 맞는 검색 결과를 가져오기 위해서는 키워드 검색하기 기능을 통해서 정보를 받아올 수 있습니다.

키워드로 장소를 검색할 때는 다음과 같이 친절하게 안내가 되어있습니다.

• GET 메서드를 통해서 URL에 자료형만 정해주면 됩니다. (저의 경우엔 JSON으로)

요청 단계에서는 다음과 같습니다.

• HEADER에 카카오 REST_API_KEY를 Authorization에 넣어주고
• 다음과 같은 쿼리 파라미터를 통해 결과를 요청할 수 있습니다. 저는 크게 query(키워드)와 page, size 정도 사용하여 결과 값을 받아왔습니다.

응답 결과

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
  "meta": {
    "same_name": {
      "region": [],
      "keyword": "카카오프렌즈",
      "selected_region": ""
    },
    "pageable_count": 14,
    "total_count": 14,
    "is_end": true
  },
  "documents": [
    {
      "place_name": "카카오프렌즈 코엑스점",
      "distance": "418",
      "place_url": "http://place.map.kakao.com/26338954",
      "category_name": "가정,생활 > 문구,사무용품 > 디자인문구 > 카카오프렌즈",
      "address_name": "서울 강남구 삼성동 159",
      "road_address_name": "서울 강남구 영동대로 513",
      "id": "26338954",
      "phone": "02-6002-1880",
      "category_group_code": "",
      "category_group_name": "",
      "x": "127.05902969025047",
      "y": "37.51207412593136"
    },
    ...
  ]
}

• 카카오 지도 api에서 예시로 보여준 응답 결과입니다. query로 카카오 프렌즈를 넣어서 요청하였을 때의 결과로 저는 여기서 phone, place_url, address_name, place_name, x, y 값을 사용하였습니다. x, y는 경도와 위도 값으로 지도 위에 마커를 찍기위해 필요한 부분이라서 가져왔습니다.

요금

• 카카오 지도 api의 경우에는 1일 300,000회 무료로 사용 가능한데 혼자 프로젝트를 진행하거나 개발 공부를 하실 때는 부담없이 사용 가능 할 것 같습니다.

장점

• 개인적으로 이번에 프로젝트에서 카카오 지도 검색 api를 사용한 이유는 제가 필요한 정보를 제공해주는 점(장소에 대한 url, 전화번호 등)이 제일 컸습니다. 좀 다양한 정보를 받아서 사용자에게 보여주고 싶었던 점이 컸기 때문에 선택하게 되었습니다.

단점

• 네이버 지도 api에 비해서 검색 결과가 사실 그렇게 정확하게 나오지는 않았던 것 같습니다. 테스트를 하는 과정에서 문제가 있었을 수도 있겠지만 네이버 지도 api에 비해서 결과 값의 정확도, 상위 결과 값의 선정 기준?? 을 잘 모르겠었습니다. 그 외에는 다 만족했습니다!

• 이건 조금 다른 이야기지만 지금 실 기기가 아닌 에뮬레이터에서 테스트를 해보고 있다 보니 https://devtalk.kakao.com/t/x86-x86-64/42582 위의 링크와 같은 오류가 생겼습니다. 그래서 문제 해결 방법으로 카카오 지도 api에서 검색 결과 값을, 네이버 지도 api를 화면에 나타내 주는 방법을 선택한 이유도 있습니다.

네이버 지도 api

• 네이버 지도 api는 다음과 같은 기능을 제공합니다.

네이버 지도는 키워드를 검색할 수 없고 주소를 검색해서 장소에 대한 정보를 얻을 수 있었습니다. 정확도는 네이버 지도 api가 더 좋았지만 다양한 결과를 얻을 수 있었던 것은 카카오 지도 api였던 이유가 이런 점도 있었습니다.

• 네이버 지도 api의 요청 예시는 다음과 같습니다. 카카오와 비슷하게 GET 메서드를 통해서 받을 수 있으며 카카오와 다른 점은 JSON 형식의 자료형만 지원합니다.

• 헤더에서 응답 데이터의 형식을 정해주는 것으로 보이고 api key도 헤더로 요청하는 것으로 보입니다.

• 요청 쿼리 파라미터로는 다음과 같이 요청할 수 있고 카카오와 마찬가지로 query, page, count 세 가지를 요청해보았습니다.

(개인적으로 공식 문서 자체는 카카오가 조금 더 잘 알려주는 느낌?? 이 있었던 것 같습니다.)

응답 결과

{
    "status": "OK",
    "meta": {
        "totalCount": 1,
        "page": 1,
        "count": 1
    },
    "addresses": [
        {
            "roadAddress": "경기도 성남시 분당구 불정로 6 NAVER그린팩토리",
            "jibunAddress": "경기도 성남시 분당구 정자동 178-1 NAVER그린팩토리",
            "englishAddress": "6, Buljeong-ro, Bundang-gu, Seongnam-si, Gyeonggi-do, Republic of Korea",
            "addressElements": [
                {
                    "types": [
                        "SIDO"
                    ],
                    "longName": "경기도",
                    "shortName": "경기도",
                    "code": ""
                },
                {
                    "types": [
                        "SIGUGUN"
                    ],
                    "longName": "성남시 분당구",
                    "shortName": "성남시 분당구",
                    "code": ""
                },
                {
                    "types": [
                        "DONGMYUN"
                    ],
                    "longName": "정자동",
                    "shortName": "정자동",
                    "code": ""
                },
                {
                    "types": [
                        "RI"
                    ],
                    "longName": "",
                    "shortName": "",
                    "code": ""
                },
                {
                    "types": [
                        "ROAD_NAME"
                    ],
                    "longName": "불정로",
                    "shortName": "불정로",
                    "code": ""
                },
                {
                    "types": [
                        "BUILDING_NUMBER"
                    ],
                    "longName": "6",
                    "shortName": "6",
                    "code": ""
                },
                {
                    "types": [
                        "BUILDING_NAME"
                    ],
                    "longName": "NAVER그린팩토리",
                    "shortName": "NAVER그린팩토리",
                    "code": ""
                },
                {
                    "types": [
                        "LAND_NUMBER"
                    ],
                    "longName": "178-1",
                    "shortName": "178-1",
                    "code": ""
                },
                {
                    "types": [
                        "POSTAL_CODE"
                    ],
                    "longName": "13561",
                    "shortName": "13561",
                    "code": ""
                }
            ],
            "x": "127.1054328",
            "y": "37.3595963",
            "distance": 0.0
        }
    ],
    "errorMessage": ""
}

• 네이버 지도 api 공식 문서에 있는 응답 결과 예시입니다. 주소에 대한 내용은 자세하게 되어있지만 그 외에 부가적인 사항은 받을 수 없더라구요 ㅠㅠ (물론 제가 잘 못 찾아본 것일 수도 있습니다!)

• 그래서 검색에 대한 조금 부가사항을 사용하고 싶어서 장소에 대한 검색은 카카오 지도 api를 사용하기로 한 것이었습니다.

요금

네이버 지도에서 방금 사용한 Geocoding의 경우에는 요금이 다음과 같습니다.

• 카카오와 마찬가지로 혼자서 공부를 하거나 작은 규모의 프로젝트라면 전혀 문제되지 않을 이용 횟수 입니다.

장점

• 주소를 기반으로 하는 프로젝트라면 훨씬 좋을 것 같습니다. 검색 결과가 정확하기도 하고 주소를 세분화 하여 분류 할 수도 있기 때문에 지도가 메인 기능인 지도 기반 프로젝트일 경우에는 네이버 지도 사용도 고려해 볼 수 있을 것 같습니다.

단점

• 단순히 서브의 느낌으로 사용하기에는 내용이 조금 부족한 느낌이 있습니다. 네이버 검색 엔진을 사용하면 더 좋을 수도 있겠지만 지도 api안에서 비교를 해보자면 단순히 주소만 보여주는 느낌이라서 활용성이 적을 수도 있을 것 같다는 느낌이 있습니다.

. . . . .

결론

• 예전에 구글 지도를 사용했을 때는 정보는 좋았지만 국내 서비스에는 조금 불편한 점이 있었고 국내 서비스를 목표로 지도 api를 사용한다면 카카오 api와 네이버 api를 고려해 볼 수 있는데

  정확한 내용과 장소에 대한 세분화를 원한다면 네이버 지도 api를, 부가적인 정보의 활용을 원한다면 카카오 지도 api의 사용이 좋을 것 같습니다. 물론 개인적인 견해이긴 하지만...사용해보니 그런 느낌을 받은 것 같습니다.

1. 데이터 구조 변경

변경전

data class PostDataModel(
    val uid: String,                ─┐
    val profileImage: String,        │
    val name: String,                │  → user data
    val email: String,               │
    val postId: String,             ─┘
    val imageList = imageList,            ─┐
    val postText: String,                  │
    val mapData = MapDataModel(),          │   → post data
    val createdAt: String                 ─┘   
)

• 원래는 다음과 같이 포스트에 대한 data class 안에 고유 아이디 값, 이름, 이메일, 프로필 사진 등 유저의 정보를 직접 참조 할 수 있도록 데이터 구조를 구성했었는데, post data를 가져올 때 user라는 collection을 참조하여 uid 값에 맞는 user 정보를 가져오는 것으로 데이터 구조를 변경해 보려고 합니다. 그렇게 되면 post data 안에는 고유 아이디 값인 uid만 넣어주면 되는 것이므로 한층 간결해 질 것으로 예상됩니다.
  ↓ ↓ ↓

• 변경후*

  data class PostDataModel(
     val uid: String,
     val postId: String,
     val imageList = imageList,
     val postText: String,
     val mapData = MapDataModel(),
     val createdAt: String
  )
  >
  data class UserDataModel(
     val uid: String,
     val name: String,
     val email: String,
     val profileImage: String?,
     val createdAt: String,
     val intro: String?
  )
  >
  // join two collections
  data class PostModel(
     val userData: UserDataModel,
     val postData: PostDataModel
  )

• user data와 post data를 분리하여 주고 post data를 작성한 유저의 uid만 post data 안에 넣어줍니다. 게시글을 작성하는건 현재 유저만 가능한 일이므로 current user의 uid가 들어가면 되겠습니다. 여기서 기존과 다른 점은 data class를 하나 더 생성하여 post data와 user data를 같이 받아올 수 있는 data class를 하나 만들어줘야 합니다. 예시에서 PostModel이
  그 data class 입니다. 이제 repository에서 로직을 작성해 보겠습니다.

2. repositoryImpl

현재 작성중인 프로젝트의 repositoryImpl의 구문을 paging 작업 빼고 가져왔습니다.

db.collection("post")
    .orderBy("createdAt", Query.Direction.DESCENDING)
    .get()
    .addOnSuccessListener { postData ->
        val documents = postData.documents
        val postResponse = postData.toObjects(PostDataResponse::class.java)
        postResponse.map { postEntity ->
            db.collection("user").document(postEntity.uid).get()
            .addOnSuccessListener { userData ->
                val userEntity = userData.toObject(UserDataResponse::class.java)?.toEntity()
                if (userEntity != null) {
                    postList.addAll(listOf(PostEntity(userEntity, postEntity)))
                }
                postDocuments.addAll(documents)
                trySend(postList)
        }
    }
}

1. post data 가져오기
>
db.collection("post").orderBy("createdAt", Query.Direction.DESCENDING).get()
>
- 먼저 fireStore database의 post collection에서 정보를 가져옵니다. 

2. 가져온 post data를 data class로 변환시켜주기
>
.addOnSuccessListener { postData ->
    val documents = postData.documents
    val postResponse = postData.toObjects(PostDataResponse::class.java)
>
- addOnSuccessListener는 firebase에서 지원해주는 로직으로 데이터를 받아오는 것이 성공했을 때를 의미합니다.
- 받아온 data의 documents를 data class로 변환(toObjects) 해줍니다.

3. user data 가져오기
>
postResponse.map { postEntity ->
    db.collection("user").document(postEntity.uid).get()
>
- toObjects 시켜준 데이터에서 각 data 마다의 uid를 가져와서 uid에 맞는 user data를 가져와 줍니다.
- 네이밍이 조금 이상하게 되어있긴합니다...ㅠㅠ

4. list 전달하기
>
.addOnSuccessListener { userData ->
    val userEntity = userData.toObject(UserDataResponse::class.java)?.toEntity()
    if (userEntity != null) {
        postList.addAll(listOf(PostEntity(userEntity, postEntity)))
    }
    postDocuments.addAll(documents)
    trySend(postList)
        }
    }
>
- 가져온 user data도 data class로 toObject 해주고 postList를 만들어서 안에 addAll 해주었습니다.
- 이때 list에 들어가야 하는 data는 아까 전에 만들어둔 PostModel 입니다!
>
                    ↓
>
data class PostModel(
    val userData: UserDataModel,
    val postData: PostDataModel
)

• 좀 뒤죽박죽 작성한 것 같긴한데 핵심은 이렇습니다.

1. user data와 post data를 분리한다.
2. post data를 가져올 때 각 post data의 uid를 참조하여 uid 값에 맞는 user data를 가져온다.
3. 두가지 데이터를 참조하는 data class를 만들어 list로 받아준다.

3. 완

이렇게 하여 data를 받아주면 collection을 따로 관리할 수 있어서 더 편리하기도 하고 나중에 프로젝트의 규모가 커질수록 더 효율적일 것 같습니다! 규모가 커진다는 것은 그만큼 관리해야 하는 데이터가 늘어난다는 것인데 그때도 모든 유저의 데이터를 각 댓글, 게시글, 대댓글 마다 넣어준다면 쓸모없는 데이터를 계속하여 넣어주는 느낌이지 않을까 싶습니다.

처음 data 구조를 구성할 때도 이게 맞나 긴가민가 했지만 좋은 선생님 덕분에 방법을 알아간 것 같아서 좋습니다!

더 깊게 공부하고 data 구조를 공부하려면 mongoDB, SQL Join 등 키워드로 검색 해봐야 겠습니다! . . .

참고문헌

https://stackoverflow.com/questions/52696311/cloud-firestore-how-to-get-relational-data-from-two-collections

• Firebase 설정

  
  먼저 FireStore Storage를 생성해주면 되는데 위치를 설정해주고
  
  테스트 모드로 시작해줍니다. (프로덕션 모드에서 시작해서 읽기/쓰기 권한을 true로 변경해줘도 될 것 같습니다!)

• 프로젝트 설정

  
  
  프로젝트에서 Tools를 통해 Cloud Firestore를 추가하셔도 되고

dependencies {
    implementation("com.google.firebase:firebase-firestore:25.0.0")
}

다음과 같이 의존성을 추가해도 됩니다.

• 게시물 생성

UI layer

먼저 데이터를 받아줍니다.

private fun initData() {
        val auth = CurrentUser.userData
        val uid = auth?.uid.toString()
        val profileImage = auth?.profileImage
        val name = auth?.name.toString()
        val email = auth?.email.toString()
        val postText = binding.etMakeText.text.toString()
        val time = LocalDateTime.now()
>
        val data = PostDataModel(
            uid = uid,
            postId = UUID.randomUUID().toString(),
            profileImage = profileImage,
            name = name,
            email = email,
            imageList = imageList,
            postText = postText,
            mapData = MapDataModel(placeName, addressName, lat?.toDouble(), lng?.toDouble()),
            createdAt = dateFormat(time)
        )
}

• 여기서 CurrnetUser는 MainFragment가 onCreated 될 때 값을 초기화 해준 object 입니다. (data class CurrentUserModel을 반환값으로 가짐)

• 게시물 생성은 현재 유저의 uid, name, email, profileImage 등을 보여주므로 현재 유저의 정보를 담아줍니다.

• postId는 uid와 마찬가지로 각 게시물마다 고유의 값이 존재해야 수정, 삭제 등에서 혼선이 없고 식별이 가능하기 때문에 randomUUID를 통해 값을 지정해주었습니다.

• createdAt 즉, 생성 시기는 게시물을 생성된 시기에 따라 순차적으로 보여주기 위해 받았고 추후에 게시물 생성 몇 초전, 몇 분전과 같이 생성 시간에 따른 로직을 추가할 예정이기 때문에 넣어주었습니다. (여기서 dateFormat은 util로 빼준 함수입니다.) ``` fun dateFormat(time: LocalDateTime) : String { return time.format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")) }

• 시간만 넣으면 변환 (편안) - ```
• mapData는 data class MapDataModel로 받고 있는데 장소 이름과 주소, 경도, 위도를 받고 있습니다. 현재 장소 이름은 null이 아닐 경우에 게시물에 표시되고 있고 추후에 naver 지도를 통해 받은 경도, 위도를 입력해서 지도에 위치를 나타내줄 생각으로 경도, 위도까지 같이 받고 있습니다.

사실 mapData를 받는 과정에서 viewModel을 사용했는데 data가 들어오지않아 새로 배운 기술을 사용해 보았습니다. (후에 알았지만 fragment 생명주기의 영향을 받는 by viewModels를 사용했을 때는 안되던 것이 by activityViewModels를 사용하니 받아지더라구요...이 부분도 공부해서 다음에 포스트 작성해야겠습니다.)

• 
  현재 다음과 같이 바텀시트를 이용해서 검색 결과를 보여주고 아이템 클릭 리스너를 통해 클릭 시 데이터를 bottomSheetFragment.popBackStack() 하면서 전달해주어야 하는데 viewModel을 사용하지 않고 적용하려하니 좀 어려웠던 것 같다 ㅠㅠ...
  검색하면서 알아보다보니 Fragment Result API를 이용해서 값을 전달해 줄 수 있다는 것을 알았고 한번 사용해보았다!
  Fragment 간 result를 전달 하기 위해 사용하는데 간단하다. 전달하고 싶은 데이터를 담아서 클릭 리스너에 연결시켜주었다.

MapBottomSheetFragment -> SendData

Recyclerview ClickListener ->
>
>
val mapAdapter = KakaoMapListAdapter { data ->
            sendMapData(data)
            findNavController().popBackStack()
        }
        with(binding.rvMap) {
            LinearLayoutManager(requireContext(), LinearLayoutManager.VERTICAL, false)
            adapter = mapAdapter
        }
    }
>
>
>
sendMapData -> 
>
>
private fun sendMapData(mapData: KakaoDocumentsModel) {
        val bundle = Bundle()
        bundle.putString("placeName", mapData.placeName)
        bundle.putString("addressName", mapData.addressName)
        bundle.putString("lat", mapData.lat)
        bundle.putString("lng", mapData.lng)
        setFragmentResult("data", bundleOf("mapData" to bundle))
    }

. . mapData를 번들로 담아서 recyclerview item 클릭 시 Fragment Result API로 넘겨주었다.

MakePostFragment -> RecieveData

private fun getMapData() {
>
        setFragmentResultListener("data") { data, bundle ->
            val mapData = bundle.getBundle("mapData")
            if (mapData != null) {
                binding.clMakeLocationText.visibility = View.VISIBLE
                binding.tvMakeLocationName.text = mapData.getString("placeName")
                binding.tvMakeLocationInfo.text = mapData.getString("addressName")
>
                placeName = mapData.getString("placeName")
                addressName = mapData.getString("addressName")
                lat = mapData.getString("lat")
                lng = mapData.getString("lng")
>
            } else {
                binding.clMakeLocationText.visibility = View.GONE
            }
>
            binding.ivMakeMapDelete.setOnClickListener {
                mapData?.clear()
                binding.clMakeLocationText.visibility = View.GONE
            }
        }
    }

데이터를 전달해줬으면 받는 쪽에서는 setFragmentResultListener를 통해 key값으로 data를 받을 수 있다.

지금은 해결방법을 알아서 viewModel을 통해서 데이터를 전달하고 사용하지만 Fragment Result API를 통해서 데이터를 전달하고 받는 과정도 공부해봐서 좋았던 것 같다. . . . 이제 데이터가 준비됐다면 Firebase FireStore로 데이터를 올려줄 차례이다. domain layer에서 먼저 작업을 해보자!

Domain layer

먼저 repository에서 함수를 작성해준다.

DataRepository

interface DataRepository {
    suspend fun uploadPost(postData: PostDataEntity): Flow<Boolean>
}

그 다음 useCase를 작성하고 data layer로 넘어가보자

UploadPostUseCase

class UploadPostUseCase @Inject constructor(private val dataRepository: DataRepository) {
    suspend operator fun invoke(postData: PostDataEntity) : Flow<Boolean> {
        return dataRepository.uploadPost(postData)
    }
}

(invoke에 관해서도 한번 공부할 필요가 있어보인다...)

Data layer

DataRpositoryImpl impl에서 먼저 constructor로 auth, firestore, storage를 생성해준다.

class DataRepositoryImpl @Inject constructor(
    private val auth: FirebaseAuth,
    private val db: FirebaseFirestore,
    private val storage: FirebaseStorage
): DataRepository

storage는 따로 소개가 되지 않았지만 이미지는 firestore에 바로 올릴 수 없기 때문에 storage에 저장한 다음 downloadUrl을 통해 가져와야 부를 수 있습니다!

(storage도 firestore 처럼 종속성 추가하면 됩니다!! 과정이 같아서 생략...ㅎ)

그 다음 아까 작성해둔 uploadPost를 override하여 여기서 구현하면 된다.

override suspend fun uploadPost(postData: PostDataEntity): Flow<Boolean> {
        return flow {
            try {
                val currentUser = auth.currentUser?.uid
                val imageList = arrayListOf<ImageDataEntity>()
                if (currentUser != null) {
                    val data = hashMapOf(
                        "postId" to postData.postId,
                        "uid" to currentUser,
                        "profileImage" to postData.profileImage,
                        "name" to postData.name,
                        "email" to postData.email,
                        "postText" to postData.postText,
                        "mapData" to postData.mapData,
                        "createdAt" to postData.createdAt
                    )
                    db.collection("post").document(postData.postId).set(data).await()
                    >
                    if (postData.imageList != null) {
                        for (i in 0 until postData.imageList.count()) {
                            val imageToUri = postData.imageList[i].imageUri.toUri()
                            val storageRef =
                                storage.getReference("image")
                                    .child("${currentUser}/${postData.postId}/${postData.createdAt}_${i}")
                            if (imageToUri.pathSegments?.contains("video") == true) {
                                storageRef.putFile(imageToUri).addOnSuccessListener {
                                    storageRef.downloadUrl.addOnSuccessListener { downloadUri ->
                                        imageList.add(
                                            ImageDataEntity(
                                                downloadUri.toString(),
                                                "video"
                                            )
                                        )
                                        val imageData =
                                            mapOf("imageList" to imageList.sortedBy { it.imageUri })
                                        db.collection("post").document(postData.postId)
                                            .update(imageData)
                                    }
                                }
                            } else {
                                storageRef.putFile(imageToUri).addOnSuccessListener {
                                    storageRef.downloadUrl.addOnSuccessListener { downloadUri ->
                                        imageList.add(
                                            ImageDataEntity(
                                                downloadUri.toString(),
                                                "image"
                                            )
                                        )
                                        val imageData =
                                            mapOf("imageList" to imageList.sortedBy { it.imageUri })
                                        db.collection("post").document(postData.postId)
                                            .update(imageData)
                                    }
                                }
                            }
                        }
                    }
                    emit(true)
                }
>
            } catch (e: Exception) {
                emit(false)
            }
        }
    }

코드가 좀 길긴한데 코드를 더럽게 못짜서 그런가 싶다...하나씩 살펴보자

먼저 아래 코드로 데이터를 firestore에 올려준다. db.collection("post").document(postData.postId).set(data).await()

여기서! 굳이 데이터를 hashMap의 형태로 바꿔줄 필요는 없고 나는 image 데이터를 따로 올려주려고 하다보니 한번 다시 하나하나 직접 바꿔주었다. data class 형태 그대로 올려도 무방하다.

그리고 image 데이터가 사실 거의 메인인데... for 문을 통해 0 부터 imageList.count() or imageList.size까지 imageData의 downloadUrl을 해당 post에 updata 시켜준다. storage에 있는 이미지들을 한번에 변환시켜줄 수 있는 방법이 있는 지는 모르겠지만...내가 알아본 정보로는 없어서...그렇다 ㅠㅠ

다음 구문을 통해 내가 저장하고 싶은 image의 이름과 경로를 지정해준다.

storage.getReference("image").child("${currentUser}/${postData.postId}/${postData.createdAt}_${i}")

그 다음 나는 video와 image 두 가지 타입을 구분해줘야 했기 때문에 다음 구문을 작성했다.

  if (imageToUri.pathSegments?.contains("video") == true) {
                                storageRef.putFile(imageToUri).addOnSuccessListener {
                                    storageRef.downloadUrl.addOnSuccessListener { downloadUri ->
                                        imageList.add(
                                            ImageDataEntity(
                                                downloadUri.toString(),
                                                "video"
                                            )
                                        )
                                        val imageData =
                                            mapOf("imageList" to imageList.sortedBy { it.imageUri })
                                        db.collection("post").document(postData.postId)
                                            .update(imageData)
                                    }
                                }

if 문을 통해 만약 imageUri에 "video"가 포함되어 있다면 (이 부분은 Log로 직접 image와 video의 다른 점을 찾아야 합니다! 제가 사용한 imagePicker는 달라서...)

putFile 후 addOnSuccessListener로 putFile에 성공했을 때 storageRef.downloadUrl에서 downloadUri를 가져옵니다. (이 친구가 중요합니다!)

가져온 uri를 imageList에 담아줍니다. 저는 추후에 구분을 편하게 하기 위해 type: String과 Uri: String으로 값을 받아줬습니다.

이제 imageData를 아까 다른 postData를 set해준 경로에 update 시켜주면 됩니다. (이미지도 같은 방법으로 pathSegments에 contain("image")일 경우에 다음과 같이 진행해주면 됩니다!)

결과화면

다음과 같이 데이터가 잘 들어오는 모습을 볼 수 있습니다. . . . 만약 hilt를 사용하고 계신다면 di module을 통해 firebase @Provides 해야합니다! repository는 @Binds! . . .

참고문헌

https://moon-i.tistory.com/entry/Fragment-Result-API

https://rkdrkd-history.tistory.com/3

https://velog.io/@simsubeen/Android-Kotlin-Firebase-Storage-%EC%9D%B4%EB%AF%B8%EC%A7%80-%ED%8C%8C%EC%9D%BC-%EC%97%85%EB%A1%9C%EB%93%9C%EB%8B%A4%EC%9A%B4%EB%A1%9C%EB%93%9C%EC%82%AD%EC%A0%9C

사전설정

• 먼저 firebase에서 프로젝트의 이름을 정하고 프로젝트를 설정해준다.
  
• 저는 Firebase Crashlytics를 사용할 것이기 때문에 Google 애널리틱스를 사용하도록 설정했습니다. (추후에 Crash가 난 이유와 개선점을 Firebase에서 관리할 수 있도록!)
  
• 계정은 default로 설정해주고
  
• 프로젝트가 생성되면 다음 화면에서 자신의 프로젝트에 맞게 앱에 Firebase를 추가해주면 되는데 저는 안드로이드를 사용하고 있기 때문에 안드로이드를 추가해주겠습니다.
  
• 앱 등록에서 패키지명을 추가해줍니다. (저는 임의로 Test라는 프로젝트를 생성해서 만들어 줬습니다.)
  
• 그 다음 google-services.json 파일을 Project에 app 디렉토리에 넣어줍니다.
  
• 해당 plugin과 dependencies는 파이어 베이스의 설명대로 복사 해주시면 됩니다!
  
• 그러면 사전 설정은 끝납니다!
  (추후에 편하게 firebase SDK를 추가하고 싶으시면 tools에서 추가할 수 있습니다.)
  

• Add the...을 눌러서 편하게 SDK를 app에 추가해줄 수 있습니다.

회원가입 / 로그인

Domain layer

• 먼저 layer를 data, domain, ui 영역으로 나누어놨기 때문에 domain 영역에서 AuthRepository를 생성하여 회원 정보에 관한 메서드를 suspend fun으로 설정해놨습니다.

• 이후 suspend operator fun invoke를 통해 AuthRepository의 login과 signup을 return 하도록 UseCase를 만들어 주었습니다.

• LoginUseCase*

• SignUpUseCase*
  (반환 값을 사실 Result로 굳이 두지 않아도 됩니다. 그저 성공했을 때와 실패했을 때 예외처리를 두고 싶어서 만들어뒀습니다!)

Data layer

• data 영역의 AuthRepositoryImpl를 통해 메서드를 실체화 해주었습니다.

  class AuthRepositoryImpl @Inject constructor(
    private val db: FirebaseFirestore,
    private val auth: FirebaseAuth
  ) : AuthRepository {
    override suspend fun signUp(
        email: String,
        password: String,
        data: FirebaseUserData
    ): Result<String> {
        return try {
            val result = auth.createUserWithEmailAndPassword(email, password).await()
            val user = result.user
  >
            if (user != null) {
                db.collection("user").document(user.uid).set(data)
                    .addOnSuccessListener {
                        Log.d("debug_signup", "success")
                    }
                    .addOnFailureListener {
                        Log.d("debug_signup", "fail")
                    }
                Result.success("Success")
            } else {
                Result.failure(Exception("Fail"))
            }
        } catch (e: FirebaseAuthException) {
            Result.failure(Exception("FirebaseAuthException: ${e.message}"))
        } catch (e: FirebaseFirestoreException) {
            Result.failure(Exception("FirebaseFirestoreException: ${e.message}"))
        } catch (e: Exception) {
            Result.failure(Exception("Exception: ${e.message}"))
        }
    }
  >
    override suspend fun logIn(email: String, password: String): Result<String> {
        return try {
            auth.signInWithEmailAndPassword(email, password).await()
            Result.success("success")
        } catch (e: Exception) {
            return Result.failure(Exception("Exception: ${e.message}"))
        }
    }

• 여기서 FirebaseAuth에서 제공해주는 createUserWithEmailAndPassword() 메서드를 통해서 파라미터로 받은 email과 password를 통해 FirebaseAuth에 계정을 생성할 수 있다.
  (await() 함수는 코루틴 함수로 suspend 함수 내에서만 사용이 가능한데 await() 함수가 실행되면 코루틴은 결과가 반환될 때까지 기다리게 되면서 생성된 계정의 uid를 가져올 수 있게 해주었습니다.)

Ui layer

• ui layer에서는 viewmodel을 만들어 constructor로 LoginUseCase와 SignUpUseCase를 받아주고 fragment에서는 view에 대한 설정만 해줄 수 있도록 해주었습니다.

• ViewModel*

  @HiltViewModel
  class LoginViewModel @Inject constructor(
     private val logInUseCase: LogInUseCase
  ) : ViewModel() {
  >
     private val _loginEvent = Channel<CheckLogin> { }
     val loginEvent = _loginEvent.receiveAsFlow()
  >
     fun login(email: String, password: String) {
         viewModelScope.launch {
             val loginData = logInUseCase(email = email, password = password)
             if (loginData.isSuccess) {
                 _loginEvent.send(CheckLogin.LoginSuccess("환영합니다! ${email}님\uD83D\uDC4D"))
             } else {
                 _loginEvent.send(CheckLogin.LoginFail("이메일 및 비밀번호를 확인해주세요."))
             }
         }
     }
  }

• Fragment*

  private fun initView() {
  >
         binding.btnLogin.setOnClickListener {
             initLogin()
             collectFlow()
         }
     }
  >
     private fun collectFlow() {
  >
         viewLifecycleOwner.lifecycleScope.launch {
             repeatOnLifecycle(state = Lifecycle.State.STARTED) {
                 loginViewModel.loginEvent.collect { checkLogin ->
                     when (checkLogin) {
                         is CheckLogin.LoginSuccess -> {
                             Toast.makeText(requireContext(), checkLogin.message, Toast.LENGTH_SHORT)
                                 .show()
                             findNavController().navigate(R.id.action_loginFragment_to_mainFragment)
                         }
  >
                         is CheckLogin.LoginFail -> {
                             Toast.makeText(requireContext(), checkLogin.message, Toast.LENGTH_SHORT)
                                 .show()
                         }
                     }
                 }
             }
         }
     }
  >
     private fun initLogin() {
         val email = binding.etLoginEmail.text.toString()
         val password = binding.etLoginPassword.text.toString()
  >
         viewLifecycleOwner.lifecycleScope.launch {
             loginViewModel.login(email, password)
         }
     }

• 예전 팀 프로젝트를 많이 참고하면서 진행하였는데 가장 좋았던 부분이 sealed interface를 사용하여 로그인 성공했을 때와 실패했을 때의 data class를 나누어 동작을 다르게 설정해 줄 수있었던 점이 좋았다.

• viewmodel에서 loginEvent에 send한 예외처리 상황을 통해 fragment에서는 when문을 이용하여 loginEvent가 받은 LoginSuccess와 LoginFail일 때의 Toast 메세지를 다르게 설정해주어 sealed interface를 이용해보았다.
  내 실력으로는 사실 생각하기 어려웠을 것 같은데 예전 팀 프로젝트를 복기하면서 좋은 아이디어를 얻어 적용해 볼 수 있어서 편했던 것 같다.
  특히 회원가입 단계에서 예외처리가 굉장히 많이 들어갔어야 했는데 정말 유용했다.
  
• 회원가입 실패했을 때 각 상황에 맞게 message를 넣어주어 이 메세지를 view에서 Toast 메세지로 사용할 수 있도록 해주었다.

결과

• test용으로 이메일을 설정하여 회원가입을 하면 다음과 같이 Firebase 프로젝트에 계정이 생성되는 것을 볼 수 있다.

. . . . . 오늘은 Firebase를 통해 회원가입과 로그인을 구현하는 법을 작성해보았습니다. 아직 코드적으로나 여러 방면으로 부족해서 좀 더 심도있게 공부해보고 계속 열심히 해야겠다는 생각이 많이 듭니다 ㅠㅠ

FireStore에 데이터를 전송하는 부분도 작성은 되어있지만 이 부분은 다음에 작성해보겠습니다!

ViewBinding을 프래그먼트에서 사용하게 될 경우에 메모리 누수(Memory leak)과 관련하여 문제가 생길 수 있다. 이는 구글 문서에 나와있다.

(아래는 구글 문서 원본)

• 프래그먼트에서 뷰 결합 사용

  프래그먼트와 함께 사용할 결합 클래스 인스턴스를 설정하려면 프래그먼트의 onCreateView() 메서드에서 다음 단계를 따르세요.

1. 생성된 결합 클래스에 포함된 정적 inflate() 메서드를 호출합니다. 그러면 프래그먼트에서 사용할 결합 클래스 인스턴스가 생성됩니다.

2. getRoot() 메서드를 호출하거나 Kotlin 속성 문법을 사용하여 루트 뷰 참조를 가져옵니다.

3. onCreateView() 메서드에서 루트 뷰를 반환하여 화면의 활성 뷰로 만듭니다.

private var _binding: ResultProfileBinding? = null
// This property is only valid between onCreateView and
// onDestroyView.
private val binding get() = _binding!!

override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?
): View? {
    _binding = ResultProfileBinding.inflate(inflater, container, false)
    val view = binding.root
    return view
}

override fun onDestroyView() {
    super.onDestroyView()
    _binding = null
}

이렇게 프래그먼트에서 binding = null 처리를 해주는 이유는 아래 참고사항에 나와있다.

프래그먼트는 뷰보다 오래 지속되므로 프래그먼트의 onDestroyView() 메서드에서 결합 클래스 인스턴스 참조를 정리해야 한다고 한다.

이러한 현상때문에 메모리를 회수하려고 하여도 프래그먼트 뷰가 살아있게 되면서 회수하지 못하여 메모리 누수 현상이 일어나게 되는 것이라고 한다.

다음에는 baseFragment를 통해 반복되는 binding 코드를 줄일 수 있는 방법을 작성해봐야겠다.

참고 :

https://developer.android.com/topic/libraries/view-binding?hl=ko https://bignerdranch.tistory.com/65

어플을 처음 사용하는 분들이 사용법을 잘 모를 수 있기 때문에 어플 사용법을 따로 만들어서 sharedPreference를 이용해 어플을 처음 실행하면 페이지를 띄워주고 그 이후에는 세팅 페이지에서 다시 볼 수 있도록 설정했다.

• 
• 앱 사용 설명서 페이지를 누르면
• 피그마에서 만든 이미지를 통해서 안내해 줄 수 있도록 해주었다.
• 원래 레이아웃으로 작업하려고 했었는데 생각보다 프래그먼트랑 너무 많아져서 viewpager에 이미지를 넣어주는 방향으로 변경하였다.

하루의 마무리

• 이제 4일 남았다 ㅠㅠ 얼마 안남았다 화이팅

• 
• 채팅방 리스트를 보여주고
• 채팅방을 들어가면 실시간으로 채팅을 주고 받을 수 있다.
• 상단 공지를 클릭하면 채팅방에 대한 내용을 볼 수 있다.
• 날짜와 제목을 입력하고
• 정산하기 기능에서는 벌금과 벌금 납부 인원을 기입하면
• 지출해야할 정산 내역 결과를 볼 수 있다.
• 공유 버튼을 누르면 정산 내용을 공유 받을 수 있고
• 내역을 문자로 공유해 보았다.
• 정산완료를 누르지 않고 나가기를 누르면 정산 중에 입력되어있고
• 완료로 누르면 정산 내역으로 상태가 변경된다.

하루의 마무리

• 어플 제출하고 나서야 오랜만에 블로그 쓰는 것 같다 ㅠㅠ 이제 다시 자주 써야겠다.

○ 이 개인정보처리방침은 2023년 1월 1부터 적용됩니다.

제1조(개인정보의 처리 목적)

① 늦지마컴퍼니는 다음의 목적을 위하여 개인정보를 처리합니다. 처리하고 있는 개인정보는 다음의 목적 이외의 용도로는 이용되지 않으며, 이용 목적이 변경되는 경우에는 개인정보 보호법 제18조에 따라 별도의 동의를 받는 등 필요한 조치를 이행할 예정입니다.

1. 회원 가입 및 관리

• 회원 가입의사 확인, 각종 고지·통지 등을 목적으로 개인정보를 처리합니다.\n\n

제2조(개인정보의 처리 및 보유 기간)

① 늦지마 컴퍼니는 법령에 따른 개인정보 보유·이용기간 또는 정보주체로부터 개인정보를 수집 시에 동의받은 개인정보 보유·이용기간 내에서 개인정보를 처리·보유합니다.

② 각각의 개인정보 처리 및 보유기간은 다음과 같습니다.

1. 홈페이지 회원 가입 및 관리 : 홈페이지 탈퇴시까지 다만, 다음의 사유에 해당하는 경우에는 해당 사유 종료시까지 1) 관계 법령 위반에 따른 수사·조사 등이 진행중인 경우에는 해당 수사·조사 종료시까지\n\n

제3조(개인정보의 제3자 제공)

① 늦지마컴퍼니는 정보주체의 동의, 법률의 특별한 규정 등 개인정보 보호법 제17조 및 제18조에 해당하는 경우에만 개인정보를 제3자에게 제공하며, 정보 주체의 사전 동의 없이는 본래의 범위를 초과하여 처리하거나 제3자에게 제공하지 않습니다.

제4조(개인정보처리의 위탁에 관한 사항(해당되는 경우에만 정한다.))

제5조(정보주체와 법정대리인의 권리ㆍ의무 및 그 행사방법에 관한 사항) ① 정보주체는 늦지마컴퍼니에 대해 언제든지 개인정보 열람·정정·삭제·처리정지 요구 등의 권리를 행사할 수 있습니다. ② 제1항에 따른 권리 행사는 늦지마컴퍼니에 대해 개인정보 보호법 시행령 제41조제1항에 따라 서면, 전자우편, 모사전송(FAX) 등을 통하여 하실 수 있으며, 늦지마컴퍼니는 이에 대해 지체없이 조치하겠습니다.

• [시행규칙 별지 제8호] 개인정보(열람, 정정·삭제, 처리정지) 요구서 ③ 제1항에 따른 권리 행사는 정보주체의 법정대리인이나 위임을 받은 자 등 대리인을 통하여 하실 수 있습니다. 이 경우 개인정보 보호법 시행규칙 별지 제11호 서식에 따른 위임장을 제출하셔야 합니다.
  • [시행규칙 별지 제11호] 위임장 ④ 개인정보 열람 및 처리정지 요구는 개인정보보호법 제35조 제5항, 제37조 제2항에 의하여 정보주체의 권리가 제한 될 수 있습니다. ⑤ 개인정보의 정정 및 삭제 요구는 다른 법령에서 그 개인정보가 수집 대상으로 명시되어 있는 경우에는 그 삭제를 요구할 수 없습니다. ⑥ 늦지마컴퍼니는 정보주체 권리에 따른 열람의 요구, 정정·삭제의 요구, 처리정지의 요구 시 열람 등 요구를 한 자가 본인이거나 정당한 대리인인지를 확인합니다.

제6조(처리하는 개인정보 항목) ① 늦지마컴퍼니는 다음의 개인정보 항목을 처리하고 있습니다.

1. 개인정보파일 명칭 : 홈페이지 회원정보
2. 개인정보 항목 : (필수항목) 아이디, 비밀번호, 이름(or nick-name), 이메일 ② 인터넷 서비스 이용과정에서 아래 개인정보 항목이 자동으로 생성되어 수집될 수 있습니다.

• IP주소, 쿠키, MAC주소, 서비스 이용기록, 방문기록, 불량 이용기록 등

제7조(개인정보의 파기) ① 늦지마컴퍼니는 개인정보 보유기간의 경과, 처리목적 달성 등 개인정보가 불필요하게 되었을 때에는 지체없이 해당 개인정보를 파기합니다. ② 정보주체로부터 동의받은 개인정보 보유기간이 경과하거나 처리목적이 달성되었음에도 불구하고 다른 법령에 따라 개인정보를 계속 보존하여야 하는 경우에는, 해당 개인정보(또는 개인정보파일)을 별도의 데이터베이스(DB)로 옮기거나 보관장소를 달리하여 보존합니다. ③ 개인정보 파기의 절차 및 방법은 다음과 같습니다.

1. 파기절차

• 늦지만컴퍼니는 파기하여야 하는 개인정보(또는 개인정보파일)에 대해 개인정보 파기계획을 수립하여 파기합니다.
• 늦지만컴퍼니는 파기 사유가 발생한 개인정보(또는 개인정보파일)을 선정하고, 개인정보 보호총괄책임자의 승인을 받아 개인정보(또는 개인정보파일)을 파기합니다.

2. 파기방법

• 늦지만컴퍼니는 전자적 파일 형태로 기록·저장된 개인정보는 기록을 재생할 수 없도록 파기하며, 종이 문서에 기록·저장된 개인정보가 있다면 분쇄기로 분쇄하거나 소각하여 파기합니다.

제8조(개인정보의 안전성 확보조치) ① 늦지마컴퍼니는 개인정보의 안전성 확보를 위해 다음과 같은 조치를 취하고 있습니다.

1. 정기적인 자체 감사 실시

• 개인정보 취급 관련 안정성 확보를 위해 정기적(분기 1회)으로 자체 감사를 실시하고 있습니다.

제9조(개인정보 자동 수집 장치의 설치·운영 및 거부에 관한 사항) ① 늦지마컴퍼니는 정보주체의 이용정보를 저장하고 수시로 불러오는 를 사용하지 않습니다.

제10조(개인정보 보호책임자) ① 늦지마컴퍼니는 개인정보 처리에 관한 업무를 총괄해서 책임지고, 개인정보 처리와 관련한 정보주체의 불만처리 및 피해구제 등을 위하여 아래와 같이 개인정보 보호책임자를 지정하고 있습니다.

• 개인정보 보호책임자 부서명 : 늦지마 컴퍼니 성명 : 김재현, 임채명, 장규식, 최지원, 박혜란 직급 : 리더, 부리더, 팀원, 팀원, 팀원 연락처 : onecoin789@gmail.com, limchaem0318@gmail.com, jgs288@gmail.com, sp202401jw@gmail.com, tnfl2644@gmail.com

제11조(개인정보 열람청구) ① 정보주체는 개인정보 보호법 제35조에 따른 개인정보의 열람 청구를 아래의 부서에 할 수 있습니다. 늦지마컴퍼니는 정보주체의 개인정보 열람청구가 신속하게 처리되도록 노력하겠습니다. ② 정보주체께서는 모든 개인정보 보호 관련 문의, 불만처리, 피해구제 등에 관한 사항을 개인정보 보호책임자 및 담당부서로 문의하실 수 있습니다. 늦지마컴퍼니는 정보주체의 문의에 대해 지체 없이 답변 및 처리해드릴 것입니다.

• 개인정보 열람청구 접수·처리 부서 (개인정보 보호책임자와 동일)

제12조(권익침해 구제방법) ① 정보주체는 개인정보침해로 인한 구제를 받기 위하여 개인정보분쟁조정위원회, 한국인터넷진흥원 개인정보침해신고센터 등에 분쟁해결이나 상담 등을 신청할 수 있습니다. 이 밖에 기타 개인정보침해의 신고, 상담에 대하여는 아래의 기관에 문의하시기 바랍니다.

1. 개인정보분쟁조정위원회 : (국번없이) 1833-6972 (www.kopico.go.kr)
2. 개인정보침해신고센터 : (국번없이) 118 (privacy.kisa.or.kr)
3. 대검찰청 : (국번없이) 1301 (www.spo.go.kr)
4. 경찰청 : (국번없이) 182 (ecrm.cyber.go.kr)

제13조(개인정보 처리방침 변경) ① 이 개인정보 처리방침은 2022. 08. 22부터 적용됩니다.

• 
• 문의하기 페이지로 들어가면 E-mail로 문의하는 기능과 오픈 채팅방이 있다.
• E-mail은 개발자 계정으로 등록된 gmail을 볼 수 있도록 설정해두었다.
• 개인정보 처리방침, 약관 등 동의 사항도 따로 마련해두었다. 원래는 앱 버전 항목을 따로 설정해두었는데 공간이 너무 많이 남아서 오른쪽 하단에 표시하도록 해두었다
• 오픈 채팅방은 카카오톡 오픈 채팅방과 디스코드 서버를 만들어서 공유해두었다.
• 앱을 만들면서 사용한 오픈소스 라이선스를 따로 넣었고
• 클릭하면 해당 페이지로 이동할 수 있다.

하루의 마무리

• 이제 거의 다 채워간다 ㅠㅠ 내일은 recyclerview 만들어야한다 ㅠㅠ

• 
• 사이드 시트를 이용해서 설정화면을 보여줄까 했는데 이 부분은 프래그먼트로 보여주기로 수정하였다.
• 약속에 대한 정보를 입력하지 않으면 토스트 메세지를 통해 입력하도록 설정해주었다.
• 목적지에 대한 정보도 동일!
• 채팅방에서는 오른쪽 위 지도 표시를 누르면 현재 위치부터 목적지까지의 거리, 소요시간, 도착시간을 볼 수 있도록 설정하였다.
• 친구 요청에서는 내가 보낸 친구 요청을 볼 수 있도록 설정해 주셨다.

하루의 마무리

• 중간 발표때문에 정신이 없어서 한동안 TIL을 못썼다 ㅠㅠ 다시 열심히 써봐야겠다.

• 
• 약속 제목, 날짜, 시간, 내용을 입력하면
• 목적지를 검색하여 정할 수 있는 화면으로 이동하고
• 검색하면 바텀시트를 통해 리스트를 보여주도록 설정했다.
• 부산역을 선택하였는데 해당 위도, 경도에 맞는 위치에 마커가 찍힌다.
• 약속을 과정을 완료하면 결과 페이지를 통해 약속 내용을 다시 한번 확인한다.

하루의 마무리

• 코드가 좀 뒤죽박죽 안좋다고 생각되는 코드가 많아서 튜터님께 여쭤보고 수정해야한다 ㅠㅠ

• api 통신 연결하고 뭔가 잘못된 곳이 없었다고 생각했는데 값이 안받아와졌다 ㅠㅠ

  java.lang.IllegalArgumentException: Unable to create converter for class com.example.donotlate.feature.searchPlace.data.model.Directions for method Goo

• 계속 다음과 같은 에러 코드만 떠서 구글링을 해도 원하는 대답이 안떴는데... 팀원분께서 구글링 해주셔서 data class 한번 확인해 보라고 하셔서 확인했더니
• 멍청한 놈이 아닐 수 없다...
• 고치고 코드 돌렸더니
• 테스트 삼아 받아보려고 했던 코드 받아와지고...
• 테스트 삼아 만든 EditText에 해당 값 출발장소, 도착장소 입력해주면
• 다음과 같이 출발시간, 도착시간, 거리, 걸리는 시간을 받아올 수 있다!

하루의 마무리

• 오늘의 3시간을 날린 교훈 : 좀 더 침착하게 일을 해보자...ㅠㅠ

• 
• 놀거리로 들어오면 다음과 같은 화면이 보이고
• EditText가 비어있는채로 검색을 누르면 다음과 같은 이미지와 텍스트가 나온다.
• 리스트가 나오고 리스트를 누르면
• 리스트에 대한 가게 이름, 주소, 번호, 영업시간, 위치 정보를 받아온다.
• 위치 정보를 보면 해당 가게에 대한 위도 경도 값으로 마커를 찍어놓았다.

하루의 마무리

• 데이터 넘겨주는 파트는 금방 끝났는데 마커 찍는데 오래걸렸다 흑 ㅠㅠ

  내일은 길찾기 파트를 끝내봐야겠다.

• 
• 일단 main 디자인은 이렇게 살짝 바꿨다
• 놀거리를 누르면 다음과 같은 화면이 되고
• 검색하면 다음과 같이 연관 키워드에 대한 검색결과를 가져올 수 있었다.

하루의 마무리

• 바쁘다 바빠 ㅠㅠ

• 
• 현재 날짜와 현재 시각을 받아오고
• datePicker를 통해 날짜를 선택하면
• 다음과 같이 날짜가 바뀐다.
• timePicker를 통해 시간을 선택하면
• 시간도 바꿀 수 있다!
• 바뀐 data값도 확인했다. 변수에 담아 놨으니 넘겨주기만 하면 끝!

하루의 마무리

• button 속성을 ripple effect를 주고 싶어서 meterial을 사용했는데 튜터님께서 안된다고 하셔서 style에서 설정해줘서 background로 넣어주는 것까지만 마무리하고 자야겠다 ㅠㅠ