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 <[email protected]> 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:[email protected]] > Sent: Tuesday, January 21, 2014 8:22 AM > To: [email protected] > Cc: [email protected] > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> 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 <[email protected]> > 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 > >> >
