학생 시간표 데이터 요청

[domino8788]

학사행정시스템한테 시간표 정보를 요청하는 기능을 구현한다.

• 학사행정시스템 로그인 #80 을 구현했던 것처럼 WebView 를 이용한다.
  마찬가지로 방안에 대한 연구를 선행한다.

[domino8788]

학사행정시스템에서 학생 시간표는 http://sam.skhu.ac.kr/SSE/SSEAD/SSEAD03 에서 요청이 가능하다.

Android WebView에서 학생 시간표 쿼리 시도 시 다음과 같은 절차가 진행된다.

1. shouldInterceptRequest 리스너가 호출되며 WebResourceRequest 객체가 매개변수로 넘어온다.
   해당 객체의 requestHeaders 정보는 다음과 같다.
   

2. shouldInterceptRequest 리스너의 다른 Override가 호출되며 url이라는 String 객체가 매개변수로 넘어온다.
   해당 String은 다음 값을 가지고 있다.
   http://sam.skhu.ac.kr/SSE/SSEAD/SSEAD03_GetList

3. onLoadResource 리스너가 호출되며 위와 마찬가지로 url 이라는 String 객체를 매개변수로 갖고 위와 같은 값을 가지고 있다.

4. 시간표가 표시된다.

[domino8788]

위의 진행 절차를 참고해 추측한 방안을 명시한다.

shouldInterceptRequest 리스너의 WebResourceRequest 객체 매개변수에서 requestHeaders 정보를 담은 요청을 통해 학생 시간표가 담긴 json 파일을 다운로드 할 수 있을 것으로 예상된다.

해당 사항을 구현 및 시도해본다.

• Retrofit 라이브러리를 이용하도록 한다.

[domino8788]

위의 방안을 적용한 결과 다음 응답을 확인할 수 있었다.

IdentityServer/IdentityServer3#1672
위의 링크에 따르면 해당 응답은 유효하지 않은 토큰이나 쿠키를 받았을때 돌아오는 응답이라 한다.
하지만 응답을 받아냈다는 것에 의미를 두고 유효한 값을 전달할 방안을 알아내도록 한다.

[domino8788]

데이터를 요청 과정에 interceptor 를 적용해 로그를 확인한 결과
유효한 요청을 하기 위해서는 다음 사항들이 필요한 것으로 밝혀졌다.

• Request의 Header에 유효한 쿠키를 담아야한다.(로그인 된 상태에서 발급 받은 만료되지 않은 쿠키)
• Request의 Header에 http://sam.skhu.ac.kr/SSE/SSEAD/SSE/SSEAD/SSEAD03 페이지 로드 시 발급되는 인증 토근(RequestVerificationToken)을 담아야한다.
  해당 토큰은 페이지가 바뀔때마다 재발급되며 페이지 내에서 수행할 수 있는 Request 에만 유효하다.
• Yy(연도 ex) "2020" ), Haggi(학기 ex) "Z0101" ), HaggiNm(학기번호 ex) "1학기") 를 Post Request의 body에 담아야한다.

[domino8788]

시간표 데이터를 요청하는 기능구현을 위해 test_request_sam 브랜치를 만들었다.
412d498 커밋에서 위에 명시한 바를 구현했지만 여전히 AntiForgery Validation Error 가 발생하고 있다.

#130 이슈를 선행하도록 한다.

[domino8788]

#130 를 해결했으므로 이슈를 재개한다.
6e894d2 커밋을 통해 시간표 데이터를 요청하는 기능 구현을 완료했다.
해당 구현은 test_request_sam 브랜치에 적용되어 있으므로
feature_calendar 브랜치에서 해당 기능을 이용할 수 있도록 반영한다.

• test_request_sam 브랜치에서 구현한 기능을 feature_calendar 브랜치에 반영

[domino8788]

test_request_sam 브랜치에서 구현한 기능을 feature_calendar 브랜치에 반영하던 중 문제가 발생했다.
해당 기능은 AuthViewModel 의 로그인 로직에서 얻을 수 있는 쿠키가 필요하다.
또한 쿠키를 임의로 가져올 수 있다해도 유효한 쿠키를 가져올 수 있는 인증 로직을 항상 선행 하므로 의미가 없다.
무엇보다 WebView의 WebViewClient에서 기능을 수행하므로 ViewModel이 요청한 기능을 수행할 수 있게 설정된 WebViewClient 객체를 반환하고 그것을 WebView에 설정 후 loadUrl 을 호출하는 형식으로 작동한다.
결과값은 WebViewClient 내부에서 postValue 를 호출하는 것으로 얻을 수 있다.
그러므로 AuthViewModel 과 WebViewClient 를 분리 시키는건 불가능하다.

그렇다면 어떻게해야 CalendarViewModel에 이번에 구현한 기능을 담을 수 있을까?

1. AuthViewModel 에 구현된 WebViewClient 를 상속한 클래스를 인증로직만 가져와서 이번에 구현한 로직을 덧붙인다.
2. AuthViewModel 에 모든 로직을 넣고 view가 AuthViewModel 에 요청하면 CalendarViewModel 이 결과값을 받게 한다.
3. 2번처럼 하되 calendarViewModel이 값을 받게 하는게 아니라 바로 Firestore 에 저장한다. 그리고 calendarViewModel 이를 다운받게 한다.

• firestore의 calendar 컬렉션에 학생 시간표 데이터를 넣을 생각은 없다.
  학생 시간표 데이터는 학사행정시스템에 의존하는 데이터라 변경사항이 발생할 수 있으므로 매번 변경사항에 대응하기보다 되도록 필요할 때마다 요청해서 데이터를 받는것이 낫다.
  단, 트래픽을 줄이기 위해 오프라인 저장소를 혼용하게 구현할 예정이다.

4. WebView가 필요한 로직을 WebViewModel 을 만들어 담는다. WebViewModel을 통해 WebViewClient 를 반환받고 WebView 에 적용하는 로직을 구성한다.

• 문제는 어떻게 WebViewClient 의 작동 결과를 받을 수 있느냐는 것이다.

우선 1번 방안을 채택한다.
기존 WebViewClient 로직 중 오직 인증로직만이 의존성이 없다.
그러므로 분리가 가능하며 또한 현재 적용된 기능이 적어서 그렇지
확장성 측면에서는 1번과 같이 각 ViewModel 이 독립된 WebViewClient를 갖는게 낫다.

[domino8788]

위의 방안을 적용해서 다음 사항들을 구현한다.

• AuthViewModel 에서 기존 WebView 에 대한 url 요청 코드를 개선한다.

• 기능을 분리함에 따라 잦은 요청을 방지할 수 있어서 postDelayed 에 의한 지연요청을 할 필요가 없어졌다.

• FirestoreHelper 의 userReference 초기화를 AuthViewModel 이 수행하도록 수정한다.
• 기존 FirestoreHelper 의 경로명을 repository 로 변경한다.
• RetrofitHelper를 구현한다.
• 시간표 데이터 요청 및 파싱에 필요한 VO 클래스를 구현한다.

• Request Body 역할을 하는 Haggi 클래스
• 학생 시간표 내 강의 정보가 담기는 Lecture 클래스
• json 의 형태로 넘어온 Response를 변환 후 담을 StudentSchedule 클래스

• 의존성을 추가한다.

• 아래 링크를 참고해 최신 버전을 적용하도록 한다.
• retrofit, converter-gson
  https://github.com/square/retrofit
• gson
  https://github.com/google/gson
  *okhttp, logging-interceptor, okhttp-urlconnection
  https://square.github.io/okhttp/

[domino8788]

위의 커밋을 통해 구현을 완료했으므로 이슈를 닫는다.

[domino8788]

몇 가지 구현을 안한 사항이 있어서 이슈를 재개한다.
다음 기능을 추가한다.

• 데이터 요청에 필요한 WebView 를 추가 및 설정한다.
• 현재 학기 정보를 담기 위한 VO 클래스를 구현한다.
• 현재 학기 정보를 요청하는 RetrofitService 를 구현한다.

[domino8788]

위의 커밋을 통해 구현을 완료했으므로 이슈를 닫는다.

[domino8788]

#138 에 명시한 에러가 발생했으므로 해당 버그를 해결할 때까지 이슈를 재개한다.

[domino8788]

#138 의 버그를 해결했으므로 변경사항이 발생할 때까지 이슈를 닫는다.

[domino8788]

#138 버그를 해결했던 커밋에서 추가로 증상이 발생했으므로 해당 이슈를 재개하고 해결을 선행한다.

[domino8788]

#138 에서 재차 발생한 버그를 해결했으므로 변경사항이 발생할 때 까지 이슈를 닫는다.