А за что минусы? Аргументы будут?
Я вот Transmission пользовался 4 года, и он до сих пор у меня стоит как запасной. Сделал несколько донатов им в сумме на 50$, а потом когда перешёл на 100 мегабитный тариф как-то скорость закачки у Transmission меня перестала радовать. Закачка идёт на SSD, WiFi 5Ghz, скорость по speedtest 90Мбит/с. Давайте минусовщики свои варианты или только минусы умеете ставить?
Серьёзно?)
Если посмотреть первые пару ссылок в и Гугле, то видно что дискеты можно купить в среднем по 250р за 10шт, т.е. за 14.4 Мбайта. За эти деньги легко купить флешку на 4-8 гигов.
Посмотрел мельком код Telegram под Андроид. Если человек делает это всё сам один, то стоя жму ему руку. Но вот, честно, на первый взгляд такого опыта получать я не хочу:
Файлы по 4-7! тысяч строк кода — явно в них происходит очень много всего.
Почти везде числовые и строковые значение определяются на месте, в константы не выносятся.
Какие-то странности с именованием привычных классов:
public class ChatActivity extends BaseFragment {
...
}
package org.telegram.ui.ActionBar;
...
public class BaseFragment {
...
}
Активити, которая наследует BaseFragment, который не настоящий Fragment, который находится пакете ui.ActionBar… что?
Очень много повторяющихся условий вида(с отсылкой на пункт 2):
if (type == 0) {
...
} else if (type == 1) {
...
} else if (type == 2) {
...
} else if (type == 3) {
...
}
Которые могут быть в разных частях файла, такое ведь очень сложно поддерживать.
Вы не нервничайте — и не будете промахиваться по кнопке «Ответить» :) Это ведь не удобно, вот вам пример)
По делу, официальную документацию к чему надо читать? Открыл документацию по Андроиду — вашу тему не нашёл.
Для начала оффтоп — чтобы ответить на комментарий есть кнопка «Ответить», не нужно писать новый каждый раз.
Далее, вы куда-то уходите от идеи, C# тут появился уже:)… можете дать конкретный пример, ссылки?
Скажем есть база данных, простейшая. Есть экран со списком и с кнопкой, по нажатию идёт запрос в базу и заполняется список.
Какие ноды куда мне надо привязывать?
Я понял, можно, но это если View чётко соответсвует одной модели, а если нет?
Например, есть 2 Активити, которым нужна одна модель, но разные поля из неё т.е. для разных View, ViewObject будут разные, хоть и будут абстрагировать одну модель.
У вас получится, что слой Repository будет иметь методы getViewObject1() и getViewObject2().
В примере автора, о конкретном ViewObject будет знать только соответствующая конкретная реализация Presenter, что на мой взгляд несколько правильнее.
По поводу классов презентера соглашусь, но только для данного примера. В общем случае не известно как может пойти развитие.
А вот по сущностям в модели можно обсудить.
Вы предлагаете жёстко привязаться к модели данных.
Возьмём за пример модель RepositoryDTO — в реальности это большая модель с большим количеством полей.
В этом примере слою View надо всего лишь 4 поля. Для этого создаётся отдельный ViewObject — Repository(не путать с вашим паттерном) который содержит только нужные поля, тем самым абстрагируясь от RepositoryDTO и от модели вообще.
Можно предположить, что в будущем измениться апи, скажем c GitHub на GitLab.
В текущем примере нужно поменять маппер Model <->ViewObject. В вашем менять View.
Как-то всё было испробовано наскокам. В школе Pascal, потом Photoshop, HTML, CSS, внезапно админство и замена картриджей, SQL, PHP.
Причём в какой-то хаотичной последовательности.
Возможно стоит начать с чистого листа и остановить свой выбор на основных языках, скажем C++, Java, .NET?
Плюс их в том, что технологии не бегут совсем уж бешеными темпами, есть база которой хватит в 80% случаев.
Специалистов также полно, почти все вопросы будут иметь чёткие ответы без воды на том же StackOverflow.
Я вот Transmission пользовался 4 года, и он до сих пор у меня стоит как запасной. Сделал несколько донатов им в сумме на 50$, а потом когда перешёл на 100 мегабитный тариф как-то скорость закачки у Transmission меня перестала радовать. Закачка идёт на SSD, WiFi 5Ghz, скорость по speedtest 90Мбит/с. Давайте минусовщики свои варианты или только минусы умеете ставить?
Серьёзно?)
Если посмотреть первые пару ссылок в и Гугле, то видно что дискеты можно купить в среднем по 250р за 10шт, т.е. за 14.4 Мбайта. За эти деньги легко купить флешку на 4-8 гигов.
Активити, которая наследует BaseFragment, который не настоящий Fragment, который находится пакете ui.ActionBar… что?
Которые могут быть в разных частях файла, такое ведь очень сложно поддерживать.
По делу, официальную документацию к чему надо читать? Открыл документацию по Андроиду — вашу тему не нашёл.
Далее, вы куда-то уходите от идеи, C# тут появился уже:)… можете дать конкретный пример, ссылки?
Скажем есть база данных, простейшая. Есть экран со списком и с кнопкой, по нажатию идёт запрос в базу и заполняется список.
Какие ноды куда мне надо привязывать?
Например, есть 2 Активити, которым нужна одна модель, но разные поля из неё т.е. для разных View, ViewObject будут разные, хоть и будут абстрагировать одну модель.
У вас получится, что слой Repository будет иметь методы getViewObject1() и getViewObject2().
В примере автора, о конкретном ViewObject будет знать только соответствующая конкретная реализация Presenter, что на мой взгляд несколько правильнее.
По поводу классов презентера соглашусь, но только для данного примера. В общем случае не известно как может пойти развитие.
А вот по сущностям в модели можно обсудить.
Вы предлагаете жёстко привязаться к модели данных.
Возьмём за пример модель RepositoryDTO — в реальности это большая модель с большим количеством полей.
В этом примере слою View надо всего лишь 4 поля. Для этого создаётся отдельный ViewObject — Repository(не путать с вашим паттерном) который содержит только нужные поля, тем самым абстрагируясь от RepositoryDTO и от модели вообще.
Можно предположить, что в будущем измениться апи, скажем c GitHub на GitLab.
В текущем примере нужно поменять маппер Model <->ViewObject. В вашем менять View.
Причём в какой-то хаотичной последовательности.
Возможно стоит начать с чистого листа и остановить свой выбор на основных языках, скажем C++, Java, .NET?
Плюс их в том, что технологии не бегут совсем уж бешеными темпами, есть база которой хватит в 80% случаев.
Специалистов также полно, почти все вопросы будут иметь чёткие ответы без воды на том же StackOverflow.