I can see where you are coming from for your rationale. Do you have a use case where you don't want the preferences acted upon until after onCreate()?
The breakage is that our product expects the preferences to be acted upon during onCreate(), and it tries to use the result of that preference activation before loadUrl(). Although it is true that adding an explicit call to init() does activate the preferences, that would require the entire install base of users to change their app source code, which of course is not something we want to do. Bottom line is that a public API changed without a major version bump. I'd like to put the preference activation in onCreate() / init() back to where it was, but leaving everything else unchanged. If there is a real need to be able to defer the preference activation outside of onCreate() before 4.x, how about using a different signature, like the following? https://github.com/cmarcelk/cordova-android/blob/5862352ba64ec44fbf04a3dc87f108d951f3933f/framework/src/org/apache/cordova/CordovaActivity.java#L215 On Sep 30, 2014, at 9:50 AM, Andrew Grieve <agri...@chromium.org> wrote: > Sorry about the bad commit message. Was a part of my > not-so-good-at-explaining streak :S. > > The rationale I had was that with the code in init(), there was no way to > programmatically influence the behaviour of the preferences that you had. I > tried to make the split now so that preferences are loaded in onCreate(), > and then not acted upon until init(), so this way you can set preferences > programmatically between the two if you'd like. > > Which part of the change is causing a break for you? Is it that > createViews() isn't called during onCreate? If so - does adding an explicit > call to init() from within your subclass work around the problem?
