윈7폰에서 SQLLite쓰기

모바일에서 자주 사용했었던 SQLLite가 윈7폰에는 빠져 있지요

안드로이드는 내부 DB가 있는데 윈7폰은 빠져서 여기에 불만인 사람들이 많습니다.

MS에서는 자사의 클라우드 서비스를 사용하라고 이야기 합니다만 개발자들이 꼭 시키는대로 따르지는 않죠.

그래서 SQLLite 소스를 C#으로 완전 포팅하여 IsolatedStorage를 사용할수 있게 한게 나왔습니다. (혹 뒷북인가요?;;)

프로젝트에 DLL을 추가하고 약간 잡다한 설정하나 해주면 끝납니다. 단 주의할것은

1) 에뮬레이터 재부팅 하면 DB가 날아갑니다. 에뮬에서는 IsolatedStorage를 리부팅 할때마다 날려버리는듯..

2) IsolatedStorage가 일반 파일 IO보다 매우 느리기 때문에 성능을 기대하긴 어렵습니다.

간단한 DB 트랜잭션이 꼭 필요하다면 사용할만 합니다. 다운로드는 아래에...

http://www.fnnews.com/view_news/2010/10/28/00000922129337.html

http://sviluppomobile.blogspot.com/2010/03/sqlite-for-wp-7-series-proof-of-concept.html

어제출시된 따끈한 윈7폰 테스트 (삼성,LG)

출시된 폰들 비됴입니다.

보신분은 패스

 

안보신 분은 함 대충 느껴보세요

손이랑 크기를 비교해보시면 대략 감이 오실것 같습니다.

 

급하신 분들위한 종합버전 ->

 

 

 

 

 

 

 

 

 

 

 

1) 슬쩍 버벅? 대는 옴니아 7폰...

 

 

2) 옵티머스 7

 

3) 포커스 .. 요건 좀 성실히 테스트 해줬네요

 

오랜만에 Win7 폰 광고 2개

오토마우스 오토키보드 소스

푸 요청으로 올립니다.

옛날에 짠 소스인데... 아래 SendInput  이라는 API 로 마우스/키보드 흉내를 낼수 있습니다.

오토 마우스/ 키보드가 가능하다는 것이지요...

굳이 복잡한 후킹기술 안써도 아래 소스로 충분합니다.

 

 

[code csharp] using System; using System.Runtime.InteropServices; namespace AutoKeyMouseExample { internal class Win32APIs { [DllImport("user32.dll", SetLastError = true)] public static extern uint SendInput(uint nInputs, ref INPUT pInputs, int cbSize); [DllImport("user32.dll")] public static extern IntPtr GetMessageExtraInfo(); [StructLayout(LayoutKind.Sequential)] public struct MOUSEINPUT { public int dx; public int dy; public uint mouseData; public uint dwFlags; public uint time; public IntPtr dwExtraInfo; } [StructLayout(LayoutKind.Sequential)] public struct KEYBDINPUT { public ushort wVk; public ushort wScan; public uint dwFlags; public uint time; public IntPtr dwExtraInfo; } [StructLayout(LayoutKind.Sequential)] public struct HARDWAREINPUT { public uint uMsg; public ushort wParamL; public ushort wParamH; } [StructLayout(LayoutKind.Explicit)] public struct INPUT { [FieldOffset(0)] public int type; [FieldOffset(4)] //* public MOUSEINPUT mi; [FieldOffset(4)] //* public KEYBDINPUT ki; [FieldOffset(4)] //* public HARDWAREINPUT hi; } /***************************** * EVENT CONSTANTS * *****************************/ public const int INPUT_MOUSE = 0; public const int INPUT_KEYBOARD = 1; public const int INPUT_HARDWARE = 2; public const uint KEYEVENTF_EXTENDEDKEY = 0x0001; public const uint KEYEVENTF_KEYUP = 0x0002; public const uint KEYEVENTF_UNICODE = 0x0004; public const uint KEYEVENTF_SCANCODE = 0x0008; public const uint XBUTTON1 = 0x0001; public const uint XBUTTON2 = 0x0002; public const uint MOUSEEVENTF_MOVE = 0x0001; public const uint MOUSEEVENTF_LEFTDOWN = 0x0002; public const uint MOUSEEVENTF_LEFTUP = 0x0004; public const uint MOUSEEVENTF_RIGHTDOWN = 0x0008; public const uint MOUSEEVENTF_RIGHTUP = 0x0010; public const uint MOUSEEVENTF_MIDDLEDOWN = 0x0020; public const uint MOUSEEVENTF_MIDDLEUP = 0x0040; public const uint MOUSEEVENTF_XDOWN = 0x0080; public const uint MOUSEEVENTF_XUP = 0x0100; public const uint MOUSEEVENTF_WHEEL = 0x0800; public const uint MOUSEEVENTF_VIRTUALDESK = 0x4000; public const uint MOUSEEVENTF_ABSOLUTE = 0x8000; /***************************** * VIRTUAL KEYS * *****************************/ public enum VK : ushort { /* * Virtual Keys, Standard Set */ VK_LBUTTON = 0x01, VK_RBUTTON = 0x02, VK_CANCEL = 0x03, VK_MBUTTON = 0x04, /* NOT contiguous with L & RBUTTON */ VK_XBUTTON1 = 0x05, /* NOT contiguous with L & RBUTTON */ VK_XBUTTON2 = 0x06, /* NOT contiguous with L & RBUTTON */ /* * 0x07 : unassigned */ VK_BACK = 0x08, VK_TAB = 0x09, /* * 0x0A - 0x0B : reserved */ VK_CLEAR = 0x0C, VK_RETURN = 0x0D, VK_SHIFT = 0x10, VK_CONTROL = 0x11, VK_MENU = 0x12, VK_PAUSE = 0x13, VK_CAPITAL = 0x14, VK_KANA = 0x15, VK_HANGEUL = 0x15, /* old name - should be here for compatibility */ VK_HANGUL = 0x15, VK_JUNJA = 0x17, VK_FINAL = 0x18, VK_HANJA = 0x19, VK_KANJI = 0x19, VK_ESCAPE = 0x1B, VK_CONVERT = 0x1C, VK_NONCONVERT = 0x1D, VK_ACCEPT = 0x1E, VK_MODECHANGE = 0x1F, VK_SPACE = 0x20, VK_PRIOR = 0x21, VK_NEXT = 0x22, VK_END = 0x23, VK_HOME = 0x24, VK_LEFT = 0x25, VK_UP = 0x26, VK_RIGHT = 0x27, VK_DOWN = 0x28, VK_SELECT = 0x29, VK_PRINT = 0x2A, VK_EXECUTE = 0x2B, VK_SNAPSHOT = 0x2C, VK_INSERT = 0x2D, VK_DELETE = 0x2E, VK_HELP = 0x2F, /* * VK_0 - VK_9 are the same as ASCII '0' - '9' (0x30 - 0x39) * 0x40 : unassigned * VK_A - VK_Z are the same as ASCII 'A' - 'Z' (0x41 - 0x5A) */ VK_LWIN = 0x5B, VK_RWIN = 0x5C, VK_APPS = 0x5D, /* * 0x5E : reserved */ VK_SLEEP = 0x5F, VK_NUMPAD0 = 0x60, VK_NUMPAD1 = 0x61, VK_NUMPAD2 = 0x62, VK_NUMPAD3 = 0x63, VK_NUMPAD4 = 0x64, VK_NUMPAD5 = 0x65, VK_NUMPAD6 = 0x66, VK_NUMPAD7 = 0x67, VK_NUMPAD8 = 0x68, VK_NUMPAD9 = 0x69, VK_MULTIPLY = 0x6A, VK_ADD = 0x6B, VK_SEPARATOR = 0x6C, VK_SUBTRACT = 0x6D, VK_DECIMAL = 0x6E, VK_DIVIDE = 0x6F, VK_F1 = 0x70, VK_F2 = 0x71, VK_F3 = 0x72, VK_F4 = 0x73, VK_F5 = 0x74, VK_F6 = 0x75, VK_F7 = 0x76, VK_F8 = 0x77, VK_F9 = 0x78, VK_F10 = 0x79, VK_F11 = 0x7A, VK_F12 = 0x7B, VK_F13 = 0x7C, VK_F14 = 0x7D, VK_F15 = 0x7E, VK_F16 = 0x7F, VK_F17 = 0x80, VK_F18 = 0x81, VK_F19 = 0x82, VK_F20 = 0x83, VK_F21 = 0x84, VK_F22 = 0x85, VK_F23 = 0x86, VK_F24 = 0x87, /* * 0x88 - 0x8F : unassigned */ VK_NUMLOCK = 0x90, VK_SCROLL = 0x91, /* * VK_L* & VK_R* - left and right Alt, Ctrl and Shift virtual keys. * Used only as parameters to GetAsyncKeyState() and GetKeyState(). * No other API or message will distinguish left and right keys in this way. */ VK_LSHIFT = 0xA0, VK_RSHIFT = 0xA1, VK_LCONTROL = 0xA2, VK_RCONTROL = 0xA3, VK_LMENU = 0xA4, VK_RMENU = 0xA5, VK_BROWSER_BACK = 0xA6, VK_BROWSER_FORWARD = 0xA7, VK_BROWSER_REFRESH = 0xA8, VK_BROWSER_STOP = 0xA9, VK_BROWSER_SEARCH = 0xAA, VK_BROWSER_FAVORITES = 0xAB, VK_BROWSER_HOME = 0xAC, VK_VOLUME_MUTE = 0xAD, VK_VOLUME_DOWN = 0xAE, VK_VOLUME_UP = 0xAF, VK_MEDIA_NEXT_TRACK = 0xB0, VK_MEDIA_PREV_TRACK = 0xB1, VK_MEDIA_STOP = 0xB2, VK_MEDIA_PLAY_PAUSE = 0xB3, VK_LAUNCH_MAIL = 0xB4, VK_LAUNCH_MEDIA_SELECT = 0xB5, VK_LAUNCH_APP1 = 0xB6, VK_LAUNCH_APP2 = 0xB7, /* * 0xB8 - 0xB9 : reserved */ VK_OEM_1 = 0xBA, // ';:' for US VK_OEM_PLUS = 0xBB, // '+' any country VK_OEM_COMMA = 0xBC, // ',' any country VK_OEM_MINUS = 0xBD, // '-' any country VK_OEM_PERIOD = 0xBE, // '.' any country VK_OEM_2 = 0xBF, // '/?' for US VK_OEM_3 = 0xC0, // '`~' for US /* * 0xC1 - 0xD7 : reserved */ /* * 0xD8 - 0xDA : unassigned */ VK_OEM_4 = 0xDB, // '[{' for US VK_OEM_5 = 0xDC, // '\|' for US VK_OEM_6 = 0xDD, // ']}' for US VK_OEM_7 = 0xDE, // ''"' for US VK_OEM_8 = 0xDF /* * 0xE0 : reserved */ } } } [/code]

HTC의 Windows 7 Phone ROM 유출?

HTC에서 유출된 Phone ROM에 windows 7 Phone OS로 보이는 데이터가 담겨 있었답니다. 이걸로 봐서 올 하반기엔 HTC에서 Mondrian 등의 차기 단말로 Windows 7 Phone이 등장할 확률이 높아졌군요. 다른 제조사의 행보가 주목됩니다. (LG에서 해외를 대상으로 Windows 7 Phone을 샘플로 선보였다고 하는데... 자세한건 두고봐야겠죠?)

 

http://www.engadget.com/2010/05/17/htc-mondrian-with-1-3ghz-snapdragon-detailed-in-leaked-windows-p/

 

 

Blend & Windows 7 Phone 동영상 한점.

 

Microsoft Blend로 App을 만드는 방법에 대한 90초 짜리 동영상입니다.

간단해보이는군요... 시간나는대로 바로 해서 포스팅 해보겠습니다.

개인적으로 이제부터 화면전환이용이 가능하다는게 좋군요.

 

Windows 7 Phone Design 관련 동영상 2점

Windows 7 Phone의 디자인에 관한 동영상이 2개 있어요

흥미있는 분들 보시라고 링크~

Windows Phone 7 Design

아래는 위 동영상의 독어 버전? 인데 좀더 7 Phone의 디자인 테마에 대해서 이야기하고 있는듯....

MSDN TV Live - Metro, designspråket för Windows Phone 7

놀고먹으면서 일 잘하는 방법 - 우리의 Agile 실험

 

"놀고먹으면서 일 잘하는 방법은 없을까?"

 

제가 입사한 후 근 9개월동안 알게 된 IT 현실은 다음과 같습니다.

 

1) 개발자는 노동강도가 세다. 그들에겐 밤도, 주말도 존재하지 않는다. 왜냐면...

2) 대부분의 개발자들의 업무가 과중하고 업무를 처리하는 방식이 비 효율적이기 때문이다.

    (주 업무의 70% 이상이 유지보수 = 버그잡기 이고 신규개발에 의한 과중은 얼마 안되었습니다.)

3) 개발자들도 이 사실을 알고있다.

4) 하지만 여러가지 이유를 들어 섣불리 개선하지 못하고 있다.

5) 그리고 타인과 조직이 잘못되어 있다고 한탄한다.

 

약간 다른 이야기지만, 저는 몇년전부터 "효율적으로 일하는방법 = 놀면서 일하는 방법"을 고민해 왔습니다.

 

사실 이러한 저의 고민은 저의 학창시절의 고민에서 시작되었습니다.

저의 학창시절 소원은 1등을 해보는 것이었습니다. 저는 5시간만 자고 공부만 했지만 항상 8시간 이상 자고 친구들과 자주 스타크래프트를 하는 1등이 항상 부러웠습니다. 시험에서의 퍼포먼스와 삶에서의 퍼포먼스 양쪽을 다 잡고있는 그가 매우 부럽고 시기했었습니다. 그리고 저는 "천재"가 아니기 때문에 그러한 것이 불가능할 것이다라고 단정지었었죠.

 

 하지만 대학들어와도 바로 옆 친구가 시험기간동안 게임을 즐기면서도 항상 평점은 4.0 이상 이었던것에 비해, 저는 딱히 노는것도 없이 밤새는데 3.5를 간신히 넘는 상황이 발생하자 그동안 제가 해온 공부 = 일의 방식이 매우 비 합리적이고 아둔하지 않았나 생각하게 되었습니다.

 

 무엇에 차이가 있나 저는 그때부터 잘하는 녀석들을 붙잡고 물어보고 저와 비교하는 일을 시작했습니다.  그 과정은 매우 괴로웠습니다. "나도 이렇게 진작 했다면 좀더 나았을텐데" 라는 생각과 "내가 멍청했다." 라는 자괴감 때문에 많이 괴로웠거든요. 무조건 시간을 오래 쏟는다고 성능이 나아지지 않는것인데 저는 그저 인내하고 파기만 하면 모든게 해결될줄 알았던 것입니다.

 

아래의 링크는 유명인사들이 왜 다른 평범한 사람들과 같은 시간을 보내면서도 탁월한 성과를 올릴수 있는가에 대한 이야기입니다.

http://lifedev.net/2008/03/10-ways-historys-finest-kept-focused-at-work/

 

정리하자면, 그들은 자신이 일하는 방식에 대한 그들만의 원칙이 있고. 결코 오래 엉덩이를 붙이고 있는것이 능사가 아니라는 것을 알고 있었으며 짧은시간동안 최대한 문제에 집중하고 나머지 시간은 몸과 뇌를 놀리는데 썼다는 것입니다.

 

 역시 학창시절에 저보다 우월한 녀석들은 "모든 일을 줄기차게 많이 하는것" 보다 "중요한 일에 단시간 집중하여 탁월한 성과를 내는것"을 선호하고, 각자 그렇게 하는 자기만의 최적화된 방법을 연구하고 체득하고 있었다는 겁니다.

 

결국, "놀면서 일 잘하는 방법에 대한 패턴"은 존재했다고 생각합니다.

 

 그래서 저는 저만의 방법을 찾아 연구했고 이를 간단히 실험해 보았습니다. 공부의 원칙과 시간을 세우고 제가 잘하는 "그림/동영상 기억법"을 이용해서 "숲에서 나무로 훓어 내려가는"공부를 해 보았습니다. 그리고 공부시간 외의 시간은 음악을 듣고 군것질을 하고 잡담을 하고 만화책을 보며 게임을 했습니다. 이전에 시험기간동안 공부에만 투자한 시간이 하루 10시간 이라면 이를 5시간까지 줄였습니다.

 

 그 결과는 생각 외였습니다. 저는 이전보다 많은 시간을 공부에 할애하지 않아도 많은 양을 기억할수 있었고 (일부는 지금도 기억합니다.) 성적도 0.3포인트 이상 더 잘 나왔던 것입니다.

 

다시 회사 이야기로 돌아가서, 수많은 개발자들이 오늘도 죽음의 행진을 하고 있습니다. 아직 초년때에 이 죽음의 대열에 막 발을 담그고 "정말 대한민국에서의 회사생활과 IT엔 답이 없는가?" 하며 괴로워 하고 있을때 한 상사분께서 다음과 같은 조언을 몇가지 해주었었습니다.

 

1) 주요이슈(issue)는 정리되어야 한다. (잠재적인것도 포함)

2) 문제는 잘게 쪼개어야 한다.

3) 히스토리는 기록되어야 한다.

4) (상사가 보기에)중요한 몇가지에 우선 집중하라.

5) 문서와 코딩은 같이 가야한다.

6) 설계와 코드는 자주 리뷰되어야 한다.

7) 설계는 절대 폼잡지 말고 실용적이어야 한다.

8) 프로세스를 세우고 이에 맞추어 일하라.

9) 일 할땐 하되, 자주 쉬어라.

10) 개선할것은 시간을 들여서라도 자주 개선하고

11) 위 모든것은 보고하여 실적화가 가능한 형태로 준비하라.

 

저는 이러한 조언이 그분의 직장생활 10년동안에 나온 귀중한 경험이자 하나의 패턴이라고 생각했습니다. 하지만 그 상사분도 이러한 것들을 제대로 실천하고 계시지는 못하고 계셨습니다. 그래서 저는 여기에 아래와 같은 약간의 변형을 가하고 이를 구체적으로 패턴화 하고 실천하는 작업에 들어갔습니다.

 

12) 모든 업무는 파이프라인처럼 병렬적으로 진행하도록 한다.

     (신속한 태스크 스위칭을 통해서)

 

 저는 스프레드쉬트로 각 업무에 맞는 문서를 만들었고, 오늘의 프로세스를 세워 이를 적어두고 하나씩 실천했습니다. 처음에는 상당히 귀찮을 뿐더러, 번거롭기 그지 없었지만. 이것이 몇달이상 쌓이게 되자 위 11가지 사실을 어느정도 만족시킬수 있는 자료가 되고, 그 자료를 근거로 RISK를 예측하고, 문제에 당황하지 않으며, 한번 해결한 문제가 두번 열리지 않게 하고 남는시간에 중요한 문제에 포커스 하며, 결국 단위시간동안 이전보다 좀더 많은 일을 해결할 수 있음을 알게 되었습니다.

 

통계를 내본결과. 적용전에 하루 3개 정도의 업무를 해결했었으나 이후 5개 이상 최대 하루 10개까지 완료했다는 사실을 발견했기 때문입니다. (이를 가능하게 해준 Franklyn Planner에게 감사~:) )

 

 결국 개발자들이 겪는 수많은 문제들이 정말 IT란 것이 일이 단순히 많아서가 아니라, 과거에 처리한 Bug가 다시 reopen되거나 대충한 설계와 구현때문에 요구사항이 바뀔때 대응을 못하고, 정작 이러한 모든 일에 대한 전체적인 정리된 문서나 설계서가 없기 때문에 문제원인 파악과 대책마련에 시간이 걸린다는 것을 깨닭게 되었습니다. (결국 인간의 기억력에는 한계가 있는데, 많이들 이를 간과합니다.)

 

 문제가 생기지 않는다는 것은, 그 문제를 끊임없이 관리하기 때문이라는 사실도요.

 

 저는 주로 유지보수일을 하고 있었기 때문에, 신규개발만 하는 분들에게 있어서는 별로 공감이 안갈수도 있겠습니다. 그래서 저는 신규개발에도 이러한 "패턴"을 발견하고 여기서 프로세스를 만들어 이를 실천함으로서 현재와 미래의 퍼포먼스와 RISK 안전성을 높이는 작업 이 가능한지 실험해 보기로 하였습니다. 그래서 몇가지 프로세스를 만들었고 이를 실험하여 "우리의 Agile 실험" 이라는 태그를 붙여 블로그에 포스팅 하려 합니다.

 

그리고 저 뿐만 아니라 저 주변의 사람들도 이러한 실험을 통해서 개발에 대한 새로운 눈을 뜰수 있게 되길 소망합니다.

 

 

타블렛 인터랙션 프로토타입 만들기 2

2단계

 아이디어 스케치를 요구사항으로 전환하고 이를 자세히 세분화 및 정리한다. (잘게 쪼갠다.)

 요구사항으로, 모듈로의 변환은 OOAD 개발 방법론의 그것을 적절히 따른다.

 요구사항 하나가 모듈의 한 기능으로 연결될수 있도록 1:1 관계가 되도록 명확하게 만드는것이 좋다.

타블렛 인터랙션 프로토타입 만들기

1단계

 간단한 브레인스토밍과 아이디어 스케치로 만들고자 하는 것에 대한 큰 이미지와 틀을 잡는다.

바탕화면, 지도뷰어, 일기장을 중심으로  프로토타입을 만들기로 하고 기능을 정의해 보았습니다.

Photo Slider

지난 시간에 이어서 이번엔 Win7 phone SDK로

PhotoSlider app을 만들어 보았습니다.

WPF 와는 좀 차이가 나서 삽질이 많았습니다. ;;

대충 삼성 옴니아에 들어있는 1 Finger Zoom을 구현해 보았습니다.

손가락 한개로 줌인/아웃을 할수 있습니다. 원래는 아이팟처럼 두개의 손가락으로 테스트 하고 싶었지만

관련 제스처를 이용할수 있는 방법을 아직 발견못했습니다. ...

(있다고 해도 에뮬레이터 개발환경에서는 test하기 힘들겠군요, 아시는분은 알려주시면 감사하겠습니다.)

다른 이미지로 이동기능들을 구현해 봤습니다.

정말 Silverlight 를 통해서 기존 윈도우폰 개발과는 차별화된 간편함을 제공하는군요;;

좀더 많고 다이나믹한 아이디어를 앱으로 개발할수 있게 되어 기대됩니다.

다만, 실버라이트가 WPF에 익숙한 저로서는 아직 좀 헷갈리는군요....

추가로, 제 욕심입니다만...

이번 앱을 통해서 기존처럼 예제만 제공하는것이 아닌 요구사항-설계-구현이

어떻게 같이 진행되는지 이야기 하고자 합니다.

곧 프로세스/예제와 함께 발전하는 Application을 기대해 주세요~

인터페이스 이야기

 

"객체지향의 꽃은 무엇인가?"

이러한 질문을 누구로부터 듣는다면

여러분은 뭐라고 대답하실 건가요?

캡슐화, 다형성, C++, 오버라이딩, 오버로딩, 추상화, 상속, virtual 기타 등등....

수많은 후보가 있을 거라 생각합니다.

이들 중 제가 이야기 하고 싶은 후보가 하나 있습니다.

바로 "인터페이스" 입니다.

인터페이스는 객체지향의 개념중

가장 늦게 등장했지만, 그 등장은 필연적인것이 아니었나 생각합니다.

(C++, 스몰토크엔 없지만, 유사한 개념이 있고,

C# JAVA등 나중에 등장한 언어에서는 필수적인 요소입니다.)

하지만 딱 봐서는 도대체 이것이 왜 나왔고, 어디에 써야 하는지 알기 어렵습니다.

저도 도대체 인터페이스가 무엇을 위한 것인지, 이해하기 어려웠고 오랫동안 알고 싶었습니다.

그래서 여러 글과 책을 보고 나름 연구해본 결과를 아래 공유합니다. (스크롤 압박 주의)

1) 인터페이스는 무엇을 위한 것인가

인터페이스 - 위키백과, 우리 모두의 백과사전

ko.wikipedia.org

인터페이스(interface, 문화어: 대면부, 결합부) 또는 접속기는 사물 간 또는 사물과 인간 간의 의사소통이 가능하도록 일시적 혹은 영속적인 접근을 목적으로 ...

사전적인 의미에서의 "인터페이스"는 위의 위키피디아 링크처럼 "의사소통"을 위한

"수단(method)"과 같은 개념입니다.

우리가 사용하는 "언어 = 한국어"는 한국사람,

또는 한국어를 사용하는 사람들과 "소통" 하기 위한 수단입니다.

우리는 우리의 생각과 의지를 한국어란 수단을 통해서 다른 사람에게 전달합니다.

만일 영어를 안다면, 쓸수 있다면 더 많은 사람들에게 전달할수 있을 것입니다.

(왜냐면 영어는 표준이기 때문이죠.)

OOP언어에서도 인터페이스의 의미는 "한국어" 처럼

객체를 사용하기 위해서, 객체와 객체가 서로 "상호작용" 하기 위해서 필요한 도구를 의미합니다.

그래서 UML 2.0의 인터페이스 스타일을 보면 아래와 같이 "손잡이" 처럼 생겼습니다.

그리고 이 손잡이를 "붙잡음"으로서 인터페이스를 사용하게 되는 것이지요.

그림의 예는 매우 일반적인 예입니다.

자동차라는 클래스가 Handle이라는 Interface를 가지고 있고 이를 Driver가 이용한다는 의미이지요.

쉽게 말해서 "드라이버가 핸들로 자동차를 운전한다."는 것을 표현하는 것입니다. 붕~붕~

여기까지는 이해가 쉽습니다. 하지만 코드로 가면 약간 성격이 달라지게 됩니다.

C#문법 기준으로 인터페이스 Handle의 구현은 다음과 같습니다.

Interface Handle

{

void Drive();

}

그리고 인터페이스를 사용하는 Car 클래스는 다음과 같이 구현되어야 합니다.

class Car : handle

{

public void Drive()

{

}

}

그리고 Driver는 다음과 같이 인터페이스를 사용합니다.

class Driver

{

void Main()

{

Handle car = new Car();

car.Drive();

}

}

이 코드를  UML로 그대로 표현하면 이렇습니다.

이전 그림에서 Car와 Handle 의 관계는 "Association"인데

지금은 "상속"으로 바뀌어 있는것을 볼수 있습니다. 코드에서도 실제로 상속이구요.

여기서 저의 경우엔 약간의 혼동이 있었습니다.

다른 클래스가 이 클래스를 사용하기 만들기 위해서 왜 인터페이스를 "상속"해야 하는가?

에 대해서 의문을 가지고 있었습니다. 왜 굳이 상속으로 표현되어야 하는 것일까요?

(인터페이스가 아무런 구현도 없다는 사실을 알면 더욱 의문스럽습니다. 상속해줄 구현이 없는데

상속관계라니... 이게 무슨 의미가 있는건가요?)

왜 이렇게 되냐면,

객체지향에서 "public 상속"의 의미는 "is-a" 관계이기 때문입니다.

혹시 잘 기억이 안나는 분들을 위해서, Scott Myers의 명저 : Effective C++에 나온

이야기를 정리해 인용하겠습니다.

B가 D를 public 상속 하면 이는 is-a 관계로서 B에서 되는 것은 모두 D에서도 되어야 한다.

여기서 B는 D의 부모 클래스를 의미합니다.

결국, is-a 상속을 통해서 부모 클래스에서 되는것, 부모 클래스의 특성을 자식 클래스 또한 그대로 가지고 있어야 한다는 것입니다. 인터페이스의 모든 요소는 비록 형체만 있고 구현이 없는 것일지라도 이를 상속받는 놈들에서는 반드시 구현되어야 합니다. 왜나면 자식들은 부모인 인터페이스와 상속을 통해서 is-a 관계를 유지하기 때문이죠. 인터페이스가 가진 것들은 자식에서도 다 되어야 합니다.

 만일 인터페이스의 메소드 하나라도 구현하지 않는다면 컴파일러는 이를 꼭 구현해야 한다고 컴파일 에러를 뿜습니다. 컴파일 단계에서부터 날 상속해 쓰려면 꼭 구현하라고 강요하는 것이지요.

그럼 왜 이러한 "강요"를 시키는 것일까요? 내부에 구현도 없는 존재가 말입니다.

이는 "인터페이스"의 근본적인 특성과 관계가 있습니다.

다시 "한국어"로 돌아가 봅시다.

우리가 이야기를 하기 위해서 사용하는 "한국어"는 정형화된 언어입니다.

우리가 마음대로 만들어내고 자기 혼자 사용한다고 해서 그것이 한국어가 될수는 없습니다.

한국어를 사용하는 모두가 동의할수 있고 익숙한, 그리고 정해진 어법에 맞는 언어요소만이 한국어가

될수 있습니다. 여기서 이 "동의"와 "어법"이 중요합니다.

우리가 한국사람들과 소통하려면 우리가 사용하는 언어가 "한국어" 임을 보장해 줄수 있어야 합니다.

이를 위해서 우리는 "어법"이라는 것을 만들고 이를 모든 한국어를 사용하는 사람들이 배우고 지키게 해 왔습니다. 그리고 모두가 암묵적으로 "동의" 함으로서 사용하는 언어가 모두에게 사용될수 있는 것입니다. (

유행어가 오랫동안 유지되기 힘든데엔 이러한 이유가 있습니다. 한국어를 쓰는 일부 구성원들만이 동의하고 사용하며. 한국어 어법에 맞지 않기 때문에 오래가지 않아 도태되는 것입니다.)

 예시가 길었는데, 결국 인터페이스가 상속으로 "구현"을 강제하는 이유는 클래스간에 소통의 편의를 위한 일관된 "규칙"으로서 존재하기 위함입니다. 이 "인터페이스"라는 규칙을 통해서 여러 클래스=컴포넌트들은 서로 "일관되게" 소통할수 있는 것입니다. 이 "일관된 규칙화된 소통"을 바꾸는 행위가 발생했을때 컴파일러는 이를 잡아내어 "인터페이스"를 사용하는 모든 클래스들에 대해서 새로운 행위를 지키도록 강제합니다. 이것이 지켜지지 않는다면, 마치 유행어가 어르신들에게 이해되지 않는 것처럼 클래스들은 서로 잘못 사용하게 되고 결국 프로그램은 망가지게 됩니다. 그러므로, 객체지향 개념과 언어의 설계자들은 이런것을 시스템적으로 컴파일러 레벨부터 지키도록 만들었습니다. (정말 멋지지 않습니까?)

결국 이러한 일관된 규칙을 통해서 클래스들은 서로 믿고 소통할수 있게 되었고,

이 규약만 지키면 되므로 꼭 자신이 소통하려는 클래스 전체를 알지 못해도 소통이 가능하게 되었습니다. 마치 우리가 상대방을 몰라도, 한국어만 알면 이야기를 할수 있는 것처럼 말입니다.

이를 통해서 우리가 객체지향과 인터페이스의 장점이라고 이야기하는

"객체끼리의 의존성 감소"가 실현되는 것입니다. 그리고 이것이 객체지향이 추구하는 바입니다.

(그렇기 때문에 제가 객체지향의 꽃이라 감히 부르는 것입니다.)

이해를 돕기 위해서,

지금까지의 이야기를 하나의 과정으로

정리하자면 다음과 같습니다.

1) 클래스 간의 소통이 필요

2) 소통을 위해서 정해진 규칙이 필요

3) 정해진 규칙을 여러 클래스들에게 강제할수 있는 방법이 필요

4) is-a  관계의 "public 상속"은 "부모에서 되는건 자식에서도 되어야 해" 이므로 3)의 조건 만족

5) 4)의 is-a 관계를 통해서 인터페이스를 3) 으로 강제 구현할수 있도록 함으로서 1)과 2)의 조건

모두 만족

6) 결과적으로, 1)과 2)가 실현되고 이것이 5)를 통해서 컴파일러에서 지켜지는 것이 보장됨으로서

지금의 인터페이스 개념이 필요해지고 완성됨.

좀 이해에 도움이 되셨는지요?

2) 인터페이스는 언제 어떻게 써야 할까

그렇다면 인터페이스는 도대체 언제 써야 하는걸까요?


제가 처음 인터페이스에 대해서 너무 궁금해서 여기저기 찾아 보았지만 명확한게 없어
제 코드 멘토였던 분에게 질문한적이 있었습니다. 그분은 다른말은 안하고 코딩으로 직접 알려 주셨던 기억이 납니다. 아래는 그 내용을 제가 기억을 살려 재구성한 것입니다.
 
옛날옛날에, 웹에서 휴대폰 문자 메세지를 보내는 서비스를 하던 회사가 있었는데 이 회사의 메세징 라이브러리는 다음과 같이 구성되어 있었다.

그리고 이를 사용하는 메인코드는 다음과 같이 구성되어 있었다.

[code csharp]
public void Main(string ISPName, int phoneNo, string message)
{
      if (ISPName == "SKT")
     {
           SKTSMSManager manager = new SKTSMSManager();
           manager.InitSKT();
           manager.SendSKT(phoneNo, message);
           manager.CloseSKT();
     }
     else if(ISPName == "KTF")
    {
           KTFSMSManager manager = new KTFSMSManager();
           manager.InitKTF();
           manager.SendKTF(phoneNo, message);
           manager.CloseKTF();
     }
     else if(ISPName == "LGT")
     {
           LGTSMSManager manager = new LGTSMSManager();
           manager.InitLGT();
           manager.SendLGT(phoneNo, message);
           manager.CloseLGT();
     }
}
[/code]

처음에는 이러한 방식이 별 문제가 없었다. 하지만 시간이 지남에 따라 SMS 뿐만 아니라, MMS 또한 지원해야만 하게되었다. 통신사는 3개지만, 구현해야 하는 클래스는 6개로 늘어나게 되었다.

 그리고 위 메인코드의 분기문또한 2배로 늘어나게 되었다. 이후 통신사 서비스, 요금제마다 또 방식이 바뀌게 되어 결국 이에 맞추어 새로운 클래스와 분기문 코드를 만들어야만 했다. 분기문이 길어지다보니 코드들이 서로 꼬이는 부분이 늘어나 버그가 급증하고 읽기도 어렵게 되었다. 사장은 코드중복을 줄이거나 버그를 열심히 잡으려 노력했지만 늘어나는 클래스와 분기문을 주체하기 힘들었다. 게다가 클래스들이 동작하는 방식들이 각 통신사들이 서비스마다 메세징을 지원하는 방식에 따라 미묘하게 달라 이들을 추상화하거나 통합할 엄두를 내지 못하고 있었다. (이런일은 현업에서 매우 비일비재합니다.)
 
그때 혜성처럼 한 개발자가 나타났다. 그는 재야의 숨은 고수로 불리던 이XX 였다.
그는 3개월 이라는 시간만에 이 복잡한 클래스와 분기문들을 싹다 정리하고 수천만원을 챙기고 다시 재야로 사라졌다. 그가 사용한 방법은 무엇이었을까?

그는 인테페이스를 사용했던 것이었다.

각 클래스마다 공통으로 수행해야 하는 시퀸스를 담은 메소드들 Init(), Send(), Close()를 인터페이스로 추상화 하고 모든 메세징 클래스들이 이를 상속받게 한다. 이렇게 하면 새 메세징 클래스가 만들어 지더라도 IMessenger라는 인터페이스에서 요구하는 메소드들을 구현해야 되므로, 모든 클래스가 동일한 방식으로 접근하고 동작할수 있도록 강제할수 있다.

따라서, 메인에서 분기문을 없애고 직접 해당 메세징 클래스 객체를 넘기도록 다음과 같이 수정할수있다. 메세징 클래스에 접근하는 방법을 하나로 통일한 것이다. 결국 아래 메인 코드는 메세징 클래스가 늘어나거나 줄어들거나 상관없이 일관된 동작을 수행한다.

[code csharp]
public void Main(IMessenger messenger, int phoneNo, string message)
{
           IMessenger manager = messenger;
           manager.Init();
           manager.Send(phoneNo, message);
           manager.Close();
}
[/code]

여기에 약간의 추상화를 더하여 추상 베이스 클래스를 만들수 있다. 하지만 이는 세부적인 구현과 관계된 문제 : 서비스 방식이나, 통신사 규약이냐는 차이점에 따라 달라질수 있기 때문에 이번 화에서 이야기하려는 범위를 벗어남으로 "추상화와 추상 클래스 이야기"에서 다루도록 합시다...

어쨌든, 인터페이스를 통해서 서로다른 것들에 일관된 접근 방법을 제시함으로서 우리는 아래의 목적을 달성할수 있습니다.

1) 여러 클래스 간의 일관된 구현/확장 강제
2) 여러 클래스를 일관되게 Access 하고 싶을때

 

 

이렇게 인터페이스는 가장 나중에 나온 객체지향 개념답게, 객체지향을 확실히 객체지향 답게 만들어주는 중요한 기능을 제공해주고 있습니다. 따라서 인터페이스에 친해진다면 좀더 객체지향다운 코드를 짜실수 있을 겁니다.

 

지금까지의 이야기는 제 경험과 연구 그리고 생각에 의한 이야기이기 때문에 실제 사실과는 조금 다를수 있습니다. 다만, 보시는 분들이 이글을 통해 "인터페이스"에 대해서 좀더 이해를 넓히는 실마리가 되었음 합니다.

 

 

윈도폰 7에선 더이상 네이티브 개발이 안된다?

윈도폰7용 파이어폭스 개발이 중단된 이유 - ZDNet Korea

www.zdnet.co.kr

2010년 3월 26일 ... 윈도폰7용 파이어폭스 개발이 중단된 이유. 임민철 기자 imc@zdnet.co.kr. 2010.03.28 / PM 03:09. 모질라, 파이어폭스, 브라우저, 모바일, 스마트폰, ...

이미 회자된 것이지만,

윈도폰 7에는 더이상 네이티브 개발이 들어갈 자리가 없군요...

기사의 내용은, 파이어폭스는 기존의 윈도우 개발환경을 사용하지 않는 완전히 독립된

개발로 진행되어 왔고, 네이티브로 만들어져 와서 현재 윈도폰 7처럼 개발을 한정지을 경우

이를 위해서 코어를 다시 만드는 개발을 진행할수는 없다.

 

따라서 파폭 모바일 7은 못만들겠다.

 

이러한 이야기입니다.

 

이미  MS에서 이야기 한대로 윈도폰 개발의 2 방법은 다음과 같습니다.

 

1) 일반 앱 : 실버라이트

2) 게임 : XNA

 

둘다 c# 기반의 매니지드 환경이라 C++이 치고 들어갈 틈이 없어 보입니다.

왜 C++을 버리게 되었을까요? 최근 MS의 행보를 기준으로 유추해보면

 

1) .NET 프레임웍을 주력으로 확정짓기 위한 행보

 (여기엔 차세대 윈도를 닷넷기반으로 만드는것도 포함됩니다.)

2) .NET 프레임웍 개발이 중심임을 기정사실화 하여 플랫폼 경쟁에서 우위를 선점하기 위해서

3) 아이폰에서 배운 애플의 폐쇄정책 (MAC + Xcode + Objective C)의 교훈

 

때문이 아닐까 합니다.

결국 가면 갈수록 저같은 MS .NET 빠돌이들은 개발할수 있는 영역이 늘어나는 반면

네이티브 개발자들은 점점 영역이 좁아질지도 모르는 일입니다.

(하지만 아직 MFC/C++/CLI에 대한 지원이 계속되고 있으니, 완전히 버렸다고는 할수 없겠지요.

하지만 완전 네이티브 개발도 계속 매니지드 영역으로 편입될 것으로 보입니다.

그리고 MS가 C#을 주력 언어로 밀어부치는 것도 확실하구요 : 여기에 대해선 추후 좀더 다루겠습니다.

할말이 많아서 ㅋㅋㅋ)

 

결국 차세대 윈도폰 개발을 하고싶은 사람들은

좋던싫던, 실버라이트/WPF/XNA를 배워야 할 날이 다가오고 말았습니다.

 

(뭐, 여러 개발사들의 반발이 심하면 플래쉬 경우처럼 네이티브 개발 영역을 열어줄지도 모르는 일입니다. )

 

 

뱀발:

누구는 MS가 점점 개발자를 바보로 만들고 있다고 하는데

(이경우 매니지드 환경 자체가 쉽기? 때문에 개발자를 바보로 만든다고 생각하는 편입니다.)

사실 MS입장에서는 자사 플랫폼이 좀 더 많은 사람에게 쓰이는 것이 목적이기 때문에

상위 개발자들보다 하위 개발자를 포섭시키고 개발업무의 효율성을 증가시킬수 있는 닷넷을

미는것이 옳습니다. 그리고 저같은 개발자 입장에서도 처음에는 닷넷이 별거 없다고 생각했지만

사실 CLR via C#. Effective C#, C# the programming language 등의 책을 읽어보면

.NET 프레임웍이라는 것이 현대 컴퓨터 공학의 정수를 많이 담아둔 것임을 알수 있을겁니다.

 

중요한건 자기가 처음부터 모래성을 다 만들면서 배우냐, 아니면 이미 잘 쌓여진 모래성을 연구하면서

실력을 쌓느냐에 달려있는것 같습니다. 결국 배움의 의지와 노력에 달린것이지요.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Windows Phone 7 Information

안녕하세요, 불곰입니다.

윈도폰 7 관련하여 개발을 해보고자 여기저기 자료를 찾아서 몇개 모아봤습니다...

그리고 들리는 이야기로 LG에서 지난달 HW 데모를 내놨다는군요.

(삼성은 안드로이드 올인인데... 과연 Win7 Phone이 나올까요?)

MIX10

MIX10에 나온 윈도폰 관련 내용...

폰에 대포를 연결해서 가속도 센서로 각을 조절해 쏘는군요

(학교에서 공작수업으로 했던 포트리스가 생각납니다. ^^)

http://blogs.msdn.com/eva/archive/2010/03/17/mix10-7-ie9.aspx

이런거 보면  MS가 "재미"를 자꾸 강조하는것 같습니다.

삼성도 좀 "재미"를 강조했음 좋겠습니다.

(당장 "돈" 되는것 이외엔 별로 관심이 없으니...안타까울 따름입니다.)

윈도우폰 7 시리즈 무료 개발툴 다운로드

이 링크에서는 윈도 마켓플레이스 등록이 가능하고

http://developer.windowsphone.com 

이 링크에서는 툴을 직접 다운로드 가능합니다.
http://developer.windowsphone.com/windows-phone-7-series/

 

위트스튜디오

지인들이 모여 만든 닷넷 전문 커뮤니티 - 위트

http://blog.witstudio.net/category/Developer/Windows%20Phone

페졸드 아저씨 책

 

CodeSamples_DRAFTPreview_ProgrammingWindowsPhone7Series.zip

ProgWinPhonePreview.pdf

 

이 아저씨는 정말 대단한것 같습니다.

책 빨리 내는것도 그렇고

쓰면 읽는사람 지치고 지루할 정도로 자세히,

그리고 두껍게! 쓰는것도 그렇고...

 

아마 MS에서 페졸드 아저씨 명성을 이용하려고 하는것도 있겠죠.

 

 

이 글은 스프링노트에서 작성되었습니다.

Windows 7 Phone

 

불곰은 .NET 개발자입니다.

JAVA 개발자가 JAVA로 먹고살듯이

.NET으로 먹고살아 왔고 현재도 그렇습니다.

앞으로도 .NET 으로 먹고살수 있을지는 장담하기 어렵지만

MS가 완전히 망하지 않는 이상, 취미로라도 계속 .NET을 할 것입니다.

 

불곰은 PC Client Application이 전문입니다.

주로 PC나 이에 상응하는 중/고사양 PC에서 돌아가는 어플들을 만들어 왔죠.

하지만 항상 모바일에대한 관심이 있었고 AppStore 가 나왔을때엔

진짜 심각하게 맥을 살까 고민도 했습니다.

비싼돈들여 iPod Touch를 산것도 Apps 때문이었습니다.

 

윈도우 개발자이니까

윈도 모바일 개발을 하면 어떨까 생각도 했습니다만,

역시 윈도 모바일은 하나도 예쁘지 않더군요...

 

"예뻐야 되, 무조건 예뻐야 되" 라는 금자씨의 명언처럼

예쁘지 못한 WM은 저에게 실망 그 자체였고

자연스레 강력한 표현력을 지닌 플래쉬나 WPF등으로 갈아타고 있었습니다.

 

그런데 결국 실버라이트가 일을 냈군요.

 

 

 

 

 

이전부터 실버라이트 모바일이라고 하여 플래쉬 모바일을 맞수로 하여 Feature Phone에서도

미려한 UX를 보여주겠다고 그래서 언제쯤 써볼수 있을까 고대하고 있었습니만...

출시가 늦어 사실상 포기하고 있었습니다.

(쓸수 있었다면... 삼성전자 가전제품의 UX가 실버라이트 모바일이 되었을지도 모릅니다.)

 

그런데 이번 MWC 2010에 발표된 Windows 7 Phone은 실버라이트 모바일이 보여줄수 있는 한계를

훌쩍 뛰어넘어 일반 클라이언트 어플수준의 UX까지 보여주는군요...

"예쁜 디자인"을 신경써온 개발자로서는 멋져보일수 밖에 없습니다. ㅜㅜ

(실버라이트 개발팀 분들 에게: 엉엉 날 가져요 ㅜㅜ 부탁이삼)

 

 제 디자이너 친구 oblidust씨는 이러한 7 phone의 UX적 변화에 대해서

기존의 iPhone 식 고정관념을 깬 새로운 Innovation 이다 라면서 꽤 높은 점수를 주더군요.

 

그에비해, 저와 가까이 있는 삼성의 Bada Phone - Wave는 iPhone 판박이구요...

저희도 Innovation을 한번 했으면 좋겠습니다.

종종 초 일류기업이라면서, 선도하지 않고 따라가는것만 좋아하는것 같아서 안타까워요~

 

삼성 Wave 화면, 실제로 저렇습니다. Wave의 터치위즈 UI가 옴니아 2의 그것보단 빠른것 같아요.

 

일각에서는 과연  MS가 Phone으로 성공할 것인가? 하는 의문을 많이 품고 있습니다만

(사실 MS는 이전에도 몇번 폰을 내놨지만 별로 반응이 좋지 않았답니다.)

제 생각엔, 삼성이 독자 플랫폼 Bada로 iPhone 시장에 도전장을 내밀고 있는것과

마찬가지라 생각합니다. 두고봐야죠.

 

어쨌든 개인적으로는 이러한 WM의 새로운 변화를 저는 새로운 기회로 보고 싶습니다.

그리고 좀더 즐겁게 모바일 개발을 할수 있었음 합니다.

(얼마전에 푸와 WM으로 오랜만에 개발을 했었는데... 힘들어 고생 많이 했습니다. ㅜㅜ)

저도 그러한 즐거운 윈도우 모바일 개발에 뛰어들고자 준비중입니다...

그리고 그러한 발자취를 계속 방문해주신 분들과 공유할 생각입니다...

 

저희 블로그를 지켜봐 주세요~~~!