파파비의 블로그

여기 보면 circle 아바타가 네모 위에 이상하게 겹쳐있는 것을 볼 수 있다 과연 어떻게 한 것일까? stack 위젯 + positioned 위젯을 활용했다. stack으로 겹치게 했고 positioned로 구체적인 위치를 조정했다 특이 stack에는 overflow라는 속성이 있는데, 여기 값을 조정하면 stack을 벗어나도 지워지지 않는다.(clipped 되지 않는다) 스택에서 컨테이너 및에 이렇게 포지션드 위젯과 overflow 속성을 따로 해두었다.

파이어 스토리지를 시작하면 하나의 버킷이 부여된다. 우리는 그 버킷안에서 폴더를 만들고 파일을 넣고 할 수 있다. 프로젝트 하나 당 하나의 버킷을 부여 받을 수 있다. (돈 주면 더 할 수 있긴 한데, 폴더도 만들 수 있어서 굳이..? 여러개 프로젝트에도 이거 하나면 충분) 버킷의 개념, 이해했는가? ㅇㅋ! 여기가 버킷의 위치이다. 버킷으로 가는 방법을 코드로 보여주겠다. 파이어스토어 sdk를 깐 뒤에. 이렇게 싱글톤을 받고, ref()를 사용하면 된다. 여기부터 이제 어떤 파일을 가져올지, 뭐 등등의 작업등을 지시하면 된다. 더 구체적인 부분들을 살펴보자 잠깐, 그전에 규칙부터 잠시 살펴보자 파이어 스토어랑 비슷한 느낌이지 않는가? 맞다 거의 똑같다 대신 collection, documents 대신 b..

메시지를 보낼 때, 누가 보냈는지 이름이라도 알면 좋을 것 같다. 이렇게 말이다. 그런데 문제가 있다. 저 이름은 users라는 컬렉션안에 있다. 그러면 다시 관련된 정보를 future로 가져와서, await로 해서 보여주어야할까? 유저id를 버블위젯만들 때 받으니까, 생성 버블 위젯을 만들때, futureBuilder를 넣어서 유저 이름 정보를 가져오면 어떨까? 가능하다! 다만 매우 비효율적이다, 채팅이 새로 만들어질 때마다, futurebuilder가 실행되어서 보기도 안좋고, 이상하다 딱 한번만 futurebuilder에서 정보를 가져오면 그만인데, 자꾸만드는게 안좋다. 그럴 경우에는 메시지 정보를 저장할 때, user name을 가져와서, message쪽에 한번 더 저장해버리면 된다. 그러면 da..

채팅창 같은 것을 만들 때, 본인 채팅과 남의 채팅의 보여지는 것이 다르다. 그것을 확인하는 방법을 보고자 한다. 1. 저장하기 일단 Data에 누가 해당 메시지를 적었는지 유저 id를 함께 저장하면된다. 어렵지 않다. 유저id 정보는 auth를 통해서 알 수 있다. FirebaseAuth.instance.currentUser() 를 통해 객체를 받고 거기서 uid에 접근하면 된다. 다만 여기서 하나의 문제는 FirebaseAuth.instance.currentUser()는 future형태이다. 그래서 await으로 한번 기다린 객체를 받은 후에 uid에 접근할 수 있다는 것이다. 버튼을 눌렀을 때, 콜백 메소드에서 진행하는 것은 큰 무리가 없다. 2.데이터 불러와서 확인하고 채팅버블 만들기 1) 퓨처빌..

정렬되는 기준은 무작위로 랜덤하게 생성된 id이다. 그렇기 때문에 우리가 마음대로 조종이 불가능. 따라서 우리는 문서에 data 안에 timestamp 따로 넣어서 여기에 맞게 정렬할 것이다. 요로코롬 timeStamp 데이터를 추가해주고, (fireStore는 Timestamp 객체를 자료로 받을 수 있다. 좋다,..) FireStore에서 읽어올 때, 순서를 유의하게 만든다. orderBy를 사용해서 말이다! 여기 스트림 부분을 보면, 컬렉션 다음에 snapshot 전에, orderby (필드) 로 기준점을 정해주고, 오름차순인지 내림차순인지 정해주는데, 우리는 descending: true로 설정해서 원하는대로 작동되게 했다.

자세한 사항은 꼭 문서를 읽어보고 결정해라 특이 진지한 제품을 만들거면 꼭 읽어보길... https://firebase.google.com/docs/firestore/security/rules-structure?authuser=0 Cloud Firestore 보안 규칙 구성 | Firebase Cloud Firestore 보안 규칙을 통해 데이터베이스의 문서 및 컬렉션 액세스를 제어할 수 있습니다. 유연한 규칙 구문을 사용하면 전체 데이터베이스에 대한 모든 쓰기 작업부터 특정 문서에 대한 작�� firebase.google.com 내가 설정한 코드를 보고 한번 배워보자 match 라는 개념은 일단 path를 가르키고 여기에 해당하는 rules를 할 수 있게 해준다. match /users/{uid} 에서..

Firebase sdk를 쓰면 매우매우 편리한 점이 있다. 로그인 후, 알아서 토큰 관리를 해준다. 토큰을 저장하고, 혹시 앱이 꺼졌다가 켜지면 존재하는 토큰을 확인하고, 혹시 그 토큰이 유효하면 알아서 또 처리를 해준다. 그야말로 익스트림리 컨비니언트 하다. 자 그래서, 우리는 이제 메인화면에서 곧장 Auth Screen을 띄우는게 아니라 토큰을 확인하고, 존재하면(유효하면 존재함, 오래되면 알아서 폐기됨) 바로 ChatScreen을 띄우고, 그렇지 않으면 Auth Screen을 띄우게 할 것이다. 그리고 또 하나 좋은 점은 Firebase Auth는 이 유저로그인 상태를 Stream으로 제공한다는 사실이다. 따라서, StreamBuilder로 Auth를 띄울지, Chat을 띄울지 결정할 수 있다는 얘..

rest api를 활용한 경우 서버에 우리의 api key를 함께 보내면서 로그인을 확인 받고, 거기서 토큰을 받아서 로그인이 인정되는 시간까지 하다가 뭐 또 연장하거나 등등의 절차를 우리가 직접 처리했다. 그런데 sdk를 쓰면 이미 서버와 긴밀하게 연결이 되어 있기 때문에 토큰이런거 다 필요없고 그냥 더 간단하게 할 수 있다. 사실은 sdk가 뒤에서 다 작업을 해주는데 우리는 간편하게 몇줄의 코딩으로 처리할 수 있는 것이다. 또한 rest api의 경우에는 그냥 백엔드 서버랑 통신하는거라서 아무런 연결절차도 필요없지만 파이어베이스의 경우 이미 해둔 연결작업들이 있어서, 더 간편하게 할 수 있다. 이제 코드를 살펴보자 1. 먼저 Firebase auth 패키지를 import해야 한다 https://pub..