안녕하세요
리그베다 위키 비공식 앱 제작자 StanleyKou 입니다.
https://play.google.com/store/apps/details?id=com.kou.android.RigVedaViewer 이번에 1.03 릴리즈를 해서 홍보하러 왔습니다.
프로그래밍 게시판이니 기술적인 내용을 좀 말씀드리자면...
이번 1.03 릴리즈에는 각주 메뉴에서 해당 아이템을 클릭 시 해당 위치로 이동시켜주는 기능이 들어갔습니다.
이 기능은 SpannableStringBuilder를 TextView에 설정해주는 방식으로 구현 되었는데요,
즉 TextView 하나에 여러 개의 링크를 걸고 각 링크마다 클릭 시 개발자가 원하는 동작을 수행하는 방식입니다.
stackoverflow 사이트에서 아래와 같은 방식의 예제를 제시해 주었습니다.
String sentence = "this is [part 1] and [here another] and [another one]"
textView.setMovementMethod(LinkMovementMethod.getInstance());
textView.setText(addClickablePart(sentence), BufferType.SPANNABLE);
private SpannableStringBuilder addClickablePart(String str) {
SpannableStringBuilder ssb = new SpannableStringBuilder(str);
int idx1 = str.indexOf("[");
int idx2 = 0;
while (idx1 != -1) {
idx2 = str.indexOf("]", idx1) + 1;
final String clickString = str.substring(idx1, idx2);
ssb.setSpan(new ClickableSpan() {
@Override public void (View widget) {
Toast.makeText(getView().getContext(), clickString,
Toast.LENGTH_SHORT).show();
}
}, idx1, idx2, 0);
idx1 = str.indexOf("[", idx2);
}
return ssb;}
즉 SpannableStringBuilder 를 textView에 넣어주는데, 이 SpannableStringBuilder 는 setSpan 메소드를 통해 특정 위치에 ClickableSpan을 지정해 줄 수 있습니다. 그리고 ClickableSpan이 을 받게 됩니다.
다만 리그베다 위키 같은 모니위키 사이트에서는 단순히 [] 만이 아닌 다른 구분자가 더 들어가는데, 아래와 같습니다.
[wiki:"실제링크텍스트" 보여지는텍스트]
[[이중괄호]]
그래서 이번에 구현된 부분은 해당 구분자를 판별하여 링크로 만드는 작업이었습니다. 실제 예문은 아래처럼 나옵니다.
이 부분을 parsing 하기 위해서 아래와 같은 코드를 이용했습니다.
간단히 설명하자면 wiki로 시작되는 링크를 먼저 처리하고
그 다음 [으로 시작되는 링크를 처리하는 방식입니다.
만약 [ 기호를 구분자로 이용하면 "[" 과 "[w" ([wiki 의 앞부분) 이렇게 두 종류가 검출되기 때문에
[ 기호 처리 시에는 [w가 아닌지 추가로 검사하는 do-while문이 들어갔습니다.
rfnTitle이 예제 구문입니다.
if (rfnTitle.contains("[[")) {
rfnTitle = rfnTitle.replace("[[", "[");
rfnTitle = rfnTitle.replace("]]", "]");
}
// wiki link
int initialLengthForLink = ssb.length();
ssb.append(rfnTitle);
idx1 = rfnTitle.indexOf("[w");
idx2 = 0;
while (idx1 != -1) {
idx2 = rfnTitle.indexOf("]", idx1) + 1;
// final String clickString = str.substring(idx1, idx2);
String linkWikiTag = rfnTitle.substring(idx1, idx2);
int linkidx1 = linkWikiTag.indexOf("\"");
int linkidx2 = linkWikiTag.indexOf("\"", linkidx1 + 1);
String linkitem = linkWikiTag.substring(linkidx1 + 1, linkidx2);
final String clickStringWiki = getString(R.string.url_home_page_with_slash) + linkitem;
//Toast.makeText(getView().getContext(), clickStringWiki, Toast.LENGTH_SHORT).show();
ssb.setSpan(new ClickableSpan() {
@Override
public void (View widget) {
// Toast.makeText(getView().getContext(), clickStringWiki, Toast.LENGTH_SHORT).show();
((WebViewFragmentHolderActivity) getActivity()).loadUrl(clickStringWiki);
((WebViewFragmentHolderActivity) getActivity()).toggle();
}
}, idx1 + initialLengthForLink, idx2 + initialLengthForLink, 0);
idx1 = rfnTitle.indexOf("[w", idx2);
}
// link
idx1 = 0;
int idx1w = 0;
do {
idx1 = rfnTitle.indexOf("[", idx1 + 1);
idx1w = rfnTitle.indexOf("[w", idx1w + 1);
} while (idx1 != -1 && idx1 != idx1w);
idx2 = 0;
while (idx1 != -1) {
idx2 = rfnTitle.indexOf("]", idx1) + 1;
// final String clickString = str.substring(idx1, idx2);
String linkitem = rfnTitle.substring(idx1, idx2);
linkitem = linkitem.replace("<", "");
linkitem = linkitem.replace(">", "");
final String clickString = getString(R.string.url_home_page_with_slash) + linkitem;
ssb.setSpan(new ClickableSpan() {
@Override
public void (View widget) {
// Toast.makeText(getView().getContext(), clickString, Toast.LENGTH_SHORT).show();
((WebViewFragmentHolderActivity) getActivity()).loadUrl(clickString);
((WebViewFragmentHolderActivity) getActivity()).toggle();
}
}, idx1 + initialLengthForLink, idx2 + initialLengthForLink, 0);
do {
idx1 = rfnTitle.indexOf("[", idx1 + 1);
idx1w = rfnTitle.indexOf("[w", idx1w + 1);
} while (idx1 != -1 && idx1 != idx1w);
}
결론적으로 말하자면, 문제가 많은 코드입니다.
질문 : 왜 일까요?
이것은 문자열 처리라는 개발자의 귀찮은 과제와도 연관이 있습니다.
작업 시 과정은 아래와 같습니다.
1) 텍스트 파싱하여 링크를 붙이는 작업이 필요 -> 2) 가능한 방법 조사. 가능하면 샘플 확보 -> 3) 적용 -> 4) 동작! PROFIT!
......
아마도 초보 개발자분들이나 시간 없는 개발자분들은 보통 이렇게 작업을 하시겠지만, 이렇게 작업하시면 안됩니다. 왜 그런가하면
문제를 이해하는 과정이 빠졌기 때문입니다.
흔히들 시간이 없으면 문제를 이해하지 않고 그냥 넘어갑니다. 인풋에 따른 아웃풋만 처리하고 끝나버립니다.
그리고나서 다음번에 버그가 생깁니다.
-> "아, 이런 케이스가 있는걸 몰랐는데, 새로 구현해야 겠어"
그러면 이전의 코드에 땜빵질을 해서 if-else를 추가하고, boolean 변수를 만들어 특정 경우에 true로 만들고, 결과물을 내놓습니다.
그러면 새로운 케이스에서 돌아가고, 이전 케이스에서 안돌아가는 사태가 벌어집니다. 그러면 몇 개의 if-else, boolean을 추가하고
다시 돌려서 두 케이스에서 돌아가는 것을 확인하고 안심합니다.
그러면 새로운 케이스가 나올겁니다.
그래서 이렇게 처리해야 합니다.
1) 문제의 인식. 해당 문제의 스펙 확보, 가능한 케이스 확보. 이것을 테스트 케이스로 만들어 자동화 테스트 가능하도록 구현 (TDD)
2) 기본적인 구현, 가능하면 boolean을 쓰지 않고, Flow에 따라 강물이 갈라져나가듯 처리. 메소드명은 알기 쉽게 (CleanCode)
3) 텍스트 처리라면 Regular Expression을 고려할 것. 잘 구현된 표준 라이브러리가 있다면 적극 활용할 것. 개발자들은 보통 표준/유명 라이브러리를 잘 숙지하고 있기 때문에, 이런 것들을 이용하면 다른 개발자가 이 코드를 읽기 편해져서 생산성이 증가함.
4) 패턴을 적용할 만한 구조라면 패턴 적용. 그러나 대부분 경우에는 이 단계에서 빠르게 최적화하면 가독성이 떨어지고 수정이 어려워지기 때문에, 한 서너번 수정을 하게 된 이후 디자인패턴이나 재사용성 증가를 위한 코드 적용. 그렇지 않다면 최대한 가독성을 높이는 것이 생산성을 높이게 됨.(Design Pattern)
가독성에 대해 잠시 언급하고 넘어가자면, 임베디드 빼고 현대의 대부분 환경에서는 미친듯한 CPU빨 덕분에 퍼포먼스는 크게 고려의 대상이 아닙니다. 일단 가독성 높은 코드로 작성한 뒤, 속도가 문제가 생기는 부분에서 최적화를 하는 것이 정석입니다. CPU 코스트나 퍼포먼스보다 사람 인건비가 제일 비싼 자원인 경우가 많기 때문입니다.
5) 테스트. 개발자 유닛 테스트, 전문 테스터 테스트, 결합 이휴 통합테스트.
6) 작성 이후 소설처럼 읽히지 않는 부분에 주석 추가.
7) 릴리즈 이후 잘 되기를 간절히 기도하거나 지쳐쓰러짐
그러니까 결론은
-> 이 버전에서는 시간이 없어서 허접하게 개발했습니다. 엉엉엉
감사합니다.
