Friday, 16 August 2013


Many times we wonder how to make symbols/alt codes with keyboard...
Below are the alt codes we can make. For this you need to press "Alt" key with the combination of numbers on the number pad(numbers on the right side) as show in the picture below -
Alt + 0153..... ™... trademark symbol
Alt + 0169.... ©.... copyright symbol
Alt + 0174..... ®....registered ­ trademark symbol
Alt + 0176 ...°......degre­e symbol
Alt + 0177 ...± ­-minus sign
Alt + 0182 ...¶.....paragr­aph mark
Alt + 0190 ...¾....fractio­n, three-fourths
Alt + 0215 ....×.....multiplication sign
Alt + 0162...¢....the ­ cent sign
Alt + 0161.....¡..... ­.upside down exclamation point
Alt + 0191.....¿..... ­upside down question mark

Alt + 1.......☺­iley face
Alt + 2 ......☻.....bla­ck smiley face
Alt + 15.....☼­n
Alt + 12......♀.....female sign
Alt + 11.....♂......m­ale sign
Alt + 6.......♠.....spade
Alt + 5.......♣...... ­Club
Alt + 3.......♥...... ­Heart
Alt + 4.......♦...... ­Diamond
Alt + 13......♪.....e­ighth note
Alt + 14......♫...... ­beamed eighth note
Alt + 8721.... ∑.... N-array summation
Alt + 251.....√.....s­quare root check mark
Alt + 8236.....∞..... ­infinity
Alt + 24.......↑..... ­up arrow
Alt + 25......↓...... ­down arrow
Alt + 26.....→.....ri­ght arrow
Alt + 27......←.....l­eft arrow
Alt + 18.....↕......u­p/down arrow
Alt + 29......↔...left right arrow

How do you do it with your Laptop? Watch it here!
Making HTML text symbols? Click here.

References -

Monday, 1 July 2013

HTML5’s pros and cons compared to native app development

Pros –
  • Supports multimedia without plugin - It is the first version to support multimedia without plugins and has the ability to be “understood” by all computers and devices.
  • HTML5 web apps can be accessed on any device via a web browser - Much like a mobile website.
    These web apps also provide the capability for offline access and usage via application cache, meaning you don’t have to have a network connection to use them.
  • Single web app rather than multiple native apps - Some have predicted the impending demise of the native app.
  • Ability to bypass app stores – This presents an additional advantage for companies that use mobile apps to engage consumers in purchase transactions.
  • Makes things easier - HTML 5 is aimed at making things easier to build search front-ends, wikis, real-time chat, drag-and-drop tools, discussion boards and many other modern web elements into any site, and have them work more efficiently.

 Cons –
  • Security issues - HTML5 web apps are set up in a way that ultra-savvy users could tamper with processing scripts, which might allow unauthorized access. Variables could be altered in a way that would allow hackers to access perks, discounts, etc. for which they really aren’t eligible.
  • Functionality does not rival that of a native app (not yet anyway) - Most say that it’s pretty good, but it’s no native app.  It will be a while yet before web apps can offer the speed and features of a native app.  It’s important to remember that consumers use native apps because they’re easy, fast and convenient. Also, better integration with hardware and other apps.
  • You lose the marketing benefits of being featured in app stores -  If you are a smaller company, new and potential customers are probably more likely to find you if you’re featured in an app store.

Strategic decision-makers for successful apps should weigh the importance of the following:
  1. User experience
  2. Performance
  3. Monetization
  4. Cross platform deployment costs
  5. Fragmentation
  6. Availability of programming expertise
  7. Importance of immediate updates and distribution control
  8. Timeliness of new OS innovations
  9. Security
When does using HTML5 make sense?
The short answer: When the information is always updating; you don’t want Apple or Google as intermediaries, or if the user doesn't want to download an application.

Note: Above comparison may not hold true for hybrid container-based apps that run in a native shell 

Thursday, 6 June 2013

Frequently asked PhoneGap/Cordova interview questions

When we talk about PhoneGap/Hybrid mobile app development, it is most probable that the interviewer may also ask about JavaScript, Dojo, jQuery, HTML5, CSS, Sencha, JSON and so on. Be prepared. Below are some questions which I came across -

1. What is PhoneGap and why ?
PhoneGap is a mobile application framework that allows developers to use HTML, JavaScript and CSS to create mobile apps that are present as first-class applications on the phone. That means the mobile apps have their own icons and operate similarly to native applications without a browser frame around them.

They have access to a set of native functions to further make them work like native apps.

Mobile developers use PhoneGap because it allows them to have a common codebase for all their application code. It doesn’t force developers to write code from scratch every time they move from platform to platform.

2. PhoneGap architecture.
PhoneGap has a plugin-based architecture. Each device-specific feature is a plugin, which consists of javascript and native sides. Js side should be as cross-platform as possible, whereas native side can be implemented only once, for 1 device. Nevertheless built-in plugins are developed for all of the most popular platforms, so no need to reinvent the wheel.
This architecture, together with open source code, not only allows a developer to fix their bugs, but also allows them to tweak their plugins for as per requirements. Also, a developer can build his own plugin, and support any platform of his choice.

3. What is the difference between PhoneGap and Cordova?
PhoneGap is a distribution of Apache Cordova. You can think of Apache Cordova as the engine that powers PhoneGap, similar to how WebKit is the engine that powers Chrome or Safari.

4. What is PhoneGap Build, and how is it different from PhoneGap framework?
PhoneGap is a mobile application development framework, based upon the open source Apache Cordova project. It allows you to write an app once with HTML, CSS and JavaScript, and then deploy it to a wide range of mobile devices without losing the features of a native app. PhoneGap Build is a cloud-based service built on top of the PhoneGap framework. It allows you to easily build those same mobile apps in the cloud.

5. What is a Plist file in iOS development ?
Yes, this is not related to phonegap, but interviewer expects the answer!

Property lists are a way of structuring arbitrary data and accessing it at run-time. An information property list is a specialized type of property list that contains configuration data for a bundle. The keys and values in the file describe the various behaviors and configuration options you want applied to your bundle. Xcode typically creates an information property list file for any bundle-based projects automatically and configures an initial set of keys and values with appropriate default values. You can edit the file to add any keys and values that are appropriate for your project or change the default values of existing keys.

For further details click here.

6. What is the difference between ChildBrowser and InAppBrowser in PhoneGap ?
As the name suggests, Child Browser Plugin is a plugin and can be integrated in any phonegap application.

Whereas, InAppBrowser is a phonegap API that provides the ability to spawn a browser instance from a Cordova(2.3.0) application. The API is based on standard browser capability. In a nutshell, this has the same functionality as the ChildBrowser, and has events support as well.
Example usage:
var ref ='', '_blank');
ref.addEventListener('loadstart', function(event) { alert(event.type + ' - ' + event.url); } );
ref.addEventListener('loadstop', function(event) { alert(event.type + ' - ' + event.url); } );
ref.addEventListener('exit', function(event) { alert(event.type); } );

// also, you can do ref.removeEventListener('loadstart', myfunc) .. etc

7. What are CDNs in jQuery? Why do we use it?
CDNs(Content Delivery Networks) can offer a performance benefit by hosting jQuery on servers spread across the globe.
There are three CDNs available that host the jQuery library free of charge:
  1. Google’s Libraries API CDN (a.k.a. Google Ajax API CDN)
  2. Microsoft’s Ajax CDN
  3. Media Temple’s ProCDN (the official “jQuery CDN”)
Using jQuery's CDN provided by MediaTemple
<script src=""></script>
<script src=""></script>

There are several benefits to using CDNs:
  • The file will normally load faster than it would if self hosted.
  • Odds are better that the site visitor will have a cached copy of the file since other sites will also be linking to the same file.
  • It saves the site owner some bandwidth since the file is externally hosted.
8. Name PhoneGap events
  • deviceready
  • pause
  • resume
  • online
  • offline
  • backbutton
  • batterycritical
  • batterylow
  • batterystatus
  • menubutton
  • searchbutton
  • startcallbutton
  • endcallbutton
  • volumedownbutton
  • volumeupbutton
More details here


Wednesday, 29 May 2013

Commonly asked JavaScript interview questions

1. What is the difference between == and === in javascript ?
The 3 equal signs mean "equality without type coercion". Using the triple equals, the values must be equal in type as well.
0==false   // true
0===false  // false, because they are of a different type
1=="1"     // true, auto type coercion
1==="1"    // false, because they are of a different type

Null and Undefined types are == (but not ===). [i.e. Null==Undefined (but not Null===Undefined)]

2. null vs undefined in Javascript ?
In JavaScript, undefined means a variable has been declared but has not yet been assigned a value, such as:

var TestVar;
alert(TestVar); //shows undefined
alert(typeof TestVar); //shows undefined
null is an assignment value. It can be assigned to a variable as a representation of no value:

var TestVar = null;
alert(TestVar); //shows null
alert(typeof TestVar); //shows object

From the preceding examples, it is clear that undefined and null are two distinct types: undefined is a type itself (undefined) while null is an object.

3. What are global variables and how are they declared? Also, explain problems using globals?
Global variables are available throughout your code: that is, the variables have no scope. Local variables scope, on the other hand, is restricted to where it is declared (ex-within a function). The var keyword is used to declare a local variable, while omitting the var keyword creates a global variable.

// Declare a local variable
var localVariable = "TechRepublic"
// Declare a global
globalVariable = "NewDelhi"

Most JavaScript developers avoid globals. One reason why is they’re averse to naming conflicts between local and globals, Also, code that depends on globals can be difficult to maintain and test.

4. How do you handle errors in JavaScript?
Exceptions that occur at runtime can be handled via try/catch/finally blocks. This can avoid unfriendly error messages. The finally block is optional and execution is transferred to the catch block of code when/if runtime errors occur. When the try/catch block is finally done, code execution transfers to the finally code block. This is the same way it works in other languages like C# and Java.

try {
// do something
} catch (e) {
// do something with the exception
} finally {
// This code block always executes whether there is an exception or not.

5. The onerror Event Handler
JavaScript 1.1 allowed a new event handler named "onerror". This Event Handler allows you to have something happen when the page throws an error.
The onerror event can only be defined inside your JavaScript code as a property of the window object:

<script type="text/javascript">
 //code to run when error has occured on page

6. Write a 1-line JavaScript code that concatenates all strings passed into a function?
The following function should help achieve the desired result

function concatenate() {
return String.prototype.concat.apply('', arguments);

7. What are windows object and navigator object in JavaScript?
The window object represents an open window in a browser.
Windows object is top level object in Java script and contains several other objects such as, document, history, location, name, menu bar etc., in itself. It is the global object for Java script that is written at client-side. For more details, click here.

The navigator object contains information about the browser.
navigator.appName - Gives the name of the browser
navigator.appVersion - Gives the browser version
navigator.appCodeName - Gives the browser codename
navigator.platform - Gives the platform on which the browser is running
For more details, click here.

8. Difference between window.onload and onDocumentReady?
The onload event does not fire until every last piece of the page is loaded, this includes css and images, which means there’s a huge delay before any code is executed.
If you just want to wait until the DOM is loaded and is able to be manipulated. onDocumentReady allows you to do that.

Wednesday, 1 May 2013

amCharts vs Chart.js - Visuals

I was just going through source HTML5 charts using canvas tag) and found it very useful. Its good for small/medium chart usage(supports only 6 chart types as of now). But, being a fan of amCharts, I started comparing some of the visuals as below -

Radar chart

Column chart

Pie chart
Hope this will give you some insights of amCharts and Chatrjs and you will be able to compare at a glance. For other javascript charting comparisons click here.

Friday, 8 March 2013

Dojo vs jQuery Mobile: Quick Comparison

Both jQuery and DOJO are JavaScript Development Frameworks/Packages that provide functions to make the writing of JavaScript code easier, faster and more efficient. jQuery normalize things across browsers and serves as a great way of doing DOM manipulation. Dojo is a more on comprehensive toolkit which helps developers to build superior desktop and mobile web experiences.

Advantages of jQuery:
  • Fast
  • Well documented
  • Easy to use
  • Chaining
  • Easy-to-use Ajax
  • Nice event handlers
  • CSS selectors
  • Small (only 30 KB)
  • Nice little built-in effects.
  • Plugins
Advantages of Dojo:
  • OOP (and other paradigms).
  • Widget infrastructure.
  • Modules done right with all necessary goodies:
    • Lazy loading of modules dynamically.
    • Asynchronous loading of modules if desired.
    • Simple integration with CDNs (content delivery networks) for heavy-duty web applications.
  • Sheer breadth of available modules in DojoX including graphics, charting, grids, and so on.
  • Attention to details in widgets:
    • Support for i18n (including LTR and RTL languages),
    • Support for l10n (including standard date, currency, number formatting),
    • Provisions for people with special needs (automatic high-contrast mode, keyboard-only support, and so on).
Deciding right tool for a project depends a lot on complexity of the application, scalability, DB/Web Service dependencies, current skill set, etc. jQuery offers little guidance on how to structure your codebase, how to ensure that everything you need is loaded, or how to build your code into production-ready files. Dojo really shines here, but again, it takes a bit of getting used to.

Personally, I think Dojo's lack of good documentation/reference code, lack of 'marketing', and relative complexity keep it from becoming popular. Documentation is a whole lot harder to use than jQuery’s because, at first glance, it’s quite a bit more scattered and substantially more API-based than task-based. It's much easier to get started with library like jQuery because of all these factors. However, once you get over that initial steep learning curve, Dojo is good!


Thursday, 7 February 2013

Mobile App Security - Top 10

Industry analysts’ findings reveal that in 2011, the number of users to access banking services from their smartphones was a gigantic 300 million, which is further expected to rise to a whopping 530 million by 2013!The exponential growth of smart phones and their widespread usage have brought to the fore the criticality of mobile app security from an enterprise safety standpoint.The rapid adoption of mobile devices and mobile apps has led to a significant and unbounded security risk for any enterprise. The mobile app threat is escalating rapidly – spanning simple “premium SMS and call” attacks that are directly monetized by running up a victim’s bill, to hampering full-scale mobile functionality.

The need for enterprises to equip their mobile workforce with productive, meaningful applications is more critical than ever. Such applications need to ensure the security of sensitive data on the device as well as internal networks. Enterprise mobile applications extend corporate networks beyond the perimeter devices, thus potentially exposing these organizations to new types of security threats.

As smartphones are natural devices for data management, they are easy sources of sensitive data like credit card numbers, authentication information, private information, activity logs (calendar, call logs) and the like. The graphic below shows the relevant statistics about types of information stored by users in mobile devices.
Survey carried out by ESET Latin America(Trends for 2013)

Three prime target components for attackers are – Data, Identity and Availability.

Android platform remains the prime target for both mobile malware and spyware miscreants. According to one of McAfee’s recent findings, there are very few mobile threats that are not directed at Android phones!After an apparent but slight decline earlier in the year, Android malware has rebounded and has almost doubled.
McAfee Threats Report: Third Quarter 2012

Here's peek into 10 key inhibitors for enterprise apps - 

    1: Insecure Data Storage

Most mobile applications have a need to store sensitive information, either in its local storage or on SD card. The information might be passwords, account records, or proprietary information.
Frequently, encryption techniques are used to protect this sensitive information. While encryption has become relatively easy to implement and use, developers still frequently make mistakes while integrating it. Developers may overestimate the protection gained by using encryption and not be as careful in securing other aspects of the mobile application.
A few areas where mistakes are commonly made include:
         Sensitive data left unprotected.
         Weak or global permissions
  • Insecure storage of keys, certificates, and passwords
  • Improper storage of secrets in memory
  • Poor sources of randomness
  • Poor choice of algorithm
  • Attempting to invent a new encryption algorithm
  • Failure to include support for encryption key changes and other required maintenance procedures
The impact of these weaknesses can be devastating to the security of a mobile.
Prevention Tips
         Store ONLY what is absolutely required
         Never use public storage areas (i.e. SD card)
         Leverage secure containers and platform provided file encryption APIs.
         Do not grant files world readable or world writable permissions
         Do not store historical GPS/tracking or other sensitive information on the device beyond the period required by the application
         There is currently no standard secure deletion procedure for flash memory (unless wiping the entire medium/card). Therefore data encryption and secure key management are especially important.

     2: Weak Server Side Controls

Weak server controls applies on backend systems causing loss of data via cloud storage. The majority of mobile applications interact with the backend APIs using REST/Web Services or proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow attackers to compromise data on the mobile device when transferred to the backend, or to attack the backend through the mobile application.
These are:
         Not mobile specific, but essential to get right
         Applicable to backend service
Prevention Tips
         Carry out a specific check of your code for sensitive data unintentionally transferred, any data transferred between the mobile device and web-server back- ends and other external interfaces - (e.g. is location or other information included within file metadata).
         Ensure that the backend platform (server) is running with a hardened configuration with the latest security patches applied to the OS, Web Server and other application components.
         All backend services (Web Services/REST) for mobile apps should be tested for vulnerabilities periodically, e.g. using static code analyzer tools for testing and finding security flaws.
         Ensure adequate logs are retained on the backend in order to detect and respond to incidents and perform forensics (within the limits of data protection law).
         Understand the additional risks mobile apps introduce into existing architecture.

      3: Insufficient Transport Layer Protection

Network spoofing attacks, surveillance. The majority of smart phones are capable of using multiple network mechanisms including Wi-Fi, provider network (3G, GSM, CDMA and others), Bluetooth etc. Sensitive data passing through insecure channels could be intercepted.
These can be due to:
         Complete lack of encryption for transmitted data
         Weakly encrypted data in transit
         Authorization header sent over HTTP
         Strong encryption, but ignoring security warnings
         Ignoring certificate validation errors
         Falling back to plain text after failures
Prevention Tips
         Assume that the provider network layer is not secure. Modern network layer attacks can decrypt provider network encryption, and there is no guarantee that the Wi-Fi network will be appropriately encrypted.
         Applications should enforce the use of an end-to-end secure channel (such as SSL/TLS) when sending sensitive information over the wire/air (e.g. using Strict Transport Security - STS).This includes passing user credentials, or other authentication equivalents. This provides confidentiality and integrity protection.
         Use strong and well-known encryption algorithms and appropriate key lengths.
         Be very cautious in allowing self- signed certificates. Do not disable or ignore SSL chain validation.
         SMS, MMS or notifications should not be used to send sensitive data to or from mobile end-points.
         When security exceptions are thrown, it’s generally for a reason… DO NOT ignore them!

     4: Client Side Injection

This type of attack exploits buffer overflow vulnerability in targeted client software through injection of malicious content from a custom-built hostile service.
The server may look like a valid server, but in reality it may be a hostile server aimed at fooling the client software. For instance the server can use honey pots and get the client to download malicious code.
The hostile server may also attempt to install and run malicious code on the client software. That malicious code can be used to scan the client software for buffer overflow.
Attack Execution Flow:
         The attacker creates a custom hostile service
         The attacker acquires information about the kind of client attaching to her hostile service to determine if it contains exploitable buffer overflow vulnerability.
         The attacker intentionally feeds malicious data to the client to exploit the buffer overflow vulnerability that she has uncovered.
         The attacker leverages the exploit to execute arbitrary code or to cause a denial of service.

These attacks generally occur in apps using browser libraries:
         Pure web apps
         Hybrid web/native apps
Also, mobile attackers can:
         Abuse phone dialer +SMS
         Abuse in-app payments
Prevention Tips
         Sanitize/Escape un trusted data before rendering or executing it
         Use prepared statements for database calls
         Minimize the sensitive native capabilities tied to hybrid web functionalities

       5: Poor Authorization and Authentication

This is part mobile, part architecture threat. Unauthorized individuals may obtain access to sensitive data or systems by circumventing authentication systems (logins).
This can result in unauthorized access and loss of confidential data.
Prevention Tips
         Implement user authentication/authorization and session management correctly
         Use authentication that ties back to the end user identity (rather than the device identity).
         Never use device ID or subscriber ID as sole authenticator.
         Use context to add security to authentication - e.g. IP location, etc...
         Authenticate all API calls

     6: Improper Session Handling

Unauthorized individuals may obtain access to sensitive data by reusing valid tokens or cookies.
Mobile app sessions are generally MUCH longer due to the convenience and reusability. Apps maintain sessions via:

         HTTP cookies
         OAuth  tokens
         SSO authentication services

In case of mobile apps it’s always a bad idea to use a device identifier as a session token. This can lead to unauthorized access and circumvent licensing and payments.

Prevention Tips
         It is important to ensure that the session management is handled correctly after the initial authentication, using appropriate secure protocols. For example, require authentication credentials or tokens to be passed with any subsequent request (especially those granting privileged access or modification).
         Don’t be afraid to make users re-authenticate every so often
         Ensure that tokens can be revoked quickly in the event of a lost/stolen device
         Utilize high entropy, tested token generation resources

     7: Security Decisions via Un-trusted Inputs

Data leakage. Users may install applications that may be malicious and can transmit personal data (or other sensitive stored data) for malicious purposes. It can also be leveraged to bypass permissions and security model resulting in confidentiality loss and unauthorized consumption of paid resources.

Prevention Tips
         Check caller’s permissions at input boundaries

         Vet the security/authenticity of any third party code/libraries used in your mobile application (e.g. making sure they come from a reliable source, with maintenance supported, no back-end Trojans)

         Pay particular attention to validating all data received from and sent to non-trusted third party apps (e.g. ad network software) before processing within the application.

         Track all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile applications using these third party APIs/frameworks.

     8: Side Channel Data Leakage

This is generally a result of mix of not disabling platform features and programmatic flaws. Generally sensitive data ends up in unintended places like:

         Web caches
         Keystroke Logging
         Logs (system, crash)
         Temp directories

Also, there is a need to understand what 3rd party libraries are doing with user data (i.e. ad networks, analytics)

Prevention Tips
         Never log credentials, or other sensitive data to system logs
         Remove sensitive data before screenshots are taken, disable keystroke logging per field, and utilize anti-caching directives for web content
         Debug your apps before releasing them to observe files created, written to, or modified in any way
         Carefully review any third party libraries you introduce and data they consume
         Test your applications across as many platform versions as possible

     9: Broken Cryptography

These are the result of broken implementations using strong crypto libraries or custom (easily defeated) crypto implementation.

Always keep in mind:
         Encoding != Encryption
         Serialization != Encryption

Prevention Tips
         Never store key with encrypted data, it negates everything
         Leverage battle-tested crypto libraries vice writing your own
         Take advantage of what your platform already provides. Utilize file encryption APIs
         Leverage secure containers

     10: Sensitive Information Disclosure

Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure: Mobile devices (being mobile) have a higher risk of loss or theft. Adequate protection should be built in to minimize the loss of sensitive data on the device.

Commonly found “treasures” are:
         API keys
         Sensitive business logic

Prevention Tips
         In the design phase, classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs, etc.). Process, store and use data according to its classification. Validate the security of API calls applied to sensitive data.
         Store sensitive data on the server instead of the client-end device. This is based on the assumption that secure network connectivity is sufficiently available and that protection mechanisms available to server side storage are superior.
         When storing data on the device, use a file encryption API provided by the OS or other trusted source. Some platforms provide file encryption APIs which use a secret key protected by the device unlock code and deleteable on remote kill. If this is available, it should be used as it increases the security of the encryption without creating extra burden on the end-user. It also makes stored data safer in the case of loss or theft. However, it should be born in mind that even when protected by the device unlock key, if data is stored on the device, its security is dependent on the security of the device unlock code if remote deletion of the key is for any reason not possible.
         Do not store/cache sensitive data (including keys) unless they are encrypted and if possible stored in a tamper-proof area
         Do not store historical GPS/tracking or other sensitive information on the device beyond the period required by the application