Web-apps vs Native-apps

There is a world, a nerdy world occupied by people living in a private bubble called "IT". In this world "new" things are created, things that "ordinary" people couldn't care less about until they are publicized and popularized. Things like Facebook, Twitter, the iPad, gMail, the AppStore and the Internet are things created by the people in this nerdy world. Right now an imagined war is raging in this world, a war between the "by god we will cram everything into a browser" people and the "browsers are cool but slow" people. I'm of course talking about web-apps vs native-apps, or Google vs Apple as some have come to believe. So, is there a war? And who's winning?

When contemplating the differences inherently present in the not so wide crevasse between web-apps and native apps there are four main areas I want to examine:

1. Performance
2. Accessibility
3. Data persistence and security
4. The browser

Performance

The first thing that springs to mind when taking the classical approach to this age long tiresome debate is the issue of performance. Native apps perform better than web-apps, hence the end user gets a smoother and better experience when using the app. This is true, in most cases. However, performance is more than just the smoothness of animations and the speed of which data is read. Consider the process of installing Adobe Photoshop on your trusty Windows laptop, then activating it, then figuring out how to navigate the god awful interface just to adjust the contrast of an image. Compare that workflow to opening the image with Picnik and the choice is pretty clear. Web-apps rule! But, wait. What if you want to edit the movie you shot during the holiday with your FlipMino HD, can you do that in a web-app? Well, sort of, with services like JayCut and the likes. However, you will get a much better result using iMovie, which is already on you Mac. What about Skype, code compiling, 3D games and so on..? To make a long story short, native apps will outperform web-apps when it comes to pure performance and as long as web-apps are based on a document oriented language (HTML). It will always be a catchup game for web-apps. But, web-apps have another kind of performance advantage, accessibility.

Accessibility

A web-app is always up to date, most of them are easy to use, requires no installation and can be used from almost any computer. That is, except when you're not connected to a network. A statement with modifications indeed, some web-apps do work when in offline mode as well, however a pure offline web-app would be pretty pointless. Consider Google Docs versus Microsoft Office. If you're an author (a brave one) you might want to use MS Word, or if you need some crazy ass pivot tables or other super advanced stuff you would perhaps also need MS Excel. However if you just want to calculate stuff, create and produce formatted text, spreadsheets and presentations, Google Docs is far superior to MS Office. Oh, have you tried to collaborate in real time on a MS Word document, doesn't work does it?! Also, Google Docs keeps your documents on the server so you can access them from anywhere and they are always backed up. Does it work offline, well, not yet.

Data persistence and security

With a native-app your data is always available to you, online or offline, provided that your computer is with you of course, or that you have synced the data to the cloud. What happens if (God forbid) your house (containing your laptop) is leveled by aliens? Where did all your native-app data go? It's history! Your e-mail and Google Docs data is safe at Google. That is, if you are okay with Google searching through your e-mails and documents in order to give you targeted advertisements? And what happens if, say you have saved all your links and bookmarks at a cloud service (lets call it Delicious) and then out of the blue Yahoo! suddenly decides to fire all the people working at that service and let it die a slow death. What about all those years worth of bookmarks then? This is somewhat complicated isn't it?

The browser

How awesome do you think it would be to play Halo: Reach in Google Chrome? Not so much? What about programming a movie-editor that has to work within the browser sandbox and is only allowed to cache 10MB of data, how would that go down you think? It wouldn't you say? Last one: Let's say we want to persuade ReSpawn Studios or Epic Games to work with WebGL on an unknown amount of browsers and computers instead of writing their engines based directly on a familiar platform. No dice? This is because the browser isn't a gaming platform, it isn't a good platform for handling a lots of files or large files. But, it does add another layer of security and it make everything accessible everywhere, plus if you're using Facebook and gMail what more do you need.. The average time a user spends in a web-page is about 10 seconds, this makes the "browser experience" kinda ..volatile..and short lived. Native app sessions are more persistent and have a longer lifespan, hence more suitable for playing games, editing movies and so on. The browser can do many things, not everything and yes, native apps will continue to be perform better for some time.

There is no war. The browser with it's web-apps is an awesome platform for some things, just as native apps do better on other things. I for one enjoy both web-apps and native-apps and will continue to do so for a long time I suspect.

Scrolling a div on multitouch devices using JavaScript

With the emergence of touch devices and the slow but steady tendency of replacing the mouse as an input device, this leaves us with fingers. Both the iOS platform and the Android platform sports APIs for dealing with touches from fingers, for native apps that is. But what about web-apps? Enter the JavaScript touch DOM events. In this post I'll discuss how to use the touch events to scroll a container (a div) using a finger, e.g. on an iPhone.

What you'll need
First of all you need a touch device or a simulator like the iPhone simulator to test your code. The code itself can be written in any text editor, however it is recommended to use an editor with a build in debugger or a test environment that supports debugging JavaScript touch events. You might be thinking that Firebug or Drosera is great for debugging, but how exactly would you trigger the touch events in your desktop browser? Well, you can't. This is why I'm using Dashcode from the iOS SDK for my JavaScript coding. More on using Dashcode in a later post.
Note that this code is written for WebKit based browsers, but should work in principle on other touch browsers as well.

The HTML

<div id="holder">
   <div class="content">
       your content here
   </div>
</div>


Notice that the content is inside of a div within the holder div, this is because you can't scroll the div in which the touch event is attached to.

The CSS

#holder{
   width: 300px;
   height: 200px;
   background-color: blue;
   -webkit-box-shadow: 3px 3px 5px #000;
   padding: 10px;
}

#holder div{
    width:100%;
    height:100%;
    color: white;
    overflow: auto;
    -webkit-user-select: none;
}

Not much revolutionary here, but do note that we set the "overflow" property to auto on the content div, not the holder itself. Also, we set the "-webkit-user-select" to "none" on the content div, thereby preventing the user of selecting the content. This is optional.

The JavaScript
There are three main touch events:

• touchstart - Called when a finger touches the listening container (finger down)
• touchmove - Called repeatedly when a finger moves (finger down and moving)
• touchend - Called when a finger leaves the listening container (finger up)

Each of these methods gives us an event with a touches array. Remember, there might be more than one finger since these APIs are made to handle multitouch devices. To get a hold of the vertical position of one finger you would query the touches array for one finger and get it's pageY property, like this: event.touches[0].pageY

From this we can calculate and set the scrollTop property of the content container. But, wait! If you try this the rest of the page will also scroll, not what we wanted. The reason why this happens is because the touch event bubbles all the way up to the window, making the browser think it needs to scroll the window because you have dragged your finger on it. We need to tell the event to stop bubbling, we will handle the event ourselves. We do this by calling: event.preventDefault()

The complete JavaScript code will then look something like this:

var startPos;
function init()
{
    var scrollArea = document.getElementById('holder');
    scrollArea.addEventListener('touchstart', function(event){
        touchstartHandler(event);
    }, false);

    scrollArea.addEventListener('touchmove', function(event){
        touchmoveHandler(event);
    }, false);

    scrollArea.addEventListener('touchend', function(event){
        touchendHandler(event);
    }, false);
}

function touchstartHandler(e)
{
    startPos = e.touches[0].pageY;
}

function touchmoveHandler(e)
{
    var touch = e.touches[0];
    var targetBox = e.currentTarget.getElementsByTagName("div")[0];
    e.preventDefault();

    var fingerMoved = startPos - touch.pageY;
    startPos = touch.pageY;

   targetBox.scrollTop = targetBox.scrollTop + fingerMoved;

}
This is just a simple example, but it's something you'll probably end up using a lot. Speaking of...

When should you override the default window scroll
On an iPhone there is not as much need for this method as you'll probably scroll the entire screen in most cases anyway. However, the iPad is a different story. Take a look at the iPad version of gMail created by Google. They are using this method with success, and they have added inertia scrolling as well. This can be accomplished using the last touch event we did not implement, touchend. Maybe more on this in a later post. Anyway, you should use you own scrolling when it's appropriate to scroll only a part of the app, like a spilt view list or something like that.

Downscaling images in Flash applications

The other day I ended up in an interesting discussion regarding how to downscale a large image in a Flash based application. What we figured out was that even though the FlashPlayer can do bilinear smoothing on scaled images automatically, this will fail when the scaling factor is more than 2 times of the source image. Hence a custom method is needed.

The simple approach (scaling down less than 2 times the size)
If the loaded image is to be scaled less than 2 times (400 -> 200) simply use the build in "smoothing" property of the Bitmap Class. This can be set directly on the Bitmap itself or via different DisplayElements such as the mx:Image in Flex. If you set this property to true the Bitmap will use bilinear scaling, achieving quite good results.

Grayscale bilinear interpolation

Now, if you need to do actual resampling of an image, in other words create a new smaller image, then you need to do this manually using the "draw()" method of the BitmapData Class. Use the bitmapData.draw() method and set the "smoothing" property to true. This will give you the same result as setting the smoothing property on an Bitmap container, however it uses less memory as only the pixels for the resulting image is stored (if you remember to dispose of the original data!).

Scaling down more than 2 times
Let's say that you have an image that is quite large and you want to create a thumbnail from it. A thumbnail is often way smaller than 2 times smaller than the original image. It would be quite nice to use the above method to just scale the image, or better resample the image with the "smoothing" property set to true. However, if you try to do this the FlashPlayer will simply fail and default back to using the "nearest neighbor" algorithm. If you try it you'll soon discover that this will give you a horrible result.

What you'll need to do in this case is to do an iterative or recursive resampling of the image at hand. In layman terms this means resampling the image several times, each time no more than 2 times downscaling factor. You could call this a multi pass resampler (actually it would be a multi-multi pass resampling as the draw() method is also multi pass). You would still use the build in "BitmapData.draw()" method to accomplish this, you only divide the work into multiple jobs. This will give you a much better result. Note that in my experience, function calls in ActionsScript 3 are quite expensive, hence a iterative approach would maybe be preferable to a recursive one.

Using PixelBender
If you have decided to go for the manual approach of resampling the picture, you can use a PixelBender shader to do the job. In this case the actual resampling will be a lot faster (as the PB language is based on C), however applying the PB shader and passing the image back and forth takes time. See the speed section..

Combining the two
So, what if you have an application and you don't know in advance the downscale factor. Well, then you'll need to use both of the approaches like so:

1. Calculate the scale factor
2. If the scale factor is less than 2, set "smoothing" to true on the container or do a singe pass resampling.
3. If the scale factor is more than two, use the multi pass scaling approach. And set the "smoothing" property of the container to false (else it will be blurry).

What about speed?

Let's say that you have an image that is 1200 x 1200 pixels and you're resampling it to 200 x 200. This is a 6 times resample and will look like ass using only the "smoothing" property, but it is faster.

Let look at some hard results. In this test we see how much time is used extra compared to no "nearest neighbor" scaling (default in Bitmaps if smoothing is off).

Method	Time in ms
Smoothing property on	0 ms
Multi pass resample	9 ms
Multi pass PixelBender	32 ms

Using the smoothing property takes no extra time, because it fails and defaults back to nearest neighbor. The other two are both pretty fast, however even though the PB algorithm is way faster than the others, we see that the applying of the shader eats a lot of time, thereby making the multi pass resampler method the way to go on a large rescaling operation.

Shifting the attention - facing forward.

“Innovation is the ability to see change as an opportunity - not a threat”. - Unknown

This is not where I'm going to announce to the world that I'm leaving the FlashPlayer platform behind all together. Nor is this where I'll tell you to forget everything you know, gather you wits about you and start over. No, this is where I'll tell you what I've learned, how I've learned this and why this is.

Like Borland Delphi back in the days, the Adobe FlashPlayer architecture is dying without itself being aware of it. It's not because Flash content is evil, nor because the FlashPlayer is particularity crappy. Still, many sites, like YouTube are heavily dependent on the FlashPlayer in order to display their content. This will be true for quite some time. However, at the same time, all these sites still depending on the FlashPlayer do not express enthusiasm for it, it's seen more as a necessary evil in order to get the job done while we are waiting for something better. Well, change has come to the interwebs..and it's called HTML 5.

HTML 5 is acctually a standard being developed by the World Wide Web Consortium. Like HTML 4 it's a specification used by browser vendors to integrate the support into their browsers. This by it self means that  individual browser vendors are responsible for the performance of HTML content in their browsers, effectively launching a race to be the fastest browser. This is a win for HTML 5 over Flash, seeing as Flash Player has no real competitors, because Adobe is the sole vendor. However, HTML 5 and it's companions CSS 3 and JavaScript cannot accomplish the same as the content you create using Adobe Flash, or so many people think. Actually, it can. Both 2D animations, 3D animations, advanced text layout and so on is readily available using HTML 5. So is advanced interactions. What HTML 5 does not have, that Flash do have, is an advanced authoring tool. Using HTML 5 may require more development skills, longer production time and more work to achieve the same result as using Flash authoring, today. This will change in time as HTML 5 skills grow more common amongst web-developers and the marked for great tools enlarges.

“Innovation distinguishes between a leader and a follower.” - Steve Jobs

Let's not forget the devices. The iPad, the iPhone, Android devices and the Google Chrome OS. These are the platforms of the future, the PC is not. Yeah, PCs will still be around, we as developers will still adhere like superglue to our Macs and Chrome computers. But, the normal users, aka. "most people" will not. Flash belongs to the PC era, HTML 5 is build for the touchscreen generation. This is kinda hard to see if you don't look closely, but think about it. How many iPads and iPhones does Apple sell? A lot! How many Android devices are there? A lot! Granted, Android phones do have a FlashPlayer, but have you tried it? Yes, it really sucks. And that is the most devastating blow to the FlashPlayer, the experience on future devices sucks or it simply isn't supported like on iOS devices.

Change is one of the most difficult things for humans to endure. We don't play well with it at all, but sometimes it's for the better. Remember, there is nothing wrong with plugin based technologies like FlashPlayer or Silverlight, like there was nothing wrong with the horse and carriage. But, now we drive cars, even if they can't do everything horses can do. This does not, however, mean that we hate horses, does it?

Resulting from my contemplation is an understanding that my attention will focus on the utilization of standard based technologies in the foreseeable future. I believe HTML 5 and all its companions will be the way of future web-based solutions. Flash is not dead, will perhaps never die, but if you're starting out today as a greenhorn developer, go for the future. And if you are a seasoned web-developer like myself, embrace this opportunity to learn new things, to start from "scratch".

Some great HTML 5 demos can be found here:

• Safari demos from Apple
• HTML 5 Demo
• YouTube HTML 5 version
• HTML 5 Presentation

Do we need Flash anyway? Apple says hell no!

Unless you have been living in a box for the last couple of months or so, you're probably noticed that there's somewhat of a controversy dealing in the subject of Adobe Flash and Apple Inc.'s not so new policy to not support this widely used content type in their mobile devices.
In short, Apple cry fault on several things like CPU usage and instability, using these as the foundation for it's "no Flash content on our devices" policy. But, is it really that simple? Here's my take on this soon to be "greek tragedy".


What is Flash?
First of all, Flash is a type of media content, like images, movies and so on. Flash by itself doesn't do diddly-squat, it's just a description and a file format. In order to view Flash content you'll need an interpreter, in others words a player. What Apple is calling "the great evil" is (hopefully) the Adobe FlashPlayer, not the content type which is actually Flash.


Is Flash crashing my browser?
No! As described above, Flash all by itself can't do anything. If anything related to Flash is crashing your browser, it is the Adobe FlashPlayer. So you may ask, is the FlashPlayer the reason (most of the time) my browser is suddenly crashing? In my opinion it probably is. The Adobe FlashPlayer is quite unstable and buggy and slow. Why? Read on..


Is the FlashPlayer a "CPU hog"?
Yes it is. The Adobe FlashPlayer runs a constant loop of so called frames, driving animation, UI and so on. This will create a constant load on the CPU, because the content can change without reloading the webpage holding the Flash content. In contrast, HTML will create a heavy CPU load when initially loading the content and then it becomes static, thereby not using any (almost) CPU cycles. So, what if you where able to create the same content as you can show in the FlashPlayer in say.. HTML and JavaScript. What do you think would happen to the CPU load of that HTML page then? Of course, it would use more CPU cycles.
So, Adobes FlashPlayer is slow, no doubt about it, but this does not make Flash itself a "CPU hog" or anything like that. If Apple wants a faster FlashPlayer.. write one!

Will Flash die, what might prevent it?
Flash will die, or evolve into something else, eventually. But, it won't happen tomorrow, or the next day. Event though Apple does not support Flash in the iPhone and the iPad, almost any other device does or will support it. However, if you're a smart developer you'll use this time to widen your skill set beyond the Flash platform.

Development time and cost
The time spend creating an online application or website will in many cases be the deciding factor in a project, unless you're Google or Apple that is. Using the Flash platform compared to JavaScript/HTML solutions leaves the latter far behind in the dust when it breaks down to actual production time. This factor will no doubt change with the advent of advanced frameworks like JQuery and SproutCore. But still, anything you can do in JS and HTML, Flash can do better and faster from an time and design standpoint... today.

Dropping legacy support is the way of making a more stable player
One of the biggest problems with the Adobe FlashPlayer as I see it, is it's reluctance to get rid of old and bad ways of creating content. If Adobe where to drop support for the old player model, supporting ActionScript 2 and Flash 8 and older, I'll bet money that Flash content around the web would run faster, smoother and crash way less. If they are willing to do this I do believe Flash content might have a future, if not it will be kept alive by the need for banner ads, for a while.

Why doesn't Apple support Flash content?
Well, Steve Jobs allegedly stated that Apple wasn't supporting Flash content on the iPhone and the iPad for reasons dealing in instability, performance and generally bad user experience. If that's all, why not support Microsoft Silverlight?
Flash could be a competitor for Apple, both in the apps section of their business model and in the media consumption part (buying videos from the web (e.g. Hulu) and not the iTunes Store).
This is why, in my opinion, Apple will not support Flash content on their mobile devices. And really, if you think of it, is is such a problem? If you depend on Flash driven web content, don't buy Apple hardware. For me, being both an Apple "fan" and a Flash developer, I don't see the need for Flash content on mobile devices. No matter how you word it, the iPhone and the iPad won't give you the entire web..

Screencast # 3 - iPhone web app Twitter viewer

In this Screencast I create a really simple iPhone Web Application using DashCode, one of the tools provided trough the iPhone Developer Tools.
I'll show you how to create a simple Twitter viewer, getting started using lists and how to use value transformers in DashCode.



Download DashCode Project

Screencast # 2 - Scrolling HBox without scrollbars (Flex 3)

In this screencast we'll be looking at how to scroll an HBox in Flex 3, without having the scrollbars present. I'll also show you how to get a nice animation effect when doing the scrolling.
Source code below the video.



Download source

Screencast # 1 - Filtering ArrayCollections

In this first screencast I take look at loading XML data into an ArrayCollection, avoiding some common pitfalls and then doing live filtering on the data shown in an DataGrid.
Note that this is my first sceencast and my native language is not english, so this is just me getting my feet wet so to speak.
Source code below the video.



Download source