if (Titanium.Platform.name == 'iPhone OS')
{
    var laborsync = Titanium.UI.createWindow({url:'laborsync.js',backgroundColor:'#f3f4f4',tabBarHidden:true,navBarHidden:true,animate:false});
}

if (Titanium.Platform.name == 'android')
{
    var laborsync = Titanium.UI.createWindow({url:'laborsync.js',backgroundColor:'#f3f4f4',tabBarHidden:true});
}

var tabGroup = Ti.UI.createTabGroup();

var tab = Ti.UI.createTab({
    title:"Doesn't matter",
    window: laborsync
});

tabGroup.setActiveTab(1);

tabGroup.addTab(tab);

tabGroup.open();

16 Answers

• This is a problem for me, too. As far as I can tell the only way to make apps with "back" buttons in a nav bar on the iPhone is to use tabs. On Android you can use fullscreen/modal windows that revert to the previous window when the back button is pressed, but we shouldn't have to redesign our app's window opening method for different platforms.

• This is how I am rendering windows on both the iPhone and Android with no tab bars or nav bars:

  Titanium.UI.setBackgroundColor('#000');
  var tabGroup = Titanium.UI.createTabGroup();
  
  var firstRun = Titanium.App.Properties.getString('init') ? false : true;
  
  var rootWindow = Titanium.UI.createWindow({ 
      statusBarHidden:false,
      navBarHidden:true, // top tab area on iphone
      tabBarHidden:true, // bottom tab area on iphone
      url:(firstRun ? 'init1.js' : 'init2.js')
  });
  
  rootWindow.orientationModes = [ Titanium.UI.PORTRAIT ];
  
  if (Titanium.Platform.name == 'iPhone OS') {
      var rootTab = Titanium.UI.createTab({ 
          title:'Root Tab',
          window:rootWindow
      });
      tabGroup.addTab(rootTab);
      tabGroup.open();
  }
  
  if (Titanium.Platform.name == 'android') {
      rootWindow.open();
  }
  

  Then, depending on if the URL of the window is set to init1.js or init2.js, I can render anything like so:

  var window = Titanium.UI.currentWindow;
  var label = Titanium.UI.createLabel({
      color:'#000',
      text:'In init1.js',
      width:'auto'
  });
  window.add(label);
  

  I'm not very far in developing apps with Titanium, but this seems like it works for simple apps that don't require a lot of (or any) tab switching (which mine doesn't). If anyone has any caveats to share, please do so.

• It shouldn't crash, but you can't hide the tabs in Android. Why even bother with tabs at all if you're not using them?

• Let me pontificate just a bit.

  We are going to be looking into creating a core layer that works cross platform on all supported devices. In order to do that, it will basically have to be mostly non-UI and the UI feature will be driven by what's a capability on all platforms. For instance, blackberry doesn't provide tabs at all. That being said. If you want a no UI changes App, you'll be able to create one.

  We are also going to be working on exploiting, in a non-cross platform way, platform specific features. For example Android Activities, Intents, Notifications, Services, etc. they will be in the Ti.Android namespace and if you use those features to build a best of breed Android app your users will appreciate it.

  For the ideal user experience (UX) you should write to the UI metaphors of the platform the User uses and follow the UX of that platform. That works all ways. An iPhone user would be confused by a true port of an Android app. A blackberry user wouldn't even be able to use a true port of an iPhone app if they have a keyboard only device.

  Titanium's strength, IMO, is a common set of tooling, a single language, and cross platform library support everywhere we can provide it.

  Not sure if that address everything in the thread, but I'm hoping it helps you rethink the problem from a UX perspective vs a programmer comfort perspective.

• Hi, I insert myself into this thread.
  In my perspective Don is right. You should adhere to the UX rules of the target platform. In particular, iOS uses the navbar for providing navigation facilities, since on the physical device you only have one button (the home button). On the other hand Android relies on a physical back button.

  You are forced using a TabGroup for visualizing the navbar because Ti.UI.iPhone.NavigationGroup isn't working properly, however on Android you could simply get rid of the TabGroup from the start creating a simple window.
  Obviously, for easing your development tasks you should encapsulate window creation code in some function that takes care of applying the correct behaviour based on the actual platform it is executed onto.

  In this pastie you can find a couple of functions: the first is to be used for creating the main app window (usually in app.js), while the second is to be used every time you need to open a new window. This allows you to get a consistent behaviour across the two platforms.

  I hope this will help.

• Try This Link, Mritunjay Singh Answer this This is really help for you

• Try This Really working :

  http://developer.appcelerator.com/question/109971/how-to-hide-tabgroup-or-tabbar-in-android.html#answer-240922

• Thanks Don for your quick reply, I used tabs because I read in the Q&A's that the only way to use shownavbar and hideNavBar was if tabs were used. Maybe I read incorrect?

• Looks like nobody has found a suitable solution for this, huh?

• DId we ever figure this out? I'm dealing with the same thing and it's an absolute show-stopper :(

• I didn't expect this simple task of getting rid of the top bar would be such a hassle until I tried to do it.. Even tried it with win.hideNavBar({animated:false}); with the same error on my android emulator. I get Cannot call property hideNavBar in object… It is not a function, it is object. or if I use navBarHidden:true, I get the sucky stopped unexpectedly error. There must be a way to get rid of it.. Here are the closest open tickets I found on the subject: https://appcelerator.lighthouseapp.com/projects/32238/tickets/1097-android-fullscreen-issues and https://appcelerator.lighthouseapp.com/projects/32238/tickets/1621-ios-navbarhiddentabbarhidden-assignments-do-not-have-immediate-effect

  Guess I gotta live with the flaw in the meantime.. Should I bother posting a new ticket that more accurately describes this bug?

• I am also affected by this issue.

  The use case for me is that I want to use tabs, but I don't want them visible until the user has logged in. So I want a full screen login window, so that the tabs are not navigable - and preferably not visible.

  I can do this buy initially opening a stand alone login window and creating the tabGroup on successful log in, the content of the windows in the tabGroup are dependant on data entered in a text field in the log in window, this all works great.

  My problem then becomes hidingdisabling the tabs and re-displaying the login window when the user clicks on a 'logout' button from one of the tabs. (Android only - it all works a treat for iPhone)

  Actually would a modal window meet my requirements? I would still need to regenerate the tabGroup window content depending on the logged in user.

• Did we ever figure this out? I'm running into this issue, now, myself and it's an absolute show-stopper :(

• I am also interested in this. Has anybody found a way or is this just not possible with the current/official release (1.3.0) version? Or is this not also possible in soon-to-be-released 1.4?

• you can use this code to hide Tab Bar in android

  tabGroup.addEventListener("open", function(){
  tabGroup.animate({top:-65,duration:0});
  });

• you can use this code to hide Tab Bar in android

  tabGroup.addEventListener("open", function(){
  tabGroup.animate({top:-65,duration:0});
  });