Спасибо за конструктивный фидбэк, без негатива.
Тестирование — тут мне нечего сказать, на проекте у нас его нет и я не приверженец этого подхода.
Рефакторинг — сколько его ни было, никаких особых проблем не испытывал из-за своего подхода. Скорее проблемы случаются, когда ленишься прописывать сеттеры и обращаешься к переменным напрямую. Благо с kotlin их теперь можно переопределить в любой момент без труда
Если передавать аргументы чуть сложнее базовых классов — их все равно придется переносить в новый проект. Если модуль удобен и универсален, пусть я может и потрачу чуть больше времени, но перенесу его полностью со всеми связями. Какие то базовые вещи, которые оправдали свою пользу — в любом случае окажутся и в новом проекте. Если модуль все же специфичен — и так и так придется его менять и адаптировать.
Если поле существует и должно существовать в единственном экземпляре и оно может понадобиться по всему проекту, то почему сразу надо писать кучу кода, чтобы все о ней узнали? При сферическом коне в вакууме — это будет лучше статики. Ну а в реальности куча кода — либо вручную, либо через какие-то библиотеки.
В идеальной работе приложения — toast и не выскочит. Но ради тех редких случаев, когда он понадобится, прокидывать во все методы контекст или какие либо колбеки, создавая связи, которые в теории могут обернуться утечкой памяти? А так — и утечек нет и сообщение отобразится не зависимо от того, что случилось с приложением.
В любом случае это то, к чему я пришел исходя из рабочих проектов. То, что работает и что я с большой вероятностью возьму и в следующий раз. То, что получено путем проб и ошибок. Да, где-то это больше о работе и удобстве здесь и сейчас, чем о красоте и потенциальном удобстве когда-то в будущем.
Я постараюсь учесть все, на что мне указали и сделать свой код еще лучше. И я рад, что не все закатывают глаза и сразу лепят минус. Еще раз спасибо за конструктив :)
Уже изучал. Уже частично используем. Так же периодически проверяем с помощью leak canary — проблем нет. Unit тест не используем и не планируем. Ни тихого ни громкого ужаса нет.
Настройки, которые зависят от id пользователя. Чтобы не модифицировать ключи, можно перегрузить хранилище и продолжить работать. При этом все настройки хранятся в одном менеджере, независимо от того, зависят ли они от пользователя или нет, чтобы не размазывать по проекту
Пояснение по вопросу. Как поменять хранилище значений? Поменять значение с типом SharedPreferences. И я про default, который можно определить в самом конструкторе, чтобы каждый раз не передавать «константу»
По поводу вашего делегата для SharedPreferences. Как я понял, у него нельзя задать default по умолчанию. И как можно в процессе работы поменять значение preferences внутри? Пока приходит на ум только оборачивание в класс, в который при инициализации передавать SharedPreferences. И тогда пересоздавать этот контейнер.
Не пробовали. Сразу использовался RecyclerView.Adapter без DiffUtils. Что касается пересоздания — как я понял из того, что нашел в интернете, RecyclerView сам решает, переиспользовать View или создать новую, а почему и как он решает — надо копаться под капотом. Единственно как удалось заметно повлиять на пересоздание — через обращение напрямую к View в ViewHolder, а не через notify. Но даже так, при самописном свайпе и смещении позиции View — периодически View создавалось, а не переиспользовалось. К слову, странность с пересозданием наблюдалась еще и у знакомых на другом проекте с другой архитектурой и стилем написания. Но все равно не исключаю возможности, что просто что-то сделано в адаптере не так.
Что касается «бизнес-логики» и View. Различные слои у нас точно есть, может не везде идеально и где-то глаз успел замылиться, но буду работать над этим. Учиться, учиться и еще раз учиться :)
1) Toast. К сожалению context есть не везде. Поэтому я и перешел к варианту доступному везде и всегда.
2) TextWatcherObject. Согласен, можно сделать и интерфейсом.
3) SharedPreferences. Интересное решение. Спасибо, испробую на досуге.
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
// Тут не совсем разобрался, если кто подскажет, буду благодарен
if (!bp.handleActivityResult(requestCode, resultCode, data)) {
super.onActivityResult(requestCode, resultCode, data);
}
}
Если к экрану вернулись с результатом после startActivityWithResult(), сначала пробуем передать данные для обработки в BillingProcessor. Если он сообщит, что это не его — то идет обработка дальше.
@Override
public void onPurchaseHistoryRestored() {
}
Как правило, в этом методе можно перестраховаться на случай, если покупка была успешно оплачена, но по каким-либо причинам приложение не успело это обработать. Например, если система успела убить приложение, или приложение упало с ошибкой.
Где то год назад, на хакатоне, мы пытались сделать подобное приложение, только с названием GoWithMe. Правда нас завернули как социальный проект, у которого будут проблемы с продвижением. Основной проблемой таких приложений является раскрутка, так как для того, что бы пользователи из него не уходили, в нем должно публиковаться много предложений.
Попробуйте пустить рекламу в группах «Кто со мной?» в vk, аудитория как раз подходящая. И удачи вам!
Как раз недавно реализовывал подобную штуку. ПК часть писал на java. C помощью библиотеки Roboto можно эмулировать нажатие клавиш и клики мышкой. В ответ ПК постоянно слал скриншоты. Получалось что то около 2 скриншотов в секунду. Фильм конечно не посмотришь с такой скоростью, но управлять курсором получалось вполне комфортно.
Тогда ленту надо будет заранее заготавливать, а тут — любой фломастер и в бой.
Специально сейчас глянул. С бесплатной доставкой стоит 130 руб.
Понимаю. Там есть несколько узких мест, где можно при должной подготовке, достаточном терпении и запасе времени сделать еще дешевле.
Идея крутая, можно взять капиллярную ручку, обмотать чем то металлическим и использовать вместо гвоздя. будет удобно и не сложно.
По поводу быстрее. Если использовать один такой элемент, то не на много быстрее выйдет. Сервопривод ставит точку за 100мс, основное время тратится на работу шаговиков. Хотя можно сделать матрицу из таких ручек и ставить сразу несколько точек, но там вопрос расстояний между ними, т.к. нужна большая точность (возможная точность шаговиков — 1/8 мм).
По поводу дешевле. Цена сервопривода в 1.7$ теряется на фоне цены за другие элементы. Но если вопрос идет о максимальном удешевлении, то да, лучше заменить.
У меня вал 4,7 мм и шестерни хорошо держатся на своих креплениях. Правда один вал, для надежности, я обмотал 1-2 слоями скотча.
P.s. в вк я ответ продублировал
Тестирование — тут мне нечего сказать, на проекте у нас его нет и я не приверженец этого подхода.
Рефакторинг — сколько его ни было, никаких особых проблем не испытывал из-за своего подхода. Скорее проблемы случаются, когда ленишься прописывать сеттеры и обращаешься к переменным напрямую. Благо с kotlin их теперь можно переопределить в любой момент без труда
Если передавать аргументы чуть сложнее базовых классов — их все равно придется переносить в новый проект. Если модуль удобен и универсален, пусть я может и потрачу чуть больше времени, но перенесу его полностью со всеми связями. Какие то базовые вещи, которые оправдали свою пользу — в любом случае окажутся и в новом проекте. Если модуль все же специфичен — и так и так придется его менять и адаптировать.
Если поле существует и должно существовать в единственном экземпляре и оно может понадобиться по всему проекту, то почему сразу надо писать кучу кода, чтобы все о ней узнали? При сферическом коне в вакууме — это будет лучше статики. Ну а в реальности куча кода — либо вручную, либо через какие-то библиотеки.
В идеальной работе приложения — toast и не выскочит. Но ради тех редких случаев, когда он понадобится, прокидывать во все методы контекст или какие либо колбеки, создавая связи, которые в теории могут обернуться утечкой памяти? А так — и утечек нет и сообщение отобразится не зависимо от того, что случилось с приложением.
В любом случае это то, к чему я пришел исходя из рабочих проектов. То, что работает и что я с большой вероятностью возьму и в следующий раз. То, что получено путем проб и ошибок. Да, где-то это больше о работе и удобстве здесь и сейчас, чем о красоте и потенциальном удобстве когда-то в будущем.
Я постараюсь учесть все, на что мне указали и сделать свой код еще лучше. И я рад, что не все закатывают глаза и сразу лепят минус. Еще раз спасибо за конструктив :)
Что касается «бизнес-логики» и View. Различные слои у нас точно есть, может не везде идеально и где-то глаз успел замылиться, но буду работать над этим. Учиться, учиться и еще раз учиться :)
2) TextWatcherObject. Согласен, можно сделать и интерфейсом.
3) SharedPreferences. Интересное решение. Спасибо, испробую на досуге.
Если к экрану вернулись с результатом после startActivityWithResult(), сначала пробуем передать данные для обработки в BillingProcessor. Если он сообщит, что это не его — то идет обработка дальше.
Как правило, в этом методе можно перестраховаться на случай, если покупка была успешно оплачена, но по каким-либо причинам приложение не успело это обработать. Например, если система успела убить приложение, или приложение упало с ошибкой.
Попробуйте пустить рекламу в группах «Кто со мной?» в vk, аудитория как раз подходящая. И удачи вам!
Специально сейчас глянул. С бесплатной доставкой стоит 130 руб.
Понимаю. Там есть несколько узких мест, где можно при должной подготовке, достаточном терпении и запасе времени сделать еще дешевле.
По поводу быстрее. Если использовать один такой элемент, то не на много быстрее выйдет. Сервопривод ставит точку за 100мс, основное время тратится на работу шаговиков. Хотя можно сделать матрицу из таких ручек и ставить сразу несколько точек, но там вопрос расстояний между ними, т.к. нужна большая точность (возможная точность шаговиков — 1/8 мм).
По поводу дешевле. Цена сервопривода в 1.7$ теряется на фоне цены за другие элементы. Но если вопрос идет о максимальном удешевлении, то да, лучше заменить.
P.s. в вк я ответ продублировал