Category Archives: Browsers

UK Future Decoded Event Video: Martin Beeby on Visual Studio & Apache Cordova

Posted on by

Microsoft UK recently ran the UK Future Decoded Event where I was the owner of a half-day track of sessions on Visual Studio for Cross Platform Applications. I described that track as;

There’s a tension between an app developer who wants to get the most from their investment in skills and tools and a device/platform vendor who wants to make sure that apps are really shiny on their devices.

What’s a dev to do? Build native for iOS/Android/Windows and take the hit on multiple code-bases? Go lowest, common denominator and build hybrid? Or…is there another way? Join us for an afternoon of getting bang up to date on how Visual Studio works with Xamarin and Cordova to get your code across as many devices as possible without compromising the user or developer experience.

The last session of the day was my colleague Martin Beeby. Martin delivered a great session entitled “Visual Studio & Apache Cordova: Hybrid Apps on All Devices” and the video is now available for you to watch below;

Enjoy!

SteveB at the Microsoft Developer Forum, Japan

Posted on by

Just a link to some interesting things that SteveB talked about at the recent developer forum in Japan;

I can’t find an online video of the session yet but the transcript is up here and has some interesting pointers around a few future areas.

Please note that I’m not attempting to add commentary or interpretation here, I’m just quoting the public press release and suggesting that it’s very worth reading.

Here’s some snippets – firstly around HTML and JavaScript;

“The third area that I think will be increasingly important is HTML and JavaScript. We've made a big investment, obviously, in Windows and IE9 in our HTML and JavaScript support, but more and more of the world's programmers will be fluent in these technologies in addition to whatever skills people have in C++ and C# and a variety of other important skills. But we have to recognize that more and more of the world's talent will know these techniques. And whether it's writing a website or a client application, or a server application, we want to build and develop the range of things that you can do not only using .NET, but also in using HTML and JavaScript. And, in fact, even how you can weave these things together into sensible programs in the future.”

and then around the move to ARM;

“Just think back three or four years ago and how quickly performance and size, and miniaturization and the move to ARM processors has happened. We've announced with Windows that we're going to support system-on-a-chip "architectures, not only from Intel and AMD, but also from a set of ARM vendors.”

and around Visual Studio;

“Today you write a program and as you're writing it you have to say, what computing resources does it use, how much of it runs on a client device? How much of it runs in the server? How is my server going to get set up and provisioned? How is my application going to get deployed? How do I deploy it in a redundant fashion, to have good business continuity, in the event of the kind of natural disaster that we saw here in Japan? As we are rebuilding Visual Studio, .NET, Windows Azure, we essentially are designing around the automation of program development and deployment, and the operation of those activities.”

and then around Windows;

“We're obviously hard at work on the next version of Windows. Windows 7 PCs will sell over 350 million units this year. We've done a lot in Windows 7 to improve customer satisfaction. We have a brand new user interface. We've added touch, and ink, and speech. And yet, as we look forward to the next generation of Windows systems, which will come out next year, there's a whole lot more coming. As we progress through the year, you ought to expect to hear a lot about Windows 8. Windows 8 slates, tablets, PCs, a variety of different form factors.

The browser is an area where we've been very active. Internet Explorer 9 is the fastest browser around because of the way that we've married it to Windows systems and allow essentially full exploitation of the hardware to have the fastest and most beautiful Web on the planet run on Windows systems.

We've integrated the browser into Windows more fully, so that you can put jumplists, and pin those to the taskbar on Windows. We've improved JavaScript performance. We're running on downloads that are about five times the rate of customer acceptance that we saw on IE8. and when it comes to HTML and JavaScript, and the browser, there will be simply no one who pushes that, not Google, not Firefox, nobody will push that faster and harder than we push with IE.”

and finally around developers Smile

“The relationship with developers is the most fundamental relationship between Microsoft and its customers. You're it. You write the programs, the applications that really turn on all of our customers to the power of information technology, whether you're writing for the phone or the Xbox, the PC, or the tablet, your work is the work of our industry. And our No. 1 goal in life is to support the developers, developers, developers here in Japan and across the world.”

Very interesting stuff – I’ll link to the video as/when I find it.

How Native is Native?

Posted on by

Just a fairly obvious thought that’s been kicking around in the empty space between my ears for a few weeks now. It really came to the fore when I was casting my eyes over HP’s webOS developer platform. I didn’t read so much of it but I did read (from here);

“You can think of webOS applications as native applications, but built from the same standard HTML, CSS and JavaScript that you'd use to develop web applications. Palm has extended the standard web development environment through a JavaScript framework that gives "standardized UI widgets, and access to selected device hardware and services.”

and I thought this was “interesting” in that a lot of folks have started conversations with me along the lines of;

“Is the answer native or HTML?”

and I think that the terminology is wrong.

I don’t think the choice is between “native” and “HTML”, I think the choice is between;

  • Standardised clients – I think I’d call this the “Standards API Client” or SAC.
  • Proprietary clients – I think I’d call this the “Proprietary API Client” or PAC.

and so you can write your client using HTML today, CSS, JavaScript and you have the opportunity of that client working pretty well in a browser on pretty much every platform out there although you’d perhaps end up writing different clients for different form factor devices.

If you’re feeling more progressive, you can target HTML5 and CSS3 and achieve the same effect with more functionality available to you albeit with potentially less browser support today across all devices as HTML5 hasn’t yet reached the point where it’s ubiquitous. Naturally, that’s a matter of time.

You build a standards API client. A SAC. You accept that the UI layer, API layer and language are owned by a standards body/process and that works for the application you’re building.

But, as in the webOS case, it’s pretty easy for a vendor to take that same set of implementation technologies and surface up proprietary APIs through JavaScript – anyone that’s hosted the WebBrowser control in .NET would know that you can provide an object for scripting whereby you could open up a channel to communicate from JavaScript through to the .NET framework and beyond into the native platform. It’s even more flexible if you were starting from unmanaged code and hosting the WebBrowser from that kind of environment.

So, it wouldn’t be “rocket science” to write a hosting environment that loaded up HTML and JavaScript and offered additional functionality to it either from the environment itself (like a browser does) or from the underlying OS.

Whether you’d ever do that from a web browser is a different question. The browser’s sandboxed so that’d need an awful lot of care and attention – you can’t suddenly surface underlying platform APIs to browser code but browser vendors do it in ways such as;

both of which are examples of in-browser exposure of proprietary APIs called from what would otherwise be a standards-based client.

Clearly, there are cases where you might be able to be a mixture of SAC and PAC. You might do a standards based client for 95% of your work but you might then just drop into some of that proprietary stuff on a per-browser or per-platform basis.

There’s also the question about which standards come into play – standards from whom and at what status?

Ultimately, though, I don’t think it’s about “HTML versus native” – I think it’s more a choice of whether you build a standards based client or a proprietary based client or, as is frequently the case today, both.

SACs versus PACs Winking smile