Creating Tabbed Content on Android

[richervin]

I've read what I can find on this topic, and this is what I believe I've found. I'm looking for verification/correction on this:

The basic issue is the need to create a panel of content on the screen of the phone which
a) Displays a different set of controls to the user depending on which tab is selected
b) Allows the user to change tabs
c) Ensures that the state of tabs is preserved between tabs (i.e. the user is working on Tab A, can change to Tab B, then come back to Tab A to continue working)

Here is what I think I understand about this:

The Tabbed Panel
1) That the "tabbed panel" control is not really a panel, and cannot contain other objects.
2) It is really only a simple outline object with push buttons, over which other content can be displayed
3) Cannot be reskinned for Mobile devices
4) Does not provide any built in support to actually change the tabs, the tabbing functionality must be emulated with "Hide" and "Show" commands

The Substack
1) The substack feature works on Android
2) Does not work well for a smaller-sized substack, as one would like to see in a tabbed application, it leaves the underlying objects partially exposed, partially covered, and non-functional
3) Cannot be resized (true or false?)

The Card
1) Covers the entire screen, and cannot be used for a smaller panel (true or false?)

A Group
1) Contains multiple objects
2) Can be scripted (True/False?)
3) Can be hidden or shown
4) Retains it's state when hidden, so when it is shown again it is in the same state as when it was hidden (true/false?)

My Summary
Substacks do not work well for Android
Cards are not suitable for panel type functionality
The "Tabbed Panel" does not provide tabbing OR panel functionality
Groups is the best/only way to provide this kind of functionality.

[JacobS]

Yes Richervin, from what I've found you're correct.

I have developed multiple applications for Android that make use of tabs and tabbed content. You're correct that the tabbed panel control doesn't work well at all on Android. And that using multiple cards doesn't work well in Android either. And yes, groups are definitely the best way to provide this functionality.

When I implement tabs in my apps, I find that it's easiest to make 3 or 4 (or however many tabs you want) "tabs" out of fields and then add mouseDown functionality to them. The mouseDown event will hide/show groups according to which tab was clicked on. It's also nice to change the backgroundcolor of the field to a different color than the others, so the user knows which tab they selected.

Hope this helps,
Jacob

[richervin]

Thanks Jacob, I appreciate the feedback. I'm working on this now.

I think I made one flawed assumption about groups being scriptable - it looks like the groups themselves are not scriptable.

Edit: Groups ARE scriptable

If that's the case, I may go to a hybrid option using cards for tabs, and using groups to control screen flow within the cards. Otherwise I'll end up with a hundred or more elements to manage. I'll have to duplicate the navigation bar (i.e. "tabs") across the cards, but there are only 4 cards so that is a minimal amount of duplication. I think this will simplify the logic, but maybe not. I guess this might also lead to some code duplication which could otherwise be shared.

I'm envisioning a massive group of case statements using the single card method. I suppose that can be managed by organizing functionality into subroutines.

[sturgis]

If you decide you want to use a tab panel and cards for navigation you can
1. add the tab panel.
2. select it and click "group" so that its is in a group of 1.
3. set the group to act as a background. New cards will get the group. If you already had some cards you can "place" the group onto them.

At this point similar to showing and hiding groups you can "go card..." in your button scripts. In fact, when I do this I name my cards in a form matching the button labels so that the label can be used for the card transition. Having said this, showing and hiding groups works just as well.

I agree that using substacks is pointless except for their use as library stacks on mobile.

Finally, groups are scriptable. Though the empty space in a group is not clickable, but the objects in the group are so you can use the group script to handle their events.

For a quick example, create a few buttons, group them. Add this script to the group

on mouseup
put the id of the target
end mouseup

THe message box will display the id of each button as you click them, but if you click blank space nothing is sent to the message box. (in fact the last message stays there unchanged.)

[richervin]

Thanks sturgis, this conversation is bringing back some ideas from the last time I tried to evaluate liveCode.

Right now I'm messing around with the TickedOff sample application, but the more I look at how it's structured, the more I think it is unnecessarily complex and perhaps is not the best template - at least not for a quick prototype.

I think I'm going to go to a barestack, and work on putting this together with just basic Card, Group, Field, and Button elements and a plain black background.

It's a little disturbing that RunRev didn't provide a better set of mobile widgets, especially since this is a major segment for them. But then, if they did, I suppose people wouldn't want to use them because of the look and feel.