From 3ba792c7f4646f6a33fdc2b6d9b8831ecf479e2c Mon Sep 17 00:00:00 2001 From: Roman Nurik Date: Thu, 26 Jan 2012 11:56:31 -0800 Subject: docs: Update designing-navigation training class to link to Android Design Change-Id: I1cdda032f31798f9a32b7bec583dcfaa6eafb8c2 --- .../design-navigation/ancestral-temporal.jd | 8 ++++- .../design-navigation/descendant-lateral.jd | 42 +++++++++++++++++++--- docs/html/training/design-navigation/index.jd | 2 +- .../training/design-navigation/multiple-sizes.jd | 11 ++++-- .../html/training/design-navigation/wireframing.jd | 2 +- 5 files changed, 56 insertions(+), 9 deletions(-) diff --git a/docs/html/training/design-navigation/ancestral-temporal.jd b/docs/html/training/design-navigation/ancestral-temporal.jd index 02e43e150bd1..c0b1aef738e9 100644 --- a/docs/html/training/design-navigation/ancestral-temporal.jd +++ b/docs/html/training/design-navigation/ancestral-temporal.jd @@ -21,6 +21,7 @@ next.link=wireframing.html

You should also read

@@ -30,6 +31,11 @@ next.link=wireframing.html

Now that users can navigate deep into the application's screen hierarchy, we need to provide a method for navigating up the hierarchy, to parent and ancestor screens. Additionally, we should ensure that temporal navigation via the BACK button is respected to respect Android conventions.

+
+

Back/Up Navigation Design

+

For design guidelines, read Android Design's Navigation pattern guide.

+

Support Temporal Navigation: Back

@@ -49,7 +55,7 @@ next.link=wireframing.html

Provide Ancestral Navigation: Up and Home

-

Before Android 3.0, the most common form of ancestral navigation was the Home metaphor. This was generally implemented as a Home item accessible via the device's MENU button, or a Home button at the top-left of the screen, usually as a component of the Action Bar. Upon selecting Home, the user would be taken to the screen at the top of the screen hierarchy, generally known as the application's home screen.

+

Before Android 3.0, the most common form of ancestral navigation was the Home metaphor. This was generally implemented as a Home item accessible via the device's MENU button, or a Home button at the top-left of the screen, usually as a component of the Action Bar (pattern docs at Android Design). Upon selecting Home, the user would be taken to the screen at the top of the screen hierarchy, generally known as the application's home screen.

Providing direct access to the application's home screen can give the user a sense of comfort and security. Regardless of where they are in the application, if they get lost in the app, they can select Home to arrive back at the familiar home screen.

diff --git a/docs/html/training/design-navigation/descendant-lateral.jd b/docs/html/training/design-navigation/descendant-lateral.jd index ebfd913fe848..0064bd495c2d 100644 --- a/docs/html/training/design-navigation/descendant-lateral.jd +++ b/docs/html/training/design-navigation/descendant-lateral.jd @@ -18,9 +18,18 @@ next.link=ancestral-temporal.html
  • Buttons and Simple Targets
  • Lists, Grids, Carousels, and Stacks
  • Tabs
    • -
  • Horizontal Paging
    • +
  • Horizontal Paging (Swipe Views)
    • +

    You should also read

    + + @@ -48,6 +57,12 @@ next.link=ancestral-temporal.html

    Buttons and Simple Targets

    +
    +

    Button Design

    +

    For design guidelines, read Android Design's Buttons guide.

    +
    +

    For section-related screens, offering touchable and keyboard-focusable targets in the parent is generally the most straightforward and familiar kind of touch-based navigation interface. Examples of such targets include buttons, fixed-size list views, or text links, although the latter is not an ideal UI (user interface) element for touch-based navigation. Upon selecting one of these targets, the child screen is opened, replacing the current context (screen) entirely. Buttons and other simple targets are rarely used for representing items in a collection.

    @@ -64,6 +79,13 @@ next.link=ancestral-temporal.html

    Lists, Grids, Carousels, and Stacks

    +
    +

    List and Grid List Design

    +

    For design guidelines, read Android Design's Lists and Grid Lists guides.

    +
    +

    For collection-related screens, and especially for textual information, vertically scrolling lists are often the most straightforward and familiar kind of interface. For more visual or media-rich content items such as photos or videos, vertically scrolling grids of items, horizontally scrolling lists (sometimes referred to as carousels), or stacks (sometimes referred to as cards) can be used instead. These UI elements are generally best used for presenting item collections or large sets of child screens (for example, a list of stories or a list of 10 or more news topics), rather than a small set of unrelated, sibling child screens.

    @@ -80,6 +102,12 @@ next.link=ancestral-temporal.html

    Tabs

    +
    +

    Tab Design

    +

    For design guidelines, read Android Design's Tabs guide.

    +
    +

    Using tabs is a very popular solution for lateral navigation. This pattern allows grouping of sibling screens, in that the tab content container in the parent screen can embed child screens that otherwise would be entirely separate contexts. Tabs are most appropriate for small sets (4 or fewer) of section-related screens.

    @@ -89,7 +117,7 @@ next.link=ancestral-temporal.html

    Figure 5. Example phone and tablet tab-based navigation interfaces with relevant screen map excerpt.

    -

    Several best practices apply when using tabs. Tabs should be persistent across immediate related screens. Only the designated content region should change when selecting a tab, and tab indicators should remain available at all times. Additionally, tab switches should not be treated as history. For example, if a user switches from a tab A to another tab B, pressing the BACK button (more on that in the next lesson) should not re-select tab A. Tabs are usually laid out horizontally, although other presentations of tab navigation such as using a drop-down list in the Action Bar are sometimes appropriate. Lastly, and most importantly, tabs should always run along the top of the screen, and should not be aligned to the bottom of the screen.

    +

    Several best practices apply when using tabs. Tabs should be persistent across immediate related screens. Only the designated content region should change when selecting a tab, and tab indicators should remain available at all times. Additionally, tab switches should not be treated as history. For example, if a user switches from a tab A to another tab B, pressing the BACK button (more on that in the next lesson) should not re-select tab A. Tabs are usually laid out horizontally, although other presentations of tab navigation such as using a drop-down list in the Action Bar (pattern docs at Android Design) are sometimes appropriate. Lastly, and most importantly, tabs should always run along the top of the screen, and should not be aligned to the bottom of the screen.

    There are some obvious immediate benefits of tabs over simpler list- and button-based navigation:

    @@ -101,9 +129,15 @@ next.link=ancestral-temporal.html

    A common criticism is that space must be reserved for the tab indicators, detracting from the space available to tab contents. This consequence is usually acceptable, and the tradeoff commonly weighs in favor of using this pattern. You should also feel free to customize tab indicators, showing text and/or icons to make optimal use of vertical space. When adjusting indicator heights however, ensure that tab indicators are large enough for a human finger to touch without error.

    -

    Horizontal Paging

    +

    Horizontal Paging (Swipe Views)

    + +
    +

    Swipe Views Design

    +

    For design guidelines, read Android Design's Swipe Views pattern guides.

    +
    -

    Another popular lateral navigation pattern is horizontal paging. This pattern applies best to collection-related sibling screens, such as a list of categories (world, business, technology, and health stories). Like tabs, this pattern also allows grouping screens in that the parent presents the contents of child screens embedded within its own layout.

    +

    Another popular lateral navigation pattern is horizontal paging, also referred to as swipe views. This pattern applies best to collection-related sibling screens, such as a list of categories (world, business, technology, and health stories). Like tabs, this pattern also allows grouping screens in that the parent presents the contents of child screens embedded within its own layout.

    This class is not specific to any particular version of the Android platform. It is also primarily design-focused and does not require knowledge of the Android SDK. That said, you should have experience using an Android device for a better understanding of the context in which Android applications run.

    -

    You should also have basic familiarity with the Action Bar, used across most applications in devices running Android 3.0 and later.

    +

    You should also have basic familiarity with the Action Bar (pattern docs at Android Design), used across most applications in devices running Android 3.0 and later.

    diff --git a/docs/html/training/design-navigation/multiple-sizes.jd b/docs/html/training/design-navigation/multiple-sizes.jd index 7a8139f08910..ebaec0f567a0 100644 --- a/docs/html/training/design-navigation/multiple-sizes.jd +++ b/docs/html/training/design-navigation/multiple-sizes.jd @@ -22,6 +22,7 @@ next.link=descendant-lateral.html

    You should also read

    @@ -35,6 +36,12 @@ next.link=descendant-lateral.html

    Group Screens with Multi-pane Layouts

    +
    +

    Multi-pane Layout Design

    +

    For design guidelines, read Android Design's Multi-pane Layouts pattern guide.

    +
    +

    3 to 4-inch screens are generally only suitable for showing a single vertical pane of content at a time, be it a list of items, or detail information about an item, etc. Thus on such devices, screens generally map one-to-one with levels in the information hierarchy (categories → object list → object detail).

    Larger screens such as those found on tablets and TVs, on the other hand, generally have much more available screen space and are able to present multiple panes of content. In landscape, panes are usually ordered from left to right in increasing detail order. Users are especially accustomed to multiple panes on larger screens from years and years of desktop application and desktop web site use. Many desktop applications and websites offer a left-hand navigation pane or use a master/detail two-pane layout.

    @@ -76,12 +83,12 @@ next.link=descendant-lateral.html
  • Expand/collapse Expand/collapse strategy -

    A variation on the stretch strategy is to collapse the contents of the left pane when in portrait. This works quite well with master/detail panes where the left (master) pane contains easily collapsible list items. An example would be for a realtime chat application. In landscape, the left list could contain chat contact photos, names, and online statuses. In portrait, horizontal space could be collapsed by hiding contact names and only showing photos and online status indicator icons.

    • +

    A variation on the stretch strategy is to collapse the contents of the left pane when in portrait. This works quite well with master/detail panes where the left (master) pane contains easily collapsible list items. An example would be for a realtime chat application. In landscape, the left list could contain chat contact photos, names, and online statuses. In portrait, horizontal space could be collapsed by hiding contact names and only showing photos and online status indicator icons. Optionally also provide an expand control that allows the user to expand the left pane content to its larger width and vice versa.

  • Show/Hide Show/Hide strategy -

    In this scenario, the left pane is completely hidden in portrait mode. However, to ensure the functional parity of your screen in portrait and landscape, the left pane should be made available via an onscreen affordance (such as a button). It's usually appropriate to use the Up button in the Action Bar to show the left pane, as is discussed in a later lesson.

    • +

    In this scenario, the left pane is completely hidden in portrait mode. However, to ensure the functional parity of your screen in portrait and landscape, the left pane should be made available via an onscreen affordance (such as a button). It's usually appropriate to use the Up button in the Action Bar (pattern docs at Android Design) to show the left pane, as is discussed in a later lesson.

  • Stack Developer's Guide: User Interface: learn how to implement your user interface designs using the Android SDK.
  • Action Bar: implement tabs, up navigation, on-screen actions, etc.
  • Fragments: implement re-usable, multi-pane layouts -
  • Support Library: implement horizontal paging using ViewPager
    • +
  • Support Library: implement horizontal paging (swipe views) using ViewPager
    • -- cgit v1.2.3-59-g8ed1b From bb9bffb6b9baede8239589599f7ef59859f94f7d Mon Sep 17 00:00:00 2001 From: Roman Nurik Date: Thu, 26 Jan 2012 14:56:28 -0800 Subject: docs: add NOTICE to action bar icon pack and sprinkle download links Change-Id: I1437ce64908c28621e86fff54767ddbd2b1fcb3a --- docs/html/design/patterns/actionbar.html | 18 ++++++++++++++++- .../static/download/action_bar_icons-v4.0.zip | Bin 1100797 -> 1104707 bytes docs/html/design/style/iconography.html | 22 +++++++++++++++++++-- 3 files changed, 37 insertions(+), 3 deletions(-) diff --git a/docs/html/design/patterns/actionbar.html b/docs/html/design/patterns/actionbar.html index 99ae2d75ee73..911c549df7db 100644 --- a/docs/html/design/patterns/actionbar.html +++ b/docs/html/design/patterns/actionbar.html @@ -133,7 +133,7 @@ The app icon establishes your app's identity. It can be replaced with a differen you wish. Important: If the app is currently not displaying the top-level screen, be sure to display the Up caret to the left of the app icon, so the user can navigate up the hierarchy. For more discussion of -Up navigation, see the "Navigation" pattern. +Up navigation, see the Navigation pattern.
    @@ -369,6 +369,22 @@ action overflow.

    If either F, I, or T apply, then it's appropriate for the action bar. Otherwise, it belongs in the action overflow.

    +

    + +Pre-defined glyphs should be used for certain common actions such as "refresh" and "share." The +download link below provides a package with icons that are scaled for various screen densities and +are suitable for use with the Holo Light and Holo Dark themes. The package also includes unstyled +icons that you can modify to match your theme, in addition to Adobe® Illustrator® source +files for further customization. + +

    +

    + +Download the Action Bar Icon +Pack + +

    +
    diff --git a/docs/html/design/static/download/action_bar_icons-v4.0.zip b/docs/html/design/static/download/action_bar_icons-v4.0.zip index e255931f9765..456889405687 100644 Binary files a/docs/html/design/static/download/action_bar_icons-v4.0.zip and b/docs/html/design/static/download/action_bar_icons-v4.0.zip differ diff --git a/docs/html/design/style/iconography.html b/docs/html/design/style/iconography.html index 663770b6933d..5d5d200af75e 100644 --- a/docs/html/design/style/iconography.html +++ b/docs/html/design/style/iconography.html @@ -193,10 +193,28 @@ from above, so that users perceive some depth.

    Action Bar

    -

    Action bar icons are graphic buttons that represent the most important actions people can take +

    + +Action bar icons are graphic buttons that represent the most important actions people can take within your app. Each one should employ a simple metaphor representing a single concept that most -people can grasp at a glance.

    +people can grasp at a glance. + +

    +

    + +Pre-defined glyphs should be used for certain common actions such as "refresh" and "share." The +download link below provides a package with icons that are scaled for various screen densities and +are suitable for use with the Holo Light and Holo Dark themes. The package also includes unstyled +icons that you can modify to match your theme, in addition to Adobe® Illustrator® source +files for further customization. + +

    +

    + +Download the Action Bar Icon +Pack +

    -- cgit v1.2.3-59-g8ed1b From 2c911b24163c9bcb50bc548c828b7fc2f6ef8bce Mon Sep 17 00:00:00 2001 From: John Wang Date: Fri, 27 Jan 2012 11:05:24 -0800 Subject: Adjust the LTE signal bar mapping. The new mapping are Four bars: RSRP >= -95dBm Three bars: -105 dBm <= RSRP < -95 dBm Two bars: -115 dBm <= RSRP < -105 dBm One bars: RSRP < -115 dBm No bars: No Service bug:5640958 Change-Id: I9efabaeac33b624ea0a58a4d3760169dff6544f6 --- telephony/java/android/telephony/SignalStrength.java | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/telephony/java/android/telephony/SignalStrength.java b/telephony/java/android/telephony/SignalStrength.java index 3128592ca004..05e198f3dbdb 100644 --- a/telephony/java/android/telephony/SignalStrength.java +++ b/telephony/java/android/telephony/SignalStrength.java @@ -568,11 +568,10 @@ public class SignalStrength implements Parcelable { int levelLteRsrp = 0; if (mLteRsrp == -1) levelLteRsrp = 0; - else if (mLteRsrp >= -90) levelLteRsrp = SIGNAL_STRENGTH_GREAT; - else if (mLteRsrp >= -100) levelLteRsrp = SIGNAL_STRENGTH_GOOD; - else if (mLteRsrp >= -110) levelLteRsrp = SIGNAL_STRENGTH_MODERATE; - else if (mLteRsrp >= -118) levelLteRsrp = SIGNAL_STRENGTH_POOR; - else levelLteRsrp = 0; + else if (mLteRsrp >= -95) levelLteRsrp = SIGNAL_STRENGTH_GREAT; + else if (mLteRsrp >= -105) levelLteRsrp = SIGNAL_STRENGTH_GOOD; + else if (mLteRsrp >= -115) levelLteRsrp = SIGNAL_STRENGTH_MODERATE; + else levelLteRsrp = SIGNAL_STRENGTH_POOR; if (DBG) log("Lte level: "+levelLteRsrp); return levelLteRsrp; -- cgit v1.2.3-59-g8ed1b From b1560f20859ac46d48a753e67d9ac33748d2c558 Mon Sep 17 00:00:00 2001 From: Scott Main Date: Thu, 26 Jan 2012 16:14:29 -0800 Subject: docs: add G+ page announcement to homepage Change-Id: I400334fc1465b67ec34af2071a6cca5b6eda116f --- docs/html/index.jd | 30 +++++++++++++++++++++++++++++- docs/html/resources/community-more.jd | 21 ++++++++++++++++++++- docs/html/resources/resources_toc.cs | 2 +- 3 files changed, 50 insertions(+), 3 deletions(-) diff --git a/docs/html/index.jd b/docs/html/index.jd index 9197b5d202a3..c14c0ae05c63 100644 --- a/docs/html/index.jd +++ b/docs/html/index.jd @@ -142,6 +142,20 @@ href="{@docRoot}resources/dashboard/platform-versions.html">Learn more »diff report. If you're new to Android, " + "get started with the SDK starter package.

    " }, + + 'plus': { + 'layout':"imgLeft", + 'icon':"google-plus-small.png", + 'name':"Google+ Page", + 'img':"google-plus.png", + 'title':"Android Developers on Google+", + 'desc': "

    We now have a Google+ page for +Android Developers. " ++ "We'll use it to host Hangouts for developers, talk about the latest releases, " ++ "development and design tips, and much more.

    " ++ "
    " + }, 'tv': { 'layout':"imgLeft", @@ -186,5 +200,19 @@ href="{@docRoot}resources/dashboard/platform-versions.html">Learn more » + + + + diff --git a/docs/html/resources/community-more.jd b/docs/html/resources/community-more.jd index df729265cc05..3089d45aa9b5 100644 --- a/docs/html/resources/community-more.jd +++ b/docs/html/resources/community-more.jd @@ -1,5 +1,5 @@ community=true -page.title=IRC and Twitter +page.title=IRC, G+, Twitter @jd:body

    In addition to the Android developer forums, you can participate in the Android developer community through IRC and you can follow us on Twitter.

    @@ -45,8 +45,27 @@ does not require any installation, to join discussions on the Android IRC channe + +

    Google+

    +

    We use a Google+ page to host Hangouts for developers, talk about the latest +releases, development and design tips, and much more.

    + +
    + +

    Twitter

    You can follow us on Twitter at this account:

    http://twitter.com/androiddev

    + + \ No newline at end of file diff --git a/docs/html/resources/resources_toc.cs b/docs/html/resources/resources_toc.cs index 8df419fd5a6a..628df9ecfe46 100644 --- a/docs/html/resources/resources_toc.cs +++ b/docs/html/resources/resources_toc.cs @@ -302,7 +302,7 @@ Developer Forums
  • - IRC, Twitter + IRC, G+, Twitter
    • -- cgit v1.2.3-59-g8ed1b From fa9b5cae646ab1461c9f0f4b170c941e3da7c740 Mon Sep 17 00:00:00 2001 From: Dianne Hackborn Date: Mon, 30 Jan 2012 11:45:00 -0800 Subject: Update documentation to reflect the old approach not working. The old approach has a problem with the original application's recent tasks entry disappearing (this is probably a bug in the platform). Update to an alternative approach that does work. Change-Id: I15e582eff8c77cc22628f7b099e9f04eb5bfbce7 --- .../guide/topics/ui/notifiers/notifications.jd | 24 +++++++++------------- 1 file changed, 10 insertions(+), 14 deletions(-) diff --git a/docs/html/guide/topics/ui/notifiers/notifications.jd b/docs/html/guide/topics/ui/notifiers/notifications.jd index 33b0fecc9ed5..bef9671100bf 100644 --- a/docs/html/guide/topics/ui/notifiers/notifications.jd +++ b/docs/html/guide/topics/ui/notifiers/notifications.jd @@ -245,31 +245,27 @@ an application to be part of that application's UI flow, so simply launching the activity like this can cause it to be mixed with your normal application back stack in undesired ways. To make it behave correctly, in the manifest declaration for the activity the attributes -android:launchMode="singleInstance" and +android:launchMode="singleTask", +android:taskAffinity="" and android:excludeFromRecents="true" must be set. The full activity declaration for this sample is:

    {@sample development/samples/ApiDemos/AndroidManifest.xml interstitial_affinity} -

    Because of the use of singleInstance, you must be careful about launching -any other activities from this one. These activities will be launched -in their own task, and care must be taken to make sure this interacts -well with the current state of your application's task. This is essentially +

    You must be careful when launching other activities from this initial activity, +because this is not a top-level part of the application, does not appear in +recents, and needs to be relaunched at any point from the notification with new data +to show. This best approach is to make sure any activity launched from it is +launched in its own task. When doing this care must be taken to make sure this +new task interacts well with the current state of your exiting application's +task. This is essentially the same as switching to the main application as described for the Email style notification shown before. Given the makeMessageIntentStack() -method previously shown, handling a click here would look something like this:

    +method previously shown, handling a click then would look something like this:

    {@sample development/samples/ApiDemos/src/com/example/android/apis/app/IncomingMessageInterstitial.java app_launch} -

    If you don't want to use the singleInstance launch mode for -this activity, an alternative approach is to use android:taskAffinity="". -This tells Android that the activity should not be treated as part of the -main application flow, so it will not get mixed together with that. All of the -other issues discussed here do still apply, though this would allow you to start -additional activities that are part of this notification task instead of switching -to and replacing the main application task.

    -

    Managing your Notifications

    The {@link android.app.NotificationManager} is a system service that manages all -- cgit v1.2.3-59-g8ed1b