defee headline api 연동 테스트 및 잡담

헤드라인 api 연동 해결

재희님이 cors를 해결했다고 해서 테스트를 진행했다. 잠깐 디코하면서 코드를 실행했을 땐 코스에러가 없었는데, 재부팅 하고 재실행하니까 다시 발생했다. 이쯤되면 아마 앱 개발에서는 코스에러가 발생하지 않아서 적용이 안되는 걸수도 있을거라 결국 에뮬레이터 문제를 해결해서 사용해야되나 싶었는데, 세팅 수정으로 코스에러를 막을 수 있는 블로그를 발견했다.

https://kjmhercules.tistory.com/8

[해결방법] Flutter CORS 에러 없애기

해당 방식은 정확히는 올바른 방식은 아니고 개발에 방해되지 않게 플러터에서 const를 안써도 에러가 발생하지 않는, 임시방편의 방식이다.

브라우저를 개발할 땐 당연히 코스 에러를 해결해야하지만, 앱에선 브라우저에 접근할 일이 없으니 개발할 때 사용해도 무방할 거라 생각하여 세팅을 수정했다.

코스가 해결되니 정상적으로 데이터를 받아오는 걸 확인할 수 있었다.

import 'package:defeefront/screens/headline/widgets/category.dart';
import 'package:defeefront/screens/headline/widgets/other_post.dart';
import 'package:defeefront/screens/headline/widgets/popular.dart';
import 'package:defeefront/screens/headline/widgets/slide_post.dart';
import 'package:defeefront/widgets/basescreen.dart';
import 'package:defeefront/widgets/gallary_view_post.dart';
import 'package:flutter/material.dart';
import 'package:dio/dio.dart';

class Headline extends StatefulWidget {
  const Headline({super.key});

  @override
  _HeadlineState createState() => _HeadlineState();
}

class _HeadlineState extends State<Headline> {
  List<dynamic> posts = [];
  bool isLoading = true;

  @override
  void initState() {
    super.initState();
    fetchPosts();
  }

  Future<void> fetchPosts() async {
    try {
      Dio dio = Dio();
      final response = await dio.get('http://localhost:8080/api/posts');

      setState(() {
        posts = response.data;
        isLoading = false;
      });
    } catch (e) {
      // 오류 처리
      if (e is DioError) {
        // DioError일 경우
        print('Error: ${e.response?.statusCode}');
        print('Error Message: ${e.message}');
      } else {
        print('Unexpected Error: $e');
      }

      setState(() {
        isLoading = false;
      });
    }
  }

  @override
  Widget build(BuildContext context) {
    return BaseScreen(
      child: Padding(
        padding: const EdgeInsets.symmetric(horizontal: 30.0),
        child: isLoading
            ? const Center(child: CircularProgressIndicator())
            : Column(
                children: [
                  // 카테고리
                  Category(),
                  // 인기 포스트
                  GestureDetector(
                    onTap: () {
                      final postUrl = posts[0]['url'];
                      Navigator.pushNamed(
                        context,
                        '/post',
                        arguments: postUrl,
                      );
                    },
                    child: GallaryViewPost(post: posts[0]),
                  ),
                  // 포스트 컨텐츠
                  SlidePost(posts: posts),
                  // 하단 나머지 포스트
                  OtherPost(posts: posts),
                ],
              ),
      ),
    );
  }
}

dio를 사용해서 api 요청을 진행했으며, 헤드라인 구조에 맞게 이 후 첫 부분은 조회수나 구독같은 특정 데이터가 가장 높은 한 개의 게시글을 출력해주고, 포스트 컨텐츠의 경우는 유저가 지정해놓은 키워드를 대상으로 맞춤 게시글을 출력, 

그 아래의 게시글들은 최신 글들을 쭉 나열하는 식으로 변경할 예정이다.

지금은 api 경로가 /posts로만 되어있지만 나중엔 페이지네이션으로 page=와 count=를 사용해 각 페이지별로 데이터를 가져와 최적화를 하는게 목표이다.

 

그리고 iframe으로 블로그 자체를 가져올 수 있는 post페이지로 이동하기 위해 navigate로 연결을 해봤는데, 에러 발생하더라.

웹 뷰 패키지에 대한 에러로 해당 경로의 진입에서 박혔다는 소린데, 시현이가 이미 웹 뷰 패키지를 설치해서 테스트해봤는데 똑같이 발생한다고 했다. 애플 에뮬레이터에선 정상 작동하는 걸 보아 코드는 올바르게 작성했으나, 앱 기능을 브라우저로 접근하려 해서 생기는 문제일 것 같아 일단은 넘어가기로 했다.

---

공백의 잡담

근 2주간 진짜 많은 일이 있었다.. 아무것도 못하고 컴퓨터 수리만 하고있으니 정신 나갈뻔

 

그동안 도커 컨테이너 생성에 실패하던 원인 중 하나가 C드라이브가 꽉차있어서 컨테이너 데이터와 캐시가 들어가질 못해 생성이 안됐던 문제가 있었다.

c드라이브 용량 자체가 250기가로 너무 적었던 탓도 있어 이번에 sata 스스디 1테라를 큰맘먹고 샀는데, 프로그램을 사용해서 윈도우 데이터를 복사하고 디스크를 변경하던 과정에서 스스디가 뻑이 났다;

 

처음에 부팅도 안되가지고 다시 기존 디스크에서 데이터 복사해서 몇번 만지다보니 다행히 인식이 됐다. 근데 부팅 후 윈도우를 실행시켰더니 바로 블루스크린이 날 반겨주더라

덕분에 디스크 다시 날리고 새로 옮겨서 해결했다. 1차는 해결됐고, 기존 윈도우 데이터들이 오래되서 쓸모없는 파일들이 많아 포맷을 진행했는데, 중요 문서들은 다 옮겼으나 환경변수와 코딩 프로그램을 생각을 못했다.

초기화하고 프로그램과 환경변수들을 설정하는데, 이전 값과 뭔가 다른지 인식이 잘 안되가지고 뺑이좀 쳤다.

 

용량이 엄청나게 늘어나니까 그동안 10분넘게 걸리던 부팅도 30초도 안되서 켜지는거보고 시간있을 때 진작 늘릴껄 너무 후회했다. 상황에 놓여야 그때서야 해결하려고 해서 생긴 문제였다.

이 과정에서 다른 부분은 해결됐는데, 에뮬레이터가 연동이 안되고 계속 블루스크린이 발생하여 당분간은 크롬으로 작업하고 에뮬레이터는 봉인하려고 한다.

스스디를 교체하고 도커랑 로컬 클라이언트랑 이것저것 키다보니 좀 버벅이는 문제가 있어서, 이참에 램도 바꾸려고 구매했는데 그러지 말걸 그랬다.

 

기존 램이 ddr4 8gb 2개를 장착중인데, 체감을 위해 16gb 2개로 변경하려고 야무지게 샀다.

그리고 급한 나머지 바로 실수했다. ㅎㅎ 전력을 확실히 차단하고 교체를 진행했어야 했는데, 끄기만하고 파워를 그대로 연결한 상태에서 램교체를 진행했다.

바로 인식못해서 뻑나버렸고 스스디 교체할 때가 생각나서 또 그 난리날까봐 소름돋았다. 그대로 3일간 램 인식 시키느라 개고생만 하면서 차라리 공부하고 싶더라 :-(

한가지 간과한게, 본인 메인보드는 램 최대 출력을 2666으로 제한하고 있어서 이 부분을 확인하고 램을 구매했어야 했는데, ddr4는 웬만하면 다 호환된다고 들어서 가장 인기많은 시리즈인 에센코어인가 해당 램을 선택했다.

당일 산 폰 다루듯이 세상에서 제일 조심스럽게 수리를 진행했고 다행히 정상적으로 인식되었다. 컴퓨터 성능 체크나 상향하는 법을 잘 몰라서 구글링 좀 하면서 수동 오버클럭을 해줬는데, XMT라는 미리 세팅해둔 클럭 프리셋 없이 직접 만지게 되면 프리징 현상이 빈번하게 발생한다고 하더라.

근데 지금 상황에서 돌아가게 해야하기 때문에 어쩔 수 없었고, 블로그 쓰는 당일 밤까지 컴퓨터를 사용하며 아직은 프리징의 흔적은 없었다. 컴퓨터 세팅 만지고 있으니 예전에 공단에서 유지보수 배울 때 생각나서 좀 반갑기도 했다.

사용하다가 프리징 발생 시 해결이 안되면 다시 봉인을 풀어야 하기 때문에 기존에 사용하던 램은 배송할 때 온 은박지로 잘 담아 보관했다. 

시행착오를 겪었으니 사용하다가 또 고장나면 이번엔 바로 고쳐버리겠다. 누가 이기나 해보자.