Picture of embedded browser w/ header and footer

[Paul Prescod]

Attached.

[Nathan Clevenger]

If you look carefully at the Amazon app, you'll see that while the
tabbar and navigation bar are native, the screens themselves are
rendered in a UIWebView

On Mar 2, 7:02 pm, Paul Prescod <pres...@gmail.com> wrote:
> Attached.
>
>  photo.jpg
> 63KViewDownload

[Brian LeRoux]

Sure, headers and footers are a device agnostic idiom. Easily
achievable with html/css/js.... but what we're really talking about in
the earlier thread was the ability to navigate between multiple
stateful web pages?

I mean, if we were to implement header/footer type stuff where do we
stop? Icons only? Icons and centered text? Icons with text... or....
you get the idea. It is a slippery slope implementing a browser. What
about the approach of Palm Pre pages? Or, what about the left hand
side tab stack we see in Fennec? The mutliple pages in mobile safari?

See what I mean?

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

Right, it would be a little like doing a browser...
But it would be under our controll! :-)

Hey, phonegap is a great project and I'm so happy to be able with html/
css/javascript to use native iphone functions (cam/pictures etc...)

The thing what would let me produce apps in a way like a factory chain
would be the discussed controls.

I'm with you when you say that it should be as much crossplatform as
possible but the native controls would made phonegap to a like we say
in german
"EierlegendeWollMilchSau" what means => A combination of domestic
animals that produces eggs, wool, milk and can be grilled ;-)

You know what I mean?

On 3 Mrz., 08:14, Brian LeRoux <brian.ler...@nitobi.com> wrote:
> Sure, headers and footers are a device agnostic idiom. Easily
> achievable with html/css/js.... but what we're really talking about in
> the earlier thread was the ability to navigate between multiple
> stateful web pages?
>
> I mean, if we were to implement header/footer type stuff where do we
> stop? Icons only? Icons and centered text? Icons with text... or....
> you get the idea. It is a slippery slope implementing a browser. What
> about the approach of Palm Pre pages? Or, what about the left hand
> side tab stack we see in Fennec? The mutliple pages in mobile safari?
>
> See what I mean?
>

[Brian LeRoux]

check out these demos in phonegap:

http://cubiq.org

---- very much a native experience.

[Paul Prescod]

On Mon, Mar 2, 2009 at 11:14 PM, Brian LeRoux <brian....@nitobi.com> wrote:
>
> Sure, headers and footers are a device agnostic idiom. Easily
> achievable with html/css/js....

You say that this isn't just possible but rather that it is easy. If
it is easy, then please check in a demo. Please add a
standards-looking, non-scrolling header and footer to the top and
bottom of an otherwise scrolling page? It seems easier to show people
than to tell them that it can be done. Probably you have the code in
your head and just need to write it down rather than telling people
that it could exist...

Doesn't need to be part of XUI or anything formal. Just one HTML page
showing us how to do it. It may be easy for you but it is not easy for
the rest of us.

> ... but what we're really talking about in
> the earlier thread was the ability to navigate between multiple
> stateful web pages?

Stateful windows is a separate and unrelated requirement that happens
to also have a potentially shared solution of having multiple
UIWebView controls. The solution is potentially the same, but the
requirement is unrelated.

A third, unrelated requirement is to have a scrolling IFRAME with
intuitive controls hosting third-party content like a web page. The
solution to this problem might ALSO have the same technological basis,
but it need not, if there is a standards-based way of doing it.

> I mean, if we were to implement header/footer type stuff where do we
> stop? Icons only? Icons and centered text? Icons with text... or....
> you get the idea. It is a slippery slope implementing a browser.

I don't think that browser is the right word. It's a slippery slope to
implementing a more complicated and hard to use framework...it's still
a dev framework, not a browser.

> ... What

> about the approach of Palm Pre pages? Or, what about the left hand
> side tab stack we see in Fennec? The mutliple pages in mobile safari?

Those are browsers, not task-specific applications.

Here's another crazy thought: what would it take to make the iPhone
PhoneGap extensible so that people who wanted to add native features
to it could do so without forking or branching...I have no idea: I'm
just throwing it out as an idea. Like what if it could dynamically
load plugins at startup...Objective-C should be good at that kind of
thing.

Paul Prescod

[Brian LeRoux]

Plugins would be a great feature / nice way to support extension that
isn't core. Any ideas how we should implement such a scheme guys?

[Nathan Clevenger]

> Plugins would be a great feature / nice way to support extension that
> isn't core. Any ideas how we should implement such a scheme guys?

That's a very good point. What if the UIViewController, UIWebView,
and all of the core PhoneGap logic currently in the AppDelegate was
incorporated into a single self-contained class? The sample project
would implement just one instance of this, but it would allow other
developers to build their own "wrappers" around the "PhoneGap" class,
which could potentially be more of a UIPhoneGapWebView. Any unhandled
events called with the "gap://" uri schema could be raised as an event
within the class, so developers could implement their own custom logic
without having to manually merge code with the updates from the master
code base.

To be honest, the more that I think about it, the PhoneGap browser as
a class, as opposed to a complete project, would be incredibly
powerful and flexible, because it could mature on its own trajectory
without interfering with the native development aspects of projects
which may want to use it.

This way, developers of native apps could even use PhoneGap for a part
of their application, which is something that I've been trying to
figure out how it could be done. For instance, an app could have 4
tabs where two of the tabs contain completely native Obj-C code, and
other other two tabs contain an instance of the PhoneGap browser. It
would all be up to the developer!

On Mar 3, 2:39 pm, Brian LeRoux <brian.ler...@nitobi.com> wrote:
> Plugins would be a great feature / nice way to support extension that
> isn't core. Any ideas how we should implement such a scheme guys?
>

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

[Nathan Clevenger]

I slept on it, and I really think that the best way to do this would
be to simply split the "PhoneGap" iPhone project into two:
- a PhoneGap Framework which is essentially a "super-UIWebView"
- a PhoneGap Sample iPhone App that contains a single instance of the
PhoneGap Framework, and the settings to configure that instance

With that abstraction in place, development can continue on two
separate trajectories without interfering. My focus would be on
building more robust native apps that consume the PhoneGap framework
to enable things like native NavigationBars, TabBars, and ToolBars, as
well as multiple instances of the PhoneGap "super-UIWebView."
Development can still continue on building out the PhoneGap framework,
and adding more APIs ... but developers wouldn't be limited either,
because the PhoneGap framework could also just raise events for any
unhandled calls, so that the consuming application can handle them.
This would expose a direct communication channel between JavaScript
running within the PhoneGapWebView, and the wrapping application ...
which could also choose to handle synchronization of data between
PhoneGapWebView instances, if anyone wanted to take on that challenge.

This comes down to simple object-oriented design principles - there
really are two distinct entities within PhoneGap, and leaving them
joined is severely stifling innovation.

Respectfully,
Nathan

On Mar 3, 2:39 pm, Brian LeRoux <brian.ler...@nitobi.com> wrote:

> Plugins would be a great feature / nice way to support extension that
> isn't core. Any ideas how we should implement such a scheme guys?
>

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

[Brian LeRoux]

eh Nathan I tend to agree but so you are aware we're experimenting w/
a plugin architecture so that this sort of thing can an optional be a
drop in capability for the current project

[Nathan Clevenger]

How would you structure the plug-in architecture? Could plug-ins be
created that would implement native navigation across multiple
instances of a browser class, or could plug-ins only be created to
expand the "PhoneGap API" between JavaScript and Obj-C?

Even if there is a plug-in architecture, why couldn't the PhoneGap
browser by a class by itself, so that it can be embedded within native
applications wherever the developer sees fit.

On Mar 4, 11:59 am, Brian LeRoux <brian.ler...@nitobi.com> wrote:
> eh Nathan I tend to agree but so you are aware we're experimenting w/
> a plugin architecture so that this sort of thing can an optional be a
> drop in capability for the current project
>

[Brian LeRoux]

Sure, PhoneGap can be a class unto itself. Love that idea.

Plug ins will take advantage of the dynamic nature of obj-c allowing
for any sort of customization of the PhoneGapUIView (or whatever we'll
call it). Make sense? We're still experimenting here.

Any code you'd like to contribute is welcome of course. Patches > Talking

[Nathan Clevenger]

Great - I just started another thread specifically on the topic of
extensibility.

Before we take a stab at refactoring anything or rewriting code, I
want to make sure we're all on the same page ... that's why I started
the other thread.

On Mar 4, 12:59 pm, Brian LeRoux <brian.ler...@nitobi.com> wrote:
> Sure, PhoneGap can be a class unto itself. Love that idea.
>
> Plug ins will take advantage of the dynamic nature of obj-c allowing
> for any sort of customization of the PhoneGapUIView (or whatever we'll
> call it). Make sense? We're still experimenting here.
>
> Any code you'd like to contribute is welcome of course. Patches > Talking
>