welcome to my blog

Synegry is a awesome sofware for interacting 2 pc in the network(for eg: linux & windows)

it like your key board & mouse acts same for bothe PC's like host & client.

one we have to make host and second one need to use as client.

Steps you can see from the below like.

http://www.mattcutts.com/blog/how-to-configure-synergy-in-six-steps/


I enjoying a lot using this software. i configured it its working well.

For developers, the Android 2.3 platform is available as a downloadable component for the Android SDK. The downloadable platform includes an Android library and system image, as well as a set of emulator skins and more. The downloadable platform includes no external libraries.

API Overview

The sections below provide a technical overview of what's new for developers in 2.3, including new features and changes in the framework API since the previous version.

SIP-based VoIP
The platform now includes a SIP protocol stack and framework API that lets developers build internet telephony applications. Using the API, applications can offer voice calling features without having to manage sessions, transport-level communication, or audio — these are handled transparently by the platform's SIP API and services.

The SIP API is available in the android.net.sip package. The key class is SipManager, which applications use to set up and manage SIP profiles, then initiate audio calls and receive audio calls. Once an audio call is established, applications can mute calls, turn on speaker mode, send DTMF tones, and more. Applications can also use the SipManager to create generic SIP connections.

The platform’s underlying SIP stack and services are available on devices at the discretion of the manufacturer and associated carrier. For this reason, applications should use the isApiSupported() method to check whether SIP support is available, before exposing calling functionality to users.

To use the SIP API, applications must request permission from the user by declaring and

in their manifest files.

Additionally, developers can request filtering on Android Market, such that their applications are not discoverable to users whose devices do not include the platform’s SIP stack and services.

To request filtering,
add and to the application manifest.

Near Field Communications (NFC)
Android 2.3 includes an NFC stack and framework API that lets developers read NDEF tags that are discovered as a user touches an NFC-enabled device to tag elements embedded in stickers, smart posters, and even other devices.

The platform provides the underlying NFC services that work with the device hardware to discover tags when they come into range. On discovering a tag, the platform notifies applications by broadcasting an Intent, appending the tag's NDEF messages to the Intent as extras. Applications can create Intent filters to recognize and handle targeted tags and messages. For example, after receiving a tag by Intent, applications extract the NDEF messages, store them, alert the user, or handle them in other ways.

The NFC API is available in the android.nfc package. The key classes are:

NfcAdapter, which represents the NFC hardware on the device.
NdefMessage, which represents an NDEF data message, the standard format in which "records" carrying data are transmitted between devices and tags. Applications can receive these messages from ACTION_TAG_DISCOVERED Intents.
NdefRecord, delivered in an NdefMessage, which describes the type of data being shared and carries the data itself.
NFC communication relies on wireless technology in the device hardware, so support for the platform's NFC features on specific devices is determined by their manufacturers. To determine the NFC support on the current device, applications can call isEnabled() to query the NfcAdapter. The NFC API is always present, however, regardless of underlying hardware support.

To use the NFC API, applications must request permission from the user by declaring in their manifest files.

Additionally, developers can request filtering on Android Market, such that their applications are not discoverable to users whose devices do not support NFC.

To request filtering, add to the application's manifest.

Gyroscope and other sensors
Android 2.3 adds platform and API support for several new sensor reading types — gyroscope, rotation vector, linear acceleration, gravity, and barometer. Developers can use the new sensor readings to create applications that respond quickly and smoothly to precise changes in device position and motion. The Sensor API reports gyroscope and other sensor changes to interested applications, whether they are running on the application framework or in native code.

Note that the specific set of hardware sensors available on any given device varies at the discretion of the device manufacturer.

Developers can request filtering in Android Market, such that their applications are not discoverable to users whose devices do not offer a gyroscope sensor.

To do so, add to the application manifest.

Multiple cameras support
Applications can now make use of any cameras that are available on a device, for either photo or video capture. The Camera lets applications query for the number of cameras available and the unique characteristics of each.

New Camera.CameraInfo class stores a camera's positional characteristics (orientation, front-facing or back-facing).
New getNumberOfCameras(), getCameraInfo(), and getNumberOfCameras() methods in the Camera class let applications query for the cameras available and open the camera that they need.

New get() method lets applications retrieve a CamcorderProfile for a specific camera.
New getJpegEncodingQualityParameter() lets applications obtain the still-image capture quality level for a specific camera.

The Camera API also adds:

New parameters for cameras, including focus distance, focus mode, and preview fps maximum/minimum. New getFocusDistances(), getPreviewFpsRange(), and getSupportedPreviewFpsRange() for getting camera parameters, as well as setPreviewFpsRange() for setting preview framerate.

Mixable audio effects
The platform's media framework adds support for new per-track or global audio effects, including bass boost, headphone virtualization, equalization, and reverb.

New android.media.audiofx package provides the API to access audio effects.
New AudioEffect is the base class for controlling audio effects provided by the Android audio framework.
New audio session ID that lets an application associate a set of audio effects with an instance of AudioTrack or MediaPlayer.
New AudioTrack class constructor that lets you create an AudioTrack with a specific session ID. New attachAuxEffect(), getAudioSessionId(), and setAuxEffectSendLevel() methods.
New attachAuxEffect(), getAudioSessionId(), setAudioSessionId(int), and setAuxEffectSendLevel() methods and supporting types.

The media framework also adds:

New support for altitude tag in EXIF metadata for JPEG files. New method getAltitude() method to retrieve the value of the EXIF altitude tag.
New setOrientationHint() method lets an application tell MediaRecorder of the orientation during video capture.

Download manager
The platform includes a new DownloadManager system service that handles long-running HTTP downloads. Applications can request that a URI be downloaded to a particular destination file. The DownloadManager will conduct the download in the background, taking care of HTTP interactions and retrying downloads after failures or across connectivity changes and system reboots.

Applications can obtain an instance of the DownloadManager class by calling getSystemService(String) and passing DOWNLOAD_SERVICE.

Applications that request downloads through this API should register a broadcast receiver for ACTION_NOTIFICATION_CLICKED, to appropriately handle when the user clicks on a running download in a notification or from the Downloads UI.

The DownloadManager Request class lets an application provide all the information necessary to request a new download, such as request URI and download destination. A request URI is the only required parameter. Note that the default download destination is a shared volume where the system can delete your file if it needs to reclaim space for system use. For persistent storage of a download, specify a download destination on external storage (see setDestinationUri(Uri)).
The DownloadManager.Query class provides methods that let an application query for and filter active downloads.


StrictMode
To help developers monitor and improve the performance of their applications, the platform offers a new system facility called StrictMode. When implemented in an application, StrictMode catches and notifies the developer of accidental disk or network activity that could degrade application performance, such as activity taking place on the application's main thread (where UI operations are received and animations are also taking place). Developers can evaluate the network and disk usages issues raised in StrictMode and correct them if needed, keeping the main thread more responsive and preventing ANR dialogs from being shown to users.

StrictMode is the core class and is the main integration point with the system and VM. The class provides convenience methods for managing the thread and VM policies that apply to the instance.
StrictMode.ThreadPolicy and StrictMode.VmPolicy hold the policies that you define and apply to thread and VM instances.


UI Framework

Support for overscroll
New support for overscroll in Views and Widgets. In Views, applications can enable/disable overscroll for a given view, set the overscoll mode, control the overscroll distance, and handle the results of overscrolling.
In Widgets, applications can control overscroll characteristics such as animation, springback, and overscroll distance. For more information, see android.view.View and android.widget.OverScroller.
ViewConfiguration also provides methods getScaledOverflingDistance() and getScaledOverscrollDistance().

New overScrollMode, overScrollFooter, and overScrollHeader attributes for elements, for controlling overscroll behavior.
Support for touch filtering
New support for touch filtering, which lets an application improve the security of Views that provide access to sensitive functionality. For example, touch filtering is appropriate to ensure the security of user actions such as granting a permission request, making a purchase, or clicking on an advertisement. For details, see the

View class documentation.
New filterTouchesWhenObscured attribute for view elements, which declares whether to filter touches when the view's window is obscured by another visible window. When set to "true", the view will not receive touches whenever a toast, dialog or other window appears above the view's window. Refer to View security documentation for details.
To look at sample code for touch filtering, see SecureView.java in the ApiDemos sample application.

Improved event management
New base class for input events, InputEvent. The class provides methods that let applications determine the meaning of the event, such as by querying for the InputDevice from which the event orginated. The KeyEvent and MotionEvent are subclasses of InputEvent.
New base class for input devices, InputDevice. The class stores information about the capabilities of a particular input device and provides methods that let applications determine how to interpret events from an input device.

Improved motion events
The MotionEvent API is extended to include "pointer ID" information, which lets applications to keep track of individual fingers as they move up and down. The class adds a variety of methods that let an application work efficiently with motion events.
The input system now has logic to generate motion events with the new pointer ID information, synthesizing identifiers as new pointers are down. The system tracks multiple pointer IDs separately during a motion event, and ensures proper continuity of pointers by evaluating at the distance between the last and next set of pointers.

Text selection controls
A new setComposingRegion method lets an application mark a region of text as composing text, maintaining the current styling. A getSelectedText method returns the selected text to the application. The methods are available in BaseInputConnection, InputConnection, and InputConnectionWrapper.
New textSelectHandle, textSelectHandleLeft, textSelectHandleRight, and textSelectHandleWindowStyle attributes for , for referencing drawables that will be used to display text-selection anchors and the style for the containing window.

Activity controls
ActivityInfo adds new constants for managing Activity orientation: SCREEN_ORIENTATION_FULL_SENSOR, SCREEN_ORIENTATION_REVERSE_LANDSCAPE, SCREEN_ORIENTATION_REVERSE_PORTRAIT, SCREEN_ORIENTATION_SENSOR_LANDSCAPE, and SCREEN_ORIENTATION_SENSOR_PORTRAIT.

New constant IMPORTANCE_PERCEPTIBLE for the importance field in ActivityManager.RunningAppProcessInfo. The value indicates that a specific process is running something that is considered to be actively perceptible to the user. An example would be an application performing background music playback.

The setPersistent(boolean) method to mark an Activity as persistent is now deprecated and the implementation is a no-op.
Notification text and icon styles

New TextAppearance.StatusBar.EventContent,
TextAppearance.StatusBar.EventContent.Title, TextAppearance.StatusBar.Icon, and
TextAppearance.StatusBar.Title for managing notification style.

WebView
New setUseWebViewBackgroundForOverscrollBackground() method lets a WebView specify whether to use its own background for the overscroll background.

Extra Large Screens
The platform now supports extra large screen sizes, such as those that might be found on tablet devices. Developers can indicate that their applications are designed to support extra large screen sizes by adding a element to their manifest files. Applications can use a new resource qualifier, xlarge, to tag resources that are specific to extra large screens. For details on how to support extra large and other screen sizes, see Supporting Multiple Screens.

Graphics
Adds remaining OpenGL ES 2.0 methods glDrawElements() and glVertexAttribPointer() in the android.opengl.GLES20 class.
Adds support for YV12 pixel format, a planar 4:2:0 YCrCb format.
Content Providers

New AlarmClock provider class for setting an alarm or handling an alarm. The provider contains a ACTION_SET_ALARM Intent action and extras that can be used to start an Activity to set a new alarm in an alarm clock application. Applications that wish to receive the SET_ALARM Intent should create an activity that requires the the SET_ALARM permission. Applications that wish to create a new alarm should use Context.startActivity(), so that the user has the option of choosing which alarm clock application to use.

MediaStore supports a new Intent action, PLAY_FROM_SEARCH, that lets an application search for music media and automatically play content from the result when possible. For example, an application could fire this Intent as the result of a voice recognition command to listen to music.

MediaStore also adds a new MEDIA_IGNORE_FILENAME flag that tells the media scanner to ignore media in the containing directory and its subdirectories. Developers can use this to avoid having graphics appear in the Gallery and likewise prevent application sounds and music from showing up in the Music app.

The Settings provider adds the new Activity actions APPLICATION_DETAILS_SETTINGS and MANAGE_ALL_APPLICATIONS_SETTINGS, which let an application show the details screen for a specific application or show the Manage Applications screen.
The ContactsContract provider adds the ContactsContract.CommonDataKinds.SipAddress data kind, for storing a contact's SIP (Internet telephony) address.
Location

The LocationManager now tracks application requests that result in wake locks or wifi locks according to WorkSource, a system-managed class that identifies the application.
The LocationManager keeps track of all clients requesting periodic updates, and tells its providers about them as a WorkSource parameter, when setting their minimum update times. The network location provider uses WorkSource to track the wake and wifi locks initiated by an application and adds it to the application's battery usage reported in Manage Applications.
The LocationManager adds several new methods that let an Activity register to receive periodic or one-time location updates based on specified criteria (see below).
A new Criteria class lets an application specify a set of criteria for selecting a location provider. For example, providers may be ordered according to accuracy, power usage, ability to report altitude, speed, and bearing, and monetary cost.

Storage
Android 2.3 adds a new StorageManager that supports OBB (Opaque Binary Blob) files. Although platform support for OBB is available in Android 2.3, development tools for creating and managing OBB files will not be availble until early 2011.
The Android 2.3 platform adds official support for devices that do not include SD cards (although it provides virtual SD Card partition, when no physical SD card is available). A convenience method, isExternalStorageRemovable(), lets applications determine whether a physical SD card is present.

Package Manager
New constants for declaring hardware and software features. See the list in the New Feature Constants section, below.
PackageInfo adds new firstInstallTime and lastUpdateTime fields that store the time of the package installation and last update.
New getProviderInfo() method for retrieving all of the information known about a particular content provider class.

Telephony
The TelephonyManager adds the constant NETWORK_TYPE_EVDO_B for specifying the CDMA EVDO Rev B network type.
New getPsc() method returns the primary scrambling code of the serving cell on a UMTS network.
Native access to Activity lifecycle, windows
Android 2.3 exposes a broad set of APIs to applications that use native code. Framework classes of interest to such applications include:

NativeActivity is a new type of Activity class, whose lifecycle callbacks are implemented directly in native code. A NativeActivity and its underlying native code run in the system just as do other Activities — specifically they run in the Android application's system process and execute on the application's main UI thread, and they receive the same lifecycle callbacks as do other Activities.
New InputQueue class and callback interface lets native code manage event queueing.
New SurfaceHolder.Callback2 interface lets native code manage a SurfaceHolder.
New takeInputQueue and takeSurface() methods in Window let native code manage events and surfaces.
For full information on working with native code or to download the NDK, see the Android NDK page.


Dalvik Runtime
dalvik.system removes several classes that were previously deprecated.
Dalvik core libraries:
New collections: ArrayDeque, NavigableMap, ConcurrentSkipListMap, LinkedBlockingDeque
New Arrays utilities: binarySearch(), copyOf(), copyOfRange(), and others.
CookieManager for HttpURLConnection.
More complete network APIs: InterfaceAddress, NetworkInterface and IDN
File read and write controls
String.isEmpty()
Normalizer and Normalizer.Form
Improved javax.net.ssl server sockets.
New manifest elements and attributes
New xlargeScreens attribute for element, to indicate whether the application supports extra large screen form-factors.

For details, see Supporting
Multiple Screens.
New values for android:screenOrientation attribute of element:
"reverseLandscape" — The Activity would like to have the screen in landscape orientation, turned in the opposite direction from normal landscape.
"reversePortait" — The Activity would like to have the screen in portrait orientation, turned in the opposite direction from normal portrait.
"sensorLandscape" — The Activity would like to have the screen in landscape orientation, but can use the sensor to change which direction the screen is facing.
"sensorPortrait" — The Activity would like to have the screen in portrait orientation, but can use the sensor to change which direction the screen is facing.
"fullSensor" — Orientation is determined by a physical orientation sensor: the display will rotate based on how the user moves the device. This allows any of the 4 possible rotations, regardless of what the device will normally do (for example some devices won't normally use 180 degree rotation).
New Permissions
com.android.permission.SET_ALARM — Allows an application to broadcast an Intent to set an alarm for the user. An Activity that handles the SET_ALARM Intent action should require this permission.
android.permission.USE_SIP — Allows an application to use the SIP API to make or receive internet calls.
android.permission.NFC — Allows an application to use the NFC API to read NFC tags.
New Feature Constants
The platform adds several new hardware features that developers can declare in their application manifests as being required by their applications. This lets developers control how their application is filtered, when published on Android Market.

android.hardware.audio.low_latency — The application uses a low-latency audio pipeline on the device and is sensitive to delays or lag in sound input or output.
android.hardware.camera.front — The application uses a front-facing camera on the device.

android.hardware.nfc — The application uses NFC radio features in the device.
android.hardware.sensor.barometer — The application uses the device's barometer.
android.hardware.sensor.gyroscope — The application uses the device's gyroscope sensor.
android.software.sip — The application uses the SIP API on the device.
android.software.sip.voip — The application uses a SIP-based VoIP service on the device.

android.hardware.touchscreen.multitouch.jazzhand — The application uses advanced multipoint multitouch capabilities on the device screen, for tracking five or more points fully independently.

The Android 2.3 platform introduces many new and exciting features for users and developers. This document provides a glimpse at some of the new features and technologies in Android 2.3. For detailed information about the new developer APIs, see the Android 2.3 version notes.

New User Features
New Developer Features
New Platform Technologies


New User Features


UI refinements for simplicity and speed
The user interface is refined in many ways across the system, making it easier to learn, faster to use, and more power-efficient. A simplified visual theme of colors against black brings vividness and contrast to the notification bar, menus, and other parts of the UI. Changes in menus and settings make it easier for the user to navigate and control the features of the system and device.

Faster, more intuitive text input
The Android soft keyboard is redesigned and optimized for faster text input and editing. The keys themselves are reshaped and repositioned for improved targeting, making them easier to see and press accurately, even at high speeds. The keyboard also displays the current character and dictionary suggestions in a larger, more vivid style that is easier to read.

The keyboard adds the capability to correct entered words from suggestions in the dictionary. As the user selects a word already entered, the keyboard displays suggestions that the user can choose from, to replace the selection. The user can also switch to voice input mode to replace the selection. Smart suggestions let the user accept a suggestion and then return to correct it later, if needed, from the original set of suggestions.

New multitouch key-chording lets the user quickly enter numbers and symbols by pressing Shift+ and ?123+, without needing to manually switch input modes. From certain keys, users can also access a popup menu of accented characters, numbers, and symbols by holding the key and sliding to select a character.


One-touch word selection and copy/paste
When entering text or viewing a web page, the user can quickly select a word by press-hold, then copy to the clipboard and paste. Pressing on a word enters a free-selection mode — the user can adjust the selection area as needed by dragging a set of bounding arrows to new positions, then copy the bounded area by pressing anywhere in the selection area. For text entry, the user can slide-press to enter a cursor mode, then reposition the cursor easily and accurately by dragging the cursor arrow. With both the selection and cursor modes, no use of a trackball is needed.


Improved power management
The Android system takes a more active role in managing apps that are keeping the device awake for too long or that are consuming CPU while running in the background. By managing such apps — closing them if appropriate — the system helps ensure best possible performance and maximum battery life.

The system also gives the user more visibility over the power being consumed by system components and running apps. The Application settings provides an accurate overview of how the battery is being used, with details of the usage and relative power consumed by each component or application.

Control over applications
A shortcut to the Manage Applications control now appears in the Options Menu in the Home screen and Launcher, making it much easier to check and manage application activity. Once the user enters Manage Applications, a new Running tab displays a list of active applications and the storage and memory being used by each. The user can read further details about each application and if necessary stop an application or report feedback to its developer.

New ways of communicating, organizing
An updated set of standard applications lets the user take new approaches to managing information and relationships.



Internet calling

The user can make voice calls over the internet to other users who have SIP accounts. The user can add an internet calling number (a SIP address) to any Contact and can initiate a call from Quick Contact or Dialer. To use internet calling, the user must create an account at the SIP provider of their choice — SIP accounts are not provided as part of the internet calling feature. Additionally, support for the platform's SIP and internet calling features on specific devices is determined by their manufacturers and associated carriers.


Near-field communications

An NFC Reader application lets the user read and interact with near-field communication (NFC) tags. For example, the user can “touch” or “swipe” an NFC tag that might be embedded in a poster, sticker, or advertisement, then act on the data read from the tag. A typical use would be to read a tag at a restaurant, store, or event and then rate or register by jumping to a web site whose URL is included in the tag data. NFC communication relies on wireless technology in the device hardware, so support for the platform's NFC features on specific devices is determined by their manufacturers.

Downloads management

The Downloads application gives the user easy access to any file downloaded from the browser, email, or another application. Downloads is built on an completely new download manager facility in the system that any other applications can use, to more easily manage and store their downloads.

Camera

The application now lets the user access multiple cameras on the device, including a front-facing camera, if available.

New Developer Features

Android 2.3 delivers a variety of features and APIs that let developers bring new types of applications to the Android platform.

Enhancements for gaming
New forms of communication
Rich multimedia
Enhancements for gaming
Performance

Android 2.3 includes a variety of improvements across the system that make common operations faster and more efficient for all applications. Of particular interest to game developers are:

Concurrent garbage collector — The Dalivik VM introduces a new, concurrent garbage collector that minimizes application pauses, helping to ensure smoother animation and increased responsiveness in games and similar applications.
Faster event distribution — The plaform now handles touch and keyboard events faster and more efficiently, minimizing CPU utilization during event distribution. The changes improve responsiveness for all applications, but especially benefit games that use touch events in combination with 3D graphics or other CPU-intensive operations.
Updated video drivers — The platform uses updated third-party video drivers that improve the efficiency of OpenGL ES operations, for faster overall 3D graphics performance.
Native input and sensor events

Applications that use native code can now receive and process input and sensor events directly in their native code, which dramatically improves efficiency and responsiveness.

Native libraries exposed by the platform let applications handle the same types of input events as those available through the framework. Applications can receive events from all supported sensor types and can enable/disable specific sensors and manage event delivery rate and queueing.

Gyroscope and other new sensors, for improved 3D motion processing

Android 2.3 adds API support for several new sensor types, including gyroscope, rotation vector, linear acceleration, gravity, and barometer sensors. Applications can use the new sensors in combination with any other sensors available on the device, to track three-dimensional device motion and orientation change with high precision and accuracy. For example, a game application could use readings from a gyroscope and accelerometer on the device to recognize complex user gestures and motions, such as tilt, spin, thrust, and slice.

Open API for native audio

The platform provides a software implementation of Khronos OpenSL ES, a standard API that gives applications access to powerful audio controls and effects from native code. Applications can use the API to manage audio devices and control audio input, output, and processing directly from native code.

Native graphics management

The platform provides an interface to its Khronos EGL library, which lets applications manage graphics contexts and create and manage OpenGL ES textures and surfaces from native code.

Native access to Activity lifecycle, window management

Native applications can declare a new type of Activity class, NativeActivity whose lifecycle callbacks are implemented directly in native code. The NativeActivity and its underlying native code run in the system just as do other Activities — they run in the application's system process and execute on the application's main UI thread, and they receive the same lifecycle callbacks as do other Activities.

The platform also exposes native APIs for managing windows, including the ability to lock/unlock the pixel buffer to draw directly into it. Through the API, applications can obtain a native window object associated with a framework Surface object and interact with it directly in native code.

Native access to assets, storage

Applications can now access a native Asset Manager API to retrieve application assets directly from native code without needing to go through JNI. If the assets are compressed, the platform does streaming decompression as the application reads the asset data. There is no longer a limit on the size of compressed .apk assets that can be read.

Additionally, applications can access a native Storage Manager API to work directly with OBB files downloaded and managed by the system. Note that although platform support for OBB is available in Android 2.3, development tools for creating and managing OBB files will not be available until early 2011.

Robust native development environment

The Android NDK (r5 or higher) provides a complete set of tools, toolchains, and libraries for developing applications that use the rich native environment offered by the Android 2.3 platform. For more information or to download the NDK, please see the Android NDK page.

New forms of communication
Internet telephony

Developers can now add SIP-based internet telephony features to their applications. Android 2.3 includes a full SIP protocol stack and integrated call management services that let applications easily set up outgoing and incoming voice calls, without having to manage sessions, transport-level communication, or audio record or playback directly.

Support for the platform's SIP and internet calling features on specific devices is determined by their manufacturers and associated carriers.

Near Field Communications (NFC)

The platform's support for Near Field Communications (NFC) lets developers get started creating a whole new class of applications for Android. Developers can create new applications that offer proximity-based information and services to users, organizations, merchants, and advertisers.

Using the NFC API, applications can respond to NFC tags “discovered” as the user “touches” an NFC-enabled device to elements embedded in stickers, smart posters, and even other devices. When a tag of interest is collected, applications can respond to the tag, read messages from it, and then store the messages, prompting the user as needed.

NFC communication relies on wireless technology in the device hardware, so support for the platform's NFC features on specific devices is determined by their manufacturers.

Rich multimedia
Mixable audio effects

A new audio effects API lets developers easily create rich audio environments by adding equalization, bass boost, headphone virtualization (widened soundstage), and reverb to audio tracks and sounds. Developers can mix multiple audio effects in a local track or apply effects globally, across multiple tracks.

Support for new media formats

The platform now offers built-in support for the VP8 open video compression format and the WebM open container format. The platform also adds support for AAC encoding and AMR wideband encoding (in software), so that applications can capture higher quality audio than narrowband.

Access to multiple cameras

The Camera API now lets developers access any cameras that are available on a device, including a front-facing camera. Applications can query the platform for the number of cameras on the device and their types and characteristics, then open the camera needed. For example, a video chat application might want to access a front-facing camera that offers lower-resolution, while a photo application might prefer a back-facing camera that offers higher-resolution.

New Platform Technologies

Media Framework
New media framework fully replaces OpenCore, maintaining all previous codec/container support for encoding and decoding.
Integrated support for the VP8 open video compression format and the WebM open container format
Adds AAC encoding and AMR wideband encoding
Linux Kernel
Upgraded to 2.6.35
Networking
SIP stack, configurable by device manufacturer
Support for Near Field Communications (NFC), configurable by device manufacturer
Updated BlueZ stack
Dalvik runtime
Dalvik VM:
Concurrent garbage collector (target sub-3ms pauses)
Adds further JIT (code-generation) optimizations
Improved code verification
StrictMode debugging, for identifying performance and memory issues
Core libraries:
Expanded I18N support (full worldwide encodings, more locales)
Faster Formatter and number formatting. For example, float formatting is 2.5x faster.
HTTP responses are gzipped by default. XML and JSON API response sizes may be reduced by 60% or more.
New collections and utilities APIs
Improved network APIs
Improved file read and write controls
Updated JDBC
Updates from upstream projects:
OpenSSL 1.0.0a
BouncyCastle 1.45
ICU 4.4
zlib 1.2.5

Having threads to do some heavy lifting and long processing in the background is pretty standard stuff. Very often you would want to notify or prompt the user after the background task has finished by displaying a Dialog.

The displaying of the Dialog has to happen on the UI thread, so you would do that either in the Handler object for the thread or in the onPostExecute method of an AsyncTask (which is a thread as well, just an easier way of implementing it). That is a textbook way of doing this and you would think that pretty much nothing wrong could go with this.

Surprisingly I found out that something CAN actually go wrong with this. After Google updated the Android Market and started giving crash reports to the developers I received the following exception:

android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@447a6748 is not valid; is your activity running?
at android.view.ViewRoot.setView(ViewRoot.java:468)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:177)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:91)
at android.view.Window$LocalWindowManager.addView(Window.java:424)
at android.app.Dialog.show(Dialog.java:239)
at android.app.Activity.showDialog(Activity.java:2488)
…
at android.os.Handler.dispatchMessage(Handler.java:99)
…

I only got a couple of these exceptions from thousands of installs, so I knew that was not anything that happens regularly or that it was easy to replicate.

Looking at the stack trace above it gives us a pretty good idea why it failed. It started in the Handler object, which naturally was called by a background thread after it finished its processing. The Handler instance tried to show a Dialog and before it could show it, it tried to set the View for it and then it failed with:

android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@447a6748 is not valid; is your activity running?

The 447a6748 number is just a memory address of an object that no longer exists.

Note- do not get hung up on the exact number. It would be different with every execution.

Now we know why the application crashed, the only thing left is to figure out what caused it?

We know that background threads execute independently of the main UI thread. That means that the user could be interacting with the application during the time that the thread is doing its work under the covers. Well, what happens if the user hits the “Back” button on the device while the background thread is running and what happens to the Dialog that this thread is supposed to show? Well, if the timing is right the application will most likely crash with the above described error.

In other words what happens is that the Activity will be going through its destruction when the background thread finishes its work and tries to show a Dialog.

In this case it is almost certain that this should have been handled by the Virtual Machine. It should have recognized the fact that the Activity is in the process of finishing and not even attempted to show the Dialog. This is an oversight of the Google developers and it will probably be fixed some time in the future, but in the meantime the burden is on us to take care of this.

The fix to this is pretty simple. Just test if the Activity is going through its finishing phase before displaying the Dialog:

private Handler myHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case DISPLAY_DLG:
if (!isFinishing()) {
showDialog(MY_DIALOG);
}
break;
}
}
};

Öredev 2010 is over and it is time for me write some words about the conference. What I like about the conference is that has an interesting mix of tracks; Java, .NET, Agile, Web Development etc. It is always nice to broaden your views. New this year was the Xtra(ck). The Xtra(ck) contained sessions that had nothing to with software development, or at least very far from it. For example there was a session called "Understand Hypnosis". These session was definitely a way to broaden your mind. I liked the "Photographic Composition and Creativity" and the photo walk both with Amy Archer. Thanks for the tips during the photo walk!

Also new for this year was the Öredev puzzle application. The application was designed around the concept of being social. Each participant got a puzzle code within the application. By sharing your code you got a piece of the puzzle. As a bonus you got the contact information for the person whose code you entered. Each person to finish the puzzle got an Öredev t-shirt and was participating to win some great prizes. The application was available for Blackberry, Android, Windows Phone 7 and iPhone. The application also contained the schedule and speaker bios. A real nice application. Next year I hope to see an improved version. For example, integrating your own schedule would be great.

And here are some photos from the conference. Enjoy!

Öredev 2010 - Get Real

Speaker Dinner at Malmö City Hall

Developers Competing

Hard to Choose the Righr Track?

Even Doll showing of Some Nice Xcode Tricks

Coffe Lounge

Jack Nutting about Making Money in Appstore

John Seddon

Marcus Zarra on Core Graphics

The Audience

Library by Night

The hosts file is a computer file used in an operating system to map hostnames to IP addresses. The hosts file is a plain-text file and is traditionally named hosts.

The hosts file is one of several system facilities to assist in addressing network nodes in a computer network. It is a common part in a operating system's Internet Protocol (IP) implementation, and serves the function of translating human-friendly hostnames into numeric protocol addresses, called IP addresses, that identify and locate a host in an IP network.
In some operating systems, the host file content is used preferentially over other methods, such as the Domain Name System (DNS), but many systems implement name service switches (.e.g., nsswitch.conf) to provide customization. Unlike the DNS, the hosts file is under the direct control of the local computer's administrator.

#This is an example of the hosts file
127.0.0.1 localhost loopback
::1 localhost

path of host file is:

Windows 95/98/Me c:\windows\hosts

Windows NT/2000/XP Pro c:\winnt\system32\drivers\etc\hosts

Windows XP Home c:\windows\system32\drivers\etc\hosts

From the below snippet we can check the list of running applications and check whether your application is in foreground or not.

ActivityManager actvityManager = (ActivityManager)
this.getSystemService( ACTIVITY_SERVICE );
List procInfos = actvityManager.getRunningAppProcesses();

boolean appFound = false;

for(int i = 0; i < procInfos.size(); i++)
{
if(procInfos.get(i).processName == "com.android.camera")
appFound = true;
}

if (appFound)
Toast.makeText(getApplicationContext(), "Camera App is running!!!!", Toast.LENGTH_LONG).show();
else
Toast.makeText(getApplicationContext(), "Camera App is not running!!!!", Toast.LENGTH_LONG).show();

the above snippet shows your camera application is running or not.

Today i gone through this tutorial from developer site seems to be interesting for UI application performance ,adding basic information on my blog:

---Basically Monkey is a program that runs on you emulator or Device(Mobile) and generates pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-level events.

---You can use the Monkey to stress-test applications that you are developing, in a random yet repeatable manner.

Description of Monkey Tool:

--The Monkey is a command-line tool that that you can run on any emulator instance or on a device. It sends a pseudo-random stream of user events into the system, which acts as a stress test on the application software you are developing.

Categories:

The Monkey includes a number of options, but they break down into four primary categories:
1.Basic configuration options, such as setting the number of events to attempt.
2.Operational constraints, such as restricting the test to a single package.
3.Event types and frequencies.
4.Debugging options.

****When the Monkey runs, it generates events and sends them to the system. It also watches the system under test and looks for three conditions, which it treats specially:

1.If you have constrained the Monkey to run in one or more specific packages, it watches for attempts to navigate to any other packages, and blocks them.
2.If your application crashes or receives any sort of unhandled exception, the Monkey will stop and report the error.
3.If your application generates an application not responding error, the Monkey will stop and report the error.

Depending on the verbosity level you have selected, you will also see reports on the progress of the Monkey and the events being generated.

Basic Use Steps for Monkey:

****You can launch the Monkey using a command line on your development machine or from a script. Because the Monkey runs in the emulator/device environment, you must launch it from a shell in that environment. You can do this by prefacing adb shell to each command, or by entering the shell and entering Monkey commands directly.

The basic syntax is:

$ adb shell monkey [options]

With no options specified, the Monkey will launch in a quiet (non-verbose) mode, and will send events to any (and all) packages installed on your target. Here is a more typical command line, which will launch your application and send 500 pseudo-random events to it:

$ adb shell monkey -p your.package.name -v 500

Command Options Reference

The below lists all options you can include on the Monkey command line.

1. --help : Prints a simple usage guide.

2. -v : Each -v on the command line will increment the verbosity level. Level 0 (the default) provides little information beyond startup notification, test completion, and final results. Level 1 provides more details about the test as it runs, such as individual events being sent to your activities. Level 2 provides more detailed setup information such as activities selected or not selected for testing.

3. -s : Seed value for pseudo-random number generator. If you re-run the Monkey with the same seed value, it will generate the same sequence of events.

4. --throttle : Inserts a fixed delay between events. You can use this option to slow down the Monkey. If not specified, there is no delay and the events are generated as rapidly as possible.

5. --wait-dbg : Stops the Monkey from executing until a debugger is attached to it.

etc., command for debugging, constraints, events & general commands refer android developer site for more information.

System administrators can use the Device Administration API to write an application that enforces remote/local device security policy enforcement. This section summarizes the steps involved in creating a device administration application.

Creating the manifest:
To use the Device Administration API, the application's manifest must include the following:

A subclass of DeviceAdminReceiver that includes the following:
--The BIND_DEVICE_ADMIN permission.
--The ability to respond to the ACTION_DEVICE_ADMIN_ENABLED intent, expressed in the manifest as an intent filter.

A declaration of security policies used in metadata.

Here is an snippet for the Device Administration sample manifest:

android:label="@string/activity_sample_device_admin">






android:label="@string/sample_device_admin"
android:description="@string/device_admin_description"
android:permission="android.permission.BIND_DEVICE_ADMIN">
android:resource="@xml/device_admin_sample" />






Note that:

The activity in the sample application is an Activity subclass called Controller. The syntax ".app.DeviceAdminSample$Controller" indicates that Controller is an inner class that is nested inside the DeviceAdminSample class. Note that an Activity does not need to be an inner class; it just is in this example.

The following attributes refer to string resources that for the sample application reside in ApiDemos/res/values/strings.xml. For more information about resources, see Application Resources.

android:label="@string/activity_sample_device_admin" refers to the user-readable label for the activity.

android:label="@string/sample_device_admin" refers to the user-readable label for the permission.

android:description="@string/sample_device_admin_description" refers to the user-readable description of the permission. A descripton is typically longer and more informative than a label.

android:permission="android.permission.BIND_DEVICE_ADMIN" is a permission that a DeviceAdminReceiver subclass must have, to ensure that only the system can interact with the receiver (no application can be granted this permission). This prevents other applications from abusing your device admin app.

android.app.action.DEVICE_ADMIN_ENABLED is the the primary action that a DeviceAdminReceiver subclass must handle to be allowed to manage a device. This is set to the receiver when the user enables the device admin app. Your code typically handles this in onEnabled(). To be supported, the receiver must also require the BIND_DEVICE_ADMIN permission so that other applications cannot abuse it.

When a user enables the device admin application, that gives the receiver permission to perform actions in response to the broadcast of particular system events. When suitable event arises, the application can impose a policy. For example, if the user attempts to set a new password that doesn't meet the policy requirements, the application can prompt the user to pick a different password that does meet the requirements.

android:resource="@xml/device_admin_sample" declares the security policies used in metadata. The metadata provides additional information specific to the device administrator, as parsed by the DeviceAdminInfo class. Here are the contents of device_admin_sample.xml:











Implementing the code

The Device Administration API includes the following classes:

DeviceAdminReceiver

Base class for implementing a device administration component. This class provides a convenience for interpreting the raw intent actions that are sent by the system. Your Device Administration application must include a DeviceAdminReceiver subclass.
DevicePolicyManager

A class for managing policies enforced on a device. Most clients of this class must have published a DeviceAdminReceiver that the user has currently enabled. The DevicePolicyManager manages policies for one or more DeviceAdminReceiver instances
DeviceAdminInfo

This class is used to specify metadata for a device administrator component.
These classes provide the foundation for a fully functional device administration application. The rest of this section describes how you use the DeviceAdminReceiver and DevicePolicyManager APIs to write a device admin application.

Subclassing DeviceAdminReceiver

To create a device admin application, you must subclass DeviceAdminReceiver. The DeviceAdminReceiver class consists of a series of callbacks that are triggered when particular events occur.

In its DeviceAdminReceiver subclass, the sample application simply displays a Toast notification in response to particular events. For example:

public class DeviceAdminSample extends DeviceAdminReceiver {

...
@Override
public void onEnabled(Context context, Intent intent) {
showToast(context, "Sample Device Admin: enabled");
}

@Override
public CharSequence onDisableRequested(Context context, Intent intent) {
return "This is an optional message to warn the user about disabling.";
}

@Override
public void onDisabled(Context context, Intent intent) {
showToast(context, "Sample Device Admin: disabled");
}

@Override
public void onPasswordChanged(Context context, Intent intent) {
showToast(context, "Sample Device Admin: pw changed");
}

void showToast(Context context, CharSequence msg) {
Toast.makeText(context, msg, Toast.LENGTH_SHORT).show();
}
...
}

Enabling the application

One of the major events a device admin application has to handle is the user enabling the application. The user must explicitly enable the application for the policies to be enforced. If the user chooses not to enable the application it will still be present on the device, but its policies will not be enforced, and the user will not get any of the application's benefits.

The process of enabling the application begins when the user performs an action that triggers the ACTION_ADD_DEVICE_ADMIN intent. In the sample application, this happens when the user clicks the Enable Admin button

for Reference's Android Device Administration code

Android 2.2(FROYO) introduces support for enterprise applications by offering the Android Device Administration API.

--Device Administration API provides device administration features at the system level.

--These APIs allow you to create security-aware applications that are useful in enterprise settings, in which IT professionals require rich control over employee devices.

***For example, the built-in Android Email application has leveraged the new APIs to improve Exchange support. Through the Email application, Exchange administrators can enforce password policies — including alphanumeric passwords or numeric PINs — across devices.

**Administrators can also remotely wipe (that is, restore factory defaults on) lost or stolen handsets.

**Exchange users can sync their email and calendar data.

--This above information is intended for developers who want to develop enterprise solutions for Android-powered devices. It discusses the various features provided by the Device Administration API to provide stronger security for employee devices that are powered by Android.


Device Administration API Overview :

Here are examples of the types of applications that might use the Device Administration API:

--Email clients.
--Security applications that do remote wipe.
--Device management services and applications.

How does it work?

You use the Device Administration API to write device admin applications that users install on their devices. The device admin application enforces the desired policies. Here's how it works:

A system administrator writes a device admin application that enforces remote/local device security policies. These policies could be hard-coded into the app, or the application could dynamically fetch policies from a third-party server.
The application is installed on users' devices. Android does not currently have an automated provisioning solution. Some of the ways a sysadmin might distribute the application to users are as follows:

Android Market.

Enabling non-market installation.

Distributing the application through other means, such as email or websites.

The system prompts the user to enable the device admin application. How and when this happens depends on how the application is implemented.
Once users enable the device admin application, they are subject to its policies. Complying with those policies typically confers benefits, such as access to sensitive systems and data.

If users do not enable the device admin app, it remains on the device, but in an inactive state. Users will not be subject to its policies, and they will conversely not get any of the application's benefits—for example, they may not be able to sync data.

If a user fails to comply with the policies (for example, if a user sets a password that violates the guidelines), it is up to the application to decide how to handle this. However, typically this will result in the user not being able to sync data.

If a device attempts to connect to a server that requires policies not supported in the Device Administration API, the connection will not be allowed. The Device Administration API does not currently allow partial provisioning. In other words, if a device (for example, a legacy device) does not support all of the stated policies, there is no way to allow the device to connect.

If a device contains multiple enabled admin applications, the strictest policy is enforced. There is no way to target a particular admin application.

To uninstall an existing device admin application, users need to first unregister the application as an administrator.

Policies
In an enterprise setting, it's often the case that employee devices must adhere to a strict set of policies that govern the use of the device. The Device Administration API supports the policies listed in Table 1. Note that the Device Administration API currently only supports passwords for screen lock:

Table 1. Policies supported by the Device Administration API.
Below explanation with Policy:Description
Password enabled Requires that devices ask for PIN or passwords.

Minimum password length : Set the required number of characters for the password. For example, you can require PIN or passwords to have at least six characters.

Alphanumeric password required : Requires that passwords have a combination of letters and numbers. They may include symbolic characters.

Maximum failed password attempts : Specifies how many times a user can enter the wrong password before the device wipes its data. The Device Administration API also allows administrators to remotely reset the device to factory defaults. This secures data in case the device is lost or stolen.

Maximum inactivity time lock : Sets the length of time since the user last touched the screen or pressed a button before the device locks the screen. When this happens, users need to enter their PIN or passwords again before they can use their devices and access data. The value can be between 1 and 60 minutes.


Other features

In addition to supporting the policies listed in the above table, the Device Administration API lets you do the following:

Prompt user to set a new password.
Lock device immediately.
Wipe the device's data (that is, restore the device to its factory defaults).

A Small Code Snippet to Convert String to Hex-Decimal

class StringtoHexConvertion {

public static void main(String args[]){

try{
String imputString = "000000000002";
byte[] bytes = imputString .getBytes("US-ASCII");

String str1 = "";
for(int i=0;i
System.out.println("byte value = "+ bytes[i]);
str1 = str1 + Integer.toHexString(bytes[i]);
}
System.out.println(" final String = "+ str1);
}
catch(Exception e){}
}
}

It might be helpful for some sceneries.

When you are porting Android, one important feature to check is SD card mount.

Needless to say this feature is needed for many functions to operate in correctly.

Couple of such examples are Bluetooth OPP and FTP profiles.

SD card boot up sequence is as follows :

mmc/sd driver recognises the inserted card, makes device object for every partitions

with unique combination of MAJOR:MINOR numbers and generate uevent.

uevent comes to user-level via kernel socket NETLINK_KOBJECT_UEVENT.

vold handles this uevent in uevent.c::handle_block_event().

vold reads boot sector to determine, how many partitions remains on storage.

If all partitions are found, vold will start "mount" procedure.

If mount is successfully finished, vold sends "volume_mounted:/sdcard" to

com.android.server.MountListener.

com.android.server.MountListener dispatches message to

com.android.server.MountService by handleEvent() method.

com.android.server.MountService provides to framework the logical interpretation of

vold actions such as update icon notification and forwards command from user to vold.

So, in our case MountService::notifyMediaMounted() will generate

Intent.ACTION_MEDIA_MOUNTED.

This intent will start com.android.providers.media.MediaScanner which will start

searching the media content and makes the database. Parallely

com.android.settings.deviceinfo.Memory will update memory status.

Some important files to remember for SD card boot sequence are mmc.c,

ums.c vold.c, voldmgr.c, uevent.c. These files will be useful in debugging SD card

boot up sequence. The configuration file of SD card is vold.conf and is present in

/etc.

I am interested to share a funny trick with time display in the taskbar....Let us see.....

Trick to show ur Name after time in taskbar....

Here is a trick to add up ur name in place of AM and PM beside time and make urself to feel proud among ur group of friends...
Its simple....

Start -> Control Panel -> Regional and Language option -> Customize (beside English US) -> Go to TIME tab -> change AM or PM symbols from AM or PM to ur name or the word u like to display-> Apply -> OK

How to Hide the drives(c:,d:,e:,a:...etc)
How to Hide the drives(c:,d:,e:,a:...etc)
This is a great trick you can play on your friends. To disable the display of local or networked drives when you click My Computer.




1.Go to start->run.Type regedit.Now go to:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Now in the right pane create a new DWORD item and name it NoDrives(it is case sensitive). Now modify it's value and set it to 3FFFFFF (Hexadecimal) .Now restart your computer. So, now when you click on My Computer, no drives will be shown(all gone...). To enable display of drives in My Computer, simply delete this DWORD item that you created.Again restart your computer.You can now see all the drives again. Magic.......

There are so many different ways to turn off your Windows XP computer, let's look at some of them:


1. The standard approach - click the Start Button with your mouse, then select the Turn Off menu and finally click the Turn Off icon on the Turn Off computer dialog. blink.gif

2. Press Ctrl+Esc key or the Win key and press u two times - the fastest approach.

3. Get the Shutdown utility from Download.com - it add the shut down shortcuts for you. Else create them yourself using approach 4.

4. Create a shutdown shortcut on your desktop. Right click on the desktop, choose New Shortcut and type shutdown -s -t 00 in the area where you are asked to specify the location of the program file. Now you can just double click this icon to turn off the computer. The best location would be your quick launch bar.

5. Press the Win key + R key to open the run window. Type shutdown -s -t 00. [s means shutdown while t means the duration after which you want to initiate the shutdown process].

If some open processes or application won't let you turn off, append a -f switch to force a shut down by closing all active processes.



6. Win+M to minimize all windows and then Alt+F4 to bring the Turn Off computer dialog.

7. Open Windows Task manager (by right clicking the Windows Task bar or Alt+Ctrl+Del) and choose Shut down from the menu. Useful when the Windows are not responding.

Trick to find the World Trace Center crash Logic.

1.Open NotePad, type World Trade Center crash flight number Q33N.

2. Increase your font size to 72.

3. change the font type to Wingdings.

and check the result.

How was the result?????

Location and maps-based applications are compelling for mobile device users.

You can build application by android.location packages and com.google.android.maps.MapView which is sub class of ViewGroup in Andorid.

Location Services :

1.Android gives your applications access to the location services supported by the device through the classes in the android.location package.

2.The central component of the location framework is the LocationManager system service, which provides APIs to determine location and bearing of the underlying device (if available).

You do not instantiate a LocationManager directly. Rather, you request an instance from the system by calling getSystemService(Context.LOCATION_SERVICE). The method returns a handle to a new LocationManager instance.

Once your application has a LocationManager, your application is able to do three things:

1.we can Query for the list of all LocationProviders for the last known user location.

2.Register/unregister for periodic updates of the user's current location from a location provider .

3.Register/unregister for a given Intent to be fired if the device comes within a given proximity (specified by radius in meters) of a given lat/long.

Next Post we will see this location services with Examples.

Among the most important things to master for a mobile application developer is network programming. Every mobile application I have developed has involved some kind of network communication. During the year I have learned a thing or two. Read on to get some tips & trick from me.

Quite often the server is developed alongside the client. This means that you as a client developer have to wait for those awfully slow server programmers. Not every server programmer is slow, but most likely you have to wait for some server functionality. In situations like these, it is handy to roll your own server. But as a client developer, you do not want to spend an massive amount of time to setup a server. In fact, if it takes longer than a couple of minutes most client developers give up. What you need is a server that is very quick and easy to setup. Also it needs to be simple, yet powerful. Many server programmers would recommend you setting up a Tomcat server. The advantage of using a Tomcat server is that it is very versatile. But I do not really like Tomcat. It is to advanced for me. Another solution is to use a Jetty server. This is simpler to setup than Tomcat, but yet rather powerful. It could be executed from Maven. As such is is convenient to use for automated tests. Maven takes cares most of the work, including starting and stopping your Jetty server. But there is a new and rising star, the Sinatra server. The Sinatra server is actually a Ruby library. You use Ruby to program the behavior of your server.   

A simple “Hello World” implementation for Sinatra looks like the one below (from the Sinatra Book).

require 'rubygems'
require 'sinatra'

get '/' do
  "Hello world, it's #{Time.now} at the server!"
end

The file is saved as a file with .rb extension, in our example we save it as “hello.rb”. Then you start your server as simple as this:

ruby hello.rb

You get a nice line saying that Sinatra has taken the stage and that your server uses port 4567. This could of course be changed, if you want to mimic another server without changing your code. It is very easy to extend your server functionality. Ruby is easy to learn and powerful for making your own server without any big hazzle. Take a look at the “Sinatra Book” if you want to master Sinatra.

Another common scenario is that you need to figure out what happens when you make a certain URL request, for example if you do a REST request. Before even writing a single of code, you could use the cURL command line tool. Its available on most platforms, like Unix, Linux, Mac OS, Windows etc. For a matter of discussion, let us assume that you want to check that you programmed your Sinatra web server correctly. Then you the following command:

curl http://127.0.0.1:4567/

The response should look like this:

Hello world, it's Mon Oct 25 20:44:19 +0200 2010 at the server!

So now you know how to implement your own simple server, as well as how to debug your server request using curl. But wait, there is even more tricks I want to share with you. I hope that you feel like reading a little bit more.

I think that XML is a rather misused technologies around. It is used for many things, ranging from describing your builds (Ant, Maven, etc) to describing serialized objects traveling through cyberspace (SOAP, REST etc). When SOAP was introduced, one main argument for XML is that it human readable. What? Have you ever seen a SOAP request that is human readable? If you are about to send and/or receive objects there are much more suitable technologies than XML. Especially when making a mobile client, where XML parsing could take to much time and memory, it is important to understand that there are good alternatives. One good old technology is ASN.1, that is hugely underestimated. It was designed for communicating data between different architectures and CPUs. It is fast even on a 8-bit CPU. The biggest drawback is that it is not widely supported and it requires an ASN.1 compiler. However you could implement your own ASN.1 encoder/decoder quite easy. Another solution that is easier to use, but building on the same principles as ASN.1 is the Hessian protocol. It is a binary web service protocol. The specification is originally designed by Caucho, who did the Resin web server. The specification is open and implemented in many languages, including .NET, Flash, Ruby, Python, Objective-C etc. I have primarily used it for Java ME, where only a subset is implemented. If you use it in Java ME, I would recommend considering using it to store object data in the record store. But now it is more relevant for me to use it on Android or iPhone. The Objective-C variant for iPhone is called HessianKit. It is open source and released under Apache 2.0 license. Thus it is not a viral open source license, which I think is great. I will not describe how to use it, since there already is a good article on the subject “HessianKit Released”. I hope that you will consider using Hessian if you are in the position to decide what web service protocol to use. If you feel the urge to use XML for your web services, you could use Burlap which is the XML version of Hessian. The communication is as simple as it could get using XML.

Another useful tool is a network analyzer. This is good for finding out what happens between the client and server. For example, if you want to take a look at the headers are many times auto generated. I have used Wireshark with great success. It would not say it is easy to use, but when you need to use it is priceless.

These are the tools that I think I use the most for network programming. What are your best tools when doing network programming?

In the Code Pollution series, I'll be writing about topics where a coding anti-pattern may work tactically for an individual application, but strategically will be bad for Android as a whole, just as pollution may benefit one firm while harming many others.

Many readers have, at one point in time or another, had a Windows PC that got overloaded with "cruft" and took forever and a day to boot up. Or, even if it would boot normally, it would be slow as a dog for the first minute or two after the desktop showed up.

While it would be fun and entertaining to bash Windows for this, in reality, it was probably third party applications causing a chunk of the problem. Lots of programs think that they just have to do something when the PC starts up, and too many of them bring the boot process to a halt.

The good news is that, for most people, Android is plenty stable enough not to require constant reboots. The bad news is that Android devices may still need to be rebooted from time to time, to process firmware upgrades, to recover from a dead battery, and the like.

One of the things the core Android team feared was too many applications asking to do something at boot time, via the BOOT_COMPLETED broadcast Intent, and causing the boot process to become horribly slow. That is why you need the REQUEST_BOOT_COMPLETED permission to receive BOOT_COMPLETED broadcasts -- the theory being that users who have had problems with slow boots might be less inclined to install other programs that demand boot-time access.

Still, though, it is up to us as developers to try to make the boot process as quick and painless as possible. Here are some ways you can help:

Do not request BOOT_COMPLETED broadcasts unnecessarily. For example, some developers may think it would be cool to steal three or four seconds of processing time at boot to do some sort of initialization, rather than have to deal with that work when their app is started. Tactically, this will improve responsiveness of that one application...at the cost of harming all applications on a reboot.
Do whatever you need to do quickly. If BOOT_COMPLETED is unavoidable, try to get in and out in few dozen milliseconds, not a few seconds.
Consider whether you can wait a bit. Many times, apps do not need to start up right at boot time, but rather sometime after a reboot. Unfortunately, there is no built-in way to ask for a "early, but not right away" broadcast...unless you set one up yourself. Consider whether you could use AlarmManager to do a one-shot alarm to fire your real boot-time code a minute or two after the boot is over. You only lose a minute, and it clears out the rest of the boot processing, and perhaps some initial user actions, before your code needs to join the fray.