학창시절 Swing을 정말 열심히 공부했던 기억이 난다.. 그러고 보니 그때가 이미 10년전인가..
Swing은 MVC기반의 Java의 UI Framework으로 기존의 AWT 제약을 탈피하고, 탄생한 Java GUI를 위한 회생의 역작이라고도 할 수 있다..
물론 그 이면에는 MS의 아성을 띄어넘기 위해 PC Client 시장을 장악하기 위한 Sun의 초대회장 Scott Mcnealy의 야심의 결과물인지도 모르겠다..
어찌되었건,
학창시절 정말 열심히 Swing을 공부했다.. Swing은 철저희 MVC의 기본 원칙을 내세우며 완벽에 가까운 객체지향 기반의 API를 제공한다. Swing 한번 정도 해본 사람들이라면 JTable의 악몽을 기억할 것이다. 엑셀같은 간단한 Sheet를 표현하기 위해서 얼마나 많은 Interface와 Class간 의존구조를 알아야 하는지..
그리고 사실상 디자인 패턴이나 중고급이상의 S/W 설계 지식이 없으면 제대로 사용할 수 도 없는, 지금 생각해보면 극악의 어려움을 제공하는 구조임에는 틀림없었으나,
Swing의 사용 경험을 통해 객체지향 설계의 많은 부분을 경험할 수 있었고, 이후에 많은 프로그래밍 설계에 있어서 경험적 지식의 기반이 되었다는 점에서 공부한것에 대해 그리 나쁘지 않았다고 생각된다..
이후, Swing은 거의 사장되고, 아무도 쓰지 않는 상황이 되버렸지만,
어찌보면 Swing을 공부했던 사람들에게 Android는 정말 하늘에서 내려준 선물이 아닐까 생각이 들 정도로, 구조적인 측면 사용성의 측면에서 Swing의 것을 닮아있다..
물론 결국 둘다 GUI 프로그래밍을 위한 것이다 보니 설계의 구조적으로 비슷해 질 수 밖에는 없겠지만..
Android는 Swing 혹은 AWT에서 사용하던 LayoutManager들과 거의 유사한 기능을 제공하며, Swing 코드 작성시 많이 생성되는 반복적이고 Tree 구조의 특성을 xml로 분리하여, 개발 효율을 극대화 시켰다고 봐도 무방할 것 같다.
EventListener를 이용한 이벤트 Handling 방식은 Swing이나 AWT에서 사용했던 방식과 거의 동일하며, 모듈의 Life Cycle 관리나 Paint 메카니즘은등은 Applet의 그것과 매우 유사하다. (이건 뭐 다른 유사 시스템에서 비슷할 것으로 보인다)
Android Platform 초기에는 OSGi 가 탑재될뻔 했던적이 있었던 것으로 생각난다. OSGi 가 탑재되면 개발측면에서 많은 부분 Application 간의 의존성 관리나 App - Service 사용 측면에서 유리한 점이 많아 질 것 같지만, 현 분위기상 쉽지는 않아 보인다.