Проверка на десятки признаков в ZennoDroid Enterprise за пару секунд

[Мамикон]

Zennodroid Enterprise пользуюсь с первых дней публикации и создавал много шаблонов под свои нужды, по сути основная логика шаблонов - это поиск совпадения на экране , а именно текстовая проверка , получить координаты, получить ширину и/или высоту , клик, получить данные все это каждый раз или по несколько раз обращаюсь к XML структуре , а это вне зависимости от модели телефона занимает не малое время.
Раньше мои проверки выглядели +- вот так

Теория

В первую очередь приступил к вторичным проверкам из серии ошибка приложения, раскрыта шторка, смс , всплывашки от операторов, будильник, PlayMarket , нет интернета, пуш уведомления, запрос геолокации , капча и тд и все они могут вклинится во время работы иных шаблонов и нарушить всю логику работы шаблонов.

Было принято решение реализовать универсальную проверку, Но стандартными методами разрастались шаблоны и очень большие задержки были и было принято решение попробывать сократить время исполнения шаблона без ущерба для стабильности и естественно не обошлось без советов из участников нашего форума.

Первая реализация

Выстроил логику
1) Получил структуру XML
2) Положил содержимое в список
3) Чекаю по очереди все признаки (не только текст)
4) Если совпадение на вторичные признаки то сразу на решение
Сейчас выглядит вот так

Практика

Практически во всех моих шаблонах используется эта универсальная проверка и на этом же принципе реализован чуть более усложненный вариант уже под логику шаблонов используя белый и черный список .

1) Получил xml
2) Записал в список
3) Поиск по признакам (не только текст)
4) При совпадении получаю координаты x1,y1,x2,y2 помог @xDIXIx

Далее использую обработанные данные для последующих действий.

Приложил простейший пример реализации на 23 самые необходимые на мой взгляд проверки, на выходе или решение (закрытие или свайп) и/или совпадение в переменной, все это отрабатывает за 1-2 секунды.

 

[radv]

Приложил простейший пример реализации на 23 самые необходимые на мой взгляд проверки, на выходе или решение (закрытие или свайп) и/или совпадение в переменной, все это отрабатывает за 1-2 секунды.

А можете сделать скриншоты или описания каждой проверки, чтобы их не только в файле проекта их можно было посмотреть?

 

[Мамикон]

А можете сделать скриншоты или описания каждой проверки, чтобы их не только в файле проекта их можно было посмотреть?

1-2 проверка шторки и закрытие их
3-5 ошибка приложения и приложение не отвечает (выводит в переменную)
6-12 проверка на плеймаркет и закрытие его
13 проверка на плеер и закрытие
14 проверка на камеру и закрытие
15-16 проверка на главную телефона (выводит в переменную)
17 проверка на плеер и закрытие
18 проверка на часы/будильник и закрытие
19 проверка на обновления (приложение Яндекс на пол экрана)
20 проверка на поделиться и закрытие
21 проверка на активную строку браузера и закрытие
22 -23 проверка на контакты (нечаяно нажали на номер телефона) и закрытие
По сути добавить можно любой признак и последующее действие

 

[Dgo]

Еще можно это все в 1 кубик c# положить и будет всего лишь 1 кубик

 

[Мамикон]

Еще можно это все в 1 кубик c# положить и будет всего лишь 1 кубик

Открывал хоть шаблон в Enterprise?

 

[myndeswx]

Nice! After using ZD for a while I realized to use the same method, just get the XML once and regex the contents to see what state is it in. It is also important to check the 'bounds' because the element can be on the XML but not visible on the screen (need to scroll if you need to click it).

 

[Dmitriy Ka]

Открывал хоть шаблон в Enterprise?

Вообще он прав, а что в Enterprise шаблон будет как-то по другому работать?

Идея прикольная, только ее можно сделать чуть лучше и уйти от работы со списком (пробегаться по списку строк XML ну такое себе, если взять во внимание, что там будет куча ненужных строк, а мы их все проверяем на Contains)

Если мы работаем на С#, то у нас есть такой интерфейс: instance.DroidInstance.AppiumDriver;
Он имеет методы, которые позволяют находить элементы и если элемент не найден возвращает null.

Можно сделать что-то типа такого:

var driver = instance.DroidInstance.AppiumDriver;
var text = project.Variables["poisk"].Value; // poisk - переменная из шаблона
var element = driver.FindElementByXPath($"//*[@text=\"{text}\"]");
if (element == null)
    throw new Exception("Not found: " + text);

Если элемент будет найден выйдем по зеленой, если нет, по красной.

 

[Мамикон]

Вообще он прав, а что в Enterprise шаблон будет как-то по другому работать?

Идея прикольная, только ее можно сделать чуть лучше и уйти от работы со списком (пробегаться по списку строк XML ну такое себе, если взять во внимание, что там будет куча ненужных строк, а мы их все проверяем на Contains)

Если мы работаем на С#, то у нас есть такой интерфейс: instance.DroidInstance.AppiumDriver;
Он имеет методы, которые позволяют находить элементы и если элемент не найден возвращает null.

Можно сделать что-то типа такого:

var driver = instance.DroidInstance.AppiumDriver;
var text = project.Variables["poisk"].Value; // poisk - переменная из шаблона
var element = driver.FindElementByXPath($"//*[@text=\"{text}\"]");
if (element == null)
    throw new Exception("Not found: " + text);

Если элемент будет найден выйдем по зеленой, если нет, по красной.

Повторюсь шаблон хоть открывали?
Ну ХЗ ...... сколько раз по "Вашему сценарию" надо будет обращаться к телефону для 20 проверок? 20? а в Этом сценарии всего 1

 

[Dmitriy Ka]

Повторюсь шаблон хоть открывали?

Конечно открывал, поэтому и говорю работа с XML через списки сомнительное решение.

Ну ХЗ ...... сколько раз по "Вашему сценарию" надо будет обращаться к телефону для 20 проверок? 20? а в Этом сценарии всего 1

Я точно не знаю, как разработчики реализовали методы FindElement, но я думаю что данные методы не обращается к телефону, а работает напрямую с XML, то есть так же один раз обращаемся к телефону получаем XML и работаем с ней через xPath, как крутые ребята

Ну и если душнить, то зачем мы возвращаем -1 и следующим кубиком делаем проверку на это значение, если мы можем сразу в C# уйти по красной ветке.

Спойлер: Так удобней

 

[Мамикон]

Конечно открывал, поэтому и говорю работа с XML через списки сомнительное решение.



Я точно не знаю, как разработчики реализовали методы FindElement, но я думаю что данные методы не обращается к телефону, а работает напрямую с XML, то есть так же один раз обращаемся к телефону получаем XML и работаем с ней через xPath, как крутые ребята

Ну и если душнить, то зачем мы возвращаем -1 и следующим кубиком делаем проверку на это значение, если мы можем сразу в C# уйти по красной ветке.

Спойлер: Так удобней

Посмотреть вложение 122300

Номер строки можно и нужно использовать для дальнейшей обработки (взять строку под номером N , получить оттуда координаты и прочие данные )

Душнить точно не надо, но вот параллельно с к критикой было бы справедливо условно доработать этот шаблон в выложить на форум, иначе это все просто условное повышение самооценки .

 

[Мамикон]

но я думаю что данные методы не обращается к телефону

Каждый раз обращается к телефону

 

[Dmitriy Ka]

Номер строки можно и нужно использовать для дальнейшей обработки (взять строку под номером N , получить оттуда координаты и прочие данные )

Но в вашем шаблоне это не используется. Открою секрет, через методы FindElement(), мы тоже можем получить координаты и прочие данные.

Душнить точно не надо, но вот параллельно с к критикой было бы справедливо условно доработать этот шаблон в выложить на форум, иначе это все просто условное повышение самооценки.

Это и было сделано:

Спойлер: Тык

Вообще он прав, а что в Enterprise шаблон будет как-то по другому работать?

Идея прикольная, только ее можно сделать чуть лучше и уйти от работы со списком (пробегаться по списку строк XML ну такое себе, если взять во внимание, что там будет куча ненужных строк, а мы их все проверяем на Contains)

Если мы работаем на С#, то у нас есть такой интерфейс: instance.DroidInstance.AppiumDriver;
Он имеет методы, которые позволяют находить элементы и если элемент не найден возвращает null.

Можно сделать что-то типа такого:

var driver = instance.DroidInstance.AppiumDriver;
var text = project.Variables["poisk"].Value; // poisk - переменная из шаблона
var element = driver.FindElementByXPath($"//*[@text=\"{text}\"]");
if (element == null)
    throw new Exception("Not found: " + text);

Если элемент будет найден выйдем по зеленой, если нет, по красной.

Каждый раз обращается к телефону

Откуда такая уверенность?
Метод работает с XML, который уже подгружен в instance, зачем ему обращаться к телефону?


Спорить больше не вижу смысла, идея хорошая, реализация сомнительная. Возьму себе на вооружение, но только перепишу под себя, без листов

 

[Мамикон]

Но в вашем шаблоне это не используется. Открою секрет, через методы FindElement(), мы тоже можем получить координаты и прочие данные.


Это и было сделано:


Откуда такая уверенность?
Метод работает с XML, который уже подгружен в instance, зачем ему обращаться к телефону?


Спорить больше не вижу смысла, идея хорошая, реализация сомнительная. Возьму себе на вооружение, но только перепишу под себя, без листов

Вопрос лишь в том что выложенный в открытый рабочий, доступный для понимания всем шаблон критикуешь по сути .........
Отвечу 2 поговорками
1) Критикуешь - предлагай!
2) Нет предела совершенству!!!

 

[Мамикон]

Но в вашем шаблоне это не используется. Открою секрет, через методы FindElement(), мы тоже можем получить координаты и прочие данные.

Это статья про подход к работе (МЕТОД) , и в нем приведен пример реализации этого подхода в виде этого шаблона.....
Прошло тем более почти пол года и естественно прогресс не стоит на месте........

 

[Dmitriy Ka]

1) Критикуешь - предлагай!

Вот поговорка:

Не согласен - критикуй, критикуешь - предлагай, предлагаешь - делай, делаешь - отвечай

По моему я все чекпоинты выполнил

 

[Dgo]

Открывал хоть шаблон в Enterprise?

у меня нет зенодроид по этому не могу открыть, но судя по описанию идет проверка xml на совпадения, это ооооочень громоздко. Не проще все сделать в одном кубике c#, через массив перебирая элементы и находя совпадение. можно для этого даже отдельный класс написать и положить в общий код, загоняя документ и ожидая получения совпадения.

 

[Мамикон]

Закидывайте рабочие варианты, но в любом случае будет громоздко именно по тому что у каждого совпадения есть свое решение (действие) или несколько решений при совпадении с другими условиями.