Rich Internet Applications

Reasons to Love Flex

Flex was designed in order to give Flash Developers an edge when developing Rich Internet Applications (RIAs). Although RIAs can be built from within Flash, there are various limitations, especially when it comes to a developer’s time.
One of the major reasons why Flex is becoming more and more popular is because it utilizes ActionScript 3.0. One important thing to note is that the Flex environment does not use a Timeline. This does not mean that it is limited. Rather, Flex has been developed more for programmers and less for designers.

Let’s take a look at the reasons to love to develop RIAs (Rich Internet Applications) in Flex.

  1. Flash is everywhere — The Adobe Flash 9 Player has about 98% market penetration across browsers. This means that when you launch an application on the Web, you are virtually guaranteed that anyone will be able to use it. Compared to the distribution statistics of other RIA runtimes, there is simply no contest.
    Flash is cross-OS, or “platform-agnostic”: it runs in Windows, Mac and Linux. It is also installed in every type of browser, making it the only RIA technology that can truly claim to be a “write once, run everywhere” platform.
  2. Flex = Flash on steroids — Flex is Flash and Flash is ActionScript 3.0 (or more specifically, Flex runs on the Flash Player, and the Flash Player’s language is ActionScript 3.0.)
    In ActionScript 3.0 you have all the aspects of a mature, robust programming language: strong runtime typing, class inheritance, interfaces, error handling, a built-in event model, sealed classes, method closures, custom namespace accessors, regular expressions, E4X. The Flash Player incorporates the Tamarin ActionScript 3.0 Virtual Machine with the power of a Just in Time (JIT) compiler, which interprets SWF application bytecode into machine-level instructions so that your code runs as fast as the processor can handle. Warp speed, Scotty!
    And since Flex is built on top of Flash, you have the full power of the Flash APIs to draw in real time with lines, gradients and fills and manipulate and animate vectors, bitmap data, and visual assets, complete with matrix transformations, programmatic Photoshop-like filters, and blends. Flash allows communication using a dizzying array of data formats, but if you don’t find the format that suits your needs, create your own using a binary socket and custom interpreter! You also get high-definition, full-screen, hardware-accelerated video capabilities, supported by enterprise-capable video encoding and streaming server products.
    Flex 3 adds another layer of power onto the Flash runtime: a visual markup language called MXML, and a full-featured compiler that includes compiler metadata and data binding. The Flex framework adds class libraries for natively managing HTTP requests, RPC services, and Web Services, a dizzying array of visual UI components, a deep linking framework for browser integration, an API for AIR applications that can interact natively with the desktop, logging and unit testing frameworks, and much much more, all of which will be covered in this book. Not to mention an IDE based on Eclipse, and a whole suite of server tools for your application to communicate with the backend using native ActionScript class objects.
  3. Flex is open source — The Flex Software Development Kit (SDK), which comprises the compiler, the component framework, and several other tools, is a free, open-source development platform. Although Flex Builder is neither free nor open source, it is built upon Eclipse, and can be installed standalone (with Eclipse built in) or as an Eclipse plug-in alongside other Eclipse development environments. In fact, Adobe Flex Builder has been voted Best Open Source Developer Tool for RIAs by InfoWorld’s Best of Open Source Software Awards.
  4. Interoperability — ActionScript 3 has XML baked into it as a native format with E4X parsing capability, facilitating JSON and XML data transfer. The Flash Player is able to interface directly with JavaScript in the browser through a native JavaScript communications API, and is able to recognize SWF filename query name-value pairs. Two great examples of Flash-AJAX interoperability are Google Finance and Yahoo! Maps Canada, both of which combine the versatility of an enhanced hypertext application with the interactive power of the Flash runtime.
    The Flash Player also includes XML and binary sockets capability, including traditional GET and POST HTTP requests.
    The Flash Player natively supports image file formats GIF, JPG, PNG, media file formats MP3, FLV, F4P, F4A, and F4V, including the AAC, MP4, M4V, M4A, 3GP, and MOV multimedia container formats, encoded in Sorenson Spark, On2VP6, H.264, MPEG-4, MP3, or AAC.
    The Flash Platform also enables some unique RIA communications protocols. Connected to the Flash Media Server, the Flash Player is also able to stream video and audio using the RTMP protocol, and its rights-encrypted cousin RTMPE, as well as the new RTMFP format in Flash 10. Using the Adobe AMF protocol, the Flash Player is able to communicate complex ActionScript objects directly with data services applications on the server. Adobe LiveCycle Data Services and its open-source cousin BlazeDS enable bidirectional ActionScript-to-Java object transfer, and the ColdFusion server allows for ActionScript-to-CFC object transfer. Third-party data service implementations such as WebOrb, AMFphp, and Zend enable native ActionScript object communication with the.NET and PHP server languages. Other third-party data services solutions exist for languages such as Ruby and Python.
    The Flex framework contains APIs that allow very easy deployment for HTTP requests, Web Services, and RPC services data transfers. So needless to say, a Flex application can communicate a wide variety of web technologies, allowing for a plethora of server integration options with an impressive array of interoperability with many data formats, languages, and protocols.
  5. The community — Conceived with the same spirit as the Flash community, the Flex community is passionate, generous, and vibrant, always coming up with new ways to alert each other of the latest quirks, share their discoveries, their tips, their components, and their experiments, helping Adobe make a better product. And Adobe does an incredible job of feeding that fire: it actually listens to the community, and rewards them with changes to product development that directly reflect what designers and developers has been asking for, going so far as to organize events and surveys that elicit feedback for the sole purpose of making Flash and Flex better and better. One has only to look at all the new features in Flash Player 10 and those planned for Flex 4 to know that Adobe has listened to and cares about its community. Many Flash and Flex designers and developers, including the writers of this book, really enjoy what they do for a living, and thrive on that energy. And this level of passion and commitment to each other and to the evolution of the platform shows through in every Flash and Flex conference, every technical blog, every community forum and list this author has ever visited.
  6. Creative Suite integration — When Adobe purchased Macromedia in 2005, it brought to the Flash and Flex development scene the possibility of the full force of its Creative Suite of applications. As of Creative Suite 3, we can now experience the fruits of that promise, as we now have seamless integration between Flash and Illustrator, Fireworks and After Effects. This opens up a vast sea of creative possibilities for Flex development, enabling even “richer media” applications than ever before. See Chapters 26 and 29, which cover Flash and Flex workflow integration in greater detail.
  7. Flex enables modular, rapid application development (RAD) — Flex natively encourages a Model-View-Controller (MVC) separation of application parts through the use of MXML, which is an XML-based visual layout markup language that facilitates rapid prototyping and development (see Listing 1-1 for details). In the simplest Flex MVC pattern, the View or interface layout is typically coded in CSS and MXML, and the Controller or application logic is typically coded in ActionScript, though one is not constrained to these norms. This will be covered in greater detail in Chapter 60, “MVC Frameworks.” Flex Builder also has a Design View, which allows for the visualization of MXML layouts, and a Properties View, which allows for the setting of inspectable component properties directly in the IDE (see Chapter 5, “Introduction to Flex Builder 3,” for details).
    Flex also enables a variety of modular compilation and deployment methods. You can pre-compile application modules or class libraries to increase compilation efficiency, code distribution, or asset management. By compiling all your fonts into one module, and all your skins into another module, for example, you cut down overall application compilation time and increase asset management efficiency. You can compile SWFs to be compiled in the main application as embedded assets, which can be easier to use than Flex modules, or you can opt to load SWF application subcomponents at runtime, decreasing the initial application filesize.
    The application footprint can also be mitigated by the use of persistent framework caching, where you can compile your application sans the Flex framework, allowing the Flash Player runtime to preload and cache the framework as a separate class library on the client. This means that after the Flex framework has been downloaded once, it is cached on the client, and your application will load much quicker for the user. See Chapter 66, “Modular Application Development,” for details.
  8. Adobe AIR — AIR brings the power of Flash and Flex to a whole other level. With AIR, AJAX applications can be deployed to the desktop, or a Flash/Flex application can be deployed to the desktop, in either the PC, Mac or Linux OSs, with access to system windowing and local file system interactivity. Or even more powerfully, both AJAX and Flash can be leveraged together in the same application, in ways that could never be done in a conventional browser environment. You can apply Flash bitmap filters and tweens directly onto an HTML object, or have a JavaScript object communicate directly with an ActionScript object without the intermediary of a communications format. This enables the development of flexible, “sometimes connected,” desktop solutions that have not previously been possible in the realm of RIAs.
  9. Seeing is believing — But don’t take our word for it. Check out some Flex and AIR applications yourself. Have a look at some of the showcased applications, and you’ll see exactly what we mean:
Web 2.0

Advertising and Brand Building with Social Networks

Social media encompass communication possible throughout all of the forms of social communities online. Social-media communities include forums, virtual worlds, social news organizations, social opinion sharing sites, and social networks. Social networks are built around site platforms that enable members to develop identity profiles, interact with other members, and participate in various site activities. Social networks are 2D environments with identity representation limited to one’s profile rather than by visually detailed avatars common to virtual worlds.

Although interactions with others can seemingly approximate synchronous real-time communication, the messaging structure is static rather than dynamic. Networks can be thought of as utility-based tools. They are an elegant but fun way to organize content, socialize, and promote one’s self-identity. Despite this, social networks have grown in popularity from their ability to provide a platform for information sharing, communication, and relationship development and maintenance. In a world where individuals may have reduced physical contact and heightened time spent interacting with electronic devices, social networks have evolved to provide an online platform for personal, intimate, informal neighborhood and office chatter. They offer a sense of ‘‘contact comfort’’ in a society where many of us spend less time with actual people than we do with machines.

Contact comfort helps to meet individual needs for affiliation and socialization. Social networks meet our need for contact comfort while also providing entertainment and information sharing.

Social networks are above all else communication hubs. While they all offer the core product of networking capabilities, networks do find ways to differentiate themselves. MySpace and FaceBook support relationship building and maintenance. YouTube offers a venue for sharing and promoting videos and related opinions. Flickr enables photo sharing and reviewing. LinkedIn provides a form of self-promotion and career networking.

There are niche sites as well focused on any number of hobbies and personal interests. Catster, for example, offers tips and information on caring for one’s feline companion with the added benefit of being able to talk with others who define themselves in part by the pets they love.

Social networks, like other online communities, are participatory, conversational, and fluid. Members produce, publish, control, critique, rank, and interact with online content. On FaceBook, for instance, the second most popular social network, members can build a profile that includes information about their education, habits, favorite movies and books, and other personality indicators. They can send and receive messages to members, ‘‘friend’’ people, and join groups and networks.

Profiles can be complemented with pictures, news feeds on member activities (e.g., Tracy just went shopping), and a variety of widgets. Widgets are small applications made up of code embedded on a Web site. FaceBook widgets enable members to virtually hug, wink, smile, and engage in a host of other behaviors. Most sites offer similar features, with messaging, profiling, and friending being the core functions of any network site. The interaction with others enhances the need to return to the site and continue the process of generating new content. The result is an online community of friends who may spend hours in the network each day.

Web 2.0

Ten Things You Should Do to Make Your Business More Web 2.0

These ten ideas are meant to be practical, relatively easy steps that could benefit almost every website, whatever its mission (including nonprofit missions). Some ideas are more relevant to organizations that sell products or services, generate advertising revenue, or generate business leads. But whatever your model is, if you want to embrace some of the cultural and technical trends of Web 2.0, these are great places to start.


eCommerce merchants are in a touchy position when it comes to making Web 2.0 innovations, because they must weigh any hoped-for gain against both the cost of implementation and the potential cost of confusing or distracting visitors from the task of finding and buying products.

Probably that’s why the Web 2.0 features that are enjoying the fastest uptake on ecommerce sites are ones with clear connections to improving the purchase conversion rate:

·         Enhanced product images

·         Product reviews and ratings

·         Personalization

·         Live customer-service chat

Some Web 2.0 innovations seem promising, but aren’t for everyone— for instance, they may demand too much time from a typically brief user session. For social-media features to be successful, you must operate in a market that stirs people’s passions enough to get them interacting with their online social circle. For mobile applications to benefit you, your offerings must be a natural fit for on-the-go customers.


Before testing, you have to identify what “best” outcomes mean to you. If you’re selling products, you’ll look for increased sales conversion rates, or average order value (or both!). If your site is ad-supported, your goal may be to increase visits, page-views, and visit duration. Social-media features might be weighed in terms of repeat visits, and traffic coming from referrals to friends. And you’ll also want to track the numbers most directly associated with your Web 2.0 initiatives: How many people are posting and reading product reviews? How many are establishing profiles, what is the average number of friend links, how many forum postings, RSS subscriptions, visits to your .mobi site, signups for your mobile text messaging program, links into your site from the blogosphere? To spot trends, you should track some metrics not just in their raw numbers, but also as a portion of the total. For example, what portion of all customers are registered users? What percentage of business leads is coming from the mobile site?


Following are the 10 important ideas –

  • Idea 1. Participate in Your Relevant Online Community
  • Idea 2. Launch Customer Ratings and Reviews
  • Idea 3. Add Value for Customer Registration
  • Idea 4. Create Valuable Content and Set it Free
  • Idea 5. Enhance Your Branding and Security Messaging
  • Idea 6. Deploy Web Analytics and A/B Testing
  • Idea 7. Segment Your Loyalty eMail Program
  • Idea 8. Push Channel Integration
  • Idea 9. Position Yourself in Mobile Media
  • Idea 10. Design Your Personal “Killer App 

Letting Go


To let go doesn’t mean to stop caring. It means I can’t do it for someone
else. To let go is not to cut myself off. It’s the realization that I
can’t control another. To let go is not to enable, but to allow learning
from natural consequences.

To let go is to admit powerlessness, which means the outcome is not
in my hands. To let go is not to try and change or blame another, I can
only change myself. To let go is not to care for, but to care about.

To let go is not to fix, but to be supportive. To let go is not to judge,
but to allow another to be a human being. To let go is not to be in the
middle arranging all the outcomes, but to allow others to affect their
own outcomes. To let go is not to be protective, it is to permit another
to face reality

To let go is not to deny, but to accept. To let go is not to nag, scold, or
argue, but to search out my own shortcomings and correct them.
To let go is not to adjust everything to my desires, but to take each
day as it comes and cherish the moment.

To let go is not to criticize and regulate anyone, but to try to become
what I dream I can be. To let go is not to regret the past, but to grow
and live for the future. To let go is to fear less and love more

~Author Unknown



One night a man had a dream. He dreamed he was walking

along the beach with the God. Across the sky flashed scenes

from his life. For each scene, he noticed two sets of footprints in

the sand: one belonging to him, and the other to the God.


When the last scene of his life flashed before him, he looked

back at the footprints in the sand. He noticed that many times

along the path of his life there was only one set of footprints.

He also noticed that it happened at the very lowest and saddest

times in his life.


This really bothered him and he questioned the God about it.

“God, you said that once I decided to follow you, you’d walk

with me all the way. But I have noticed that during the most

troublesome times in my life, there is only one set of footprints.

I don’t understand why when I needed most you would leave



The God replied, “My son, I would never leave you. During

your times of trial and suffering, when you see only one set of

footprints, it was then that I carried you.”


Author: Mary Stevenson Parker 

Pre Sales, Software Services

Proposal Building Process in Presales

Based on the size and/or complexity of the project, the study effort may vary. The typical process steps for conducting a requirement study and proposal building are outlined below. These steps are often being conducted concurrently, iteratively and, in fact, some steps may be omitted entirely, depending on the complexity and criticality of the effort. Process steps include:

  1. Determine requirements for the study
  2. Determine objectives, scope and approach, and plan the effort
  3. Conduct a current state assessment
  4. Identify potential solutions
  5. Determine the feasibility of each option
  6. Document and communicate the results of the requirement study, and obtain approval to estimate development for the recommended solution


1.       Determine Requirements for the Study: Business Problem or Opportunity

Requirement studies are used to determine the approach to solving a business problem or seize a new business opportunity, the approach is slightly different. In the case of a business problem, the Business Analyst first determines and documents the problems faced by the organization and the potential areas of study required to address the issues. The analyst then conducts root cause analysis to determine the full nature of the problem, the actual cause (or causes) of the problem, the adverse impact it is having on the business and the criticality and required timing of the resolution.

To take advantage of a new business opportunity, the analyst defines the opportunity in as much detail as possible to understand the scope and determine the nature of the study. This information is then used to determine the methodology or approach to be undertaken to complete the study. For each business problem and/or opportunity, the analyst drafts a requirements statement describing the business need for a solution.

2.       Determine the Objectives, Scope and Approach and Plan the Study Effort

To plan the requirement study effort, the Pre-Sales/Business Analyst first assembles a team of skilled resources who collaboratively perform the following tasks:

2.1   Establish specific, measurable objectives that the recommended solution must meet. These objectives provide the basis for formulating options for consideration.

2.2   Develop benefit criteria upon which alternative solutions will be evaluated in the form of quantitative measurement criteria by which to judge the success of the investment in the recommended solution.

2.3   Define scope of activities to be performed during the study.

2.4   Define deliverable(s) to be produced from the study; if it does not exist, develop a template for the final proposal document.

3.       Conduct a Current State Assessment

The study team conducts a limited amount of internal analysis when initiating the requirement study. These may include review of business objectives, strategy and vision; analysis of current business processes; and assessment of current (as-is) and future (to be) documentation. The current state assessment consists of a review of all or part of these elements, depending on the nature and scope of the study:

3.1   Strategy – Review the business vision, strategy, goals and measures.

3.2   Business Area – Describe the mission of each line of business or business unit that is a stakeholder for the area under study, and collect relevant organizational charts.

3.3   Locations – Document the physical location of each impacted business unit.

3.4   Data and Information – Identify the major types of business information required. It is also helpful to list the repositories which retain the information listed.

3.5   Infrastructure – List each of the current business technologies impacted by the initiative.

3.6   Processes – List and provide a description of each of the current business processes relevant to this project.

3.7   Competitive Arena – Describe the current business environment within which the business operates, including:

  • Market analysis, competition, products and services available
  • Emerging markets and technologies
  • Regulatory or legislative changes.


4.       Identify Potential Solutions

At this point the study team conducts external research activities to uncover general information about the industry, the competitive environment, best practices, risks and results of the actual similar approaches that have been implemented by others to solve the business problem or seize the new opportunity under consideration. Then, the team identifies as many potential options as possible to meet the objectives identified in the planning process. It is important to note that the list of possible alternatives should include the option of doing nothing.

5.       Determine the Feasibility of each Option

For each potential solution, typical analysis steps include the following:

5.1   Describe the solution option in as much detail as possible, perhaps building a high-level work breakdown structure (WBS), a hierarchical decomposition of the solution, to bring the full scope of the effort into view.

5.2   Identify methods to assess the alternative, ensuring the analysis of the economic, operational and technical feasibility of the option. Examples of methods include: prototyping to prove the highest risk portions of the solution option are technically feasible, market surveys to ensure there is a demand for the solution and it will be economically feasible, technology capability assessment to ensure the solution does not require new, unproven technology, and business staff interviews and IT staff interviews to determine operational feasibility.

5.3   Identify expected results of the assessment.

5.4   Define assessment steps.

5.5   Undertake feasibility analysis for each option.

5.6   Review results to ensure completeness.

6.       Document and Communicate the Results of the Requirement Study

Proposal document would describe the results of the requirement study for each identified alternative solution. Share the proposal document with the executive sponsor of the study, and secure approval to estimate development efforts for the recommended option.

Types of Requirement

The types of requirements that exist vary based on the problem domain and methodology that the Pre-Sales/Business Analyst works with. For the proposal, the following types of standard requirements types have been defined:

  1. Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. This describes such things the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.
  2. User Requirements are statements of the needs of a particular stakeholder or class of stakeholders. This describes the needs that a given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the various classes of solution requirements.
  3. Functional Requirements describe the behavior and information that the solution will manage. This describes capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response.
  4. Quality of Service Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. This is also known as non-functional or supplementary requirements.
  5. Assumptions and constraints identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution.
  6. Implementation requirements describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete.


The deliverable from this effort is the scope statement and supporting information defining the following components by inclusion or reference. This proposal documentation is input to determine the development efforts, and includes the following elements.

  1. Summary of activities the led up to the recommended solution including the business environment analysis and competitive analysis.
  2. Strategic alignment describing how the initiative fits with organizational direction or mission.
  3. Business objective(s) and high-level business requirements.
  4. Product description and scope.
  5. Project boundaries including context diagrams to provide a visual model of the scope of the project.
  6. Assumptions and constraints.
  7. Major project milestones, funding requirements and limitations.
  8. Initial project approach including resource requirements, methodology, tools, and training requirements.
  9. Current and future standards, policies, regulations to be adhered to and impacts to the initiative.
  10. Commercial Off-the-Shelf (COTS) packages available vs. customized development of the solution.
  11. Dependencies, including downstream systems, interfaces, supporting data required.
Pre Sales, Software Services

What is proof of concept?

A proof of concept or a proof of principle is realization of a certain method or idea(s) to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory is probably capable of being useful. A proof-of-concept may or may not be complete, and is usually small and incomplete.

In software development, proof of concept (abbreviated PoC) is often incorrectly used to describe three processes with different objectives and different participant roles. These uses of the phrase proof of concept are therefore not synonymous and are delineated below.

  • A proof of concept can refer to a partial solution that involves a relatively small number of users acting in business roles to establish whether the system satisfies some aspect of the requirements.
  • By contrast, the objective of a proof of technology is to determine the solution to some technical problem, such as how two systems might be integrated or that a certain throughput can be achieved with a given configuration. No business users need be involved in a proof of technology.
  • A pilot project refers to an initial roll out of a system into production, targeting a limited scope of the intended final solution. The scope may be limited by the number of users who can access the system, the business processes affected, the business partners involved, or other restrictions as appropriate to the domain. The purpose of a pilot project is to test, often in a production environment, whether the system is working as it was designed while limiting business exposure.

Why we need proof of concept?

A PoC generally should be done early in the development cycle or to sell a software concept. It is used to validate technical feasibility, helps identify potential stumbling blocks, identifies what a platform can or can’t provide, helps determine the scope and level of customization necessary to complete the project.

The PoC can also help identify performance issues.  Generally, today, we assemble many of our applications / solutions in a “composite” fashion.  We’re re-using services, functions, etc. from other applications.  This re-use requires integration points.  It’s these integration points in our overall “context” that we’re vetting with the prototype effort.  While also validating assumptions regarding what the platform or framework can or can’t provide.

The outcome is a technical feasibility confidence factor along with factors that impact overall scope and estimate of effort.

Effective PoC

To create an effective PoC we need to create a PoC project as well as a document which will cover all the technical, functional approach of the project.

Below are the useful tips to create an effective PoC project:

  • Create the same architecture for PoC project which you are going to use for the development.
  • Design a Login page with exciting graphical interface if security is a primary concern for the project.
  • Home page with logo, all the possible menus/tabs, Search, links for the other sub functions of the project.
  • The home page should speak about the entire site what we are going to achieve.
  • If the content of the home page or other pages is based on user Roles then you should develop different pages showing how it will look like after login depending upon Roles.
  • Dashboard if required.
  • One or Two pages/modules which will show that how you are going to design/develop the pages/modules and how they are linked to each other. These page(s) should be the most important parts of the application.
  • If the project has any report(s), create a sample report with exciting look & feel so that the client can understand how you are going to produce the results.
  • If the project has any graph(s), create a sample graph.

In brief, it should cover all the features in short so that one can see what you are going to achieve after in the production version of the project.

 How to create PoC Documentation

The documentation for your PoC should explain about the entire design of the project. You add the below points with brief description.

  • The architecture detail which will be used for development.
  • Add all the technologies, third party tools you are going to use, with explanations why you have chosen the same.
  •  Add all the modules with brief functionality which will be developed.
    • Add the methods how you are going to handle security.
    • Explain each menu you have used in the PoC project.