Pokazywanie postów oznaczonych etykietą Visual Studio 2012. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą Visual Studio 2012. Pokaż wszystkie posty

wtorek, 17 września 2013

Windows 8.* + Visual Studio 201*

W przypływie zachwytu nad najnowszymi Windows i Visual Studio umknął mi jeden cichy szczegół, a może nawet dwa.

Otóż Visual Studio 2013 (także najnowsze RC) nie pozwala tworzyć nowych projektów Windows Store przeznaczonych dla Windows 8.0. Każdy nowy projekt VS 2013 dla Windows Store będzia działać tylko na Windows 8.1. VS 2013 pozwala jedynie utrzymywać projekt stworzony w Visual Studio 2012 dla Windows 8. Opisane jest to na stronie http://msdn.microsoft.com/en-us/library/vstudio/hh266747(v=vs.120).aspx. Była również wzmianka o tym na sesji BUILD’a, ale nie zwróciło to specjalnie mojej uwagi. Warto rzucić też okiem na rozważania w poście http://tedwvc.wordpress.com/2013/07/19/visual-studio-2013-support-for-targeting-windows-8/.

Następnym zamieszaniem jest kwestia wersji systemu 8.1 i Visual Studio 2013 do pisania aplikacji dla Windows Store. Na publicznie dostępnym Windows 8.1 Preview należy wciąż używać VS 2013 Preview.  Z VS 2013 RC mogą korzystać wyłącznie posiadacze Windows 8.1 RTM. Informacje te są umieszczona na stronie http://msdn.microsoft.com/en-US/windows/apps/bg182409. Jednak dopiero narzędzia w wersji RTM umożliwią publikacje do Windows Store. To wszystko ruszy 18 pażdziernika. Więcej informacji na http://blogs.msdn.com/b/stevengu/archive/2013/09/09/download-windows-8-1-rtm-visual-studio-2013-rc-and-windows-server-2012-r2-rtm-today.aspx.

Podsumowując mamy obecnie kilka opcji dla pisania aplikacji Windows Store:

  • Windows 8.0 + VS 2012
  • Windows 8.1 Preview + VS 2012 / VS 2013 Preview
  • Windows 8.1 RTM + VS 2012 / VS 2013 RC

Prowadzona polityka w VS 2013 ma swoim założeniu zachęcać do pisania nowych aplikacji dla Windows 8.1.

piątek, 12 kwietnia 2013

Node.js + Edge.js (2)

Dziś poruszę wywoływanie skompilowanego assembly .NET z poziomu node.js.

image

Na początku zaznaczę, że nie bedę opisywać wszystkich zagadnień i szczegółów związanych z komunikacją JavaScript (node.js) i .NET 4.5 (maszyna wirtualna CLR hostowana w procesie node.js). U mnie to będzie konkretny praktyczny przykład takiej komunikacji. Do pełnego zrozumienia omawianej tematyki polecam zapoznanie się z informacjami pod trzema adresami:

Edge.js jest dzieckiem Tomasza Janczuka, który w Microsoft najpierw zajmował się serwisami danych, później komunikacją w Silverlight, a obecnie jego zadaniem jest tworzenie rozwiązań w oparciu o node.js, JavaScript i Windows Azure.

Po co takie wywoływanie .NET z node.js?  Chcemy oczywiście jak najwięcej nowych rozwiązań, ale nic nie jest idealne. W zależności od zmieniających się warunków i priorytetów może czasami chcielibyśmy dać sobie elastyczną furtkę, by wykorzystać część dotychczasowego kodu w C#?  Po drugie przepisywanie w wielu przypadkach nie ma żadnego sensu, chyba że rzeczywiście coś na tym zyskamy np. większą wydajność, większą niezawodność czy większą wygodę używania. Jednak skompilowany C# czy C++ na pewno będą wydajniejsze niż JavaScript (choć ostatnio pojawia się prekompilacja tego ostatniego).

Wróćmy do node.js.  Załóżmy, że czasami mamy działający “legacy code” w .NET, którego nie chcemy przepisywać. Może to być coś w stylu poniższego kodu:

image

Przejdźmy do integracji. Załóżmy najpierw, że ten kod zostanie umieszczony razem z kodem integracyjnym w jednym assembly .NET 4.5. Kod integrujący wygląda w następujący sposób:

image

Zawsze musi być klasa o nazwie Startup, która zawiera jedną lub więcej metod koniecznie o sygnaturze Func<object,Task<object>>. Ta asynchroniczność jest zawsze potrzebna, nawet gdy wykonujemy w C# prostą synchroniczną operację typu 2+2. Dlaczego?  Node.js jest jednowątkowy, CLR jest wielowątkowy, ma inny model, to zupełnie inne środowisko. Przejdźmy do wywołania powyższego kodu z poziomu TypeScript/JavaScript:

image

Assembly z kodem “legacy” i kodem integrującym znajduje się w głównym folderze serwera. Całość ładnie działa i dostajemy JSON-a w oknie przeglądarki:

image

Jak debugować powyższy kod .NET w node.js?  Bardzo prosto! Uruchamiamy nasz serwer w konsoli i attachujemy się w Visual Studio 2012 do procesu node.exe (możemy sobie wybrać, jaki rodzaj debuggera chcemy użyć, powinien być tutaj do kodu zarządzanego CLR 4.0/4.5). Zgodnie z opisem autora Edge.js to po prostu działa! Zresztą praktycznie wszystko można debugować. W przypadku C# oprócz postaci skompilowanej jest to także możliwe dla postaci skryptowej (w prawie wszystkich przypadkach).

A co, jeśli mamy “legacy” kod w skompilowanym assembly dla starszej wersji .NET, np. 4.0?  Sprawdziłem również taki scenariusz umieszczając kod integrujący w assembly dla .NET 4.5, które odwołuje się do assembly .NET 4.0. Obie biblioteki umieściłem obok siebie, jak w przykładzie powyżej. Również wszystko ładnie działa (zgodnie zresztą z teorią).

Podsumowując, łączenie node.js z .NET wygląda całkiem zgrabnie, choć daleko do bezszwowej integracji jaką oferuje Windows Runtime -;) Ale wynika to pewnie z zupełnie innego podejścia do obsługi wątków w node.js i w CLR .NET. Tutaj mamy dopasowanie do czegoś, co jest tworzone z myślą o różnych systemach operacyjnych i jest zasadniczo oparte o JavaScript. W WinRT twórcy mieli wpływ na całość rozwiązania, więc mogli zrobić to lepiej.  Ale ogólnie edge.js to super rewelacja!  Będą liczne integracje z rozwiązaniami Microsoft (m.in autentykacja ASP.NET, kryptografia, obsługa certyfikatów w magazynie, Event Log, komunikacja z serwisami SOAP i WCF, Active Directory, MS SQL). O planach rozwoju można przeczytać na http://tjanczuk.github.io/edge/#/24.

BTW jeśli chodzi o języki w Edge.js, to możliwe jest napisanie wsparcia dla każdego języka CLR, natomiast na obecny moment wspierany jest C# (w postaci skompilowanej i jako skrypt dynamicznie kompilowany) oraz Python.

niedziela, 20 stycznia 2013

Windows Phone 8 na żywo - odc 2 (komendy głosowe)

Dziś napiszę trochę o komendach głosowych w WP8.

W WP 7.x można było używać tylko standardowych poleceń typu “Otwórz kalendarz”. Teraz mamy możliwość definiowania dla naszych aplikacji własnych komend z frazami. Postanowiłem trochę się zabawić i zamienić aplikację z ostatniego posta w szafę grającą spełniającą ustnie wypowiadane życzenia. Pamiętam, że w dzieciństwie podziwiałem jakiś układ elektroniczny przełączający obwód na zadane hasło… Były też bajki o Sezamie… No czy jakoś odwrotnie -;) W każdym razie dziś mała namiastka tego.

Obsługa mowy jest bardzo prosta. Jest to część wysokopoziomowego WinPRT API (btw szkoda że nie ma takiego API w Windows 8).

Zacznijmy od zdefiniowania pliku XML z komendami (najlepiej użyć do tego predefiniowanego szablonu w Visual Studio).  W moim przypadku komendy w języku polskim przedstawiają się w tym pliku następująco:

<?xml version="1.0" encoding="utf-8"?>

<VoiceCommands xmlns="http://schemas.microsoft.com/voicecommands/1.0">

  <CommandSet xml:lang="pl-PL" Name="myPolishCommands">
    <CommandPrefix>Tuba</CommandPrefix>
    <Example>Graj ostatni</Example>

    <Command Name="playVideo">
      <Example>Graj ostatni</Example>
      <ListenFor>[Graj] {video}</ListenFor>
      <Feedback>Gram {video}</Feedback>
      <Navigate Target="/StartPage.xaml"/>
    </Command>

    <PhraseList Label="video">
      <Item>ostatni</Item>
      <Item>losowy</Item>
    </PhraseList>

  </CommandSet>

   …
 
</VoiceCommands>

Ogólnie zakładam mówienie w trzech postaciach: “Tuba, graj ostatni”, “Tuba, graj losowy” lub “Tuba, graj {nazwa utworu}” oraz krótsze wersje tych wypowiedzi bez słowa “graj” (zdefiniowane jest ono w []). Pierwsze dwa przypadki są zdefiniowane w samym pliku XML (fraza “video” o wartościach “ostatni” i “losowy”, wstawianie wartości z frazy oznaczone jest {}). O trzecim przypadku za chwilę. Warto wspomnieć, że w tym samym pliku możemy równocześnie zdefiniować inne wersje językowe komend poprzez inny CommandSet (u mnie “myEnglishCommands” z językiem en-US). Druga rzecz jaką warto dodać, to wygodne przełączanie języka mowy w Ustawienia –> Mowa. Jest to zupełnie niezależne od wszystkich innych ustawień językowych w telefonie.

Należy teraz zarejestrować w systemie zdefiniowane przed chwilą komendy. Czynimy to raz przy uruchomionej aplikacji (przeważnie w obsłudze zdarzenia Load strony startowej).

        async private void RegisterVoiceCommandsAtFirstRun()
        {
            var appSettings = IsolatedStorageSettings.ApplicationSettings;
            if (appSettings.Contains("firstRun")) return;

            Uri uri = new Uri("ms-appx:///VoiceCommands.xml", UriKind.Absolute);
            await VoiceCommandService.InstallCommandSetsFromFileAsync(uri);           

            appSettings["firstRun"] = true;
        }

Na tym etapie po jednokrotnym uruchomieniu aplikacji możemy wrócić do ekranu startowego i przytrzymać dłużej przycisk Start. Pojawi się okno dialogowe do słuchania komend (pierwszy screenshot z poniższych). Jeśli chcemy wiedzieć jakie aplikacje na naszym telefonie wspierają komendy naciskamy “?” i wyświetla się nam odpowiednie okno z pivotem (drugi screenshot). Przechodzimy wtedy do zakładki “aplikacje” (trzeci screenshot). Wróćmy jednak do chwili, gdy jesteśmy słuchani. Wypowiadamy nasze magiczne słowa i jeśli zostaniemy dobrze rozpoznani, to pojawi się okienko z ikoną naszej aplikacji i usłyszymy odpowiedź określającą podejmowaną czynność np. “Gram ostatni” (czwarty screenshot). Następnie aplikacja zostanie otworzona na wskazanej w definicji komendy stronie (u mnie jest to StartPage.xaml)

VC0_PL  VC1_PL  VC2_PL  VC3_PL

Jak aplikacja dowiaduje się, przez jaką komendę została uruchomiona? Komendy mogą mieć przecież różne parametry i zachowanie aplikacji może być nimi uwarunkowane. Twórcy WP8 nie szukali długo, zrealizowali to tak jak każdy inny mechanizm deep linking. Do adresu strony są doklejane parametry w określony sposób. W moim przypadku odczyt przychodzących parametrów został zrealizowany na stronie StartPage w następujący sposób:

        async protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
        {
            base.OnNavigatedTo(e);

            //…

            if (e.NavigationMode == System.Windows.Navigation.NavigationMode.New)
            {
                if (NavigationContext.QueryString.ContainsKey("voiceCommandName"))
                {
                    string voiceCommandName = NavigationContext.QueryString["voiceCommandName"];

                    switch (voiceCommandName)
                    {
                        case "playVideo":

                            string video = NavigationContext.QueryString["video"];

                            //…                          

                       if (video == "last")
                       {
                          //...
                       }
                       else if (video == "random")
                       {
                          //...
                       }
                      else
                      {
                         //...
                      }

                            //…

                            break;

                        default:
                            break;
                    }
                }
            }

            //…

      }

Jak dodać tytuły klipów zarządzanych przez aplikację do wartości frazy “video”? Zbiór wartości odświeżam korzystając z metody:

        async private Task UpdatePhrasesForVoiceCommands(string voiceCommandSet, string[] startPhrases)
        {
            var phrases = startPhrases.Concat(AllVideos.Select(f => GetTitle(f.Name.Replace(".mp4", "")))).ToList();

            var videoVcs = VoiceCommandService.InstalledCommandSets[voiceCommandSet];
            await videoVcs.UpdatePhraseListAsync("video", phrases);
        }

Tytuł nagrania z YouTube obcinam do słów, które powinny zawierać tytuł utworu (GetTitle). Całość wywołuję w następujący sposób:

await UpdatePhrasesForVoiceCommands("myPolishCommands", new string[] { "ostatni", "losowy" });

Przykładowe uruchomienie aplikacji za pomocą komendy zawierającej nazwę utworu pokazałem na poniższym nagraniu:

P.S  API dla mowy w WP8 obejmuje także zamianę tekstu na mowę oraz rozpoznawanie mowy za pomocą wbudowanych i własnych gramatyk, ale o tym może innym już razem.

piątek, 21 grudnia 2012

BUILD 2012 News (33)

Prezentacje nt. technologii Web - ASP.NET SignalR i przyszłość

 

Building Real-time Web Apps with ASP.NET SignalR

Niezły przegląd możliwości SignalR.

image

image

image

image

image

image

shootr.signalr.net

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

 

Bleeding edge ASP.NET: See what is next for MVC, Web API, SignalR and more…

Przyszłość nie została ukazana jako coś przełomowego. Sporo czasu poświęcono jesiennej aktualizacji ASP.NET i różnym usprawnieniom. Osobiście zwróciło moją uwagę debugowanie Type Script.

ASP.NET Fall 2012 Update

  • Web API Docs
  • Web API Tracing

image

  • Web API OData

image

image

image

  • ASP.NET MVC Intranet application (Windows + Windows Azure auth)

       VS –> Solution Explorer –> Enable Windows Azure Authentication (prawy przycisk)

       Publikacja na Windows Azure (na podstawie wyeksportowanego publicznego profilu)

  • ASP.NET SignalR (nowe szablony: SignalR Hub Class, SignalR Persistent Connection Class)
  • Facebook Application

image

image

  • Single Page Application

image

image

image

image

image

  • Webowe aplikacje mobilne

image

image

Pobranie .zip jako pakiet do nuget i jego instalacja

Scaffolding

VS –> Solution Explorer –> Add Scaffolded Item

image

image  image

image

image

Type Script

*.js.map - podpowiedzi dla debuggingu

image

Debugowanie TS w Chrome

image

Async

image

image