Contact me at : hello[at]gauravjassal[dot]com
Multi touch is a method of interaction with a computer screen or your smartphones like iPhone or Palm Pre. Its allows the user to interact with your device by placing one or more than one finger on the screen. The multi touch intraction have become very popular these days because of products like Apple iPhone .
Now Adobe Air 2 will also support Multi Touch to explore new techniques for interacting with software and devices with latest capabilities of Flash Platform. In multi touch there are two input mode : Gesture and touch. Gesture mode enables you to use predefined/built in gestures using GestureEvent and TransformGesture event. This includes logic for pinch, zoom, rotate, pan, two finger tap, etc. The gestures enable you to quickly and easily add gestural logic to your applications. Touch mode allows you to get access to low-level touch events using the TouchEvent class. This enables you to create custom gestures or actions for your applications.
I found one presentation by Andrew Trice from Cynergy System talking and demonstrating about Multi touch development with flex at Max 2009. It’s a 58 min presentation so sit back and watch the complete the presentations.
Here is another video of Adobe Air 2 demonstration.
I am not sure when it is going to be official released but I guess its will be early next year same time Adobe release Flash CS5. I can’t wait for it to get release I already have loads for applications in my mind. If you want to be among the first to test the public beta of AIR 2.0, all you have to do is to sign up over here.
Here’s the list of new features I found after reading some blogs online.
Beta version of Flash builder 4 and Flash catalyst is available now. I am very excited to use the new feature of both the software’s. I have seen alot of presentation on flash catalyst now its the time to use the newest tool for RIA development.
 |
 |
Flash builder and Flash catalyst can develop from Adobe lab. Here are the links and
To help you get started, we’ve created a bunch of tutorials and samples to get you going. I’ve just listed a couple of them here. For more tutorials and samples, check out the Adobe Developer Connection. Also there are two video tutorial available on Lee Brimelow’s website Flash Catalyst and Flex 4: Part 1 and Flash Catalyst and Flex 4: Part 2
Recently i was doing reading on using itemRenderer in Flex. I found it interesting and very very useful for application development. All Flex list components are derived from the ListBase class, and include the following controls: DataGrid, HorizontalList, List, Menu, TileList, and Tree.
A list control gets its data from a data provider, which is a collection of objects. For example, a Tree control reads data from a data provider to define the structure of the tree and any associated data that is assigned to each tree node.You can think of the data provider as the model, and the Flex components as the view of the model. By separating the model from the view, you can change one without changing the other. (more…)
Farata Systems, a world leader in the RIA space has open sourced their Clear Toolkit framework for developing enterprise Rich Internet Applications with Adobe Flex and Java. The latest builds and the source code of Clear Toolkit 3.1 are located at http://sourceforge.net/projects/cleartoolkit/ . The current documentation, demos, user forums, and bug trackers are also there. (more…)
When you develop a actionsction 3 component its good to compile the component to .swc file and reuse it in different projects. To create a SWC file, use the compc compiler in the flex_install_dir/bin directory. The compc compiler generates a SWC file from MXML component source files and/or ActionScript component source files.
In this example, you create a SWC file for a custom formatter component that you defined by using the following package and class definition:
package com.gauravjassal.controls.TwitterList
{
//Import base Twitter class.
import mx.controls.Label
public class TwitterList extends UIComponent{
...
}
}
You use the following compc command from the flex_install_dir/bin directory or flex_builder_director/sdks/sdkversion/bin to create the SWC file for this component:
.\compc -source-path c:\flex\wamp\www\Twitter\src\ -include-classes com.gauravjassal.controls.TwitterList -o c:\flex\wamp\www\Twitter\TwitterList.swc
What makes a truly great developer? Some might say a positive attitude. Some might say a high-sugar, high-caffeine, high-bacon diet. Some might say an absence of sunlight and as many monitors as a desk can support.
Certainly, everyone has anecdotes about developers they’ve worked with who they thought were brilliant. Unfortunately, most of the time that judgement is made not based on code quality, or hitting of deadlines, but on less relevant criteria, like whether or not the developer knew the names of their colleagues, how many lines of code they output or how confident they sounded when talking about their work.
Unfortunately, the best developers don’t always come across positively. While this list may not be applicable to every development environment, here are a few of the traits to look out for to spot a great developer.
Pessimistic
Great developers are almost always pessimistic with regard to their work. That doesn’t mean they’re not upbeat, lively or even cheerful – just that they will always be thinking about what can go wrong and how it can be dealt with.
They’ll assume that at some point they’ll need to undo work already completed, that hardware will fail, that all security will be compromised, and that your office will burn to the ground. The really brilliant ones will assume that will all happen on the same day. And they won’t be happy until there is a specific, actionable, testable – and fully tested – plan for dealing with these sorts of issues. Even then they won’t be completely happy.
Pessimistic developers will be the ones that find constant flaws in ideas, and the important thing to remember when working with them is that they’re not doing that to tear down other people’s ideas – they’re doing it to ensure that the ideas that turn into projects are properly thought through and that as many problems as possible have been anticipated in advance. That neurotic, paranoid, pessimistic attitude is exactly what you should be looking for if what you want from your developers is robust, secure, reliable code.
By contrast, an optimistic developer will be more likely to simply assume code will work, or that it is secure, or give a deadline for a project without considering all the potential pitfalls.
Likely to be heard saying: “And what happens when that goes wrong?”
Lazy
Laziness is not usually viewed as a desirable trait, and in this case I don’t mean turns-up-late-and-pretends-to-work laziness or just-move-that-logic-to-the-view laziness – both entirely unwanted. I mean a desire to not do tasks that are repetitive, or to waste time doing things a machine can do for you, or even to avoid future work by writing better code now. A lazy developer is one that builds a reusable code library, or wants a fully automated build process rather than a manual copy-and-paste one, or wants comprehensive automated unit testing, or writes code to be scalable even though that wasn’t a requirement (rather than revisit it later).
As a bonus, a lazy developer is also usually one who will try and keep a project focussed on its core goals, rather than try and cram more work into the same time, providing a buffer against feature creep.
For example, when writing a category structure, a lazy developer might be likely to assume a many-to-many relationship between parent and child categories, even though the project specification says it will be a one-to-many relationship. Why? Because it might be needed one day and it would be better to write it that way from the start than to revisit it later.
Likely to be heard saying: “We could automate that.”
Good developers are often rather like Gregory House. They’re very easily bored by repetitive work (see laziness) and spend most of their time ploughing through it looking for an interesting and challenging (and hopefully new) problem to solve. The less time they can spend on the repetitive, the higher the frequency of the challenges.
Curious developers will be constantly looking for new problems to solve, and better ways to solve previous problems. They’ll be the ones encouraging new ways to work and constantly tweaking and trying to improve existing systems. They’ll also be the ones most conscious of existing problems in the current working environment, and trying to correct those problems. Curious developers will usually have a wide breadth of knowledge, not just of their primary language(s), but of supportive, associated and alternative technologies.
Curious (or easily-bored) developers are often the least stuck in their ways – the most open to change. They may well need convincing of why a new way of working is better (and that’s no bad thing) but as long as it’s an improvement, and likely to release more time to spend on the interesting problems, they’ll embrace it with a minimum of resistance.
Curiosity also breeds creativity, another highly desirable trait in any developer. A strong desire to work out what has caused a problem and how to solve it is highly likely to motivate someone to continue once obvious avenues are exhausted. It is that sort of mentality that fosters “outside the box” thinking and creative coding.
Possibly the most useful attribute of a curious developer is that desire to find and cure a problem rather than just paper over the crack.
Likely to be heard saying: “Maybe there’s another way to do this.”
Many great developers are sticklers for detail. They will demand consistency in their work and the work of their team (they’re likely to care about common code standards and naming conventions, for example). They’ll want unit testing and peer review of code. They’ll want everyone in their team to comment on and document code. They are likely to be fussy about version control log messages.
They’ll also be fussy about details in communication, and happy to ask what might seem like obvious questions, simply to be sure they have properly understood. This is especially true of things like bug reports. While they may not be terribly motivational communicators, they will usually be able to explain concepts clearly and effectively. That clarity is a tremendous advantage in any development environment, especially if teaching and learning are encouraged.
Likely to be heard saying: “I just have a couple of questions …” I’m lazy, a little bit pessimistic, too much curious and meticulous: i’ll be a GREAT developer! soonn………..
I think this is the best article to judge how great developer you are.This article is from ILoveJackDaniels.com.
http://www.ilovejackdaniels.com/blog/what-makes-a-great-developer
Errors
One thing you may notice about ActionScript 3 how error prone it is or, rather, how error prone it perceives you to be. You’ll see a lot more errors, not only during compile, but also runtime. ActionScript 3 is much less lenient in letting you get away with mistakes or code conflicts. Whereas ActionScript 1 and 2 may silently fail or ignore many errors, ActionScript 3 will be sure to let you know something went wrong.
Synchronous Errors
Normal errors in code which occur as a code block is being executed are synchronous errors. When the Flash player encounters one of these errors in code, an error, or exception, is thrown. At that point the Flash player will suspend all code in the current block and prevent it from continuing unless the exception is taken care of or caught. To catch exceptions in ActionScript, you use a try..catch..finally statement.
The try..catch..finally statement lets you try a block of code possible of throwing an error and react accordingly if an error occurs. It consists of 2 or more blocks of code: an initial try block, consisting of the code that could throw an error, 1 or more catch blocks that catch errors of different types and run if that type of error is thrown, and an optional finally block which is run after the try and any catches whether or not an error occurs. Its format is as follows:
try {
// potential error causing code
} catch (error:Error) {
// error of type Error occurred
// additional catch blocks may follow
} finally {
// optional to follow try and catch blocks
}
If an exception is thrown within a try block, Flash will look through each catch block until a matching error type is found. When a match is found, that code is run followed by the finally block if it exists. Any additional code following a try..catch..finally statement will be executed as normal even if an error occurs because it was caught by the try..catch..finally statement.
Throw custom errors
Errors are not thrown exclusively by Flash. You also have the ability to throw errors in your own code if you so desire. To throw errors you would use the throw statement. The throw statement throws any value that precedes it (namely an Error object). When thrown, the error will act just like any error and would require a try..catch..finally block to be correctly caught.
// Throwing your own errors in ActionScript throw new Error(”Error message”);
Throwing your own errors can be a helpful debugging tool, especially as you work with more complicated applications.
Asynchronous Errors
Errors can also occur during asynchronous actions, such as loading external content, and take the form of events. These errors cannot be caught with try..catch..finally statements. Instead you have to create event handlers to handle and “catch” the error events. If you do not have an event listener assigned to an error event and that error occurs, the Flash player will inform you of the unhandled error event.
// creating listeners for error events handles
// asynchronous errors
target.addEventListener(ErrorEvent.TYPE, handler);
function handler(event:ErrorEvent):void {
// handle error
}
Creating Asynchronous Errors
If you want to invoke your own asynchronous errors, all you need to do is dispatch an event using dispatchEvent that is of the type ErrorEvent. When an unhandled ErrorEvent reaches the Flash player when authoring in Flash, the output window will display the error.
// target object is an event dispatcher // that needs to dispatch an error event target.dispatchEvent(new ErrorEvent(”type”));
Release and Debug Players
The release of the Flash player is available in two versions, the release and debug. The release player is the standard, public player. This player is what you will have installed for your browser(s) when you download and install Flash player from adobe.com.
The debug player is an alternate player with additional debug information and capabilities embedded within it. This makes the player a little heftier in file size (which is why its not preferred for distribution) but also provides popup dialogs for uncaught exceptions and unhandled asynchronous errors – something the public would rather not see when your Flash movie or application runs into a snag. For developers, however, this player provides useful information when testing your movies.
You can find installers for both the release and debug players in the Players folder within your Flash CS3 (or older) install directory.
One thing to keep in mind is that just because the release player doesn’t visually show an error when an exception is thrown, it doesn’t mean that error line is simply ignored like with previous versions of ActionScript. The code block where that error occurred will be exited and the remaining script ignored.
Example: Loading external text with error handling
To load text content from an external source into the Flash player, you would use the URLLoader class. An instance of URLLoader will load a text file into its data property to be read as a string. Because the process of locating, downloading, and reading an external file into the Flash player takes time, events are used to indicate when the content has been loaded and is available. Not only that, events are used to indicate loading progress and also any errors that occur.
The URLLoader class uses the load method to start the loading process which is also capable of throwing exceptions of many different error types. When using the URLLoader class to load external content, its always best to listen for all asynchronous errors as well as call the load method within a try..catch..finally statement.
// load textfile.txt text into loader instance
var request:URLRequest = new URLRequest(”textfile.txt”);
var loader:URLLoader = new URLLoader();
// listen for complete event (and others if desired)
loader.addEventListener(Event.COMPLETE, loadComplete);
// listen for error events
loader.addEventListener(IOErrorEvent.IO_ERROR, loadIOError);
loader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, loadSecurityError);
// complete event handler
function loadComplete(event:Event):void {
trace(loader.data); // textfile.txt contents
}
// handler for IO error
function loadIOError(event:IOErrorEvent):void {
trace(”IOError: “+event);
}
// handler for security error
function loadSecurityError(event:SecurityErrorEvent):void {
trace(”SecurityError: “+event);
}
// try the load operation and
// catch any thrown exceptions
try {
loader.load(request);
}catch (error:ArgumentError){
trace(”ArgumentError: “+error);
}catch (error:MemoryError){
trace(”MemoryError: “+error);
}catch (error:SecurityError){
trace(”SecurityError: “+error);
}catch (error:TypeError){
trace(”TypeError: “+error);
}catch (error:Error){
trace(”Unknown Error: “+error);
}
In the above example, each error event has its own listener tracing the error if an error occurs during loading. Additionally, each type of error thrown by the load operation is being checked within respective catch blocks. An ending catch with the type Error is used in case there was an error thrown not within the other catches. Then that final block would catch the error no matter what it was. And really, you could just have one catch of the type Error to handle all error events. Similarly one event handler could be used for all error events. In doing this you can still catch and handle all errors but it would involve less code.
// load textfile.txt text into loader instance
var request:URLRequest = new URLRequest(”textfile.txt”);
var loader:URLLoader = new URLLoader();
// listen for complete event (and others if desired)
loader.addEventListener(Event.COMPLETE, loadComplete);
// listen for error events using one handler
loader.addEventListener(IOErrorEvent.IO_ERROR, loadError);
loader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, loadError);
// complete event handler
function loadComplete(event:Event):void {
trace(loader.data); // textfile.txt contents
}
// handler for errors
function loadError(event:ErrorEvent):void {
trace(”Error: “+event);
}
// try the load operation and
// catch any thrown exceptions
try {
loader.load(request);
}catch (error:Error){
trace(”Error: “+error);
}
Here, all errors are still accounted for but less code is involved.
Note that the event parameter of the loadError method is typed as ErrorEvent. Just like all errors thrown by Flash are also of the type Error as well as their own type (their classes extend the Error class), the event errors are also of the type ErrorEvent. By typing the event parameter as ErrorEvent, you can be sure that whatever type of error occurs, it will correctly match with the type of event used in the event handler.
Previously i posted a very useful class to categorize multi-dimensional array. I wrote another one that is just an alternative for array_unique function.
This extension notifies you with latest London underground tube updates. You can click on the browser button and check the status of any tube line.By default the extension updates the status in every 5 mins.
In the second example I am going to use Standard PHP Library (SPL) to notify all attendees about the party location change. SPL has 2 interfaces and a Class for Observer.
© 2008
Gaurav Jassal
