Skip to main content

What is HTML5 for native Windows 8 applications

Am vazut ca foarte multa lume se plange de faptul ca codul HTML5 scris pentru aplicatii native for Windows 8 nu este compatibil pe alte browsere.
Cea ce trebuie subliniat este faptul ca aplicatiile scrise pentru WinRT nu sunt cross-platform. De exemplu daca apelan din JavaScript API de WinRT pentru a vedea locatia GPS atunci ne putem lua adio de la notiunea de cross-platform. Trebuie avut grija ca API de WinRT nu se refera doar la functionalitati apelate din JavaScript. Cand folosim un layout specific din HTML folosind atribute custom pe care le gasim doar pe desktop application for Windows 8, sau avem un CSS cu style care se gaseste doar pe Windows 8 atunci noi deja folosim WinRT API, iar partea de compatibilitate este total pierduta.
Pentru partea de compatibilitate ar exista cateva solutii. De exemplu sa ne definim un wrapper peste API care foloseste aceste resurse si in functie de unde ruleaza pagina noastra sa incarcam diferite JavaScript-uri.
Dar cel mai important lucru care trebuie luat in vedere este faptul ca HTML 5 pe Windows 8 nu este WEB PROGRAMMING. Laurent Bugnion a spun un lucru destul de frumos, care este 100%, adevarat, dar multa lume il ignora:

This is a standalone Windows 8 app that happens to be coded in a programming language that can also be used on the web.

Sursa: http://geekswithblogs.net/lbugnion/archive/2011/09/17/my-thoughts-about-build-windows-8-winrt-xaml-and-silverlight.aspx

Cea ce vrea sa spuna prin acest lucru este faptul ca cunostintele necesare pentru a scris o aplicatie pe Windows 8, folosind HTML5 sunt similare cu cele pe care trebuie sa le ai pentru a scris o aplicatie HTML5 pentru web. Dar exista lucruri diferite pe care userul trebuie sa stie, incepand de la starile pe care le poate avea aplicatia, la API pe care il poate folosi si la ce controale exista defaut pentru desktop application.
Acelasi lucru este si aplicatiile scrise in XAML pentru Windows 8. Acestea sunt destul de similare cu WPF/Silverlight. Exista lucruri comune la nivel de UI, dar o parte din ele sunt total diferite.
In concluzie, HTML 5 pentru desktop applications este similar cu HTML5 pentru web, dar totul se termina aici. Nu o sa vedem cat de curand ca funcționalitatile care exista pentru HTML5 sa apara in standardul HTML5 si nici nu vrem acest lucru. Sunt lucruri diferite, dar care se aseamana in unele privinte. Pentru dezvoltatorii care cunosc HTML5 sau HTML + CSS + JavaScript o sa le fie destul de usor sa faca tranzitia spre Windows 8 si scrie aplicatii native. Problema cea mai mare este pentru programatorii C#, care in momentul de fata sunt debusolati si nu stiu care e viitorul.

Change is good, change is normal. When you are not in the comfort zone you will grow and discover new things.

Comments

  1. Nu cred ca cineva s-a asteptat ca aplicatiile dezvoltate folosind HTML5+JS+WinRT sa fie cross-platform vreodata (asa cu mnici .NET-ul nu e, desi teoretic ar putea fi) - Microsoft nu are nici un interes sa dezvolte vreun framework cu adevarat cross-platform, nefacand profit din asta, ci din vanzarea Windows, Office etc.

    Cat despre programatorii C#/.NET, acestea au ramas first-class citizen cand vine vorba de aplicatii desktop pentru WintRT si Windows 8, deci no problems in directia asta - normal, nimic nu e vesnic, si la fel cum numarul aplicatiilor dezvoltate folosind COM/ActiveX/VB6 a scazut vertiginos dupa anul 2000, la fel si peste X ani va aparea altceva (mai bun sa speram).

    ReplyDelete
  2. Si tu in ce ai face o aplicatie desktop pentru win8? In html5 sau XAML?

    ReplyDelete
  3. Eu as face in sunt mai productiv, cat timp nu ma limiteaza - XAML+C#+WinRT in cazul asta. Daca as fi un web programmer care stie foarte bine JS/HTML/CSS si as vrea sa dezvolt o aplicatie pe un tablet pentru Win8, normal ca as folosi HTML5+JS+WinRT.

    Microsoft a mai incercat si pe vremuri sa atraga programatorii din alte directii pe platforma proprie, fie cu Visual J++, JScript.NET, dar de data asta ar putea sa reuseasca, in masura in care Win8 pe tablets/slates vor fi o reusita (spre deosebire de Windows Phone 7 care nu a atins cota de piata dorita din pacate).

    ReplyDelete
  4. Cat despre linkul la blogul lui Laurent Bugnion, are dreptate, dar "uita" sa mentioneze ceea ce multa lume a observat - ca in ultimii ani strategia MS in ce priveste developmentul pe Windows desktop a fost destul de inconsecventa si greu de inteles pentru cineva din exterior (cum explica foarte bine fostul manager de la Microsoft care se ocupa de Silverlight: http://www.riagenic.com/archives/363 ). E la fel ca si cand a aparut .NET-ul - multi develeperi au fost lasati cu ochii in soare si dezorienatati, dar cine a avut curajul sa riste si sa sara in noua barca, n-a avut decat de castigat in timp.

    ReplyDelete
  5. @Tudor

    Chiar daca Microsoft nu are niciun interes sa dezvolte cross-platform, exista exemple care arata in mod practic ca .NET Framework nu e doar pentru Windows:

    Q) http://xamarin.com/
    * http://blog.xamarin.com/2012/02/24/mwc_2012/
    * http://blog.xamarin.com/2012/03/21/vision-mobile/
    W) http://mono-project.com
    E) http://www.cellsdk.com/
    R) http://monogame.codeplex.com/
    T) http://unity3d.com/
    Y) http://www.mono-project.com/GtkSharp
    etc...

    ReplyDelete
    Replies
    1. @Anonim - da' stiu de Mono - nu l-as numi .NET - e o implementare in mare parte compatibila, un efort de admirat al unui mic grup de persoane, dar nici ei nu-l numesc ".NET for Linux". Da', proiectul e tolerat si "suportat" de Microsoft, suna promitator cat timp au fost sustinuti financiar de Novell, dar care i-a dat afara fara menajamente cand noul owner a vazut ca nu ii iese profit din asta, din pacate.

      O implementare compatibila .NET pe Linux as numi-o cand orice firma care dezvolta o aplicatie ASP.NET complexa nu si-ar pune problema efortului de a o hosta pe Linux sau pe Windows, la alegere si fara modificari in cod.

      Delete
  6. @Andrei - "Si tu in ce ai face o aplicatie desktop pentru win8? In html5 sau XAML?"
    Depinde de echipa cu care urmeaza sa lucrez si care ar fi zona de confort pentru toata lumea. Eu personal in momentul de fata ma simt mai bine in C# decat in JavaScript, dar cu putin studiu se poate aprofunda si JavaScript-ul. Lucrurile o sa schimbe, chiar daca noi vrem sa nu, iar limbajul in care lucram este doar o unealta.

    ReplyDelete
  7. HTML5 ,MARI probleme in win8 nush la alti dar mie in unele aplicatii din windows store gen vimeo si altele ce contin videoclipuri imi dau eroare… merg 10 min asa si dupa aceea imi apare de parca as avea prb cu plaka video.... patratele dungi in tot felu de culori si nu mai am ce face decat restart .

    ReplyDelete
    Replies
    1. Problema poate sa fie de la driveri. La W8 inca se lucreaza, abia in toamna o sa fie lansarea la versiunea finala. Eu nu am avut nici o problema de genul acesta, in cazul tau s-ar putea sa fie probleme de la driveri care nu sunt compatibili 100%.
      Sa speram ca pana in toamna se rezolva problema.

      Delete

Post a Comment

Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…