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(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP