Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#11855 closed enhancement (fixed)

Fixed-position bar

Reported by: ykami Owned by: Jared Jurkiewicz
Priority: high Milestone: 1.6
Component: DojoX Mobile Version: 1.5
Keywords: Cc: Shane O'Sullivan
Blocked By: Blocking:

Description

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.

Attachments (3)

dojox-mobile-20101111.patch (217.4 KB) - added by Douglas Hays 9 years ago.
fix to be reviewed. test_iPad-Settings-fixed.html deleted
new-icons.zip (19.6 KB) - added by Douglas Hays 9 years ago.
new icons for dojox/mobile/tests/images/
scrollable-class-diagram.gif (9.2 KB) - added by ykami 9 years ago.
class diagram of the touch scrolling related modules

Download all attachments as: .zip

Change History (20)

comment:1 Changed 9 years ago by 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.

comment:2 Changed 9 years ago by Shane O'Sullivan

Owner: changed from Shane O'Sullivan to Douglas Hays

comment:3 Changed 9 years ago by Douglas Hays

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

comment:4 in reply to:  3 Changed 9 years ago by 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.

Changed 9 years ago by Douglas Hays

Attachment: dojox-mobile-20101111.patch added

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

comment:5 Changed 9 years ago by Douglas Hays

Cc: sos added
Milestone: tbd1.6
Status: newassigned

Shane, can you review this patch?

comment:6 Changed 9 years ago by Douglas Hays

Cc: Shane O'Sullivan added; sos removed

comment:7 Changed 9 years ago by Shane O'Sullivan

I'll take a look this weekend

Changed 9 years ago by Douglas Hays

Attachment: new-icons.zip added

new icons for dojox/mobile/tests/images/

comment:8 Changed 9 years ago by 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.

Changed 9 years ago by ykami

class diagram of the touch scrolling related modules

comment:9 Changed 9 years ago by 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!

comment:11 Changed 9 years ago by 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
  1. 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.

  1. 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?
  1. 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?
  1. dojox.mobile._magic is a hack if ever I saw one :-) Using TouchScroll? should remove the need for magical hack.
  1. In TabBar?, the line

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

can be shortened to

box.appendChild(r.firstChild);

comment:12 Changed 9 years ago by 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.

comment:13 Changed 9 years ago by 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

comment:14 Changed 9 years ago by Douglas Hays

Owner: changed from Douglas Hays to Jared Jurkiewicz
Status: assignednew

Jared has reviewed the patch as well

comment:15 Changed 9 years ago by 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.

comment:16 Changed 9 years ago by Jared Jurkiewicz

Resolution: fixed
Status: newclosed

(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

comment:17 Changed 9 years ago by ykami

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

Note: See TracTickets for help on using tickets.