Сначала нужно определить, нужен ли кому-то этот Неуловимый Джо:)
Если вдруг нужен, начать с простого - подписывать запросы ключём, лежащим внутри приложения. В лицензионном соглашении написать, что пользоваться этим можете только вы или купивший доступ за миллионы денег. Если конкуренты будут нарушать - есть официальные процедуры, как их прижать.
Если прямо сильно надо, купить защиту, что-нибудь типа https://licelus.com/ или аналогов.
Число перестановок из n элементов равно n! Считай, сколько это будет, явно не 49.
Со знанием того, что это называется перестановкой алгоритм гуглится в два счёта. Модифицировать его для себя сможешь сам.
У тебя null в tvWord_ROWW, потому что ты его присваиваешь/ищешь до того, как его добавил.
Вообще так обычно не делают, не очень понятно, чего ты этими плясками добиваешься. Если это разные экраны, используй фрагменты. Ты не заменяешь активити, ты только меняешь вьюхи.
Используй нормальные имена: camelCase. Не надо мешать его со snake_case. Не надо использовать венгерскую нотацию, в джаве и Андроиде обычно это не принято.
Ну в общем я посмотрел, там есть такой скрытый метод MaterialDatePicker.Builder::customDatePicker().
Думаю, если туда дать правильную реализацию DateSelector'a, то всё заработает. Сделать такую реализацию тривиально.
С доступом к методу могут быть проблемы, он помечен как недоступный юзеру. Можно рефлексией его достать и дёрнуть, в принципе это в данном случае нестрашно.
Каноничная реализация ничего не перекладывает обратно.
У тебя имена странные, я бы их поменял.
enqueue должен ложить в in
poll должен перекладывать из in в out до тех пор, пока in непуст. out.push(in.pop())
результат poll будет out.pop()
public void enqueue(T value){
in.push(value);
}
public T poll() {
while(!in.isEmpty()) {
out.push(in.pop());
}
if (out.isEmpty()) throw new NoSuchElementException();
return out.pop();
}
Бинарные деревья это обычно деревья поиска. Просто бинарные деревья, по-моему, не используются. Единственное, что на ум приходит, это hash tree(Merkle tree) в криптографии. В общем, правила будут такие, какие задашь в имплементации.
Вопросы, ну например, что такое высота дерева? (Здесь и далее за дерево считай BST). Каково асимптотическое поведение основных операций над деревом? Как их улучшить? Что такое сбалансированное дерево? Какие реализации сбалансированных деревьев поиска ты знаешь? Какие из них используются в стандартной библиотеке твоего основного языка?
Можно придумать пачку вопросов про обход: как обойти дерево по слоям(в ширину)? В глубину? Как проверить, что бинарное дерево является деревом поиска?
Ну и потом можно спросить, какие небинарные деревья ты знаешь?
Пиши код. Все эти книги и прочее - лабуда,ты ничего по ним не добьешься. Ты должен писать код, тебе должно быть это интересно. В процессе рано или поздно ты поймёшь, что тебе чего-то не хватает, тогда берешь и читаешь книги/статьи. И снова пишешь код. У тебя должен быть свой код, не списанный из книги, не по заданию. Просто твой код.
Это у тебя что-то типа ленивой фабрики получается. Всё зависит от окружающего кода, имхо. Сам геттер, если он нужен только для того, чтобы доставать поля, вообще не нужен. Можно так-то и полем торчать.
Изучать второй язык в одной парадигме всегда легче. С# и js оба императивные, в них достаточно много похожих конструкций. Возможно, будут проблемы с типизацией.
Мы у себя используем два вида модулей-либ.
1) Фиче-модуль. Это модуль, содержащий одну законченную фичу, такой модуль не следует подключать к другим модулям, кроме основного и сэмпл-аппа. Этот модуль обычно имеет одну(редко больше) точку входа, условно - фрагмент.
2) Утильный модуль. Это модуль, содержащий некий утилитарный код, который хочется пошарить между разными модулями. Такой модуль можно подключать куда угодно. В таком модуле обычно достаточно много публичных классов и функций (хотя может быть и всего один большой класс).
Судя по твоему разбиению, проект у тебя маленький. Чего ты ждёшь от разбиения на модули? Зачем?
