О, вы уточнили комментарий :) Да, я в общих чертах (все же не геолог) представляю себе обработку сырых данных. Там же большей частью выбор и применение определенных алгоритмов, а не распознавание образов. Что там делать нейросетям?
Не уверена, что в решении этой задачи нейронные сети могут сильно помочь. Насчет же «десятого дела» не соглашусь. И, думаю, интерпретаторы, которым надо быстро разметить стопицот срезов меня поддержат :)
Если в приложении есть куча задач, которые требуют такого решения — да, обосновано. Если нет — я предпочитаю более легкие решения. Мне пока Броадкаст ресивер и иже с ним без надобности, поэтому обхожусь слушателями для связки активити с фрагментами. Но на заметку взяла — не последнее приложение, надеюсь, пишу.
По поводу интерфейсов я согласна с одним из основных принципов проектирования: «Программируйте на уровне интерфейсов, а не на уровне реализации». Такой подход обеспечивает гораздо большую гибкость в очень многих случаях. Конечно, далеко не везде его имеет смысл применять — например, для крошечных задач создавать отдельный интерфейс нелепо. Но для подобных — вполне оправданно.
Возвращаясь к данному частному случаю — а захотите вы добавить еще одну активити с подобным же функционалом. Вот у меня их уже две. Чтобы реализовать преобразование типов на уровне объектов, нужен будет общий предок и изменение кода, завязанного на ранее использованный класс. В случае использования интерфейсов в уже написанный код лезть не придется.
Не совсем корректно выразилась ранее. Я считаю, что делать насильственное преобразование типа к конкретной реализации активити — плохо, а к интерфейсу, который она имплементит — правильно. При этом зашивать в каждый фрагмент код обновления каких-то кусков, которыми рулит активити — плохо, передавать ей полномочия на управление и данные для этого управления — правильно. Вопросы сугубо архитектуры приложения.
getActivity() возвращает FragmentActivity, у которой доступа нет. Делать насильственное преобразование типов — плохо. Лучше через слушатели связку реализовать.
Читайте внимательнее. Я предлагаю по кнопке Back открывать предыдущий открытый пользователем фрагмент, как это рекомендует гугл. При таком возврате в Экшнбаре и в самом навигаторе информация должна обновиться, но сама она не обновляется — об этом приходится заботиться разработчику.
При разделении айдишника и заголовка появляется возможность генерить заголовки динамически в зависимости от содержания фрагмента, что мне важно. Как я писала — то же ФИО автора или заголовок текущего рассказа.
Ну, про сайты-то я давно в курсе. Удивило, что на мобильные приложения накинулись. Причем, изощренность нарастает — опасаюсь, что в какой-то момент автофильтры могут и перестать срабатывать. А руками эту дрянь из статистики вычищать совсем не хочется…
Но себе запомнила, спасибо. Вдруг, когда пригодится :)
Возвращаясь к данному частному случаю — а захотите вы добавить еще одну активити с подобным же функционалом. Вот у меня их уже две. Чтобы реализовать преобразование типов на уровне объектов, нужен будет общий предок и изменение кода, завязанного на ранее использованный класс. В случае использования интерфейсов в уже написанный код лезть не придется.
Хых… Мы по месяцу ждем каждый сертификат по треку :(