We just announced that we will move Adobe MAX from the end of the year to spring. So the next Adobe MAX will be on May 4-8 in Los Angeles. I for one I am excited with this move and I can’t wait for Adobe MAX 2013. You can find more about this in Kevin Lynch’s post.

Another month, another Adobe WebUp (#5) has come :) (May 31st in our office). You should know this by now! For the first time there will be more external speakers than Adobe speakers – in total five sessions. If you live in Bucharest or close make sure you go here and register. Here are the five topics:

• Advanced CSS Layout Techniques – Dan Popa/Adobe
• Take your web apps offline with Application Cache – Ionut Margelatu/Adobe
• Introduction to HTML5 History API – Cosmin Nicula
• Common mistakes in Mobile Web Apps – David Emanuel Oprea
• From development to evolution – Andrei Epure

See you there on May 31st and if you want to be a speaker at one of the future events, drop me an email!

Register for the event here! Event hashtag #AdobeWebUp5 and Twitter @AdobeWebUp.

The web is moving forward. And it is so great to see this. I know it sounds a bit dramatic but this is exactly what happened before with two CSS proposals (CSS Regions and CSS Exclusions).

As a result of the past six months or so of work between Adobe and the other parties involved in the process the specs were updated this very month (May 2012) and new working drafts have been published.

If you want to read more about these proposals or to understand how the standardization process works read here.

We just launched the second release of Adobe Shadow. You can grab the bits from here.

If you haven’t already tried this tool and you build websites or web apps for mobile then you should definitely check this out. It will make your life so much easier.

What’s new in this release:

• Localhost URL support – now you can test localhost, 127.0.0.1, and machine.local (for Mac OS X) URLs instead of using the IP address of your desktop device
• Adobe Edge integration – the Preview command from Adobe Edge works with Adobe Shadow
• HTTP Authentication Support – you can navigate to URLs that require HTTP Authentication (you will see the login form on the mobile devices). It works also with URLs that contain the login information - http://login:password@mysite.com
• Support for the latest iPad (retina display)
• Support for working with sticky caches – you can perform a gesture on the mobile devices to force Shadow to load the latest resources (tap on the page, hold, and pull down until you see the “Release to refresh…” message)
• Amazon Kindle Fire version will be soon available for download in store
• URL Monitoring – if your website/web app uses # to change the state, now it will work with Shadow

If you want to stay updated with what’s happening with Shadow make sure you follow the team blog.

Now go and make sure you update your desktop app, Chrome extension, and iOS/Android clients. Enjoy!

Adobe WebUp #4 registration is open now! This means that you should not only register yourself and your girlfriend/friend/brothers&sisters but you should also tell others about this awesome event!

What? You don’t believe that it will be awesome? Trust me, I should know as I am the organizer:)

Now seriously, when I started to plan this series back in December 2011 one of the goals and success indicators that I set at the time was having people outside of Adobe speaking at our event. And this is exactly what is about to happen: two great programmers who don’t work for Adobe will be our first two speakers (thanks Cristian and Alexandru).

See you on April 26th. Until then all the best and Happy Easter!

Later Update: if you can’t attend the event and you still want to see what’s happening there (maybe you are from Republic of Moldova or Timisoara) you can watch the live streaming at

https://eseminars.adobeconnect.com/_a827192574/adobewebup (we will open the stream around 5:30PM)

My fellow evangelist Michaël Chaize was quite busy lately doing some strange alchemy experiments that involved high command of DPS, the art of charming people, UXD, and many more I am afraid to name.

And the result is even tastier than a French croissant in a Spring morning in the 18th arrondissement of Paris (which is Montmartre, if you didn’t know). Which shouldn’t come as a big surprise because although Michaël didn’t invent the croissant, he is very French.

What is Appliness? In a nutshell, Michaël used Adobe Digital Publishing Suite to create the first digital magazine for web application developers. It has lots of interesting topics (jQuery Mobile, PhoneGap, BackBone,…). You can download the magazine for your iPad or Android tablet (it is free by the way). If you want to contribute to this magazine go to http://appliness.com and if you want to learn more about the project read Michaël’s post.

Later Update: Just got an email from Michaël saying that my post is epic. I guess some of the “magique” did rub off on me :)

Last week, for three days, the Adobe Romanian office hosted a WebKit Hackathon. What’s all the fuss with this WebKit Hackathon you might wonder. Let me explain :D

First of all, why WebKit? I truly believe that you already know the answer. In case you don’t, here is a short anecdote: Dion Almaer (you know, the guy who started Ajaxian among many other things) once said something along these lines: if you are a student probably the best time investment you can make today is to grab the WebKit source code and start “playing” with it. There is no dennying that WebKit is one of the most used  browser engines today (I’m not talking about browser market share I’m talking about the number of different projects using this engine).

Let’s move on and talk about the hackathon. A hackathon gives developers a chance to learn or to teach about a specific technology. Because you have these two categories involved (people who want to learn new things and people who know these things and want to teach others) the energy level and enthusiasm is pretty much off the scale. This is why it is not unusual at the end of a hackathon to realize you’ve gotten more work done than what you had expected.

The last question you might have is why Adobe Romania? Because we have engineers who have been working on the WebKit codebase for the past 4-5 years. From their work prototypes of CSS Regions, CSS Exclusions, and CSS Shaders – to name just a few – emerged.

Thus, if you put these three ingredients together you get the first Romanian WebKit Hackathon. So what exactly happened there?

A number of Adobe WebKit engineers together with seven students worked on the WebKit codebase. It is interesting to note that the students didn’t have any prior experience with WebKit. The result was amazing. Some of their work was accepted by WebKit reviewers and it will be committed back to the WebKit trunk. Here are some examples of the work they did:

• Fixed elements that use rounded corners and background images so the image will be clipped.
• Enhanced the Web Inspector UI for visual manipulation of numerical data-types
• Created a prototype of CSS Regions that uses Shadow DOM
• Implemented overflow event on NamedFlow objects
• Added support for resize events for any DOM element

My colleagues are working on getting the demos out. I will update this post with the links once they are published. Until the next Adobe Romania WebKit Hackathon, all the best and, of course, congrats to all people involved in this event!

Recently, we released Adobe Edge preview 5.1 (you can grab the bits from here). Adobe Edge helps you to create interactive web sites and web animation using just HTML, CSS, and JavaScript. The tool does a really good job of being intuitive. Look at the image below:

You have the web page loaded on the canvas (Edge uses WebKit to render web pages), you have the timeline at the bottom, and on the right side you have a panel with all the HTML DOM elements from the current page. Here is a screenshot of an interactive design created with this tool:

I know there are some people who don’t trust visual tools that create web pages. But I encourage you to take a look at this tool and also give us feedback to make it better (Edge was downloaded by a large number of people, a clear sign that the tool answers a need many people have). If you are not able to visualize code like Neo,  a tool that helps you to code visually is simply awesome :)

There are many more things that the tool can do and as we move on towards the launch day more features will be added. If you want to check all the features that Edge supports, make sure you take a look at this page. If you prefer watching a video, here is the link. And if you want to see some cool sites created with Edge check this  link or this (if this isn’t enough check the Facebook page).

A simple example of a web animation

My fellow evangelist Kevin Hoyt created the Adobe logo using just CSS and DIV elements (that’s right, no letters). Once the Edge preview 5 was out I thought that this would be the perfect opportunity to play with the tool on some cool HTML code.

First, I saved Kevin’s example locally. Then I removed the JavaScript code (it was used for centering the logo and I didn’t need it for my example) and I inlined the CSS (this is not an Edge requirement; I did it only to contain everything in a single resource). With all these small tweaks I was ready to start my Edge animation: I opened the Edge tool, I chose Open File and selected the web page with the Adobe logo (this is one of the great things about Edge: it allows you to work directly on a web page).

Having the page loaded in Edge, it is time to create my simple animation. The timeline features two important parts: the playhead and the pin. Using these two tools you can either animate from the current state of the DOM to a future one, or you can animate towards the current state of the DOM.

For what I want to create I have to use the second scenario: I want to animate the individual parts of the logo from “nothing” to the finished logo. To do that I will enable the pin by clicking on the third icon from the Timeline panel (see the picture below). This will add to the timeline a little blue icon.

Adobe Edge allows you to control the easing equation for your animations. If you click the fourth icon from the Timeline panel you will be able to select the equation to be used.

Once I selected the easing equation I moved the pin to the right of the playhead. This means that I will create an animation towards the current state, which means that at the end of the animation the logo will look like the one created by Kevin.

Now I am ready to  be creative with the different parts of the logo. I can play with the position by dragging the DIV elements in different positions, rotate (right-click on an element and choose Add Key Frame > Rotate), and changing its opacity (right-click on the element and choose Add Key Frame > Opacity).

You can orchestrate the animations so instead of moving all elements with the same speed and at the same time you can choose to delay some of them (just select the elements on the timeline and drag to the right or left and/or compress the animation line when you want to accelerate  or slow an animation). You can insert key frames along an existing animation to fine tune the whole animation. In short, you have pretty much everything you’d expect from an animation tool.

When you are ready to publish your project, all you have to do is to select File > Publish Settings (you can choose to embed some of the JavaScript files from CDNs instead of your server; this way you might speed up the loading time) and then hit File > Publish. The last command will create a folder named publish in the same folder where your HTML file is stored (all the JS files being minified). All you have to do is to copy this folder to your server and you are done. Here is a screenshot with the project folder:

So what did Edge add to the original file (remember that we started with only one file containing HTML and CSS)? Basically it added just JavaScript files (Edge libraries plus jQuery libraries). All the information needed for the animations are stored in a JavaScript file that ends with _edge.js. Edge didn’t touch the original file other than including the pre-loader JavaScript file; if you open the HTML file you will see in the head section these lines:

<!--Adobe Edge Runtime-->
 <script type="text/javascript" charset="utf-8" src="Adobe-Logo-in-CSS_edgePreload.js"></script>
<!--Adobe Edge Runtime End-->

You can see the final animation here.

What browsers are supported

Basically almost all browsers are supported: Chrome, Safari (including iOS and Android), Firefox,  and Internet Explorer 9. For older browsers you have an option to create an image from any state of the animation and display that image.

Where to go next

I hope this short introduction raised your curiosity and you’ll try the product and give us feedback. As I said earlier, as we move on towards the 1.0 release it is important that people who actually build the web try this product and help us make the best tool for motion and interaction web content based on web standards – here you can find the product forum, a perfect place to share your thoughts.

Follow me, my blog or Edge to stay informed on what’s new and hot.

This post has been in the back of my mind for sometime. When I woke up this morning I felt a strong desire to help spread the gospels about some of the coolest CSS proposals around layout and effects. If you are the type of person who attends W3C CSS Working Group or maybe W3C CSS-SVG Effects Task Force meetings then you already know this stuff. Otherwise, you should probably keep reading because you might learn some new things.

So what am I talking about here? Pardon me sir, I should have said right at the beginning of this post: I am talking about CSS Regions, CSS Exclusions, CSS Pagination Templates, and CSS Shaders. All of these features were proposed by Adobe and we are working together with other members of web standard groups to make them a … web standard :).

Before getting into details and stuff, let me step back to give you the context in which these CSS proposals were born. Most of the time the feature proposals for new web standards come from web browser manufacturers, guys like Google, Apple, Mozilla, Opera, and so forth. And this is great because they are building browsers day in, day out.

However, there are other players out there who can give a valuable input despite the fact they don’t build a browser. And Adobe is one good example. Our clients create digital content using various combinations of Adobe tools and this content targets the web browser along with other mediums.

And when you talk to a client who comes from the publishing business, one of the things he’ll tell you is that it is extremely hard to create complex layouts using today’s web standards. Of course if you throw in some JavaScript libraries and/or lots of PNGs then you can actually recreate what is possible to do in print. But why not have support for complex layouts built-in directly at the browser level and exposed as a number of CSS properties? This would ensure that you can not only build the content faster (because you don’t have to jump through all kind of hoops) but you’d get consistent performance across devices (mobile and desktop).

Adobe’s solution to this very question (how can you create magazine quality layout for web?) is this trio of CSS proposals: Regions, Exclusions & Shapes, and Pagination Templates.

While making CSS proposals is important, having a prototype could be even more important. Adobe provided for three of them a prototype implementation for WebKit. In case you wonder why Adobe chose WebKit as the engine to build prototypes for, the response is simple: WebKit has been used for different products for a number of years already. This means that we have engineers who are familiar with the WebKit code base (some being WebKit committers/reviewers).

Current Status

Before talking about what each proposal does, I think that it is better to talk about today’s status (yes, I’m going to keep this section up to date). So, what is the spec status and what browsers implement the feature?

Note: If you’re wondering what an Editor’s Draft is, then here is a little explanation. The proposal life-cycle is pretty much like this:

1. Working Draft (WD) (could be multiple iterations) – the new standard is published for review by the community for the first time (virtually anyone can provide feedback).
2. Candidate Recommendation (CR) - at this point the important features are locked in although the design of these features can change.
3. Proposed Recommendation (PR) - Once all the involved parties (users and implementers of the standard) provided feedback and the feedback is addressed, the spec moves to this stage, Proposed Recommendation.
4. Finally it becomes a W3C Recommendation (REC) - the final stage of the technical specification. This is what the browsers should use to implement support for the given spec.

CSS Regions

CSS Regions allow you to create “named flows” of content which can then get laid out across multiple regions. In other words, you can reflow the content from an element to an arbitrary number of elements, which can be in different parts of document. The simple example is one that allows you to create a number of columns and as you change the columns’ number or dimensions, the content automatically flows within them.

If you have a Chrome browser on your desktop/mobile device or Internet Explorer 10 you should be able to see this example.

Probably the simplest example you can build (using the current syntax) is this:

<style>

#article {
flow-into: article_flow;
}

#region1, #region2, #region3 {
flow-from: article_flow;

</style>

<div id="article">Here comes the text you want to display in different regions</div>

<div id="region1"></div><!-- First region -->
<div id="region2"></div><!-- Second region -->
<div id="region3"></div><!-- Third region -->

The flow order (the order in which the regions are filled with the text) is determined according to the document order. The proposal specifies that you can use region styling. This allows you to style the content depending on the region it flows into.

• Proposal authored by Adobe and Microsoft
• Blogpost by Vincent Hardy from Adobe, one of the two editors of this spec
• Spec home
• Custom build of WebKit (the first prototype showed)

CSS Pagination Templates

If you read the CSS Regions description and think a little bit about it chances are you discovered two issues. First, you have to define in the page a bunch of elements that initially are empty – these elements will be filled with the content to be flowed. Second, if the content is less or more than the regions capability to display the text, then you don’t have a clean way to deal with this.

This is where Adobe’s CSS Pagination Templates proposal comes in. It allows you to define templates to be used for displaying content using just CSS. And because you define a template, it doesn’t matter how much content you have. The browser will be capable of generating the number of elements you need to fully display the content. Now this is something sweet, isn’t it?

• Spec home
• No prototype available for now, BUT keep an eye on this page – I will have something awesome for you to play with :)

CSS Exclusions and Shapes

If you go back to the original problem Adobe wanted to solve (magazines quality layout for the web) then you likely realize that CSS Regions (and his little brother, CSS Pagination Templates) is just half of the problem. Consider these two layouts:

You don’t have to be a CSS ninja to understand that there is no way to create this design for the web using just text and CSS.

So how can you solve this problem? Probably the best friend (or girlfriend if you want) of CSS Regions is CSS Shapes and Exclusions. This proposal allows you to:

<style>
#exclusion {
   position: absolute;
   wrap-flow: both;
   background: #dedede;
   width: 80px;
height: 70px;
}
</style>

<div>
   <div id="exclusion"></div>
Lorem ipsum dolor sit amet...
</div>

<style>
.in-a-circle {
    shape-inside: url(#circle_shape);
}
</style>

<svg...>
    <circle id="circle_shape" cx="50%" cy="50%" r="50%"/>
</svg>

<div class="in-a-circle">Content to be wrap...</div>

Another cool aspect of this spec is the ability to use images for defining the exclusion area. In this case the alpha channel is used to compute the shape.

• Proposal authored by Adobe and Microsoft
• Spec home
• Custom build of WebKit (the first prototype showed)

CSS Shaders

This proposal brings cinematic effects to the web. If you are familiar with the Filter Effects spec then you know that you can use a number of predefined filters (or effects) on any DOM element: blur, drop-shadow, hue-rotate, saturate, invert, grayscale, opacity, gamma, and sepia.

Together with CSS transitions you can create some nice visual effects. However, what if you want to do something that is not covered by these built-in effects? The answer is the CSS Shaders proposal.

As with Filter Effects, you can apply a CSS Shader to any DOM element. This means that the source of a CSS Shader (texture) will be the DOM element rendered by the browser. Then you can apply a vertex shader and/or fragment shader to change the appearance.

A vertex shader is used to change the geometry of the pixels input. This is what you’d have to use in order to wrap the DOM element to sphere for example or any other 3D surface. Consider the two images below:

On the left-hand side you can see a list (<ul>) that displays some tweets. On the right-hand side the same list is wrapped in a 3D perspective by applying a vertex shader.

A fragment shader (also known as pixel shader) changes the color of the pixels. Here is simple example where the fragment shader applies a grayscale (the result is on the right) on the DIV element (on the left):

When you create CSS Shaders that apply both vertex and fragment shaders, behind the scene the source DOM element (the raster image of the element as rendered by the browser before applying the CSS Shader) is first processed by the vertex shader and its geometry is changed and then the fragment shader kicks in and changes the pixels’ appearance (color or alpha).

The Shaders are written using the OpenGL ES shading language, the same language used for WebGL shaders. I encourage you to look at the videos from this page where you can see a bunch of examples of CSS Shaders.

• Proposal authored by Adobe, Apple, and Opera
• Spec home
• More info about CSS Shaders
• No prototype available for no

Conclusions

I hope that you are excited by these features. If you have input please make sure you watch the proposal specs and you give your feedback. And keep an eye on this page to see how the specs evolve. Another good resource is Adobe Web Platform Team blog.

It is my pleasure to announce that registration for Adobe WebUp (the third event of the series) is open. If you care about technologies like: Google Web Toolkit, CoffeeScript, mobile web site debugging, Backbone.js, Liquid.js, and Node.js then you should come. You can read more about the agenda here.

If you’ve attended the previous editions and enjoyed it, then make sure you tell your friends about this. By the way the “official” Twitter hashtag is #AdobeWebUp.

As usual, the conference is on a Thursday (March 29th) and registration starts at 17:30. See you there amigos!

A friend of mine, Ray Camden, has recently posted his thoughts on Windows Phone. As his impressions are quite different from mine I thought I should give it a try and explain what Windows Phone felt like to me.

I had the chance to play with it at Barcelona Mobile World Congress. Right near our booth was the Microsoft booth. There were four devices running the latest Windows mobile OS (I can’t remember all four devices but I’m pretty sure they included Nokia, HTC, and Samsung).

What I really liked was the sheer speed of the device. I couldn’t sense any lag everything was running fast and smooth. This doesn’t mean that this will be the case for anything or everything running on the device – remember I tried just the default apps.

Then, I liked the fact that they went for something different that doesn’t look like Android or iOS or anything else I played with.

Unfortunately, this is exactly why I could not say that I’d love to use it regularly. To me, the two biggest mistakes or drawbacks are:

1. Using the apps tiles from the home screen to display notifications. As I was firing up the screens from sleep mode on these phones I couldn’t help feeling that all those notifications were competing for my attention. At a minimum I’d say they are distracting.I could be biased but when I unlock my Android screen I know exactly what I want to do (like checking email or send a message). Although there are notifications in the Android’s title bar they are not screaming in your face.
   Compared to this, the dozens of Windows tiles were like a school of piranhas and by the time I was finished dodging them I’ve already forgotten what I wanted to do.

   After my second attempt using the phone I realized that this phone doesn’t feel like a business or knowledge worker type of phone but like a device for a college kid who only cares about keeping “in synch” with all his friends.

2. As I was playing with different apps on the phone I realized that something was odd. After a couple of seconds I realized that there was too much animation going on, things were flying on the screen or flipping over onto something else, and it was all a bit too much.

Note: I may be biased as I’ve been using iPhone and Android phones for the past five years.

During one of the Q&A sessions we had at the Adobe WebUp #2 event I was surprised to see so many people defending quite aggressively the idea of building web sites/apps for the common denominator (in other words making sure that everything works in IE6).

Well, just to be clear there is nothing wrong with building a web site or application that supports IE6. What I think is wrong is when you get so comfortable with this mindset that you don’t even question the need of supporting IE6. And this is the very reason I was actually surprised to see defending the support for IE6 in the name of the user.

Just off the top of my head I can give you three simple examples where supporting old browsers doesn’t add any benefit:

• You build a web site or application for enterprise or something that will be consumed behind a firewall. In this scenario you are free to choose whatever HTML features you want to use because you can control the web browser of the users. So you can enforce the use of modern browsers.
• You build a mobile web site or application. Although there are stats suggesting that the mobile landscape is not only about iOS and Android, I think that for most businesses this is what they mean when talking about mobile web sites. Obviously both iOS and Android have great support for HTML5 and CSS3 features so you are “liberated” to use whatever you want.
• Finally, you’re working on an existing project and the analytics you have suggest that your customers don’t use older browsers.

Am I wrong? Have you seen this in practice? Talk back!

PhoneGap is a great solution for building mobile applications for multiple platforms using the “write once, run everywhere” paradigm. However there is a tricky part: when you want to package your app and get the native installers you get back to the native development nightmare.

Typically you package your PhoneGap app using the developer tool chain for the specific platform. In other words, if you want to package your app for iOS and Android you will be using a Mac and XCode for iOS and Eclipse with Android plugins for Android. As you add more platforms you can get a sense of the magnitude of the problem.

This is exactly the problem PhoneGap Build solves. Using PhoneGap Build you can let the “cloud” do the crunching task for you. So from the comfort of your browser you only have to upload your application files (HTML, CSS, JavaScript, and images files) and PhoneGap Build will give you back installers for:

• iOS
• Android
• BlackBerry
• webOS
• Symbian

Windows mobile support is coming in case this question was about to land in the comments section :)

Before moving on I want to stress one thing so I make sure you get the awesomeness of this service: in order to use it and get the native installers you don’t have install anything – no IDEs or developer SDKs.

What’s the catch?

If it sounds t0o good to be true then I will have to partly disagree with you. It does what it advertises for. However, you have to understand that as of today (March 7th, 2012) this service is still in beta. So you might find some rough edges or you might discover that some things you need are not there.

However, the service is completely free and it will remain free for open source projects. We haven’t announced any other pricing details yet.

Another rough edge is the support for PhoneGap plugins. Out of the box, PhoneGap Build supports the ChildBrowser plugin (again, you may want to verify this info going forward because this is true as of March 7th, 2012). However, if you are not afraid of a little work you might be able to use other plugins too. You can read more here.

Using PhoneGap Build

Once you’ve created an account at https://build.phonegap.com it is time to rock. And you can rock like a newbie and upload a ZIP file with your application or you can rock like U2 and point the PhoneGap Build to a GitHub or SVN repository.

A couple of weeks ago I built a simple web app for splitting a restaurant bill. And because I have the app uploaded to my GitHub account I thought that this might be perfect for testing the service. So all I had to do was click the New App button and then fill in two fields: application name and GitHub application URL.

Then I hit the Create button. In less than one minute I was able to download the Android APK file, and files for webOS and Symbian (the BlackBerry one wasn’t successful first time). The only one that needs a little bit more work than that is the iOS (you have to provide signing key/provisioning files).

I don’t know about you but I was really impressed to see that it only took 2-3 minutes to go from a web app to running an Android app on my phone.

For now the PhoneGap Build doesn’t support private GitHub repositories (this feature will come). But you can work around this buy creating a new Git repository on the service servers. Read more here.

You can make your application private and then add people so they can download the app. These individuals can have two roles: tester (read access only) and developer (read/write access). If you want to play with this feature all you have to do is to click the Edit button from the application page and then, from the left-hand menu choose the Collaborators entry.

The PhoneGap Build API

The PhoneGap Build API it is really cool. Basically you have programmatic access to the service and thus you can add PhoneGap Build support to IDEs or automated build processes.

You can read more here.

Debug Build

Another cool and time saving feature is the ability to build a debug version of your app and then use http://debug.phonegap.com to start a Web Inspector session on your computer that is connected to your app running on the mobile device.

The first thing you have to do is to enable debug mode for your app. So from the Application view click the Edit button, then select the enable debug mode option.

Once you click Save you will see the Application build page and a new button labeled Debug. After couple of minutes you should get builds created (refresh the page to see this). Install the native app on your device, fire up the app on your mobile device, and make sure it is connected to the Internet.

Then click the Debug button on the Application page. This will open a new browser and you will be able to use the Elements and Console sections of this remote Web Inspector. Pretty cool, isn’t it?

Once again I have to warn you that because it is a beta service sometimes the servers are overloaded with requests from people from all over the world.

Rebuild the app

Every time you change your app you may want to test the app again on your devices. With PhoneGap Build this task is extremely easy. From the Application page all you have to do is to click the Update Code button and then Rebuild all or Rebuild for the platform you are interested in. Of course before rebuilding the app you have to remember to push the changes to your GitHub repository.

You have to refresh the page if you want to know when the build process has finished.

Adding code signing certificates

If you have ever done mobile development for iOS, Android, or BlackBerry you know that in order to be able to submit your application to their stores the app must be properly signed. PhoneGap build supports this.

Under the Navigation section, choose Edit account link and then Signing (it is on the right hand side) – see the picture below.

Once the Signing page loads you will see that you can add the keys for Android, iOS, and BlackBerry. You can add multiple keys for each supported platform and select the one for the default option.

Using the config.xml file

At a minimum all you have to provide to PhoneGap Build is an index.html file of your application. However you can control a number of settings using a file named config.xml, which has to stay in the root folder of your application. Using this file you can specify a version number, icons for your app, splash screens, and device orientation among other things. You can read more here.

For my app I wanted to set icons, a splash screen, and the orientation mode to portrait. Here is the file:

<?xml version="1.0" encoding="UTF-8" ?>
 <widget xmlns = "http://www.w3.org/ns/widgets"
 xmlns:gap = "http://phonegap.com/ns/1.0"
 id = "org.corlan.atabsplitter"
 version = "1.0.0">

<name>aTabSplitter</name>

<description>
 A simple app for splitting a restaurant bill.
 </description>

<author href="http://corlan.org" email="mcorlan@adobe.com">
 Mihai Corlan
 </author>

 <preference name="orientation" value="portrait" />

 <!-- the default attribute can also be used -->
 <icon src="assets/icons/48.png" gap:role="default" />

 <!-- Android icons -->
 <icon src="assets/icons/36.png" width="36" height="36"/>
 <icon src="assets/icons/48.png" width="48" height="48"/>
 <icon src="assets/icons/72.png" width="72" height="72"/>

 <!-- if a single splash screen is specified it will be used for all platforms -->
 <gap:splash src="assets/images/table_01.png" />
</widget>

Where to go next

First of all make sure you go to https://build.phonegap.com and you create an account :) Then you can read the documentation, give feedback, make feature requests, and start building your app.

So what is Adobe Shadow? Shadow helps developers who work on mobile web sites and applications by enabling them to do “synchronous browsing”. You connect your mobile devices to your computer and then you navigate to a page on your computer and all the devices are synchronized displaying the same web page.

So when you open an URL in your desktop browser, all the connected devices will stay synchronized displaying the same URL. Furthermore, you can open up a debug session with one mobile device and use Web Inspector to check the DOM as it was generated on that device, check the CSS properties for DOM elements, resources, and network calls.

It supports iOS and Android devices and it works on Windows/Mac OS computers using the Chrome browser.

How does it work?

Under the hood, Adobe Shadow uses the weinre project (I wrote about weinre here). The main difference is that there is zero configuration setup when using Adobe Shadow (no need to add the weinre JavaScript file to your webpage in order to enable the workflow) and also you get the this nice synchronization between devices where the connected devices follow the computer browser.

There is one limitation at least for now: all the devices must be connected to the same Wi-Fi network.

Installing Shadow

The installation process is quite simple. You grab the desktop Shadow app for your operating system. You install the Shadow Chrome extension from here.

Then you install the Shadow app for your mobile devices from the app stores (iOS App Store and Android Market).

You can read more about this process on the project page.

Shadow in action

Now let’s see how you use Shadow. Once you’ve installed everything, you are ready to pair the mobile devices to your computer. Here are the steps:

1. Make sure your computer and mobile devices are connected to the same Wi-Fi network.

2. Start the Shadow application on your computer and make sure that the Shadow Chrome extension is enabled.

3. On all your mobile devices start the Shadow application and choose the computer you want to connect to (you will see all the computers running Shadow and connected to the same Wi-Fi network).

4. The first time you pair a mobile device to your computer you’ll have to provide a PIN. So once you select the computer you want to connect to, the mobile device will display a PIN number.

5. Grab the PIN number and type it in the Chrome Shadow Extension (you will see that the extension displays a little green plus every time a new device needs pairing)

6. That’s it. From now on your devices are connected (your mobile device and your desktop/laptop computer). What’s more: you need to do this only once for a pair. Of course, if you need to disconnect or reauthorized a device you can do this (you do this from the Shadow Chrome extension).

Starting a Remote Inspection session

Once the devices are connected via Shadow, choose the brackets icon corresponding to the mobile device you want to debug. See the picture below:

This will open up the Web Inspector that it is connected to the selected mobile device. You can go to Elements and select a node and you will see it highlighted on your mobile device. You can check the Console or check the CSS properties and metrics. You can even play with the JavaScript Console.

As you select nodes from the DOM you will see that on the mobile device that very DOM element is highlighted.

Here I used the Console to remotely execute some JavaScript code (alert(‘Hello Adobe Shadow! ‘)):

And here is the result of the JavaScript code execution on the device:

Conclusions

I think that Adobe Shadow brings mobile development to a whole new level by greatly simplifying the testing and debugging of web pages and apps on mobile devices. Right now it is in beta and it is free so make sure you go to Adobe Labs, grab Adobe Shadow, and give it a try.

Although there are other methods to do mobile testing for web pages (I am thinking of weinre and Google Chrome for Android), I think Adobe Shadow offers more value. Someone from the team told me that at some point he had 35 mobile devices connected to his computer and it was awesome to see how different web pages were rendered on all these different devices.

Also, keep in mind that this is just the beginning. The team has many more ideas and we are happy to listen to your feedback. So don’t be shy :D

Actually, if you want to keep a close eye on the team you can follow them on Twitter and is the team blog, here.

As my duty at Adobe’s booth started only in the afternoon, I used the first part of the day to walk around and get a sense of the show. Here are some pictures I took with my phone camera.

First, the Adobe booth. I was surprised by the number of people coming right from the opening hours. I was expectecting people to be more interested in all the new cool devices. Instead there were lots of people all over the place.

One of the biggest booths around is Google’s. I think they are using the same booth they had last year. Nevertheless it is impressive. You can see there are lots of people.

Some press guys resting before their next interview.

Next, the Microsoft Windows Phone booth. I played a bit with some HTC and Nokia devices. I am sure I am biased, but I will say it anyway: the devices are fast. No doubt. But somehow I don’t get the UI. Probably all the years I’ve been using iOS and Android devices…

Right near our booth there is the HTC booth. I have to check them out as it seems they announced a crazy powerful new phone, HTC One X.

That phone is powered NVidia’s Tegra 3 chip. So here is NVidia booth:

As with any show there are lots of characters :)

It’s lunch time, which means the crowd is starting to move outside.

That’s it for today. Now I have to run for my booth duties.

Later Update: This is the only conference where I’ve seen only men queueing in front of the rest rooms. It must be divine retribution I guess:

The Mobile World Congress has started this morning and one of big announcements is Adobe’s release of Adobe Photoshop Touch app for iPad 2. This tool offers core Photoshop features plus some features uniquely tailored to the mobile medium like sharing. What’s more is that this is just the first step. Photoshop Touch is part of a family of six touch apps – the rest of the suite will come to iPad later this year. You can see the app here.

If you are at the MWC then make sure you drop by our booth in Hall 1. You can play with the app on our devices and you can see how it is already being used by professionals.

There were two other announcements this morning related to digital publishing and video. If you are a developer, maybe this type of announcement  is not your cup of tea, but nevertheless they are important because digital publishing and video publishing are growing.

Adobe’s solution for digital publishing (AKA creating beautiful digital magazines and newspapers for tablets) has served more than 16 million publications for the past 12 months. Using anonymous data collected across these publications we distilled them to:

• 68% of readers are paying for the content
• 48% of readers explore the interactive features (web views, audio and video clips, slide shows, and image sequences
• 56% of readers spent 25 minutes to 2.5 hours reading digital titles each month. What is even more important is the trend: this time has increased more than 70% over the last six months.

Project Primetime was announced today too and it is all about delivering and monetizing video content. Nothing new so far, right? Well, here is where the interesting things come together: Primetime helps you use a single, end-to-end workflow, to create a TV-like experience for premium video and ad content and distribute this to all major Web connected devices: iOS devices, Android devices, and of course desktop computers. It supports live streaming, linear, and on demand streams and for all of them you can insert ads with complete control.

Again, if you are at MWC come to our booth and you can find out more. There are presentations on all these topics.

Finally, here is a picture of the main entrance this morning:

I thought that it would be helpful to document the experience I had while building a web application using jQuery Mobile. And this is what this article is all about. But before going into details let me set the context.

I started building mobile applications a while ago using Adobe AIR and the Flex framework. My first “production ready” application was called aTabSplitter and it is available for download in Android and BlackBerry markets. It was a fun and eye-opening experience. I mean it is one thing “to play” with technology and an entirely different thing to build something that will be actually useful and people will love to use.

Recently, as I was playing with jQuery mobile I had an idea: what if I tried to rebuild the application using HTML, CSS, and JavaScript? To make things more complicated I wanted to retain the same UI and user experience. In other words I treated the mobile application as the design and user workflow diagrams you’d get from a UX.

If you haven’t tried the application yet let me briefly describe it: it allows you to split a restaurant bill. The important workflows are the first screen, where you add new persons, delete them, move them around the table, or adjust the tip, and the calculator screen where you add the items for a single person. Actually, I am pretty proud because I think I found a good/intuitive user interface.

And by the way, here is the link for this web app.

Here are screenshots with the application running on desktop and mobile devices.

Android 4 Phone:

On iPad:

The Plan

Here is what I was set to achieve: a web application that will work on mobile devices and the desktop. Although I could have gone the PhoneGap route and pack the whole thing into a native app, I wanted to have a single base code base for the first pass that will work in browsers on all these different devices. As a framework I decided to go with jQuery Mobile. This, at least in theory, was a perfect match for my application given the fact that all I needed was a nice way to keep the two screens separated from a functional point of view.

I didn’t see any need for other frameworks. So for the rest of functionality I wrote JavaScript and used HTML/CSS and images to create all the UI I needed. Because I went for a web application I chose to implement only the main features of the original AIR app. Nevertheless, I wanted to use all the new features available in modern browsers that made sense for my app so I could make a responsive and usable web app. For the rest of the article, I will highlight some of the things that were either trickier than I anticipated or altogeher unexpected and the general approach. I hope you will find it useful.

jQuery Mobile and architectural considerations

jQuery mobile was a pretty obvious choice because of the features it offers. The way it lets you organize your application using “pages” and keep them in the same HTML document is perfect for what I needed. Remember that I wanted to build a small application that has only two “screens”.  Also I like the fact that I can define most of the UI using pure HTML without the need for JavaScript.

Once I had the UI in place, I started to write the JavaScript code that powers the user interface. Normally, I would wrap the different functionalities in a number of objects. However for this project I decided to go against the best practices and write mainly functions. The only way I organized them was by splitting them in three different files: home.js, calculator.js, and utils.js. The first two files hold the functions used for the home screen and calculator screen and the third one holds utility functions. Why did I choose to go against best practices? One main reason: the application is too small to be worth spending time on architecting the code.

Although conceptually, there are two pages in my application as far as the browser is concerned there is only one page. This means that the JavaScript code has visibility over the whole application DOM.

In index.html there is a little bit of JavaScript code used for boot strapping the application. It is the usual jQuery business, executing the bootstrap code on the jQuery ready event. This is where I attached various event listeners on UI components and I set the height for main UI components.

The part with setting up the height manually was a bit of a surprised. I was expecting that jQuery Mobile will take care of this for me and when the content in the page didn’t overflow it would set the size of the div to be equal to the viewport minus the header and footer. This is not the case.

Another interesting thing in index.html is the array that holds references to all the plates on the screen, as well as a reference to the trash bin image – so I can quickly check if the user wants to delete a plate (if you drag a plate on top of the trash bin it will be deleted).

One of the issues I had was how can I make sure that the user doesn’t land directly on the second page. It doesn’t make sense to support this and if it happens it is confusing for the user. After I spent some time reading the documentation and talking to my fellow evangelist Ray Camden I decided to go for an extreme solution. Inside the function executed for the jQuery ready event I checked the current page value. If it is calculator (the second page) then I reload the page:

//forcing the app to load the first screen if the user lands directly on the second page
if ($.mobile.activePage[0].id === 'calculator') {
   l = window.location;
   l.hash = '';
   window.location = l;
}

Finally, I tried to keep the dependencies on jQuery to a minimum. Why? Because I plan to rewrite the application using other frameworks and if I decide to go without jQuery then I don’t want to have lots of code to clean up.

Custom Data Attributes

Obviously this application must have a data model, right? There are different approaches I could have used to store the data model. The one that made most sense to me is using custom data- attributes.

Each plate that you add has the data stored in two attributes:

• data-i : stores the items you add. For example, if you added 5 + 12, then data-i = [5, 12]
• data-t: stores the total. Using the example above, data-t = 17

Touchstart event vs mouse click event

If you’ve worked with mobile web apps then chances are that you already know this. If not then you should pay attention. If you use click events for your UI components (buttons for example) when you run the application on a mobile device (including most powerful tablets) you will notice a huge lag between the time you touch a button and the execution of the click event listener. It is so big that it renders the app almost unusable. The solution is pretty simple: use touchstart events instead of clickevents. On touch devices whenever you touch the screen you get events in the following order:

1. touchstart
2. touchmove
3. touchend

Dealing with multiple touch events

When you use touchstart and click events in your application a lot, you will end up in a situation where you need to add logic to handle some use cases. The first screen of my application is pretty heavy on touch events usage: you can touch the screen to add a new plate, you touch a plate to go the second screen and edit, you can move around a plate, or you can touch the slider to adjust the tip. I have all my events registered for the bubbling phase (if you need a refresher on the event phases check this resource).

Much to my surprise, I couldn’t use the slider on mobile devices. Every time I touched the slider a new plate was added to the screen. My solution to this issue was a quick hack to check for the target object in the event listener that adds a new plate – if the target is part of the slider then I don’t add a new plate.

Another area where I had to pay attention was the plate itself. You can touch/click a plate to move around or to edit. I decided that if you move a plate around it doesn’t necessarily mean you want to edit. I change the app to the edit plate screen if the plate has moved more than 10 pixels in any direction.

Custom components

Most of the UI components I needed for my app were covered by the browser or jQuery Mobile. However there was one I needed to create – the component that represents one person on the first screen.

It is pretty simple component: an image that represents a plate and a label that displays the total. At least it seems simple until you try to make it work. Because I wanted the text to be centered both vertically and horizontally. Also, if the text grows bigger than the image, I wanted it to be centered (see the picture below).

After some trial and error I managed to come up with the following code for this:

<div class="plate">
    <img src="assets/images/plate-big.png" alt="" />
    <div>0</div>
</div>

Here is the CSS for this component:

.plate {
      position: absolute;
      color: #000000;
      font-size: 20px;
      overflow: visible;
      text-align: center;
      -moz-user-select: -moz-none;
      -khtml-user-select: none;
      -webkit-user-select: none;
      user-select: none;
}
.plate > div {
      text-align: center;
      margin-top: -65px;
      width: 100%;
}

The second custom component was the keyboard I use on the second screen. All I needed was a basic calculator keyboard – actually even simpler as I didn’t need all the operations. Why did I go for a custom keyboard? Because it makes my app more usable by giving the user only the keys he needs.

I used the old school tables approach. And it worked beautifully on the desktop but not so good on mobile phones – the keyboard was falling out the screen. After some debugging using weinreI realized what was happening. jQuery Mobile augments your code. Typically, for any button you have in your app it will generate a number of divs/spans that are positioned on top of the button and these elements actually provides the visual appearance of the button.

Because it does a generous use of padding and margins there was no way I could manage to fit 5 buttons on the same row on an iPhone or Android phone. How did I fix this? Well my solution is certainly not the most elegant but it works. I used Media Queries, CSS selectors, and the infamous !important to overwrite the jQuery styles for my keyboard when the app is running on mobile phones. If anyone knows a better solution, please tell me!

Saving application state – Web Storage

Suppose you add some items and persons to the app and you accidentally hit the back button. Of course, the whole state of the application will be lost. And this is something I didn’t want to happen.

I save the application state using the Web Storage localStorage feature. This feature is supported by all modern browsers and it offers a simple API to store key/value pairs (think of a hash map or associative array in PHP). The only catch is that the value is saved as a string. The application state is saved in the form of an array of objects where each object maps one of the plates: it holds the top and left position, the total, and the items. This information is enough to restore the application state. The relevant code is in the scripts/home.jsfile. Here is the code for saving and reading:

//
function persistApplicationState(arr) {
    var i, l, toSave, el;
    toSave = [];
    for (i = 0, l = arr.length; i 0 && localStorage) {
       localStorage.setItem('plates', JSON.stringify(toSave));
   }
}

function getPersistedPlates() {
    var ret;
    if (!localStorage)
       return false;
    ret = JSON.parse(localStorage.getItem('plates'));
    if (!ret || ret.length === 0)
       return false;
    return ret;
}

Note that I am using JSON.stringify() and JSON.parse(). This is related to the fact that Web Storage saves only strings. In terms of size, most browsers offer by default 5MB (Firefox warns the users and asks for permission).

Reduce Loading Time – Application Cache

You might think of Application Cache like browser caching on steroids. By using Application Cache you can dramatically improve the loading speed of your application and the app can be used while users are offline.

This feature is pretty simple to use: you create a manifest file (which is a simple text file with an appcache extension and the first line must have this text CACHE MANIFEST). In this file you add entries for all the things you want to cache – could be CSS files, JS files, images, HTML. Then you enable the Application cache by setting the manifest attribute on the <html> tag:

<html manifest="app.appcache">

Now, every time you want to invalidate the cache and make the browser reload the resources you change something in the application cache file. Most people add a commented line with a timestamp and version number and they just change this. Here is my cache file:

CACHE MANIFEST
# 2012-02-21:v9.5

CACHE:
index.html
styles/styles.css
styles/jquery.mobile-1.0.1.min.css
scripts/jquery-1.6.4.min.js
scripts/jquery.mobile-1.0.1.min.js
scripts/utils.js
scripts/home.js
scripts/calculator.js
assets/images/plate-big.png
assets/images/table_01.jpg
assets/images/bill.jpg
assets/images/trash.png
assets/favicon.ico
styles/images/ajax-loader.png
styles/images/icons-18-black.png
styles/images/icons-18-white.png
styles/images/icons-36-black.png
styles/images/icons-36-white.png

Once the application has loaded for the first time, you will notice that subsequent loads are extremely fast. This is because all the resources used in the app are cached locally. And remember that each time you change something in your application you have to invalidate the cache.

iOS Offline Web Application

iOS lets you save a web site/application to the home screen. This is the closest you can get to a native app with HTML without using something like PhoneGap. Also this feature plays nicely with Application Cache.

You have control over a number of things:  the icon to be used for your application, an image to be used during the loading time (startup image), and if you want to hide the Safari Mobile chrome or not. All these are set or controlled by using <meta> or <link> tags added to the <head> section of your webpage.

In the index.html you will find these tags:

<!-- Hiding the browser chrome -->
<meta name="apple-mobile-web-app-capable" content="yes" />
<!-- Setting a startup image for the app -->
<link rel="apple-touch-startup-image" href="assets/images/table_01.jpg">
<!-- Providing Icons for iOS and iPAd -->
<link rel="apple-touch-icon" href="apple-touch-icon-57x57-precomposed.png" />
<link rel="apple-touch-icon" sizes="72x72" href="apple-touch-icon-72x72-precomposed.png" />
<link rel="apple-touch-icon" sizes="114x114" href="apple-touch-icon-114x114-precomposed.png" />

Here are screenshots with the app saved to the home screen and running without the browser chrome.

You can read more about this topic here.

Preparing the app for mobile browsers

By default, on most mobile platforms you can scroll the page in the browsers a few pixels up and down even when the page content fits to the screen. Man, I hated this feature so much. Why? Because the main paradigm for using the first screen is by touch and dragging. Now every time you tried to move a plate up or down, the whole page was moving in the same direction. It was disturbing and annoying at the same time. To fix this I added a listener on the body for the touchmove event to prevent the default behavior:

// fix for canceling the scrolling of the body on mobile devices
 document.body.addEventListener('touchmove', function(event) {
           event.preventDefault();
      }, false);

The second thing I had to do was to set the layout viewport width to the device width and make sure scaling was disabled – I didn’t feel that the user could benefit in any way by zooming the app in or out. So I placed the following meta tag in the head section:

<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, user-scalable=no">

This is a good read on understanding the mobile layouts viewports and screen sizes and the difference between screen resolution and CSS pixels.

Handling different screen sizes/devices – Media Queries

The Media Queries feature was quite handy especially for getting the second screen of the application right. Because that screen has a keyboard, I had to make sure that the keyboard size was big enough to be usable on the phones and, at the same time, stays within the screen width.

Due to how the layout viewport works on mobiles and how jQuery Mobile styles buttons, the code that was working perfectly on the desktop even when minimizing the browser window was entirely unusable on iPhone or Android phones. The keyboard (on the second screen) didn’t fit so almost half of it was invisible. By setting up two additional sections for devices with maximum width 720px (Samsung Nexus) and 640px (most Android phones and iPhone/iPod Touches) I managed to fix the problems.

//styles/styles.css

@media only screen and (max-device-width: 720px) {

...

}

@media only screen and (max-device-width: 640px) {

...

}

Debugging the code

Nothing new here. For the desktop I used Web Inspector and for mobile, weinre. In case you have never used weinre then you can read my post on this topic here. I was so happy to have weinre because it helped me to understand and fix the issues I had with the layout on the calculator screen.

Google released this month a special build of Chrome for Android that enables remote debugging. Basically you get the web inspector on your desktop hooked up to the app running on your mobile device. Unfortunately, the application is not available in all the countries. I don’t exactly understand why and I don’t know when it will be available world wide.

The Code

You can download the source code from GitHub or you can play with the application. I tested it on desktop (Firefox, Chrome, and Safari) and on Android Phones/iPad/iPhone4.

Conclusions

As I said at the beginning, I had lots of fun while building this. The fact that I was able to test some of the frameworks and HTML features I’ve been playing with in a real app was a bonus.

In terms of development effort, I spent most of the time on making the application look the same (or as close as possible) on different browsers/devices. I used Chrome during my development. And once everything was in place I was sure that I was done. Poor me, because I kid you not the app looked differently in Firefox, Safari, and Chrome – I mean each browser rendered something different than the other two :D

In terms of performance and quality there is a big difference between how the app performs on the desktop and how it works on mobile. On mobile there is some screen flickering, the transitions are not always smooth, and the UI is not always perfectly aligned. You might argue that it is jQuery Mobile’s fault or my fault. My opinion is this: it is what it is. I mean mobile browsers have come a long way in recent years but there is still a gap between desktop and mobile. This is what is possible today. Tomorrow it will be better, no doubts.

Now, that I have the V.1 I am ready to experiment with different approaches. First on my list is to use PhoneGap to package my web application as a native application. This will give me a chance to add another feature from the original app: taking a photo with the device camera and replacing the picture from the first screen. Second, I will try frameworks other than jQuery Mobile.

If you build web pages that are interactive and work on desktops and mobile devices then chances are that you need to work with touch and click events. For mobile devices you’d want to use events like touchstart, touchmove, and touchend and for desktops you’d use mouse events (mousedown, mousemove, and mouseup).

Most of the time the code you execute as a response to these events is the same between these two platforms. So one way to avoid duplicating your code is to take advantage of the JavaScript’s dynamic nature to inject additional data into the event object and chain the click and touch event listeners.

Here is a snippet of code that illustrates my point:

function init() {
    var el = document.getElementById('myDiv');
    el.addEventListener('mousemove', onMouseMove);
    el.addEventListener('touchmove', onTouchMove);
}

function onMouseMove(e) {
    e.touches = [{clientX: e.clientX, clientY: e.clientY}];
    onTouchMove(e);
}

function onTouchMove(e) {
    //do something with e.touches[0].clientX or e.touches[0].clientY

}

The code should be pretty simple to follow:

• I register listeners for mousemove and touchmove
• If the code runs on a desktop then the mousemove listeners will be triggered. When this happens I inject the mouse X and Y position in the event object using the data structure used by touch events (touch events have a touches property, which is an array of objects that follow this pattern: {clientX: value, clientY: value}). The touches property is an array because you can expect more than one touch point on some devices. Then I call the onTouchMove function passing along the modified event object
• The logic I want to execute for that specific action is declared in a single place, the onTouchMove function

I put together a simple page so you can see the code and test it on you computer/devices: demo here.

What method do you use to deal with this?

I am happy to announce that the second event of the Adobe WebUp series has been announced and you can register yourself here. In the meantime we’ve changed the name from “Adobe Developer Days – Web Platform” to “Adobe WebUP”.

The second event is dedicated to HTML5 forms: what HTML5 forms are, how to style them, and browsers support for them.

I hope you’ll join us on February 23rd. You have to register here if you want to participate.

On February 2nd we will host the first conference from a series of conferences about web technologies and development. Our presenter will be Vincent Hardy, principal scientist at Adobe Systems.

See you on February 2nd!

You can find more info about this conference and register here (the presentations will be in English).

PS. I am so happy to see this finally get started as I’ve been working on it for some time.

If you want to learn how to use PhoneGap to build mobile applications with JavaScript and HTML, one good way is to watch this great series of nine videos. My fellow evangelist Kevin Hoyt spent some time in the studio for shooting and the result is great. It will take you less than a hour and a half to watch all the videos.

Here is the list:

1. Getting Started with PhoneGap

2. Developing for iOS

3. Developing for Android

4. Device API

5. Accelerometer API

6. Camera API

7. Compass API

8. Connection API

9. Contacts API

In  a previous post I explained how you can use weinre to remotely ”debug” web pages that run on your mobile devices. If you are familiar with weinre then you also know its biggest limitations: no JavaScript debug support and CSS styles introspection.

Now there is no need to be sad if you happen to have a PlayBook device. If so, then you are back in business. What do I mean by that? I mean full access to Web Inspector/Developer Tools goodies while browsing web pages on the PlayBook tablet. Yes, including JavaScript debugging and CSS introspection.

A question or a doubt might pop in at this point … how this could this be possibly useful for developing web applications that run on mobile devices when Android and iOS devices have the greatest market share? Relax my friend, no need to lose your faith :D Because iOS, Android, and PlayBook default browsers are all based on WebKit. Although there are some differences between them I think they are close enough that you can get lots of value out of using the PlayBook device as the “debug” mobile platform. It also performs fine, at least today. I mean it is not too far off from the latest mobile phones or tablets.

So let me guide you through the steps you need to complete if you want to remotely debug web pages using a PlayBook.

1. Get a PlayBook

The most important step is actually getting a device :D. You might be able to buy a used one for a good price. I think it is a good investment if you plan to (or  you already) do lots of mobile web development.

2. Connect the PlayBook and your computer to the same WiFi network

This is another important step. The PlayBook browser has Web Inspector support. While you can use it directly on the device I bet my 2 cents that it is far more convenient to use it on your computer. So this is the reason you need to connect them to the same network

3. Enable Web Inspector on your PlayBook

Set up a password for your PlayBook if you haven’t already set one (Settings > Security > Password). Then open the browser application and go to Settings. Select Privacy & Security and then enable Web Inspector (it will ask for your password when enabling this option).

Once you enter the password a message window will give you the IP and port number of the PlayBook Web Inspector. Write down this info because you will need it.

4. Load the page you want to debug/profile

Now it is time to get serious. So open the web page you want to debug in the PlayBook browser. Please note that it is possible to open up a web page hosted on your computer web server (remember that the PlayBook and your computer are connected to the same network; so if you have a web server running on your computer you will be able to access it from your tablet).

5. Start Web Inspector

You can do this in two different ways. If you are a masochist you could use the Web Inspector on the PlayBook: open a new tab in your browser and type in this URL http://localhost:1337. You will see a page that has an entry for each opened tab in your browser (the URL must be opened after you enable Web Inspector in order to be listed). Here is an image to get an idea:

And here is the Web Inspector running for the first tab on my PlayBook on the PlayBook if you know what I mean:

But probably the sane way to do it is to run the Web Inspector remotely on your computer. So open a browser and type in the URL you got from Step 3. Once it is loaded you can select the tab you want to debug. And once you select the tab the Web Inspector should be displayed. From now onit is business as usual: you can access Elements, Resources, Scripts, Timeline, Profiles, Storage, Audits, and Console. You can debug the JavaScript code, audit the page for performance, and all sorts of magical things.

Here are screenshots with the Web Inspector running on my machine and the page I am debugging on the PlayBook. In the Web Inspector I selected a DIV element and you can see that the element was highlighted in the PlayBook browser.

Word of warning: it might take a while for the Web Inspector to initialize on your machine. Be patient and don’t give up.

Conclusions

If you are not excited by this amazing workflow then there must be something wrong with you (or you are not a web developer and then it is OK :D). Again it might not be the perfect solution. I mean in a perfect world you’d have something similar for each mobile platform. Until then don’t whine too much and do your work with what you got!

Here is a screencast that takes you through the setup steps of the PlayBook Web Inspector and shows a simple debugging session. Enjoy!

While using Canvas 2D context for drawing stuff I discovered that the drawing line API can surprise you a bit especially when drawing horizontal or vertical lines. Here is a screenshot with a Canvas element and 5 lines drawn using lineTo() calls:

In case you haven’t noticed, let me tell you what’s wrong with this: the lines are suposed to be 1 pixel width and black. Clearly what you see on the screen is not 1 pixel and the lines are somehow grayish. It looks more like 2 pixels. The code for drawing this looks like this:

<input onclick="draw()" type="button" value="draw" />

<script type="text/javascript">// <![CDATA[
function draw() {
    var context, i, y;

    context = document.getElementById('canvas').getContext('2d');
    y = 20;
    context.lineWidth = 1;
    context.strokeStyle = '#000000';
    for (i = 0; i < 5; i++) {
       context.moveTo(0, y);
       context.lineTo(450, y);
       y += 10;
    }
    context.stroke();
}
// ]]></script>

Let’s change the line width to 2 (line 10 in the above code snippet) and check the result:

Interesting, isn’t it? So the lines width is basically the same, but the color now is really black. Now, let’s try something else: change the line width back to 1 and adjust the y property of the moveTo/lineTo functions with o.5 (line 13/14):

context.moveTo(0, y + 0.5);
context.lineTo(450, y + 0.5);

And surprise, surprise the lines are now exactly 1 pixel and black:

So what’s happening? After some research I think that this is what is happening:

• When you use integer coordinates like 10 or 15 the drawing algorithm is actually trying to draw a line in between two pixels (for example between the 9th and 10th pixels). As a result it will actually draw two lines.
• I think the line is slightly lighter than the color set because of the antialiasing algorithm.
• When you offset the coordinates by 0.5 then you “end” up with drawing the line exactly on one pixel.
• If you draw a 1 pixel vertical line from (0,0) to (0,200) you will see that this time the line is exactly one pixel wide but the issue of lighter than defined color remains. As there is no other pixel to the left of the 0 pixel on the X axis on the screen you will see only one line.

Using fillRect() function instead of lineTo()

If you don’t like adding those 0.5 to any coordinate when using the lineT0() API then you can actually use the drawing rectangle API. As you probably already guessed, the trick is to draw a rectangle of one pixel for one dimension and the length you need for the other one. So here is the script for drawing 5 horizontal lines:

function draw() {
    var context, i, y;

    context = document.getElementById('canvas').getContext('2d');
    y = 20;

    for (i = 0; i < 5; i++) {
       context.fillRect(0, 10 + y, 450, 1);
       y += 10;
    }
}

And here is the result:

If you are wondering about performance differences between lineTo() and fillRect() then you shouldn’t. fillRect() is probably even faster than lineTo().

You can see here a page that illustrates the differences between lineTo() and fillRect() when using integer coordinates.

If you are a web developer chances are that Google Chrome Developer Tools, Safari Web Inspector, or a Firefox equivalent are your best friends when it comes to debugging web pages (check CSS styles, verify generated HTML, or debug JavaScript). Isn’t that great? I mean not so long ago we used to debug JavaScript using alert() calls.

Once you get used to these tools it is hard not to have them. And this is exactly what happens when you move to mobile web development. As you probably know there is no web inspector running on your iOS device browser.

How do you debug your web apps when running on mobile devices? The best answer to this question is using weinre (if you know a better way, please let me know).

What is weinre?

weinre is a remote Web Inspector that runs on your computer but it is connected to a browser (or a PhoneGap application) that is running on a mobile device. In terms of user interface it reuses the Web Inspector project at WebKit.

weinre consists of a debug server that runs on your computer and a user interface that also runs on your computer. The server component is able to communicate with the web page you are “debugging” (that typically runs on a mobile device) thanks to a JavaScript script that you have to inject in the page you want to debug (the script is served by the server component). And here comes the first thing you have to know: because of this architecture your mobile phone must be able to reach the server running on your computer (you can easily achieve this by connecting the computer and mobile device to the same WiFi network). If you are curious about how the web page running on the mobile device is able to communicate with the debug server, the answer is using XMLHttpRequest.

Finally, weinre is distributed either as a Java JAR file or as a Mac OS X application. This means that you can use this tool on a Windows, Mac OS X, or Linux machine.

Are there any limitations?

Unfortunately there are: you can’t debug the JavaScript code. This means you are not able to set breakpoints in your JavaScript code and introspect the variables. Unfortunate though this limitation might be, weinre is still incredibly useful because you can introspect the HTML code, see the Console output, execute JavaScript code in the console, get information about the XHR calls made by your page, and even select DOM elements.

How can you use it?

Here is a step-by-step list that explains how you can use weinre to “debug” a web page that is running on your mobile phone:

1. Download the weinre debug server application

First download the weinre application (this will be basically the debug server). I will use the Mac OS X application instead of the JAR file and I will point out what is different if you use the JAR file.

2. Connect the computer and mobile device to the same WiFi network

After you download the weinre file it is time to connect your computer and mobile device to the same WiFi network. Once the computer is connected, it is time to find out what IP address it is using. On my case the IP address is 42.1.2.250.

3. Configure the weinre debug server application

Now, it is time to configure the weinre debug server. Because I am using the Mac OS application, all I have to do is to create a server.properties file in the following location: ~/.weinre/server.properties

Next, open the server.properties file and add these two lines (for boundHost you have to introduce the IP address of your computer and for httpPort you can use any port number you want that doesn’t conflict with other web servers that might be running on your computer):

boundHost: 42.1.2.250
httpPort:  8080

Make sure you save the file.

If you use the JAR file, then you can set the options either using the server.properties file or adding them as options to the command line when invoking the JAR file.

4. Start the weinre debug server

For the Mac OS X app all you have to do is start the weinre application. If you use the JAR file then you should start the application using the command line.

5. Inject the JavaScript file in the web page you want to debug

With the debug server running it is time to inject the JavaScript file that makes all the parts to communicate. To do so, open the HTML page you want to “debug” and add this line:

<script src="http://42.1.2.250:8080/target/target-script-min.js#anonymous"></script>

Please note that the IP address and port number must match the values you set in the server.properties file. Make sure you save these changes.

6. Make the web page available to your mobile phone

Now, you are ready to debug the web page. However, in order to do this you have to load this page in the browser that runs on your mobile device. You will have to copy the web page and its dependencies to a web server running on your computer. In my case I’m running a MAMP instance on port 80. So what I’ve done is to copy the folder where I created the web page to the htdocs folder of the MAMP. Make sure the web server you want to use is running.

7. Load the web page on your mobile device browser

Open the browser on your mobile phone and load the page: http://42.1.2.250/weinre/index.html

Please note the IP address and port number must be your computer IP address and your web server port number (in my case I am running on the default port so there was no need to add it) and the rest of the URL must match the folder/file name you have.

8. Debug the page

Once your mobile browser loads the page, the weinre application should look like this:

In the picture above Targets refers to the mobile device browser (so the IP address is your mobile device IP) and Clients refers to the debug client/server.

Here is a screenshot with the weinre application when the Elements tab is used and the console is opened too. You can see that the whole body element is selected. And in the console you can see some outputs. These were dysplayed once I hit the two buttons I have created in the web page.

And here is a screenshot of the web page running on my Android phone. As you can see the body is selected – because in the weinre app the body element was selected.

Finally, the web page used in this example looks like this:

<!DOCTYPE HTML>
<html>
<head>
<meta charset=”UTF-8″>

<title>Testing</title>
<script src=”http://42.1.2.250:8080/target/target-script-min.js#anonymous”></script>
<script>
function clickBtn() {
console.log(‘clickBtn() was called!’);
}
function click2Btn() {
console.log(‘click2Btn() was called!’);
}
</script>
</head>
<body onLoad=”init()”>
<h1>A simple page</h1>
<h2>To test weinre – Web Inspector Remote</h2>
<button onClick=”clickBtn()”>Click Me</button>
<br>
<button onClick=”click2Btn()”>Click Me Too</button>
</body>
</html>

If you use the JAR file, then you should open on your computer this URL: http://42.1.2.250:8080/client/#anonymous. Again change the IP address and port number to what you configured for the weinre debug server. Here is a screenshot with the debugger client opened in my browser:

For your convenience, I captured this workflow in a short screencast:

Conclusions

Although you don’t get all the features available in the desktop Web Inspector, weinre is still a formidable asset in any developer’s toolbox. I mean without this you would have to use alert() or some other ten times more time consuming technique. Recently I was working on a web mobile application and weinre came to my rescue on a number of occasions.

I intended to write this post last month. But because the last two months were so busy, in the end I could find neither the time nor the energy to write. So here I go with my first post in 2012 that partially talks about 2011.

Speaking of the previous year, I’d like to extend a big thank you to all my readers and followers. Knowing that people will read your posts and send feedback is like fuel for engines. Next, I’d like to say thank you and applaud all the community leaders who worked so hard to organize events. I know firsthand the hard work needed to put together an event. You guys did an amazing job in 2011. I feel both proud and lucky being able to be part of some of the events you organized around the world.

People asked me what the highlights of 2011 were for me. Many things come to mind, but once I boiled them down they distilled  down to only two:

1. Adobe AIR and Flex demonstrated that development for multiple mobile platforms can be both fun and efficient. Indeed, what started as a promise back in 2010 grew to an amazing platform in less than a year.
2. Adobe increased investment and effort in HTML/CSS/JavaScript. The last part of 2011 only accelerated a process that started long ago and produces things like: CSS Regions and Exclusions, CSS Shaders, Dreamweaver support for jQuery and PhoneGap, contributions to WebKit and jQuery Mobile. The PhoneGap and Typekit acquisitions cemented these trends and set up a perfect scene for more things to come moving forward.

What about me (I know, I know it’s a bit too much :D)? Well, I couldn’t be happier to tell you the truth! I am still having the time of my life and enjoy every bit of my job :) I’ve been doing evangelism for almost four years and I’m looking forward to many more. However 2012 marks a change regarding what my focus will be: I will focus more and more on HTML, JavaScript, and CSS. And I have to confess that I’m excited. First, because this is how I started to make money programming years ago (HTML/JavaScript/CSS and server-side technologies). And second, I think Adobe is extremely well positioned on moving forward the web standards and HTML authoring/services tools.

What about Flex, AIR, and Flash Player? Despite what some people are saying I think they will be doing great. The runtimes are pushed harder and harder because Adobe wants to make the Flash Platform the game console of the web. This means that even if you are not in the gaming industry your Flash apps will benefit. What about Flex? I think the Flex framework is mature, it has a great community around it, and it is used for big enterprise projects and consumer apps. Having said that I think that the Flex framework will be relevant as long as the community wants it to be. Because if the community doesn’t believe in it and stops using it then it doesn’t matter what Adobe does and who’s behind it. I will surely keep an eye on what you guys will be doing :).

I wish you a Happy New Year!

Recently I played with CoffeeScript a bit. Friends were talking about CoffeeScript and also I read couple of interesting blog posts. Based on my limited experience with it here is my understanding of what is cool and not so cool.

Cool:

1. It is much more compact than JavaScript. This translates to up to 1/3 less lines of code than the equivalent JavaScript
2. Offers the concept of classes – something that is familiar for people coming from the Java world
3. Insulates you from JavaScript pitfalls like global scope
4. Some times you can get a performance boost – hard to tell when and by how much
5. Some compile-time error checking, which helps you to write code with fewer bugs right off the bat

Not so cool:

1. Hard to debug. You have to debug the generated JavaScript code and from there you have to trace back to the CoffeeScript code
2. Writing less code can actually be something bad. Anyone remember Perl? And how hard it can be to read Perl code?
3. Adds another layer of abstraction on top of the browser stack. Adding to this jQuery or other frameworks and you can easily be in a situation where you can put together reasonably complex apps but you have no idea of what is happening under the hood nor how to fix a bug that originates from the frameworks you used
4. While I understand from why is done the way it was, I still think it would have been nice to have optional data typing

Maybe not so surprisingly , I’ve seen people coming from OOP languages (Java or C#) that totally love CoffeeScript and this is their preferred way to write JavaScript apps.

As I said, I just played with it. So if I misunderstood something or completely missed a point please let me know.

My colleagues from the Enterprise team were busy updating the Tour de Flex application to Flex 4.6 and they have published it to Android Market and the Apple App Store.

What’s cool about this project is that it is a three-in-one type of product: you can learn how to use Flex, you can experience the performance of the Flex framework on mobile devices firsthand, and you can check the source code and learn how to build awesome mobile projects. Here is the project home page and you can get the source code from here (you’ll need Flash Builder 4.6 to import the project).

And if you’re looking for the app on the stores search fom “Game of Flex” and not Tour de Flex!

I’ve been receiving a number of emails on this topic lately. It seems there is little information out there about how to move from development to production with a Flex and PHP application. Here is a simple checklist that could help you, especially if you are doing this for the first time. Please note that I presume you used the Data Services (wizards) to connect the Flex client to PHP services.

1. Make sure you have Zend Framework on your server. If you don’t, install it
2. Make sure you change MySQL credentials and server IP/name used by your PHP scripts to connect to the database
3. Copy the PHP services folder to your server. Then test these services. If they don’t work check the MySQL credentials or look for dependencies (maybe your PHP services use other PHP classes that you forgot to copy to your server)
4. Edit the amy_config.ini file and make sure the path to the Zend Framework is OK and set production to true
5. Edit the Flex services to point to your live server gateway.php. In the services folder of your Flex project you will find _Super_something.as files. In the constructor you will find a line like this:

   _serviceControl.endpoint = “http://localhost:10088/MobileFlexPHP-PHP/public/gateway.php”;
   Copy that line and then open the class that extends this _Super class and paste the line in the constructor. Then change the URL to reflect your server setup

6. Copy the bin-release/ folder to your server (you should choose the export release for your project; this will create a SWF file smaller than the debug version)

That’s it! If I missed something please drop a comment!

As many of you probably know we made a few announcements last week that are quite interesting – let’s put it that way :). What made things even more interesting for Ryan and me is that we were right in the middle of the tour on mobile development (and we are still on tour for that matter). So we got your feedback first hand.

The good news is that last night the Flex team posted an update that adds more context and details about how Adobe plans to move Flex to Apache Software Foundation. And in short the essence of this update is that we still support Flex and Flash Builder; they won’t go away and we are not killing them. Here are some quotes from the post:

What specifically is Adobe proposing?

We are preparing two proposals for incubating Flex SDK and BlazeDS at the Apache Software Foundation.

In addition to contributing the core Flex SDK (including automation and advanced data visualization components), Adobe also plans to donate the following:

• Complete, but yet-to-be-released, Spark components, including ViewStack, Accordion, DateField, DateChooser and an enhanced DataGrid.
• BlazeDS, the server-based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Flex applications.
• Falcon, the next-generation MXML and ActionScript compiler that is currently under development (this will be contributed when complete in 2012)
• Falcon JS, an experimental cross-compiler from MXML and ActionScript to HTML and JavaScript.
• Flex testing tools, as used previously by Adobe, so as to ensure successful continued development of Flex with high quality

Adobe will also have a team of Flex SDK engineers contributing to those new Apache projects as their full-time responsibility. Adobe has in-development work already started, including additional Spark-based components.
Isn’t Adobe just abandoning Flex SDK and putting it out to Apache to die?

Absolutely not – we are incredibly proud of what we’ve achieved with Flex and know that it will continue to provide significant value for many years to come. We expect active and on-going contributions from the Apache community. To be clear, Adobe plans on steadily contributing to the projects and we are working with the Flex community to make them contributors as well.

You can read the whole post/update here. And drop a comment if you have something to share!

We just launched the Adobe Touch Apps part of the Adobe Cloud. You will find the six apps in the Android Market with one of them being available for iOS too (iOS versions will follow). Just as a quick reminder the six apps are: Collage, Debut, Ideas, Kuler, Photoshop Touch, and Proto.

I think this is great because it was about time we had more apps for tablets that can be used to create digital content. So far developers and companies were extremely good at creating apps for consuming existing content on tablets. As I said many times it is a pity not to be able to create content on your tablet device. I think that with the Adobe Touch apps we are going in the right direction: you can start working on a prototype while you are commuting and all you have is your tablet. Once you get to your computer you can continue your work on the same file. And the synch process between your computer and tablets devices is transparent; it happens auto-magically.

You can read more about these apps here.

This Friday we will host a Flash Camp in our Bucharest office. The event starts at 5:00 PM and will end at 8:00 PM. If you have questions about what was announced at MAX, if you want to find out what’s coming next, or if you want to learn how you can start mobile development with our tools, runtimes, and frameworks then make plans to be there. There are still a few seats left so you can go here and register.

This event is a premiere because for the first time I will have the pleasure of co-presenting  (a Romanian event) with one of my American teammates: Ryan Stewart. So that is another reason to be there :)

And finally, we will have a hands-on session on getting startet with mobile development with Flex, AIR, and Flash Builder. So if you never tried Flex mobile and you want to learn the basics then you have a third reason to be there.

See you Friday!

Registration link.

With almost all the bits and pieces falling nicely in place I can finally blog about the European tour we’ve been working on. Before talking about content, dates, and locations let me say loud and clear “Thank you!” to the people in our community who worked hard to make these events possible and to Magda Neagu and John Koch, my colleagues who gave us all the support we needed.

Why am I saying us instead of I? Because I have the pleasure of doing this tour together with my friend and fellow evangelist Ryan Stewart.

Here is the list:

1. November 3rd – Vienna / Austria
2. November 4rd – Rome / Italy
3. November 7th – London / UK
4. November 9th – Kiev / Ukraine
5. November 10th – Berlin / Germany
6. November 11th – Bucharest / Romania
7. November 14th – Zurich / Swiss
8. November 15th – Dublin / Ireland
9. November 17th – Barcelona / Spain
   1. We will do a session at Barcelona DevCon
   2. We will have a meeting with the local Flex and Flash user group. I will update this post once I have the location and date
10. November 19th – Zagreb / Croatia

If you want to attend one of these events make sure you register today because the number of seats is limited.

In terms of content, we will do a hands-on on mobile development with Flex, Adobe AIR, and Flash Builder. We will also have sessions about mobile development and some of the cool things we announced at MAX. And this will provide you with the perfect opportunity to throw questions at us. Actually let me re-phrase this: it will be the perfect opportunity to ask Mr. Ryan Stewart anything you want to know :).

Last but definitely not the least, if you have a cool project and you want to show it to us, please don’t be shy. Come to us after the event or during one of the breaks and we will listen to you. We always love seeing the great stuff you build and listening to your feedback. If you are reading my blog you know that from time to time I blog about cool apps and projects.

PS. If you plan to attend one of our hands-on sessions then you should have Flash Builder installed on your laptop. Also, if you have an Android phone you will be able to run all the examples on your device too (you will need a USB cable to connect the device to your laptop). Otherwise you can use the Flash Builder desktop simulator.

The latest release of the Chrome browser (15 was launched last night) makes Chrome the first browser that offers support for the CSS Regions feature. This is really amazing as the story has been developing for a little bit more than a year: from the initial idea, to the first proof of concept, then working with the standards bodies and WebKit, and finally to Chrome 15.

If you have the latest Chrome on your machine (should work on both Windows and Mac OS) you should be able to test this page. Just play with the size of your browser window and you should see how the text fills the three different columns.

PS. Just talked to the Adobe engineers that work on this and they told me that there might be a small glitch with how the text flows sometimes. But this has been already been fixed in the main line. So probably the next update of the Chrome will pick up this change.

Later Update: Peter Elst dropped me a message telling me that the CSS Regions examples we host on Adobe Labs don’t work in Chrome 15. This is true and normal at the same time. The examples we have there represent one of the first drafts of CSS Regions. Since then the syntax has changed. This is why I included a page for test in my post.

Later Update 2: Someone told me that Internet Explorer 10 already supports CSS Regions. This is true, but IE 10 is a pre-release version while Chrome 15 is a “production” ready release.

We just released Flash Player 11.2 Beta and Adobe AIR 3.2 Beta on Adobe Labs. The main features for this release are:

Multi-threaded video decoding (Windows, Mac OS, and Linux) — The video decoding pipeline is now fully multi-threaded. This feature should improve the overall performance on all platforms. Note that this feature is a significant architecture change required for other future improvements.

Flash Player background updates (Windows) — New versions of the runtimes can now be delivered more effectively to the end user with this enhanced updating mechanism (Background update is only available in the release versions of Flash Player).

From the release notes some additional info on the multi-threaded video decoding feature:

Multi-threaded pipeline was written grounds up to support lower end devices and full hardware stacks where all the decoding and rendering isoffloaded to hardware. The benefits of the modernization of the pipeline would be visible from mobile devices, tvs, netbooks to high end desktops.In Flash Player 11.2, the new video pipeline is available for desktop platforms (including netbooks ) and brings enhancements with respect to:

• Eliminating jitter seen occasionally in some encoding and typically in live streams and real time interactive scenarios.
• Gains in frame rate by reducing dropped frames as much as 50% on certain platforms with high bit rate content.
• Seek frame accuracy.
• High resolution/bit rate content decoding would still keep the player UI responsive and any background ActionScript processing going,which earlier could have experienced brief halts because all the decoding and player UI/ActionScript resided on the main thread. For HTTP streaming, ActionScript is the control point of fetching the stream data and delivering to the video stack. On seek, earlier thestreaming would halt, while the frames up to the point of seek would be getting decoded. With multithreaded video decoding, not onlywould the seek be more responsive, but it would also start playback faster after seek.
• 50+ fixes as part of the modernization of the video pipeline architecture

Is this cool or what?

This week I’ll be at the ZendCon PHP Conference in Santa Clara. I will have a session on Flex and PHP mobile development for iOS, Android, and PlayBook on Thursday starting at 9:15 AM.

If you plan to attend this conference make sure you drop by to say hello. We will have a booth in the exposition area next to Zend’s booth.

I’m really excited to be part of this conference. First, it is my first PHP conference in the States – so far I’ve been speaking only at European conferences. And second, it has been a while since my last PHP conference. I think I will have a great time catching up with what the PHP community is doing these days. I already picked up some sessions that I’m sure will blow my mind :)

Now straight to the airport! A long trip awaits me!