if i handle accept all permissions through capabilities but this make accept update alert of app
but i need to cancel update alert of app
when i tried to handle it manually , the appium is pressed accept update automatically very fast before cancel it
is there any idea how to handle it
i can not cancel the update alert before appium accept it
it is very fast
You are probably going to have to start handling the alerts in your code. There isn’t any way to specify which ones to accept and which to dismiss in capabilities.
the issue that you do not have timing of appearance of alerts so i made it accept by capabilities but i need to dismiss the alert of updating app
It does take more work to handle alerts manually. If your code can’t do that then maybe this is a manual test until you change the code. I would encourage you to take a look at the factory pattern and apply it to how you check for screens. If you do something like this, you can handle alerts as screens in what I consider the most elegant way:
yes. i use factory pattern but i have the same issue that i can not determine exactly when alert of update app will appear , if i will make want time , it will be delay the app and if no update , i will use tray and catch and it will also delay
please if you have a snippet of code to deal with any pop up alert as screen , please add it
So for our code, we call the screen factory a lot. It caches the current screen and if the initial checks show same it returns the same screen again and again. Mainly this is to quickly get the state of the app and react to it. In the screen factory in several places we handle any alert with a method. I think we’ve talked before about how my code is in Ruby, and there is a lot of abstraction in this method. Also lots of comments:
# check_for_alert_screens
#
# see if an alert is open and act on it
def check_for_alert_screens(current_screen_classes)
# This decision tree checks for and accepts/dismisses Alerts
if current_screen_classes.include?(dictionary.alert_element)
log.debug 'looking for alerts in the screen factory'
# This would mean that an unexpected alert has popped up
# take care of the alert & then continue to get the screen
# If there is more than one Alert we should handle that also
while current_screen_classes.include?(dictionary.alert_element)
log.debug 'in the while loop looking for alerts in screen factory'
alert_screen = AlertScreen.new.map_text_to_alert_opts
log.debug alert_screen
# This sleep is to let the animation finish in the Enterprise App
# It was put here because of this bug in WebDriver:
# https://github.com/facebook/WebDriverAgent/issues/372
log.debug 'Sleeping for 3 seconds while animation finishes.'
sleep(3)
current_screen_classes = apm.appium_module.get_page_class
end
end
current_screen_classes
end
current_screen_classes param is populated with a call to apm.appium_module.get_page_class with apm being the variable we use to store the driver.
The AlertScreen class has a hash that it can check to see whether to accept or dismiss the alert based on booleans (no enums in Ruby) that looks like:
# set_default_options
#
# set_default_options creates the hash containing all default options for handling
# alerts
def set_default_options
{
'alert_name' => boolean,
'alert_name' => boolean
}
end
And the alerts are matched with another hash to the screen text, and true being accept while false equals dismiss. Note that these hashes are public, so if at runtime we want to change the behavior we can just set that boolean in setup, and we have another method that will reset the hash to default and is used in the cleanup for tests that need such things.
I know this isn’t code you can use, but I hope it gives you some ideas.
Thanks for ur great effort to help but i do not know any thing about Ruby language .I use java code
if you have this code by Java Language , it is very kind of you