On Wed, Jul 9, 2014 at 2:57 PM, Joe Bowser <[email protected]> wrote:
> On Jul 9, 2014 10:22 AM, "Andrew Grieve" <[email protected]> wrote: > > > > Most of the commits to cordova-android as of late were mine. I'm hoping > > 4.0.x can be a commit-then-review kind of branch. > > Why? Branching is super cheap in git. If this was a normal repo, I'd be > meh, but it's Apache git, which is weird. Reverting is non-trivial > Refactorings are super hard to merge when conflicts arise. It's been a pain just merging master->4.0.x since any change to Cordova*Client or CordovaWebView doesn't apply at all. > > > We're a long way out from > > it being ready, so I think this will work well for now and as we get > closer > > to release we should be more cautious. It would be super-slow to ask > before > > making changes to 4.0.x, but I'm totally open to things being reverted / > > discussed. > > Why would it be slow? If it takes 2 days to get your work to pass tests, > keep it off a main repo until it does? I know we're not strict with TDD, > but still, we shouldn't break the few tests we do have. > Sorry - I've been running mobilespec and making sure it's all green. I'll have a look at the junit tests tomorrow. > > > WDYT? Maybe let's to an API walk-through once things settle to > > make the final call on what we should keep & what we should change? > > > > I honestly don't care about the changes landing as long as they don't break > tests and demos. And, if they do, a heads up is really just an e-mail > away. I'm on PTO now until Monday, and I'm writing this while waiting for > a ferry. I think others will be on PTO as well, an e-mail will save us > hours of sifting through patches trying to figure out what you did. I > didn't just create the test directory just because I needed busy work. > Awesome - yep, will try to be more ontop of emailing out changes. > > > Config.java - This I deprecated on both master and 4.0.x. The root of the > > issue is that in its current form (singleton) it does not accommodate > > having two CordovaWebViews with different settings. We're hitting this > > problem in Cordova App Harness / Chrome App Developer Tool where we'd > likei > > the main webview to use the config.xml that was bundled with the app, and > > have the child webview use a completely separate config - the one that is > > uploaded to the tool at runtime. This really should be possible, but > wasn't > > with Config being a singleton. With this refactor/deprecation, webviews > now > > have their settings set programatically and CordovaActivity gets them > from > > config.xml by default. Should be 100% backwards compatible though, as > > Config still exists and works in the same way. > > > > Some thoughts on goals for 4.0.x: > > - Enable pluggable webviews with as little copy & pasted code as possible > > - Delete most previously deprecated symbols > > - Be 100% compatible with cordova apps that have not made native-code > > customizations > > - Ensure that all cordova, chrome, and Ionic plugins (any others?) are > > compatible with both 4.0.x and 3.x.x either by maintaining APIs, or by > > changing the plugins > > > > > > From diving through the code over the past couple of weeks, I wrote a > list > > of other changes that I think would improve things: > > > > On master: > > - Move KeyEvents into a plugin (e.g. even if it's a bundled one line > > CoreAndroid) > > - Extract SplashScreen into a plugin (looking through the code, seems > this > > is doable) > > > > On 4.0.x > > - Share more code between XWalk and Android views. E.g. Maybe make > > CordovaWebView a class, and create a WebViewEngine interface that they > both > > implement. > > - Make AndroidWebView not extend WebView (or have XWalkCordovaWebView > > extend XWalkView - just want them to be consistent in this way) > > - Delete LinearLayoutSoftKeyboardDetect (functionality is provided by > > Ionic's keyboard plugin based on LayoutChange listeners) > > - Make CordovaInterface != CordovaActivity > > - I've mostly finished removing the requirement that they be the same, > > just need to now make them not actually the same class. Thinking of doing > > this by making the CordovaInterface a nested class within > CordovaActivity. > > - Move setting of disallowoverscroll into webview logic instead of within > > CordovaActivity > > - Delete shouldRequestFocusOnInit() within webview and instead have > > requestFocus() called by CordovaActivity > > > > Other things that have been discussed by I'm not entirely sure about: > > - Make default layout an AbsoluteLayout instead of a LinearLayout > > - ActivityFragment > > - Delete the LOG class > > > > > > > > > > > > > > On Tue, Jul 8, 2014 at 6:01 PM, Joe Bowser <[email protected]> wrote: > > > > > Hey > > > > > > I just noticed a ton of API changes on Android that I don't remember > > > being discussed on the list landing in 4.0.x. What's going on? > > > > > > > > > For example, I thought we were going to keep this: > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commit;h=eca05e6bad881fcd2ba928f76a28e0bb96d0e4b2 > > > > > > Also, why is the config class being deprecated? Why are these just > > > being added to the repo without being talked about on the list first? > > > > > > Joe > > > > > > > > > > > On Tue, Jul 8, 2014 at 6:25 PM, Joe Bowser <[email protected]> wrote: > > > > > Hey > > > > > > I just noticed that there's been a ton of new commits on the 4.0.x > > > branch, many of which change some public-facing APIs of Cordova. > > > Landing this many patches into Cordova without bringing these up on > > > the list isn't OK, since many of these changes will break any hope of > > > an upgrade path for our users. > > > > > > Can we please make sure that heavy refactors happen on independent > > > branches and are discussed on the list before they land in a release > > > branch? I know that 4.0.x is a long way off, but I was planning to > > > demo some of our work at OSCON, and the recent changes broke the demo. > > > I now have to fork off the branch before this refactor was done, which > > > sucks because we can't get any new people who want to contribute > > > on-boarded easily. > > > > > > I really don't want to revert everything, because that would suck, but > > > being patchbombed sucks as well, and doesn't help build consensus with > > > other people on the project. Also, I'm not sure we can revert this > > > git repo back, because Apache git is weird and doesn't allow force. I > > > know that availability is limited, but a heads up would be good, since > > > I have no idea what is going on with a lot of these commits, since > > > some are the opposite of what we agreed to earlier. > > > > > > Interested in hearing thoughts about the changes, and how we can avoid > > > this in the future. > > > > > > Joe > > > >
