Sunday, September 16, 2012

Multiple APK Support

Multiple APK support is a feature on Google Play that allows you to publish different APKs for your application that are each targeted to different device configurations. Each APK is a complete and independent version of your application, but they share the same application listing on Google Play and must share the same package name and be signed with the same release key. This feature is useful for cases in which your application cannot reach all desired devices with a single APK.

Android-powered devices may differ in several ways and it's important to the success of your application that you make it available to as many devices as possible. Android applications usually run on most compatible devices with a single APK, by supplying alternative resources for different configurations (for example, different layouts for different screen sizes) and the Android system selects the appropriate resources for the device at runtime. In a few cases, however, a single APK is unable to support all device configurations, because alternative resources make the APK file too big (greater than 50MB) or other technical challenges prevent a single APK from working on all devices.

Although we encourage you to develop and publish a single APK that supports as many device configurations as possible, doing so is sometimes not possible. To help you publish your application for as many devices as possible, Google Play allows you to publish multiple APKs under the same application listing. Google Play then supplies each APK to the appropriate devices based on configuration support you've declared in the manifest file of each APK.

By publishing your application with multiple APKs, you can:
  • Support different OpenGL texture compression formats with each APK.
  • Support different screen sizes and densities with each APK.
  • Support different platform versions with each APK.
  • Support different CPU architectures with each APK (such as for ARM, x86, and MIPS, when your app uses the Android NDK).
Currently, these are the only device characteristics that Google Play supports for publishing multiple APKs as the same application.

Note: You should generally use multiple APKs to support different device configurations only when your APK is too large (greater than 50MB) due to the alternative resources needed for different device configurations. Using a single APK to support different configurations is always the best practice, because it makes the path for application updates simple and clear for users (and also makes your life simpler by avoiding development and publishing complexity). Read the section below about Using a Single APK Instead to consider your options before publishing multiple APKs.

Publishing Concepts

Before you start publishing multiple APKs on Google Play, you must understand a few concepts regarding how the Google Play publisher site works.

Active APKs

Before you can publish your application (whether publishing one or multiple APKs), you must "activate" your APK(s) from the APK files tab. When you activate an APK, it moves into the list of Active APKs. This list allows you to preview which APK(s) you're about to publish.

If there are no errors, any "active" APK will be published to Google Play when you click the Publish button (if the application is unpublished) or when you click the Save button (if the application is already published).

Simple mode and advanced mode

The Google Play publisher site provides two modes for managing the APKs associated with your application: simple mode and advanced mode. You can switch between these by clicking the link at the top-right corner of the APK files tab.

Simple mode is the traditional way to publish an application, using one APK at a time. In simple mode, only one APK can be activated at a time. If you upload a new APK to update the application, clicking "Activate" on the new APK deactivates the currently active APK (you must then click Save to publish the new APK).

Advanced mode allows you to activate and publish multiple APKs that are each designed for a specific set of device configurations. However, there are several rules based on the manifest declarations in each APK that determine whether you're allowed to activate each APK along with others. When you activate an APK and it violates one of the rules, you will receive an error or warning message. If it's an error, you cannot publish until you resolve the problem; if it's a warning, you can publish the activated APKs, but there might be unintended consequences as to whether your application is available for different devices. These rules are discussed more below.

How Multiple APKs Work

The concept for using multiple APKs on Google Play is that you have just one entry in Google Play for your application, but different devices might download a different APK. This means that:
  • You maintain only one set of product details (app description, icons, screenshots, etc.). This also means you cannot charge a different price for different APKs.
  • All users see only one version of your application on Google Play, so they are not confused by different versions you may have published that are "for tablets" or "for phones."
  • All user reviews are applied to the same application listing, even though users on different devices may have different APKs.
  • If you publish different APKs for different versions of Android (for different API levels), then when a user's device receives a system update that qualifies them for a different APK you've published, Google Play updates the user's application to the APK designed for the higher version of Android. Any system data associated with the application is retained (the same as with normal application updates when using a single APK).
To publish multiple APKs for the same application, you must enable Advanced mode in your application's APK files tab (as discussed in the previous section). Once in advanced mode, you can upload, activate, then publish multiple APKs for the same application. The following sections describe more about how it works.

Supported filters

Which devices receive each APK is determined by Google Play filters that are specified by elements in the manifest file of each APK. However, Google Play allows you to publish multiple APKs only when each APK uses filters to support a variation of the following device characteristics:
  • OpenGL texture compression formats This is based on your manifest file's <supports-gl-texture> element(s).
    For example, when developing a game that uses OpenGL ES, you can provide one APK for devices that support ATI texture compression and a separate APK for devices that support PowerVR compression (among many others).

  • Screen size (and, optionally, screen density) This is based on your manifest file's <supports-screens> or <compatible-screens> element. You should never use both elements and you should use only <supports-screens> when possible.
    For example, you can provide one APK that supports small and normal size screens and another APK that supports large and xlarge screens.
Note: The Android system provides strong support for applications to support all screen configurations with a single APK. You should avoid creating multiple APKs to support different screens unless absolutely necessary and instead follow the guide to Supporting Multiple Screens so that your application is flexible and can adapt to all screen configurations with a single APK.

Caution: By default, all screen size attributes in the <supports-screens> element are "true" if you do not declare them otherwise. However, because the android:xlargeScreens attribute was added in Android 2.3 (API level 9), Google Play will assume that it is "false" if your application does not set either android:minSdkVersion or android:targetSdkVersion to "9" or higher.

Caution: You should not combine both <supports-screens> and <compatible-screens> elements in your manifest file. Using both increases the chances that you'll introduce an error due to conflicts between them. For help deciding which to use, read Distributing to Specific Screens. If you can't avoid using both, be aware that for any conflicts in agreement between a given size, "false" will win.
  • API level This is based on your manifest file's <uses-sdk> element. You can use both the android:minSdkVersion and android:maxSdkVersion attributes to specify support for different API levels.

    For example, you can publish your application with one APK that supports API levels 4 - 7 (Android 1.6 - 2.1)—using only APIs available since API level 4 or lower—and another APK that supports API levels 8 and above (Android 2.2+)—using APIs available since API level 8 or lower.

    • If you use this characteristic as the factor to distinguish multiple APKs, then the APK with a higher android:minSdkVersion value must have a higher android:versionCode value. This is also true if two APKs overlap their device support based on a different supported filter. This ensures that when a device receives a system update, Google Play can offer the user an update for your application (because updates are based on an increase in the app version code). This requirement is described further in the section below about Rules for multiple APKs.
    • You should avoid using android:maxSdkVersion in general, because as long as you've properly developed your application with public APIs, it is always compatible with future versions of Android. If you want to publish a different APK for higher API levels, you still do not need to specify the maximum version, because if the android:minSdkVersion is "4" in one APK and "8" in another, devices that support API level 8 or higher will always receive the second APK (because it's version code is higher, as per the previous note).

  • CPU architecture (ABI) This is based on the native libraries included in each APK (which are determined by the architectures you declare in the file) when using the Android NDK.
Other manifest elements that enable Google Play filters—but are not listed above—are still applied for each APK as usual. However, Google Play does not allow you to publish separate APKs based on variations of those device characteristics. Thus, you cannot publish multiple APKs if the above listed filters are the same for each APK (but the APKs differ based on other characteristics in the manifest or APK). For example, you cannot provide different APKs that differ purely on the <uses-configuration> characteristics.

Rules for multiple APKs

Before you enable advanced mode to publish multiple APKs for your application, you need to understand the following rules that define how publishing multiple APKs works:
  • All APKs you publish for the same application must have the same package name and be signed with the same certificate key.
  • Each APK must have a different version code, specified by the android:versionCode attribute.
  • Each APK must not exactly match the configuration support of another APK. That is, each APK must declare slightly different support for at least one of the supported Google Play filters (listed above).
    - Usually, you will differentiate your APKs based on a specific characteristic (such as the supported texture compression formats), and thus, each APK will declare support for different devices.
    - However, it's OK to publish multiple APKs that overlap their support slightly. When two APKs do overlap (they support some of the same device configurations), a device that falls within that overlap range will receive the APK with a higher version code (defined by android:versionCode).
  • You cannot activate a new APK that has a version code lower than that of the APK it's replacing. For example, say you have an active APK for screen sizes small - normal with version code 0400, then try to replace it with an APK for the same screen sizes with version code 0300. This raises an error, because it means users of the previous APK will not be able to update the application.
  • An APK that requires a higher API level must have a higher version code. This is true only when either: the APKs differ based only on the supported API levels (no other supported filters distinguish the APKs from each other) or when the APKs do use another supported filter, but there is an overlap between the APKs within that filter.
    - This is important because a user's device receives an application update from Google Play only if the version code for the APK on Google Play is higher than the version code of the APK currently on the device. This ensures that if a device receives a system update that then qualifies it to install the APK for higher API levels, the device receives an application update because the version code increases.

    Note: The size of the version code increase is irrelevant; it simply needs to be larger in the version that supports higher API levels.

    Here are some examples:
    • If an APK you've uploaded for API levels 4 and above (Android 1.6+) has a version code of 0400, then an APK for API levels 8 and above (Android 2.2+) must be 0401 or greater. In this case, the API level is the only supported filter used, so the version codes must increase in correlation with the API level support for each APK, so that users get an update when they receive a system update.
    • If you have one APK that's for API level 4 (and above) and small - large screens, and another APK for API level 8 (and above) and large - xlarge screens, then the version codes must increase in correlation with the API levels. In this case, the API level filter is used to distinguish each APK, but so is the screen size. Because the screen sizes overlap (both APKs support large screens), the version codes must still be in order. This ensures that a large screen device that receives a system update to API level 8 will receive an update for the second APK.
    • If you have one APK that's for API level 4 (and above) and small - normal screens, and another APK for API level 8 (and above) and large - xlarge screens, then the version codes do not need to increase in correlation with the API levels. Because there is no overlap within the screen size filter, there are no devices that could potentially move between these two APKs, so there's no need for the version codes to increase from the lower API level to the higher API level.
    • If you have one APK that's for API level 4 (and above) and ARMv7 CPUs, and another APK for API level 8 (and above) and ARMv5TE CPUs, then the version codes must increase in correlation with the API levels. In this case, the API level filter is used to distinguish each APK, but so is the CPU architecture. Because an APK with ARMv5TE libraries is compatible with devices that have an ARMv7 CPU, the APKs overlap on this characteristic. As such, the version code for the APK that supports API level 8 and above must be higher. This ensures that a device with an ARMv7 CPU that receives a system update to API level 8 will receive an update for the second APK that's designed for API level 8. However, because this kind of update results in the ARMv7 device using an APK that's not fully optimized for that device's CPU, you should provide an APK for both the ARMv5TE and the ARMv7 architecture at each API level in order to optimize the app performance on each CPU. Note: This applies only when comparing APKs with the ARMv5TE and ARMv7 libraries, and not when comparing other native libraries.
Failure to abide by the above rules results in an error on the Google Play publisher site when you activate your APKs—you will be unable to publish your application until you resolve the error.
There are other conflicts that might occur when you activate your APKs, but which will result in warnings rather than errors. Warnings can be caused by the following:
  • When you modify an APK to "shrink" the support for a device's characteristics and no other APKs support the devices that then fall outside the supported range. For example, if an APK currently supports small and normal size screens and you change it to support only small screens, then you have shrunk the pool of supported devices and some devices will no longer see your application on Google Play. You can resolve this by adding another APK that supports normal size screens so that all previously-supported devices are still supported.
  • When there are "overlaps" between two or more APKs. For example, if an APK supports screen sizes small, normal, and large, while another APK supports sizes large and xlarge, there is an overlap, because both APKs support large screens. If you do not resolve this, then devices that qualify for both APKs (large screen devices in the example) will receive whichever APK has the highest version code

    Note: If you're creating separate APKs for different CPU architectures, be aware that an APK for ARMv5TE will overlap with an APK for ARMv7. That is, an APK designed for ARMv5TE is compatible with an ARMv7 device, but the reverse is not true (an APK with only the ARMv7 libraries is not compatible with an ARMv5TE device).
When such conflicts occur, you will see a warning message, but you can still publish your application.

Creating Multiple APKs

Once you decide to publish multiple APKs, you probably need to create separate Android projects for each APK you intend to publish so that you can appropriately develop them separately. You can do this by simply duplicating your existing project and give it a new name. (Alternatively, you might use a build system that can output different resources—such as textures—based on the build configuration.)

Tip: One way to avoid duplicating large portions of your application code is to use a library project. A library project holds shared code and resources, which you can include in your actual application projects.
When creating multiple projects for the same application, it's a good practice to identify each one with a name that indicates the device restrictions to be placed on the APK, so you can easily identify them. For example, "HelloWorld_8" might be a good name for an application designed for API level 8 and above.

Note: All APKs you publish for the same application must have the same package name and be signed with the same certificate key. Be sure you also understand each of the Rules for multiple APKs.

Assigning version codes

Each APK for the same application must have a unique version code, specified by the android:versionCode attribute. You must be careful about assigning version codes when publishing multiple APKs, because they must each be different, but in some cases, must or should be defined in a specific order, based on the configurations that each APK supports.

Ordering version codes

An APK that requires a higher API level must usually have a higher version code. For example, if you create two APKs to support different API levels, the APK for the higher API levels must have the higher version code. This ensures that if a device receives a system update that then qualifies it to install the APK for higher API levels, the user receives a notification to update the app. For more information about how this requirement applies, see the section above about Rules for multiple APKs.

You should also consider how the order of version codes might affect which APK your users receive either due to overlap between coverage of different APKs or future changes you might make to your APKs.

For example, if you have different APKs based on screen size, such as one for small - normal and one for large - xlarge, but foresee a time when you will change the APKs to be one for small and one for normal - xlarge, then you should make the version code for the large - xlarge APK be higher. That way, a normal size device will receive the appropriate update when you make the change, because the version code increases from the existing APK to the new APK that now supports the device.

Also, when creating multiple APKs that differ based on support for different OpenGL texture compression formats, be aware that many devices support multiple formats. Because a device receives the APK with the highest version code when there is an overlap in coverage between two APKs, you should order the version codes among your APKs so that the APK with the preferred compression format has the highest version code. For example, you might want to perform separate builds for your app using PVRTC, ATITC, and ETC1 compression formats. If you prefer these formats in this exact order, then the APK that uses PVRTC should have the highest version code, the APK that uses ATITC has a lower version code, and the version with ETC1 has the lowest. Thus, if a device supports both PVRTC and ETC1, it receives the APK with PVRTC, because it has the highest version code.

Using a version code scheme

In order to allow different APKs to update their version codes independent of others (for example, when you fix a bug in only one APK, so don't need to update all APKs), you should use a scheme for your version codes that provides sufficient room between each APK so that you can increase the code in one without requiring an increase in others. You should also include your actual version name in the code (that is, the user visible version assigned to android:versionName), so that it's easy for you to associate the version code and version name.

Note: When you increase the version code for an APK, Google Play will prompt users of the previous version to update the application. Thus, to avoid unnecessary updates, you should not increase the version code for APKs that do not actually include changes.

We suggest using a version code with at least 7 digits: integers that represent the supported configurations are in the higher order bits, and the version name (from android:versionName) is in the lower order bits. For example, when the application version name is 3.1.0, version codes for an API level 4 APK and an API level 11 APK would be something like 0400310 and 1100310, respectively. The first two digits are reserved for the API Level (4 and 11, respectively), the middle two digits are for either screen sizes or GL texture formats (not used in these examples), and the last three digits are for the application's version name (3.1.0). Figure 1 shows two examples that split based on both the platform version (API Level) and screen size.

Figure 1. A suggested scheme for your version codes, using the first two digits for the API Level, the second and third digits for the minimum and maximum screen size (1 - 4 indicating each of the four sizes) or to denote the texture formats and the last three digits for the app version.

This scheme for version codes is just a suggestion for how you should establish a pattern that is scalable as your application evolves. In particular, this scheme doesn't demonstrate a solution for identifying different texture compression formats. One option might be to define your own table that specifies a different integer to each of the different compression formats your application supports (for example, 1 might correspond to ETC1 and 2 is ATITC, and so on).

You can use any scheme you want, but you should carefully consider how future versions of your application will need to increase their version codes and how devices can receive updates when either the device configuration changes (for example, due to a system update) or when you modify the configuration support for one or several of the APKs.

Using a Single APK Instead

Creating multiple APKs for your application is not the normal procedure for publishing an application on Google Play. In most cases, you should be able to publish your application to most users with a single APK and we encourage that you do so. When you encounter a situation in which using a single APK becomes difficult, you should carefully consider all your options before deciding to publish multiple APKs.
First of all, there are a few key benefits to developing a single APK that supports all devices:
  • Publishing and managing your application is easier. With only one APK to worry about at any given time, you're less likely to become confused by which APK is what. You also don't have to keep track of multiple version codes for each APK—by using only one APK, you can simply increase the version code with each release and be done.
  • You need to manage only a single code base. Although you can use a library project to share code between multiple Android projects, it's still likely that you'll reproduce some code across each project and this could become difficult to manage, especially when resolving bugs.
  • Your application can adapt to device configuration changes. By creating a single APK that contains all the resources for each device configuration, your application can adapt to configuration changes that occur at runtime. For example, if the user docks or otherwise connects a handset device to a larger screen, there's a chance that this will invoke a system configuration change to support the larger screen. If you include all resources for different screen configurations in the same APK, then your application will load alternative resources and optimize the user experience for the new interface.
  • App restore across devices just works. If a user has enabled data backup on his or her current device and then buys a new device that has a different configuration, then when the user's apps are automatically restored during setup, the user receives your application and it runs using the resources optimized for that device. For example, on a new tablet, the user receives your application and it runs with your tablet-optimized resources. This restore process does not work across different APKs, because each APK can potentially have different permissions that the user has not agreed to, so Google Play may not restore the application at all. (If you use multiple APKs, the user receives either the exact same APK if it's compatible or nothing at all and must manually download your application to get the APK designed for the new device.)
The following sections describe some of the other options you should use to support multiple device configurations before deciding to publish multiple APKs.

Supporting multiple GL textures

To support multiple types of GL textures with a single APK, your application should query the GL texture formats supported on the device and then use the appropriate resources or download them from a web server. For example, in order to keep the size of your APK small, you can query the device's support for different GL texture formats when the application starts for the first time and then download only the textures you need for that device.

For maximum performance and compatibility, your application should use ETC1 textures wherever it doesn't impact the visual quality. However, because ETC1 cannot deal with images that have drastic chroma changes, such as line art and (most) text, and doesn't support alpha, it may not the best format for all textures.

With a single APK, you should try to use ETC1 textures and uncompressed textures whenever reasonable, and consider the use of PVRTC, ATITC, or DXTC as a last resort when ETC1 does not suffice.

Here's an example query for supported texture compression formats from inside a GLSurfaceView.Renderer:

public void onSurfaceChanged(GL10 gl, int w, int h) {
    String extensions = gl.glGetString(GL10.GL_EXTENSIONS);
    Log.d("ExampleActivity", extensions);
This returns a string that lists each of the supported compression formats.

Supporting multiple screens

Unless your APK file exceeds the Google Play size limit of 50MB, supporting multiple screens should always be done with a single APK. Since Android 1.6, the Android system manages most of the work required for your application to run successfully on a variety of screen sizes and densities.

To further optimize your application for different screen sizes and densities, you should provide alternative resources such as bitmap drawables at different resolutions and different layout designs for different screen sizes.

For more information about how to support multiple screens with a single APK, read Supporting Multiple Screens.

Additionally, you should consider using a support library from the Compatibility Package so that you can add Fragments to your activity designs when running on larger screens such as tablets.

Supporting multiple API levels

If you want to support as many versions of the Android platform as possible, you should use only APIs available in the lowest reasonable version. For example, your application may not require APIs newer than Android 2.1 (API Level 7), which makes an application available to over 95% of Android-powered devices (as indicated by the Platform Versions dashboard).

By using a support library from the Compatibility Package, you can also use APIs from some of the latest versions (such as Android 3.0) while still supporting versions as low as Android 1.6. The support library includes APIs for Fragments, Loaders, and more. Using the fragment APIs is particularly valuable so that you can optimize your user interface for large devices such as tablets.

Alternatively, if you want to use some APIs that are available only in newer versions of Android (which your application can still function without), then you should consider using reflection. By using reflection, you can check whether the current device supports certain APIs. If the APIs are not available, your application can gracefully disable and hide the feature.

Another way to use new APIs only when running on a version that supports them is to check the API level of the current device. That is, you can query the value of SDK_INT and create different code paths depending on the API level supported by the device. For example:

if (android.os.Build.VERSION.SDK_INT >= 11) {
    // Use APIs supported by API level 11 (Android 3.0) and up
} else {
    // Do something different to support older versions

Supporting multiple CPU architectures

When using the Android NDK, you can create a single APK that supports multiple CPU architectures by declaring each of the desired architectures with the APP_ABI variable in the file.

For example, here's an file that declares support for three different CPU architectures:

APP_ABI := armeabi armeabi-v7a mips
APP_PLATFORM := android-9

Friday, July 13, 2012

Android - English ABC Quiz

English ABC Quiz is an English learning application which can help you to learn English level A, B, and C.
English ABC Quiz is an English Quiz application which can help you to make the English test and review your performance.Creative Power Vietnam (CPViet) develops this application FREE for people can learn English easily.


The features of this FREE English Learning application is:
- Study Mode: Student can choose each question and try to answer it... until the student can choose the correct answer. Then the explanation about the correct answer will be displayed, so that student can understand why this is the correct answer.
- Test Mode: Student can choose some categories or all categories to randomize the number of questions which is specified by student. And student also can specify the time of the test. After the test, student can see the graph to show the performance of student.
- Resume Last Test: Allow student to resume the last test that student paused.
- Review Test Performance: Allow student to review the performance to improve himself/herself.




Because this version is the first version. So there are many limited things here:
- The category is "Grammar" only. The categories should be: Grammar, Vocabulary, ...
- The explanations of answers are not there now.


We are on the progress of improving this application day by day. So these limited things will be added very soon.


How you can help us to improve this application!
- Send us report if you see any incorrect question & answer.
- Contribute the list of quiz to us by sending email directly to us.
- Invite your friends and recommend this English Learning application to your friends. Share it to facebook, google plus, twitter and so on...

Thursday, July 12, 2012

Google Cloud Messaging (GCM)

Google Cloud Messaging (GCM) is a free service that helps developers send data from servers to their Android applications on Android devices. This could be a lightweight message telling the Android application that there is new data to be fetched from the server (for instance, a movie uploaded by a friend), or it could be a message containing up to 4kb of payload data (so apps like instant messaging can consume the message directly).

GCM replaces beta version of C2DM (Android Cloud to Device Messaging). Please note that C2DM is now deprecated, and that we are no longer allowing new manual C2DM sign-ups. Developers who do not switch to GCM, can continue to use C2DM with no quota increase.

To use GCM, you need to obtain a long-lived token (Simple API key). If you are an existing C2DM user, you can use your C2DM token instead. To get a Simple API key, follow these steps:
  1. In the main Google API console, select ‘API Access’.
  2. Click ‘Create new Server key’.
To learn more about GCM and get started, please visit Google Cloud Messaging developers guide.

GCM statistics

Developers will be able to sign-up for GCM for both Play and non-Play apps. However, GCM stats will be available for only published Google Play apps.
To be able to see GCM stats in your Google Play Developer Console, associate the GCM Simple API Key or C2DM token with your Android application. Here’s how:
  1. Select the application where you use GCM.
  2. Go to the 'Product Details tab.
  3. Scroll down to the GCM section of the page.
  4. Click the 'Edit' button against a GCM sender ID box and paste your GCM API key or C2DM token into the popup and click ‘Link’. This will link the corresponding GCM Sender ID with the app.
  5. Once done, don't forget to the save the app details by clicking on the Save button at the top of the page.
You can add up to 3 GCM sender IDs. To edit/remove an already linked GCM Sender ID simply click on‘Edit’ and enter a new GCM API key or C2DM token or leave the field empty to remove the previously linked GCM Sender ID. You can also revoke your key or a token through Google APIs console. After the key or token is revoked, you can continue to see GCM stats on the ‘Statistics’ page in your Google Play Developer Console until you remove the GCM sender ID too.

Thursday, April 19, 2012

Android Ebook: Nhị Thập Tứ Hiếu (The Twenty-four Paragons of Filial Respect) [Vietnamese]

Google Play Link:

Xin giới thiệu 24 Mẫu Gương Hiếu Thảo của người xưa, do Lý Văn Phức (1785-1849) lược dịch theo thể thơ song thất lục bát.

Xin gửi đến các gia đình, các bạn trẻ, đặc biệt các bạn thiếu nhi loạt phim Nhị Thập Tứ Hiếu “hoạt hình”, lấy từ Youtube.

Bộ Tranh 24 bức của Họa sĩ Trần Thiếu Mai.

1- Ngu Thuấn : hiếu cảm động trời
2- Văn Đế : tự mình nếm thuốc
3- Tăng Tử : mẹ cắn ngón tay, tim con đau xót
4- Mẫn Tử Khiên : hiếu với mẹ kế
5- Trọng Do (Tử Lộ) : gánh gạo nuôi cha mẹ
6. Diễm Tử: sữa hươu phụng dưỡng mẹ cha
7- Lão Lai Tử : đùa giỡn cho cha mẹ vui
8- Đồng Vĩnh : bán thân chôn cha
9- Quách Cự : chôn con nuôi mẹ
10- Khương Thi : suối chảy cá nhảy
11- Thái Thuận : nhặt dâu cho mẹ
12- Đinh Lan : Khắc tượng thờ cha mẹ
13- Lục Tích : Giấu quýt cho mẹ
14- Giang Cách : làm thuê nuôi mẹ
15- Hoàng Hương : quạt gối ấm chăn
16- Vương Thôi : nghe sấm khóc mộ
17- Ngô Mãnh : chịu muỗi thay cha mẹ
18- Vương Tường : nằm băng chờ cá chép
19- Dương Hương : giết hổ cứu cha
20- Mạnh Tông : khóc đến khi măng mọc
21- Du Kiềm Lâu : nếm phân lo âu
22- Đường Thị : cho mẹ chồng bú sữa
23- Châu Thọ Xương : bỏ chức quan tìm mẹ
24- Hoàng Đình Kiên : tự tay rửa bô …

Cây có cội, nước có nguồn, làm người ai cũng có Tổ tiên, Ông bà, Cha mẹ. Người Việt nam xem đây là tình cảm thiêng liêng cao quý nhất, trong bất cứ hoàn cảnh nào, thời điểm nào, và không giờ phút nào lại không nghĩ đến công ơn sinh thành dưỡng dục cù lao của Cha Mẹ :

"Công Cha như núi Thái Sơn,
Nghĩa Mẹ như nước trong nguồn chảy ra".

Thursday, April 12, 2012

Team vs Group: implications for leaders

Team vs Group? This article highlights differences between team leader and group leader roles. We include a study of leadership issues in transition from group to team.

When setting up either, it is worth considering the role the individuals are to play. Ask yourself whether organizational goals will be best achieved by a team or a group.

Where does responsibility lie?

The first team vs group issue to consider is where the focus of overall responsibility for performance si located.

One of the key differences between the team leadership and group leadership is: "Who is responsible for delivering the total outcome of the individuals' efforts?

Individual responsibilities

In a group each member is responsible for only their own individual contributions. He or she achieves outcomes or makes their contribution to the organization in (relative) isolation.

Individuals need not have any concern about what other members of the group achieve.
Group members are likely to develop an individual relationship with the group leader. Relationships between group leader and different individuals may vary considerably in their tone and quality.

One individual may need to be managed much more forcefully than another, for example. Other group members may not be aware of this ... and if they were, it is likely to be of little consequence to them.

Within a group there is not the interconnectedness and shared responsibility you see between team members. Each member of a group can say ‘I did my best, it is not my fault that others did not pull their weight.'

Collective responsibility

In a team, such as a sports team, all the players know they are interconnected. They understand that it is the quality of their collective performance that determines the final result: success or failure.

In an effective team, each member knows that they are dependent on the other members for achieving the final result. Which means team members have an interest in helping each other where they can.

In software design projects - for example - this seems to lead to more pro-active fault-finding. That is, team members recognize their collective responsibility for the outcomes they achieve.

As a direct consequence of this the team leader will tend to relate to the team as a whole. The team leader role may become more nominal as the team gels and sets its own challenges.

In some instances, this may be too challenging for some managers or team leaders. In a positive situation, the leadership role and decision-making will adapt and accommodate. Decisions will be made differently. They will be based on their impact on the dynamics of the web of relationships between group members.

If forceful treatment is meted out to one member of a team, it is likely to have consequences for the team as a whole. This is especially the case if such treatment is perceived as unwarranted or unfair.

Positive or negative, the consequences of team leadership decisions may be magnified by the relationships between team members

Team vs Group: Who owns the results?

Another way of making the distinction between team leadership and group leadership is by considering who owns or is responsible for the results.

In a team it is the team leader and the team members who have a shared responsibility for the outcomes meeting target. So in a sports team, all the players and the coach share the responsibility for what happens on the pitch.

In a group - for example a group of sales people - it is usual that each member is only responsible for her own performance. The leader takes overall responsibility for the aggregated results of each individual meeting the overall sales department target.

Team vs Group: How the behaviour of members differs

Members of a team appreciate that their own (individual) success is determined by the collective performance of everyone. They have a much greater motivation to help and support those team members whose performance may fall behind ... for whatever reason.

Perhaps an under-achiever is new and needs a buddy or a mentor to help them get established. Maybe there are environmental reasons for poor results. Other members are likely to find ways to help them raise their game.

For a group member however, his status and reward depend only upon his individual performance. Generally speaking, if he gives time or resources to another group member there is no benefit in it for him.

If this effort takes his attention away from his own performance he might even suffer as a result.

Team vs Group: How the behaviour of leaders differs

How can a group leader create team results?

Experience demonstrates that teams are usually more effective than groups. If the leader of a group want to improve performance overall, he needs to find a way of the group taking shared ownership for the results.

It is likely that a shift from individual responsibility to shared responsibility
can only be achieved if the pay and reward system has a significant element that is dependent on the overall outcome.

The knowledge, skills and attitudes of the leader may also need to shift significantly to be effective in this new environment.

For example, the leader may need to share all of the individuals' results with the group. The group  has a right to know how others are performing if their pay depends upon it.

This may be a challenging experience for a leader who has avoided the potential emotional stress that can be caused by this level of openness. They may have found it a lot safer to keep the individual results to themselves in the past.

Team vs Group: the emergence of self-managing teams

As groups begin to share responsibility for the overall performance, then the whole subject of self managing teams becomes a topic for exploration.

In our experience with a high performance work system in a manufacturing setting, it became clear that individuals were demanding a stronger voice: a group moved into a more democratic phase ... and began to behave much more like a team.

Individuals' rewards depended on the the performance of the group as a whole. Team members started to demand a much bigger say in those areas that have been traditionally the responsibility of the leader.

For example:
  • Recruitment – team members wanted a say in who was allowed to join the team
  • Discipline and Firing – team members were much less tolerant of members who broke the rules or where not up to the job
  • Training and Development – as new skills were added to the team capability, members were keen to choose who should get them
  • Promotion – equally team members wanted their input into who would be promoted 


Team vs Group: leadership roles emerge from the specific circumstances

Team leaders need to show their mettle at this time! Potential gains are great, but insecure managers may squander opportunities:
  • appropriate monitoring and checks and balances - yes!
  • micro-management and (dare we say it?) control-freakery - no!

Such changes may lead to qualitative shifts in performance and achievement, but can seem unpredictable and maverick in their very nature.

This kind of transition along the team vs group continuum can create a situation in which team leadership / group leadership decisions become difficult.

A management response may be to parachute in a respected technician to manage the group. The idea is that technical expertise brings respect and therefore confers the right to manage - not necessarily.

This team knows it's starting to fly ... and that feels good!

Technical leadership and other aspects may be split between two people. This can begin to multiply communication and co-ordination difficulties

Situations like this are made for leadership development coaching. As coaches, this looks to us like nothing is wrong, everything is right ... or at least has great potential.

How does coaching support managers or leaders who may be confronting a situation they've never seen before? And who may be feeling disempowered and vulnerable because of this kind of role-reversal?

Wednesday, March 28, 2012

Android - Avoiding Memory Leaks

Android applications are, at least on the T-Mobile G1, limited to 16 MB of heap. It's both a lot of memory for a phone and yet very little for what some developers want to achieve. Even if you do not plan on using all of this memory, you should use as little as possible to let other applications run without getting them killed. The more applications Android can keep in memory, the faster it will be for the user to switch between his apps. As part of my job, I ran into memory leaks issues in Android applications and they are most of the time due to the same mistake: keeping a long-lived reference to a Context.

On Android, a Context is used for many operations but mostly to load and access resources. This is why all the widgets receive a Context parameter in their constructor. In a regular Android application, you usually have two kinds of Context, Activity and Application. It's usually the first one that the developer passes to classes and methods that need a Context:

protected void onCreate(Bundle state) {

TextView label = new TextView(this);
.setText("Leaks are bad");


This means that views have a reference to the entire activity and therefore to anything your activity is holding onto; usually the entire View hierarchy and all its resources. Therefore, if you leak the Context ("leak" meaning you keep a reference to it thus preventing the GC from collecting it), you leak a lot of memory. Leaking an entire activity can be really easy if you're not careful.

When the screen orientation changes the system will, by default, destroy the current activity and create a new one while preserving its state. In doing so, Android will reload the application's UI from the resources. Now imagine you wrote an application with a large bitmap that you don't want to load on every rotation. The easiest way to keep it around and not having to reload it on every rotation is to keep in a static field:

private static Drawable sBackground;

protected void onCreate(Bundle state) {

TextView label = new TextView(this);
.setText("Leaks are bad");

if (sBackground == null) {
= getDrawable(R.drawable.large_bitmap);


This code is very fast and also very wrong; it leaks the first activity created upon the first screen orientation change. When a Drawable is attached to a view, the view is set as a callback on the drawable. In the code snippet above, this means the drawable has a reference to the TextView which itself has a reference to the activity (the Context) which in turns has references to pretty much anything (depending on your code.)

This example is one of the simplest cases of leaking the Context and you can see how we worked around it in the Home screen's source code (look for the unbindDrawables() method) by setting the stored drawables' callbacks to null when the activity is destroyed. Interestingly enough, there are cases where you can create a chain of leaked contexts, and they are bad. They make you run out of memory rather quickly.

There are two easy ways to avoid context-related memory leaks. The most obvious one is to avoid escaping the context outside of its own scope. The example above showed the case of a static reference but inner classes and their implicit reference to the outer class can be equally dangerous. The second solution is to use the Application context. This context will live as long as your application is alive and does not depend on the activities life cycle. If you plan on keeping long-lived objects that need a context, remember the application object. You can obtain it easily by calling Context.getApplicationContext() or Activity.getApplication().

In summary, to avoid context-related memory leaks, remember the following:

  • Do not keep long-lived references to a context-activity (a reference to an activity should have the same life cycle as the activity itself)
  • Try using the context-application instead of a context-activity
  • Avoid non-static inner classes in an activity if you don't control their life cycle, use a static inner class and make a weak reference to the activity inside. The solution to this issue is to use a static inner class with a WeakReference to the outer class, as done in ViewRoot and its W inner class for instance
  • A garbage collector is not an insurance against memory leaks