How to build hybrid mobile apps combining native UI components with HTML5 | Hacker News Reader

How to build hybrid mobile apps combining native UI components with HTML5

trigger.io

24 pointsamirnathoo7 comments

The point has to do with how the web browser renders a page on the phone. It is rendered virtually and then only the part that needs to be on the screen is sent to the graphics pipeline. The rest is thrown away until you scroll and them the new view is rendered. If you go to a long web page you can see this. Scroll really quickly and you will see squares. As a result, fixed footers were and are a mess. The engine isn't smart enough to know some thing isn't a fixed element because all it is getting is pixels. As a result you would get bouncy fixed elements. Jqmobile tried to fix this by making the footer fade on touch and the reappear on scroll. The effect pissed my customers off. And me. They have 'fixed' it in 1.1 but I'm having trouble getting things to render correctly. I haven't poured a ton of time into it, but the fix wasn't plug and play. This is a nice solution and one I want to check out. I wonder if it plays nicely with Phonegap.

Can you actually add buttons to the top bar, though? When I was making an HTML5/Native hybrid app with Titanium I came up against that a lot - when you're not using iOS native TabbedGroups (or whatever they were called) even getting a simple back button was incredibly difficult.

Yes, there's a JS API forge.topbar.addButton for example: http://docs.trigger.io/en/v1.3/modules/topbar.html#addbutton

Easiest to just specify text and use the standard button appearance, but you can also choose a specific image. You assign a callback function for when it's clicked.

Can you get it to animate the way that native views do when going back and forward (the title text moving and fading horizontally, etc.)?

It's a small thing but I kept noticing it. I ended up making an iOS-style header bar in HTML, though I'll openly admit that it's not the greatest solution.

What's the point? The two example native components don't seem to do anything that HTML5 can't do just as easily/effectively. Do they somehow get you better performance/responsiveness on Android/iOS by not going through the browser stack?

The point is to get better results for the same effort.

Instead of having to spend time styling the top bar and tab bar to look native, and battling with fixed positions and mobile browser inconsistencies, you just drop a line into your config.

Many people seem to think fixed position elements and dealing with scrolling in mobile web views is a pain: http://bradfrostweb.com/blog/mobile/fixed-position/ http://www.kylejlarson.com/blog/2011/fixed-elements-and-scro... http://blog.millermedeiros.com/ipad-is-the-new-ie6/

nice! Took me fifteen minutes to build a native tabbar on an html5 app. And the tabbar's not laggy like jQuery mobile :-P

Reply on news.ycombinator.com