Thursday, 14 January 2016

Web Services in Android

What is Web Service?

A web service is a standard used for exchanging information between applications or systems of heterogeneous type. Software applications written in various programming languages and running on various platforms can use web services to exchange information over Internet using http protocol.
This inter-operability can be achieved between Java and Dot net applications, or PHP and Java applications.

Why Web Service?

Here are the reasons for using Web Service:

Expose method as a service over network:
Web service is a chunk of code written in some programming language (Say C# or Java) that can be invoked remotely through http protocol. Once the Web methods are exposed publically, any applications can invoke it and use the functionality of the web methods.

Application Inter-operability – Connect heterogeneous applications:
With the help of web service, heterogeneous applications (Java and Dot Net / Java and PHP application) can communicate with each other. Web service written in Java can be invoked from PHP by passing the required parameters to web methods. This makes the applications platform and technology independent.

Standardized protocol:
Web Services uses standardized industry standard protocol for the communication which must be adhered and followed by the applications creating Web Service.  
                                                     
Cost effective communication:
Web service is using SOAP over HTTP protocol for communication which is much cheaper than systems.

What is the need of using Web Service in Android applications?

Existing Web applications are in a need of creating mobile applications to show their presence in mobile platform as well. Almost all web applications are having their Mobile applications created in Android, IOS or Windows platform.

Exposing the existing functionalities of the applications is bit tough as all the functionalities have to re-written in the respective platforms.

But it can be easily achieved with much ease by creating Web Service and expose the existing functionalities as web methods to Mobile platforms.

Here are the few advantages of using Web Service in Android:

Make client more lightweight:
Adding a web service layer makes the client more lightweight, both in terms of the required CPU power and the bandwidth used during the processing. Most of the processing to be done in client end can be separated and put inside a web service layer which will be extremely helpful for end-users in terms of:
Using less CPU increases the battery life
Using less bandwidth reduces monthly payments over data charge.

Re-usage of existing functionalities:
While designing the web service, we could also get significant benefits by reusing the existing functionalities by exposing them as web methods.

Remote DB hit made simple:
DB residing remotely can be hit from inside Android applications through Web Service calls.
Making Web Service call from Android applications allows us to add functionality outside the scope of a DB like caching data, applying business rules over the data etc.,

Types of web services.

1) xml
2) json
3) soap
3) rest

Which one is better XML or JSON ?

XML and JSON both are the data interchange formats accessed over WEB. Both of these formats have their own pros/cons. No one is replacement of other. Use the right tool for the right job.

XML: Extensible Markup Language

1. An open standard for describing data defined by the World Wide Web Consortium (W3C).

2. XML lets Web developers and designers create customized tags that offer greater flexibility in organizing and presenting information.

3. XML defines rules to mark-up a document in a way that allows the author to express semantic meaning in the mark-up. XML does not necessarily restrict the author to certain tags (elements) as HTML does.

4. Internet media type: application/xml

JSON: JavaScript Object Notation

1. A lightweight text-based open standard designed for human-readable data interchange.

2. A text-based format for exchanging objects.

3. It is an alternative to XML that is more concise because, unlike XML,  it is not a markup language that requires open and close tags.

4. It is derived from the object literals of JavaScript.

5. Design goals were for it to be minimal, portable, textual, and a subset of JavaScript.

6. Internet media type: application/json


JSON is built on two structures:

1. A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.

2. An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

Below are the differences between XML and JSON.

XML vs JSON

1.  JSON format is lightweight over XML.

2. JSON is recognized natively by JavaScript.

3. JSON can contain integers, strings, lists, arrays. XML is just elements and nodes that need to be parsed into integers and so on before it can be consumed.

4. The most important disadvantage of JSON is that the format is very hard to read for humans, and that, of course,    every single comma, quote, and bracket should be in exactly the correct place. While this is also true of XML, JSON’s welter of complicated-looking syntax, like the }}]} at the end of the data snippet, may frighten the newbies and make for complicated debugging.

5. Serialization format for your data, JSON is smaller, lighterweight and generally faster than XML.

6. JSON is best for consumption of data in web applications from webservices for its size and ease of use, especially due to the built-in support in JavaScript.
Imagine the computation overhead for parsing an xml fragment compared to the instant lookup in JSON.

7. XML is still great. JSON’s just the “latest and greatest” compared to XML.

8. For configurations file XML is better choice to make because it more human readable.

9. A browser JSON is faster to serialize/deserialize as it’s simpler, more compact and more importantly natively supported.

10. XML is document-oriented. JSON is data-oriented. JSON can be mapped more easily to object-oriented systems.

11. XML and JSON both use Unicode.That help in support for internationalization.

12. JSON does not have afeature, so it is not well suited to act as a carrier of sounds or images or other large binary payloads. JSON is optimized for data.

13. XML documents can contain any imaginable data type – from classical data like text and numbers, or multimedia objects such as sounds, to active formats like Java applets or ActiveX components.

14. JSON is a better data exchange format. XML is a better document exchange format. Use the right tool for the right job.

15. XML requires translating the structure of the data into a document structure. This mapping can be complicated. JSON structures are based on arrays and records. That is what data is made of. XML structures are based on elements (which can be nested), attributes (which cannot), raw content text, entities, DTDs, and other meta structures.

16. JSON is not extensible because it does not need to be. JSON is not a document markup language, so it is not necessary to define new tags or attributes to represent data in it.

Summary:

1. For Data delivery between servers and browsers, JSON is better choice.
2. For storing Information in configuration files on the server side, XML is better choice.
3. On Browser Side: The speed and ease with which JSON is parsed and the ease of simple data          retrieval from JavaScript object; makes JSON is a better choice.
4. Server Side: The querying data and format changes; makes XML a better choice.

Querying data: Using XPath, it’s possible to get direct access to a part of multiple parts of an XML data structure; no such interface exists for JSON. To get data from a JSON structure, you must know exactly where it is or else iterate over everything until you find it.

Format changes: You have your data in one format but you want it in another. If the data is in XML, you can write an XSLT template and run it over the XML to output the data into another format: HTML, SVG, plain text, comma-delimited, even JSON. When you have data in JSON, it’s pretty much stuck there. There’s no easy way to change it into another data format.

5. Security: JSON is less secure because of absence of JSON parser in the Browser; only way is to use eval() function. For security reasons on the browser side XML is better choice.

6. To extract data from database; XML is the only choice.

Below is the example:
I used to explain each one’s usage in the Browser. This usage will also show you which one is easy to use on the browser side.

Example Data Operations:

XML

<?xml version="1.0" encoding="UTF-8"?>
<root>
    <data>
        <id>1</id>                   
        <name>PHP </name>
    </data>
    <data>
        <id>2</id>                   
        <name>Table of Contents</name>
    </data>
<root>

JSON

 {
                "data": [
                           {
                                "id" :    "1",
                                "name" :    "PHP"                           
                            },
                            {
                                "id" :    "2",
                                "name" :    "Table of Contents"
                            }
]}



What is REST ?

REST describes a set of architectural principles by which data can be transmitted over a standardized interface (such as HTTP). The acronym REST stands for Representational State Transfer, this basically means that each unique URL is a representation of some object.
REST asks developers to use HTTP methods explicitly and in a way that’s consistent with the protocol definition. This basic REST design principle establishes a one-to-one mapping between create, read, update, and delete (CRUD) operations and HTTP methods. According to this mapping:
To create a resource on the server, use POST.
To retrieve a resource, use GET.
To change the state of a resource or to update it, use PUT.
To remove or delete a resource, use DELETE.

Advantages of using RESTful webservice:

RESTful Web services are designed with less dependence on proprietary middleware (for example, an application server) than the SOAP- and WSDL-based kind.

As per the RESTful interface design, XML or JSON over HTTP is a powerful interface that allows internal applications, such as Asynchronous JavaScript + XML/JSON (Ajax)-based custom user interfaces, to easily connect, address, and consume resources.

The great fit between Ajax and REST has increased the amount of attention REST is getting these days.

Exposing a system’s resources through a RESTful API is a flexible way to provide different kinds of applications with data formatted in a standard way. It helps to meet integration requirements that are critical to building systems where data can be easily combined (mashups) and to extend or build on a set of base, RESTful services into something much bigger.

What is SOAP?
SOAP (Simple Object Access Protocol) is a messaging protocol that allows programs that run on disparate operating systems (such as Windows and Linux) to communicate using Hypertext Transfer Protocol (HTTP) and its Extensible Markup Language (XML).

SOAP defines the XML-based message format that Web service-enabled applications use to communicate and inter-operate with each other over the Web. The heterogeneous environment of the Web demands that applications support a common data encoding protocol and message format. SOAP is a standard for encoding messages in XML that invoke functions in other applications.

SOAP:
Pros:
Langauge, platform, and transport agnostic
Designed to handle distributed computing environments
Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
Built-in error handling (faults)
Extensibility

Cons:
Conceptually more difficult, more "heavy-weight" than REST
More verbose
Harder to develop, requires tools

REST
Pros:
Language and platform agnostic
Much simpler to develop than SOAP
Small learning curve, less reliance on tools
Concise, no need for additional messaging layer
Closer in design and philosophy to the Web.

Cons:
Assumes a point-to-point communication model--not usable for distributed computing environment where message may go through one or more intermediaries
Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own")
Tied to the HTTP transport model.

SOAP vs REST 

Difference between Stack Overflow error and Out of memory error in android?

Difference between Stack Overflow  error and  Out of memory error in android?

When you start JVM you define how much RAM it can use use for processing. JVM divides this into certain memory locations for its processing purpose, two of those are Stack & Heap.

Out of memory error  is related to Heap. If you have large objects (or) referenced objects in memory, then you will see Out of memory error . If you have strong references to objects, then GC can't clean the memory space allocated for that object. When JVM tries to allocate memory for new object and not enough space available it throws Out of memory error because it can't allocate required amount of memory.

How to avoid: Make sure unnecessary objects are available for GC.

Stack Overflow  error is related to stack. All your local variables and methods calls related data will be on stack. For every method call one stack frame will be created and local as well as method call related data will be placed inside the stack frame. Once method execution is completed, stack frame will be removed. ONE WAY to reproduce this is, have infinite loop for method call, you will see Stack Overflow  error, because stack frame will be populated with method data for every call but it won't be freed (removed).

How to avoid:
Make sure method calls are ending (not in infinite loop).


Here are few differences between stack and heap memory in Java:

1) Main difference between heap and stack is that stack memory is used to store local variables and function call, while heap memory is used to store objects in Java. No matter, where object is created in code e.g. as member variable, local variable or class variable,  they are always created inside heap space in Java.

2) Each Thread in Java has there own stack which can be specified using -Xss JVM parameter, similarly you can also specify heap size of Java program using JVM option -Xms and -Xmx where -Xms is starting size of heap and -Xmx is maximum size of java heap.

3) If there is no memory left in stack for storing function call or local variable, JVM will throw java.lang.StackOverFlowError, while if there is no more heap space for creating object, JVM will throw java.lang.OutOfMemoryError: Java Heap Space.

4) If you are using Recursion on which method calls itself, You can quickly fill up stack memory. Another difference between stack and heap is that size of stack memory is lot lesser than size of  heap memory in Java.

5) Variables stored in stacks are only visible to the owner Thread, while objects created in heap are visible to all thread. In other words stack memory is kind of private memory of Java Threads, while heap memory is shared among all threads.

Difference between debug.apk and release.apk  android ?

The difference between debug and release builds is for example, that you can get the log output from the debug build but not from the release build.

Debug builds can be signed with the default keystore, the release builds have to be signed with your created keystore.

The Android build process signs your application differently depending on which build mode you use to build your application.

There are two build modes: debug mode and release mode.

You use debug mode when you are developing and testing your application.

You use release mode when you want to build a release version of your application that you can distribute directly to users or publish on an application marketplace such as Google Play.

When you build in debug mode the Android SDK build tools use the Keytool utility (included in the JDK) to create a debug key. Because the SDK build tools created the debug key, they know the debug key's alias and password. Each time you compile your application in debug mode, the build tools use the debug key along with the Jarsigner utility (also included in the JDK) to sign your application's .apk file. Because the alias and password are known to the SDK build tools, the tools don't need to prompt you for the debug key's alias and password each time you compile.

When you build in release mode you use your own private key to sign your application. If you don't have a private key, you can use the Keytool utility to create one for you. When you compile your application in release mode, the build tools use your private key along with the Jarsigner utility to sign your application's .apk file. Because the certificate and private key you use are your own, you must provide the password for the keystore and key alias.

The debug signing process happens automatically when you run or debug your application using Eclipse with the ADT plugin. Debug signing also happens automatically when you use the Ant build script with the debug option. You can automate the release signing process by using the Eclipse Export Wizard or by modifying the Ant build script and building with the release option.