Has anyone found a way to keep Google Home apps you've developed alive for longer than 29min? My app is only reachable on the actual device if I'm actively developing for it. So literally to interact with it I need to have pushed a command to it within the last 29min. When setting the invocation name
./gactions preview -action_package=action.json -invocation_name="wake up word"
I get back this message:
Pushing action 'wake up word' for testing...
'wake up word' is now available for you until 2017-05-03 4:57PM CDT (29 minutes from now)
If I attempt to invoke it after that timeline, its not reachable. Kinda sucks.
Simply add a preview flag to the command.
./gactions preview -action_package=action.json -preview_mins=999999999 -invocation_name="wake up word"
-preview_mins=999999999 effectively sets it for 2000 years.
Related
I uploaded my app around an hour ago and it was successfully uploaded and i got the tick mark. I waited for half hour and nothing happened, no emails , the build wasnt being shown on AppStoreConnect under Builds(testflight) and Activity.
Basically , no traces of what i did. So i tried uploading and i got error that this binary already exists with build number. So i changed the build number and uploaded again , and even now nothing is being shown under builds and under Activity. Also no mails.
Is there something i missed ? Or is there something with AppStoreConnect ?
Under normal circumstances how long do we have to wait? (p.s this is my first app)
Edit: I tried again n it was visible in activity tab for a few mins (PROCESSING). Now its gone and i cant find anything anywhere about it?!
This usually means that there was an error while the binary was being processed (and checked).
Sometimes there are warnings which should be fixed and sometimes there are errors. If an error occured, App Store Connect will then stop processing the binary file and send you an email, which contains more details why the app binary was being rejected (automatically).
You should check your email account for additional information.
I am creating a newsstand application. the application is ready, now i am trying to upload the app in apple store using Application Loader. While uploading the zip file its showing the error message as
Unable to process application info.plist validation at this time due to a general error (1095)
I googled this in the net, but did not find the solution still.
This is clearly an Apple server issue, not an Xcode/iOS/OSX issue. Just wait patiently and Apple's servers will catch up to the traffic, or solve whatever issues they're having at their end.
If you're anxious, feel free to just sit there and restart Xcode until it works - but it's not restarting Xcode, only the time you waste that's solving the issue.
While you're waiting, run your apps in Instruments and solve some performance issues ;)
I just had this error. I waited an hour and tried again with the exact same build and it was all good. Vote for it being Apple's temporary glitch.
I had the same problem. I closed Xcode, restart my computer and it worked.
One possible problem to this is corrupted png files. The png files should not be interlaced
I found a solution to the problem.
If you're using Xcode 4+, you don't have to use Application Loader anymore. Instead you should archive your project in Xcode (Product->Archive). It will then open the organizer, where 3 buttons are displayed. Hit the submit button.
If you've created an entry for your app with Itunes Connect, you should be able to choose that from the list, and then select your distribution profile. Then hit the next button, and you should get a message, that tells you, that your app has been submitted.
At least that worked for me.
Use Application Loader.
I'm getting this a lot today.
Application Loader worked.
XCode > Project > Archive
XCode > Organizer > Distribute > Enterprise/add Hoc > Save As
Saves as YOURAPP.ipa.
Make sure Save for Enterprise Deploy remains UNCHECKED.
Download latest Application Loader.
tap 'Deliver Your App'
make sure new version in itunes connect in WAITING FOR UPLOAD state
Click on Activity... button
TIP: open Console.app to see XCode Validation errors
Click on ALL MESSAGE on list of logs on right.
Then in search enter 'XCode' or 'Application Loader'
to monitor any errors with your upload.
Note:
I did all this and still got email about missing 120x120 icons.
Forgot to update them in Build Target > General Tab
List of new icon requirements for iOS7
http://www.icenium.com/resources/forums/icenium-general-discussion/missing-recommended-icon-file
Another reason why this can happen is the duplicate product name. Despite your app names, executable names, display names or bundle IDs are different, if the product name exists in your current apps this error is gonna occur.
"The server returned an invalid response. This may indicate that a network proxy is interfering with communication, or that Apple servers are having issues. Please try your request again later.""
Reset The internet connection.
Reopen the xcode.
Set the profile again.
Clean build.
And Archive the build.
Works perfect for me (With in 5 minutes no need to wait).
Thanks
It's just the time, because you can't control Apple's Server's traffic problem, We all merely become the victim of that..So cut the long story short...
By restarting XCODE may work but everyone as in my case, i tried by restarting XCODE, SYSTEM, ROUTER and anything and everything possible, only error name had changed from "The network connection was lost" to "The request timed out" and vice Versa..!
Just think at what time less people would be accessing the sever...
PS: Only perseverance can help you in this way..keep redialing..And WAIT and WATCH:P
I solved ... :)
Please remove all your icons and splash image also remove icon Files and icons File( IOS 5 ) from info.plist and then add all your icons to app bundle ...
After this update info.plist iconFiles field add desired name of icons....
And last but not least remove Provisioning profile from developer portal and recreate it ...
Clean your build and Archive it and using Application Loader submit it to AppStore ...
it work for me and i think it may help you...
Not every time not it is Apple server issue,sometime we did some bad linking according to me :)
I'm using Selenium Client 2.4.0 on Mac 10.6.6 with Firefox 5. Using the WebBackedSeleniumDriver, I'm running a "selenium.getEval" command that causes a Firefox warning,
"Warning: Unresponsive script.
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
Script: resource://fxdriver/modules/utils.js:9161"
The value of "dom.max_script_run_time" about:config was "0", which should disable the above dialog altogether. Yet, I still get the dialog. Is there any way to prevent the warning dialog from appearing?
dom.max_script_run_time is the right preference but it only applies to web pages. Browser UI (and extensions like fxdriver are part of it) are restricted by the preference dom.max_chrome_script_run_time however (default value is 20 seconds). You should set it to 0 as well.
Documentation: https://developer.mozilla.org/en/Preferences/Mozilla_preferences_for_uber-geeks#DOM_preferences
Regardless of what you have setup in your profile, during startup, Selenium sets both values to 2417483647 to try and get around the browser warning. However, because the value is so large, FF ends up ignoring it and using the default value of 10/20 instead. This is true even if you're pointing Selenium to use your profile as the template.
The best way I've found to get around this is to specify
-timeout nnnn
to the Selenium Server startup args. This sets both the server and client (browser) timeout values.
Although this thread is quite old, the problem still exists with current selenium and firefox builds. I've got these really annoying messages quite a long time now, without a good fix. Asking the devolopers / mailing list / google usually results in the following answer:
The javascript used in your application is too fat or buggy, improving your scripts will help.
As this is no option in a larger company, when you depend on a framework you have no access to, i decided to search for the root cause for myself.
The core of the problem is the fact, that selenium overrides profile settings if you specify the -timeout nnnn parameter. So creating a custom firefox profile template and setting the dom.max_script_run_time and dom.max_chrome_script_run_time will not work here.
As soon as you specify the -timeout parameter, these two settings are overriden with the value you provide to the parameter. After hours of debugging and testing i noticed some facts:
If you don't specify -timeout, firefox runs for exact 30 minutes, without one script timeout. After that, firefox gets killed by selenium with a SeleniumCommandTimedOutException
As soon as you specify -timeout (no matter which value), the script timeout appears after several seconds or minutes. These messages are independent to the timeout-value.
The -browserTimeout parameter isn't usefull as i haven't found where this parameter is used in the source.
As we have some testsuites that run longer than 30 minutes we have 2 options to fix this behaviour:
Rewriting our testsuites and splitting them to run within the 30 minutes window
Patching selenium to run longer than 30 minutes
Do not use the -timeout parameter.
So choose for yourself which option is better. I created a small and simple patch for the HTMLLauncher.java to allow 90 minutes instead of the default 30.
diff --git a/java/server/src/org/openqa/selenium/server/htmlrunner/HTMLLauncher.java b/java/server/src/org/openqa/selenium/server/htmlrunner/HTMLLauncher.java
index c2296a5..310b39f 100644
--- a/java/server/src/org/openqa/selenium/server/htmlrunner/HTMLLauncher.java
+++ b/java/server/src/org/openqa/selenium/server/htmlrunner/HTMLLauncher.java
## -146,6 +146,16 ##
launcher.launchHTMLSuite(suiteURL, browserURL);
sleepTight(timeoutInMs);
+ // SFR, Patch 2013-10-17: To get rid of the damn SeleniumCommandTimedOutException
+ // we allow the Suite to run 3 times as long as per default (30 min -> 90 min).
+ if(results == null) {
+ log.warning("SFR, Patch 2013-10-17");
+ sleepTight(timeoutInMs);
+ }
+ if(results == null) {
+ log.warning("SFR, Patch 2013-10-17");
+ sleepTight(timeoutInMs);
+ }
launcher.close();
I'll upload a pre-compiled jar with the above patch if necessary.
Go the hidden configuration page in Firefox by typing about:config in the address bar . (make sure that you are doing this for the profile you are using for selenium) In the 'Filter' box, type script_run_time.
This will narrow the options to dom.max_script_run_time and dom.max_chrome_script_run_time. Right-click it and choose Modify. A box pops up. Change the number to something bigger like 40. This is the maximum time a script can run before Firefox considers it 'unresponsive'. If you can’t find the string in the about:config page, create it by right-clicking anywhere and then choose New—> Integer and enter there name and values (when asked)
Set it to a very large number instead of "20"?
The dom.max_script_run_time setting is in seconds. Changing it from 10 to 20 just doubles the amount of time to wait. A value of 0 will disable it, but this could result in a run-away script locking up your browser. You might just use a really large value.
More details here:
http://kb.mozillazine.org/Dom.max_script_run_time
This issue appears for me when I do Selenium calls while web application is running some own crappy slow JS. Even if I catch the popup and retry after few seconds, FF is not responsive to Selenium anymore. The solution is to just put sleep 10 before otherwise any Selenium call would result in popup.
Due to the recently added "feature" in IE8 where new windows are automatically associated with a single session, some of our code is behaving erratically.
This is because a separate app would launch a new IE window when it was activated, and once the user was finished, close the window. This worked fine in IE7 because the session information in the windows stayed separate. However in IE8, since the session is shared among IE windows, we find that the "pop up" app would corrupt the session on the first app.
I have read about the nomerge switch, so that is a workaround, but I was wondering if there was a way of working the solution into the "CreateObject" of vbscript; i.e:
Dim ieWin As Object
Set ieWin = CreateObject("InternetExplorer.Application")
Is there a way of sending parameters when calling the CreateObject function?
No, there's no way to use COM to create an IE instance that specifies this behavior (or any of the others, e.g. InPrivate, No Add-ons, etc). The only thing you can do is create an automation instance that defaults to MediumIL using the CLSID provided for that purpose. http://blogs.msdn.com/b/ieinternals/archive/2011/08/03/internet-explorer-automation-protected-mode-lcie-default-integrity-level-medium.aspx
If you have control over the web application you are loading with your IE window you can set it's session to "cookieless" (http://msdn.microsoft.com/en-us/library/aa479314.aspx) which will avoid the issues you're having with multiple instances.
The solution we ended up going with, although it's more a work around than anything else - was assigning a new url to the popped up window.
Previously, it worked as follows:
Call centre agents would be using our internal app for other duties
e.g. "http://internalsite/somepage.faces" on a day to day basis.
When they got a phone call, a third party app would fire up
"http://internalsite/customerdetails.faces". This caused the issues mentioned above.
The solution we went with:
We assigned "http://internalsite/customerdetails.faces" it's own url e.g."http://customerdetailminisite/customer.faces".
This way the call center agent could keep their main window open for other stuff and still be able to handle calls when they came in.
I have been developing an AJAX application using jQuery and Microsoft Seadragon technology.
I need to have access to the html5 canvas function toDataURL.
With Google Chrome, the same origin rule applies to this function which means that a page run locally (with the file:/// in the URL) failed to satisfy the same origin rule and an exception is thrown.
With Chrome 7, starting the application with --allow-file-access-from-files option, allows to call canvas.toDataURL() from local files.
However, it seems that starting the Chrome Beta 8 with the same option (--allow-file-access-from-files) does not allow the call canvas.toDataURL() on the local file.
Does Chrome gave up on the --allow-file-access-from-files option or it has just been disabled since it is a Beta release and not a full release?
Thanks!
Looking at the issues for this shows that the whole --allow-file-access-from-files thing was rushed.
"Firefox does it.."
"How can we do it?"
some time passes
"Here are the patches"
"Passes! On trunk wonder what happens in the next dev release"
"Ahhh it's broken" "Use the command line option" "ok"
"We shipped!"
"WTF guys? You broke all my stuff! Why didn't you tell us earlier?"
silence
On to your Problem
Indeed it seems that this is something special to the beta, I'm using Chrome 8.0.552.5 dev here and --allow-file-access-from-files works like expected, I've also tested this with Chromium 9.0.592.0 (66889) were it also works as expected.
I suspect there have been some changes on the dev branch. Unfortunately, finding something on chromium's issue tracker is nearly impossible.
Did you close all chrome instances before opening with the command line argument? You have to do that to make that parameter work.
To summarize all answers so far.
Before running chrome, make sure there are no chrome processes running.
Windows
-allow-file-access-from-files
(with one dash)
Linux
--allow-file-access-from-files
(with two dashes)
I've found a way around the issue using a JavaScript/Flash approach. If flash is compiled in the Local Only security sandbox, it has full access to local files. Using ExternalInterface, JavaScript can request a Flash Application to load a file, and Flash can pass the result back to JavaScript.
You can find my implementation here: https://code.google.com/p/flash-loader/
The trick that woked for me is that you have to give the absolute path of the file and not just file name in your HTML code. e.g file://... instead of direct name even though you are accessing the file in the same directory. It will work!