Wednesday, 18 May 2016

·         Turn on the Power button.
·         CPU pins are reset and registers are set to specific value.
·         CPU jump to address of BIOS (0xFFFF0).
·         BIOS run POST (Power-On Self Test) and other necessary checks.
·         BIOS jumps to MBR(Master Boot Record).
·         Primary Bootloader runs from MBR and jumps to Secondary Bootloader.
·         Secondary Bootloaders loads Operating System.

Monday, 18 January 2016

ART vs Dalvik / AOT vs JIT

Android apps are deployed in Dalvik bytecode, which is portable, unlike native code. In order to be able to run the app on a device, the code has to be compiled to machine code.
Dalvik is based on JIT (just in time) compilation. It means that each time you run an app, the part of the code required for its execution is going to be translated (compiled) to machine code at that moment. As you progress through the app, additional code is going to be compiled and cached, so that the system can reuse the code while the app is running. Since JIT compiles only a part of the code, it has a smaller memory footprint and uses less physical space on the device.
ART, on the other hand, compiles the intermediate language, Dalvik bytecode, into a system-dependent binary. The whole code of the app will be pre-compiled during install (once), thus removing the lag that we see when we open an app on our device. With no need for JIT compilation, the code should execute much faster.
Except for the potential speed increase, the use of ART can provide an important secondary benefit. As ART runs app machine code directly (native execution), it doesn't hit the CPU as hard as just-in-time code compiling on Dalvik. Less CPU usage results in less battery drain, which is a big plus for portable devices in general.

So why wasn't ART implemented earlier?

Let's take a look at the downsides of AOT compilation.

First of all, the generated machine code requires more space than the existing bytecode. Moreover, the code is pre-compiled at install time, so the installation process takes a bit longer. Furthermore, it also corresponds to a larger memory footprint at execution time. This means that fewer apps run concurrently.
When first Android devices hit the market (like HTC Magic shown in the picture), memory and storage capacity were significantly smaller and presented a bottleneck for performance. This is the reason why a JIT approach was the preferred option at that time. Today, memory is much cheaper and thus more abundant, even on low-end devices, so ART is a logical step forward. 

Monday, 26 October 2015

What Is a Socket?


'**A server application normally listens to a specific port waiting for connection requests from a client. When a connection request arrives, the client and the server establish a dedicated connection over which they can communicate. During the connection process, the client is assigned a local port number, and binds a socket to it. The client talks to the server by writing to the socket and gets information from the server by reading from it. Similarly, the server gets a new local port number (it needs a new port number so that it can continue to listen for connection requests on the original port). The server also binds a socket to its local port and communicates with the client by reading from and writing to it.The client and the server must agree on a protocol--that is, they must agree on the language of the information transferred back and forth through the socket.


Definition: A socket is one end-point of a two-way communication link between two programs running on the network.

**The java.net package provides two classes--Socket and ServerSocket--that implement the client side of the connection and the server side of the connection, respectively.
          Definition:              A socket is one endpoint of a two-way communication link between two programs running on the                        network. A socket is bound to a port number so that the TCP layer can identify the application that data               is destined to be sent to.

Friday, 9 October 2015

Serialization vs Synchronization


Serialization is used whenever you try to store an object in a file or suppose
you want to transfer an object from one application to another application via
network in that case you serialize an object so whenever a object is serialize
it make sense because it can be transferred over the network and it can be
persisted. This is very important whenever data is transferred across the
network or you want to store it in a file right to a file. Synchronization is
whenever multiple thread that trying to access object or instance or method
then there might be problem for concurrency issues because it may happen that
once I just trying to modify the value of a variable and at the same time
another thread is trying to read it so in those cases we try to use
synchronized keyword over a block of code or over a method so that only one
thread can access that method at a time and all other threads have to wait so
only when this current thread exist the method and releases the control to
other threads in waiting.

In Other way:

Synchronization is a concurrency issue, e.g. how do you coordinate access to an object from multiple threads.

Here an arrow represents access.

                            s
 [thread1] ---------------> y
                            n [shared object]
 [thread2] ---------------> c
                            h
Serialization is the conversion of data structures and objects into a sequence of bits that you can store/transmit and then convert back to data structures and objects.

Here an arrow represents conversion.

            deserialization
           <---------------
  [object]                  [binary]
           --------------->
            serialization
This is most useful when the deserialization happens at another place and/or time.

Wednesday, 30 September 2015

How to Develop IME or SoftKeyboard or Custom Keyboard in Android?

Introduction:

BaseInputConnection
Defines the communication channel from an InputMethod back to the application that is receiving its input.
You use it to read text around the cursor, commit text to the text box, and send raw key events to the application.
Applications should extend this class rather than implementing the base interface InputConnection.

KeyboardView
An extension of View that renders a keyboard and responds to user input events.
The keyboard layout is specified by an instance of Keyboard, which you can define in an XML file.

Menifest:
In the Android system, an IME is an Android application that contains a IME service. The application's manifest file must declare the service, request the necessary permissions, provide an intent filter that matches the action action.view.InputMethod, and provide metadata that defines characteristics of the IME.
eg:-
<service android:name=".SimpleIME"
    android:label="@string/simple_ime"
    android:permission="android.permission.BIND_INPUT_METHOD"
    >
    <meta-data android:name="android.view.im" android:resource="@xml/method"/>
    <intent-filter>
        <action android:name="android.view.InputMethod" />
    </intent-filter>          
</service>

How can Design Keyboard Layout:
The layout of our keyboard contains only a KeyboardView.
<?xml version="1.0" encoding="UTF-8"?>
<android.inputmethodservice.KeyboardView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/keyboard"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:layout_alignParentBottom="true"
    android:keyPreviewLayout ="@layout/preview"
/>

Create a SoftKeyboard Class:

Create a new Java class and call it SoftKeyboard.java. The class should extend InputMethodService class and implement the OnKeyboardActionListener interface. The OnKeyboardActionListener interface contains the methods that are called when keys of the soft keyboard are tapped or pressed.

The SoftKeyboard class should have three member variables:

1.a KeyboardView referencing the view defined in the layout
2.a Keyboard instance that is assigned to the KeyboardView
3.a boolean telling us if the caps lock is enabled

After declaring these variables and adding the methods of the OnKeyboardActionListener interface, the SoftKeyboard class should look like this:

Switching among IME Subtypes:

You can allow users to switch easily among multiple IME subtypes by providing a switching key, such as the globe-shaped language icon, as part of the keyboard. Doing so greatly improves the keyboard's usability, and can help avoid user frustration. To enable such switching, perform the following steps:

Declare supportsSwitchingToNextInputMethod = "true" in the input method's XML resource files. Your declaration should look similar to the following snippet:
<input-method xmlns:android="http://schemas.android.com/apk/res/android"
        android:settingsActivity="com.example.softkeyboard.Settings"
        android:icon="@drawable/ime_icon"
        android:supportsSwitchingToNextInputMethod="true">

Call the shouldOfferSwitchingToNextInputMethod() method.



Tuesday, 29 September 2015

InputMethodSubtype:


This class is used to specify meta information of a subtype contained in an input method editor (IME). Subtype can describe locale (e.g. en_US, fr_FR...) and mode (e.g. voice, keyboard...), and is used for IME switch and settings. The input method subtype allows the system to bring up the specified subtype of the designated IME directly.

What is a Subtype
A subtype is a way to present multiple modes of operation for an Input Method Service. Commonly these different modes represent different languages, but they can also be totally different means of input such as voice input or handwriting recognition.

Before the introduction of Subtypes in Android Honeycomb (API version 11) an Input Method mapped directly to an implementation of InputMethodService.

  • The Documentation Provided by Android for Subtypes
  • The APIs surrounding Input Methods
  • InputMethodSubtype
  • InputMethodInfo
  • InputMethodManager
  • The Source code for the Android Latin IME
  • The Source code for Android

Monday, 28 September 2015


 Difference between SOAP webservice and RESTFUL webservice"

At a very basic level , SOAP is a messaging protocol , REST is a design philosophy , not a protocol. When you base a WebService on a SOAP protocol , you basically comply with SOAP rules of creating a Service Request , posting the request to server , receiving the request at server , processing the request and returning the results as a SOAP message.SOAP does not talk about the exact manner in which client benefits from the service, nor about how to design the client itself ( apart from the message it is posting ), it only tells how a message from client can be sent to service and back.
REST is short for REpresentational State Transfer. It does not specify the rules to create a message and post it to server. You can do this by simple HTTP protocol. What REST specifies is the manner in which client and server manage their states so that they become useful to the client -server communication. Here , you are more focussed on designing the states of clients and servers rather than the messages they are exchanging.