Native Mobile applications

It is needless to say, that a native mobile application is created in the respective programming language/SDK for the platform like Android and IOS. Native application normally has following two plus points points:

1. Provides seamless user experience. The native applications normally have the look and feel same as that of other platform applications.
2. Transition and animation effects while navigating within the application.
3. Access to devices resources/features like SDCard and camera

Mobile Web Application

Mobile web applications are created using the web technologies like HTML5, JavaScript and CSS3. The mobile web application can be available in either methods as below:

1. A web site optimized for mobile device and hosted on a web server. Which is accessed using the web browser on the device
2. A native/hybrid application created using PhoneGap or by embedding the WebView in a application

In both the case, the mobile web apps needs to have

1. Look and feel in sync with the platform being used. This would provide a seamless user experience
2. Mobile optimized view and touch support
3. Transitions and animations during navigation

The native look and feel and transition requirements can be addressed by using available HTML5 Mobile frameworks explained next.

HTML5 Mobile App Frameworks

In recent years w/ the advent of HTML5, many HTML5 mobile app frameworks are available. These frameworks provides features like:

1. Native Look & Feel
2. Animation
3. Transitions
4. 2D Drawing using Canvas
5. 3D drawing using Web GL

These frameworks can be used to create a mobile web site as well a native (Hybrid) mobile application. These frameworks are also compatible with PhoneGap and Appmobi. With the help of the HTML5 mobile app frameworks it is possible to have a native look and feel at the same time leveraging the HTML5 features like:

1. Geo location
2. Local Storage
3. Web Sockets
4. Audio/Video API

In the crowd of existing HTML5 Mobile App framework, I got a chance to explore following frameworks

JQuery Mobile

JQuery mobile is cross platform & cross device mobile Web App framework. It can be used to create a mobile web site, hosted on a web server as well as to create a native application using PhoneGap. It provides a unified user experience on the mobile devices. It has quite good number of widgets like Lists, Form elements, switches along with page animations and transitions.

Recently JQuery Mobile released its Final version 1.0. Compared to others it is a new player in the market but looks promising. It is based on the popular JQuery platform and is lightweight. So a person who is familiar is with JQuery, will find it bit easy to use.  It provides a flexible, easily themeable design which can be customized per the requirement

It does not provide any abstraction for HTML5/JavaScript APIs. One has to explicitly use the HTML5/JavaScript API. It also works well with PhoneGap and AppMobi. It makes use declarative HTML mark-up which can be updated at run time using DOM manipulation

It supports following platforms:

• IOS
• Android
• BlackBerry
• Windows Phone
• Symbian

Dojo Mobile

Dojo Mobile is a HTML5 mobile JavaScript framework that enables rapid development of mobile web applications with a native look and feel on modern webkit-enabled mobile devices such as iPhone, iPod Touch, iPad, Android and RIM smartphones and tablets. It is based on the popular Dojo library already available for the web

It provides several lightweight widgets (views, buttons, lists, etc.) that look and act like those found on the iOS and Android native interfaces. The View widget defines a single page in your application. One can add multiple views to the application and  use the provided transitions (flip, fade, and slide) to move between the views.

The current version of dojo is 1.6 and 1.7 is scheduled for release.

Dojo Mobile also provides features like:

• Gauges
• Chart widget

Applications that run on an Android have a distinctly different look than iPhone applications. Dojo mobile provides CSS style-sheets for both the Android and iPhone. One can  build a separate application for each device, or use JavaScript at run time, to determine the type of device the application is running on and then use the appropriate style-sheet.

Dojo Mobile is PhoneGap ready. So it can be used to create native application and publish to market place.
It provides both declarative and dynamic UI. The widget can be either defined using HTML/JSON or can be created dynamically

Sencha Touch

Sencha Touch is based on the popular Ext JavaScript Framework. It is optimized and scaled down for the mobile device usage. It leverages HTML5, CSS3, and Javascript for the highest level of power, flexibility, and optimization.

It makes specific use of HTML5 to deliver components like Audio and Video. It provides abstraction API for leveraging HTML5 storage features like LocalStorage, SessionStorage etc.

Sencha Touch is compatible with Phonegap using which it can be used to create native mobile applications.

It makes us of minimal HTML code and renders its own DOM based on the objects created using the JavaScript. For some this may be a dis-appointing factor, since it gives a less webby experience while coding

As compared to the counter parts, Sencha Touch is more extensive in term of UI components, transitions/animations and explicit iPad support. It has incredible support for storage and data binding facilities using JSON and HTML5 offline storage, and more.

It also performs better than JQuery Mobile except the initial loading time.

Currently it supports following platforms:

• Android
• iOS
• Blackberry

Sencha also provides a Native Packaging for Android and IOS. It can be used to create .APK and .APP file. For the native packaging SenchaSDKTools needs to be downloaded and installed

In addition to these frameworks, there are other frameworks available. Will cover the other frameworks later

]]> http://blogs.globallogic.com/html5-mobile-app-frame-works/feed http://blogs.globallogic.com/mobile-web-and-html-5 http://blogs.globallogic.com/mobile-web-and-html-5#comments Sat, 08 Oct 2011 17:51:38 +0000 ninad.pandey http://blogs.globallogic.com/?p=1636 In recent past, I came across requirements about creating mobile application for IPhone and Android platform. One of the obvious choices was to create a native application for IPhone and Android respectively.

After understanding the requirement, it was learnt that the application doesn’t need to access any of the native feature of mobile device like camera, accelerometer. In other words the application was a data driven application having rich user interface. It triggered the thought!!! Why not have Mobile Web Application for this?

What is Mobile Web Application?
Mobile Web Application is web application, optimized to run in mobile device web browser. Some of the parameters under consideration are:

• Screen size
• Bandwidth
• Device orientation
• Native user interface

Present day mobile web browsers contained by smart phones like IPhone and Android can show almost every website that we can open on desktop browser.
Advantages
One of the biggest advantages of Mobile Web App is, it can be uses over the variety of smart phones. If any customization is required for specific mobile device model, then it can be done on the server side. There is no need to create ports for different mobile devices.
In case of there is any update in the application, then the web server contents only needs to be updated. The mobile client will always get the updated contents.

Conventional Mobile Web App

Conventional mobile web can be created in any web platform like PHP, ASP.NET. It essentially consists of a home page which uses HTML mark-up along with CSS and javasript. Mobile user starts the web browser and hits the home page and starts using the application. For each such page, the server sends and HTML mark-up and images to have a decent user interface. One drawback here is the look and feel. Once the user starts the web application, he/she gets an off-deck user experience. The mobile web application look and feel in most of the cases is very different from the mobile device native user interface.

Leveraging HTML 5 & CSS3

HTML 5 is fast catching up. W3C has already created the draft for HTML 5 and CSS3 standards. Popular desktop browser like Chrome, Firefox 4.0 and Opera 9 supports most of HTML5 and CSS3 standards.
Good news is, IPhone mobile safari and Android device web browser also supports most of the HTML 5 and CSS3 features. With support for CSS3 and HTML 5, the developers get extra arsenals for creating more sophisticated mobile web applications

Native Look & Feel using CSS3

With the use of CSS3 it is possible to have native look & feel for IPhone and Android devices. Some of the CSS3 features are:

• Text effects, Gradients
• 2D transformation
• 3D transformation
• Transitions
• Animations

With above feature we can add the animation and transition effect to mobile web applications similar to what IPhone and Android devices provide. Due to support for gradient and text effects in CSS3, we can minimize use of images. This also helps further to reduce the page pay load

Test Web page without any specific CSS.

Test Web page in Android emulator after applying CSS

Test Web page in IPhone emulator after applying CSS

HTML 5 features

HTML 5 provides many new features as compared to HTML 4. IPhone and Android mobile web browsers now support most of the HTML 5 features.  Some of the important HTML 5 features are:

• Local Web storage. Can be used to store the intermediate data locally and when required the data can be saved to cloud or the web server
• Access to Geolocation. Can be used to location based application
• Audio API. Can be used to control and play audio
• Video API
• Canvas support. A 2D drawing mechanism.
• Web Sockets. Real time application

Full Screen Browser Or Native application with embedded web browser (Hybrid)?

The most common way to start a Mobile Web Application on mobile device is to start the web browser and type the application URL.  We can use JavaScript to set the web browser to full screen mode. For some people still this may be dislike.
For such, we can have a native device application. This application then embeds the Web view. Of course, this device application needs to be created to all supported platform. The user downloads this native application from app store. When launched, it displays the embedded web view in full screen view and hits the application home URL. This way the user has a seamless user experience. With this hybrid one can also provide a mechanism to intercept the events in the web view. For example we can intercept click events for all hyperlinks in the view and then may call some native function using the device specific language.

Accessing phone’s native features

There are many instances, in which we may need to access the native phone features like Geo-location, accelerometer. At present not all native phone features can be accessed using JavaScript API from HTML5. Unfortunately not all native features can be access using the JavaScript API. Currently JavaScript APIs are available to access the Geolocation and Address book.
For other features like camera, accelerometer we need to use some bridge. Most common way is to use PhoneGap. It provides an interface to access the native features of mobile devices. It is available for IPhone, Android and other smart phones

Indexing Basics

The purpose of storing an index is to optimize speed and performance in finding relevant documents for a search query. Without an index, the search engine would scan every document in the corpus, which would require considerable time and computing power. For example, while an index of 10,000 documents can be queried within milliseconds, a sequential scan of every word in 10,000 large documents could take hours. The additional computer storage required to store the index, as well as the considerable increase in the time required for an update to take place, are traded off for the time saved during information retrieval.

Lucene stores the data in the form of an inverted index. This index can only determine whether a word exists within a particular document, since it stores no information regarding the frequency and position of the word. Such an index determines which documents match a query but does not rank matched documents. Typically, position information and frequency is used to help in ranking the relevance of the documents.

Lucene index is built over an implementation of the Directory class. Lucene supports multiple Directory implementations :

• RAMDirectory: Implementation of RAM-based indices.
• FSDirectory: Implementation of an index as a single file. Indices is stored file system. Some part of is kept in Cache.
• DbDirectory: Implementation indices stored in a database, via JDBC.

Lucene Concepts

• Term : A Term represents a word from text. This is the unit of search. It is composed of two elements, the text of the word, as a string, and the name of the field that the text occured in, an interned string. Note that terms may represent more than words from text fields, but also things like dates, email addresses, URLs, etc.
• Document : Documents are the unit of indexing and search. A Document is a set of fields. Each field has a name and a textual value. Thus each document should typically contain one or more stored fields which uniquely identify it.
• Field : A field is a section of a Document. Each field has two parts, a name and a value. Values may be free text, provided as a String or as a Reader, or they may be atomic keywords, which are not further processed. Such keywords may be used to represent dates, URLs, etc. Fields are optionally stored in the index, so that they may be returned with hits on the document.
• Analyzer :An Analyzer is used to analyze text. It thus represents a policy for extracting index terms from text. Typical implementations first build a Tokenizer, which breaks the stream of characters tokens. One or more filters then be applied.
• Query : Base for all queries. Various types of queries are:
  * TermQuery
  * BooleanQuery
  * WildcardQuery
  * PhraseQuery
  * PrefixQuery
  * MultiPhraseQuery
  * FuzzyQuery
  * TermRangeQuery
  * NumericRangeQuery

Adding Data to Lucene Index

// Step 1: Instantiate the Directory, Analyzer and Index Writer.
// Create instance of Directory where index files will be stored
File indexDirectoryPath = new File(”C:\\temp\\index”);
Directory fsDirectory = FSDirectory.open(indexDirectoryPath);

// Step 2: Create instance of analyzer, which will tokenize the input data
Analyzer analyzer = new SimpleAnalyzer(Version.LUCENE_33);

//Step 3: Create a new index. Create instance of the IndexWriter
IndexWriterConfig conf = new IndexWriterConfig(Version.LUCENE_33, analyzer);
conf.setMaxThreadStates(2);

IndexWriter indexWriter = new IndexWriter(fsDirectory, conf);

//Step 4: Prepare the data for indexing.
String emailId = “testemail@mailinator.com”;
String message = “This is a TEST message for indexing.”;

//Step 5: Wrap the data in the Fields and add them to a Document.
Field emailIdField = new Field(”emailId”, emailId, Field.Store.YES, Field.Index.NOT_ANALYZED);
Field messageField = new Field(”message”, message, Field.Store.YES, Field.Index.ANALYZED);
Document doc = new Document();

// Step 6: Add these fields to a Lucene Document
doc.add(emailIdField);
doc.add(messageField);

//Step 7: Add this document to Lucene Index.
indexWriter.addDocument(doc);

//Step 8: Optimize Lucene Index.
indexWriter.optimize();

//Step 9. Close Lucene Index.
indexWriter.close();

Download Luke and try some of the queries on your indexes by changing the Analyzers. The tool can also be used to view and modify indexes.

Index Optimization : Requests an “optimize” operation on an index, priming the index for the fastest available search. Traditionally this has meant merging all segments into a single segment as is done in the default merge policy, but individual merge policies may implement optimize in different ways.
It is recommended that this method be called upon completion of indexing. In environments with frequent updates, optimize is best done during low volume times, if at all.

Querying Index

String querystr = “message”;

//Step 1: Instantiate the Analyzer
Analyzer simpleAnalyzer = new SimpleAnalyzer(Version.LUCENE_33);

//Step 2: Create Query
Query q = new QueryParser(Version.LUCENE_33, “message”, simpleAnalyzer).parse(querystr);
int hitsPerPage = 20;

//Step 3: Instantiate the Searcher
File indexDirectoryPath = new File(”C:\\temp\\index”);
Directory fsDirectory = FSDirectory.open(indexDirectoryPath);
IndexSearcher indexSearcher= new IndexSearcher(fsDirectory);
TopScoreDocCollector collector = TopScoreDocCollector.create(hitsPerPage, true);

//Step 4: Perform Search and collect results
indexSearcher.search(q, collector);
ScoreDoc[] scoreDosArray = collector.topDocs().scoreDocs;

// Step 5: Retrieve the matched document and show relevant details
for(ScoreDoc scoredoc : scoreDosArray){
Document doc = indexSearcher.doc(scoredoc.doc);
System.out.println(”emailId["+ doc.getFieldable("emailId").stringValue()+"]“);
System.out.println(”message["+ doc.getFieldable("message").stringValue()+"]“);
}

//Step 6: Close Lucene Index Searcher.
indexSearcher.close();

Further, Lucene can be integrated with Hibernate framework to help parse and index data. More on this in my next post.

Let us start by looking at the anatomy of a web page. Primarily web page has HTML, CSS and JavaScript or a more generic explanation will be:

A web page has:

· Structure: HTML

· Presentation: CSS

· Behavior: JavaScript

We will be focusing on the presentation today. I don’t expect you to be an expert at the end of this blog but at least I would expect that you will be skilled or at least inspired to explore more into the world of presentation aspects of a web page.

What is CSS? (I know all of you would know the answer). As per Wikipedia definition of CSS:

“Cascading Style Sheets (CSS) is a style sheet language used to describe the presentation semantics (the look and formatting) of a document written in a markup language.”

Applying Stylesheets

So how can we apply CSS on a web page? We have three option when it comes to applying CSS:

1. Inline (Easy)

2. Embedded/Internal (Better)

3. External (Best)

Inline CSS are applied using Style attribute of an HTML element. Below are few of the examples inline CSS:

<a style=”color:red;text-align:left” href=”#”>Hello World</a>

<p style=”margin-left:10px;margin-right:20px”>This is a paragraph</p>

This is of course easy but we are now mixing the structure and presentation of a web page and should be avoided whenever if not always possible. In additional it also makes the web page less maintainable and will lead to code duplication.

Embedded/Internal CSS are applied by adding <style> tag. Below is an example using embedded CSS:

<head>

<style type=”text/css”>

a {color:red;text-align:left}

p {margin-left:10px;margin-right:20px}

</style>

</head>

This is a good approach during the development phase specially when you are trying to pick the right style for your web page.

External/Linked CSS are applied using <link> tag which will contain the link to the CSS file in the href attribute. Although not very popular you can also use the @import statement within the style tag. Below is an example of using External CSS using <link> tag:

<head>

<link rel=”stylesheet” type=”text/css” href=”BaseControlStyle.css” />

</head>

This is the best option as it decouple the presentation from structure it also help to leverage the browser caching feature to improve the performance of the web page.

Although mentioned I would recommend avoiding usage of @import whenever possible as it kills the page performance. To read more on the performance impact of @import statement here.

There are other options when it comes to linking CSS which I would like to call uncommon or unconventional like using HTTP header which is explain in this article.

Anatomy of CSS

Simplest way to explain CSS anatomy to break it into 2 parts:

1. Selector

2. Declaration (Properties and Values)

CSS Selector

CSS Selector is a pattern, which will be used to identify the element(s) on which the style will be applied. 

 Most commonly used selectors are:

1. Type Selectors

2. Class Selectors

3. ID Selectors

4. Descentant Selectors

5. Pseudo classes

Type Selectors

Select all elements of a particular type. For example:

h1{declarations} – Will select all the H1 elements in the entire document

p{declarations} – Will select all the paragraph elements in the entire document.

Class Selectors

Select all elements which contain a particular class name. For example:

.colored {declarations} – Will select all elements which contains a class name “colored”

.errorMessage {declarations}– Will select all elements which contains a class name “errorMessage”

Notice that we need to put dot (.) before the class name.

ID Selectors

Select the element with a particular ID. For example:

#nav_main {declarations} – Will select all elements which has the ID “nav_main”

Notice that we need to put hash (#) before the ID.

Descentant Selectors

Select an element which is an descentant of another element. Descentant selectors are formed by combining multiple selectors seperated by whitespace. For example:

#nav_main li{declarations} – Will select all “li’ (list) elements which are descentant of an element with the ID “nav_main”

Below is another example which is slightly more complex:

#nav_main li .help #phone #mobile{declarations}

“Selects any element with an id attribute that equals mobile that is a descendant of any element with an id attribute that equals phone that is a descendant of any element with a class attribute that contains the word help that is a descendant of a li element that is a descendant of any element with an id attribute that equals nav_main”

Note: A very interesting tool that you can use to understand more how descendant selectors work is Selectoracle. I would strongly recommend spending some time with this tool if you are new to CSS world.

Pseudo classes

These are used to communicate state. Very common example is the various states of an anchor tag (<a>) like “link”, ”visited”, “hover” and “active”. These are primarily used to add special effects to some selectors. For example:

a:link {declarations} /* unvisited link */

a:visited {declarations} /* visited link */

a:hover {declarations} /* mouse over link */

a:active {declarations} /* selected link */

Notice that we need to put colon (:) after the selector while using a pseudo class.

You need to be very careful when using pseudo classes as it can bring in some cross browser compatibility issues. There is a nice matrix available illustrating various pseudo classes and its compatibilities “CSS selectors and pseudo selectors browser compatibility”.

You can read more about CSS selectors here.

CSS Declaration

Declaration includes various properties and its values. So once the selector is used to identify the element, the properties of the element included in the declaration will be set to the value as per the declaration. For example:

background-color:Red; /* Set background color to red */

border:1px; /* Set border width to 1px */

One thing worth mentioning is the granularity of properties. For example “font” properties can be used to set all the below properties:

font

font-style

font-variant

font-weight

font-size/line-height

font-family

caption

icon

menu

message-box

small-caption

status-bar

inherit

While dealing with properties granularity one thing that can come handy is to know the shorthand to set values of these granular properties. For example:

font:italics 15px arial; /*Set font style to italics, font width to 15px and font family to arial*/

is same as

font-style:italic;

font-size:15px;

font-family:Arial

Border is another property which you might come across with lot of granularity. While using shorthand it is important to know the order in which these properties are assigned.

Understanding the “Cascade” in CSS

As discussed earlier browser uses selector pattern matching to identify the element to which style need to be applied. What happens when more than one declaration having the same property but with different value gets applied to the same element?

Browser uses the following criteria to determine the declaration that will get applied:

1. Importance (using !Important keyword)

2. Origin (3 different origins: author, user and user agent)

3. Specificity

I will be only covering the Specificity in this blog. You can read more about cascading rules here.

Let us use an example to understand the “Specificity” effect.

Consider the following section of the DOM below:

<div id=”first”>

<div id=”second”>

<h1>Hello Reader</h1>

</div>

</div>

Now let us say you have the following CSS:

#first h1 {color:Green}

#first h1 {color:Black}

What will be the color of h1?

Answer is black.

So in short, the last declaration wins, easy? Not very true let me give you a second scenario.

#first #second h1 {color:Green}

#first h1 {color:Black}

What will be the color of h1 this time?

Answer is green.

So what is said before “last declaration wins” is not completely correct. So the correct rule is “the last and most specific declaration wins”.

What is meant by specific or how to calculate specificity?

Specificity is calculated based on the following point system:

ID selector = 100 points

Class selector = 10 points

Element selector = 1 point

Now let us apply this point system in our above example.

#first #second h1 {color:Green} = 100+100+1=201

#first h1 {color:Black} = 100 + 1 = 101

So now you know the declaration setting the green won over declaration setting the color black even when it appeared second in the order.

Understanding CSS Inheritance

Let us use the above DOM section and try to understand the inheritance.

<style>

#Div1 #Div2 { color:Red}

</style>

<div id=”first”>

<div id=”second”>

<h1>Hello Reader</h1>

</div>

</div>

See how it renders on the browser below:

So even though the style was only applied to the container <div> element the <h1> element inherited the color.

Most of the properties are inheritable not all though. Simplest way to memorize which properties can and cannot inherit is by memorizing the following principle:

“Text related properties gets inherited, layout related properties don’t”

The table below includes most commonly used text and layout related properties:

The “Box Model”

Before we wind up I would like to briefly touch the “Box Model” which is basic but a very important concept in CSS. I will use the image below to depict the Box Model:

So now that you have an understanding what and where padding, border etc fit in the box model let us try to set some values.

For example:

Border: 1px; - Set border width (top, right, bottom and left) to 1px

Border: 1px 2 px – Set top and bottom border width to 1px and left and right to 2px

Border: 1px 2px 3px 4px – Set border width top to 1px, right to 2px, bottom to 3px and left to 4px

Notice that values are set in the clockwise order.

You can read more on Box Model here.

Hope this blog helped to you to have some basic understanding of various concepts of CSS. I would like to thank my colleague Joydeep Das who is a design consultant for his valuable inputs to various sections of this blog.

1.       Optimizing ASP.NET web application - Part 1 (Let the journey begin)

2.       Optimizing ASP.NET web application - Part 2 (Measuring Performance)

In this blog we will be focusing on optimization techniques which can be applied at ASP.NET level. For example I will not be covering Static/Dynamic compression as it will be covered in a later blog in this series “IIS Level Optimization techniques”.

Set debug=”false”

Yes this is trivial but if missed can have a great performance implication. Make sure your web.config never has this entry:

<compilation debug=”true”/>

You can even delete the complete entry as the default value for “debug” is “false”.  This is completely different from the debug/release build mode in Visual Studio rather has only to do with how asp.net pages are compiled and served. You can read more about the why you should never have debug=”true” in ScottGu’s blog “Don’t run production ASP.NET Applications with debug=”true” enabled”

Optimizing ViewState

First of all if you don’t need ViewState support on a particular page, explicitly disable the same in the Page directive:

“EnableViewState=false”

Disabling ViewState at page level alone would not solve your problem entirely you will have set it at different control level to ensure ViewState of the page is completely empty.  This is because of the ControlState introduced in ASP.NET 2.0 which is independent from ViewState yet stored in the same hidden variable.

Note: To measure ViewState you can use Fiddler extension ASP.NET ViewState Helper.

Most of the time disabling ViewState will not be an option in such case I would recommend to use ViewState compression techniques. My colleague Manoj Garg has a very detailed blog entry on how to compress ViewState and also explain about the relationship between ViewState and ControlState.

I have also come across some techniques in which ViewState is stored in the server (Session) there by completely eliminating the ViewState bytes from the page size. Scott Hanselman has a blog entry explaining how to do the same. 

Optimizing Session State

I would recommend everyone of you to read this interesting MSDN article on ASP.NET session state management “Fast, Scalable, and Secure Session State Management for Your Web Applications”. 

Let me briefly explain how the session works. Session state feature is implemented by the “SessionStateModule” which is a httpmodule that is plugged into the asp.net request processing pipeline.  This module hooks into to request state related events “AcquireRequestState” and “ReleaseRequestState”. During the AcquireRequestState the Session ID is retrieved from the request and used to fetch the session information from the session store. During the ReleaseRequestState, either a new session ID (initial request which require session) is created to store the session details or if the session ID already exist session store will be updated with the changes. 

Optimization strategy will depend on whether you are using in-proc or out-proc session management.  There are some common optimization principles that are applicable to both in-proc and out-proc scenario:

1.       Disable Session State on pages which don’t need session

This will mean that session state will not be loaded from the store at the beginning of the request or stored into the store at the end of response.

This can be either done at the page level or application level.

Page Level:

<%@ Page EnableSessionState=”False” %>

Application level:

<configuration>

                                <system.web>

                                                <pages enableSessionState=”false” />

                                </system.web>

</configuration>

Note: Even when session is disabled at the page level there will be still some call to session store to mark session as accessed to prevent session from getting expired.

2.       Set Read-Only Session Access

There are many scenarios in which we cannot disable session for a page but then we might be able to mark session access as read-only as the page is only reading from session. When set to read-only loading of session and marking session as accessed will only be done and will not involve any update or insert activity.

This can be either done at the page level or application level.

Page Level:

<%@ Page EnableSessionState=”ReadOnly” %>

Application Level:

<configuration>

    <system.web>

        <pages enableSessionState=”ReadOnly” />

    </system.web>

</configuration>

3.       Reduce amount of session data

Size of data stored in session will have serious implication on the performance of each request as the session data need to be loaded for each request. Magnitude of the performance impact increases multifold in case of out-proc session management. Now the question is how you will measure the session state. Till date I have not found any easy mechanism to retrieve this information and what I fall back on is the technique of changing the session store to SQL Server and measure the size over there. (If any of you are aware about a better or at least easier solution please post it as a comment)

4.       Manage what is in your session

Apart from the size it also matter what is stored in the session as the type of the content will determine the serialization cost incurred especially when you are using out-proc session management. Primarily session state use custom serialization mechanism to convert the session data into binary blob which has direct support for .NET Framework primitive types. So I would recommend avoiding storing objects in session and rather stick to using primitive data types whenever possible.

If you are using out-proc session I would recommend having a custom implementation of SessionIDManager class so that you can optimize both fetching of session ID and also marking session accessed so that it best suits your requirement.

One other feature that you can look at while using out-proc session is the concept of Session Partitioning. I won’t be covering the details of how to implement session partitioning but if you are interested in knowing more about the same there is a very nice blog by Maarten Balliauw covering session partition in detail. In short State partitioning enables the session data and the associated processing load to be divided between multiple out-of-process state stores, allowing the session state load to scale as the Web farm grows and the number of concurrent session increases. 

Optimizing Images

Yes this is trivial again but I must say based on my experience at 7 out of 10 web application miss to ensure that all the images used are optimized. Image optimization involve two aspects

1.       Reduction of image size

2.       Reduction of image count (in turn reduce request count)

Regarding reducing the image size, If you are fortunate to have a graphic designer in your team use his/her expertise and if your unfortunate you can use tool like RIOT or similar tool.

Regarding reducing the image count you can try to apply CSS sprites which will help you to combine multiple images into one. I will not go into details of what CSS sprites are and how it is done but you can read more about CSS Sprites in here. But rather I would like to mention an interesting framework I came across recently which can help you use sprites is a much friendlier manner, Sprite and Image Optimization Framework. It is still in preview and here is a quick video on how to use this framework. 

Optimizing CSS and Script files

Again by optimization I mean:

1.       Reduction of file size

2.       Reduction of file count (in turn reduce request count)

One of the techniques used to reduce the size of file is called Minification. Few of the leading minifier frameworks which you can use are:

1.       YUI Compressor

2.       Google Closure Minifier/Complier

3.       Microsoft Ajax Minifier

4.       Packer.NET

(There are many more but these are only ones I am familiar with L ). Most the above framework also provides you a feature which can further reduce the size called obfuscation. Word of caution use this feature very prudently especially on your custom script files as these is a more intrusive process which involve optimizing your variable and function names etc.

You should try to make minification as the part of your build process. MSBuild guru Sayed Ibrahim Hashimi has a blog entry how to add minification as part of your build process using Packer.NET. There are also build task like MS AJAX minifier Task, YUI Build Task etc which you can use in your build script to achieve the same.

Second technique that you can to reduce the file size is compression. On approach I have seen being used to achieve compression is by using custom handler (ashx). Custom handler will serve the compressed CSS and JS files. Although I have used this approach in the past I have been never a big fan of this approach as compression can be better achieved by using IIS compression. But custom handlers approach can be useful when your web application is hosted on a Shared

Omar Al Zabir wrote an interesting article in which he explains how we can use the custom handler approach not just to compress the files but also combine the files.

Combining CSS and JS file will help us reduce the request counts which in turn will make your web page render fast.

Before we conclude I would like to add the following rules pertaining to CSS and JS files to be followed to ensure web page performance:

1.       Put CSS at the Top (Rule 5)

2.       Move Scripts to the Bottom (Rule 6)

Having CSS included in the HEAD tag allows the page render progressively. Moving JS to bottom again enable progressive rendering but also improve download parallelism as JS request are blocking calls.

Detailed explanation of these rules and how violation of these rules can adversely impact the page performance in covered in the link (associated with the rule)

There are many more optimization techniques that can be applied at ASP.NET level which I would be covering as the part of this series. But to keep each blog entry to a reasonable size I will be covering them in the next blog in the series.

This is the second blog in a series of blogs which would be focusing on optimizing the performance of an ASP.NET web application. In the first part I tried to explain where we should start while investigating the poor performance and why measuring the performance is the key to the entire exercise of performance optimization.

Let me set the context for this blog with an acronym:

YCMWYCM – You Can’t Manage What You Can’t Measure

Getting the accurate measure is not only important to assess the performance but also to assess how each of the optimization technique improved the performance of your website.

Traditionally there are 2 approaches when it comes to measuring website performance

1.      JavaScript instrumentation

2.      Using tools which are either proxies/sniffers (Fiddler, Charles proxy etc) or browser plugins (YSlow, HttpWatch etc)

Although listed first I will recommend to start with using tool primarily due to the ease with which you can get performance metrics of your website. For the completion of the blog I will also cover JS instrumentation and also some recent initiative in this direction.

Using Tools

Today we have too many tools at our disposal when it comes to obtain relatively a very accurate measure of the performance. To name few of them:

Fiddler (my favorite)

HttpWatch

Charles proxy (Not a freeware)

Wireshark (Can go beyond HTTP)

DynaTrace

YSlow (From Yahoo)

PageSpeed (From Google)

Technically you can categorize these tools into either http proxies/sniffers or browser plugins. Both of them have their own strengths and weakness. Tool selection should not be based on technique used rather should based on whether  you want to measure is Response Time or Perceived Response Time.

Dictionary definition of Response Time is:

The time elapsed between a stimulus and the response to it.

So in terms of web application, response time would mean:

The time elapsed between the first byte sent by the browser as the part of a page request and the last byte of the page received including all objects in the page like image, JavaScript etc

Defining perceived response time is a more complex subject. For simplicity let us say it is the time when the user perceives the page to be loaded.  If you want to master this concept I would recommend you to have read “Designing and Engineering Time: The Psychology of Time Perception in Software”

Response times of a website can be measured using http proxies/sniffers whereas browser plugins can do a better job when it comes to measuring the perceived response time.

I would recommend to start with measuring the response time and my favorite tool is Fiddler. It is an essential tool that every developer should have some degree of mastery on.  There is an introductory video on the fiddler website that will get you up to speed.  Reasons why I like fiddler the most are:

·         It is free

·         Extensibility: It is easy to extend the existing feature especially with my favorite language c#. Read more here

·         Fiddler Extension:  There quite a number of very handy Fiddler extensions available at this location.

A detailed dive into fiddler is not within the scope of this blog (but will be writing one pretty soon as it is long overdue).

Being my favorite does not make Fiddler in anyway the best choice available. Would recommend everyone to have anyone of the tool as their favorite and only switch between tool when the need arise. For example there are times when I use Wireshark when I suspect that the problem is deeper than the http layer.

When it comes of browser plugins some of the preferred choices are YSlow, PageSpeed but these only work with Firebug/Firefox. Considering the percentage of internet user using IE (Stats) it is important for any website to also measure the performance on IE.  Most of the time I used PageTest  or I must say was the only option. Recently I came across a one more interesting option from MySpace, MSFast.

One additional tool I would highly recommend is DynaTrace, especially due to the fact that it is capable to capture the performance measures like JavaScript execution, Rendering Time, CPU Utilization, Asynchronous Requests and Network Requests.  DynaTrace used to only support IE browser but from DynaTrace 3.0 beta it also supports Firefox.

JavaScript instrumentation

I am sure most of you would have used JavaScript “getTime()” method to measure performance of some method or some critical code path. JavaScript instrumentation at the core uses the same technique.  But then it was primarily during the development phase. Using this technique on a live site is fairly tricky and the most important pitfall is the impact on performance due to instrumentation code. The other big challenge is how and where to collect the data generated by your instrumentation code.

One interesting framework I came across that makes it very easy to instrument your JS is Jiffy. Jiffy primarily has a library that makes instrumentation very easy and measure suite that include a proxy and DB. Now the problem is that I have not seen any update to the project for a long long time.

My favorite one when it comes to JS instrumentation is Boomerang from Yahoo. Of course there is Episodes from Steve Sounders but unfortunately never had a chance to explore this framework.

There were some interesting initiative by Microsoft along these lines but due to some reason never came to limelight. One which I caught my interest was Ajax View JavaScript Instrumentation Proxy, which saved my time of writing the instrumentation code. I am not sure but I guess Microsoft used this same proxy in Microsoft Visual Studio AJAX Profiling Extensions, but I never used this extension so cannot comment on its effectiveness.

Now as I mentioned early most of these instrumentation framework uses “getTime()” method either having it at the beginning of document or writing into cookie during onbeforeunload event of the previous page.

But then one fine day I read a very interesting blog by none other than the JavaScript guru, John Resign about the accuracy of the “getTime()”.  In simple language there is going to be some percentage of error when you use JavaScript “getTime()”.  This put a very big question mark on the output of most of the frameworks.

Finally there is something from W3C, a Web Timing API specification for browser which can be used by the developers to accurately measure website performance using JavaScript. For change IE was the first one to ride on this new wave. A prototype implementation of the Web Timings NavigationTiming interface called window.msPerformance.timing is available with IE9. Now it is possible to retrieve performance information from this interface as soon as the DOM finishes loading.

Both Chrome and Firefox will be soon providing a similar implementation. Read more about update from Chrome team here and from Firefox team here.

Before I finish one quick update as per the Philip Tellis of Yahoo Performance team, in this recent blog post

“Website is too slow” how many of you have heard this complaint either from your manager or client or worst case from the end user. Fortunately I have heard this few times

General trend I have seen is that the dev team is pushed into a “stress + stretch” mode and project crash landing into the red zone and attracting lot of attention all for wrong reasons.

From my experience before any analysis or troubleshoot the most pivotal task is to ask this simple question. “What is considered good website performance?”

Let me tell you this, it is a very tricky and tough question to answer and require some meticulous analysis to come up with a pragmatic performance matrix for a website. But then I even had client responding the next day with a simple answer “page load time of 1 sec for every webpage on the website” J.

Now I want to make a very critical differentiation of term “Poor Performance”. The approach of optimization will completely change based on the context where this term is used. Primarily there can be 2 most important contexts:

1.       New website is performing poorly.

2.       High performing existing website started performing poorly.

When I refer to poor performance I will be referring to the first context. Although many of the techniques explained in the series can be also used when dealing with poor performance in second context if not already used.

Before saying good bye to the second context I would like to very briefly explain the approach I use in this context. When dealing with the second context both investigation and optimization should happen in the following order:

HardwareàOSàServer ApplicationàApplication

For example if you are looking into poor database performance in the second context, the order would be:

Physical machineàWindows OSàSQL ServeràDatabaseàTableàQuery

Although most of the time it is done in the reverse direction starting with optimization of queries which I never felt as a cost effective and efficient approach but then it is just my view.

I am iterating the scope again to avoid any confusion, the beast we are trying to tame is poor performance of a new application.

Where do we start?

Again the general trend I have seen starts with team looking into queries, missing indexes, primarily looking for the problem in the DB. Whereas in some case team would look into the code to identify any possible scope for improvement or rectification of bottlenecks.

My answer to this question is simple “Start from where it is closest to the end user” i.e. from the browser.

One aspect lot of us don’t realize is the fact that the time spend by the page to render itself on the browser has really gone up from those days of simple HTML. I have seen cases when browser render time of the page accounted for something in the range from 30% to 70% of the total page load time.

Other reasons for starting from the browser are the fact that most of optimization techniques used at this level is simple to implement, agnostic of the application logic and improvement in the performance is experienced by the end users instantaneously.

Now that we have decided where to start from what is the next step?

Measure your performance, which we will cover in the next part of the series.

 Optimizing ASP.NET web application - Part 2 (Measuring Performance)

 Optimizing ASP.NET web application - Part 3a ASP.NET Level Optimization Techniques

All knowledge is not equally useful all the time. Any particular piece of knowledge gets more valuable as you move closer to its application and diminishes more or less quickly thereafter. If you graph the value of the knowledge as a curve — with utility along the y-axis and time along the x-axis, the change in direction of the slope from positive to negative might be considered the knowledge inflection point.

When we speak about Knowledge as a Service℠ (KaaS) we are really talking about moving the point of knowledge acquisition as close as possible to the knowledge inflection point — without going beyond. This is what distinguishes KaaS as a field as opposed to other kinds of knowledge services such as classroom teaching or scientific research. The fact that KaaS is modeled after SaaS is no accident, since a running software process might be considered a particular kind of knowledge, as discussed recently by Forrester analyst Holger Kisker. The fact that software is not self-aware is not the critical distinction. What is critical though — for both KaaS and SaaS — is this idea that getting close to, but not going beyond, the knowledge inflection point is what counts.

There are lots of interesting observations to be made about knowledge inflection points. One is that any real world process — like implementing an IT system — can be viewed as a series of multiple knowledge inflection points. As you solve one problem, another emerges on the horizon — and your knowledge acquisition must rise to the occasion in time. Until the process lifecycle is complete, you must ride these successive “waves” successfully without falling off.

For more on the knowledge inflection point, and to see an example from the world of SAP customer support, check out our recent white paper here.

* Communities * Content * Communication *Conversations

Communities: Humans are social creature and associating with a ‘tribe’ is a very basic instinct for most of us. We identify ourselves by the places where we were born or live, schools we attended, religious beliefs we practice, professions organization we belong to, companies we work for and a whole slew of such groupings. The groups can be professional or personal and everything in between. Web 1.0 was very informational centric and did not include the community aspect. It did not foster any sense of community, the sense of belonging. So in a sense Web 1.0 did very little to address one of the very basic human nature.

Content: Content is king. However not all kings are created equals, there are emperors, kings and chiefs. Similarly all content is not created equal. In content world, one of the biggest differentiator is content creator. In the world of Web 1.0, because of the inherent cost related to content publishing and distribution, content was locked-up to the few. For example corporate marketing defined all out bound messaging. However, within any industry, groups or company there are leaders and experts, example company CTO or somebody who is an influencer in your group. Their voice and opinions are important to a more targeted group. The third type of content is the idle chat between friends, or a water cooler talk between co-workers, think Facebook. People have various personas, and there is place for all these types of conversation in each person’s life.

Whereas Web 1.0 was mostly for the first persona of content creators, Web 2.0 covers all types of content. In the Web 2.0 world, Wikipedia replaced Encyclopedias, Corporate Wiki replaced the intranet and your LinkedIn post of “Tell your network what you are doing” and IM status replaced the Post-it notes of “Do not disturb” sign outside the cubicle.

Communication: Communication is a two way dialog. In the real world it happens top down, bottom up, and sideways. The first version of the web was top down, talk only as it had no listen capability. In a sense it allowed for a very uninteresting monolog. Web 2.0 is about two way communication, it is about a dialog.

It put people and their communities in the center of all the dialogs. In the first incarnation of the web, this interaction was left to the physical world. Communication is about collaboration and conversations. It is about linking, sharing and interacting. Web 2.0 provided a platform to do all of this.

With so much content and so many conversations and no moderator, the problem of information overload became even more acute. Web 2.0 addressed this problem with a unique ‘wisdom of the crowds’ who provide the moderation by ‘following on twitter’, rating and ranking associated with both the content providers and their content. Comments, bookmarks, ‘..also bought’ (at Amazon), thumbs-up/ down, defined the features that link between relevant content to their communities and allowed them to have a meaningful conversation.

What role has Web 2.0 played in giving rise to the era of blogging and to social networking?

Some of the key Web 2.0 technologies include

*Social Networking site

*Wikis, Blogs & Micro blog

*Mash-ups, Video and Podcast

There are five specific business objectives of most communication — to listen, to talk, to energize, to support, and to embrace. Individuals and companies are using Web 2.0 technologies to communicate with their customers, business partners, employees and their industry groups. Blogging and Social networking are two of the more widely adopted Web 2.0 technologies.

Often time, the users for these tools are viewed as outside of the company, but the audience can very likely be your employees too. Initial adoption of these technologies was done by companies trying to sell directly to the consumer, but companies that have traditionally sold to the Fortune 2000 or to SMB are also starting to adopt ways to bring these tools into their portfolio. The initial adopters of these tools were people who were in the front end of the sales and marketing, but now applications are being developed that are using these tools to support internal and backend processes. Imagine the CEO of a company who wants to engage in ‘chat dialog’ with thousands of employees. Think of the CTO who wants to communicate his product/ architecture vision to the engineers while including constructive feedback from his entire team. These tools are the enablers of these conversations.

So how has the rise of Web 2.0 affected business and changed the way people work.

Web 2.0 is still in its infancy within most organizations. However it has the prospect of changing how marketing departments engages with prospects and customers, how product managers interact with internal and external stake holders, how hiring and recruitment is done, how training is delivered, or how customer support performs their activities today. For example, it is not uncommon that marketing updates their websites once a quarter or every six months with messages that are very carefully crafted but that is totally gibberish to most. It does not have to happen that way. There is no reason why training departments should only conduct instructor led courses that are conducted at prescheduled times that are inconvenient to all and topics that are relevant to few.

Where is the web 2.0 heading

The future is hard to predict. However, some places where Web 2.0 is most like to go next could be..

•Adoption of these tools within the enterprise. Companies shall start using these constructs to reduce the friction and increase the speed in how work is done. Some have labeled this as ‘Enterprise 2.0’. Today integration of the corporate tools such as email, documents etc. is missing. Addressing issues such as security, compliance, would be important before these tools get wider acceptance within enterprise.

•Web 2.0 is very text oriented today. Video, animation, audio, mobile smart phones are some fairly unexplored areas in the web 2.0 world.

•So far Web 2.0 is mostly about free to consumers. Rise of the private club, where members pay to participate or pay for premium services, B2B services is another area that is relatively unexplored.