Короткий ответ: Нет.
Длинный ответ:
Общение между разными активити должно происходить с помощью Intent'ов, startActivityForResult, onActivityResult.
Общение между фрагментом и активити должно происходить через аргументы фрагмента, поиска по тегу/айди и кастования фрагмента к определенному интерфейсу, getActivity() и кастования активити к определенному интерфейсу.
Общение между фрагментами, лежащими на одном уровне(лежащими в одном FragmentManager'e) должно происходить через активити и интерфейсы(фрагмент А просит у активити интерфейс Б, активити ищет фрагмент В, реализующий интерфейс Б и предоставляет его), либо через механизм TargetFragment(см get/setTargetFragment).
Общение между фрагментами, лежащими в разных фрагмент менеджерах и связанных отношением родитель-потомок(см getChildFragmentManager) должно происходить через getParentFragment + интерфейсы.
Всё это довольно сложно и запутано, но вот такой вот API.
Всё они правильно сортируются, в лексикографическом порядке. Посимвольно, '1'<'2', значит "100" < "2".
Пиши компаратор, который будет считать строки числами. Ты примерно это и сделал (дико неоптимально), но ты сравниваешь не те символы. В случае со 100 и 2 ты сравниваешь их с нулевого символа, и всего один раз. Опять 1<2. Сравнивать так имеет только строки одинаковой длины, в противном случае больше та, у которой длина больше.
Не знаю, что за соединения у тебя, но этой мапой надо правильно пользоваться. А практика показывает, что если чем-то можно воспользоваться неправильно, то это произойдет.
Я бы предложил врапперы над пулом и соединением.
У враппера пула метод obtain, который берет из пула соединение, создаёт над ним обёртку, в которую также ложит сам пул.
У враппера соединения метод release, который ложит соединение в пул.
Т.о., при работе с пулами чисто через эти обёртки, воспользоваться неправильно нельзя.
Не надо хранить ничего в одном пакете events/activities/adapters. Это тупо. Храни всё по фичам. Пакет login, внутри LoginActivity, LoginAdapter, EventLogIn, EventLogOut, etc. И так далее.
Во время создания активити фрагмент ещё не существует. Ты его, судя по коду, создал, наполнил данными, и потом просто выкинул. Пейджер создал себе новый фрагмент.
Один из путей тут, сделать некий репозиторий с данными, куда активити сложит их, а фрагмент заберёт оттуда, когда ему данные понадобятся. Репозиторий хранить в активити или в графе DI.
Другой путь проще - использовать adapter по назначению. Он, по задумке, адаптирует(превращает) данные во фрагменты. Передай свои данные из активити в адаптер, и при создании фрагмента в адаптере наполняй его этими данными.
storeDataInArrays нигде не вызывается.
loadData по факту ничего не делает.
notify* методы у адаптера не вызываются.
В общем дело не во фрагменте, а в том, что код не дописан.
Каноничная реализация ничего не перекладывает обратно.
У тебя имена странные, я бы их поменял.
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();
}
Пиши код. Все эти книги и прочее - лабуда,ты ничего по ним не добьешься. Ты должен писать код, тебе должно быть это интересно. В процессе рано или поздно ты поймёшь, что тебе чего-то не хватает, тогда берешь и читаешь книги/статьи. И снова пишешь код. У тебя должен быть свой код, не списанный из книги, не по заданию. Просто твой код.
Это у тебя что-то типа ленивой фабрики получается. Всё зависит от окружающего кода, имхо. Сам геттер, если он нужен только для того, чтобы доставать поля, вообще не нужен. Можно так-то и полем торчать.
В стеке нет операции удаления последнего элемента. В односвязном списке это вообще максимально затратная операция, зачем она?
Дальше, в тесте ты эту функцию не используешь.
Функция в любом случае реализована в корне неверно.
Нужно учитывать граничный случай size == 1 и обнулять head. Нужно итерироваться (size - 2) раз, чтобы встать на предпоследний элемент, и у него занулить next. Нужно брать value у элемента, следующего за тем, у которого обнуляется next. То есть у самого next'a.
1) Разбить на строки (split)
2) Распарсить каждую строку регуляркой(regexp) и сложить в объект с двумя полями (первым и вторым)
3) Отсортировать список объектов(sort)
4) Взять необходимое количество объектов из списка (take/drop)
...
Профит!
