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

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

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.51 EF 6.0.2 VS2013 It see

Navigating Cloud Strategy after Azure Central US Region Outage

 Looking back, July 19, 2024, was challenging for customers using Microsoft Azure or Windows machines. Two major outages affected customers using CrowdStrike Falcon or Microsoft Azure computation resources in the Central US. These two outages affected many people and put many businesses on pause for a few hours or even days. The overlap of these two issues was a nightmare for travellers. In addition to blue screens in the airport terminals, they could not get additional information from the airport website, airline personnel, or the support line because they were affected by the outage in the Central US region or the CrowdStrike outage.   But what happened in reality? A faulty CrowdStrike update affected Windows computers globally, from airports and healthcare to small businesses, affecting over 8.5m computers. Even if the Falson Sensor software defect was identified and a fix deployed shortly after, the recovery took longer. In parallel with CrowdStrike, Microsoft provided a too