Melograno, на будущее ознакомьтесь
И я думаю, совет ScriptKiddo, ограничить threads - хорош. По-умолчанию там «сколько влезет», но возможно с M1 не всё так просто.
Признаться, мне всё это кажется неправильным с точки зрения ООП.
У нас есть список всех возможных товаров. И кроме него не должно быть никаких посторонних списков - только один.
Все остальные должны быть производными от основного и генерироваться всякий раз, как понадобятся.
Если у вас будет в Классе список основной и список отфильтрованный, никак друг с другом не связанные, то придется всякий раз, обращаясь к отсортированному списку, уточнять - соответствует ли он основному?
Ну так не проще ли сразу его и отфильтровывать из основного?
В общем, сомневаюсь я… не нравится мне этот подход.
Span4ev, признаться, я не усматриваю из ваших слов никакой необходимости иметь рядом с исходным списком такой же отсортированный. То-есть абсолютно.
Если есть исходный список и есть правила сортировки, то получить отсортированный можно в любой момент (ну только если этот список не гигантский).
Но у вас речь, скорее, о фильтрации, чем о сортировке.
Но и для простой фильтрации не вижу смысла в хранении отфильтрованного состояния.
Если вам надо несколько фильтров последовательно применять, только тогда можно как-то промежуточное состояние временно хранить. И то сомнительно.
Мне кажется, вам надо не бороться с копированием списков, а поискать принципиально другой подход к решению общей, конечной задачи.
Зачем всё это в конце концов? Для чего сортировка на кнопках?
yapaofficial, вы, конечно, понимаете, что вам придётся самому изучить API от google в необходимом объёме, написать свой код и потом принести его сюда и спросить, че ж он не работает, собак такой. А сейчас у вас это и не вопрос, а задание. И соответственно вопрос под удаление, см.п.5.12 Регламента.
