less-known-facts-of-mahabharatham-great

less-known-facts-of-mahabharatham-great

Mahabharata is such a vast treasure house of facts and knowledge that it is impossible for anyone to know everything!

தாவனி

For your Loved ones

My AAMEC Friends

My AAMEC Friends

Power of Friendship

கல்லூரி

கல்லூரி நண்பர்களுடன்

நட்சத்திரங்களை நான் ரசித்தேன் அதுபோல் நானும் என் நண்பர்களுடன் இருக்க விரும்பியதால்...!

sachin-tendulkar-retires-famous-quotes

sachin-tendulkar-retires-famous-quotes

Commit all your crimes when Sachin is batting. They will go unnoticed because even the Lord is watching

தனிமை


சில நேரங்களில் 
தனிமையின் மடியில் 
நான் தவழ...
இருள் சூழ்ந்த 
காட்டில் தனியே 
மனம் பரிதவிக்க,...
இமை இமைக்கும் 
நொடி கூட 
நெடு நேரம் நீள,...உயிர் துடிக்கும் 
இதயம், உறவின்றி 
வலியோடு ஏங்க..
வாழ்க்கை பயணம் 
விடியாமல், ஒரு 
புரியாத புதிராய்..
இவ்வாழ்வில் 
துணை இன்றி, 
உன் நிழல் கூட 
இங்கு பொய்யே..

Hybrid Mobile App's - Ongoing Mobile revolution

Quite after a long time come up with a post on one of the Current trend on Mobile Application Development , Hybrid Mobile Applications.

Hybrid” applications are a special category of web applications that extend the web-based application environment through their use of native platform APIs available on a given device. The hybrid application design pattern is equally applicable to both mobile and desktop environments.

Hybrid mobile apps are like any other apps you’ll find on your phone. They install on your device. You can find them in app stores. With them, you can play games, engage your friends through social media, take photos, track your health, and much more.


How are hybrid mobile apps built?


Hybrid mobile applications are built in a similar manner as websites. Both use a combination of technologies like HTML, CSS, and JavaScript. However, instead of targeting a mobile browser, hybrid applications target a Web-view hosted inside a native container. This enables them to do things like access hardware capabilities of the mobile device. These are capabilities that are often restricted to access from inside mobile browsers.

What are the motivations to go hybrid?


Hybrid mobile applications provide a way for developers to re-use their existing skills in web development. Developers don’t like the prospect of getting locked into proprietary platforms. This includes the programming languages and SDK's provided by platform vendors. Hybrid mobile application development looks appealing to an organization’s bottom line. Why hire a developer for each platform when you can hire one developer and target all of them through HTML, CSS, and JavaScript? Well, the reality is a bit more complicated. Yes, it’s true that hybrid mobile application development enables developers to target more than one platform. However, each platform comes with a set of caveats when it comes to its web run-time or Web-view. This is especially true with Android, which is inconsistent between OS versions. Moreover, there might be unique capabilities of platforms to which a developer may wish to target. In those instances, a combination of plugins and platform-specific code must be utilized in order to take advantages of those capabilities.

When should you build a hybrid mobile app?


Before committing to a platform strategy, it’s important to evaluate the technical and non-technical merits of hybrid versus alternatives like web and native – especially as it relates to your mobile application’s requirements. For example:
  • Which mobile platforms do you wish to target?
  • Do you want to distribute your application via app stores?
  • Are you looking to utilize the capabilities of the mobile device?
  • What are the technical abilities of your development team?
  • Does the one-size-fit-all approach of hybrid really live up to its promise?
These and other questions are worth asking before embarking upon development of a mobile application. To elaborate on this, let’s examine a few of these questions in more detail.

  • WHICH MOBILE PLATFORMS DO YOU WISH TO TARGET?

If you wish to target more than one platform, you have a number of choices. Clearly, the web offers a highly attractive solution for this requirement. Your target is the mobile browser. Hybrid lends itself well to this approach as well because of its reliance upon the WebView.
Native – on the other hand – finds itself in a unique space. If you are reliant upon the vendor SDKs and platform-specific programming languages then you are essentially coupled to the platform. In the case of iOS, it’s Objective-C or Swift; for Android, it’s Java; and for Windows Phone, it’s C#.

  • DO YOU WANT TO DISTRIBUTE YOUR APPLICATION VIA APP STORES?

If you want to distribute your application via an app store, you must build a hybrid or native application. You cannot distribute websites through app stores; that’s what your browser’s address bar is for! Despite this restriction, whether you build a hybrid or native application, it’s highly recommended that you have a website available for your mobile application. This will be the first place your users will expect to go if/when they encounter problems.

  • ARE YOU LOOKING TO UTILIZE THE CAPABILITIES OF THE MOBILE DEVICE?

Websites have a restricted set of abilities as opposed to hybrid and native applications. These restrictions are enforced by browser, effectively sandboxing it away from the mobile operating system. Recent developments with mobile browsers have exposed more device capabilities through HTML5 such as the camera, geolocation, and others.
Despite these advancements, support for advanced functionality is quite limited. For example, media capture and streaming remains unsupported in various mobile browsers. Because limitations like this remain in mobile browsers, many developers are compelled to evaluate hybrid and native as alteratives. Both offer the ability for developers to access device APIs – in the case of hybrid, this ability is supported through plug-ins.
It’s often asserted that native is best suited for applications where graphics performance is paramount. Mobile games are a class of mobile application almost entirely reliant upon complex visual interactions on the screen. Even if a game operates flawlessly from a functional perspective, you should expect it to have a very low app store rating if it feels slugglish. For that reason, developers have long-argued against using hybrid as an approach to build games.
That stated, a number of solutions for hybrid mobile applications exist. These include HTML5 Canvas and WebGL, both of which are well-suited for building applications like games. Furthermore, technologies like these are more approachable for developers through libraries like Paper.jsEaselJS, and others. And it’s not just for game development. For developers building more traditional, line-of-business applications, there are frameworks like Famo.us and Kendo UI.

  • WHAT ARE THE TECHNICAL ABILITIES OF YOUR DEVELOPMENT TEAM?

Another factor to consider when evaluating your development options for mobile is your team’s technical abilities. If you decide to build a native application, you will require developers who are experienced with the platform SDKs and programming languages of every platform you wish to target. On the other hand, web and hybrid applications are built using web technologies like HTML, CSS, and JavaScript. You can have a team that can target multiple platforms with a single set of technologies. This is something worth considering when evaluating your opinions.

Key Characteristics of Hybrid Apps

Unlike web applications or mobile websites, which the user can access by browsing to the URL, hybrid apps are typically installed through an app store and are available through the platform application launcher. This means users have to follow the same procedure to install hybrid application, as they would have for native applications. The platform will ask users to grant device access permission upon installation.

NOTE

There is a lot value in developing platform-specific UIs, and you may eventually want to do it once your application usage crosses a certain threshold. Having said that, it should be relatively straightforward in the case of hybrid applications using CSS.

Why Developing Hybrid Apps Makes Sense

Hybrid apps have the unique ability of reaping all the benefits of traditional web applications without many of its limitations.
The benefits of hybrid apps compared to native include:
Faster time to market
Building a hybrid application is typically faster and requires highly reusable standards skills. It does not involve a tedious learning curve when compared to native programming languages.
Inexpensive cross-platform development cycle
Hybrid apps have cross-platform compatibility, reducing the footprint of native code needed, resulting in more reusable HTML5, CSS, and JavaScript that can be shared and deployed across platforms with minimal adjustment. This is primarily because WebKit is the platform of choice across all major mobile phone OSes today. Cross-platform development cycles also help keep the cost associated with development and testing under control. The reusability of HTML code allows developers to achieve a “develop once, deploy many” architecture. Native apps on the other hand would require developers to perform full-feature test rounds for platforms on which the application is being developed.
Abundant human resources
Hybrid apps are built with web technologies, which means that there are many web developers who have the base skill set to build mobile apps.
Cost of maintenance
Maintenance costs are usually lower because one does not need to rewrite (port) all application code to the native language of each device platform. Further, since the skill set to develop hybrid apps is readily available, scaling of a development team is also a nonissue.
Approval process
Most of the app stores do have an approval process for which each app has to qualify before it can be made available through the sales channels of that app store. Because hybrid apps can be updated outside the bounds of an app store, you can typically get away with one submission to the app store. Once you are approved, you can push subsequent updates independently through your server if you like. A key point to note however, is that a fresh submission of the application would be required every time you make changes in the native code associated with the hybrid app.
Hybrid apps are the future
Looking toward the future and upcoming advancements in mobile OS technologies, one can easily argue that hybrid apps are the future of development. Windows Phone 8, Google announcements to eventually merge Chromium OS and Android, Tizen OS, and Firefox all hint toward a hybrid future, not too far away, and hence, building and deploying hybrid apps is strategically a right thing to do.
The benefits of the hybrid apps compared to mobile web include:
Access to device capabilities
As mentioned in the introduction paragraph, hybrid apps offer the unique opportunity to reap all the benefits of traditional web applications without many of their limitations. Hybrid apps can extend the JavaScript environment to access the native APIs and capabilities of the platform that are not available through the generic web browser environment otherwise, for example, true offline storage, as well as access to contacts and other media on the device.
Unavailable new platform features
Hybrid apps can take advantage of the new features that are available in the new SDKs. However, you will have to develop and expose that native layer using plug-ins or a framework, which is usually the boilerplate code in most cases.
Distribution through app stores
Hybrid apps are distributed through app stores just as native apps are. You discover, download, and install them, as you would a native application. Therefore as a developer, you can leverage an existing well-established channel for content, app discovery, and monetization.
Offline access and execution
Hybrid apps, like native apps, can be run locally on the device when the device is offline—i.e., it is not connected to any network.
The possible drawbacks of hybrid apps as compared to native apps include:
Performance
You may experience potential performance issues because JavaScript is fundamentally single-threaded, which means that only one operation can be performed at a time. However, if done right, you can come up with a solution wherein you can offload background tasks to a native thread, which would execute in parallel while your app is busy performing UI operations. The native thread would then notify the JavaScript of the events and task completions/failures.
Differences in cross-platforms
WebKit is not equally maintained in all mobile platforms, which means that there might be indistinct differences between renderings and platform-specific features to watch out for, though one could arguably say it is a better scenario than rewriting all code from scratch. Further, this is such a well-understood topic that often you would find material describing ways to identify and mitigate these UI experience risks.
Unavailable advanced features
There might be advanced features that cannot always be easily implemented on the hybrid layer—for example, OpenGL-based rendering—however, the set of features is rapidly shrinking with companies like Microsoft, Google, and Mozilla introducing a bunch of new standards aimed at bridging this gap.
Inconsistent user interfaces
Platform-specific UIs’ look and feel might be seriously difficult to mimic using HTML, CSS, and JavaScript.

The possible drawbacks to the hybrid apps compared to mobile web include:


Not accessible via website
A user is required to find your application in a native app store and cannot access it via a traditional web browser unless you’ve made one available.

SASS - A Pre-processor of CSS3

Have you always wanted to learn Sass, but never quite made your move? Are you a Sass user, but feel like you could use a brush up? Well then read on, because today we are going to review the features of Sass and some of the cool things you can do with it.

WHAT IS SASS?

Sass (Syntactically Awesome Style Sheets) is a CSS preprocessor. It is to CSS what CoffeeScript is to Javascript. Sass adds a feature set to your stylesheet markup that makes writing styles fun again.

SO UH, HOW DOES IT WORK?

Funny you should ask. There are several ways you can compile Sass:
  • The original Ruby Sass binary. Install it with gem install sass, and compile it by running sassc myfile.scss myfile.css.
  • A GUI app such as HammerCodeKit, or Compass
  • My personal favorite libsass, which is a blazing fast Sass compiler written in C. You can also install libsass via NPM withnode-sass (npm install node-sass).
Which one should you use? That depends on what you are doing.
I work with large scale e-commerce codebases, so Ruby Sass is a little slow when compiling large source sets. I use node-sass in my build system, but I have to remain wary of the fact that libsass is not in 100% feature parity with Ruby Sass.
If you aren’t a command line person, the GUI apps are great. You can set them up to watch scss files, so when you edit them they will compile automatically.
If you want to just screw around, or share examples, I highly recommendSassmeister. It is a web based Sass playground that I will be using throughout this article.

WHATS THE DEAL WITH .SASS VS .SCSS?

When Sass first came out, the main syntax was noticably different from CSS. It used indentation instead of braces, didn’t require semi-colons and had shorthand operators. In short, it looked a lot like Haml.
Some folks didn’t take too kindly to the new syntax, and in version 3 Sass changed it’s main syntax to .scss. SCSS is a superset of CSS, and is basically written the exact same, but with all the fun new Sass features.
That said, you can still use the original syntax if you want to. I personally use .scss, and I will be using the .scss syntax in this article.

WHY WOULD I USE SASS?

Good question. Sass makes writing maintainable CSS easier. You can get more done, in less code, more readably, in less time.
Do you need more of a reason than that?

#Set Up

Without any further ado, lets get this party started. If you want to try some of these concepts while following along, either:
  • Install your compilation method of choice, and create astyle.scss file.

#Variables

Thats right, variables. Sass brings variables to CSS.
Acceptable values for variables include numbers, strings, colors, null, lists and maps.
Variables in Sass are scoped using the $ symbol. Lets create our first variable:

$primaryColor: #eeffcc;

If you tried to compile this and didn’t see anything in your CSS, you’re doin’ it right. Defining variables on their own doesn’t actually output any css, it just sets it within the scope. You need to use it within a CSS declaration to see it:

$primaryColor: #eeffcc;

body {
    background: $primaryColor;
}

Speak of the devil (scope), did you know that Sass has variable scope? Thats right, if you declare a variable within a selector, it is then scoped within that selector. Check it out:

$primaryColor: #eeccff;

body {
  $primaryColor: #ccc;
  background: $primaryColor;
}

p {
  color: $primaryColor;
}

// When compiled, our paragraph selector's color is #eeccff

But what if we want to set a variable globally from within a declaration? Sass provides a !global flag that comes to our rescue:

$primaryColor: #eeccff;

body {
  $primaryColor: #ccc !global;
  background: $primaryColor;
}

p {
  color: $primaryColor;
}

// When compiled, our paragraph selector's color is #ccc

Another helpful flag, particularly when writing mixins, is the !default flag. This allows us to make sure there is a default value for a variable in the event that one is not provided. If a value is provided, it is overwritten:

$firstValue: 62.5%;

$firstValue: 24px !default;

body {
    font-size: $firstValue;
}

// body font size = 62.5%


Math

Unlike CSS, Sass allows us to use mathematical expressions! This is super helpful within mixins, and allows us to do some really cool things with our markup.
Supported operators include:
+Addition
Subtraction
/Division
*Multiplication
%Modulo
==Equality
!=Inequality
Before moving forward, I want to note two potential “gotchas” with Sass math.
First, because the / symbol is used in shorthand CSS font properties likefont: 14px/16px, if you want to use the division operator on non-variable values, you need to wrap them in parentheses like:

$fontDiff: (14px/16px);

Second, you can’t mix value units:

$container-width: 100% - 20px;

The above example won’t work. Instead, for this particular example you could use the css calc function, as it needs to be interpereted at render time.
Back to math, lets create a dynamic column declaration, based upon a base container width:

$container-width: 100%;

.container {
  width: $container-width;
}

.col-4 {
  width: $container-width / 4;
}

//  Compiles to:
//  .container {
//   width: 100%;
//  }
//
//  .col-4 {
//      width: 25%;
//  }

Functions

Have you ever wanted to make a cool looking button, and then taken the time to mess around on a color wheel, trying to find the right shades for ‘shadowed’ parts?
Enter the darken() function. You can pass it a color and a percentage and it, wait for it, darkens your color. Check this demo out to see why this is cool:

Nesting

One of the most helpful, and also misused features of Sass, is the ability to nest declarations. With great power comes great responsibility, so lets take a second to realize what this does, and in the wrong hands, what bad things it could do.
Basic nesting refers to the ability to have a declaration inside of a declaration. In normal CSS we might write:

.container {
    width: 100%;
}

.container h1 {
    color: red;
}

But in Sass we can get the same result by writing:

.container {
    width: 100%;
    h1 {
        color: red;
    }
}

Thats bananas! So what if we want to reference the parent? This is achieved by using the & symbol. Check out how we can leverage this to add pseudo selectors to anchor elements:

a.myAnchor {
    color: blue;
    &:hover {
        text-decoration: underline;
    }
    &:visited {
        color: purple;
    }
}

Now we know how to nest, but if we want to de-nest, we have to use the@at-root directive. Say we have a nest set up like so:

.first-component {
    .text { font-size: 1.4rem; }
    .button { font-size: 1.7rem; }
    .second-component {
        .text { font-size: 1.2rem; }
        .button { font-size: 1.4rem; }
    }
}

If possible, don’t nest more than four levels. If you, in a pinch, have to go five levels deep, Hampton Catlin isn’t going to come to your house and fight you. Just try not to do it.

#Imports

Easily my second favorite part of Sass, imports allow you to break your styles into separate files and import them into one another. This does wonders for organization and speed of editing.
We can import a .scss file using the @import directive:

@import "grids.scss";

In fact, you don’t even really need the extension:

@import "grids";

Sass compilers also include a concept called “partials”. If you prefix a .sass or .scss file with an underscore, it will not get compiled to CSS. This is helpful if your file only exists to get imported into a master style.scss and not explicitly compiled.

#Extends & Placeholders

In Sass, the @extend directive is an outstanding way to inherit already existing styles.
Lets use an @extend directive to extend an input’s style if it has an input-error class:

.input {
  border-radius: 3px;
  border: 4px solid #ddd;
  color: #555;
  font-size: 17px;
  padding: 10px 20px;
  display: inline-block;
  outline: 0;
}

.error-input {
  @extend .input;
  border:4px solid #e74c3c;
}

Please note, this does not copy the styles from .input into .error-input.  Meet the placeholder selector.

%input-style {
    font-size: 14px;
}

input {
    @extend %input-style;
    color: black;
}

The placeholder selector works by prefixing a class name of your choice with a % symbol. It is never rendered outright, only the result of its extending elements are rendered in a single block.

Mixins

The mixin directive is an incredibly helpful feature of Sass, in that it allows you to include styles the same way @extend would, but with the ability to supply and interperet arguments.
Sass uses the @mixin directive to define mixins, and the @include directive to use them. Lets build a simple mixin that we can use for media queries!
Our first step is to define our mixin:

@mixin media($queryString){

}

Notice we are calling our mixin media and adding a $queryString argument. When we include our mixin, we can supply a string argument that will be dynamically rendered. Lets put the guts in:

@mixin media($queryString){
    @media #{$queryString} {
      @content;
    }
}

Because we want our string argument to render where it belongs, we use the Sass interpolation syntax, #{}. When you put a variable in between the braces, it is printed rather than evaluated.
Another piece of our puzzle is the @content directive. When you wrap a mixin around content using braces, the wrapped content becomes available via the @content directive.
Finally, lets use our mixin with the @include directive:

.container {
    width: 900px;
    @include media("(max-width: 767px)"){
        width: 100%;
    }
}

#
Function Directives
Function directives in Sass are similar to mixins, but instead of returning markup, they return values via the @return directive. They can be used to DRY (Don’t repeat yourself) up your code, and make everything more readable.
Lets go ahead and create a function directive to clean up our grid calculations from our grid demo:

@function getColumnWidth($width, $columns,$margin){
    @return ($width / $columns) - ($margin * 2);
}

Now we can use this function in our code below:

$container-width: 100%;
$column-count: 4;
$margin: 1%;

.container {
  width: $container-width;
}

.column {
  background: #1abc9c;
  height: 200px;
  display: block;
  float: left;
  width: getColumnWidth($container-width,$column-count,$margin);
  margin: 0 $margin;
}