Wednesday, 14 January 2015

SQLite browser

DB Browser for SQLite Portable (formerly SQLite Database Browser) is a visual tool used to create, design and edit database files compatible with SQLite.
SQLite is extremely popular for embedded systems. It is also used by operating systems, Web browsers and
countless mobile applications,including the smartphone and tablet versions of this encyclopedia. 

Tuesday, 13 January 2015

Dialog boxes



A dialog is a small window that prompts the user to make a decision or enter additional information. A dialog does not fill the screen and is normally used for modal events that require users to take an action before they can proceed.

Create Alert  Dialog Boxes


package com.example.alertdialog;
import com.example.alertdialog.*;
import android.os.Bundle;import android.app.Activity;
import android.app.AlertDialog;
import android.content.DialogInterface;
import android.content.Intent;
import android.view.Menu;
import android.view.View;
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
public void open(View view){
AlertDialog.Builder alertDialogBuilder = new AlertDialog.Builder(this);
alertDialogBuilder.setMessage(R.string.decision);
alertDialogBuilder.setPositiveButton(R.string.positive_button,
new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface arg0, int arg1) {
Intent positveActivity = new Intent(getApplicationContext(),com.example.alertdialog.PositiveActivity.class);
startActivity(positveActivity);
}
});
alertDialogBuilder.setNegativeButton(R.string.negative_button,
new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
Intent negativeActivity = new Intent(getApplicationContext(),com.example.alertdialog.NegativeActivity.class);
startActivity(negativeActivity);
}
});
AlertDialog alertDialog = alertDialogBuilder.create();
alertDialog.show();
}
@Override
public boolean onCreateOptionsMenu(Menu menu) {
// Inflate the menu; this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.main, menu);
return true;
}
}

Monday, 12 January 2015

Controls

Common Controls

Control TypeDescriptionRelated Classes
ButtonA push-button that can be pressed, or clicked, by the user to perform an action.Button
Text fieldAn editable text field. You can use the AutoCompleteTextViewwidget to create a text entry widget that provides auto-complete suggestionsEditText,AutoCompleteTextView
CheckboxAn on/off switch that can be toggled by the user. You should use checkboxes when presenting users with a group of selectable options that are not mutually exclusive.CheckBox
Radio buttonSimilar to checkboxes, except that only one option can be selected in the group.RadioGroup
RadioButton
Toggle buttonAn on/off button with a light indicator.ToggleButton
SpinnerA drop-down list that allows users to select one value from a set.Spinner
PickersA dialog for users to select a single value for a set by using up/down buttons or via a swipe gesture. Use a DatePickercode> widget to enter the values for the date (month, day, year) or aTimePicker widget to enter the values for a time (hour, minute, AM/PM), which will be formatted automatically for the user's locale.DatePicker,TimePicker

Friday, 9 January 2015

XML LAYOUTS


A layout defines the visual structure for a user interface, such as the UI for an activity or app widget. You can declare a layout in two ways:
  • Declare UI elements in XML. Android provides a straightforward XML vocabulary that corresponds to the View classes and subclasses, such as those for widgets and layouts.
  • Instantiate layout elements at runtime. Your application can create View and ViewGroup objects (and manipulate their properties) programmatically.

Common Layouts



Frame Layout - designed to display a stack of child View controls. Multiple view controls can be added to this layout. This can be used to show multiple controls within the same screen space.


Linear Layout - designed to display child View controls in a single row or column. This is a very handy layout method for creating forms. A layout that organizes its children into a single horizontal or vertical row. It creates a scrollbar if the length of the window exceeds the length of the screen.

Relative Layout - designed to display child View controls in relation to each other. For instance, you can set a control to be positioned “above” or “below” or “to the left of” or “to the right of” another control, referred to by its unique identifier. You can also align child View controls relative to the parent edges. 


Table Layout - designed to organize child View controls into rows and columns. Individual View controls are added within each row of the table using a Table Row layout View (which is basically a horizontally oriented Linear Layout) for each row of the table.

Layout Parameters

XML layout attributes named layout_something define layout parameters for the View that are appropriate for the ViewGroup in which it resides.
Every ViewGroup class implements a nested class that extends ViewGroup.LayoutParams. This subclass contains property types that define the size and position for each child view, as appropriate for the view group. As you can see in figure 1, the parent view group defines layout parameters for each child view (including the child view group).

Figure 1. Visualization of a view hierarchy with layout parameters associated with each view.
Note that every Layout Params subclass has its own syntax for setting values. Each child element must define Layout Params that are appropriate for its parent, though it may also define different Layout Params for its own children.
All view groups include a width and height (layout_width and layout_height), and each view is required to define them. Many LayoutParams also include optional margins and borders.
You can specify width and height with exact measurements, though you probably won't want to do this often. More often, you will use one of these constants to set the width or height:
  • wrap_content tells your view to size itself to the dimensions required by its content.
  • match_parent (named fill_parent before API Level 8) tells your view to become as big as its parent view group will allow.
In general, specifying a layout width and height using absolute units such as pixels is not recommended. Instead, using relative measurements such as density-independent pixel units (dp), wrap_content, or match_parent, is a better approach, because it helps ensure that your application will display properly across a variety of device screen sizes. The accepted measurement types are defined in the Available Resources document.

Layout Position


The geometry of a view is that of a rectangle. A view has a location, expressed as a pair of left and top coordinates, and two dimensions, expressed as a width and a height. The unit for location and dimensions is the pixel.
It is possible to retrieve the location of a view by invoking the methods getLeft() and getTop(). The former returns the left, or X, coordinate of the rectangle representing the view. The latter returns the top, or Y, coordinate of the rectangle representing the view. These methods both return the location of the view relative to its parent. For instance, when getLeft() returns 20, that means the view is located 20 pixels to the right of the left edge of its direct parent.
In addition, several convenience methods are offered to avoid unnecessary computations, namely getRight()and getBottom(). These methods return the coordinates of the right and bottom edges of the rectangle representing the view. For instance, calling getRight() is similar to the following computation: getLeft() + getWidth().

Size, Padding and Margins


The size of a view is expressed with a width and a height. A view actually possess two pairs of width and height values.
The first pair is known as measured width and measured height. These dimensions define how big a view wants to be within its parent. The measured dimensions can be obtained by calling getMeasuredWidth() andgetMeasuredHeight().
The second pair is simply known as width and height, or sometimes drawing width and drawing height. These dimensions define the actual size of the view on screen, at drawing time and after layout. These values may, but do not have to, be different from the measured width and height. The width and height can be obtained by callinggetWidth() and getHeight().
To measure its dimensions, a view takes into account its padding. The padding is expressed in pixels for the left, top, right and bottom parts of the view. Padding can be used to offset the content of the view by a specific number of pixels. For instance, a left padding of 2 will push the view's content by 2 pixels to the right of the left edge. Padding can be set using the setPadding(int, int, int, int) method and queried by callinggetPaddingLeft()getPaddingTop()getPaddingRight() and getPaddingBottom().
Even though a view can define a padding, it does not provide any support for margins. However, view groups provide such a support. Refer to ViewGroup and ViewGroup.MarginLayoutParams for further information.
Attributes

Every View and ViewGroup object supports their own variety of XML attributes. Some attributes are specific to a View object (for example, TextView supports the textSize attribute), but these attributes are also inherited by any View objects that may extend this class. Some are common to all View objects, because they are inherited from the root View class (like the id attribute). And, other attributes are considered "layout parameters," which are attributes that describe certain layout orientations of the View object, as defined by that object's parent ViewGroup object.

ID

Any View object may have an integer ID associated with it, to uniquely identify the View within the tree. When the application is compiled, this ID is referenced as an integer, but the ID is typically assigned in the layout XML file as a string, in the id attribute. This is an XML attribute common to all View objects (defined by the View class) and you will use it very often. The syntax for an ID, inside an XML tag is:
android:id="@+id/my_button"
The at-symbol (@) at the beginning of the string indicates that the XML parser should parse and expand the rest of the ID string and identify it as an ID resource. The plus-symbol (+) means that this is a new resource name that must be created and added to our resources (in the R.java file). There are a number of other ID resources that are offered by the Android framework. When referencing an Android resource ID, you do not need the plus-symbol, but must add the android package namespace, like so:
android:id="@android:id/empty"
With the android package namespace in place, we're now referencing an ID from the android.R resources class, rather than the local resources class.
In order to create views and reference them from the application, a common pattern is to:
  1. Define a view/widget in the layout file and assign it a unique ID:
    <Button android:id="@+id/my_button"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="@string/my_button_text"/>
  2. Then create an instance of the view object and capture it from the layout (typically in the onCreate() method):
    Button myButton = (Button) findViewById(R.id.my_button);
Defining IDs for view objects is important when creating a RelativeLayout. In a relative layout, sibling views can define their layout relative to another sibling view, which is referenced by the unique ID.

layout_width

android:layout_width="fill_parent" android:layout_height="wrap_content"
fill_parent  match_parent, and it means that it takes the width or height (which ever property it is being specified as) of the "parent" container
wrap_content means that the height or width takes on the height or width of the "child"
layout_height
android:layout_height="fill_parent" android:layout_height="fill_parent"




Thursday, 8 January 2015

FOLDER, FILE & DESCRIPTION OF ANDROID APPS


src: This contains the .java source files for your project.

gen: contains the .R file, a compiler-generated file that references all the resources found in your project. You should not modify this file.


bin: contains the Android package files .apk built by the ADT during the build process and everything else needed to run an Android application.


res/drawable-hdpi

This is a directory for drawable objects that are designed for high-density screens.


res/layout

This is a directory for files that define your app's user interface.


res/values

This is a directory for other various XML files that contain a collection of resources, such as strings and colors definitions.


AndroidManifest.xml

This is the manifest file which describes the fundamental characteristics of the app and defines each of its components.

example:-


<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.okey1" android:versionCode="1" android:versionName="1.0">

<uses-sdk android:minSdkVersion="8" android:targetSdkVersion="18" />
<application android:allowBackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme">
<activity android:name="com.example.okey1.MainActivity" android:label="@string/app_name">

<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>


The AndroidManifest.xml file contains the following information about the application :-
  • It contains the package name of the application.
  • The version code of the application is 1.This value is used to identify the version number of your application.
  • The version name of the application is 1.0
  • The android:minSdkVersion attribute of the element defines the minimum version of the OS on which the application will run.
  • ic_launcher.png is the default image that located in the drawable folders.
  • app_name defines the name of applicationand available in the strings.xml file.
  • It also contains the information about the activity. Its name is same as the application name.



Wednesday, 7 January 2015

ANDROID ACTIVITY AND LIFE-CYCLE


Activity is a single, focused thing that the user can do. when ever user click on GUI the next Activity will be start and new GUI set base on coding.Activity provides the user interface. When you create an android application in eclipse through the wizard it asks you the name of the activity. Default name is Main Activity. You can provide any name according to the need. Basically it is a class (Main Activity) that is inherited automatically from Activity class. Mostly, applications have one or more activities and the main purpose of an activity is to interact with the user. Activity goes through a number of stages, known as an activities life cycle.

Example :-


When you run the application on Create method is called automatically.

Activity Lifecycle
Activities in the system are managed as an activity stack. When a new activity is started, it is placed on the top of the stack and becomes the running activity the previous activity always remains below it in the stack, and will not come to the foreground again until the new activity exits.
An activity has essentially four states:-
  • If an activity in the foreground of the screen (at the top of the stack), it is active or running.
  • If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
  • If an activity is completely obscured by another activity, it is stopped. It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
  • If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
  • The entire lifetime of an activity happens between the first call to onCreate(Bundle) through to a single final call to onDestroy(). An activity will do all setup of "global" state in onCreate(), and release all remaining resources in onDestroy(). For example, if it has a thread running in the background to download data from the network, it may create that thread in onCreate() and then stop the thread in onDestroy().
  • The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onstop(). During this time the user can see the activity on-screen, though it may not be in the foreground and interacting with the user. Between these two methods you can maintain resources that are needed to show the activity to the user. For example, you can register a broadcastreceiver in onStart() to monitor for changes that impact your UI, and unregister it in onStop() when the user no longer sees what you are displaying. The onStart() and onStop() methods can be called multiple times, as the activity becomes visible and hidden to the user.
  • The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time the activity is in front of all other activities and interacting with the user. An activity can frequently go between the resumed and paused states -- for example when the device goes to sleep, when an activity result is delivered, when a new intent is delivered



The following diagram shows the important state paths of an Activity. The square rectangles represent callback methods you can implement to perform operations when the Activity moves between states. The colored ovals are major states the Activity can be in.
State diagram for an Android Activity Lifecycle.

Example:-

package com.example.lifecycle;
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import android.widget.Toast;

public class MainActivity extends Activity {

@Override
protected void onCreate(Bundle savedInstanceState) {
   super.onCreate(savedInstanceState);
   setContentView(R.layout.activity_main);
   Toast.makeText(this, "Activity is created", Toast.LENGTH_SHORT).show();
   Log.i("onCreate():","Activity is created");
   onStart();
   onRestart();
   onResume();
   onPause();
   onStop();
   onDestroy();
   
}

@Override
protected void onStart() {
   // TODO Auto-generated method stub
   super.onStart();
   Toast.makeText(this, "Activity is started", Toast.LENGTH_SHORT).show();
   Log.i("onStart():","Activity started");
}

@Override
protected void onRestart() {
   // TODO Auto-generated method stub
   super.onRestart();
   Toast.makeText(this, "Activity is Restarted", Toast.LENGTH_SHORT).show();
   Log.i("onRestart():","Activity Restarted");
}

@Override
protected void onResume() {
   // TODO Auto-generated method stub
   super.onResume();
   Toast.makeText(this, "Activity is Resumed", Toast.LENGTH_SHORT).show();
   Log.i("onResume():","Activity Resumed");
}

@Override
protected void onPause() {
   // TODO Auto-generated method stub
   super.onPause();
   Toast.makeText(this, "Activity is Paused", Toast.LENGTH_SHORT).show();
   Log.i("onPause():","Activity paused");
}

@Override
protected void onStop() {
   // TODO Auto-generated method stub
   super.onStop();
   Toast.makeText(this, "Activity is Stopped", Toast.LENGTH_SHORT).show();
   Log.i("onStop():","Activity stopped");
}

@Override
protected void onDestroy() {
   // TODO Auto-generated method stub
   super.onDestroy();
   Toast.makeText(this, "Activity is Destroyed", Toast.LENGTH_SHORT).show();
   Log.i("onDestroy():","Activity destroyed");
}
}