Skip to main content

Best practice discussion: When to favor a webview over a native UI in titanium?



I'm currently working on a cross-platform mobile app and have gone through the process of creating the UI of my application using the given Titanium api.





Compared to when you are building a mobile web application this is a time consuming task, because you don't have the possibility to work on the rendered UI like you can on a rendered webpage using firebug.





Especially form creation is bothersome, so I decided to build my forms using html and render them in a Webview, which worked out pretty sweet for several reasons:









  • WebViews are automatically scrollable, so the soft keyboard won't cover the input fields in your HTML form









  • You can control which keyboard type is displayed with a WebView form by setting attributes on the <input> tag.









  • You can use JavaScript libraries to add form validation, field highlighting, and so forth to an HTML form.









Although this works like a charm and the titanium documentation encourages you to use webviews for building forms, I have mixed feelings about having mixed native UIs with webviews.





My questions to you:









  • What do you think of mixing native UIs with Webviews?









  • Do you have other use cases that favor a Webview?









  • What could be general criteria for using one or the other?









Thank you in advance :)


Comments

  1. What do you think of mixing native UIs with Webviews?

    The real question would be : Do you care about the user experience ? If yes, then go exclusively Titanium/Native. Sometimes, you need to use the Webviews to get around some problems (I had one year ago) : I remember I couldn't open online PDF files with Titanium : As Android platforms didn't open the PDF "natively" (Now you can), you had to pass the pdf's path to a Webview. That was the only time I was forced to pop up a WebView.

    Do you have other use cases that favor a Webview?

    If you are you talking about frameworks that base the rendering on Webviews then :
    If you have a client who owns a full static website and tell you to turn it into a mobile application It could be useful. Or, If you aim many platforms (more than Titanium does), you can use frameworks such as PhoneGap that will allow you creating WP7/iPhone/Android/BlackBerry apps.

    What could be general criteria for using one or the other?

    Which platform are you aiming ? As I said, Titanium won't allow you exporting your app for the WP7 platform.
    Then, if you need better performances, then go for Titanium/Native apps.
    On the other hand, if you want to reuse your code, think PhoneGap.

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex