12-14-2011 07:11 AM
I was wondering whether this is possible.
I plan to implement a Pane (introduced in 6.0) on OS 5.0.
Not to bother you with specifics, I will go straight to the problem.
My panes are actually VFMs. And they are all inside one HFM.
The horizontal FM allows me to use several screen widths, one for each pane (VFM).
Now, the problem is that the largest pane will determine the size of all other panes since the containing HFM will set its height to match the largest child.
The user impact is visible if you have (for example) two panes: left one (A) and right one (B).
If size of B (for instance) is, let's say, 60 rows and size A is only 3 rows, I cannot tell VFM a not to allow movement under that 3rd row. By movement I think in terms of touch-navigation.
The User can touch-slide the screen downards on A and a blank screen is shown (since there are only 3 rows).
Of course if he moves slightly to the right, portion of B is appeared as expected.
The desired effect would be the same thing currently displayed on home screen of touch devices with os>=6.0. (Panels: All, favorites, Media...).
So I know the cause, but don't know if I can create some kind of a jagged array of VFMs inside one HMF.
Solved! Go to Solution.
12-14-2011 07:18 AM
12-14-2011 11:19 AM
This is an ambitious endeavor, but should be possible with some persistance. I'm afraid you'll have to override touchEvent and create your own reactions to MOVE, SLIDE_NORTH and SLIDE_SOUTH gestures (do not invoke super.touchEvent in those cases). This is not easy - I see how it can be done, but you'll have to experiment with those. I don't have enough experience creating my own reactions to these - sorry.
Alternatively, you may go the way Simon has suggested:
- Create a manager (extends Manager - the abstract class!) with HORIZONTAL_SCROLL and VERTICAL_SCROLL with a highly specialized sublayout. Use it instead of your HorizontalFieldManager.
- In that sublayout, lay out the children horizontally (with setPositionChild), using display width and (Integer.MAX_VALUE >> 1) height in your layoutChild as parameters.
- Check which one of your children is "active" and properly set your Manager's height and virtual height (the width is always display width; the virtual width is display width multiplied by the number of children): your actual height should always be your display height while the virtual one should be the maximum of your display height and the active child's height. Check setExtent and setVirtualExtent methods.
- call updateLayout on each pane flipping to re-invoke your sublayout. You might want to surround it with some boolean flag setting and re-setting to indicate that your sublayout doesn't have to re-layout the children and needs to recalculate only its dimensions (the latter step is performance-only improvement).
To make sure you keep track of the active child properly, set scroll listener on your specialized Manager and react to the changes in horizontal scroll position. You will have to snap that scroll position to the closest child's boundary and set the "active" child accordingly.
I hope this doesn't sound too confusing. As you can see, it is not so easy, either.
12-14-2011 11:44 AM - edited 12-14-2011 11:46 AM
I think I am missing the point here because I don't think it needs to be that complicated....
Will the user ever want to see and interact with part of the next VFM displayed when on the current VFM? Or are you doing this to provide a smooth transition from one VFM to another?
Assuming you are just doing a smooth transition, then I think you may be able to achieve that another way.
Assuming that the user will want to see the 'next' VFM and the current VFM at the same time, then the issue is to just make sure that these are the same vertical size, which is the size of the display area. They can scroll independently.
You can see this effect if you look at a Torch Home screen and move it from side to side with all icons visible. The 'All' list will be full, but you can slide this up and down. Do so, and then move sideways and then move back, the scroll position stays the same. If you have any other full lists (like Downloads), then this can be independently scrolled too.
Does that work?
If it does, then I think you just have a HFM with a fixed Height, inside of which you have scrollable VFMs.
But I am probably missing something.
12-14-2011 02:17 PM
@peter_strange: on the second thought, I guess the OP missed the fact that MainScreen is vertically scrolling by default. So MainScreen(NO_VERTICAL_SCROLL) along with HorizontalFieldManager(NO_VERTICAL_SCROLL | HORIZONTAL_SCROLL | USE_ALL_HEIGHT) should be a good first approximation. The members of this custom PaneManager should all have the exact screen width, but this is easy to achieve.
I still think that having some scroll listener is essential - the user expects to see two panes at the same time only during transition, so there will be a need to pull the screen to a "stable" position.
12-14-2011 05:03 PM
As usual, you are right on spot!
"Assuming that the user will want to see the 'next' VFM and the current VFM at the same time, then the issue is to just make sure that these are the same vertical size, which is the size of the display area. They can scroll independently."
Yes that (along with other lines) is exactly what I needed.
I will try to follow your advice and see where it leads me
Thank you both for your help.
Once I get it working I'll resolve the thread.