기본 콘텐츠로 건너뛰기

9월 12일 마소 행사 메모

앞에의 1~2 챕터

윈도우 10앱 개발

윈도우 10은 확장을 위해 제작

PC 에만 집중해서는 마소가 살아남기 힘들다고 판단

앱 개발 플렛폼이 통합됨

소스코드 상의 통합이아닌 바이너리 단위에서의 통합이이루어짐(그래서 디자이스는 여러개지만 마켓은 하나뿐)

UWP가 여러 부분에서 더편함 기존에 잇던것들도 실행가능

다이렉트 X의 경우 C#에서는 개발이 불가능하고 C++에서 가능하다

JavaScript 로 코당할때는 HTML로 코딩하도록됨

브릿지 기술

Ex) ios 앱을 가져와서 컴파일 시키면 윈도우앱이된다
안드로이드 애플리케이션을 사용하여 윈도우앱을 만듬(프로젝트 아스토리이아)
웹을 이용하여 앱으로 바로 제작가능(단점 : 앱에서 지원 되는 것들은 자바스크립트로 대체해야됨)

-사이트 참과여 공부하면 도움이 될듯함

디자인 할때 메뉴를 세로로 왼쪽에 배열

Universal Windows 에 확장 -> UWP -> 해당앱에 관련된 기능 추가

개발 순서 (기능을 조금씩 확장해 나가면서 개발)
1. 일단 PC 용제작
2. 핸드폰용 앶 제작 (기능 확장)
3. XBox용 앱 제작 (기능 확장)

보안은 윈도우폰이 안드로이드보다 훨씬 좋음

앱등록 방법
위의 dev.windows.com 의 대시보드에 들어가서 왼쪽에 메뉴에 추가하는 것이 붙어잇음
무언가 만들고 싶은게 있다면 일단 이름은 등록이 가능하니까 이름 먼저 등록해 두는 것이좋음(유니크하게)

*윈도우로 뭔가를 만들어야겟다고 생각된다면 빨리 이름이라도 잡아두는것이 중요

 It's all about UWP
UWP : universal Windows Platform

1. XAML
2. Tool
3. Databinding

새로운 컨트롤
* RelativePanel
Element는 또다른 Element의 상대적 위치를 가짐
적응형 UI에 이용
Visual State 와 동시에 이용된다
Panel을 기준으로 상대적 정렬 설정

*SplitView
윈도우 폰 설정과 윈도우 10 설정은 동일한 코드로 만들어 졋지만 이 스플릿 뷰를 이용하면 여러기기에 대응하는 UI를 만들수 있다.

*Adaptive UI
Visual states

상태 전환 방법 
VisualStateManger.goto()
다 코딩해야됨

*Adaptive trigger
코드없이 XAML에서 설정만으로 상태전환가능




XAML 성능
*Phase rendering
가능한 적은 단계로 관리 (제한은 없지만 3개 이하가 이상적)
연속적일 필요는 없음

*deferred loading
특정 시간까지는 작동하지 않아도 되는 element 등을 처리 하지않게하여 성능향상
초기 로드되는 요소 최소화
요소가 요구 되기 전까지는 로드되지 않는다

경량의 proxy element 가 대신 생성됨
이벤트는 element가 로딩된후 등록




Tool (visual studio 2015에 추가된것)
진단도구 (코드 우측에 걸리는 시간제공 및 프로파일링 기능 제공
중단던
직접실행창 (LINQ실행가능)
라이브 시각적 트리 (어플리케이션의 트리를 탐색할수잇는 기능)
라이브 속성 탐색기




Databinding
*기존 데이터 바인딩 방식
Class binding, {binding}
정적/동적 바인딩
convert

정적 데이터 바인딩
Static

동적 바인딩
바인딩 표현식 {Binding ....}
DataContext 설정 필요
값이 없을 경우 그냥 아누것도 출력이 되지않고 오류가 발생하지는 않음

INPC
INotifyPropertyChanged
UI업데이트
Data -> UI

INCC
INotifyCollectionChanged



*컴파일 바인딩
Compiled binding
바인딩 성능 향상 && 기존의 편리함을 유지
새로운 데이터 바인딩 원리
컴파일타임에 바인딩의 일정작업이 진행됨

런타임시 부하가 적고
런타임시의 리플렉션 코드 최소화
변환된 코드는 디버깅 가능

대상 타입의 명시적인 선업필요
-> 해당 패이지의 멤버만 바인딩 가능

Resource dictionary 

이벤트 바인딩

{X:bind}
컴파일된 바인딩

고려해야할점
MVVM에서 적용
JSON 에서 문제

Mva 홈페이지에 발표자료와 영상 업로드 예정



( 3챕터는 밖에 나갓다와서 잘 못들어서 제외)

4챕터

Windows 10 IoT Core = UWP + IoT Extention (GPIO, I2C 등)

API 호환
데스크탑 API의 54%공유 (나머지는 모바일 전용 셀롤러 데이터등)
모바일의 84% (센서 부분을 위한 API)

GDI
WinForm

하나의 UI 앱
간편한 peripherals 접근
UWP앱, 드라이버 지원 (커널 드라이버면 다시 컴파일 할경우)
Win 32.NET지원, But NO GDI, NO MFC

개발환경
Windows 10 개발 PC
    |
타겟 디바이스

이용 어플리케이션
Power Shell
Visual Studio
등등


지원보드 (현제 정식)
MinnowBoard MAX
Raspberry Pi 2
DragonBoard 410C

GPIO : 사용자 정의 통신
I2C : 낮은 스피드, 많은 디바이스 지원
SPI : 높은 스피드, 적은 디바이스 지원

간단하게
Windows.devices.gpio 등을 사용하면 사용가능

I2C 의 장점
다른 보드 작업 필요 없음
출력 값은 디지털 신호

조도센서 LSL2561
16bit 출력, I2C 연결, 400KHz
Slave address 는 0x39

영어나 열심히 하자....

Connect The Dots
PowerBI
Azure (센서값 모으고 분류)
(IoT 센서에 큰 도움을 줄것으로 보임)

TO DO...
WindowsOnDevices.com
라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

C의 volatile

가장 쓰이지 않는 C/C++ 언어의 volatile 이라는 키워드가 있다. 이 키워드는 대부분의 참고 서적들이 컴파일러의 최적화를 막아준다고만 적어둘 정도로 사용 빈도수가 적기도하고 중요도 까지도 낮은 그런 키워드인 셈이다. 하지만 이 키워드가 임베디드 소프트웨어 에서는 중요한 키워드중 하나가 된다. 거의 하드웨어가 사용하는 메모리 선언 시에 사용되고 다음과 같은 경우에 사용되는 편이다. 메모리 맵 입출력(MMIO)을 제어 인터럽트 서비스 루틴 사용 멀티 쓰레드 환경 이렇게 3가지에 사용되는데 임베디드에서는 주로 아래와 같은 예시들과 같은 경우에 주로 사용된다. 예시 1) unsigned int* test; test = (unsigned int*) 0x1020; test = (unsigned int*) 0x1028; 예를 들어서 다음과 같은 코드가 있을때 컴파일러는 중간 문장은 필요 없는 것으로 판단하고 제거한뒤 컴파일 할것이다. unsigned int* test; test = (unsigned int*) 0x1028; 결과 적으로는 위 문장만 실행되는데 volatile 키워드를 사용하면 이것들이 전부 컴파일 되서 전부의미를 가지게 된다 volatile unsigned int* test; test = ( volatile unsigned int*) 0x1020; test = ( volatile unsigned int*) 0x1028; 예시 2)  예를 들어 0x1234에 8비트의 status 레지스터가 있고, 이 레지스터가 0이 아닌 값을 가질때까지 폴딩하기 위해서 아래와 같은 코드를 작성했다. (루시퍼님 블로그의 예시가 적당해서 가져왔다) INT8U *ptr = (INT8U *)0x1234; while (*ptr == 0) 만약 옵티마이징을 키게 된다면 이것은 move ptr, #0x1234 move a, @ptr loop bz loop 이렇게 다시는 0x1234값을 받아오지 않게 어셈블...
댓글 쓰기
자세한 내용 보기

HomeNews Alpha Final!

그런데 인성인증인데 왜 기술적인걸로 프로젝트를 햇더라 파싱은 제리코 라이브러리를 사용해서 완성시켰다. 이제 PPT짜러...! 거의 다완성되간다!
댓글 쓰기
자세한 내용 보기

C언어 register 변수의 함정카드

C언어를 하다보면 register 라는 CPU의 레지스터에 자료를 저장하는 변수를 알수있다. 대신에 한 프로그램에서 최대 2개 정도까지만 사용이 가능하고 지역변수만 가능 및 32bit CPU는 32bit 크기의 변수만 사용 가능하다. 장점만 보면 기본적으로 메모리쪽에 저장되는 일반 변수들보다 더 빠르게 접근이 가능할 것 같은데...인라인 어셈이랑 메모리랑 레지스터랑 비교하면 어떤게 가장 빠른지 궁금해서 한번 테스트 해보게 되었다. 우선 테스트 해볼 코드는 다음과 같다. 거의 동일한 연산을 하고 다른 점이 있다면 인라인 어셈은 전부 다 레지스터를 이용해서 연산한다는 정도...? 위의 코드를 컴파일 해서 실제로 돌려보면 실행 결과는 다음과 같이 나온다. !? 그냥 아무런 형식도 지정해주지 않은 auto와 똑같은 결과가 나온다. # C언어는 기본적으로 아무런 형식을 지정해주지 않으면 auto로 해준다. # int a => auto int a 그래서 어째서 저런 결과가 나왔는지 컴파일에 옵션을 줘서 어셈파일을 분석해 보았다. 인라인 어셈 auto for register for push ebp mov ebp, esp mov ecx, 0 jmp SHORT $INLoop$3 $INLoop$3: cmp ecx, 10000000 jae SHORT $EXIT$4 mov eax, ecx shl eax, 2 inc ecx jmp SHORT $INLoop$3 $EXIT$4: cmp ebp, esp call __RTC_CheckEsp popebp ret,0 push ebp mov ebp, esp sub esp, 8 mov DWORD PTR [ebp-8], -858993460 mov DWORD PTR [ebp-4], -858993460 mov DWORD PTR _i$2[ebp], 0 jmp SHORT $LN4@For $LN...
댓글 쓰기
자세한 내용 보기