dAppEr, это я так - рассуждения вслух. Может слово - за слово.. так и определим ключевые моменты для рассмотрения ?

В частности, "елка" - это схема официального приложения workout.su (что там - работа с картой, с шаблоном площадок, с сообщениями привата, профилем пользователя, и реализация нескольких экранов - тоже как-то не очень густо).
Объектов - много. То что на пакеты не разнесено - ладно,.. насколько неинформативно представление схемы без локализации пакетов ?
Как по мне, то вообще мутно все. Не зная алгоритма, не зная точки входа - малоинформативно (вообще не информативно).
Да виден EventListener какой-то (звезда на елке), который задействован во многих объектах, но уровень Application - вообще не схеме не прослеживается (а по идее сеттеты и геттеры с ним работают довольно активно)..
Опять таки, это мы подходим к анализу схемы, рассуждая об объеме задачи, которая по нашему представлению в нем реализована.

Лента. Представляется банальной (я не смею утверждат что это круто, но внутри крутится нечто больше, чем просто кастомизированный список). Что в ней (по быстрой памяти) под спойлером:
Да, бесспорно, классов могло бы быть на процентов 10 меньше -в нескольких случаях класс сделать абстрактным, и на его основе сделать 2 новых (в нашем случае это дало бы мину 3, ну пускай минус 5 классов на общем фоне).. Но на тот момент я вопросом архитектуры не заморачивался
Сейчас же схема довольно прозрачна - и по ней не видно насколько где что плохо.

Вот я и в поиске ответов - может мне следует обращать снимание на какие-то кросс-комбинации связей, или связей межу пакетами, или множественных связей ?
Полагаю, что конкретно в "ленте сообщений" довольно грустно с наследованием - это видно по схеме ?

Хм, а если бы я зарисовал название программы, и на экране была бы только схема - по ней можно судить о корявости архитектуры ?

Сегодня я вот что нагуглил, но этого очень мало - фактически ничего (ни о чем)

Сперва была мысли, что связи не должны пересекаться.
Но это не так - весьма зависит от расположения (компоновки) объектов на самой схеме.

Мысль - хорошо когда объекты не просто посажены на схему, а сгруппированы по пакетам. Отсюда мысль - если связь из объекта уходит в другой пакет в соотношение один ко многим - является ли это признаком дурного тона ?

Что можно сказать, глядя на схему - стоит ли объекты по работе с экранами кидать в один пакет .activities,или на каждый экран создавать свой пакет ?
С точки последующего анализа архитектуры - что предпочтительнее ?

Может кто-то сталкивался с архитектурными решениями, с архитектурным рефакторингом, может посоветовать литературу по этим вопросам ?

Собственно, <url="http://workout.su/forum_thread/7555?page=5#227210">задался вопросом</url> - как выглядит UML-схема хорошо спроектированной архитектуры ? Что является показателем ? По схеме можно определить отсутствие "спагетти" кода ?
Можно по подобной схеме определить слабые места (нагромождения "гавнокода") ??

К примеру, вот такая вот схема:




Или такая вот "елка".. "Звезда" - это обработчик событий, поэтому он широко задействован. Можно что-то сказать по подобной схематике о самой архитектуре ??



??

Я специально ушел в свой дневник чтобы не флудить здесь - если тебе интересно, может проникнешься. Нет - ну и ладно.

Я не предлагаю садить города в никуда !..
Что там у тебя - лукапы ? Т.е списки, из которых подтягиваются города, площадки города прописаны по ID, и к площадкам подвязаны ID. Нет ?
По локации подтягивается город - ок, смотришь таблицу городов, подтягиваешь ID города, садишь в площадку ID - город подвязан.
Город не подтягивается ? Определяешь город по одному из методов (или их комбинации), получаешь город, смотришь его ID, подвязываешь ID к площадке.
Город не подтягивается (площадка на острове в бермудах) - площадке присваивается принадлежность городу WTF. Это город. У него есть вой ID (999999, или 0, или -1) . И садишь площадку в базу с ID города WTF.

Итого - все площадки сопоставлены с городами, площадок с пустыми городами нету. Твои текущие города из уже зарегистрированных площадок - переименовываются в одно движение руки (вернее в один апдейт по таблице городов).
По факту - у тебя в площадках сидят их локации, и ID на страны, города, ...
Конечный пользователь больше не заморачивается вводом города - ему достаточно координат, которые он либо получает от ЖПС, либо тыкает в точку на карте. Ты же больше не мониторишь запросы от пользователей на регистрацию новых городов в базу - города в таблицу заносятся в момент регистрации площадки (если город есть - подтягивается его ID, если нет - в лукап садится новый город с новыйм ID, и на площадку подтягивается ID только что посаженного города).
Тебе же остается лишь отслеживать критические ситуации - когда гугл не может определить город по локации и площадка подвязывается к городу WTF. Тогда уже действуешь по старинке - заводишь город (смотришь по локации - что это за чудо-место такое), и перебрасываешь площадку из города WTF в тот, который только что создал у себя в базе.

Знает на английском. Сделай транслит с английского на русский, или кидай их в WTF.
Это до первой регистрации ! После первой регистрации - хоть гугл и не знает города, ты можешь подтянуть наименование города из своего лукапа, потому что у тебя этот город уже есть в русском написании (определяешь по ранее оговоренному методу #1).

Ладно, если много работы с этим - забей. Я к тому это зацепил, чтобы обратить твое внимание - реализовать автоматизацию не так-то уж и сложно. У вас в программе есть метод, который по локации у гугла запрашивает адрес, получив этот адрес - дальше по алгоритму. Не получили адрес - выдали на гугл уточняющий запрос на определение ближайшего города... нету и такого города - площадка закидывается в город WTF. Этот город подвязать можешь к какой угодно стране - это уже не существенно.

Легко. По большому счету это уже вопрос внутренней архитектуры, а не заморочки для конечного пользователя

Решается точно так же, как вы запороли базу площадок (на предмет смещения уже подвязанных локаций) - делается апдейт городов по всем регистрациям. У всех регистраций есть локации - по ним и отработать (есть локаций, будет определен город).
Или даже еще проще - апейт не по всем регистрациям, а по списку городов. Берется город, подтягивается любая площадка с регистрацией на этот город, у площадки есть координаты - гугл выдает по координатам свое "правильное" наименование города, и в завершении делается апдейт старого наименования города на его наименование (согласно гуглу).
И чем не вуаля ?

WasD, отгоровка, имхо. Я тебе <url="http://workout.su/forum_thread/7555?page=4#227206">вот</url> скинул описание варианта автоматизации определения города - и никаких проблем ни с сортировкой, ни с определением города - ткнул пальцем в карту и вуаля

Ок. Да проблем вообще нет ))
А слепым и "пальцеруким" (с большими пальцами да мелкими кранами) так даже проще )) угу ))

О чудо. Работает !.. Гранд респект

Это поле - фргмент, не относящийся к лист списке. Полагаю ты это понимаешь. Отводишь под список 85 процентов экрана, и 25 под поле. А потом кастомизируешь элемент списка - крестики, нолики, иконки, кнопочки, бла-бла-бла..

Зачем делать логику разной ? На уровне приложения делается разбор водящей строки, или параметров, или что-то там. Из входящей информации вытягиваются данные, и садятся в шаблон кастомизации...
У меня на втором скриншоте вообще все банально - это тупо строка, в которой определяются фрагменты, и подсвечиваются разным цветом (вся кастомизация сведена к списку со структурой в одну строку).
На первом скриншоте действительно кастомизация - всякие там несолько полей строк, кнопочек (можно посадить крестики и нолики)..

Глупости все это. Было бы желание все стильно "причесать" ))

Можно. Парсится, имя выделяется, и оформляется кастомизация согласно структуре элемента списка.
Нехотите - другое дело ))
Хрен редьки не слаже. Заменится "многа букафф" на "многа букафф". Как было 3 элемента списка на экране, так и останется. На смартфоне - весьма не прикольно.
К примеру, смотри, вот кастомизация - плотность информации на элемент списка выше. И элементов списка на экране помещается гораздо больше, чем 3 !..

или вот - сколько элементов списка на экране !!! )))))

Ну, я не вижу смысла считать свои же заходы к себе на дневник; так же не вижу смысла тебя переубеждать в наличии смысла там, где ты этого смысла не видишь ))
Да, ютуб само-просмотры считает

угу, видел. спс.

Не понял. Я со своего профиля иду на свой же дневник - и чтобы на последнюю страницу перейти, мне нужно это делать в два действия (открыть дневник, перейти на последнюю страницу)
Неудобно. С last-pasge переход был бы быстрее