Opening a second UIWebView Page

[JL]

I've looked through the forums and I have seen the same question asked
many different ways but I have not seen an answer. Instead of opening
a page within the same UIWebview I want to open another page in
another UIWebview control and then move between the two. Is this
possible in PhoneGap ? If so how is it achieved. If I have to start
building this out manually it will probably be easier to write the
code from scratch. I was hoping this type of basic functionality would
be part of the phonegap framework.

[Brian LeRoux]

Hi JL --- this is possible but we're trying to understand exactly what
problem you are trying to solve (not what solution you propose). Could
you give us some more detail about what precisely you need to achieve
from an end user perspective?

[JL]

Well, I did not think I had proposed a solution......

The use case is reasonably straight forward. I want to be able to use
the UIWebView's capability to display documents, and once the user has
finished reading the document I want a button to be able to move back
to the main app.

On Feb 9, 9:06 pm, Brian LeRoux <brian.ler...@nitobi.com> wrote:
> Hi JL --- this is possible but we're trying to understand exactly what
> problem you are trying to solve (not what solution you propose). Could
> you give us some more detail about what precisely you need to achieve
> from an end user perspective?
>

[Hubert Łępicki]

Yup, this is what I was looking for some time ago and didn't get any
good answer till now :(.

2009/2/10 JL <liddl...@googlemail.com>:

--
Pozdrawiam,
Hubert Łępicki
-----------------------------------------------
[ http://hubertlepicki.com ]

[JL]

well I don't think we have an answer yet ;-)

On Feb 10, 3:21 pm, Hubert Łępicki <hubert.lepi...@gmail.com> wrote:
> Yup, this is what I was looking for some time ago and didn't get any
> good answer till now :(.
>

> 2009/2/10 JL <liddleja...@googlemail.com>:

[Brian LeRoux]

Sorry but I do not understand what the second window is for -- you can
use the current webuiview to display documents.

[kazoomer]

JL,

I think the biggest reason we haven't added this feature is because
there is a lot of overhead in creating a second UIWebView in memory.
Building the bridge to communicate between the two views would be
quite tricky and force the developer into Object-C land.

This solution wouldn't transfer well onto other devices/platforms.

Rob Ellis
Phonegap.com
Nitobi.com

On Feb 10, 9:37 am, Brian LeRoux <brian.ler...@nitobi.com> wrote:
> Sorry but I do not understand what the second window is for -- you can
> use the current webuiview to display documents.
>

[Alberto]

Would be possible just to load a second html in the same UIWebView and
later come back to the first?
That was an old request I really need for my app.

> > >> [http://hubertlepicki.com]- Hide quoted text -
>
> - Show quoted text -

[Hubert Łępicki]

Me too,

just need to open second page in the same web view by clicking a link
- so that it doesn't open new window.

H.

[kazoomer]

This is very possible.
Either a link to a second page will work <a href="page2.html">New
Page</a>
Or though some container div with an XHR call. x$('container').xhr
('page2.html'); // XUI example

Hope that helps.

Rob Ellis
Phonegap.com
Nitobi.com

[Chris D]

I too have this problem when opening another page with a link.
On the iPhone it quits the web app and tries to open the page in
safari.
On android its fine and stays within the web app.

[kazoomer]

Chris

This is not expected behavior, I will look into it.

Rob Ellis
Phonegap.com
Nitobi.com

[Alberto]

When you do a window.location="newpage.html"; it alerts Phonegap not
supported. But all the js included.
Even when you link one page to itself.

[Kris Ziel]

Is there any way to implement TabViewController into this so that
clicking on a different tab will open a different URL in the existing
UIWebView or in a different one?

[davidroe]

I just happened to see whether this was possible - initial results
look like it might work.

create n dummy views, add to the tabBarController viewControllers, add
the tabBarController view instead of the viewController view, trap
didSelectViewController, add webView to selectedViewController, send a
javascript string to switch the page.

HTH,
/dave

[Kris Ziel]

I have never programmed on Objective C, so I have no idea to do
anything. If you could post the code to do that it would be wonderful.

[davidroe]

I have also never programmed in Objective-C, so I don't want to imply
that this is the right way of doing it.

in appDelegate.m, applicationDidFinishLauching:

tabBarController = [[UITabBarController alloc] init];

view1Controller = [[UIViewController alloc] init];
[view1Controller setTitle:@"view1"];

view2Controller = [[UIViewController alloc] init];
[view2Controller setTitle:@"view2"];

tabBarController.viewControllers = [NSArray
arrayWithObjects:view1Controller, view2Controller, nil];
tabBarController.delegate = self;

[window addSubview:tabBarController.view];

and later

- (void) tabBarController:(UITabBarController *)tabBarController
didSelectViewController:(UIViewController *)selectedViewController
{
NSLog(@"tabbar: selected view");
/* if (webView.superview != nil) {
NSLog(@"tabbar: webview already attached");
[webView removeFromSuperview];
} */

NSString * jsCallBack = [NSString stringWithFormat:@"jsSwitchView
('%@');", selectedViewController.title];
[webView stringByEvaluatingJavaScriptFromString:jsCallBack];

[selectedViewController.view addSubview:webView];
}

/dave

[Kris Ziel]

Do you happen to have an app that uses this? If so it would be great
if you could send me a ZIP file of it. I can't seem to get this
working. I have played around with it a little bit, but have not had
any success in getting to to run without errors.

[davidroe]

sorry, I don't have anything that I can share publicly. keep trying
and good luck.

[editman]

Is anyone else working on this?

I've been thinking about creating multiple uiwebviews inside of the
view controllers for each individual tab. Yes, there is some
additional memory overhead, but my initial tests haven't suffered
much ... and in fact the huge performance boost of not having to load
the different pages when specific tabs are selected is very much worth
the extra memory usage.

My main problem is that I did this in a separate project outside
phonegap, and I'm finding that integrating these concepts into the
phonegap project to be quite challenging ... especially without huge
modifications. And if this isn't a feature that other people want,
and is therefore never integrated into the codebase, I would be left
with the very painful chore of managing code merges manually.

Is this something that other people want too, or is it just me?

[marc.b...@googlemail.com]

Hi,
this sound intresting!

I would like to get a tabbar with multible webviews.
Did you already got that feature in a phonegap project?

[editman]

I haven't yet integrated it with PhoneGap ... I'm not sure the best
way to get all the logic in the AppDelegate to work across multiple
tabviewcontrollers each containing a UIWebView. I just built a plain
project from scratch that had four tabs on a TabController, dropped a
UIWebView on each tab, and then set each to load a different page on
start.

Bottom line, I've built a POC to show that it's possible, but I'm not
sure how to integrate it into PhoneGap

On Mar 2, 8:12 am, "marc.bende...@googlemail.com"

[Paul Prescod]

On Sun, Mar 1, 2009 at 5:11 PM, editman <nate...@gmail.com> wrote:
>

> I've been thinking about creating multiple uiwebviews inside of the
> view controllers for each individual tab.  Yes, there is some
> additional memory overhead, but my initial tests haven't suffered
> much ... and in fact the huge performance boost of not having to load
> the different pages when specific tabs are selected is very much worth
> the extra memory usage.

Aren't there more web-oriented ways of keeping multiple pages in
memory at once? Hidden DIV stuff? That's how IUI works for example.

> ...

> Is this something that other people want too, or is it just me?

I've never understood myself exactly what people are aiming to
achieve. If it is just pre-caching of pages, then maybe hidden DIV
tricks could be incorporated into xui or magic framework. One benefit
of doing it that way is that your application state can be stored in
Javascript global variables.

Paul Prescod

[editman]

The goal is simply to accelerate the development of native
applications, and to make web apps virtually indistinguishable from
truly native apps. The best design for many native apps includes a
tab bar to streamline navigation.

Of course we use divs to have many pages loaded at once, but there are
hard limits to that, and even though we can certainly async load more
divs, there are often clear separation of functions across tabs.
Having seperate UIWebViews has the added benefit of increased
performance switching across tabs, and not losing position or data
within the tab.

I'm also working on a framework to intercept specific navigation
events, cancel them within that particular UIWebBiew, expose the
UINavigationBarController to dynamical deep copy the UIWebView and
UIViewController, add it to an array for history, and push the new
WebView and VC to the top of the stack. Add in dynamic tab bar
creation (which I've also implemented in a POC), and you can
essentially develop web apps which are virtually indistinguishable
from native apps, because they dynamically use the native controls for
high-performance navigation. Once you can do that, it changes the
whole game ... development lifecycle, version management, not to
mention the added productivity benefits of working in mature languages
with enormous adoption and user community instead of Obj-C.

On Mar 2, 12:42 pm, Paul Prescod <pres...@gmail.com> wrote:

[davidroe]

have you benchmarked the difference in startup time when creating
multiple UIWebView controls vs 1? is it a 1 to 1 ratio?

[editman]

It depends if you're opening up multiple seperate instances of the
UIWebView, or if you're taking an instance that is already loaded, and
already contains data, and making a deep copy of that.

I didn't benchmark it, but it is a lot faster to make a copy of a
UIWebView that already has all of the divs loaded, display the right
div, and push that to the top of the controller than to initialize a
UIWebView from scratch and load the data (a huge part of that is the
latency of actually loading the site into the UIWebView).

[Paul Prescod]

On Mon, Mar 2, 2009 at 1:49 PM, editman <nate...@gmail.com> wrote:
>
> The goal is simply to accelerate the development of native
> applications, and to make web apps virtually indistinguishable from
> truly native apps.  The best design for many native apps includes a
> tab bar to streamline navigation.

Sure, I agree. I wasn't asking "why do you want apps that look like
native apps" but rather "what limitations of HTML/Javasript prevent
you from using HTML/Javascript techniques to achieve that goal." I'm
going down the same path so I'm trying to learn from your experience.
I have heard mixed messages about whether it is effective to emulate
the native navigation controls in HTML/Javascript.

> Of course we use divs to have many pages loaded at once, but there are
> hard limits to that, and even though we can certainly async load more
> divs, there are often clear separation of functions across tabs.

Can you talk a bit more about the hard limits and performance
problems? Do you find that there is a noticeable lag when you hide and
show DIVs corresponding to tabs?

> ...  Add in dynamic tab bar

> creation (which I've also implemented in a POC), and you can
> essentially develop web apps which are virtually indistinguishable
> from native apps, because they dynamically use the native controls for

> high-performance navigation.  ...

We all agree with the overall goal. My understanding was that it is
*already* possible to make apps that are virtually indistinguishable
from native apps. So I'm trying to clarify the limitations of the
current Phonegap/HTML/Javascript platform. Am I going to have to
develop a native component-based framework like yours to get native
seeming behaviour or do I just need more sophisticated HTML/Javascript
tricks?

Also, when you have multiple UIWebViews, how are you communicating
application state between them?

Paul Prescod

[editman]

I'm not sure we're all clear on the same goal. From reading a lot on
this forum, there is a balance between building a cross platform
framework, and enhancing the product to improve the iPhone-specific
experience.

The current limitations of purely web-based apps are: (although these
are being worked on, and I have no doubt will eventually be
eliminated).
- the iPhone's 300 millisecond delay between ontouchup event and the
onclick event to support gestures. By overriding onclick and watching
for ontouch, you break cross-platform compatibility.
- robustly managing static header and footer visual objects (whether
they are the nav bar, tab bar, or tool bar). This can be done, and
has been done in a number of POCs, but it either breaks the current
frameworks like iUI or suffers from other performance degradation.
- Opening external web sites from within your web app. Many web sites
will break your iWebApp if you load them in an iframe or
xmlhttprequest, and even if you do manage to load them, you have no
way to navigate back into your application when you're using a native
wrapper like PhoneGap (using safari, you obviously have the back
button).

There are a few other minor annoyances in simulating native apps with
web apps, but these three are deal breakers. And I say that because
I'm with an iPhone custom development shop with 15 or so developers,
and these are the roadblocks that we are currently running into with
building apps in this framework. Our clients, and their customers
obviously need native apps for certain types of apps, like games and
very heavy processing intensive. Many of the apps we have/are/will
develop are data driven apps that could be developed in a web app
architecture if these three issues were resolved. And honestly, our
clients wouldn't even be able to tell the difference ... but until we
can resolve these issues we can't use this architecture for the
majority of our projects.

On Mar 2, 4:08 pm, Paul Prescod <pres...@gmail.com> wrote:

[marc.b...@googlemail.com]

Well, why we want such a stuff, it´s because we are at the moment not
able to develop fully native apps...
In the near future we will do... ok, but take a look at www.motherapp.com
They made a framework with that you can write HTML-Code and that
framwork will convert it to native code (apps).

But I would like to use phonegap, I find it very good and the
integration of cam / pictures / acceleration / location is right that
what I want...
I think, using tabbars with multible webviews could be the solution
for speedup....

[editman]

Yes, that is a difference. I have a whole team of native iPhone
developers, but I'm sick and tired of how long it takes to build
native apps, the amount of overhead managing versions/deployment/
roadmap, not to mention the control that Apple enforces.

I'm not looking to this framework as a "shortcut" to iPhone
development - we're already there. I'm looking to "accelerate" iPhone
development by being able to build "native" apps on PCs and in robust
languages like Java and .NET, and not requiring developers to suffer
through weeks of digging through code to find memory leaks in a data-
driven, web service-consuming application that takes 3x longer to
develop in low-level Obj-C than it does on more mature platforms.

On Mar 2, 4:32 pm, "marc.bende...@googlemail.com"

[Brock Whitten]

These are all very good arguments. There is really only one problem. Our goal is to use existing open technologies to build mobile applications.

If you can suggest a way to add to make this an opt-in feature Im all for it. I have a hard time seeing how we can implement this without limiting the developer to a certain structure. 

Just to be clear, we dont mind if some phonegap features are iphone/android/BB specific. We just dont want to make phonegap an iphone only tool. we are open to the idea as long as it does not interfere with our cross platform goals.

-brock

[editman]

The more that I think about this, I'm positive that native navigation
can be accomplished without breaking cross platform compatibility.

Take the tab bar ... add a style settings property as well as a
dictionary to the Settings.plist with the title, icon, and start url
for each tab. Each tab controller would contain it's own unique
UIWebView instance, and communication between the UIWebViews would
have to be implemented on the back-end application.

Take the tool bar ... follow the example of the current fork that
implements this. The toolbar has a different paradigm than the tab
bar, in that it doesn't require different ViewControllers, so each
button on the toolbar would simple execute a specific command (url to
navigate to or JS command) when selected.

Take the navigation bar ... add a property in Settings.plist to enable
the feature, as well as configure style, and optionally a dictionary
with button items that follows the same convention as the tool bar
syntax mentioned about. When the setting is enabled, just intercept
all navigation requests (or navigation requests with a specific
PhoneGap URI syntax), stop them from executing the current navigation
request, make a deep copy of the UIWebView (so that the copy contains
all of the data already loaded within the current instance of the
UIWebView, without modifying the state) and the ViewController, add
them to a history array, and push it onto the UINavigationController.
Again, I do not believe that there is any need to facilitate cross
communication between the different UIWebViews. That would be the
responsibility of the web app itself. If the user goes "back" onto a
previous UIWebView, a javascript callback could be sent telling the
view that it is back in focus, which could refresh data from the
server or local SQLlite database if necessary.

This could be implemented, just like this, and apps would still run on
Android, or Pre, or whatever ... they wouldn't have the toolbar/tabbar
functionality, but the look and feel could be essentially the same,
because the intent of our webapp framework would simply be to hide the
JS/CSS versions of the navigation bar header, etc if it detects the
native capability to render these control.

On Mar 3, 1:14 am, Brock Whitten <brock.whit...@nitobi.com> wrote:
> These are all very good arguments. There is really only one problem. Our
> goal is to use existing open technologies to build mobile applications.
> If you can suggest a way to add to make this an opt-in feature Im all for
> it. I have a hard time seeing how we can implement this without limiting the
> developer to a certain structure.
>
> Just to be clear, we dont mind if some phonegap features are
> iphone/android/BB specific. We just dont want to make phonegap an iphone
> only tool. we are open to the idea as long as it does not interfere with our
> cross platform goals.
>
> -brock
>

[marc.b...@googlemail.com]

Exactly like that! I could not better describe it!

[davidroe]

my preference would be for a single UIWebView but I see that this will
not be the best situation for everyone. I am looking at a single large
Javascript application, and there is definitely a large overhead when
loading the same app with different entry points in different
UIWebView controls.

I also have a bad feeling about cloning UIWebViews and having a
situation where my original UIWebView holds a stale copy of
application state. the drawbacks easily outweigh the benefits here.
what do you want out of navigation that you can't already achieve
using HTML/CSS/JS?

PhoneGap is, needless to say, in its infancy and has a long road
ahead. nevertheless, the code is already in a place where you, the
developer, can tinker, tweak and improve upon the fundamentals. I
suggest you throw together a prototype to see exactly what is possible
and what problems it turns up.

/dave

[Paul Prescod]

On Tue, Mar 3, 2009 at 10:42 AM, davidroe <roe....@gmail.com> wrote:
>
> my preference would be for a single UIWebView but I see that this will
> not be the best situation for everyone. I am looking at a single large
> Javascript application, and there is definitely a large overhead when
> loading the same app with different entry points in different
> UIWebView controls.
>
> I also have a bad feeling about cloning UIWebViews and having a
> situation where my original UIWebView holds a stale copy of
> application state. the drawbacks easily outweigh the benefits here.
> what do you want out of navigation that you can't already achieve
> using HTML/CSS/JS?

I feel like different solutions to different problems may be
appropriate. If Brian still believes that one can make a basic tabbar
that feels 100% native then I'd like to see that and would prefer
that to a platform-specific solution that loads multiple instances of
the Javascript app. The techniques would certainly be useful for other
kinds of headers and footers.

On the other hand, it seems unlikely that there is any pure-web
solution to the problem that mobile webkit does weird things with
iFrames. So working around that will probably take some objective-C
coding. :( David, if you have an HTML/CSS/JS solution then please
share it.

Here's the description of the problem:

http://groups.google.com/group/phonegap/browse_thread/thread/5b3be67faa955d4c/b4c2bf0c5896e72d?lnk=gst&q=rss#b4c2bf0c5896e72d

"Multiple UIWebViews" is a solution can solve several problems. Some
may have other solutions (which should also be explored) and some
probably do not.

Paul Prescod

[Brock Whitten]

If Brian still believes that one can make a basic tabbar that feels 100% I'd like to see that...

IMHO this is the wrong way to look at it. Does gmail look 100% like a native email client on OSX or Windows? NO! who fucking cares. Gmail still has fantastic usability and so can a phonegap application. That said, people seem to be having a hard with building good user experiences so I have created a repo for phonegap examples.

http://github.com/sintaxi/phonegap-examples/tree/master

The first example (address-list) is based on some great work that I found on cubiq.org. It has a fixed header and footer. check it out. Will it convince you that it its 100% native? I expect not. my response to that is, it shouldn't matter :)

-brock

[Nathan Clevenger]

> what do you want out of navigation that you can't already achieve
> using HTML/CSS/JS?

For starters, there is no way around the problem of launching another
web site without killing the application. As I articulated I
hopefully quite clearly in a very specific example above, the
resulting usability is a fundamental deal killer.

Secondly, there is a fundamental issue with the way that Safari fires
the "onclick" event. There is a 300ms delay from the point of
"ontouchend" until the "onclick" event has fired. And once you start
writing for ontouchevents in your javascript code, you either break
cross platform compatibility or start doing browser detection and
using different JS code for different platforms which also goes
fundamentally against your core value proposition.

Third, while I'm sure that someone will eventually implement it, there
currently is not a robust framework that supports static headers and
footers while simulating a native iPhone experience. Having those UI
elements is fundamentally necessary in maximizing the usability of
certain applications.

Fourth, we simply need better overall application performance. My
firm has developed dozens of native iPhone apps, both in the app store
as well as for internal enterprise deployments. Due to the shear cost
and overhead of developing in low-level languages like Obj-C, I have
been aggressively pushing as many of the new projects we are kicking
off to at least explore a web app (or offline web app) architecture.
We've implemented about half a dozen native wrapped web apps for the
iPhone, and while we have been able to get the experience VERY CLOSE
to the iPhone, and generally have satisfied customers on those
projects, we still get feedback that something is slow, sluggish, or
just not quite right.

Finally, I need a native experience. Not a native-like experience,
but a truly native experience. I don't care if you can achieve the
same results with a very slightly different experience, if my customer
who is paying 5 or 6 figures for an iPhone app doesn't like the
experience we can provide with this architecture, then quite simply we
just have to deliver it by writing a boatload of Obj-C.

Again, and I'll say it again, it's not a question of whether this will
be built. The only question is whether PhoneGap will be the project
that it is based on or not. I would certainly prefer it to be
incorporated into PhoneGap, but if you guys don't want to go this
direction then my team will have to go in a different direction.

[davidroe]

> if you have an HTML/CSS/JS solution then please
share it.

I was thinking of MagicFramework - it does a great job wrapping the
CSS transforms and stacking your panel history.

[Nathan Clevenger]

> IMHO this is the wrong way to look at it. Does gmail look 100% like a native
> email client on OSX or Windows? NO! who fucking cares.

My clients do. And they do, because their customers do.

> Gmail still has
> fantastic usability and so can a phonegap application. That said, people
> seem to be having a hard with building good user experiences so I have
> created a repo for phonegap examples.

You're preaching the choir. You do not need to convince me that web-
based apps can have incredible user experiences. I know that. But it
doesn't matter to my clients who are paying big bucks for native
iPhone application development. If I can't give them an experience
that is indistinguishable from a truly native app, then I must
continue developing truly native apps in Obj-C.

> The first example (address-list) is based on some great work that I found on
> cubiq.org. It has a fixed header and footer. check it out. Will it convince
> you that it its 100% native? I expect not. my response to that is, it
> shouldn't matter :)

It shouldn't matter. You know that, and I know that. But
unfortunately is does matter. And since the solution is a few hundred
lines of Obj-C code, there is no reason not to do it. Especially when
we're churning out thousands of lines of Obj-C code every week for
many other apps that could easily be developed in Java or .NET in half
the time if we had a framework to give web apps access to truly native
UI navigation components.

Again, the only question is whether PhoneGap is the right project to
incorporate it.

On Mar 3, 3:33 pm, Brock Whitten <brock.whit...@nitobi.com> wrote:
> > If Brian still believes that one can make a basic tabbar that feels 100% I'd
> > like to see that...
>
> IMHO this is the wrong way to look at it. Does gmail look 100% like a native
> email client on OSX or Windows? NO! who fucking cares. Gmail still has
> fantastic usability and so can a phonegap application. That said, people
> seem to be having a hard with building good user experiences so I have
> created a repo for phonegap examples.
>
> http://github.com/sintaxi/phonegap-examples/tree/master
>
> The first example (address-list) is based on some great work that I found on
> cubiq.org. It has a fixed header and footer. check it out. Will it convince
> you that it its 100% native? I expect not. my response to that is, it
> shouldn't matter :)
>
> -brock
>

> On Tue, Mar 3, 2009 at 10:53 AM, Paul Prescod <pres...@gmail.com> wrote:

>
> > On Tue, Mar 3, 2009 at 10:42 AM, davidroe <roe.da...@gmail.com> wrote:
>
> > > my preference would be for a single UIWebView but I see that this will
> > > not be the best situation for everyone. I am looking at a single large
> > > Javascript application, and there is definitely a large overhead when
> > > loading the same app with different entry points in different
> > > UIWebView controls.
>
> > > I also have a bad feeling about cloning UIWebViews and having a
> > > situation where my original UIWebView holds a stale copy of
> > > application state. the drawbacks easily outweigh the benefits here.
> > > what do you want out of navigation that you can't already achieve
> > > using HTML/CSS/JS?
>
> > I feel like different solutions to different problems may be
> > appropriate. If Brian still believes that one can make a basic tabbar
> > that feels 100% native then  I'd like to see that and would prefer
> > that to a platform-specific solution that loads multiple instances of
> > the Javascript app. The techniques would certainly be useful for other
> > kinds of headers and footers.
>
> > On the other hand, it seems unlikely that there is any pure-web
> > solution to the problem that mobile webkit does weird things with
> > iFrames. So working around that will probably take some objective-C
> > coding. :( David, if you have an HTML/CSS/JS solution then please
> > share it.
>
> > Here's the description of the problem:
>

> >http://groups.google.com/group/phonegap/browse_thread/thread/5b3be67f...

[Brock Whitten]

Finally, I need a native experience.  Not a native-like experience

WTF dude? Apple has provided a SDK to do achieve this. At six figures, it seems like your customers are paying for a native experience so why not give it to them. Perhaps you can get them to pay you another six figures for building the android version.

Again, and I'll say it again, it's not a question of whether this will be built.  The only question is whether PhoneGap will be the project that it is based on or not.

Do it! We would be stoked to see this in action. We are open to adding this to phonegap. It just seems to me like you are asking us to implement it for you (and your six figure client). How could we effectively add this feature when we do not currently see the value of it. If you are passionate about it, write it. Are you not interested in making this contribution to phonegap? do you really need us to blindly commit to supporting it before we see how it works? Am I missing something?

Forgive me if Im starting to sound like a dick but this thread is starting to feel counter productive. We have looked at EVERY pull request that has ever been submitted to PhoneGap and I promise we will look at yours and give it serious consideration for acceptance. Currently we are talking about hypothetical code. 

-brock

[Paul Prescod]

Thanks for setting up the examples directory. It has already been helpful to me.

On Tue, Mar 3, 2009 at 1:33 PM, Brock Whitten <brock....@nitobi.com> wrote:
>
>> If Brian still believes that one can make a basic tabbar that feels
>> 100% I'd like to see that...
>
> IMHO this is the wrong way to look at it. Does gmail look 100% like a native
> email client on OSX or Windows? NO! who fucking cares.

I would say that gmail gets a pass because it offers extra features to
the end-user. Not the developer. The end-user. If I could say that my
PhoneGap app did X or Y that an Objective-C app did not then my
end-users would overlook quirks. In fact, if I deliver a "native-like"
performance through Safari then I'll be a rock star. But if I put a
"native-like" app into the app store then people will complain that it
doesn't feel right. That's just how people are....once its in the app
store it isn't perceived as a web app. Look at the abuse Swing apps
have taken over the years. ;)

> http://github.com/sintaxi/phonegap-examples/tree/master
> The first example (address-list) is based on some great work that I found on
> cubiq.org. It has a fixed header and footer. check it out. Will it convince
> you that it its 100% native? I expect not. my response to that is, it
> shouldn't matter :)

As I said, that example is already very valuable to me, so thank you
for that. Actually, it feels damn close to a native app to me. There
is something buggy about the letters on the right side but that could
as easily be an Objective-C bug as a Javascript one.

Could I suggest that the examples be in a single "www" tree rather
than multiple? It's much easier to navigate around a single app with
multiple examples linked by hyperlinks than to build a bunch of
examples one at a time.

Paul Prescod

[Nathan Clevenger]

Brock - I apologize if my comments came off insincere, I was honestly
just trying to make the case for this architecture to see if you would
adopt it into PhoneGap. I'm also sorry if it came off like I was
asking you to do this work, that is not the case at all, and in fact
we are already working on it and have put together an internal POC for
one of our projects.

The primary reason I joined this discussion is to see if the idea of
implementing native iPhone navigation components meshes with your
vision for PhoneGap. Before we work to build all of this IP into the
PhoneGap framework, I want to know that it will be adopted, and based
on this and other discussions, I'm really not sure it would be. Most
telling, though, is the fact that Geri has already implemented a very
fundamental piece of native UI navigation components: the tool bar.
And while most of his other contributions have been merged with the
master, the tool bar has not, and from my reading of other posts on
this forum, there really isn't any intention to integrate his toolbar.

If you're serious about incorporating native UI components into
PhoneGap, please start by integrating the work that Geri has already
contributed. That sets a standard for how UI components should be
implemented, as well as how the settings should be designed to allow
configuration. And it also lets me know that the vision for PhoneGap
is aligned with what I'm trying to contribute.

Sincerely,
Nathan

On Mar 3, 5:54 pm, Brock Whitten <brock.whit...@nitobi.com> wrote:
> > Finally, I need a native experience.  Not a native-like experience
>
> WTF dude? Apple has provided a SDK to do achieve this. At six figures, it
> seems like your customers are paying for a native experience so why not give
> it to them. Perhaps you can get them to pay you another six figures for
> building the android version.
>
> Again, and I'll say it again, it's not a question of whether this will be
>
> > built.  The only question is whether PhoneGap will be the project that it is
> > based on or not.
>
> Do it! We would be stoked to see this in action. We are open to adding this
> to phonegap. It just seems to me like you are asking us to implement it for
> you (and your six figure client). How could we effectively add this feature
> when we do not currently see the value of it. If you are passionate about
> it, write it. Are you not interested in making this contribution to
> phonegap? do you really need us to blindly commit to supporting it before we
> see how it works? Am I missing something?
>
> Forgive me if Im starting to sound like a dick but this thread is starting
> to feel counter productive. We have looked at EVERY pull request that has
> ever been submitted to PhoneGap and I promise we will look at yours and give
> it serious consideration for acceptance. Currently we are talking about
> hypothetical code.
>
> -brock
>

[dave johnson]

Wow this thread is great. I already replied to a later thread espousing the idea of a platform agnostic HTML based approach but I am thinking more now about what could be achieved through a phonegap declarative layer ...

<div class="menu"><div>item 1</div><div>item 2</div></div> could be rendered natively in a platform specific way. I am going to try this on blackberry / android. I think the basic HTML / CSS implementation would be good but there might still be an argument for actually taking HTML markup (declared using classes) and render native controls based on it.

Could be interesting.

-dave

[Nathan Clevenger]

On further reflection, I really think the best way to solve this is to
split PhoneGap into two distinct entities - a PhoneGap Framework which
contains essentially a super-UIWebView class with all of the
incredible PhoneGap goodness, and a PhoneGap wrapper app that simply
implements a single instance of the PhoneGap class and exposes quick
configuration in icon, splash screen, and settings.

This way, developers can innovate on one of either two different
trajectories - building out the capabilities within the PhoneGap
framework, or implementing the PhoneGap class in more innovative ways
to improve the iPhone native experience (like navigation bars, tab
bars, tool bars, or multiple instances of the PhoneGap browser class).

Respectfully,
Nathan

On Mar 4, 2:03 am, dave johnson <dave.c.john...@gmail.com> wrote:
> Wow this thread is great. I already replied to a later thread espousing the
> idea of a platform agnostic HTML based approach but I am thinking more now
> about what could be achieved through a phonegap declarative layer ...
>
> <div class="menu"><div>item 1</div><div>item 2</div></div> could be rendered
> natively in a platform specific way. I am going to try this on blackberry /
> android. I think the basic HTML / CSS implementation would be good but there
> might still be an argument for actually taking HTML markup (declared using
> classes) and render native controls based on it.
>
> Could be interesting.
>
> -dave
>

[Paul Prescod]

I think that Nathan and Dave's suggestions are complimentary and
should probably be discussed in separate threads.

Nitobiers, what do you think about making phonegap's supercharged
uiwebview widget into a class that can be dropped into any iPhone
project?

###This message was lovingly handcrafted on a phone-like device###

[Brian LeRoux]

once again: we're adding a plugin capability to the project so that
this can be an optional extension

[Paul Prescod]

I think that these are all great ideas but I still think that Nathan's
deserves some discussion in its own right. Maybe I misunderstand
something important but it seems kind of obvious to me that it would
be cool for iPhone developers to be able to just drag a PhoneGapUI
into any project...it might vastly increase the user base of PhoneGap
on the iPhone at very low cost to those who want a full-featured
multi-platform app deployment framework.

If Nathan or someone on my team was willing to do the work is it
likely that the Nitobites would accept that patch?

[Brian LeRoux]

absolutely would love a patch. the idea is solid. enough said.

[Nathan Clevenger]

Awesome! Paul, I just started another thread where we can discuss
extensibility in detail. Let's figure out the best way to separate
the PhoneGap browser from the app as its own class, then we can
collaborate on refactoring it.

Thanks!
Nathan

On Mar 4, 1:02 pm, Brian LeRoux <brian.ler...@nitobi.com> wrote:
> absolutely would love a patch. the idea is solid. enough said.
>

> On Wed, Mar 4, 2009 at 10:44 AM, Paul Prescod <pres...@gmail.com> wrote:
>
> > I think that these are all great ideas but I still think that Nathan's
> > deserves some discussion in its own right. Maybe I misunderstand
> > something important but it seems kind of obvious to me that it would
> > be cool for iPhone developers to be able to just drag a PhoneGapUI
> > into any project...it might vastly increase the user base of PhoneGap
> > on the iPhone at very low cost to those who want a full-featured
> > multi-platform app deployment framework.
>
> > If Nathan or someone on my team was willing to do the work is it
> > likely that the Nitobites would accept that patch?
>

> > On Wed, Mar 4, 2009 at 9:59 AM, Brian LeRoux <brian.ler...@nitobi.com> wrote:
>
> >> once again: we're adding a plugin capability to the project so that
> >> this can be an optional extension
>

> ...
>
> read more »

[marc.b...@googlemail.com]

Looking good, but it is a toolbar NOT a tabbar!
Tabbars using a new view for each tab!

The toolbar from geri´s repository worked for me as well.


On 4 Mrz., 22:57, "Kyle.Balogh" <kyle.bal...@gmail.com> wrote:
> So I have been following this form for a couple days now...I decided
> to take Nathan's advice and looked into the work Geri has done
> (excellent work).  You can find his work athttp://github.com/Geri...
> For me, I was looking for native tabs to link to a couple different
> pages on my website to replace tabs on my webapp, similar to what Geri
> has in his setup.  The only issue for me was finding a way to link a
> full html link, not php.  I changed some things in this code to allow
> the webview url to be changed each time a tab was clicked...Values for
> this change are the similar to the initial Callback value (http://example.com
> ).  This allowed me to change the webview to the value associated with
> each tab.  As far as performance goes, each tab is loaded every time
> the tab is clicked ... but for me this is not a huge problem, because
> this was what happened without the native tabs (tabs through the web).
>
> In summary: One webview ... tabs linking to multiple html pages.
>
> Video:http://shindiggie.com/shindiggie.swf
>
> Let me know what you think...if you want I would be more than happy to
> submit the code on github (although I am not sure how I would go about
> doing that)...
>
> Kind Regards,
> Kyle

[Nathan Clevenger]

I get that you guys from Nitobi don't want to comment on the things
I've proposed until I show you the code, but can you tell us what
you're plans are for integrating Geri's toolbar contribution?

How the toolbar code is integrated into the master has an impact on
how the project should be split into the standalone class and wrapper.

On Mar 5, 2:10 am, "marc.bende...@googlemail.com"

[Brian LeRoux]

Our first plan is to make PhoneGap inherit from WebUIView making it a
class that could be embedded in a native app. Sometime in parrallel we
plan to build out an official approach to a plugin architecture. There
is no timeline for any of this of course because we're also looking at
getting android up to spec while continuing research into nokia and
windows mobile. Its a lot of work and do appreciate any help you can
give in the form of code.

[Brock Whitten]

Nathan, sorry for the late reply. I appreciate these Ideas and would like to explore them. I have been extremely sick the last two days so I have been laying low. I will checkout Geri's code (hopefully tonight) and let you know my thoughts (I encourage others to do this as well). I want to be clear, we are not opposed to these ideas. We just don't want to sacrifice the phonegap vision to achieve this. Not having to write Objective-C is only the short term benefit. The big picture is being a way to write cross platform apps using existing open web technologies.

I would agree/argue that the iphone at the moment is the only true important product but we dont want to build phonegap with the assumption that this will always be the case.

The ones of us that work at nitobi express our opinions with the interest of phonegap and its community in mind. In the long run this is what will benefit nitobi the most. I assure you those of us at nitobi do not agree on everything but in this case just happen to all see the same issues with supporting this feature. We all want phonegap to kick supreme ass.

Many of you feel this feature is important, so I personally will remain open to the idea. Im sure the others opposed to it will keep an open mind as well. Is there anything I need to know about Geri's branch befor I start to play with it?

Im starting to think that PhoneGap as a subclass of WebUIView is the answer. this would allow people to work with it in any way they want. But even this is just a thought at this point. Just as Brian says, all these are fantastic ideas but getting Android synced with the HTML5 API as has to be top priority right now. I could'nt agree with him more.

-brock

ps. I am sorry for being kurt earlier. your ideas are valuable to this project.

[dave johnson]

I like the sounds of that Paul. Might as well be a PhoneGap web view class on all the platforms.

-dave