open link in system browser
Hi, sorry to ask this question again, but I simply can't get this to
work.
The problem I have is when I do
window.open(url, "_system") (e.g.
window.open("http://www.cnn.com", "_system") )
I want to open the link on the system (e.g. safari) browser, but
instead it opens the content inside the app (blocking the previous
screen).
I'm using Cordova 3.0.0. This behavior happens both on Android and
iOS.
I've installed InAppBrowser ( cordova plugin add
https://git-wip-us.apache.org/repos/asf/cordova-plugin-inappbrowser.git
), like the instructions said. I have also added the clause to the
platform-specific config.xml, e.g. in
/platforms/android/res/xml/config.xml:
Could this be because I have:
in the config.xml? Do I need to change that setting?
Please help!
Thanks,
Kirill
--
Kirill Kireyev, PhD
Founder/CTO instaGrok.com
kir...@instagrok.com
Twitter: @instaGrok
FB: facebook.com/instagrok
no more commit, jira emails
I don't seem to be getting any commit or jira emails anymore. The last commit email was 11:15am Pacific, and the last JIRA email was 1:48pm Pacific. There definitely has been more commits and updates to JIRA issues since then. Anyone see this?
RE: When to do "Official Apache Releases"
+1. We have same scenario described by Marcel below. -Original Message- From: Marcel Kinard [mailto:cmarc...@gmail.com] Sent: Tuesday, 10 September 2013 11:21 PM To: dev@cordova.apache.org Subject: Re: When to do "Official Apache Releases" +1 to still do these for each cadence release. I'm in a somewhat unique situation where Cordova gets bundled as a downstream distribution into a vendor product. The vendor product uses the Cordova native platforms and core plugins that get embedded in the product, the product doesn't fetch any code from git or npm. And the product itself doesn't get installed in an npm-like way. There isn't dynamic updates or dependency fetching. As we bundle those downstream distributions, I'm very used to using the official apache release tarballs. I'm fine with it being just the native platforms and docs. We don't embed the Cordova docs in the product, we just link out to cordova.apache.org/docs. And it would feel weird for an Apache project to not publish source releases. I nobody else wants to invest the time to publish an official apache release to dist.apache.org, then I can own that. -- Marcel On Sep 3, 2013, at 12:36 PM, Andrew Grieve wrote: > It's been mentioned before, but with CLI, there's not a lot of utility > in doing official apache releases (uploading signed zips to dist.apache.org). > > I don't think we should stop doing these entirely, but should we still > do these for each Cadence Release? An alternative would be to do them > only once / twice a year. > > Any thoughts on why / why not? > > Andrew
Re: iOS 7 went GM
In any case, this method below has worked for supporting older SDKs in a newer IDE even before Xcode 5: http://blog.spacemanlabs.com/2013/09/how-to-support-old-ios-sdks-in-xcode-5/ ... which might give a compile-time check that you are using iOS 7 APIs dynamically by compiling with the actual iOS 6 SDK On Thu, Sep 12, 2013 at 3:32 AM, Shazron wrote: > Enterprises can already do so with Xcode 5 since our deployment target is > iOS 5.0 (like usual). We just have to be careful (like when we upgraded to > iOS 6.0 support) to conditionally use any iOS 7 APIs... which since we are > not really using any (except for some UIWebView new properties that we > would have to support, which will be properly guarded against, which we > have done before for iOS 6 -> 5) > > > On Thu, Sep 12, 2013 at 12:31 AM, purplecabbage > wrote: > >> As Shaz said, soon they will not. After iOS7 is out. >> >> There is still however a reason to support older Xcode version because >> enterprises can distribute their own apps. >> >> Sent from my iPhone >> >> > On Sep 12, 2013, at 12:19 AM, Samuel Nova >> wrote: >> > >> > Can anyone confirm that Apple does not take new apps unless compiled >> with >> > Xcode 5? We submitted 2 updates yesterday using Xcode 4.6.3, no >> problems so >> > far.. >> > >> > >> > >> >> On Wed, Sep 11, 2013 at 2:41 PM, Andrew Grieve >> wrote: >> >> >> >> Okay, well that is a bit annoying, but the fact that they won't take >> apps >> >> unless built with 5 is pretty darn compelling :P. >> >> >> >> >> >>> On Tue, Sep 10, 2013 at 5:06 PM, Shazron wrote: >> >>> >> >>> Xcode 5 does require at least Mountain Lion (10.8) while Xcode 4.6.3 >> you >> >>> could still use Lion (10.7) >> >>> >> >>> From the download page: >> >>> "Xcode 5 GM seed requires OS X Mountain Lion or later." >> >>> >> >>> >> >>> On Tue, Sep 10, 2013 at 1:53 PM, Andrew Grieve >> >>> wrote: >> >>> >> Sounds good! No reason not to insist on this. It's a free download >> and >> doesn't change the system requirements (at least they don't mention >> >> that >> >>> it >> does) >> >> >> > On Tue, Sep 10, 2013 at 4:38 PM, Shazron wrote: >> > >> > Also, Apple just sent out the email "Submit your iOS 7 apps today" >> >>> using >> > Xcode 5 GM. >> > >> > So I say once iOS 7 goes GA (Sept 20?) we say Cordova only supports >> Xcode 5 >> > going forward (since that will be the requirement for submitting to >> >> the >> App >> > Store) >> > >> > >> >> On Tue, Sep 10, 2013 at 1:21 PM, Shazron >> wrote: >> >> >> >> download the GM Xcode from the iOS Dev Center. I suppose we can >> finalize >> >> iOS 7 support/testing. >> > >> > >> > >> > -- >> > Samuel Nova >> > samuel.n...@terria.com >> > >> > Terria Mobile >> > Steinenvorstadt 30 >> > CH-4051 Basel >> > Switzerland >> > >> > Office: +41 61 511 76 88 >> > Direct: +41 61 511 76 83 >> > Mobile: +41 79 455 71 14 >> > Web: www.terria.com >> > >
Re: [Android] Adding init() to the template and decoupling from loadUrl
reviewing the issue, I don't see any problem with this fix. Sounds reasonable to me. On Wed, Sep 11, 2013 at 1:24 PM, Joe Bowser wrote: > This is in response to CB-4620: > > This bug only happens if you are switching between pages faster than > the app can draw the URI. I don't even know how this could happen, > since I didn't think the WebView worked without being attached to a > view, but it does. > > So, what I'm proposing is that we add an init() call to the template > so that the layout is initialized before we load URLs? Is there a > reason to not do this? Does this break anything? > > Joe >
Re: [Android] Adding init() to the template and decoupling from loadUrl
I've committed it. It doesn't break anything, and if we can fix random view detachment issues, I think it's all good. On Thu, Sep 12, 2013 at 9:52 AM, Lorin Beer wrote: > reviewing the issue, I don't see any problem with this fix. Sounds > reasonable to me. > > > On Wed, Sep 11, 2013 at 1:24 PM, Joe Bowser wrote: >> >> This is in response to CB-4620: >> >> This bug only happens if you are switching between pages faster than >> the app can draw the URI. I don't even know how this could happen, >> since I didn't think the WebView worked without being attached to a >> view, but it does. >> >> So, what I'm proposing is that we add an init() call to the template >> so that the layout is initialized before we load URLs? Is there a >> reason to not do this? Does this break anything? >> >> Joe > >
Re: config.xml as a build artifact for less suffering and easier upgrades
Yup I'm on the same page with you Michal, and I believe Braden as well. I'm sorry I should have said so earlier, we resolved this on irc. I have a basic implementation here https://github.com/apache/cordova-cli/pull/39 but I'm still testing it. On 13-09-12 12:36 PM, "Michal Mocny" wrote: >Trying to clarify the misunderstanding... > >Jeffrey, if I understand your email, your understanding of point (4) of >bradens flow is that the app.xml is *being* munged, whereas we meant that >its the app.xml config that is *doing* the munging to the platform config. > I think that means we both agree that app.xml should never be modified, >and it was just a miscommunication. Am I right with that understanding? > >Also, in your proposal you have plugins munging/preparing *after* app.xml >does its munging. I assume you did not do intentionally, that you had just >not considered the order important. If it was intentional, why? We were >thinking app.xml should be last and thus have the most "importance". > > >On Wed, Sep 11, 2013 at 11:38 AM, Braden Shepherdson >wrote: > >> I think we've gotten a bit confused. Let me try to describe again the >>way I >> was envisioning things. >> >> 1. If defaults.xml exists, replace platform config.xml with it. >> 2. Use plugman to add each plugin's changes onto the >>platform >> config.xml. >> 3. Add in the values from the app config.xml: , etc., >>which >> it currently does, plus the proposed new tags. >> 4. Somewhere in there, call plugman prepare to update the JS modules. >>This >> doesn't change or depend on config.xml at all. >> >> NB: I don't suggest anywhere that we edit the user's top-level, app >> config.xml. This is just a process for building the platform config.xml, >> and making it a pure build artifact. >> >> I also suggest that the "last word"; the file whose changes are added >>last, >> is the app config.xml. This allows the user the power to override any >> default or setting from a plugin. >> >> Braden >> >> >> On Wed, Sep 11, 2013 at 2:16 PM, Jeffrey Heifetz >>> >wrote: >> >> > I'd like to clarify the changes to prepare before I continue the >> > implementation. >> > >> > The current prepare flow works like this >> > 1. Call parser.update_project. This includes calling >> > parser.update_from_config which updates the platform config and >>resources >> > based on app config (but only handles specific tags). It also updates >>the >> > platform www based on app www, staging and overrides. >> > 2. Call plugman prepare (sets up JS-modules) >> > 3. Plugin config-munge (where each plugin config changes are >> > iterated >> > through) >> > >> > Braden's proposed flow (in his own words) >> > 1. Delete the old platform config.xml. >> > 2. Copy the defaults.xml to config.xml. >> > 3. Re-run the Plugman config munging for every plugin, >>modifying >> > the >> >fresh platform config.xml. (The order here is deliberately >> > undefined; >> >plugins should already not be relying on this.) >> > 4. Run the config munging for the app’s config.xml as well. >> > Where I believe #4 means the plugin config-munge. >> > >> > I'd like to propose the new flow to be the following >> > >> > 1. If defaults.xml exists, replace platform congig.xml with it >> > 2. Run a generic clobbers from app.xml to platform.xml that >>will >> > include >> > processing the proposed tags. >> > 3. Run plugman config munge on the platform config.xml (I >>believe >> > this should only add net new elements) >> > >> > 4. Call a modified parser.update_project that no longer makes >> > changes to >> > the platform config.xml >> > >> > I believe that this is complimentary with the approach Braden >>suggested >> > with one major change. I did not include plugin config munging on the >>app >> > config.xml. This is because I feel that by doing so we make the app >> > config.xml the same half build artifact half user edited mess we're >> trying >> > to solve. If the list disagrees with me I will of course implement it >>the >> > way Braden proposed it though. >> > >> > >> > >> > On 13-09-10 1:58 PM, "Jeffrey Heifetz" >>wrote: >> > >> > >Issue Created - https://issues.apache.org/jira/browse/CB-4774 >> > > >> > >On 13-09-10 9:30 AM, "Tommy-Carlos Williams" >> wrote: >> > > >> > >>Then colour me excited! >> > >> >> > >>+1 >> > >> >> > >> >> > >>On 10/09/2013, at 11:27 PM, Andrew Grieve >> wrote: >> > >> >> > >>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams >> > >>>wrote: >> > >>> >> > I have been following this thread with a combination of interest >>and >> > trepidation. >> > >> > Interest: >> > >> > Anything that works towards ./platforms being a build artefact I >>am >> > all >> > for. In our app, ./platforms is already a build artefact. We used >> > hooks to >> > achieve this (updating config files, copying icon / splash >>assets, >> > etc). >> >
Re: config.xml as a build artifact for less suffering and easier upgrades
Trying to clarify the misunderstanding... Jeffrey, if I understand your email, your understanding of point (4) of bradens flow is that the app.xml is *being* munged, whereas we meant that its the app.xml config that is *doing* the munging to the platform config. I think that means we both agree that app.xml should never be modified, and it was just a miscommunication. Am I right with that understanding? Also, in your proposal you have plugins munging/preparing *after* app.xml does its munging. I assume you did not do intentionally, that you had just not considered the order important. If it was intentional, why? We were thinking app.xml should be last and thus have the most "importance". On Wed, Sep 11, 2013 at 11:38 AM, Braden Shepherdson wrote: > I think we've gotten a bit confused. Let me try to describe again the way I > was envisioning things. > > 1. If defaults.xml exists, replace platform config.xml with it. > 2. Use plugman to add each plugin's changes onto the platform > config.xml. > 3. Add in the values from the app config.xml: , etc., which > it currently does, plus the proposed new tags. > 4. Somewhere in there, call plugman prepare to update the JS modules. This > doesn't change or depend on config.xml at all. > > NB: I don't suggest anywhere that we edit the user's top-level, app > config.xml. This is just a process for building the platform config.xml, > and making it a pure build artifact. > > I also suggest that the "last word"; the file whose changes are added last, > is the app config.xml. This allows the user the power to override any > default or setting from a plugin. > > Braden > > > On Wed, Sep 11, 2013 at 2:16 PM, Jeffrey Heifetz >wrote: > > > I'd like to clarify the changes to prepare before I continue the > > implementation. > > > > The current prepare flow works like this > > 1. Call parser.update_project. This includes calling > > parser.update_from_config which updates the platform config and resources > > based on app config (but only handles specific tags). It also updates the > > platform www based on app www, staging and overrides. > > 2. Call plugman prepare (sets up JS-modules) > > 3. Plugin config-munge (where each plugin config changes are > > iterated > > through) > > > > Braden's proposed flow (in his own words) > > 1. Delete the old platform config.xml. > > 2. Copy the defaults.xml to config.xml. > > 3. Re-run the Plugman config munging for every plugin, modifying > > the > >fresh platform config.xml. (The order here is deliberately > > undefined; > >plugins should already not be relying on this.) > > 4. Run the config munging for the app’s config.xml as well. > > Where I believe #4 means the plugin config-munge. > > > > I'd like to propose the new flow to be the following > > > > 1. If defaults.xml exists, replace platform congig.xml with it > > 2. Run a generic clobbers from app.xml to platform.xml that will > > include > > processing the proposed tags. > > 3. Run plugman config munge on the platform config.xml (I believe > > this should only add net new elements) > > > > 4. Call a modified parser.update_project that no longer makes > > changes to > > the platform config.xml > > > > I believe that this is complimentary with the approach Braden suggested > > with one major change. I did not include plugin config munging on the app > > config.xml. This is because I feel that by doing so we make the app > > config.xml the same half build artifact half user edited mess we're > trying > > to solve. If the list disagrees with me I will of course implement it the > > way Braden proposed it though. > > > > > > > > On 13-09-10 1:58 PM, "Jeffrey Heifetz" wrote: > > > > >Issue Created - https://issues.apache.org/jira/browse/CB-4774 > > > > > >On 13-09-10 9:30 AM, "Tommy-Carlos Williams" > wrote: > > > > > >>Then colour me excited! > > >> > > >>+1 > > >> > > >> > > >>On 10/09/2013, at 11:27 PM, Andrew Grieve > wrote: > > >> > > >>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams > > >>>wrote: > > >>> > > I have been following this thread with a combination of interest and > > trepidation. > > > > Interest: > > > > Anything that works towards ./platforms being a build artefact I am > > all > > for. In our app, ./platforms is already a build artefact. We used > > hooks to > > achieve this (updating config files, copying icon / splash assets, > > etc). > > > > Just a quick questionŠ I know that ./platforms/../config.xml (even > > after a > > `cordova build Š`) still has the old defaults for name, author, id > > etcŠ but > > it doesn't seem to make any difference. We don't modify > > ./platforms/../config.xml as it seemed like the modifications to > > ./www/config.xml (and our custom hook modifications to say > > ./platforms/android/AndroidManifest.xml)
Re: iOS 7 went GM
Enterprises can already do so with Xcode 5 since our deployment target is iOS 5.0 (like usual). We just have to be careful (like when we upgraded to iOS 6.0 support) to conditionally use any iOS 7 APIs... which since we are not really using any (except for some UIWebView new properties that we would have to support, which will be properly guarded against, which we have done before for iOS 6 -> 5) On Thu, Sep 12, 2013 at 12:31 AM, purplecabbage wrote: > As Shaz said, soon they will not. After iOS7 is out. > > There is still however a reason to support older Xcode version because > enterprises can distribute their own apps. > > Sent from my iPhone > > > On Sep 12, 2013, at 12:19 AM, Samuel Nova > wrote: > > > > Can anyone confirm that Apple does not take new apps unless compiled with > > Xcode 5? We submitted 2 updates yesterday using Xcode 4.6.3, no problems > so > > far.. > > > > > > > >> On Wed, Sep 11, 2013 at 2:41 PM, Andrew Grieve > wrote: > >> > >> Okay, well that is a bit annoying, but the fact that they won't take > apps > >> unless built with 5 is pretty darn compelling :P. > >> > >> > >>> On Tue, Sep 10, 2013 at 5:06 PM, Shazron wrote: > >>> > >>> Xcode 5 does require at least Mountain Lion (10.8) while Xcode 4.6.3 > you > >>> could still use Lion (10.7) > >>> > >>> From the download page: > >>> "Xcode 5 GM seed requires OS X Mountain Lion or later." > >>> > >>> > >>> On Tue, Sep 10, 2013 at 1:53 PM, Andrew Grieve > >>> wrote: > >>> > Sounds good! No reason not to insist on this. It's a free download and > doesn't change the system requirements (at least they don't mention > >> that > >>> it > does) > > > > On Tue, Sep 10, 2013 at 4:38 PM, Shazron wrote: > > > > Also, Apple just sent out the email "Submit your iOS 7 apps today" > >>> using > > Xcode 5 GM. > > > > So I say once iOS 7 goes GA (Sept 20?) we say Cordova only supports > Xcode 5 > > going forward (since that will be the requirement for submitting to > >> the > App > > Store) > > > > > >> On Tue, Sep 10, 2013 at 1:21 PM, Shazron wrote: > >> > >> download the GM Xcode from the iOS Dev Center. I suppose we can > finalize > >> iOS 7 support/testing. > > > > > > > > -- > > Samuel Nova > > samuel.n...@terria.com > > > > Terria Mobile > > Steinenvorstadt 30 > > CH-4051 Basel > > Switzerland > > > > Office: +41 61 511 76 88 > > Direct: +41 61 511 76 83 > > Mobile: +41 79 455 71 14 > > Web: www.terria.com >
Re: addJavascriptInterface fails on Android API levels 17 and 18 (4.2.2 and 4.3)
Android does not use jsi for this exact reason, so it is advised that you do
the same.
My advice, short of making a full on plugin, is to learn how to use
cordova.exec directly and never worry about a bridge again.
Sent from my iPhone
> On Sep 12, 2013, at 12:00 AM, "dev at watch2web.com"
> wrote:
>
> My app is a Cordova app -- Cordova 3.0.0, as I said. I added just a few
> little JavascriptInterface methods because they did so little that writing a
> full-on plugin seemed like overkill. It has all worked very nicely until API
> 17, and I have not come across something that says it is forbidden to create
> your own little JSI when using Cordova. If it is forbidden, please tell me,
> and I apologize for my ignorance.
>
> I am using JDK 1.6. According to docs, it has full support for annotations,
> and if it didn't, wouldn't this have failed on API levels 16 and lower?
>
> I guess your point is that I can probably demonstrate the same failure in an
> app that doesn't use Cordova, and therefore, my problem is irrelevant. You
> may be right about the first part, and of course I respect your judgment re.
> relevance. But I imagine the same thing could be said about a lot of issues
> you have had to deal with. I was hoping to get some direction from experts
> who have had to deal with whatever change in Android 4.2.2 (API 17) occurred
> that seems to be connected here.
>
>
> - Original Message - From: "Joe Bowser"
> To: "dev"
> Sent: Wednesday, 11 September, 2013 16:59
> Subject: Re: addJavascriptInterface fails on Android API levels 17 and 18
> (4.2.2 and 4.3)
>
>
> What does this have to do with Cordova? It looks like you're building
> your own bridge on Android.
>
> Make sure that your Java version that you're building with supports
> annotations. If not, you won't be able to add the Javascript
> Interface.
>
>> On Wed, Sep 11, 2013 at 4:52 PM, dev at watch2web.com
>> wrote:
>> I recently changed the value of targetSdkVersion in my AndroidManifest.xml
>> from 16 to 18. They say, "Better late than never," but maybe not in this
>> case. I discovered that the change causes my app to white-screen on startup
>> on two Samsung Galaxy S4s -- both running API level 17 (4.2.2). (On the five
>> other devices I have -- all running API 16 or lower -- everything still
>> works as if nothing has changed.) If I set targetSdkVersion back to 16, the
>> app works great on all devices, including both Samsungs. I am using Cordova
>> 3.0.0.
>>
>> I have traced the problem to my onDeviceReady function, at the line where it
>> first tries to execute one of my @JavascriptInterface functions. (It doesn't
>> seem to matter which one.) Code snippet looks like:
>>
>> (in main Activity)
>>
>> appView.addJavascriptInterface(this, "MyJSI");
>>
>> @JavascriptInterface
>> public void foo() { }
>>
>>
>> (in onDeviceReady)
>>
>> if (window.MyJSI == undefined) console.log("javascript interface is
>> undefined");
>> else if (window.MyJSI == null) console.log("javascript interface is null");
>> else if (typeof(window.MyJSI) == 'object') console.log("javascript interface
>> is an object: " + window.MyJSI);
>> else console.log("javascript interface is not an object");
>>
>> window.MyJSI.foo(); // foo is just some method I wrote -- I've only
>> experimented with a few
>>
>>
>> On both "good" (API level <= 16) and "bad" (Galaxy S4, API level >= 17)
>> phones I get in the console output:
>>
javascript interface is an object: [object Object]
>>
>> On the "good" phones, everything continues, and I get all the logging that
>> comes from subsequent parts of the app. On the "bad" phone, I get:
>>
Uncaught TypeError: Object [object Object] has no method 'foo'
>>
>> and things pretty much stop.
>>
>>
>> You'd think I was in OK shape. I have a fix that involves changing one
>> character -- not even in code, just a settings file -- and it works on all
>> API levels. But NO, Google Play forbids lowering the targetSdkVersion. So I
>> need to fix this for real.
>>
>> In searching, I found this issue from December. It isn't exactly what I'm
>> seeing since deviceready does fire for me. But a lot of the elements seem
>> very similar.
>>
>> https://issues.apache.org/jira/browse/CB-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501660#comment-13501660
>>
>>
>> I'm happy to dig through Java source myself if it will help, but if so, I
>> could use a little guidance getting started.
>>
>> Thanks,
>> Andrew
>
Re: iOS 7 went GM
As Shaz said, soon they will not. After iOS7 is out. There is still however a reason to support older Xcode version because enterprises can distribute their own apps. Sent from my iPhone > On Sep 12, 2013, at 12:19 AM, Samuel Nova wrote: > > Can anyone confirm that Apple does not take new apps unless compiled with > Xcode 5? We submitted 2 updates yesterday using Xcode 4.6.3, no problems so > far.. > > > >> On Wed, Sep 11, 2013 at 2:41 PM, Andrew Grieve wrote: >> >> Okay, well that is a bit annoying, but the fact that they won't take apps >> unless built with 5 is pretty darn compelling :P. >> >> >>> On Tue, Sep 10, 2013 at 5:06 PM, Shazron wrote: >>> >>> Xcode 5 does require at least Mountain Lion (10.8) while Xcode 4.6.3 you >>> could still use Lion (10.7) >>> >>> From the download page: >>> "Xcode 5 GM seed requires OS X Mountain Lion or later." >>> >>> >>> On Tue, Sep 10, 2013 at 1:53 PM, Andrew Grieve >>> wrote: >>> Sounds good! No reason not to insist on this. It's a free download and doesn't change the system requirements (at least they don't mention >> that >>> it does) > On Tue, Sep 10, 2013 at 4:38 PM, Shazron wrote: > > Also, Apple just sent out the email "Submit your iOS 7 apps today" >>> using > Xcode 5 GM. > > So I say once iOS 7 goes GA (Sept 20?) we say Cordova only supports Xcode 5 > going forward (since that will be the requirement for submitting to >> the App > Store) > > >> On Tue, Sep 10, 2013 at 1:21 PM, Shazron wrote: >> >> download the GM Xcode from the iOS Dev Center. I suppose we can finalize >> iOS 7 support/testing. > > > > -- > Samuel Nova > samuel.n...@terria.com > > Terria Mobile > Steinenvorstadt 30 > CH-4051 Basel > Switzerland > > Office: +41 61 511 76 88 > Direct: +41 61 511 76 83 > Mobile: +41 79 455 71 14 > Web: www.terria.com
Re: iOS 7 went GM
Can anyone confirm that Apple does not take new apps unless compiled with Xcode 5? We submitted 2 updates yesterday using Xcode 4.6.3, no problems so far.. On Wed, Sep 11, 2013 at 2:41 PM, Andrew Grieve wrote: > Okay, well that is a bit annoying, but the fact that they won't take apps > unless built with 5 is pretty darn compelling :P. > > > On Tue, Sep 10, 2013 at 5:06 PM, Shazron wrote: > > > Xcode 5 does require at least Mountain Lion (10.8) while Xcode 4.6.3 you > > could still use Lion (10.7) > > > > From the download page: > > "Xcode 5 GM seed requires OS X Mountain Lion or later." > > > > > > On Tue, Sep 10, 2013 at 1:53 PM, Andrew Grieve > > wrote: > > > > > Sounds good! No reason not to insist on this. It's a free download and > > > doesn't change the system requirements (at least they don't mention > that > > it > > > does) > > > > > > > > > On Tue, Sep 10, 2013 at 4:38 PM, Shazron wrote: > > > > > > > Also, Apple just sent out the email "Submit your iOS 7 apps today" > > using > > > > Xcode 5 GM. > > > > > > > > So I say once iOS 7 goes GA (Sept 20?) we say Cordova only supports > > > Xcode 5 > > > > going forward (since that will be the requirement for submitting to > the > > > App > > > > Store) > > > > > > > > > > > > On Tue, Sep 10, 2013 at 1:21 PM, Shazron wrote: > > > > > > > > > download the GM Xcode from the iOS Dev Center. I suppose we can > > > finalize > > > > > iOS 7 support/testing. > > > > > > > > > > > > > > > -- Samuel Nova samuel.n...@terria.com Terria Mobile Steinenvorstadt 30 CH-4051 Basel Switzerland Office: +41 61 511 76 88 Direct: +41 61 511 76 83 Mobile: +41 79 455 71 14 Web: www.terria.com
Re: addJavascriptInterface fails on Android API levels 17 and 18 (4.2.2 and 4.3)
My app is a Cordova app -- Cordova 3.0.0, as I said. I added just a few
little JavascriptInterface methods because they did so little that writing a
full-on plugin seemed like overkill. It has all worked very nicely until API
17, and I have not come across something that says it is forbidden to create
your own little JSI when using Cordova. If it is forbidden, please tell me,
and I apologize for my ignorance.
I am using JDK 1.6. According to docs, it has full support for annotations,
and if it didn't, wouldn't this have failed on API levels 16 and lower?
I guess your point is that I can probably demonstrate the same failure in an
app that doesn't use Cordova, and therefore, my problem is irrelevant. You
may be right about the first part, and of course I respect your judgment re.
relevance. But I imagine the same thing could be said about a lot of issues
you have had to deal with. I was hoping to get some direction from experts
who have had to deal with whatever change in Android 4.2.2 (API 17) occurred
that seems to be connected here.
- Original Message -
From: "Joe Bowser"
To: "dev"
Sent: Wednesday, 11 September, 2013 16:59
Subject: Re: addJavascriptInterface fails on Android API levels 17 and 18
(4.2.2 and 4.3)
What does this have to do with Cordova? It looks like you're building
your own bridge on Android.
Make sure that your Java version that you're building with supports
annotations. If not, you won't be able to add the Javascript
Interface.
On Wed, Sep 11, 2013 at 4:52 PM, dev at watch2web.com
wrote:
I recently changed the value of targetSdkVersion in my AndroidManifest.xml
from 16 to 18. They say, "Better late than never," but maybe not in this
case. I discovered that the change causes my app to white-screen on
startup on two Samsung Galaxy S4s -- both running API level 17 (4.2.2).
(On the five other devices I have -- all running API 16 or lower --
everything still works as if nothing has changed.) If I set
targetSdkVersion back to 16, the app works great on all devices, including
both Samsungs. I am using Cordova 3.0.0.
I have traced the problem to my onDeviceReady function, at the line where
it first tries to execute one of my @JavascriptInterface functions. (It
doesn't seem to matter which one.) Code snippet looks like:
(in main Activity)
appView.addJavascriptInterface(this, "MyJSI");
@JavascriptInterface
public void foo() { }
(in onDeviceReady)
if (window.MyJSI == undefined) console.log("javascript interface is
undefined");
else if (window.MyJSI == null) console.log("javascript interface is
null");
else if (typeof(window.MyJSI) == 'object') console.log("javascript
interface is an object: " + window.MyJSI);
else console.log("javascript interface is not an object");
window.MyJSI.foo(); // foo is just some method I wrote -- I've only
experimented with a few
On both "good" (API level <= 16) and "bad" (Galaxy S4, API level >= 17)
phones I get in the console output:
javascript interface is an object: [object Object]
On the "good" phones, everything continues, and I get all the logging that
comes from subsequent parts of the app. On the "bad" phone, I get:
Uncaught TypeError: Object [object Object] has no method 'foo'
and things pretty much stop.
You'd think I was in OK shape. I have a fix that involves changing one
character -- not even in code, just a settings file -- and it works on all
API levels. But NO, Google Play forbids lowering the targetSdkVersion. So
I need to fix this for real.
In searching, I found this issue from December. It isn't exactly what I'm
seeing since deviceready does fire for me. But a lot of the elements seem
very similar.
https://issues.apache.org/jira/browse/CB-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501660#comment-13501660
I'm happy to dig through Java source myself if it will help, but if so, I
could use a little guidance getting started.
Thanks,
Andrew
