월루를 꿈꾸는 대학생

웹서비스 개발은 거의 틀이 비슷함 ex) 로그인 , 게시판, 검증 등등 Firebase - 이런 공통적인 백엔드 부분을 만들어주는 서비스 - 웹서비스를 대신 만들어주니까 프론트에 집중해서 개발 가능 코딩해야할 부분은 단 한 개 - 유저가 버튼 눌렀을 때 서버로 데이터 전송 - 그 외 자잘한거는 firebase가 해줌 요금 https://firebase.google.com/pricing?hl=ja Firebase Pricing Firebase を無料で開始し、世界中の何百万人ものユーザーに向けてスケールアップしましょう。発生する費用は使用した分のみです。 firebase.google.com 장점 - 그냥 서버단 작업을 간편하게 할 수 있음 - 스케일업 등 알아서 해줌 단점 - 비쌈 (아무래도 직접 서버 만들어서 서비스..

먼저 api가 필요함 https://www.themoviedb.org/ The Movie Database (TMDB) Welcome. Millions of movies, TV shows and people to discover. Explore now. www.themoviedb.org TMDB에서 회원가입을 한 후 api 문서 홈페이지 접속 https://developers.themoviedb.org/3/movies/get-popular-movies API Docs developers.themoviedb.org 유명한 영화 순위를 받아 올거니까 해당 api를 사용한다 postman으로 리퀘스트 보내보고 확인 네비게이션 바텀 바 만들 때를 위해서 provider 가 하나 더 필요해짐 import 'pack..

Provider 설치 https://pub.dev/packages/provider/install provider | Flutter Package A wrapper around InheritedWidget to make them easier to use and more reusable. pub.dev dependencies: provider: ^6.0.4 --- import 'package:flutter/cupertino.dart'; //해당 클래스 안에서 선언된 멤버변수 상태관리를 provider가 하도록 class CountProvider extends ChangeNotifier { // 외부 접근 금지 int _count = 0; String value = "test"; } main.dart @ove..

setState - build 메서드를 호출해서 새로 랜더링함 - 하단 전체 위젯을 다 리빌드하기에 비효율적!! - 동시에 다른 위젯의 state를 업데이트 시키지 못함 Provider - create 파라미터에서 모델을 받고 이를 하위 child 밑에 위젯들이 참조해서 사용이가능 - 하나의 데이터를 하위 위젯에서 바로 바로 사용이 가능하기 때문에 편리 - 쉽게 위젯이 데이터에 접근이 가능 with ChangeNotifier - mixin - within -> 상속과 별개로 사용 다트에서 다중상속을 허용하지 않기 때문에 결속력은 약하지만 여러개 붙여서 사용할 수 있도록 사용 - 모델이 변화하면 ChangeNotifier의 notifyListeneres를 통해서 ChangeNotifiter를 Listen하..

mvc 패턴의 불편한 점을 개선한 것이 MVP -> MVVM 점점 발전해 가는 중 어떤 것이 개선 되었는가 ..? 기능별 역할별 분리를 해 서로의 의존성을 최소화 하는 중 MVC -> View와 Model간의 의존성이 높음 MVVM Model : 데이터와 관련있는 모델 View Model : View에서 사용되는 모델 --> 컨트롤러랑 비슷? mvc - 컨트롤러에서 모델의 갱신을 감지하고 뷰에 갱신 요청을 함 - 컨트롤러가 뷰랑 모델 둘 다 신경 써야함 MVVM - 컨트롤러가 뷰를 신경쓰지 않음.. 모델 변경되어도 변경사항만 수정하고 View에 요청 따윈 없음 VIew에 스트림 빌더 사용 StreamBuilder( stream: viewModel.mvvmStream, builder: ((context, ..

패턴은 총 3가지 1. mvc 2. mvp 3. mvvm 세상에 완벽한 패턴은 없음 mvc 쓰다가 부족함을 느끼고 개선하기 위해 mvp 그리고 마지막 mvvm이 나옴 디자인 패턴은 모두 기능성 역할을 구분하고 의존성을 최소하 하는 것이 목표 디자인 패턴은 그냥 코드의 형식을 정의한 것 뿐 확장된 기능을 여러 곳에서 사용할 수 있도록 거치고 거치고 거쳐서 만들어진 것 ex_ 싱글톤 패턴, 옵저버 패턴 등등 디자인 패턴을 써야하는 이유 - 내가 짠 코드는 내가 작성한 거니까 잘 아는데 협업시 다른 개발자는 보기 힘듦 .. 공통 규격?이 필요 - 이미 다른 사람이 열심히 검증하고 써왔던 코드가 있는데 안 쓸 이유가 없다 = 시간 절약 * 혼자 개발하는 경우 일단 기능부터 빨리 구현하는 것이 답일 수도 있다. ..