Should the implementation of the InAppBrowser on Android mimic the UI of the iOS app or should it go it's own way?
Currently the Android ChildBrowser has the buttons and location bar on the top of the screen. Is there any UI pattern we should be following for this type of in app browsing? Simon Mac Donald http://hi.im/simonmacdonald On Mon, Nov 19, 2012 at 6:24 PM, Shazron <shaz...@gmail.com> wrote: > I have a pull request for the JavaScript changes, can someone please > review: https://github.com/apache/incubator-cordova-js/pull/43 > > I have committed my InAppBrowser changes to iOS: > > https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-ios.git;a=commit;h=26a6535c > > To test this on iOS right now: > cordova.exec(null, null, "InAppBrowser", "open", ["http://google.com";, > "_blank", "location=yes"]); > > (don't forget to add InAppBrowser/CDVInAppBrowser to your Cordova.plist). > > Note that non-whitelisted URLs cannot be opened in the InAppBrowser yet > because of http://issues.cordova.io/1695 which I am doing next. > > Once the js changes are in (at least on ios), you can do: > var mywin = window.open("http://www.google.com";, "_blank", > "location=no"); > mywin.close(); > > > > > > On Thu, Nov 15, 2012 at 3:58 PM, Shazron <shaz...@gmail.com> wrote: > > > I updated the spec: http://wiki.apache.org/cordova/InAppBrowser > > However, I added the _blank option as well just to be explicit. > > > > > > On Thu, Nov 15, 2012 at 1:58 AM, Shazron <shaz...@gmail.com> wrote: > > > >> > >> I spent some time playing with how to do this. > >>> 1 - Use referer header - Too many situations result in no header, so > this > >>> is out! > >>> 2 - Use Cookies - if there were a way to have UIWebViews use separate > >>> cookie jars, this might be feasible. Don't think that's possible. > >>> 3 - Use User-Agent - this is already suggested in CB-1695. I also found > >>> this: > >>> > >>> > http://stackoverflow.com/questions/12180224/unique-tab-id-appended-to-user-agent-string-in-chrome-for-ios > >>> , > >>> which suggests that this is what Chrome for iOS uses to implement > >>> incognito > >>> mode. If they can make it work, then we should be able to as well! > >>> > >>> So, this is looking like it's non-trivial but not impossible! As long > as > >>> it's possible, let's implement it :) > >>> > >>> > >> Looks like it may be possible in CB-1695 as you mentioned -- so we can > >> finish InAppBrowser with this one failing case until it is implemented. > I > >> can look into this further once I finish the InAppBrowser integration. > >> > >> > >>> I don't think the semantics of _parent and _blank really map well to > what > >>> we're doing. My vote is to create a new special value: _system, and > only > >>> this target kicks you out to the system browser. > >>> > >>> Also: on the wiki we have: > >>> [F] window.open('http://random-url.com', '_blank'); // native browser > >>> > >>> It seems weird to me that the effect of _blank changes based on whether > >>> the > >>> URL is in the whitelist. I'd think this case would also open in the > >>> InAppBrowser. > >>> > >>> > >>> Summary of what I think: > >>> _self or no target --> open in cordova webview if it's in the > Whitelist, > >>> InAppBrowser otherwise > >>> _system --> open in system browser > >>> anything else --> open in InAppBrowser > >>> > >>> Also, I like Simon's idea of using the options in window.open to > specify > >>> whether to show URL bar etc. :) > >>> > >> > >> I agree, we need a new value "_system" as you suggested, as well as the > >> other parts of the summary of your changes -- makes more sense, and if > used > >> in another context -- it will just work as expected. I can make the wiki > >> changes unless others have more comments. > >> > >> We can definitely add the window options as well, for sure! > >> > >> > > >
