Wednesday, April 27, 2011

Android 3.0 Honeycomb Features

Everyone seems to be excited about the latest version of Android 3.0, honeycomb which is designed from the ground up for devices with larger screen sizes, particularly for tablets like Motorola Xoom. Developer has also spent lot of time refining the user experience in Honeycomb to develop this brand new, truly virtual and holographic user interface theme. What is more interesting about Android 3.0 Honeycomb is the features and technology introduced for users and developers.If you are still unaware about Android 3.0 Honeycomb then have a look at the video below:



Android developers has released many exciting features for users and developers. You can check out these 12 best Android 3.0 Honeycomb features, which are expected to fix many of the issues concerning Android.
1. Optimized Tablet UI - You will find this very interesting as the general layout of UI has extravagant space on the home screen for icons and widgets. With this well optimized Table UI you are free to accommodate many required things just on home screen.
2. Redesigned widgets – With the updated set of Android 3.0 UI widgets, it becomes easier for developers to add new content to their existing applications. The new UI widgets concentrate on bigger screens such as tablets and including the new holographic UI theme. Don’t miss out on the new widgets comprising a 3D stack, search box, a date/time picker, number picker, calendar, popup menu, and others.
3. Elegant Notification Bar – You will find the notification bar at the bottom of the screen so as to offer quick access to notifications. Back, Home, and Recent Apps are the three buttons you will find on the System Bar. In the present System Bar there is a new “lights out Mode” which can be dimmed for full-screen viewing, for example videos.
4. Customizable Home Screen – Home screen is more or less the similar to previous version on Android where you can add widgets, apps and shortcuts. However, when you are allowed to swipe between five different screens along with an awesome new 3D look for the home screen is definitely fun and this is what the new version offers!
5. Action-bar – Action bar is placed at the top of the screen where users can access contextual options, navigation, widgets, or content.  This one is always present when anyapplication is in use, however its content, theme, and other properties are handled by theapplication and not by the system.
6. Redesigned Keyboard and Improved Copy/Paste – To make typing fast and accurate, Android 3.0 has a soft keyboard on larger screen size. These reshaped, repositioned and new keys (Tab key) are certainly welcomed by users that offer richer and more effective text input. Copy/paste now becomes simpler for users by just selecting a word by press-hold and then moving the selection area as needed by dragging a set of bounding arrows to new positions.
7. Browser Enhancements – Browser enhancements include tabbed web pages, form auto-fill, bookmark syncing with Google Chrome, and private browsing. Other updated areas would include Browser, Contacts, Email and Camera that can be used more efficiently with your larger screen tablet.
8. Visual multi-tasking – Users have had the benefit of multitasking in Android for now and latest version is even better. When you launch apps to handle multitask, you can make use of Recent Apps list in the System Bar to see and switch between one application to another. The System Bar also has the snapshot list that state when you viewed it last.
9. Multiselect, Clipboard, and Drag-and-drop – This will be really convenient for developers when handling various items in lists or grids, where developer can offer a new multiselect mode to choose multiple item for one action. The new clipboard will let developers copy any type of data into and out of their applications. Further, neat drag-and-drop will help to easily manage and organize files.
10. New Connectivity options – New APIs for Bluetooth A2DP and HSP let applications offer audio streaming and headset control. Support for Bluetooth insecure socket connection lets applications connect to simple devices that may not have a user interface.
11. Support for Multi-core Processors – Android 3.0 is the first version of the platform designed to run on either single or multi-core processor architectures. Many other changes in the Dalvik VM, Bionic library, and elsewhere add support for symmetric multiprocessing in multicore environments. This will do nothing but help all the applications including those that are single-threaded.
12. Hardware acceleration for 2D graphics – Android honeycomb offers a new hardware-accelerated OpenGL renderer, which offers a performance boost to many common graphics operations for applications running in the Android framework. When the renderer is enabled, most operations in Canvas, Paint, Xfermode, ColorFilter, Shader, and Camera are accelerated.
Android 3.0 honeycomb of course has many other interesting features like support forvideo chat using Google Talk and it also gives access to over 100,000 apps, however above given were really interesting. In case, you got some more to share on Android 3.0, then we would like hear that!

Sunday, April 17, 2011

Custom Component

To Create Your own custom component you have to override the View Class or any other subclass of View Class.

Saturday, April 16, 2011

Style in android layout

A style is a collection of properties that specify the look and format for a View or window. A style can specify properties such as height, padding, font color, font size, background color, and much more. A style is defined in an XML resource that is separate from the XML that specifies the layout.
Styles in Android share a similar philosophy to cascading stylesheets in web design—they allow you to separate the design from the content.
For example, by using a style, you can take this layout XML:
<TextView
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:textColor="#00FF00"
    android:typeface="monospace"
    android:text="@string/hello" />
And turn it into this:
<TextView
    style="@style/CodeFont"
    android:text="@string/hello" />
All of the attributes related to style have been removed from the layout XML and put into a style definition called CodeFont, which is then applied with the style attribute. You'll see the definition for this style in the following section.
A theme is a style applied to an entire Activity or application, rather than an individual View (as in the example above). When a style is applied as a theme, every View in the Activity or application will apply each style property that it supports. For example, you can apply the same CodeFont style as a theme for an Activity and then all text inside that Activity will have green monospace font.

Defining Styles

To create a set of styles, save an XML file in the res/values/ directory of your project. The name of the XML file is arbitrary, but it must use the .xml extension and be saved in the res/values/ folder.
The root node of the XML file must be <resources>.
For each style you want to create, add a <style> element to the file with a name that uniquely identifies the style (this attribute is required). Then add an <item> element for each property of that style, with a name that declares the style property and a value to go with it (this attribute is required). The value for the <item> can be a keyword string, a hex color, a reference to another resource type, or other value depending on the style property. Here's an example file with a single style:
<?xml version="1.0" encoding="utf-8"?>
<resources>
    <style name="CodeFont" parent="@android:style/TextAppearance.Medium">
        <item name="android:layout_width">fill_parent</item>
        <item name="android:layout_height">wrap_content</item>
        <item name="android:textColor">#00FF00</item>
        <item name="android:typeface">monospace</item>
    </style>
</resources>
Each child of the <resources> element is converted into an application resource object at compile-time, which can be referenced by the value in the <style> element's name attribute. This example style can be referenced from an XML layout as @style/CodeFont (as demonstrated in the introduction above).
The parent attribute in the <style> element is optional and specifies the resource ID of another style from which this style should inherit properties. You can then override the inherited style properties if you want to.
Remember, a style that you want to use as an Activity or application theme is defined in XML exactly the same as a style for a View. A style such as the one defined above can be applied as a style for a single View or as a theme for an entire Activity or application. How to apply a style for a single View or as an application theme is discussed later.

Inheritance

The parent attribute in the <style> element lets you specify a style from which your style should inherit properties. You can use this to inherit properties from an existing style and then define only the properties that you want to change or add. You can inherit from styles that you've created yourself or from styles that are built into the platform. (See Using Platform Styles and Themes, below, for information about inheriting from styles defined by the Android platform.) For example, you can inherit the Android platform's default text appearance and then modify it:
    <style name="GreenText" parent="@android:style/TextAppearance">
        <item name="android:textColor">#00FF00</item>
    </style>
If you want to inherit from styles that you've defined yourself, you do not have to use the parent attribute. Instead, just prefix the name of the style you want to inherit to the name of your new style, separated by a period. For example, to create a new style that inherits the CodeFont style defined above, but make the color red, you can author the new style like this:
    <style name="CodeFont.Red">
        <item name="android:textColor">#FF0000</item>
    </style>
Notice that there is no parent attribute in the <style> tag, but because the name attribute begins with the CodeFont style name (which is a style that you have created), this style inherits all style properties from that style. This style then overrides the android:textColor property to make the text red. You can reference this new style as @style/CodeFont.Red.
You can continue inheriting like this as many times as you'd like, by chaining names with periods. For example, you can extend CodeFont.Red to be bigger, with:
    <style name="CodeFont.Red.Big">
        <item name="android:textSize">30sp</item>
    </style>
This inherits from both CodeFont and CodeFont.Red styles, then adds the android:textSize property.
Note: This technique for inheritance by chaining together names only works for styles defined by your own resources. You can't inherit Android built-in styles this way. To reference a built-in style, such as TextAppearance, you must use the parent attribute.

Style Properties

Now that you understand how a style is defined, you need to learn what kind of style properties—defined by the <item> element—are available. You're probably familiar with some already, such as layout_width and textColor. Of course, there are many more style properties you can use.
The best place to find properties that apply to a specific View is the corresponding class reference, which lists all of the supported XML attributes. For example, all of the attributes listed in the table of TextView XML attributes can be used in a style definition for a TextView element (or one of its subclasses). One of the attributes listed in the reference is android:inputType, so where you might normally place the android:inputType attribute in an <EditText> element, like this:
<EditText
    android:inputType="number"
    ... />
You can instead create a style for the EditText element that includes this property:
<style name="Numbers">
  <item name="android:inputType">number</item>
  ...</style>
So your XML for the layout can now implement this style:
<EditText
    style="@style/Numbers"
    ... />
This simple example may look like more work, but when you add more style properties and factor-in the ability to re-use the style in various places, the pay-off can be huge.
For a reference of all available style properties, see the R.attr reference. Keep in mind that all View objects don't accept all the same style attributes, so you should normally refer to the specific View class for supported style properties. However, if you apply a style to a View that does not support all of the style properties, the View will apply only those properties that are supported and simply ignore the others.
Some style properties, however, are not supported by any View element and can only be applied as a theme. These style properties apply to the entire window and not to any type of View. For example, style properties for a theme can hide the application title, hide the status bar, or change the window's background. These kind of style properties do not belong to any View object. To discover these theme-only style properties, look at the R.attr reference for attributes that begin with window. For instance, windowNoTitle and windowBackground are style properties that are effective only when the style is applied as a theme to an Activity or application. See the next section for information about applying a style as a theme.
Note: Don't forget to prefix the property names in each <item> element with the android: namespace. For example: <item name="android:inputType">.

Applying Styles and Themes to the UI

There are two ways to set a style:
  • To an individual View, by adding the style attribute to a View element in the XML for your layout.
  • Or, to an entire Activity or application, by adding the android:theme attribute to the <activity> or <application> element in the Android manifest.
When you apply a style to a single View in the layout, the properties defined by the style are applied only to that View. If a style is applied to a ViewGroup, the child View elements will not inherit the style properties—only the element to which you directly apply the style will apply its properties. However, you can apply a style so that it applies to all View elements—by applying the style as a theme.
To apply a style definition as a theme, you must apply the style to an Activity or application in the Android manifest. When you do so, every View within the Activity or application will apply each property that it supports. For example, if you apply the CodeFont style from the previous examples to an Activity, then all View elements that support the text style properties will apply them. Any View that does not support the properties will ignore them. If a View supports only some of the properties, then it will apply only those properties.

Apply a style to a View

Here's how to set a style for a View in the XML layout:
<TextView
    style="@style/CodeFont"
    android:text="@string/hello" />
Now this TextView will be styled as defined by the style named CodeFont. (See the sample above, in Defining Styles.)
Note: The style attribute does not use the android: namespace prefix.

Apply a theme to an Activity or application

To set a theme for all the activities of your application, open the AndroidManifest.xml file and edit the <application> tag to include the android:theme attribute with the style name. For example:
<application android:theme="@style/CustomTheme">
If you want a theme applied to just one Activity in your application, then add the android:theme attribute to the <activity> tag instead.
Just as Android provides other built-in resources, there are many pre-defined themes that you can use, to avoid writing them yourself. For example, you can use the Dialog theme and make your Activity appear like a dialog box:
<activity android:theme="@android:style/Theme.Dialog">
Or if you want the background to be transparent, use the Translucent theme:
<activity android:theme="@android:style/Theme.Translucent">
If you like a theme, but want to tweak it, just add the theme as the parent of your custom theme. For example, you can modify the traditional dialog theme to use your own background image like this:
<style name="CustomDialogTheme" parent="@android:style/Theme.Dialog">
    <item name="android:windowBackground">@drawable/custom_dialog_background</item>
</style>
Now use CustomDialogTheme instead of Theme.Dialog inside the Android Manifest:
<activity android:theme="@style/CustomDialogTheme">

Using Platform Styles and Themes

The Android platform provides a large collection of styles and themes that you can use in your applications. You can find a reference of all available styles in the R.style class. To use the styles listed here, replace all underscores in the style name with a period. For example, you can apply the Theme_NoTitleBar theme with "@android:style/Theme.NoTitleBar".
The R.style reference, however, is not well documented and does not thoroughly describe the styles, so viewing the actual source code for these styles and themes will give you a better understanding of what style properties each one provides. For a better reference to the Android styles and themes, see the following source code:
These files will help you learn through example. For instance, in the Android themes source code, you'll find a declaration for <style name="Theme.Dialog">. In this definition, you'll see all of the properties that are used to style dialogs that are used by the Android framework.
For more information about the syntax used to create styles in XML, see Available Resource Types: Style and Themes.
For a reference of available style attributes that you can use to define a style or theme (e.g., "windowBackground" or "textAppearance"), see R.attr or the respective View class for which you are creating a style.

Monday, April 11, 2011

SOAP

SOAP is a simple XML-based protocol to let applications exchange information over HTTP.
Or more simply: SOAP is a protocol for accessing a Web Service.

What You Should Already Know

Before you study SOAP you should have a basic understanding of XML and XML Namespaces.


What is SOAP?

  • SOAP stands for Simple Object Access Protocol
  • SOAP is a communication protocol
  • SOAP is for communication between applications
  • SOAP is a format for sending messages
  • SOAP communicates via Internet
  • SOAP is platform independent
  • SOAP is language independent
  • SOAP is based on XML
  • SOAP is simple and extensible
  • SOAP allows you to get around firewalls
  • SOAP is a W3C recommendation

Why SOAP?

It is important for application development to allow Internet communication between programs.
Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic.
A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this.
SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.

SOAP is a W3C Recommendation

Building Web Services the REST Way

What is REST?

REST is a term coined by Roy Fielding in his Ph.D. dissertation [1] to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.

Why is it called Representational State Transfer?

The Web is comprised of resources. A resource is any item of interest. For example, the Boeing Aircraft Corp may define a 747 resource. Clients may access that resource with this URL:
http://www.boeing.com/aircraft/747
representation of the resource is returned (e.g., Boeing747.html). The representation places the client application in a state. The result of the client traversing a hyperlink in Boeing747.html is another resource is accessed. The new representation places the client application into yet another state. Thus, the client application changes (transfers) state with each resource representation --> Representational State Transfer!
Here is Roy Fielding's explanation of the meaning of Representational State Transfer:
"Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use."

Motivation for REST

The motivation for REST was to capture the characteristics of the Web which made the Web successful. Subsequently these characteristics are being used to guide the evolution of the Web.

REST - An Architectural Style, Not a Standard

REST is not a standard. You will not see the W3C putting out a REST specification. You will not see IBM or Microsoft or Sun selling a REST developer's toolkit. Why? Because REST is just an architectural style. You can't bottle up that style. You can only understand it, and design your Web services in that style. (Analogous to the client-server architectural style. There is no client-server standard.)
While REST is not a standard, it does use standards:
  • HTTP
  • URL
  • XML/HTML/GIF/JPEG/etc (Resource Representations)
  • text/xml, text/html, image/gif, image/jpeg, etc (MIME Types)

The Classic REST System

The Web is a REST system! Many of those Web services that you have been using these many years - book-ordering services, search services, online dictionary services, etc - are REST-based Web services. Alas, you have been using REST, building REST services and you didn't even know it.
REST is concerned with the "big picture" of the Web. It does not deal with implementation details (e.g., using Java servlets or CGI to implement a Web service). So let's look at an example of creating a Web service from the REST "big picture" perspective.

Parts Depot Web Services

Parts Depot, Inc (fictitious company) has deployed some web services to enable its customers to:
  • get a list of parts
  • get detailed information about a particular part
  • submit a Purchase Order (PO)
Let's consider how each of these services are implemented in a RESTful fashion.

Get Parts List

The web service makes available a URL to a parts list resource. For example, a client would use this URL to get the parts list:
http://www.parts-depot.com/parts
Note that "how" the web service generates the parts list is completely transparent to the client. All the client knows is that if he/she submits the above URL then a document containing the list of parts is returned. Since the implementation is transparent to clients, Parts Depot is free to modify the underlying implementation of this resource without impacting clients. This is loose coupling.Here's the document that the client receives:

<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com" 
         xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>
      <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>
      <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>
      <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>
[Assume that through content negotiation the service determined that the client wants the representation as XML (for machine-to-machine processing).] Note that the parts list has links to get detailed info about each part. This is a key feature of REST. The client transfers from one state to the next by examining and choosing from among the alternative URLs in the response document.

Get Detailed Part Data

The web service makes available a URL to each part resource. Example, here's how a client requests part 00345:
http://www.parts-depot.com/parts/00345
Here's the document that the client receives:
<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>This part is used within the frap assembly</Description>
      <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
</p:Part>
Again observe how this data is linked to still more data - the specification for this part may be found by traversing the hyperlink. Each response document allows the client to drill down to get more detailed information.

Submit PO

The web service makes available a URL to submit a PO. The client creates a PO instance document which conforms to the PO schema that Parts Depot has designed (and publicized in a WSDL document). The client submits PO.xml as the payload of an HTTP POST.

The PO service responds to the HTTP POST with a URL to the submitted PO. Thus, the client can retrieve the PO any time thereafter (to update/edit it). The PO has become a piece of information which is shared between the client and the server. The shared information (PO) is given an address (URL) by the server and is exposed as a Web service.

Logical URLs versus Physical URLs

A resource is a conceptual entity. A representation is a concrete manifestation of the resource. This URL:
http://www.parts-depot.com/parts/00345
is a logical URL, not a physical URL. Thus, there doesn't need to be, for example, a static HTML page for each part. In fact, if there were a million parts then a million static HTML pages would not be a very attractive design.
[Implementation detail: Parts Depot could implement the service that gets detailed data about a particular part by employing a Java Servlet which parses the string after the host name, uses the part number to query the parts database, formulate the query results as XML, and then return the XML as the payload of the HTTP response.]
As a matter of style URLs should not reveal the implementation technique used. You need to be free to change your implementation without impacting clients or having misleading URLs.

REST Web Services Characteristics

Here are the characteristics of REST:
  • Client-Server: a pull-based interaction style: consuming components pull representations.
  • Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.
  • Cache: to improve network efficiency responses must be capable of being labeled as cacheable or non-cacheable.
  • Uniform interface: all resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE).
  • Named resources - the system is comprised of resources which are named using a URL.
  • Interconnected resource representations - the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.
  • Layered components - intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.

Principles of REST Web Service Design

1. The key to creating Web Services in a REST network (i.e., the Web) is to identify all of the conceptual entities that you wish to expose as services. Above we saw some examples of resources: parts list, detailed part data, purchase order.2. Create a URL to each resource. The resources should be nouns, not verbs. For example, do not use this:

http://www.parts-depot.com/parts/getPart?id=00345
Note the verb, getPart. Instead, use a noun:
http://www.parts-depot.com/parts/00345
3. Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.
4. All resources accessible via HTTP GET should be side-effect free. That is, the resource should just return a representation of the resource. Invoking the resource should not result in modifying the resource.
5. No man/woman is an island. Likewise, no representation should be an island. In other words, put hyperlinks within resource representations to enable clients to drill down for more information, and/or to obtain related information.
6. Design to reveal data gradually. Don't reveal everything in a single response document. Provide hyperlinks to obtain more details.
7. Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or Schematron). For those services that require a POST or PUT to it, also provide a schema to specify the format of the response.
8. Describe how your services are to be invoked using either a WSDL document, or simply an HTML document.

Summary

This article described REST as an architectural style. In fact, it's the architectural style of the Web. REST describes what makes the Web work well. Adhering to the REST principles will make your services work well in the context of the Web.
In a future article I will write about the evolution of the Web using the REST principles.

Friday, April 8, 2011

Window

Abstract base class for a top-level window look and behavior policy. An instance of this class should be used as the top-level view added to the window manager. It provides standard UI policies such as a background, title area, default key processing, etc.
The only existing implementation of this abstract class is android.policy.PhoneWindow, which you should instantiate when needing a Window. Eventually that class will be refactored and a factory method added for creating Window instances without knowing about a particular implementation.

Summary

Nested Classes
interfaceWindow.CallbackAPI from a Window back to its caller. 
Constants
intDEFAULT_FEATURESThe default features enabled
intFEATURE_ACTION_BARFlag for enabling the Action Bar.
intFEATURE_ACTION_BAR_OVERLAYFlag for requesting an Action Bar that overlays window content.
intFEATURE_ACTION_MODE_OVERLAYFlag for specifying the behavior of action modes when an Action Bar is not present.
intFEATURE_CONTEXT_MENUFlag for the context menu.
intFEATURE_CUSTOM_TITLEFlag for custom title.
intFEATURE_INDETERMINATE_PROGRESSFlag for indeterminate progress
intFEATURE_LEFT_ICONFlag for having an icon on the left side of the title bar
intFEATURE_NO_TITLEFlag for the "no title" feature, turning off the title at the top of the screen.
intFEATURE_OPTIONS_PANELFlag for the "options panel" feature.
intFEATURE_PROGRESSFlag for the progress indicator feature
intFEATURE_RIGHT_ICONFlag for having an icon on the right side of the title bar
intID_ANDROID_CONTENTThe ID that the main layout in the XML layout file should have.
intPROGRESS_ENDEnding value for the (primary) progress
intPROGRESS_INDETERMINATE_OFFFlag for setting the progress bar's indeterminate mode off
intPROGRESS_INDETERMINATE_ONFlag for setting the progress bar's indeterminate mode on
intPROGRESS_SECONDARY_ENDHighest possible value for the secondary progress
intPROGRESS_SECONDARY_STARTLowest possible value for the secondary progress
intPROGRESS_STARTStarting value for the (primary) progress
intPROGRESS_VISIBILITY_OFFFlag for setting the progress bar's visibility to GONE
intPROGRESS_VISIBILITY_ONFlag for setting the progress bar's visibility to VISIBLE
Public Constructors
Window(Context context)
Public Methods
abstract voidaddContentView(View view, ViewGroup.LayoutParams params)
Variation on setContentView(View, android.view.ViewGroup.LayoutParams) to add an additional content view to the screen.
voidaddFlags(int flags)
Convenience function to set the flag bits as specified in flags, as per setFlags(int, int).
voidclearFlags(int flags)
Convenience function to clear the flag bits as specified in flags, as per setFlags(int, int).
abstract voidcloseAllPanels()
abstract voidclosePanel(int featureId)
ViewfindViewById(int id)
Finds a view that was identified by the id attribute from the XML that was processed in onCreate(Bundle).
final WindowManager.LayoutParamsgetAttributes()
Retrieve the current window attributes associated with this panel.
final Window.CallbackgetCallback()
Return the current Callback interface for this window.
final WindowgetContainer()
Return the container for this Window.
final ContextgetContext()
Return the Context this window policy is running in, for retrieving resources and other information.
abstract ViewgetCurrentFocus()
Return the view in this Window that currently has focus, or null if there are none.
abstract ViewgetDecorView()
Retrieve the top-level window decor view (containing the standard window frame/decorations and the client's content inside of that), which can be added as a window to the window manager.
abstract LayoutInflatergetLayoutInflater()
Quick access to the LayoutInflater instance that this Window retrieved from its Context.
abstract intgetVolumeControlStream()
WindowManagergetWindowManager()
Return the window manager allowing this Window to display its own windows.
final TypedArraygetWindowStyle()
Return the Window attributes from this window's theme.
final booleanhasChildren()
booleanhasFeature(int feature)
Query for the availability of a certain feature.
abstract voidinvalidatePanelMenu(int featureId)
final booleanisActive()
abstract booleanisFloating()
Return whether this window is being displayed with a floating style (based on the windowIsFloatingattribute in the style/theme).
abstract booleanisShortcutKey(int keyCode, KeyEvent event)
Is a keypress one of the defined shortcut keys for this window.
final voidmakeActive()
abstract voidonConfigurationChanged(Configuration newConfig)
Should be called when the configuration is changed.
abstract voidopenPanel(int featureId, KeyEvent event)
abstract ViewpeekDecorView()
Retrieve the current decor view, but only if it has already been created; otherwise returns null.
abstract booleanperformContextMenuIdentifierAction(int id, int flags)
abstract booleanperformPanelIdentifierAction(int featureId, int id, int flags)
abstract booleanperformPanelShortcut(int featureId, int keyCode, KeyEvent event, int flags)
booleanrequestFeature(int featureId)
Enable extended screen features.
abstract voidrestoreHierarchyState(Bundle savedInstanceState)
abstract BundlesaveHierarchyState()
voidsetAttributes(WindowManager.LayoutParams a)
Specify custom window attributes.
abstract voidsetBackgroundDrawable(Drawable drawable)
Change the background of this window to a custom Drawable.
voidsetBackgroundDrawableResource(int resid)
Change the background of this window to a Drawable resource.
voidsetCallback(Window.Callback callback)
Set the Callback interface for this window, used to intercept key events and other dynamic operations in the window.
abstract voidsetChildDrawable(int featureId, Drawable drawable)
abstract voidsetChildInt(int featureId, int value)
voidsetContainer(Window container)
Set the container for this window.
abstract voidsetContentView(View view)
Convenience for setContentView(View, android.view.ViewGroup.LayoutParams) set the screen content to an explicit view.
abstract voidsetContentView(int layoutResID)
Convenience for setContentView(View, android.view.ViewGroup.LayoutParams) to set the screen content from a layout resource.
abstract voidsetContentView(View view, ViewGroup.LayoutParams params)
Set the screen content to an explicit view.
abstract voidsetFeatureDrawable(int featureId, Drawable drawable)
Set an explicit Drawable value for feature of this window.
abstract voidsetFeatureDrawableAlpha(int featureId, int alpha)
Set a custom alpha value for the given drawale feature, controlling how much the background is visible through it.
abstract voidsetFeatureDrawableResource(int featureId, int resId)
Set the value for a drawable feature of this window, from a resource identifier.
abstract voidsetFeatureDrawableUri(int featureId, Uri uri)
Set the value for a drawable feature of this window, from a URI.
abstract voidsetFeatureInt(int featureId, int value)
Set the integer value for a feature.
voidsetFlags(int flags, int mask)
Set the flags of the window, as per the WindowManager.LayoutParams flags.
voidsetFormat(int format)
Set the format of window, as per the PixelFormat types.
voidsetGravity(int gravity)
Set the gravity of the window, as per the Gravity constants.
voidsetLayout(int width, int height)
Set the width and height layout parameters of the window.
voidsetSoftInputMode(int mode)
Specify an explicit soft input mode to use for the window, as perWindowManager.LayoutParams.softInputMode.
abstract voidsetTitle(CharSequence title)
abstract voidsetTitleColor(int textColor)
voidsetType(int type)
Set the type of the window, as per the WindowManager.LayoutParams types.
abstract voidsetVolumeControlStream(int streamType)
voidsetWindowAnimations(int resId)
Specify custom animations to use for the window, as perWindowManager.LayoutParams.windowAnimations.
voidsetWindowManager(WindowManager wm, IBinder appToken, String appName, boolean hardwareAccelerated)
Set the window manager for use by this Window to, for example, display panels.
voidsetWindowManager(WindowManager wm, IBinder appToken, String appName)
Set the window manager for use by this Window to, for example, display panels.
abstract booleansuperDispatchKeyEvent(KeyEvent event)
Used by custom windows, such as Dialog, to pass the key press event further down the view hierarchy.
abstract booleansuperDispatchKeyShortcutEvent(KeyEvent event)
Used by custom windows, such as Dialog, to pass the key shortcut press event further down the view hierarchy.
abstract booleansuperDispatchTouchEvent(MotionEvent event)
Used by custom windows, such as Dialog, to pass the touch screen event further down the view hierarchy.
abstract booleansuperDispatchTrackballEvent(MotionEvent event)
Used by custom windows, such as Dialog, to pass the trackball event further down the view hierarchy.
abstract voidtakeInputQueue(InputQueue.Callback callback)
Take ownership of this window's InputQueue.
abstract voidtakeKeyEvents(boolean get)
Request that key events come to this activity.
abstract voidtakeSurface(SurfaceHolder.Callback2 callback)
Take ownership of this window's surface.
abstract voidtogglePanel(int featureId, KeyEvent event)
Protected Methods
final intgetFeatures()
Return the feature bits that are enabled.
final intgetForcedWindowFlags()
Return the window flags that have been explicitly set by the client, so will not be modified bygetDecorView().
final intgetLocalFeatures()
Return the feature bits that are being implemented by this Window.
final booleanhasSoftInputMode()
Has the app specified their own soft input mode?
abstract voidonActive()
voidsetDefaultWindowFormat(int format)
Set the default format of window, as per the PixelFormat types.
[Expand]
Inherited Methods
 From class java.lang.Object