Announcing a series of web conferences organized by Adobe Romania

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.

January 16, 2012 | Filed Under Conferences | Leave a Comment

Getting Started with PhoneGap resources

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:

January 13, 2012 | Filed Under Video | 3 Comments

Debugging web pages remotely using a PlayBook tablet

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.

January 12, 2012 | Filed Under JavaScript, Tutorials | Leave a Comment

Canvas Quirks

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.

January 12, 2012 | Filed Under Canvas, JavaScript | Leave a Comment

Debugging Web Pages and PhoneGap apps on mobile devices

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).

January 10, 2012 | Filed Under HTML, JavaScript, Tutorials | 1 Comment

Happy New Year!

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:

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.
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!

January 4, 2012 | Filed Under Others | 2 Comments

CoffeeScript or JavaScript?

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:

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

Not so cool:

Hard to debug. You have to debug the generated JavaScript code and from there you have to trace back to the CoffeeScript code
Writing less code can actually be something bad. Anyone remember Perl? And how hard it can be to read Perl code?
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
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.

December 11, 2011 | Filed Under JavaScript | 2 Comments

Tour de Flex is available for iPad now

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!

December 9, 2011 | Filed Under Flex | Leave a Comment

Steps to deploy a Flex and PHP application

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.

Make sure you have Zend Framework on your server. If you don’t, install it
Make sure you change MySQL credentials and server IP/name used by your PHP scripts to connect to the database
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)
Edit the amy_config.ini file and make sure the path to the Zend Framework is OK and set production to true
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
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!

December 9, 2011 | Filed Under Flex, PHP | 5 Comments

The future of the Flex framework

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.