Serialization at Client Side

Serialization is a process of converting Object into Raw data.In javascript many times we need to convert Raw data into Object and viceversa.
For example, when we submit a form, Its data needs to be sent to the server in JSON form.

• Serialization is the process of turning any object into a string.
• De-serialization turns that string back into a native object.

JSON is a lightweight data-interchange format inspired by JavaScript object literal notation.
Certain framework provides method to convert Model, Form data into JSON.
For eg backbone.js provieds following

• Model.toJSON for serialization
• Model.parse for de-serialization

Once we have JSON library we can use the two most useful methods whcih are availble:

• JSON.stringify(obj) — converts an JavaScript object to a JSON string
• JSON.parse(str) — converts a JSON string back to a JavaScript object

 Both are really cool features which we can use where we are interarcting with web services and serer is going to use the object to marshal into a Java Object.

Test Framework setup

In this blog we will talk about setting up a Test framework.Unit test case helps the application in many ways.For eg in finding Bugs, detecting regression, designing Software Components.

For a desktop based swing application we are pretty much clear on the classes and methods which will need to be added in the test cases.

In a multi tiered J2EE application the question comes is should we write a test case for each layer (Service/ Business /DAO layer) of the application separately?

The answer is ‘YES’ (full proof over engineering) and partly ‘NO’. We will need to write test cases for Service layer and DAO layer separately. We can test the DB system testing by writing test cases for DAO Layer. Similarly we can test the functional behaviour by writing test cases for service layer. A Business layer  is being accessed only by the services layer then we do not need to write a test case for the business layer since service layer is the only consume for which a Test case might have been already defined.

What all options we have, to set up a Testing framework?

Strategies we can go with are

• Create a Test specific DAO spring configuration
• Use different database for executing the Tests cases.
• Use in memory database for eg you can use HSQL DB.
• Write Test specific DAO implementation class: Let’s write a DAO implementation class
• Simplify testing environment by providing empty proxies instead of complex logical units. In other words replace all collaborators with mocks

 OK Now my Testing framework is UP. 

 Do we need to write test cases for all the(non private) method?

No.Test only the core functionality of a class or a method.Or all the methods which we can think of a logical or system operation.

Fine. I have my Testing framework. I have identified the behaviors and methods for which Test case need to be added. what all thing we need to keep in our mind while writing Junit Test cases?

• Write one test-condition per test method
•  When testing output of Collections (List, Set) test for Null and Emptiness
•  Use java reflections for adding new methods into test suites
•  Compare the objects after performing an operation
• Test the exceptions
•  Group logical test cases into test suites
• Check for order of execution of test cases
•  Always include a message to assertion
• Write test cases for each condition
• Write each test case to test only one thing
• The more are the number of test cases the more will get the test coverage
• Make each Test process independent to each others
• Avoid unnecessary preconditions
• Name your unit tests clearly and consistently
• Avoid the use of context with specific setup

That sounds good.We are done with the Unit test cases.After going through couple of testings(Smoke and Sanity) we will be in good shape to move into the Production.

TDD : Most Suitable Scenarios

Having said in the previous blog on TDD : Test Driven Development  now we know the recipe and it’s time understand when to cook this food.

 Points are bulleted as below: 

• When the product is complex 
• Product having lot of dependencies
• When you want to sell your product
• Frequent releases
• Very short development cycle
• Winning the trust from Client
• Agile development
• Enhancing or migrating your legacy code
• When the development is happening on a matured product
• When the emphasis is more on quality than delivering much functionality
• Deadlines are not very much aggressive .
•  Availability of sufficient number of resources
• When you want reduced risk in the Production environment
• Requirements are clear
• When we want more attention to Design  
• Relying more on Continues Integration
• Parallel distributed development
• Large Teams 
• Designing robust software components
• More clarity from the Product management 
•  Suffiicient Test coverage
• Automated regression

I hope things are very much clear now and many of the points above are self explanatory. TDD is followed in most of the big companies like Google, Facebook, Yahoo.
 With this we should be fairly confident in taking decisions in going with TDD which says  'SPECIFY FIRST'.

TDD : Test Driven Development

 Red -->Green --->Refactor

 Write the tests first.fail the test cases. This is what the main philosophy of TDD This paradigm can also be used in debugging legacy code.In this Blog we are going to talk about TDD methodology.

 Following are the steps for following TDD:

• Add a test
• Run all tests and see if the new one fails
• Write some code
• Run the automated tests and see them succeed
• Refactor code
• Repeat
• Keep the unit small.
• If require we can mock objects for eg sum third party services, DB we may use a mocking framework like EasyMock,Jmockit, Mockito.

What are the benefits of TDD?

• Test Coverage.
• Test Repeatability.
• Documentation
• API Design
• System Design
• Reduced Debugging.
• Your code worked a minute ago

Now the question is what are the costs of TDD?

•  Programming in tiny cycles can seem inefficient
•  A lot of test code is produced
•  A lot of time is spent keeping the tests in sync with the production code

 Some time people says  'SPECIFY FIRST' which means the specify the desired behavior in testms of test case.In the next blog TDD:Most Suitable Scenarios we will see some practical example where TDD suits best.

Developing Mobile Website

There are various options available for Mobile application. Many times we prefer to develop unique apps for each mobile devices or OS. The other option is to have a single highly-branded web site or application that will work on all popular smartphone, tablet, and desktop platform.

Mobile Web application development: 

Developing a web application for Mobile is going to be definitely faster. It does not require specific skills to develop a web application.You do not need to do OS specific coding.There is no need to hire Android developer and Iphone developers separatly to build device specific Application. However there is also a downfall here which is with respect to usability. 
The user will not get device specific rich interfaces and It will have limited animation. This means we have to take proper judgement on the basis of the feature the website is going to provide.quesion which we should think are

• Does It require Rich UI? 
• Will my web application suffice the user needs withe least amount of time without downloading any thing to their device?

Developing a Mobile application

Mobile development is more than cross-browser; it should be cross-platform

Android user could access your site using the native Android browser, or could have also installed Opera Mini or Firefox Mobile.

Lets see few browsers which are available on dfiffent devices:

•Opera Mobile
•Skyfire
•Safari
•Google Android
•Microsoft IE for Mobile
•Firefox Mobile

Redirect to mobile Sub domain:

Based on the user agent the main domain will redirect to its mobile domain.

eg. User Agent for Froyo on a Nexus

Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

The "Mobile" string in the User Agent indicate that the request has come from a mobile device. For eg Facebook will redirect to their mobile web site m.facebook.com.

Apply mobile stylesheets:

Here we will apply the stylesheet which are specific to mobile only.

Jquery Mobile:

The advantage here is that jQuery mobile framework takes the "write less, do more" mantra to the next level: Instead of writing unique apps for each mobile device or OS, the jQuery mobile framework allows you to design a single highly-branded web site or application that will work on all popular Smartphone, tablet, and desktop platform.

The framework includes an Ajax navigation system that brings animated page transitions and a core set of UI widgets: pages, dialogs, toolbars, listviews, buttons with icons, form elements, accordions, collapsibles, and more.

The most significant thing about Jquery mobile is that same piece of code automatically handles the device and based on the space and available It adjusts as per the ambient accordingly .This framework has been tested on most of the mobile devices and mobile browsers. 

Restrict to core featutes:

 Since there is limitation of space available because of reduced screen size we can provide the core functionality only. For eg The screen will have  header , page-content, and footer only.No need to have menu list either on the Left or on below the Header section. This ensures that the core feature will have optimum space to be shown in most fashionable and appealing look.

 For more refer to
http://en.wikipedia.org/wiki/Mobile_application_development