작년에 Google gears에 대해서 잠시 분석해 본적이 있다. 그리고 몇몇 다른 플랫폼에서 그 아키텍쳐의 유사함과 기능에 대해서 자료를 조사해 보았었다.
MS의 Silver light, Sync Framework과 Adobe의 Air가 그 것이다. 그래서, 올해도 일부러 Adobe의 Air/Flex의 발표장을 찾아 나섰다.

동기화에 대한 개념은 크게 어렵지 않다. 그러나 왜 갑자기 이슈가 되었을 지는 생각해 볼 문제이다. 이는 향후 개발 방향을 크게 좌우 할 수 있다. 현재의 추세대로라면, 앞으로는 Moblie이 PC보다 더 큰 시장이 될 것이 틀림없다.  그리고, 이는 현재의 개발 방법론을 바꿀지도 모른다. 그러나 네트워크에 연결되는 순간 배터리의 사용량을 급격히 늘어난다. 필요할 때만 네트워크에 연결한다면 배터리의 사용시간을 늘릴수 있을 것이다. Google은 이러한 관점에서 gears의 구조를 설계 했다.

구글 gear의 Architecture는 정말 Simple하다. 누구나 생각할 수 있는 구조이고, 쉽게 구현할 수 있고, 쉽게 이해할 수 있는 구조이다. 하지만 콜롬부스의 달걀은 도전과 두려움의 극복이 우선되어야 한다.

isolating the data layer

deciding which features to implement offline (connection strategy)

deciding on the app's modality

implementing data synchronization



이번에 다시 Google gears에 대해서 다시 한번 볼 기회가 있어서 Google code를 뒤져 보았더니, 모바이 디바이스를 위한 Google gears에 대한 자료가 있어서 살펴보게되었다.

사실 Google gear의 궁국적인 목적은 모바일 디바이를 위한 것이다. 내부에 내장되어 있는 Database를 이용하여 인터넷/네트워크가 되지 않는 환경에서도 인터넷 어플리케이션은 자유롭게 이용할 수 있도록 google gears는 도와준다. 그리고 인터넷/네트워크가 연결될 때, 서버와 자료를 자동으로 동기화 한다.  

이번에 내가 찾아 참고한 자료는 모바일에 Google gears를 데스크탑 PC에서와 같이 윈도우즈 모바일 5,6에서 Application을 사용가능하게 만들어 준다. 그러나 여기에는 몇 가지 제약 사항들이 있다.

CSS와 Dom object Model과 ActiveX등 제약사항이 있는데, 이는 Windows Mobile 5,6의 Web browser가 데스크답 PC의 그것과 기능과 구조가 다르기 때문이다.

관련된 제약 조건들은 아래와 같다.

Windows Mobile 5 and 6 Limitations

Limitations to consider when writing AJAX applications for Windows Mobile 5 and 6 devices, and some workarounds, are provided below:

• CSS
• Document Object Model
• ActiveX
• Recursion
• Layout refresh
• MSDN Resources

CSS

Neither Windows Mobile 5 nor 6 support the CSS position: style attribute. This means text is not positioned in any way, it simply appears within the normal flow of an HTML document.

Document Object Model

Document Object Model (DOM) limitations, and example workarounds, are provided below:

• Accessing a Document Element
• Creating a Document Element
• Setting Element Text
• Modifying a Document Element

Accessing a Document Element

Windows Mobile 5 does not support document.getElementById(), though Windows Mobile 6 does. The following code snippet provides a workaround using the document.all DOM property.

오늘 ZDNet에서 본 기사이다. Microsoft에서 로봇 개발자용 소프트 최신판을 올해 안에 발표 한다고 한다. 최근에 S/W프레임워크들을 보면, PC라는 역영을 벗어나 H/W영역으로 확장하려는 시도들이 눈에 띈다. MS의IP TV플랫폼도 그렇고, Google이 안드로이드역시 마찮가지이다.

Micro Robotics Studio(MSRS)는 로봇에 관심이 있는 개발자, 학생 또는 일반인들이 프로그램에 대한 지식이 있으면, 로봇 애플리케이션을 쉽게 개발 할 수 있도록 지원해주는 개발 툴이다. 사실 작년에 지나가는 기사로 언듯 봤는데, ZdNet에 새로운 MSRS가 올해 안에 출시된다고 한다.

MS의 소개 자료에 따르면 VPL(Visual Programming Language)을 이용해서 마우스로 필요한 서비스 로직을 구현할 수 있다고 한다. 이는 누구나 쉽게 개발에 참여할 수 있게 배려한 것이다.
그리고, 로봇은 고가의 장비이므로 MS는 이를 시험할 수 있도록  물리 시물레이션 환경을 제공하고 있어 쉽게 테스트가 가능하다. (시간이 나면 꼭 해보고 싶다. 레고를 조립하는 우리 아이처럼...)







아래는 '알데바란 로보틱스'사의 'Nao'이다. 정말 신기하게 생겼는데, 결코 밉지 않은 디자인이다.



아래는 위에 있는 Nao의 동영상이다.
흥미로운 장난감(?) 이긴하지만, 일반인들이 쉽게 구하기는 힘들듯...
생각보다 크기가 작지 않다.

틈틈히 OSGi를 공부하기 위해서, 여러 사이트를 돌아다니면서, 알지 못했던것들을 배우게 된다. 친절하게도 자세하게 설명해주신 모든 분께 감사드린다.(사실 친분은 없지만, 그래도...)

http://www.osgian.com/ 의 자바 모듈 시스템 이라는 글을 보면 자바 7의 새로운 모듈 시스템에 대한 글이 있다. 기존의 자바의 모듈 시스템은 몇 가지 문제점을 안고 있다.

   [기존의 문제점]
    1. 제한된 Scoping Mechanisms
    2. 기본적이고 제한된 기능의 버전관리
    3. 모듈간 의존선(Implicit Dependency)문제
    4. 패키지에서이 단순한 Class path 관리
    5. 불분명한 Class Space Consistency

이러한 문제들은 자바 플랫폼에서의 모듈이라는 실행단위가 명확하지 않기때문이라고 결론을 내리고 있다.(위의 자바 모듈 시스템 링크 참조)
그래서 JSR 277을 통해 이를 개선하려 하고 있다.

    [문제점의 개선사항]
    1. 버전관리(Version Management)
    2. 배포(Distribution) 및 패키징 (Packaging)
    3. 새로운 저장소 (New Repository)
    4. 모듈간 공유 및 연결성 (Module Interconnection)

이는 OSGi 모델을 자바 플랫폼에서 구현하려는 노력의 결과물인데, 이로 이해서 기존에 사용되고 있던, .jar 포맷의 파일은 .jam 포맷의 새로운 파일을 탄생시키게 된다.
물론 이는 자바 7 을 통해서 반영될 수 있을 것이다.

자바는 진화하는 언어임이 분명하다!

자바에서는 getter과 setter을 이용하여 클래스 객체에 상태값을 설정하거나, 상태값을 읽어들인다. 일반적으로 클래스의 멤버 변수를 private로 설정한 후 각각의 값을 getter과 setter로 재 정의 하는 것은 사실 노가다(?) 스러운 작업이라고 스스로 생각을 했었다. 특히 맴버 변수가 5개 이상으로 늘어나면, 이는 정말 코드의 양만 늘이고, 사용에는 별 도움이 안되는 작업을 반복적으로 해야 한다는 사실에 불평을 하곤 했다. 나중에 Eclipse에서 자동으로 생성해주는  Dialog를 무척 고마와 했다.(아래 그림 참조)



.Net이나 Visual Basic에서는 getter, setter 대신에 Properties를 사용한다. 물론 getter와 setter 형태로도 만들수 있지만, 사실 이는 다른 메소드와 큰 차이는 없다.
Properties는 마치 변수에 대입하거나, 변수에서 값을 읽는 것과 큰 차이가 없어, 직관적이고 사용하기 편리하다.

하지만, 이를 정의 하기 위해서는 자바의 getter, setter처럼 여러 줄에 걸쳐서 코드를 작성하기 때문에 불편하기는 마찬가지이다. 물론 Visual Basic 6에서는 툴을 이용하여 정의하기도 했지만, 습관적으로 Coyp/Paste 메소드를 이용해서 복사후 수정하는 것이 일반적인 사용법이었다.

Properties는 아래와 같은 형태로 정의하게 된다. Java의 getter,setter과 크게 다르지 않다. 아래의 코드는 C#으로 되어 있어서 Java를 아는 사람도 어렵지 않게 이해할수 있을 것이다.

이를 Automatic Properties로 바꾸면 다음과 같다. 보기 편하고 심플하다. 그리고 Private로 변수를 클래스 내에 선언해서 사용할 필요도 없다. 물로 내부적으로 연산 처리하는 경우는 조금 다를수 있다.

이를 좀더 가독성 있도록 쓰고 사용하려면, 아래와 같이 고쳐서 사용하면 된다.

그럼 이것은 뭘 뜻하는 것인지 한번 생각해 보시길... 퀴즈 아닌 퀴즈

The simple is good!