[개발] #06 중섭 대응 업데이트 (리모델링)

<Fig. 00> 230906 업뎃 하루 전 완료..!

 

 

<Fig. 01> 첫 의견, 감사합니다 (__)

생각해보니, 스토어에 올리고 심사 기간동안 아무것도 못 할 바에는 중국어라도 중섭의 내용을 보면 미래시를 보는데 더욱 좋을 거 같아서 중섭 DB 기능을 업데이트를 진행하기로 했습니다!

 

그런데...

 

<Fig. 02>

지금 보니 글로벌 데이터와 중국 데이터의 모델이 달라진..?

 

 

그래서 언젠가 모델링을 Equatable, JsonSerializable를 이용해서 다시 하고 싶기도 했기에

이번 기회에 모델링을 새로 하며, 동시에 중섭도 대응할 수 있도록 하기로 결정했습니다.

 

 

1. DB Region

 

<Fig. 03>

그 전에 일단 region을 설정하고 Bloc으로 관리,

Bloc을 생성할 때 의존성을 주입(일부 제외)하여 편리하게 게임 데이터 주소를 가져올 수 있도록 했습니다.

 

 

2. Modeling

그 다음은 모델을 새로 만들어줍니다.

 

<Fig. 04>

다만, 글로벌 서버와 중국 서버 데이터 모두 받을 수 있도록 해야했기에 조금 머리가 아팠습니다..

위 모델의 경우에는 levelType이 글로벌은 0, 1, 2와 같은 int로 표현되었는데,

중국 서버는 NORMAL, ELITE, BOSS와 같이 String으로 표현되어서..

결국은 int를 String으로 형변환 해서 사용하기로 결정했습니다.

 

 

모델링을 하면서 코드 재사용성을 높이기 위해 generic를 사용했는데,

이걸 사용하면서 JsonSeriralizable의 몇 가지 기능을 알게되어 소개합니다.

 

 

a. @JsonSeriralizable.expliciteToJson

<Fig. 04>를 참고해주세요.

기본값은 false지만, true로 설정하면 toJson 함수를 호출할 때, 명시적으로 toJson 메서드를 호출하게 됩니다.

이를 클래스A 내부에 클래스B 변수를 사용할 때 무의식적으로 사용하면 좋습니다.

왜냐하면, 클래스A를 직렬화(toJson)할 때, 인자로 인스턴스A를 넘겨주기만 하면, 내부에서는 인스턴스B가 알아서 직렬화(명시적으로 인스턴스 뒤에 .toJson을 호출하도록 하는 것임) 되기 때문입니다.

 

따라서 사용할 때 주의점은 반드시 클래스B의 toJson 함수가 정의되어 있어야 합니다.

 

하지만, 내부에 클래스 변수가 없을경우 사용하지 않는 것이 좋습니다.

기본형에도 반드시 toJson이 붙기 때문에 성능상 이슈가 생길 가능성이 있습니다.

클래스 변수에만 toJson을 명시하고 싶을 경우에는 해당 변수 상단에 @JsonKey 어노테이션에서 toJson 함수를 별도로 지정하는 방법이 있습니다만, 그렇게 까지 피곤함을 감수할 정도는 아닙니다.

 

 

b. @JsonSeriralizable.createToJson

기본값은 true지만, false로 설정하면 g.dart 파일에 toJson 함수 생성을 막아줍니다.

단순히 코드 사이즈를 줄이는데 의의가 있습니다.

 

추가로, toJson을 사용하지 않는다면, a. expliciteToJson역시 사용할 필요가 없습니다.

 

 

<Fig. 05>

c. @JsonSeriralizable.genericArgumentFactories

<Fig. 05>를 참고해주세요.

기본값은 false지만, true로 하면, 제네릭 멤버 변수의 직렬화/역직렬화를 지원하게 됩니다.

단, fromJson, toJson 함수에 두 번째 인자로 제네릭을 적절하게 변환해주는 콜백함수를 넣어줘야 합니다.

 

제 경우에는 List<String> 형식과 String 형식을 별도로 처리해 주었습니다.

List는 그렇다고 쳐도, String까지 별도로 처리한 이유는, 앞서 언급했 듯 글로벌과 중국 서버 모두 커버하기 위함입니다.

 

levelType과 같이 데이터가 int로 제공되지만, String으로 모델링 해야하는 경우 반드시 별도의 처리가 필요했습니다.

String이 별도로 처리되지 않고, data as E로 리턴하는 경우, int 타입은 String으로 캐스트 될 수 없다는 에러가 발생합니다.

하지만, String의 경우에는 data.toString() as E로 리턴하는 경우, int가 String으로 형변환되어 에러가 발생하지 않습니다.

 

정석은 .fromJson에 두 번째 인자로 콜백함수를 넘겨주는 것인데,

제 경우에는 static으로 함수를 만들어 인자를 받지 않고 직접 주입해서 넘겨줬습니다.

 

static으로 지정한 이유는... 메모리 절약을 위해..!

요즘같이 메모리 많은 세상도 아끼면서 쓰는 것이 참된 개발자겠죠..!

 

 

d. @JsonKey.name

<Fig. 05>를 참고해주세요.

특정 멤버 변수위에 해당 어노테이션을 지정하는 경우 json에서 읽고 쓸 key의 이름을 지정할 수 있습니다.

 

제 경우에는 읽어야 할 key의 이름이 대문자로 시작하거나, 언더바가 들어가있는 경우가 있었는데,

dart는 대문자로 시작하는 이름은 클래스 취급을 하고, 언더바 사용은 권장하지 않기 때문에 경고문구가 나오는 경우가 있었습니다.

물론 실행하는데 문제는 없지만, 경고문구도 보기 싫고, 코드에 통일감을 주기위해 camelCase의 사용은 필수 아닌 필수입니다.

따라서 해당 어노테이션을 이용하면 이런 문제를 해결할 수 있습니다.

 

 

어째 업데이트 소개가 아니라 공부의 장이 되어버린 느낌...

 

 

3. 코드 수정

모델링을 새로 하면서 구조가 많이 변경되었기 때문에 대부분의 파일에서 빨간줄이 생기더군요,,,

하나씩 찾아가며 수정해줍니다.

 

사실 파일을 읽어 모델링할 때 문제 없으면 이 단계에서 코드를 수정해도 문제될 것이 없습니다.

물론 중섭 대응을 위해 int -> String으로 바꾼 경우에는 문제가 발생했습니다.

 

<Fig. 06>

따라서 임시방편으로 converter 함수를 구현해서 해결하는걸로..!

 

나중에 정식으로 글로벌 서버가 중섭 사양을 따라가게 되면 필요 없어지겠죠..ㅎ