I have created a script using Android studio. The script log into the app and do some insertion of data and open all fragments.
But when I add the script to my Robo test, it only get to the first screen, then waiting there for 5 minutes and finish with a Passed mark.
Anybody knows anything about this, please help.
I encountered the same problem and contacted Firebase support.
As per their response, it seems that the delay actions recorded in the Robo script by Android Studio (3.0.1) are extremely long (an hour or more). These long delays block the script execution.
For example the Robo script I recorded starts with this delay action -
{
"eventType": "DELAYED_MESSAGE_POSTED",
"timestamp": 1522050751149,
"actionCode": -1,
"delayTime": 3596480,
"canScrollTo": false,
"elementDescriptors": []
}
Notice that the "delayTime" set by Android Studio is 3596480 miliseconds which translates to 59.94 minutes. This value is incorrect.
The quick fix for this is to edit the script manually either by removing the faulty DELAYED_MESSAGE_POSTED events or by editing the "delayTime" values to something more realistic (5000 for example).
Firebase support says that this problem will be fixed in Android Studio 3.2 which is currently in canary.
Related
In using realbrowserlocusts class it appears that I'm limited in any exception handling.
The only reference that partially works is: self.client.wait.until(EC.visibility_of_element_located ....
In a failed condition where the element is not found the script simply starts over again. With the script I'm working with I need to maintain a solid session state; I need to throw and exception(report an error), log the user out and then let the script start over again. I've been testing out the behavior with the locust.py script that Nick B. created with several approaches to "try, except" and they work running without realbrowserlocusts (selenium only) but with it the execution just stops.
Any examples would be greatly appreciated.
In its current format I've been able to run 3x the amount of a browser-based load per/agent/slave than our commercial tool. My goal is to replace it with a locust/selenium approach.
locust-plugins's WebdriverUser has a little bit better exception handling I think. A failure to find an element will log a failed request and if you use RescheduleTaskOnFail (as in the the example) it will restart the task when that happens.
https://github.com/SvenskaSpel/locust-plugins/blob/master/examples/webdriver_ex.py
I am having troubles with the resetAuth() function. I implemented it roughly like this example, but I have no idea when it is being called. Adding a console output and observing the Stackdriver Log tells me that this function is never being called during what I would call a normal workflow.
The documentation is weirdly brief and is missing this part about why I need to implement it and when it is being called. Do I need to call resetAuth() manually on some point? Is there a button somewhere that calls this function?
I'm using the AuthType USER_PASS by the way and everything else seems to work just fine after some investigation and debugging.
I found this document called Community Connectors Developer Launch where, among other things, the following it listed (as of 2018-07-30):
What's next: Upcoming changes and improvements
Some of the features and improvements we'll be working on in the
coming months include:
Configuration and Authentication
Capability to execute the resetAuth function of community connectors from within Data Studio.
Does this mean that calling resetAuth() is currently not yet implemented?
resetAuth is called when the user revokes access to the connector via the https://datastudio.google.com/datasources/create endpoint.
There was a bug that caused this function to not be called for certain auth types, but it has been resolved.
I am trying to deploy a scheduled azure web job. I have everything working except the job is being deployed as 'OnDemand'.
I am building and releasing using Visual Studio Team Services.
I have set up as follows:
The contents of the webjob-publish-settings.json are
{
"$schema": "http://schemastore.org/schemas/json/webjob-publish-
settings.json",
"webJobName": "testCIJob"
}
And the settings.job are:
{"schedule": "0 0/10 0 0 0 0"}
which I believe is every 10 minutes, every day.
I have also linked my web job to my web app and have a webjobs-list.json file with the content:
{
"$schema": "http://schemastore.org/schemas/json/webjobs-list.json",
"WebJobs": [
{
"filePath": "../AscendancyCF.CmaServiceWebJob/AscendancyCF.CmaServiceWebJob.csproj"
}
]
}
I have got this far searching the web but I find a lot of the information is rapidly out of date. an example
Also, I don't want to overload the question with information so if anyone needs more please just ask and I'll try and provide.
How do I get my web job to deploy on the schedule?
A similar question is here:How to deploy a webjob through CI in VSO with vNext.
Try the solutions in it:
You can use the cron expression to create the webjob scheduler if your
app is running in Basic or High mode. Refer to this link for details:
Create a scheduled WebJob using a CRON expression
Otherwise, you need to enable continues delivery of Azure Webjobs.
According to the Deploy Webjobs with Visual Studio article, the content of the webjob-publish-settings.json should be something like:
{
"$schema": "http://schemastore.org/schemas/json/webjob-publish-settings.json",
"webJobName": "WebJob1",
"startTime": "2014-06-23T00:00:00-08:00",
"endTime": "2070-06-27T00:00:00-08:00",
"jobRecurrenceFrequency": "Minute",
"interval": 10,
"runMode": "Scheduled"
}
That should run every 10 minutes until 2070. There is one note on the article tho that you might want to keep in mind:
If you configure a Recurring Job and set recurrence frequency to a
number of minutes, the Azure Scheduler service is not free. Other
frequencies (hours, days, and so forth) are free.
I have a Windows Phone 8.1 app with Google login, which uses the
GoogleWebAuthorizationBroker.AuthorizeAsync
method. 90 % of the time, the authentication works, however, occasionally, the app just crashes on this line (I am logging right before it, so I am sure). I have the call wrapped inside try - catch, but that doesn't seem to work - exception is never caught.
I am also sure I am calling the method on a UI thread, I am using the DispatcherHelper from MVVMLight for that.
The fact that I am not able to reproduce the crash complicates this a lot, I have not experienced it with debugger attached, only in Release mode, on target device, run locally.
Do you guys have any ideas / clues / pointers? I know I'm not providing a lot of information, but I don't have any..
EDIT> So the error now happened with debugger attached - and the app just froze, last message in Ouput window was
"WinRT information: Cannot get credential from Vault"
But that's normal behavior..
I had a non-OSGi application. To convert it to OSGi, I first bundled it up and gave it a simple BundleActivator. The activator's start() started up a thread of what used to be the main() of my app (and is now a Runnable), and remembered that thread. The activator's stop() interrupted that thread, and waited for it to end (via join()), then returned. This all seemed to be working fine.
As a next step in the OSGiification process, I am now trying to use OSGi configuration management instead of the Properties-based configuration that the application used to use. So I am adding in a ManagedService in addition to the Activator.
But it's no longer clear to me how I am supposed to start and stop my application; examples that I've seen are only serving to confuse me. Specifically, here:
http://felix.apache.org/site/apache-felix-config-admin.html
They no longer seem to do any real starting of the application in BundleActivator.start(). Instead, they just register a ManagedService to receive configuration. So I'm guessing maybe I start up the app's main thread when I receive configuration, in the ManagedService? They don't show it - the ManagedService's updated() just has vague comments saying to "apply configuration from config admin" when it is passed a non-null Dictionary.
So then I look here:
http://blog.osgi.org/2010/06/how-to-use-config-admin.html
In there, it seems like maybe they're doing what I guessed. They seem to have moved the actual app from BundleActivator to ManagedService, and are dealing with starting it when updated() receives non-null configuration, stopping it first if it's already started.
But now what about when the BundleActivator's stop() gets called?
Back on the first example page that I mentioned above, they unregister the ManagedService. On the second example page, they don't show what they do.
So I'm guessing maybe unregistering the ManagedService will cause null configuration to be sent to ManagedService.updated(), at which point I can interrupte the app thread, wait for it to end, and then return?
I suspect that I'm thoroughly incorrect, but I don't know what the "real" way to do this is. Thanks in advance for any help.
BundleActivator (BA) and ManagedService (MS) are callbacks to your bundle. BundleActivator is for the active state of your bundle. BA.start is when you bundle is being started and BA.stop is when it is being stopped. MS is called to provide your bundle a configuration, if there is one, or notify you there is no configuration.
So in BA.start, you register your MS service and return. When MS is called (on some other thread), you will either receive your configuration or be told there is no configuration and you can act accordingly (start app, etc.)
Your MS can also be called at anytime to advice of the modification or deletion of your configuration and you should act accordingly (i.e. adjust your app behavior).
When you are called at BA.stop, you need to stop your app. You can unregister the MS or let the framework do it for you as part of normal bundle stop processing.