С этим полностью согласен. Уровень разный, просто название не соответствует содержанию. Описанное не является тайной или чем то необычным, либо неожиданным. Не хотел никого обидеть)
Я вот тоже прочитал заголовок и решил, что что-то не очевидное. Оказалось, что почти все знают то, о чем, судя по заголовку кто-то "не подозревает". Это же довольно базовые вещи, если работаешь с Rx
Это конечно сугубо мое мнение, просто не понимаю, зачем, видя что на ресурсе уже есть статья с разбором "Hello World", делать разбор "Hello World" другими словами. Ну сделайте вы разбор программы, которая на 2 строчки больше, вопросов бы наверное не было.
Читал обе статьи. Ни в коем случае не пытаюсь Вас обидеть и уж тем более не хочу судить о том, какая лучше, так как это сугубо субъективное мнение. Контекст, как вы выразились, у этих статей как раз идентичен, а вот содержимое действительно отличается. Про копию, я не совсем корректно выразился, за что прошу меня извинить.
Статьи отличаются, но исключительно в контексте оформления. В обоих чуть более человеческое и простая для читателя трактовка документации.
Не фанат писать нелестные комментарии, считаю, что вместо этого имеет смысл просто идти мимо, но тут все таки напишу. По большей части потому, что потратил много времени на прочтение не совсем понятно чего)
Явно чья-то дипломная работа. Ужасно много воды, общих фраз и непонятно зачем добавленной информации.
Описание разделов в начале статьи весьма слабо соответствуют тому, что эти разделы содержат.
Есть ряд неточностей связанных с Android ОС, но скорее всего точное ее описание не являлось целью (хоть и обозначено в первом разделе), по этой причине обошлись общими выражениями
Вероятно, если убрать всю ненужную воду (которая к тому же является общими фразами, а не чем-то осмысленным) и рассмотреть исключительно кейс, которым вы задались и его результаты, то думаю было бы неплохо
Да, конечные точки для управления есть, но не содержатся в интерфейсе, и таким циклом вы их не найдете.
Что касается цикла, то он перебирает конечные точки по направлению передачи, а не по типу. В данном случае они могут быть либо IN, либо OUT, а тип конечной точки и тип передачи (Bulk, Isoc, Interrupt) в данном случае не рассматриваются.
Из этого проистекает то, что цикл не дает неопределенности, все вполне логично — если точка не имеет направление IN, то она имеет направление OUT. И цель определить это, а не тип точки, тип передачи, размер пакета, частоту опроса и прочие параметры конечной точки, которые имеет место быть и важны в той или иной ситуации. Однако для того, чтобы передавать и принимать данные этого достаточно, а большего в этом примере и не нужно)
Ну да, в данной статье рассмотрен конкретный кейс. Цели написать универсальную библиотеку не было) Дело в том, что это custom hid и как правило назначение и номера конечных точек вы должны знать и в моем примере, даже поиск этих точек излишен по идее. Формально получить их по номерам можно, просто задефайниф значения номеров с учётом направления.
Но если вы хотите пройтись по всем, и вывести к примеру информацию, то да, есть смысл этот кусок кода преобразовать по вашему замыслу)
Да, и надо учитывать, что помимо hid, есть еще много стандартных классов, разными типами передачи. К тому же, само api для usb у android весьма скромное, реализует только базовые функции, необходимые для минимальной работоспособности. Сомневаюсь, что при это кто то обратил внимание на эмулятор)
На эмуляторе никогда не пробовал, не могу посоветовать и если честно, не уверен, что это легко можно провернуть на стандартном эмуляторе. Но опять же, не пробовал и даже не пытался вникать в тему
Согласен, это действительно так.
Но, насколько мне известно, (возможно я конечно не прав, но все же), если поставить правильные VID и PID в фильтр, то подобные диалоги будут появляться только в случае, если вы подключите ваше устройство. (Вы также можете поставить галочку и больше не получать диалог, а сразу запускать приложение)Во всех остальных случаях, вы диалог получать не будете в принципе. Если я сейчас подключу к телефону мышку, то диалог я не получу и мышка будет спокойно работать.
А если указать в вашем приложение в device_filter класс устройства, как сделали в коде выше Вы, то я буду получать диалог при каждом подключении устройства этого класса. Если устраивает такое поведение, то тогда это правильный шаг.
Да, но при таком раскладе, ваше приложение будет реагировать на любое устройство с тем классом, который вы описали в device_filter. В данном случае вы будете реагировать на любое устройство реализующее интерфейс 07h, к примеру, т.е. Printer
Если вы хотите реагировать на интент при подключении конкретного устройства (или серии устройств), то надо прописывать VID и PID в device_filter
Да согласен, с предыдущим комментарием, отлаживать надо через Wi-Fi. Она и не запустится просто так, проверяйте интерфейсы и дебажте функцию коннекта, чтобы понять в чем причина.
Данный пример не панацея, для корректной работы надо описать Ваше конкретное устройство
Поменять VID и PID в res/xml/device_filter.xml на свои.
Для дальнейшего взаимодействия изменить CUSTOM_HID_INTERFACE на тот, с которым вы работаете, ну и репорты привести в соответствие с вашими.
Если хотите, чтобы ваше приложение реагировало на подключение устройства, надо добавить интент фильтр в манифест.
Не совсем понимаю что вы хотите этим сказать. У Вас другое USB устройство с другими VID и PID. Естественно вы должны заменить их в коде. Код представленный в статье является демонстрационным и работает с usb устройством на базе STM32F429. Вам не нужно вставлять вашу строку в дополнение к моей. Вы можете удалить мою и вставить свою. Что касается предложения Вашей программы при подключении, то необходимо указать соответствующие интент фильтры в манифесте
Ответил, к предыдущему комментарию. Обидеть не хотел, лишь констатирую факт)
С этим полностью согласен. Уровень разный, просто название не соответствует содержанию. Описанное не является тайной или чем то необычным, либо неожиданным. Не хотел никого обидеть)
Я вот тоже прочитал заголовок и решил, что что-то не очевидное. Оказалось, что почти все знают то, о чем, судя по заголовку кто-то "не подозревает". Это же довольно базовые вещи, если работаешь с Rx
Это конечно сугубо мое мнение, просто не понимаю, зачем, видя что на ресурсе уже есть статья с разбором "Hello World", делать разбор "Hello World" другими словами. Ну сделайте вы разбор программы, которая на 2 строчки больше, вопросов бы наверное не было.
Читал обе статьи. Ни в коем случае не пытаюсь Вас обидеть и уж тем более не хочу судить о том, какая лучше, так как это сугубо субъективное мнение. Контекст, как вы выразились, у этих статей как раз идентичен, а вот содержимое действительно отличается. Про копию, я не совсем корректно выразился, за что прошу меня извинить.
Статьи отличаются, но исключительно в контексте оформления. В обоих чуть более человеческое и простая для читателя трактовка документации.
Уже было, гуглится по первой ссылке. Такой же разбор "Hello World" Зачем копия?
https://habr.com/ru/post/264919/
Продолжение следует в конце статьи звучит как угроза получить весь ваш диплом частями на Хабре)))
Уберите лишнее, и все хорошо ляжет в одну статью)
Не фанат писать нелестные комментарии, считаю, что вместо этого имеет смысл просто идти мимо, но тут все таки напишу. По большей части потому, что потратил много времени на прочтение не совсем понятно чего)
Вероятно, если убрать всю ненужную воду (которая к тому же является общими фразами, а не чем-то осмысленным) и рассмотреть исключительно кейс, которым вы задались и его результаты, то думаю было бы неплохо
Да, конечные точки для управления есть, но не содержатся в интерфейсе, и таким циклом вы их не найдете.
Что касается цикла, то он перебирает конечные точки по направлению передачи, а не по типу. В данном случае они могут быть либо IN, либо OUT, а тип конечной точки и тип передачи (Bulk, Isoc, Interrupt) в данном случае не рассматриваются.
Из этого проистекает то, что цикл не дает неопределенности, все вполне логично — если точка не имеет направление IN, то она имеет направление OUT. И цель определить это, а не тип точки, тип передачи, размер пакета, частоту опроса и прочие параметры конечной точки, которые имеет место быть и важны в той или иной ситуации. Однако для того, чтобы передавать и принимать данные этого достаточно, а большего в этом примере и не нужно)
Ну да, в данной статье рассмотрен конкретный кейс. Цели написать универсальную библиотеку не было) Дело в том, что это custom hid и как правило назначение и номера конечных точек вы должны знать и в моем примере, даже поиск этих точек излишен по идее. Формально получить их по номерам можно, просто задефайниф значения номеров с учётом направления.
Но если вы хотите пройтись по всем, и вывести к примеру информацию, то да, есть смысл этот кусок кода преобразовать по вашему замыслу)
Да, и надо учитывать, что помимо hid, есть еще много стандартных классов, разными типами передачи. К тому же, само api для usb у android весьма скромное, реализует только базовые функции, необходимые для минимальной работоспособности. Сомневаюсь, что при это кто то обратил внимание на эмулятор)
На эмуляторе никогда не пробовал, не могу посоветовать и если честно, не уверен, что это легко можно провернуть на стандартном эмуляторе. Но опять же, не пробовал и даже не пытался вникать в тему
С этим полностью согласен)
Согласен, это действительно так.
Но, насколько мне известно, (возможно я конечно не прав, но все же), если поставить правильные VID и PID в фильтр, то подобные диалоги будут появляться только в случае, если вы подключите ваше устройство. (Вы также можете поставить галочку и больше не получать диалог, а сразу запускать приложение)Во всех остальных случаях, вы диалог получать не будете в принципе. Если я сейчас подключу к телефону мышку, то диалог я не получу и мышка будет спокойно работать.
А если указать в вашем приложение в device_filter класс устройства, как сделали в коде выше Вы, то я буду получать диалог при каждом подключении устройства этого класса. Если устраивает такое поведение, то тогда это правильный шаг.
Да, но при таком раскладе, ваше приложение будет реагировать на любое устройство с тем классом, который вы описали в device_filter. В данном случае вы будете реагировать на любое устройство реализующее интерфейс 07h, к примеру, т.е. Printer
Если вы хотите реагировать на интент при подключении конкретного устройства (или серии устройств), то надо прописывать VID и PID в device_filter
Да согласен, с предыдущим комментарием, отлаживать надо через Wi-Fi. Она и не запустится просто так, проверяйте интерфейсы и дебажте функцию коннекта, чтобы понять в чем причина.
Данный пример не панацея, для корректной работы надо описать Ваше конкретное устройство
Можно и так, правда в таком случае вы скорее всего интент на подключение не получите от конкретно вашего устройстаа
Подебажде метод подключения. Находит ли устройство, затем интерфейс
Поменять VID и PID в res/xml/device_filter.xml на свои.
Для дальнейшего взаимодействия изменить CUSTOM_HID_INTERFACE на тот, с которым вы работаете, ну и репорты привести в соответствие с вашими.
Если хотите, чтобы ваше приложение реагировало на подключение устройства, надо добавить интент фильтр в манифест.