Спасибо за плагин — очень давно не хватало возможности закрасить все в темный цвет.
Не могли-бы немного поправить цвета в отладчике в IntelliJ Idea Community Edition 11.1.2?
Спасибо.
Я также ни на что не претендую. Но считаю приведенную мной выше информацию желательной для ознакомления при рассмотрении методов взаимодействия активити и сервиса.
По поводу Вашего кода — я не вникал в детали и не заметил, что там используется Handler. Все таки готовый пример был бы более наглядным.
[offtopic]У Вас новый Handler создается в потоке вызывающего кода (т.е. UI поток активити скорее всего) — я правильно понимаю? Если так, то обрабатываться Handler будет в этом-же потоке… Поправьте если я не прав[/offtopic]
Не очень хорошо этот спец советует использовать синглтон для сервиса и метод ожидания запуска сервиса.
Вместо синглтона нужно использовать класс Binder, возвращающий ссылку на инстанс сервиса, а вместо ожидания пока MyService.getInstance() возвращает null, использовать ServiceConnection.
Пример можно посмотреть например здесь: http://stackoverflow.com/questions/5731387/bindind-to-the-same-service-instance-in-android
А так ли необходимо использовать Intent'ы если и Activity и сервис находятся в одном приложении (т.е. исполняются в одном процессе)?
Activity ведь может получить ссылку на инстанс сервиса через биндинг. Также активити может быть уведомлена об остановке сервиса, что даст возможность корректно подчищать ссылки. Таким образом мы получим связь активити->сервис.
Ну а имея такую связь уже можно создать листенер для сервиса, и подписать активити на уведомления сервиса, получив таким образом обратную связь сервис->активити.
В результате мы получим быстрый, простой и прозрачный механизм взаимодействия (я не упомянул об механизме обработки сообщений сервисом — при такой схеме можно делать как заблагорассудиться — как вариант создать специальный рабочий поток и в нем через Handler уже обрабатывать команды).
Обфускация не поможет от реверс инжениринга алгоритма. А нормальная защита для.нет стоит денег (впрочем как и протекторы для нейтив кода) и часто привносит свои фичи (как например делает результат x86 only, хотя я давно не сталкивался с .net протекторами — может и появились более совершенные).
Утверждение «самый серьезный минус.нет — это возможность декомпилировать приложение» относиться к разработке shareware проложений.
Декомпилировать во что? В исходный код? Полностью наверное будет сложно. Декомпилировать только нужную часть — легче. Откусить защиту — еще легче. Но для всего этого нужно знание ассемблера/низкоуровнего отладчика/(что там еще).
Для декомпиляции .net сборки нужно всего лишь запустить reflector.
[offtopic]
Я также замечал, что maven в некоторых случаях некорректно собирает — в частности он всегда (у меня) неправильно резолвит айди рисунков если в проекте несколько модулей. В результате показываются не те рисунки.
[/offtopic]
Я бы рекомендовал вместо AsyncTask управлять потоками в ручную и разрабатывать приложение так-же как и под другие платформы — в частности вручную контролировать все созданные потоки и при закрытии приложения, останавливать также и потоки. Если по каким-либо причинам остановить поток нету возможности (а такое бывает например если он висит на чтении из сокета — в Андроид есть связанный с этим баг), то освобождать все ссылки от потока к активити, переводя его в состояние «orphaned».
Пересоздание активити при повороте экрана можно отключить установив атрибут android:configChanges="keyboardHidden|orientation" элемента activity в файле манифеста. В этом случае интерфейс все таки будет переворачиваться, но со стороны контролов все будет выглядеть как будто просто изменились размеры.
Странно почему не сделали такое поведение по умолчанию.
Есть рекомендуемые нормы для UI приложений, и отклоняться от них имеет смысл только в очень немногих случаях. Хотя главное, приложением должно быть удобно пользоваться.
Если Вам, а тем более, пользователям приложения, дизайн нравиться — то все ок.
Несколько моих замечаний на скриншотах:
Приложение в чем-то может и полезное, но дизайн никуда не годиться. Если не чувствуете себя Тёмой в дизайне пользовательских интерфейсов, то лучше используйте стандартные контролы с дефолтными свойствами.
Переходник на самом деле не USB-UART, а UART (можно и USB) -> TTL.
Тем не менее вопрос остается в силе: а Arduino тут для чего?
Точнее для чего — понятно, но зачем акцентировать внимание на нем в заголовке?
здесь интересная инфа про особенности Андроид
https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s
Не могли-бы немного поправить цвета в отладчике в IntelliJ Idea Community Edition 11.1.2?
Спасибо.
P.S. пример с исходниками сильно помог бы вникнуть в суть.
По поводу Вашего кода — я не вникал в детали и не заметил, что там используется Handler. Все таки готовый пример был бы более наглядным.
[offtopic]У Вас новый Handler создается в потоке вызывающего кода (т.е. UI поток активити скорее всего) — я правильно понимаю? Если так, то обрабатываться Handler будет в этом-же потоке… Поправьте если я не прав[/offtopic]
Вместо синглтона нужно использовать класс Binder, возвращающий ссылку на инстанс сервиса, а вместо ожидания пока MyService.getInstance() возвращает null, использовать ServiceConnection.
Пример можно посмотреть например здесь: http://stackoverflow.com/questions/5731387/bindind-to-the-same-service-instance-in-android
Activity ведь может получить ссылку на инстанс сервиса через биндинг. Также активити может быть уведомлена об остановке сервиса, что даст возможность корректно подчищать ссылки. Таким образом мы получим связь активити->сервис.
Ну а имея такую связь уже можно создать листенер для сервиса, и подписать активити на уведомления сервиса, получив таким образом обратную связь сервис->активити.
В результате мы получим быстрый, простой и прозрачный механизм взаимодействия (я не упомянул об механизме обработки сообщений сервисом — при такой схеме можно делать как заблагорассудиться — как вариант создать специальный рабочий поток и в нем через Handler уже обрабатывать команды).
Утверждение «самый серьезный минус.нет — это возможность декомпилировать приложение» относиться к разработке shareware проложений.
Для декомпиляции .net сборки нужно всего лишь запустить reflector.
Я также замечал, что maven в некоторых случаях некорректно собирает — в частности он всегда (у меня) неправильно резолвит айди рисунков если в проекте несколько модулей. В результате показываются не те рисунки.
[/offtopic]
android:configChanges="keyboardHidden|orientation"элемента activity в файле манифеста. В этом случае интерфейс все таки будет переворачиваться, но со стороны контролов все будет выглядеть как будто просто изменились размеры.Странно почему не сделали такое поведение по умолчанию.
Если Вам, а тем более, пользователям приложения, дизайн нравиться — то все ок.
Несколько моих замечаний на скриншотах:
Детали здесь
Тем не менее вопрос остается в силе: а Arduino тут для чего?
Точнее для чего — понятно, но зачем акцентировать внимание на нем в заголовке?