cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [Android] InAppBrowser sucks and needs a re-write
Date Wed, 22 Jan 2014 04:56:55 GMT
The discussion before we started implementing IAB was long and had its ups
and downs. Don't think you want to re-read that, but what came out of it
was, we decided to override the window.open API so this is *almost*
standards based, and the code will still work in a browser (not the main
goal, but a bonus). Thats why the options are like that, etc.




On Tue, Jan 21, 2014 at 6:33 AM, Wargo, John <john.wargo@sap.com> wrote:

> Part of the weirdness is that insertCSS and executeScript have callbacks
> and nothing else does. Plus options is a string rather than an object like
> it is in every other API. IAB just doesn't feel like a Cordova plugin. +1
> to refactoring it so it looks, feels and works like the other Cordova APIs.
>
> We use IAB in our solution, so would like to see it stick around. It adds
> some very useful capabilities to our plugins and it is better to have the
> community support it than to have to write our own.
>
> John M. Wargo
> Twitter: @johnwargo
>
>
> -----Original Message-----
> From: Jesse [mailto:purplecabbage@gmail.com]
> Sent: Tuesday, January 21, 2014 8:22 AM
> To: dev@cordova.apache.org
> Cc: bowserj@apache.org
> Subject: Re: [Android] InAppBrowser sucks and needs a re-write
>
> InAppBrowser is important to windows phone too.
> Oauth would be difficult/unpossible without it.
>
> I agree some of the recent additions to the api don't make a tonne of
> sense.
> Namely: insertCSS and executeScript are strange additions that seemed
> to be added out of nowhere?!
> The fact that we chose to override window.open and change the
> behaviour completely never made sense to me, but I was planning on
> just releasing my own Browser plugin that works the way I think it
> should, and the way I want it to. I would much rather see us write
> competing cross-platform plugins than try to agree on what the api
> should be.
>
> We definitely need this functionality, even on Android, as there is an
> extra level of control we get by having our own control.
>
> Sent from my iPhone
>
> > On Jan 21, 2014, at 4:58 AM, Brian LeRoux <b@brian.io> wrote:
> >
> > Eh Joe, lets tone down 'X sucks' and stick to dispassionate evaluations
> of
> > technology. I get the usefulness of the shortcut, and tend to agree, but
> it
> > isn't constructive.
> >
> > Is oAuth workflow not possible w/ vanilla intents?
> >
> >
> >> On Mon, Jan 20, 2014 at 11:05 AM, Joe Bowser <bowserj@gmail.com> wrote:
> >>
> >> Let me clarify:
> >>
> >> 1. OAuth sucks, and InAppBrowser sucks, and there's no better solution
> >> to this problem, so InAppBrowser will probably have to stay
> >> 2. Does anyone disagree with me when I say that InAppBrowser sucks and
> >> is too complex.  If so, why?
> >> 3. Who wants to re-write the code that I don't care about?
> >>
> >>
> >>
> >> On Mon, Jan 20, 2014 at 11:01 AM, Darryl Pogue <dvpdiner2@gmail.com>
> >> wrote:
> >>> As Shazron mentioned, it is important for apps doing OAuth with
> >>> 3rd party services that might not provide Java APIs.
> >>>
> >>> In our case, we need to use InApp Browser to allow users to sign in
> >>> to FitBit. We detect when the URL changes after a successful login and
> >>> pull tokens from it.
> >>>
> >>>> On Mon, Jan 20, 2014 at 10:55 AM, Brian LeRoux <b@brian.io> wrote:
> >>>> The only platform that really needs it is iOS b/c it doesn't have
> >> intents
> >>>> so I'm not sure focusing on this part of the codebase is a worthwhile
> >>>> exercise. I'd be fine with deprecating the Android support and add a
> >> docs
> >>>> note for ppl to not hijack href's for spawning in-app when running
> >> anywhere
> >>>> but iOS.
> >>>>
> >>>>
> >>>>> On Mon, Jan 20, 2014 at 10:37 AM, Joe Bowser <bowserj@gmail.com>
> wrote:
> >>>>>
> >>>>> Hey
> >>>>>
> >>>>> So, after spending a bit of time with InAppBrowser, I think we should
> >>>>> get rid of it.  It serves almost no purpose, and it's way too complex
> >>>>> of a plugin for us to maintain.  However, nobody would agree with
me
> >>>>> about shitcanning this thing, so instead I propose we re-write the
> >>>>> whole thing because it pretty much needs to be green-fielded.
> >>>>>
> >>>>> Part of the reason is the fact that the UI is all hardcoded when
it
> >>>>> doesn't need to be.  Now that we're moving around resources, we
> should
> >>>>> be able to move around XML layouts and use this instead of hardcoding
> >>>>> our UI in JS.
> >>>>>
> >>>>> The other part of the reason is that I think that too many new
> >>>>> features got added to InAppBrowser, and I don't think anyone actually
> >>>>> knows how this thing is supposed to work.  Furthermore, I think
that
> >>>>> on Android, even if you follow Android guidelines, the InAppBrowser
> >>>>> looks totally stupid and it screams "This is a PhoneGap App therefore
> >>>>> it sucks!".  If our users can tell if an app is written in Cordova,
> we
> >>>>> have failed.
> >>>>>
> >>>>> Now, I'm fine with moving out the UI, but I want to know how much
> >>>>> people care about this stupid plugin.
> >>>>>
> >>>>> Also, on another note, has anyone tried starting Chrome with
> >>>>> startActvitiyForResult and onActivityResult? I'd much rather have
> >>>>> chrome appear and have Chrome pass the results back than our stupid
> >>>>> half-baked browser.
> >>>>>
> >>>>> I'm sure everyone has thoughts on this, so let's hear them.
> >>>>>
> >>>>> Joe
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message