EgorBolotow, да, но в случае с кликерами взаимодействие происходит через интерфейс. То есть вам нужно придумать, как скрипт будет различать контакты. Обычно это делается через чтение пикселей с экрана. Например, в ватсапе есть аватары у каждого юзера и там наверняка есть уникальные пикселы по цвету и расположению. С другой стороны, стоит контакту поменять свой аватар, и кликер сломается. Ещё можно попытаться считать номер телефона или имя и т.д.
Кликеры обычно для простых задач используют. Например, контакт уже открыт, его не нужно выбирать, и с фикисрованным интервалом надо что-то писать.
Для сложных задач лучше уже не кликер, а какое-то более продвинутое решение с внедрением в логику работы whatsapp. Например, можно сделать браузерное расширение.
xmoonlight, нет. Если длина не фиксирована, то где-то там сразу до/после (зависит от структуры пакета) будет указана длина, которая будет участвовать в попытке собрать пакет.
Но, как я говорил выше, многое зависит от нюансов. Если нужно шифрование, например, то всё сильно усложняется.
Kalombyr, контрольная сумма - это алгоритм подсчёта. Да, я его предлагаю, но без деталей, которых я не знаю. Например:
- как часто встречаются ошибки
- насколько важно беречь процессор от нагрузки
- фиксированный ли замер пакета (можно ли его сделать таковым)
- какой средний и максимальный размер пакета может быть
- непрерывен ли поток данных, и что там в перерывах
- характер ваших данных (насколько они случайны или есть закономерность)
- нужно ли противодействие хакерам
- соблюдение каких-то стандартов, продиктованных задачей
- и т.д.
Все эти нюансы, конечно же, влияют на выбор. Контрольная сумма здесь - это как бы вилка, которую вы дальше можете прикрутить и обыграть так, как вам нужно. Можете выбрать сложную хеш функцию, можете выбрать разрядность и т.д.
Контрольная сумма выигрывает простотой реализации. Берём для неё 64 бита. Добавляем соль, чтобы исключить типичную ситуацию, когда поток состоит из нулей. Можете сами посчитать, каков шанс, что пакет случайно соберется сам. К тому же сборка следующего пакета начнётся сразу после предыдущего. Так что считать ошибку можно лишь в первом пакете (при условии, что ошибки вообще достаточно редки). Плюс в самом пакете должна быть какая-то структура, скорее всего. Хотя бы его длина (если она не фиксирована). Это тоже как бы плюс к разрядности контрольной суммы.
Конечно, ошибка испортит пакет, и тогда придётся искать начало следующего попытками собрать его. Но если ошибки так уж прям часты, то скорее всего нужно уже не алгоритм искать, а фиксить саму среду, по которой передаются данные. А чисто алгоритмически можно увеличить разрядность. Поднимите её до 128 бит, это уже астрономическая точность, хоть и не 100%. При такой точности ваше устройство скорее сгорит, утонет или будет украдено, чем допустит ошибку в пакете. Поднимите ещё, если мало.
Полностью решать задачу за вас я и не собирался. Просто отвечаю на вопрос про "простой и быстрый алгоритм кодирования/декодирования байт". Ответом является контрольная сумма. Точнее, ссылка на статью вики про хеш-функции. А дальше сами думайте, как вам там удобнее. Хотите разделитель - пожалуйста, делайте. Можете перед пакетом ставить какой-то неповторимый разделитель. Если он вдруг будет искажен в пакете, это тоже будет означать потерю пакета, но как по мне - слишком много информации тратится и слишком мало выхлопа в плане проверки пакетов по сравнению с контрольной суммой, в которой можно просто наращивать разрядность, и точность будет расти по экспоненте.
Kalombyr, да, но в целом не обязательно. Само совпадение с контрольной суммой и может быть сигналом начала. А последующие "пакеты" лишь подтвердят "гипотезу". Главное, чтобы разрядность была достаточно большой. И контрольная сумма - это самый простой вариант, когда лень пилить более сложный алгоритм создания хеша.
Уточните, в чём именно проблема. И что такое "ввести массив". Ведь массив может формироваться разными способами. Например, можно ввести строку, где значения элементов массива разделены запятыми. Для такого способа нужен соответствующий алгоритм. А у вас задумка какая?
Сразу видно, что функция outputChatBox отличатся от print в худшую сторону - не кушает много параметров. Похоже, что не кушает более одного. Так что вместо: outputChatBox(a,b,c,d)
Придётся писать:
Я бы даже свою функцию-обёртку сделал, более удобную, чисто для отладки.
Пока не ясно, чему равны login и password (аргументы функции playerRegister). Не нужно мне их писать. Отладкой занимаетесь вы, а не я. Или так и будем дальше - я вам код, а вы мне результат? Каждый раз, когда вы что-то выясняете, вы отсекаете примерно половину вариантов ошибок, коих миллионы. Например, если в login какая-то дичь, то дальше нужно искать там, где вызывается playerRegister. А если с login всё в порядке, то нужно детальнее смотреть, как работает getAccount.
Чтобы ответить, нужно вникнуть в условия задачи, вникнуть в устройства вашего кода, и чуть ли ни заново придумать решение. У вас в голове всё это уже есть, так что очевидно, что вам проще немного додумать решение, чем другому программисту вникать с нуля.
P.S. И код лучше вставлять в сам вопрос, равно как и прочие условия (под спойлер). Всякие ссылки уменьшают шанс ответа. Куча инфы и грузилова тоже уменьшают шанс ответа. В идеале весь вопрос должен быть полностью в заголовке, а в описании должны быть лишь уточнения на пару абзацев и примеры.
Владимир Коротенко, эта область называется "маркетинг". Издатель (или маркетолог) как раз и проконсультирует в деталях, а не я.
Это может быть маркетолог в вашей компании или даже целый отдел для продвижения в вашей компании. Оформление же делается не для галочки, чтобы приложению просто оказаться в сторе, а дальше хоть трава не расти. Целью является конверсия просмотров в инсталлы, и далее в деньги. Сторам тоже важно, чтобы ваше приложение продавалось, ибо % с продаж.
Для такого старого ноута это заметно.