Monthly Archives: September 2014

extern in “C”

1. Declaration can be done any number of times but definition only once.
2. “extern” keyword is used to extend the visibility of variables/functions().
3. Since functions are visible through out the program by default. The use of extern is not needed in function declaration/definition. Its use is redundant.
4. When extern is used with a variable, it’s only declared not defined.
5. As an exception, when an extern variable is declared with initialization, it is taken as definition of the variable as well.


Manipulating the browser history

and ) and provides functionality global to the document (such as obtaining the page’s URL and creating new elements in the document).” style=”margin: 0px; padding: 0px; border: 0px; color: rgb(0, 149, 221); text-decoration: none;”>document only if you modify only the hash.

  • You don’t have to change the URL if you don’t want to. In contrast, setting window.location = "#foo"; only creates a new history entry if the current hash isn’t #foo.
  • You can associate arbitrary data with your new history entry. With the hash-based approach, you need to encode all of the relevant data into a short string.

Note that pushState() never causes a hashchange event to be fired, even if the new URL differs from the old URL only in its hash.

The replaceState() method

history.replaceState() operates exactly like history.pushState() except that replaceState() modifies the current history entry instead of creating a new one.

replaceState() is particularly useful when you want to update the state object or URL of the current history entry in response to some user action.

Note: In Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1) through Gecko 5.0 (Firefox 5.0 / Thunderbird 5.0 / SeaMonkey 2.2), the passed object is serialized using JSON. Starting in Gecko 6.0 (Firefox 6.0 / Thunderbird 6.0 / SeaMonkey 2.3), the object is serialized using the structured clone algorithm. This allows a wider variety of objects to be safely passed.

The popstate event

A popstate event is dispatched to the window every time the active history entry changes. If the history entry being activated was created by a call topushState or affected by a call to replaceState, the popstate event’s state property contains a copy of the history entry’s state object.

See window.onpopstate for sample usage.

Reading the current state

When your page loads, it might have a non-null state object.  This can happen, for example, if the page sets a state object (using pushState() orreplaceState()) and then the user restarts her browser.  When your page reloads, the page will receive an onload event, but no popstate event.  However, if you read the history.state property, you’ll get back the state object you would have gotten if a popstate had fired.

You can read the state of the current history entry without waiting for a popstate event using the history.state property like this:

var currentState = history.state;


For a complete example of AJAX web site, please see: Ajax navigation example.

Browser compatibility

Feature Chrome Firefox (Gecko) Internet Explorer Opera Safari
replaceState, pushState 5 4.0 (2.0) 10 11.50 5.0
history.state 18 4.0 (2.0) 10 11.50 6.0

Android Low-Level System Architecture


Porting Android to Devices

Android provides you with the freedom to implement your own device specifications and the drivers to support them. The hardware abstraction layer (HAL) gives you a standard way to create software hooks in between the Android platform stack and your hardware. In addition, the Android operating system is open-sourced to help you through your device’s bringup.

To ensure that your devices maintain a high level of quality and offers a consistent experience for your users, they must must also pass the tests in the compatibility test suite (CTS). CTS ensures that anyone building a device meets a quality standard that ensures apps run reliabaly well and gives users a good experience. For more information, see the Compatibility section.

Android Low-Level System Architecture

Before you begin porting Android to your hardware, it is important to have an understanding of how Android works at a high level. Because your drivers and HAL code interact with many layers of Android code, this understanding can help you find your way through the many layers of code that are available to you through the AOSP (Android Open Source Project) source tree. The following diagram shows a system level view of how Android works:

Figure 1. Android System Architecture

Application framework

This is the level that most application developers concern themselves with. You should be aware of the APIs available to developers as many of them map 1:1 to the underlying HAL interfaces and can provide information as to how to implement your driver.

Binder IPC

The Binder Inter-Process Communication mechanism allows the application framework to cross process boundaries and call into the Android system services code. This basically allows high level framework APIs to interact with Android’s system services. At the application framework level, all of this communication is hidden from the developer and things appear to “just work.”

System services

Most of the functionality exposed through the application framework APIs must communicate with some sort of system service to access the underlying hardware. Services are divided into modular components with focused functionality such as the Window Manager, Search Service, or Notification Manager. System services are grouped into two buckets: system and media. The system services include things such as the Window or Notification Manager. The media services include all the services involved in playing and recording media.

Hardware abstraction layer (HAL)

The HAL serves as a standard interface that allows the Android system to call into the device driver layer while being agnostic about the lower-level implementations of your drivers and hardware. You must implement the corresponding HAL (and driver) for the particular piece of hardware that your product provides. Android does not mandate a standard interaction between your HAL implementation and your device drivers, so you have free reign to do what is best for your situation. However, you must abide by the contract defined in each hardware-specific HAL interface for the Android system to be able to correctly interact with your hardware. HAL implementations are typically built into shared library modules (.so files).

Linux Kernel

For the most part, developing your device drivers is the same as developing a typical Linux device driver. Android uses a specialized version of the Linux kernel with a few special additions such as wakelocks, a memory management system that is more agressive in preserving memory, the Binder IPC driver, and other features that are important for a mobile embedded platform like Android. These additions have less to do with driver development than with the system’s functionality. You can use any version of the kernel that you want as long as it supports the required features, such as the binder driver. However, we recommend using the latest version of the Android kernel. For the latest Android kernel, see Building Kernels.