我来自iOS世界，需要使用典型的标签栏/导航模式将应用移植到Android。 UI设计是客户的决定，因此我无法对其进行更改（如果您认为Android适用与否，我仍希望收到您的回复）。
所以应用程序的想法如下： 3个选项卡始终显示在屏幕底部。在每个标签内部，可以有一个屏幕层次结构，标题和向上按钮显示在顶部的操作栏中。 如何在Android中实现此功能？我是否正确，因为标签需要是一个需要在每个活动中实施的片段？硬件后退按钮应该如何表现？假如我切换到某个标签，然后按后退按钮，是否应该更换标签或是否应该反映按钮的功能？
正如您所看到的，我正在努力解决所有这些基本概念，我非常感谢能够帮助我实施此导航结构的任何提示。
感谢CommonsWare的有力回答并深入研究它，我意识到我真的应该推动客户使用更适合该平台的UI。 （另外，我知道我应该使用Android设备一段时间来习惯这些概念，但我暂时无法改变这一点。所以我很抱歉这些新手问题。）
问题是，该应用程序之前作为Web容器应用程序存在，其中包含具有上述UI元素的丑陋的jquery移动UI。现在的想法是使应用程序导航与原生动画本地化，同时将内容视图保留在webview中的html / css / js中。因此，尽管可以调整每个平台的UI原则，但我无法更改应用程序的一般结构，即：3个不同的主要入口点，并且在每个应用程序中，内容按层次结构进行导航。我已经在iOS中实现了带有tabbar和导航控制器的功能。现在的挑战是在Android中实现它。为了让我放心，我正确地理解了CommonsWare的要点以及可能收到更多提示，我写下了我对所涉及步骤的看法：
正如CommonsWare所建议的那样，我可以用动作栏中的动作按钮替换标签的想法，因为它只有3个动作按钮。因此，使用行动按钮进行导航是否合适？将会有一个用于切换语言的附加按钮（是的，我知道，通常我应该选择系统的当前语言，但在这种特定的应用程序语言切换很重要，用户在使用应用程序时会多次切换它）。为了将导航操作按钮与语言切换器分开，后者对当前内容起作用并且不那么重要，我将语言切换器置于所谓的＆＃34;动作溢出＆＃34; （右上角有3个点）。
现在每个＆＃34;标签都有一个操作栏按钮＆＃34;到目前为止一直很好。但有没有办法让用户知道哪个＆＃34;标签＆＃34;他是？或者我应该在任何给定时间只显示两个操作栏按钮，隐藏他当前的＃34;＆＃34;？
这些操作栏按钮中的每一个都会启动一个新活动（使用它自己的操作栏，对吧？）。在这样的活动中，用户可以使用向上按钮或向后按钮分层导航并返回。他还可以使用硬件后退按钮返回到最后一个选项卡＆＃34 ;;这会合适吗？ 导航层次结构中的每个屏幕都是一个单独的活动，其中包含标题和Web视图。
最后，为了让整个应用程序与姜饼兼容，我会使用actionbarsherlock库，对吗？
答案 0 :(得分：2)
3个标签始终显示在屏幕底部
那violates the Android design guidelines。在Android上，tabs go at the top。
在每个标签内，可以有一个屏幕层次结构
在Web浏览器之外，我真的讨厌这个导航概念。
我是否正确，因为标签需要是一个需要在每个活动中实施的片段？
您提议的设计中似乎没有多个活动。
如果我切换到某个标签，然后按后退按钮，如果标签更改回来还是应该反映按钮的功能？
这也是我真正讨厌标签内导航的原因之一。标签用于演示文稿的内容，而不是自身的可导航容器。
它应该反映按钮的功能吗？
由于您似乎没有多项活动，因此我不清楚您是否有一个向上按钮。
如何在Android中实现此功能？
理想情况下，您转储标签并使用action bar items在不同的可导航区域之间切换，每个区域都是自己的活动。在这种情况下，返回（并且在较小程度上）将更自然地流动。
如果您有三个以上的标签，则可以使用the navigation drawer pattern，其中每个可导航区域的抽屉中都有一个条目。但是，三个会让抽屉看起来很空。
Android设计指南中的app structure还有更多内容可以提供帮助。
UI设计是客户的决定，所以我无法改变它
应用程序的目标是允许用户实现其目标。使用平台原生的设计模式在这方面有所帮助，允许用户使用＆＃39;现有经验指导他们使用新应用程序。这并不是说超出准则的真正创新是不合适的，但它需要经验和灵巧的手。
您的客户似乎在说，＆＃34;嘿，这家公司为他们的平台提出了一种设计模式，因此我们可以随处使用它，因为我们需要一致的UI设计＆＃34; 。问题是无人关心关于除了它们之外的平台之间的一致性。很少有人从多个平台拥有移动设备，更不用说在两者上使用相同的应用程序，更不用说在两者上都需要相同的UI设计。当然，设计触摸（例如，配色方案）可以是类似的，并且如果不相同，则app的目标将是相似的。但该功能的交付应该使用每个平台原生的设计隐喻和模式，因为用户远比客户端更重要。
（如果您的客户说＆＃34;嗯，我们是用户＆＃34;，因为这是一个仅供内部使用的企业应用程序，请向他们解释时间流逝的概念，介绍他们员工离职的概念，并指出与应用程序的可能生命周期相比，他们不会成为那么长的用户。
如果您的客户经营一家美国汽车租赁公司，他们会争辩说他们的公司应该在英国租用left-hand-drive cars，以获得一致的用户界面体验，尽管所有的事故都会导致左翼 - hand- 交通国家。
现在，让我们假装你需要按照他们的UI设计编写这个应用程序。人质被枪口持有，有人在头发触发器上有一个核武器，坏人要求应用程序，the clock is ticking, you're Kiefer Sutherland，等等。
（如果你真的是 Kiefer Sutherland，嗯......嗨！）
您将最终获得此核心UI的单个活动。辅助内容（例如，首选项，帮助）将是单独的活动，但是三个选项卡到规则 - 所有UI将在一个活动中。
标签本身可能会使用FragmentTabHost，可能会进行修改以更好地支持底部的标签。这不是一个常见的选择，但它最适合。 ViewPager和标签指示符是另一种可能性，如果客户端不考虑水平滑动来更改标签，那么魔鬼的手势就会出现。或者其他的东西。操作栏选项卡位于顶部，并不总是选项卡，因为它们有时会转换为特定屏幕大小和方向组合的下拉导航。
每个标签都是一个片段，很可能会使用嵌套片段进行内容窗格之间的标签内导航。同样，还有其他可能性（例如，在单个片段中隐藏和显示小部件以处理导航），但我认为你会疯狂地试图管理所有这些。
关于BACK按钮，在不知道标签的上下文的情况下，我的直觉就是按照标签浏览器隐喻＆＃34; BACK是标签的本地＆＃34;。我认为你需要手动管理它，除非它因为你使用嵌套片段而神奇地起作用，我不认为这是事实。当您处于选项卡的开头（嵌套）片段，并且用户按下BACK时，退出活动。