Mark Everard

Hello, I'm Mark – a PhD physicist turned technologist / architect.

Archive for the ‘iOS’ Category

Will HTML5 deliver the mobile app-ocalypse?

without comments

Despite the continued success of Apples’ App Store and similar online application stores, publishers are beginning to invest and deliver mobile applications using technologies that many believe may signal the demise of the traditional native app. Is it time to take shelter from an impending mobile app-ocalypse?

With the current popularity of the App Store (over 25 billion downloads) it might not seem like it. However the phenomenal success of the native app market presents a number of problems for both users and publishers alike.

Will HTML5 deliver the mobile app-ocalypse?

The App Store is noisy

There are now over 500,000 apps available on the App Store meaning that finding the latest and greatest is difficult. This can lead to a unhealthy reliance on curated lists and editorially featured content as a means to reliably discover new apps.

As a publisher, this increases the risk that your beautifully created app can sink without trace, no matter how great it really is. This increased competition in the market place also brings out the more nefarious means of grabbing attention. Those user reviews and 5-star ratings are worth real money!

Mobile home screens are overcrowded

Once you’ve found and downloaded the app you want, it has to compete with all of the other apps you’ve downloaded for prime real estate on your device’s home screen. The desktop paradigm that most devices have adopted just doesn’t scale to hundreds of apps. The cost of having to organise, rearrange, update and de-clutter your home screen becomes significant compared to the individual value offered by many of the apps.

Developing for multiple platforms is expensive

Which platforms should you launch your app on? How many versions built on different platforms can your development teams support? Should you try and develop features in parallel across platforms or should you let your feature set diverge and add new features to one platform first? All difficult decisions. It’s pretty clear why there is an imperative to develop with cross-platform mobile frameworks.

Is HTML5 the answer?

No, not in isolation. HTML5 is often misunderstood. It provides an open standards way of marking up data for display as  user interfaces, content and rich media. So the real question is will web apps using HTML5 become the dominant way of delivering mobile functionality? The answer as always lies in the context. If you need to interact with the device hardware then a native app is still the best way to achieve this. If you need to present content, text, images and media then HTML5 and a web app allows you to do this in a cost effective and time-tested way.

There is a third way. Many publishers are now pushing a hybrid approach and realising significant cost savings across mobile channels by building native apps which use HTML5 to deliver user interfaces that are imperceivably different to those offered by native code. Take for example, the latest LinkedIn IPad app which to many commentator’s surprise delivers 95% of it’s views using HTML5 (and of course a hefty dose of JavaScript and server-side data services).


Native apps won’t disappear but clearly there is convergence between the experiences native apps can deliver and those available via a browser.

Perhaps though it’s the app delivery mechanism that will change most of all. Rather than investing time up-front collecting apps from a store (with a vastly improved app discovery mechanism), perhaps apps will be downloaded only if and when you need them. This is the exact model suggested by ex-Apple and Google mobile UX guru Scott Jenson who suggests that future apps will be delivered ‘just-in-time’, installing only the features you need there and then. The underlying technology for such delivery is already available. It’s the web!

Here for the long run

Ultimately, reports on the death of native mobile apps have been greatly exaggerated, but HTML5 shows every sign of becoming the dominant cross-platform technology for serving rich interfaces, media and content.

Every future device of note will have a standards compliant browser, meaning that every device will be capable of consuming content and services delivered in HTML. As a publisher or developer it would be foolish to ignore this. As a user, hopefully you won’t even notice the difference…..

Written by mark

May 16th, 2012 at 4:02 pm

Posted in iOS,Mobile,Opinion

Serving videos to iOS devices from EPiServer VPP folders

with 9 comments

We recently launched an EPiServer site that made moderate, but high-profile usage of video and was also designed to be iOS device friendly – meaning no Flash and Html5 used to display video. Late on in development / integration we came across an issue where the mp4 / m4v videos file that were being served from an EPiServer VPP folder did not play when viewed on an iOS device. A little investigation found that the video files would play correctly when served natively from a static / non-content managed location.

(Note: If you’re serving a large amount of media content, then you’d be better off looking at a full media hosting solution rather than just serving from the EPiServer VPP).


Obviously the files were identical, so the only difference was in how IIS was serving them. Below are the Http responses (captured using FireBug) for the identical .m4v video files, one served from a VPP, and one from a native path.

The significant difference is the Accept-Ranges : bytes header. Cool – so we can just add in this header to our response and we’re sorted right? WRONG I’m afraid!

HTTP/1.1 Accept-Ranges header field

The Accept-Ranges response-header field allows the server to indicate its acceptance of range requests for a resource. This means that the server is open to partial downloads of files, and that clients (web-browsers) can download a limited ‘chunk’ of a file by requesting a specific byte-range, for-example bytes 5001-9999.

Going back to our original issue of why the files didn’t play on an iOS device, a quick look on the Apple developer notes (via StackOverflow) confirms that the web server needs to be configured to correctly handle byte-range requests. This explains why our file doesn’t work on an iOS device when served from an EPiServer VPP.


Our site was running using IIS7.5 in integrated pipeline mode, meaning that pretty much the whole Request / Response pipeline is handled by ASP.NET modules. Looking in the EPiServer site web.config you can see that the location path elements for VPP paths (Global /PageFiles etc) contain the HttpHandlers that are responsible for serving VPP filess. This is a bespoke EPiServer file handler implementation (EPiServer.Web.StaticFileHandler), which unlike the default IIS7 StaticFileHandler does not support Range-Requests 🙁

The Solution

Now you didn’t think that I’d explain all of this, without heroically coming up with a solution did you? Well I am providing a solution, but its hardly heroic as most of the hard work was done many years ago by Scott Mitchell – see Range-Specific Requests in ASP.NET. In his post Scott explains and provides an example of how to roll a HttpHandler with support for range-specific HTTP requests.

I’ve inherited from the RangeRequestHandlerBase class that Scott posted in the above article, and overidden a few methods adding in some EPiServer specifics, such as mapping the request path to the physical VPP file path and also using the EPiServer.Web.MimeMapping class to handle mapping from an extension to a mime type.

    public class RangeRequestFileHandler : RangeRequestHandlerBase
        /// Returns a FileInfo object from the mapped VirtualPathProviderFile
        /// <param name="context" />
        public override FileInfo GetRequestedFileInfo(HttpContext context)
            UnifiedFile file = GetFileInfoFromVirtualPathProvider(context);

            if (file == null)
                return null;

            return new FileInfo(file.LocalPath);

        private static UnifiedFile GetFileInfoFromVirtualPathProvider(HttpContext context)
            return GenericHostingEnvironment.VirtualPathProvider.GetFile(context.Request.FilePath) as UnifiedFile;

        /// Returns the MIME type from the mapped VirtualPathProviderFile
        /// <param name="context" />
        public override string GetRequestedFileMimeType(HttpContext context)
            UnifiedFile file = GetFileInfoFromVirtualPathProvider(context);
            return MimeMapping.GetMimeMapping(file.Name);

        /// Prevents episerver rewrite on outgoing stream.
        private void PreventRewriteOnOutgoingStream()
            if (UrlRewriteProvider.Module != null)
                UrlRewriteProvider.Module.FURLRewriteResponse = false;

This handler can be used to serve files from your VPP folders by adding the following configuration (IIS7 only folks – which if you’re not using then you really should be pushing for an upgrade!). This handler listed below is set up only to serve files of type .m4v – and remember that it does not provide any of the native EPiServer functionality for setting the staticFile cache expiration time.

<location path="Global">
              <add name="webresources" path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader"/>
              <add name="videofiles" path="*.m4v" verb="*" type="FortuneCookie.RangeRequestFileHandler.RangeRequestFileHandler, FortuneCookie.RangeRequestFileHandler"/>
              <add name="wildcard" path="*" verb="*" type="EPiServer.Web.StaticFileHandler, EPiServer"/>
      <staticFile expirationTime="-1.0:0:0"/>

The full source code can be downloaded from the Code section at EPiServer World and a NuGet package is available that will auto-magically add in the code and configure your Global and PageFile VPP’s to serve .mp4, .m4v and .mov video files using the RangeRequestFileHandler.

Written by mark

July 5th, 2011 at 10:00 am