Fixed-position bar

[ykami]

Fixed-position header bar or footer bar, such as iPhone's UITabBar, are a common requirement for better mobile web applications. But it won't be straightforward. Unlike desktop browsers, CSS position:fixed just doesn't work on mobile Safari. Probably we need to disable the default scrolling functionality and re-build our own with JavaScript? by capturing touch events. The code should be optional. It should only be for those who need fixed-position bars.

[ykami]

Shane,

You can assign this to doughays if you like. I just started working on this. I will send a patch to Douglas when finish.

[Douglas Hays]

ykami, the window to inject new features into 1.6 is almost closed. Any progress on this?

[ykami]

Sorry for being late. I just sent it to you. If possible, I would like Shane to review the code, though I don't think I broke Shane's code.

[Douglas Hays]

fix to be reviewed. test_iPad-Settings-fixed.html deleted

[Douglas Hays]

Shane, can you review this patch?

[Shane O'Sullivan]

I'll take a look this weekend

[Douglas Hays]

new icons for dojox/mobile/tests/images/

[ykami]

Thanks Shane for the code review. The patch contains only TabBar? implementation as a fixed bar. Probably we need a toolbar on which you can place any buttons as well. I'll think about it if the patch is accepted.

Also, I'm thinking I better move TabContainer? and IconContainer? to separate files, though I didn't do it in this ticket.

[ykami]

class diagram of the touch scrolling related modules

[Shane O'Sullivan]

I'm about to look at the code. However, from reading the description it looks like we could be duplicating functionality with Uxebu's TouchScroll? code (​http://uxebu.com/blog/2010/04/27/touchscroll-a-scrolling-layer-for-webkit-mobile). Their code works great for iOS and Android, and it'd be great to maybe set up a svn:external link to their GitHub? repo to pull it into Dojo.

Right, onto the code!

[Shane O'Sullivan]

GitHub? link to TouchScroll? - ​https://github.com/davidaurelio/TouchScroll

[Shane O'Sullivan]

A few thoughts:

1. I think it's too late to get new code into 1.6. So this will likely have to wait until after 1.6

2. Can you try to integrate the ScrollableView? with TouchScroll?? If you get it working well, we can look into setting up a svn:external to pull it into dojox.mobile. I've spoke to Uxebu and they're fine with this, but they want to keep it as a standalone project. I see no point in duplicating effort here. We may need to speak to them re: CLAs etc but it should be fine.

3. You're submitting multiple items here. ScrollableView? and FlippableView? are completely separate and should be submitted in separate tickets. I'm not clear how the changes to the FixedSplitter? are related to the fixed header. Can you please break this into multiple tickets, each fixing a single thing?

4. In ScrollableView?, is there a reason that the 'flippable' value applies to it, and not to 'dojox.mobile.View' ? Shouldn't this code be in dojox.mobile.View? Also, can you use a CSS class rather than setting a style of width:100% in ScrollableView? when flippable is true?

5. dojox.mobile._magic is a hack if ever I saw one :-) Using TouchScroll? should remove the need for magical hack.

6. In TabBar?, the line

box.appendChild(r.removeChild(r.firstChild));

can be shortened to

box.appendChild(r.firstChild);

[ykami]

>1. I think it's too late

This is dojox. What's the benefit of not moving forward?

>2. duplicating effort

You are right, I know it was kind of duplicated effort. But it's already done and already integrated well, and I had some reasons.

• Implementation can be straightforward

• Maintenance is (far) easier

• To add support for non-CSS3 desktop browsers

If you still want to try to integrate the other technologies, I don't disagree. You can make the scroller exchangeable. Providing user choices is not a bad idea. But in that case, do not forget to add support for non-CSS3 desktop browsers, since it is one of important features of dojox.mobile. (Anyway, I can't help you with this task.)

>3. You're submitting multiple items here

FlippableView? is kind of feasibility test for the scrolling implementation. FixedSplitter? had its own scrolling implementation, which was replaced by the new implementation. They are all closely related to the fixed bar realization. Having said that, it's true that my patch tends to be big. There are some reasons. One is that it is still in development phase, not in bug tracking phase. Another is one code delivery cycle is too costly for me. Partly because of my company's procedure.

>4. In ScrollableView?, is there a reason that the 'flippable' value applies to it

I'm not sure I fully understand all of your points, but I think I have chance to think of these sorts of refactoring next time.

>5. dojox.mobile._magic is a hack

Actually this code is not necessary. I just found, in some particular dom structure, that code makes scrolling a little more smoother. It might be effective whatever scrolling implementation you use.

So, why don't we move forward? I already have next patches that depend on this patch.

[ykami]

For cross-browser and non-dojo apps support, scrollable.js works as follows.

Browser	App Type	How scrolling animation works
webkit(iPhone,Android,Chrome,Safari)	dojo	CSS3 animation
webkit(iPhone,Android,Chrome,Safari)	non-dojo	CSS3 animation
non-webkit(IE,Firefox)	dojo	dojo.fx
non-webkit(IE,Firefox)	non-dojo	No flick animations but at least scrollable

[Douglas Hays]

Jared has reviewed the patch as well

[Jared Jurkiewicz]

I'll look at committing this after more review and testing. In the meantime, I ask that follow-up patches include function documentation for all defined functions.

[Jared Jurkiewicz]

(In [23208]) Adding in some cool touchscroll code from Kamiyama. Should revisit and integrate with wink/embedjs, but this is a start and helps. \!strict fixes #11855

[ykami]

Thanks Shane and Jared for the code review of such a big patch.