1) Custom controls are written in separate program files that are compiled explicitly and are persisted as an assembly (.dll).User controls are authored using the ASP.NET page syntax, either in the script block or in CodeBehind pages and are implicitly just-in-time compiled by the ASP.NET runtime system.
2) Custom Controls are nicely suited for general re-use as they are easy to package and redistribute as third-party controls. User Controls are best suited for reuse within a web application. Because they are persisted as source files, less chances exist that third parties would like to distribute them.
3) Once created, a custom control can be added to the toolbox of a visual designer, such as Visual Studio .NET, and dragged and dropped onto a page— just like any built-in server control. The visual designer can also support visual manipulation of custom control’s various properties.User controls provide minimal support for use with a visual designer toolbox.
4) A custom control provides minimal support for design-time authoring in a visual designer.A user control provides design-time support for authoring in a visual designer—just like an ASP.NET page.
5) A custom controls inherits System.Web.UI.Control or System.Web.UI.WebControls.WebControl class with class hierarchy (bottom up) either MyCustomControl.Control.Object OR MyCustomControl. WebControl.Control. Object.A user control inherits System.Web.UI.UserControl class with class hierarchy (bottom up) MyUserControl. UserControl. TemplateControl. Control. Object.
6) A custom control is in the form of dynamic linked library (.dll), thus pre-compiled.A user control has extension .ascx and is JIT compiled
7) A custom control does not have any design editor. It may or may not inherit functionality of other standard control(s). It can be an entirely new one.A user control must encapsulate functionality of other web server control(s) through dragging and dropping in design mode
.8 ) A custom control does not have design editor so is harder to create.A user control is easy to create because it can be designed like a page is designed i.e. they have design editor and code behind simultaneously
9) A custom control (newly created or extended) is a separate and pre-compiled component.A user control requires registration and instantiation per page and resides on a page as an object and is compiled along with the page. It is not in pre-compiled form
10) A custom control is more reusable because you do not need a separate copy of it for each application; it can automatically be loaded be from the GAC. Thus giving an advantage of being a framework wide component.A user control cannot be registered with Global Assembly Cache (GAC) .
11) A custom control’s class is not bound with any design. Here you can take the leverage of the flexibility and richness of .NET programming model; you can expose properties, override functions of the base class and also register complex client side logic in the class. A user control cannot provide the level of richness that a custom control can provide.
12) A custom control is the best choice especially when you want to make your controls redistributable, more reusable and make it a Visual Studio IDE aware component.A user control may fulfill your need if you are working on a single web application
13) A custom control cannot use the user control. A user control can use a custom control.
14) The custom control model is designed for authoring redistributable components in the form of an assembly (compiled class library) that can be used by a number of applications. The assembly containing the controls can be used by a single application at a time when placed in the application’s private bin directory, or it can be shared across multiple applications when placed into the global assembly cache, commonly referred to as the GAC. The assembly can be deployed and used in its compiled binary form without the associated source code.The user control model is designed for single-application scenarios. A user control is dynamically compiled at run time when a page that uses it is first requested. As a result, a user control must be deployed in source form, and the .ascx file (and its associated code-behind, if any exists) must be copied into every application that requires the user control.
15) Custom controls are authored by writing a managed class that derives directly or indirectly from System.Web.UI.Control in a .NET programming language.User controls are authored declaratively in the form of .ascx files, which is very similar to the way ASP.NET pages are designed and developed.
Thursday, May 28, 2009
Monday, May 11, 2009
isolates storage
Introduction
Many programmers use the config file to keep the application configuration data. But one disadvantage with this is, it is a read only mechanism. You cannot update data in application config files, using the ConfigurationSettings classes in .NET. In earlier days, .ini files or registry was used to save application specific data.
Of course, we can use regular files to save application data. But now the question is how to protect the data, where to save it and all other mess!
Isolated Storage
.NET introduces a concept called Isolated Storage. Isolated Storage is a kind of virtual folder. Users never need to know where exactly the file is stored. All you do is, tell the .NET framework to store your file in Isolated Storage. The physical location of Isolated Storage varies for each Operating System. But your application simply uses the .NET classes to create and access files, without bothering where it is physically located. And you can have Isolated Storage specific to each Assembly or each Windows user.
The following code sample demonstrates the basic create, write and read operations with Isolated Storage.
Make sure you include the following directives on top of your file:
using System.IO;
using System.IO.IsolatedStorage;
using System.Diagnostics;
System.IO.IsolatedStorage Namespace
The System.IO.IsolatedStorage namespace contains types for creating and using a virtual file system. Isolated storage provides safe client-side storage for partial-trust applications. In Silverlight, all I/O operations are restricted to isolated storage and do not use the file system of the operating system.
Classes
Class Description
IsolatedStorageException
The exception that is thrown when an operation in isolated storage fails.
IsolatedStorageFile
Represents an isolated storage area containing files and directories.
IsolatedStorageFileStream
Exposes a file within isolated storage.
Code sample:
const string ISOLATED_FILE_NAME = "MyIsolatedFile.txt";
//-------------------------------------------------------
// Check if the file already exists in isolated storage.
//-------------------------------------------------------
IsolatedStorageFile isoStore =
IsolatedStorageFile.GetStore( IsolatedStorageScope.User
| IsolatedStorageScope.Assembly, null, null );
string[] fileNames = isoStore.GetFileNames( ISOLATED_FILE_NAME );
foreach ( string file in fileNames )
{
if ( file == ISOLATED_FILE_NAME )
{
Debug.WriteLine("The file already exists!");
}
}
//-------------------------------------------------------
// Write some text into the file in isolated storage.
//-------------------------------------------------------
IsolatedStorageFileStream oStream =
new IsolatedStorageFileStream( ISOLATED_FILE_NAME,
FileMode.Create, isoStore );
StreamWriter writer = new StreamWriter( oStream );
writer.WriteLine( "This is my first line in the isolated storage file." );
writer.WriteLine( "This is second line." );
writer.Close();
//-------------------------------------------------------
// Read all lines from the file in isolated storage.
//-------------------------------------------------------
IsolatedStorageFileStream iStream =
new IsolatedStorageFileStream( ISOLATED_FILE_NAME,
FileMode.Open, isoStore );
StreamReader reader = new StreamReader( iStream );
String line;
while ( (line = reader.ReadLine()) != null )
{
Debug.WriteLine( line );
}
reader.Close();
Visit here to read my C# Tutorial collection.
License
This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.
A list of licenses authors might use can be found here
Silverlight Tip of the Day #19: Using Isolated Storage
Silverlight uses Isolated Storage as a virtual file system to store data in a hidden folder on your machine. It breaks up the data into two separate sections: Section #1 contains administrative information such as disk quota and section #2 contains the actual data. Each Silverlight application is allocated its own portion of the storage with the current quota set to be 1 MB per application.
Advantages:
1. Isolated Storage is a great alterative to using cookies (as discussed in Tip of the Day #18) especially if you are working with large sets of data. Examples of use include undo functionality for your app, shopping cart items, window settings and any other setting your application can call up the next time it loads.
2. Isolated storage stores by user allowing server applications to dedicate unique settings per individual user.
Possible Pitfalls:
1. Administrators can set disk quota per user and assembly which means there is no guarantee on space available. For this reason, it is important to add exception handling to your code.
2. Even though Isolated Storage is placed in a hidden folder it is possible, with a bit of effort, to find the folder. Therefore the data stored is not completely secure as users can change or remove files. It should be noted though that you can use the cryptography classes to the encrypt data stored in isolated storage preventing users from changing it.
3. Machines can be locked down by administrative security policies preventing applications from writing to the IsolatedStorage. More specifically, code must have the IsolatedStorageFilePermission to work with isolated storage.
All that said, let’s take a look at how we save and load data. Note that you will need to add a using statement to reference the namespace System.IO.IsolatedStorage as well as System.IO.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.IO.IsolatedStorage;
using System.IO;
namespace SilverlightApplication10
{
public partial class Page : UserControl
{
public Page()
{
InitializeComponent();
SaveData("Hello There", "MyData.txt");
string test = LoadData("MyData.txt");
}
private void SaveData(string data, string fileName)
{
using (IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForApplication())
{
using (IsolatedStorageFileStream isfs = new IsolatedStorageFileStream(fileName, FileMode.Create, isf))
{
using (StreamWriter sw = new StreamWriter(isfs))
{
sw.Write(data);
sw.Close();
}
}
}
}
private string LoadData(string fileName)
{
string data = String.Empty;
using (IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForApplication())
{
using (IsolatedStorageFileStream isfs = new IsolatedStorageFileStream(fileName, FileMode.Open, isf))
{
using (StreamReader sr = new StreamReader(isfs))
{
string lineOfData = String.Empty;
while ((lineOfData = sr.ReadLine()) != null)
data += lineOfData;
}
}
}
return data;
}
}
}
INI files and the Windows registry were a step in the right direction, but isolated storage is the best option for persisting application-specific user settings in .NET programs.
The question of where to store user-specific application settings has plagued developers since the dawn of the PC. Prior to Windows 3.1, applications typically stored settings in a configuration file in the application directory. Windows 3.1 introduced the concept of initialization (.INI) files, and their associated headaches—corruption of WIN.INI, INI droppings all over the Windows directory, and inadvertent corruption or deletion of other applications' INI files. The Win32 platform introduced the registry—a system-wide configuration database in which developers were encouraged to store application settings. However, it's a bad idea to store large amounts of data in the registry, and giving just anybody write access to the registry poses a serious security risk. The registry is a fine place to store application configuration data that system administrators control, but it's not a good place for user-specific application settings. In .NET programs, those settings belong in isolated storage.
What Is Isolated Storage?
According to the .NET definition, "Isolated storage is a storage mechanism that provides isolation and safety by defining standardized ways of associating code with saved data." The isolated storage subsystem standardizes access methods, provides security by preventing other programs and users from accessing application-specific data, and supplies tools that help system administrators configure and control the storage space. Isolated storage provides a standard, flexible, and (to an extent) secure location for an application to store its settings—a place where other applications can't inadvertently overwrite or delete.
How Isolated Is It?
Access to an isolated storage file is always restricted to the user who created the file. This setup prevents users from inadvertently overwriting or deleting application settings that were created by other users or programs. The .NET runtime uses the operating system user-identity mechanism to support this isolation. In addition to user isolation, storage can be isolated based on the assembly (a DLL that contains all kinds of .NET-specific stuff), or on the combined application domain and assembly. () By combining user, domain, and assembly, the .NET framework provides these two types of storage isolation:
• Isolation by user and assembly. Data isolated by user and assembly can be accessed only by the user who originally created it, and only from code that resides in a particular assembly. This type of isolation is useful if you have multiple applications that need to access the same configuration data for a particular user. If you create a separate assembly that accesses the isolated storage, any application that calls the assembly can access the data for that user.
• Isolation by user, domain, and assembly. Isolation by user, domain, and assembly is more restrictive. In addition to restricting access based on user and assembly, the runtime ensures that the only application that can access the data is the application that originally created it. This type of isolation prevents data leakage between applications, as well as data corruption by other applications.
When To Use Isolated Storage
With the few exceptions noted below, you should use isolated storage anytime you need to store user-specific application settings. These situations cover a wide range of possibilities:
• Downloaded controls. Controls downloaded from the Internet don't have permissions to access the file system, but they do have isolated storage permissions. Isolated storage is the only way that these controls can persist user-specific data without requiring that the system administrator grant more permissions to the code.
• Web application storage. Web applications have the same I/O limitations as downloaded controls, and so must use isolated storage for any kind of persistent data storage.
• Shared component storage. As I pointed out earlier, isolated storage is an ideal way to persist data between multiple applications that all use the same settings for a particular user.
• Standalone client application storage. Although standalone applications typically have full access to the file system and the registry, isolated storage is usually a better choice for user-specific settings because using it prevents inadvertent corruption of one user's data by another user. It also provides a standard location for settings, thereby making it easier to secure application directories.
• Server application storage. Server applications can impersonate the logged-in user to persist user-specific settings. This provides the same level of isolation for server applications as for standalone client applications, preventing data leakage between users.
• Roaming. Because isolated storage data is stored in a user's profile directory, enabling roaming profiles makes all of the user's application-specific storage available to that user, regardless of the computer on which the user is logged in.
Of course, there are a few situations in which you shouldn't use isolated storage:
• Storing high-value secrets. Don't use isolated storage to persist unencrypted keys or passwords, or other secret information. Isolated storage files are stored on disk (see the Microsoft documentation for the location), where they're vulnerable to snooping or corruption by unmanaged code, highly trusted code, and trusted computer users.
• Administrator settings. You shouldn't use isolated storage to persist configuration and deployment settings that are controlled by administrators.
Silverlight Isolated Storage Best Practices
When you use isolated storage, following these guidelines will help you avoid problems and make the most of the protection isolated storage provides.
• Wrap all calls to isolated storage within try/catch blocks to be resilient to potential IsolatedStorageExceptions, which can be thrown if isolated storage is disabled or if the store has been deleted.
• If your Silverlight application needs to store a lot of data in isolated storage, consider hosting it on its own site so that it won't affect other applications on the site and other applications won't affect it.
• If you have a group of Silverlight applications that need to share data on the client, host them on the same site.
• Keep isolated storage paths as small as possible to prevent the internal full path from reaching the 260-character limit.
• Encrypt sensitive data stored in isolated storage.
• Use IsolatedStorageSettings to store objects and simple settings in isolated storage.
• Use IsolatedStorageFile if you want to use file and stream-based APIs, are storing large amounts of data, or need fine-grained control over the contents of isolated storage
Many programmers use the config file to keep the application configuration data. But one disadvantage with this is, it is a read only mechanism. You cannot update data in application config files, using the ConfigurationSettings classes in .NET. In earlier days, .ini files or registry was used to save application specific data.
Of course, we can use regular files to save application data. But now the question is how to protect the data, where to save it and all other mess!
Isolated Storage
.NET introduces a concept called Isolated Storage. Isolated Storage is a kind of virtual folder. Users never need to know where exactly the file is stored. All you do is, tell the .NET framework to store your file in Isolated Storage. The physical location of Isolated Storage varies for each Operating System. But your application simply uses the .NET classes to create and access files, without bothering where it is physically located. And you can have Isolated Storage specific to each Assembly or each Windows user.
The following code sample demonstrates the basic create, write and read operations with Isolated Storage.
Make sure you include the following directives on top of your file:
using System.IO;
using System.IO.IsolatedStorage;
using System.Diagnostics;
System.IO.IsolatedStorage Namespace
The System.IO.IsolatedStorage namespace contains types for creating and using a virtual file system. Isolated storage provides safe client-side storage for partial-trust applications. In Silverlight, all I/O operations are restricted to isolated storage and do not use the file system of the operating system.
Classes
Class Description
IsolatedStorageException
The exception that is thrown when an operation in isolated storage fails.
IsolatedStorageFile
Represents an isolated storage area containing files and directories.
IsolatedStorageFileStream
Exposes a file within isolated storage.
Code sample:
const string ISOLATED_FILE_NAME = "MyIsolatedFile.txt";
//-------------------------------------------------------
// Check if the file already exists in isolated storage.
//-------------------------------------------------------
IsolatedStorageFile isoStore =
IsolatedStorageFile.GetStore( IsolatedStorageScope.User
| IsolatedStorageScope.Assembly, null, null );
string[] fileNames = isoStore.GetFileNames( ISOLATED_FILE_NAME );
foreach ( string file in fileNames )
{
if ( file == ISOLATED_FILE_NAME )
{
Debug.WriteLine("The file already exists!");
}
}
//-------------------------------------------------------
// Write some text into the file in isolated storage.
//-------------------------------------------------------
IsolatedStorageFileStream oStream =
new IsolatedStorageFileStream( ISOLATED_FILE_NAME,
FileMode.Create, isoStore );
StreamWriter writer = new StreamWriter( oStream );
writer.WriteLine( "This is my first line in the isolated storage file." );
writer.WriteLine( "This is second line." );
writer.Close();
//-------------------------------------------------------
// Read all lines from the file in isolated storage.
//-------------------------------------------------------
IsolatedStorageFileStream iStream =
new IsolatedStorageFileStream( ISOLATED_FILE_NAME,
FileMode.Open, isoStore );
StreamReader reader = new StreamReader( iStream );
String line;
while ( (line = reader.ReadLine()) != null )
{
Debug.WriteLine( line );
}
reader.Close();
Visit here to read my C# Tutorial collection.
License
This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.
A list of licenses authors might use can be found here
Silverlight Tip of the Day #19: Using Isolated Storage
Silverlight uses Isolated Storage as a virtual file system to store data in a hidden folder on your machine. It breaks up the data into two separate sections: Section #1 contains administrative information such as disk quota and section #2 contains the actual data. Each Silverlight application is allocated its own portion of the storage with the current quota set to be 1 MB per application.
Advantages:
1. Isolated Storage is a great alterative to using cookies (as discussed in Tip of the Day #18) especially if you are working with large sets of data. Examples of use include undo functionality for your app, shopping cart items, window settings and any other setting your application can call up the next time it loads.
2. Isolated storage stores by user allowing server applications to dedicate unique settings per individual user.
Possible Pitfalls:
1. Administrators can set disk quota per user and assembly which means there is no guarantee on space available. For this reason, it is important to add exception handling to your code.
2. Even though Isolated Storage is placed in a hidden folder it is possible, with a bit of effort, to find the folder. Therefore the data stored is not completely secure as users can change or remove files. It should be noted though that you can use the cryptography classes to the encrypt data stored in isolated storage preventing users from changing it.
3. Machines can be locked down by administrative security policies preventing applications from writing to the IsolatedStorage. More specifically, code must have the IsolatedStorageFilePermission to work with isolated storage.
All that said, let’s take a look at how we save and load data. Note that you will need to add a using statement to reference the namespace System.IO.IsolatedStorage as well as System.IO.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.IO.IsolatedStorage;
using System.IO;
namespace SilverlightApplication10
{
public partial class Page : UserControl
{
public Page()
{
InitializeComponent();
SaveData("Hello There", "MyData.txt");
string test = LoadData("MyData.txt");
}
private void SaveData(string data, string fileName)
{
using (IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForApplication())
{
using (IsolatedStorageFileStream isfs = new IsolatedStorageFileStream(fileName, FileMode.Create, isf))
{
using (StreamWriter sw = new StreamWriter(isfs))
{
sw.Write(data);
sw.Close();
}
}
}
}
private string LoadData(string fileName)
{
string data = String.Empty;
using (IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForApplication())
{
using (IsolatedStorageFileStream isfs = new IsolatedStorageFileStream(fileName, FileMode.Open, isf))
{
using (StreamReader sr = new StreamReader(isfs))
{
string lineOfData = String.Empty;
while ((lineOfData = sr.ReadLine()) != null)
data += lineOfData;
}
}
}
return data;
}
}
}
INI files and the Windows registry were a step in the right direction, but isolated storage is the best option for persisting application-specific user settings in .NET programs.
The question of where to store user-specific application settings has plagued developers since the dawn of the PC. Prior to Windows 3.1, applications typically stored settings in a configuration file in the application directory. Windows 3.1 introduced the concept of initialization (.INI) files, and their associated headaches—corruption of WIN.INI, INI droppings all over the Windows directory, and inadvertent corruption or deletion of other applications' INI files. The Win32 platform introduced the registry—a system-wide configuration database in which developers were encouraged to store application settings. However, it's a bad idea to store large amounts of data in the registry, and giving just anybody write access to the registry poses a serious security risk. The registry is a fine place to store application configuration data that system administrators control, but it's not a good place for user-specific application settings. In .NET programs, those settings belong in isolated storage.
What Is Isolated Storage?
According to the .NET definition, "Isolated storage is a storage mechanism that provides isolation and safety by defining standardized ways of associating code with saved data." The isolated storage subsystem standardizes access methods, provides security by preventing other programs and users from accessing application-specific data, and supplies tools that help system administrators configure and control the storage space. Isolated storage provides a standard, flexible, and (to an extent) secure location for an application to store its settings—a place where other applications can't inadvertently overwrite or delete.
How Isolated Is It?
Access to an isolated storage file is always restricted to the user who created the file. This setup prevents users from inadvertently overwriting or deleting application settings that were created by other users or programs. The .NET runtime uses the operating system user-identity mechanism to support this isolation. In addition to user isolation, storage can be isolated based on the assembly (a DLL that contains all kinds of .NET-specific stuff), or on the combined application domain and assembly. () By combining user, domain, and assembly, the .NET framework provides these two types of storage isolation:
• Isolation by user and assembly. Data isolated by user and assembly can be accessed only by the user who originally created it, and only from code that resides in a particular assembly. This type of isolation is useful if you have multiple applications that need to access the same configuration data for a particular user. If you create a separate assembly that accesses the isolated storage, any application that calls the assembly can access the data for that user.
• Isolation by user, domain, and assembly. Isolation by user, domain, and assembly is more restrictive. In addition to restricting access based on user and assembly, the runtime ensures that the only application that can access the data is the application that originally created it. This type of isolation prevents data leakage between applications, as well as data corruption by other applications.
When To Use Isolated Storage
With the few exceptions noted below, you should use isolated storage anytime you need to store user-specific application settings. These situations cover a wide range of possibilities:
• Downloaded controls. Controls downloaded from the Internet don't have permissions to access the file system, but they do have isolated storage permissions. Isolated storage is the only way that these controls can persist user-specific data without requiring that the system administrator grant more permissions to the code.
• Web application storage. Web applications have the same I/O limitations as downloaded controls, and so must use isolated storage for any kind of persistent data storage.
• Shared component storage. As I pointed out earlier, isolated storage is an ideal way to persist data between multiple applications that all use the same settings for a particular user.
• Standalone client application storage. Although standalone applications typically have full access to the file system and the registry, isolated storage is usually a better choice for user-specific settings because using it prevents inadvertent corruption of one user's data by another user. It also provides a standard location for settings, thereby making it easier to secure application directories.
• Server application storage. Server applications can impersonate the logged-in user to persist user-specific settings. This provides the same level of isolation for server applications as for standalone client applications, preventing data leakage between users.
• Roaming. Because isolated storage data is stored in a user's profile directory, enabling roaming profiles makes all of the user's application-specific storage available to that user, regardless of the computer on which the user is logged in.
Of course, there are a few situations in which you shouldn't use isolated storage:
• Storing high-value secrets. Don't use isolated storage to persist unencrypted keys or passwords, or other secret information. Isolated storage files are stored on disk (see the Microsoft documentation for the location), where they're vulnerable to snooping or corruption by unmanaged code, highly trusted code, and trusted computer users.
• Administrator settings. You shouldn't use isolated storage to persist configuration and deployment settings that are controlled by administrators.
Silverlight Isolated Storage Best Practices
When you use isolated storage, following these guidelines will help you avoid problems and make the most of the protection isolated storage provides.
• Wrap all calls to isolated storage within try/catch blocks to be resilient to potential IsolatedStorageExceptions, which can be thrown if isolated storage is disabled or if the store has been deleted.
• If your Silverlight application needs to store a lot of data in isolated storage, consider hosting it on its own site so that it won't affect other applications on the site and other applications won't affect it.
• If you have a group of Silverlight applications that need to share data on the client, host them on the same site.
• Keep isolated storage paths as small as possible to prevent the internal full path from reaching the 260-character limit.
• Encrypt sensitive data stored in isolated storage.
• Use IsolatedStorageSettings to store objects and simple settings in isolated storage.
• Use IsolatedStorageFile if you want to use file and stream-based APIs, are storing large amounts of data, or need fine-grained control over the contents of isolated storage
Wednesday, May 6, 2009
RIA
RICH INTERNET APPLICTION
A cross between browser-based Web applications and traditional desktop applications
BENEFITS OF RIA
- Cost-effective way to deliver modern application with real business benefits
- Provide real time data and inventory management.
- Allow users to remotely monitor and manage data via a Web-based system.
- Reduce data complexity -- allow users to interactively visualize and manipulate complex data more effectively and easily.
- Provide immediate and dynamic visual feedback to the user.
- Allow for quicker task completion.
- Provide cross platform support.
FEATURES OF RIA - Run in a web browser, not requiring installation.
- Run locally in a secure environment called a sandbox.
- Users can use the application from any computer with an internet connection .
- Cross-platform availability
- Fast interface response time with no page refresh
- Common UI behaviors like drag & drop and the ability to work online and offline
- Common calculation that happens on the client (e.g., an insurance rate calculator)
Instant update of the application
RIA IN SILVERLIGHT - Any .Net programming language is used (c#, Ruby,Python,VB)
- .Net based browser plug-in for rich features (animation,vector graphics and audio-video).
- Silverlight is a great boost to the performance, providing a high-performance execution environment inside of the browser.
- Silverlight enables applications that run within multiple browsers and operating systems (Windows and Macintosh) and built on web standards for pogrammability such as JavaScript, CSS and XML and the .NET CLR.
- The CLR is the core piece of .NET Framework.
- The CLR is a well-proven high-performance platform providing features like Garbage Collection, Just-In-Time compilation, Exception Management and a wide array of fully featured languages such as VB.NET and C# that are used
Applications - Financial Services
- Auto Dealerships
- Mortgage Firms
- Customer survey forms
- Email forms
- Video Distribution (branding/licensing)
- Remote training services
- Customer service (live two-way video, chat )
- Virtual Desktop Environments
- CRM/ERP front-end applications
difference between silverlight 1.0 and silverlight 2.0
SILVERLIGHT 1.0
l Cross-Browser Support for Firefox , Safari
l Cross-Platform Support for Windows and Mac (and Linux through the Moonlight Project)
l 2D Vector Animation/Graphics
l AJAX Support
l HTML DOM Integration
l HTTP Networking
l Canvas Layout Support
l Media –Image support like JPG,PNG.
l Media Markers
l Silverlight ASP.NET Controls (asp: media, asp:xaml)
l JavaScript Support
l XAML Parser (based on WPF)
l Media – 720P High Definition (HD) Video
l Media – Audio/Video Support (VC-1, WMV, WMA, MP3)
l Windows Media Server Support
SILVERLIGHT 2.0
l High quality resizing
l Media - Basic SSPL Support
l Cross Domain Network Access
l Easy access to server-side data via Web Services
l Direct access to TCP sockets
l Managed HTML Bridge
l Managed Exception Handling
l Rich Core Framework (e.g. Generics, collections)
l Support for Visual Basic.NET and C#; Common Language Runtime (CLR) based languages
l Support for IronPython, IronRuby, Managed JScript, and other Dynamic Language Runtime (DLR) based languages
l Multi-Threading
l Layout controls including StackPanel and Grid
l Full suite of Controls (TextBox, RadioButton, Slider, Calendar, DatePicker, DataGrid, ListBox, TabControl, and others)
l Managed Control Framework
l Templating Model
l Visual State Manager
l Isolated Storage
l Deep Zoom Technology
l Media – DRM Powered by PlayReady
l Media - Windows Media Audio 10 Professional support
l Direct access to TCP sockets
l Media - MediaStreamSource for managed code media file parser and protocol extensibility
l Interoperability with SOAP and REST services, including support for XML, JSON, RSS and Atom data formats
l LINQ (including LINQ to XML, LINQ to JSON, and LINQ to Entities)
l Duplex communications (“push” from Server to Silverlight client)
l Data Binding
l ADO.NET Data Services
l .NET Framework Security Enforcement
l Type Safety Verification
l XMLReader/Writer
l Enhanced Keyboard Input Support
l File Upload Support (via WebClient API)
l WPF Compatibility
l Accessibility
l Localization
l Remote Debugging (PC and Mac)
l Cross-Browser Support for Firefox , Safari
l Cross-Platform Support for Windows and Mac (and Linux through the Moonlight Project)
l 2D Vector Animation/Graphics
l AJAX Support
l HTML DOM Integration
l HTTP Networking
l Canvas Layout Support
l Media –Image support like JPG,PNG.
l Media Markers
l Silverlight ASP.NET Controls (asp: media, asp:xaml)
l JavaScript Support
l XAML Parser (based on WPF)
l Media – 720P High Definition (HD) Video
l Media – Audio/Video Support (VC-1, WMV, WMA, MP3)
l Windows Media Server Support
SILVERLIGHT 2.0
l High quality resizing
l Media - Basic SSPL Support
l Cross Domain Network Access
l Easy access to server-side data via Web Services
l Direct access to TCP sockets
l Managed HTML Bridge
l Managed Exception Handling
l Rich Core Framework (e.g. Generics, collections)
l Support for Visual Basic.NET and C#; Common Language Runtime (CLR) based languages
l Support for IronPython, IronRuby, Managed JScript, and other Dynamic Language Runtime (DLR) based languages
l Multi-Threading
l Layout controls including StackPanel and Grid
l Full suite of Controls (TextBox, RadioButton, Slider, Calendar, DatePicker, DataGrid, ListBox, TabControl, and others)
l Managed Control Framework
l Templating Model
l Visual State Manager
l Isolated Storage
l Deep Zoom Technology
l Media – DRM Powered by PlayReady
l Media - Windows Media Audio 10 Professional support
l Direct access to TCP sockets
l Media - MediaStreamSource for managed code media file parser and protocol extensibility
l Interoperability with SOAP and REST services, including support for XML, JSON, RSS and Atom data formats
l LINQ (including LINQ to XML, LINQ to JSON, and LINQ to Entities)
l Duplex communications (“push” from Server to Silverlight client)
l Data Binding
l ADO.NET Data Services
l .NET Framework Security Enforcement
l Type Safety Verification
l XMLReader/Writer
l Enhanced Keyboard Input Support
l File Upload Support (via WebClient API)
l WPF Compatibility
l Accessibility
l Localization
l Remote Debugging (PC and Mac)
Monday, May 4, 2009
RIA
RICH INTERNET APPLICTION :
Rich Internet Application is a web application resembling the features of a desktop application It provides an end user experience similar to client/server applications supported by rich graphical user interface.
BENEFITS OF RIA :
RIA offers organizations a proven, cost-effective way to deliver modern application with real business benefits
Ø Offer users a richer, more engaging experience
Ø Keep pace with users' rising expectations
Ø Increase customer loyalty and generate higher profits.
Ø Leverage existing personnel ,processes ,and infrastructure.
Ø Highly responsive performance and reduced network load.
Ø Higher, richer and easier levels of interactive functionality.
BENEFITS OF RIA IN SILVERLIGHT :
The emergence of new technologies such Silverlight not only take performance management to the next level, but also enables the user to benefit from 'rich' UI and enhanced performance at the same time. These technologies facilitate the users in various ways
Ø A technology widely known as 'no-refresh', where the transition from one set of information to another is instantaneous and visually more appealing
Ø No major installation required. Updating and distributing the application is an instant and automatic process
Ø Users can use the application from any computer equipped with an Internet connection regardless of the operating system running on that computer
Ø Web-based applications are generally less prone to viral infections contrary to the desktop applications
Rich Internet Application is a web application resembling the features of a desktop application It provides an end user experience similar to client/server applications supported by rich graphical user interface.
BENEFITS OF RIA :
RIA offers organizations a proven, cost-effective way to deliver modern application with real business benefits
Ø Offer users a richer, more engaging experience
Ø Keep pace with users' rising expectations
Ø Increase customer loyalty and generate higher profits.
Ø Leverage existing personnel ,processes ,and infrastructure.
Ø Highly responsive performance and reduced network load.
Ø Higher, richer and easier levels of interactive functionality.
BENEFITS OF RIA IN SILVERLIGHT :
The emergence of new technologies such Silverlight not only take performance management to the next level, but also enables the user to benefit from 'rich' UI and enhanced performance at the same time. These technologies facilitate the users in various ways
Ø A technology widely known as 'no-refresh', where the transition from one set of information to another is instantaneous and visually more appealing
Ø No major installation required. Updating and distributing the application is an instant and automatic process
Ø Users can use the application from any computer equipped with an Internet connection regardless of the operating system running on that computer
Ø Web-based applications are generally less prone to viral infections contrary to the desktop applications
Subscribe to:
Posts (Atom)
