Comment by dheera | Hacker News Reader

Comment by dheera | Hacker News Reader

I've tried PhoneGap and Cordova wih Polymer and my biggest gripe is that even the most basic of mobile UI gestures have no good analogue. For example to emulate swiping between tabs on a ViewPager, you have to implement hundreds of dirty lines of code in JavaScript to catch touch events and decide how they should behave, and hope you emulate the native experience. None of the tabbed interfaces of any of these frameworks have it built-in.

Then you inevitably have to deal with Safari's stupid rubber-band scrolling, which causes the titlebar of your app to scroll if dragged. Then when you disable that scrolling you're forced to implement your own scrollbar from scratch and emulate the Safari rubber band on the parts you actually want to scroll.

Pull-to-refresh? Good luck implementing it in a way that feels like a native app.

Building all that in JavaScript is possible, and with the help of CSS3 and WebGL it's often possible to get FPS on par with native apps, but emulating a native-feel UI in JavaScript is more work than just developing twice for Android and iOS. And you usually end up with so much JavaScript bloat and DOM hell that it takes forever to load on 3G or slower connections.

Seriously, can someone just give us <GridViewPager>..</GridViewPager>, <ViewPager>..</ViewPager>, <ListView>..</ListView> or something like that, with everything included, including touch gestures, and make it "feel" exactly like iOS or Android depending on the OS it is loaded on, matching the respective fonts, elasticity coefficients, gesture thresholds, and everything else, no questions asked?

I'm currently using NativeScript and react-native for app development and I have to comment because items like <ListView> [1] and Grid-Layouts [2] can be done using both technologies which use native rendering and achieve 60 FPS. They both have listeners for common UI gestures. If you're building a normal app (no video game) with some forms, list views and maybe some diagrams, just use those. They give you a native experience and you don't have to build it for each platform - we're currently not in the state of "write once, run everywhere", but we're close. It's really easy to get started, please read about those if you're not satisfied with the current level of Cordova and Web apps.

I used Framework7 for a PWA (Progressive Web App) and it has a very lean learning curve if you already know web stuff and it was very easy to integrate e.g. Chartjs, so if you don't like react or NativeScript's XML you can also use HTML and plain Javascript, although the iOS 10 change is a bit troubling. I don't have any problems like a scrolling titlebar with it. Try and see if it fits your use case.

[1]: https://facebook.github.io/react-native/docs/listview.html [2]: https://docs.nativescript.org/cookbook/ui/layouts/grid-layou...

You're never going to get smooth scrolling if you need to hit the UI thread for every touch event. The platform UI frameworks use background threads for scrolling, directly in the OS compositor.

I don't know about Android, but UIScrollView does all its work on the main thread of the app.

Thanks. I assumed iOS was like Windows. Although Windows also has scroller controls that you create on the UI thread but delegate the actual event handling to the compositor.

A compositor can only do scrolling if the app is written with a retained mode API. The low-level APIs in Windows are immediate mode, whether GDI or Direct2D.

For most of time, ScrollWindow / ScrollWindowEx was how you scrolled. It doesn't know what to draw in the invalidated region because it's an immediate mode API.

In Direct2D you can use e.g. a translation to get the renderer to draw a bigger bitmap in a different section of the window, but you need to render the bigger bitmap (i.e. assemble your own retained mode). There's no free lunch.

I'm talking about the UWP/XAML/DirectComposition world, which admittedly is not game-related.

This is not strictly correct. CoreAnimation does it's work in a background thread, so the mechanical work of scrolling pixels is not done on the UI thread unless you are doing custom drawing. Under the covers its a texture so the scrolling is really just translation.

If you want to be pedantic, this isn't quite right either. CoreAnimation does some work on the main thread to encode layer properties and send them to the render server, which is in another process, not another thread.

The important part isn't the amount of work it takes to render, it's that event handling is serialized with all the other stuff happening on the main thread.

This app has nude images but I solved the "stupid rubber-band scrolling problem" be setting the <html> and <body> tags to fixed position.[1] I just wanted to share an example of this working in the wild and I only discovered it last week. I'm using Angular Material Design with a <md-content> tag which has overflow: auto and position: relative. This creates a scrolling bar inside of the fixed position body. It also creates some pretty weird side effects because HTMLElement.offsetTop remains static so none of the smooth scrolling JavaScript libraries work, so I had to role my own with a scrollToTop method.[2] I think it is because HTMLElement.offsetTop is computed relative to the parent which is fixed.

When it comes to scrolling two images they are jigging because the browser is handling the repainting instead of passing it off to the graphics card or chip. The only way to have smooth scrolling is to use translateX or translateY.

(Note: I don't know what I'm talking about and honest I just don't care.)

[1] https://github.com/adam-s/playboy-fm/blob/master/client/sass...

[2] https://github.com/adam-s/playboy-fm/blob/master/client/publ...

Ionic has done a good job of implementing standard UI idioms atop Phonegap.

Agreed, they've done a really great job and pushed it to the limits. Unfortunately they do not have support for even simple gestures, so the parent comment still applies -- afaict it's not possible with WebViews currently.

JavaScript lets you listen for multi touch events just fine with touch starts, ends, and moves, and lets you keep track of each finger separately. What gestures would it not be possible to implement with that?

The browser has a bunch of behaviors that get in the way. The Ionic team could speak better to what is preventing them from implementing these gestures, or you could browse their issues to get an idea too: https://github.com/driftyco/ionic/issues?utf8=%E2%9C%93&q=ge...

Here's the correct search link, which gives better understanding: https://github.com/driftyco/ionic/issues?utf8=%E2%9C%93&q=is...

10 open, 40 closed issues related to gestures in v2. It has not yet reached release stage, but already good enough to start the development of the new apps.

Do they have a ViewPager? A DrawerLayout? Swipable rows in lists (eg: to delete an item)?

Also v2 is not the best thing to point to because it's very new and I don't think many people are using it compared with v1. And closed issues don't necessarily mean fixed, eg: https://github.com/driftyco/ionic/issues/9052 -- I believe all WebView based apps suffer from the problem described in this issue.

ViewPager: if I understand it correctly, yes: https://ionicframework.com/docs/v2/components/#slides DrawerLayout: yes https://ionicframework.com/docs/v2/components/#menus Swipable rows - yes: https://ionicframework.com/docs/v2/components/#sliding-list

Every new technology is used initially by less people than something older. It does not say anything about it.

Regarding the issue you've mentioned, I think it can be fixed by HTML/CSS means.

Check out Framework7:

https://framework7.io

Reply on news.ycombinator.com