Сборка библиотеки FreeType для Android x86 с использованием NDK, потом эта статья. Астрологи объявили неделю бесполезных статей от Интел? Сборка библиотеки сводится к make init && make. Сомневаюсь что человеку, которому надо объяснять как установить NDK, потребуется сборка SQLCipher.
Сборка в эклипсе через билдеры! А как же тру-сборка через консоль или на CI сервере православным градлом, в котором настройка сборки с использованием NDK разжевана дальше некуда?
Вы меня неправильно поняли. Я как раз об этом и говорил. Есть некоторые сущности, которые являются ViewObject, при этом откуда она была получена, нам абсолютно неважно. Получение же этого ViewObject логично вынести в слой, который я назвал Repository, роль которого в контексте статьи выполняет ApiInterface. Просто я предлагаю скрыть всю реализацию мапингов и прочих манипуляций внутри реализации ApiInterface и наружу выдавать уже готовые ViewObject модели. В статье же это делается на уровне презентера.
Я не умею рисовать схемы (шутка) =) Но на словах: зачем три файла/класса для презентера? Зачем интерфейс Presenter (если там lifecycle callback методы, то и назовите его LifecycleCallbacks по аналогии с ActivityLifecycleCallbacks)? А абстрактный BasePresenter, чтобы от CompositeSubscription отписываться? Увеличение абстракции оправдано, если вы пишете какой-нибудь фреймворк или библиотеку. Или это делается потому что так написано в статьях по MVP? Задайте себе вопрос: как часто вам приходилось выкидывать один презентер и заменять его на другой? Мне, например, ни разу.
Что касается Model слоя: приложение вообще ничего не должно знать о сущностях DTO, DBO а так далее. Это все лучше вынести в, так называемый, Repository слой. В котором выполняются мапинги данных, принятия решений о том, откуда эти данные брать (из кэша, БД или сети) и так далее. Наружу торчит только Observable<List> getRepoList(String name);
При этом я ни в коем случае не говорю что статья плохая, статья отличная, особенно учитывая их скудное количество в русскоязычном сегменте.
«более безопасным/удобным/идеологически правильным способом будет» использовать jcenter, деплой в который не требует недельных танцев с бубном, в отличие от maven central.
Безусловно, придумано уже много чего. Но APT, который появился фактически вместе с релизом аннотаций, объявлен ораклом как устаревший инструмент. А aspectJ работает схожим образом: модификация кода. Только использовать надо кастомный компилятор. Ещё ASM есть, lombok и еще куча всего.
Никак. Сгенерированные в процессе компиляции классы, используются рефлексией в рантайме. Кстати, хак со встраиванием класса в иерархию наследования решает эту проблему, ProGuard спокойно может обфусцировать все что можно =)
Пример в статье — лишь малая часть тех возможностей, которые можно получить. А вообще, да, это хороший способ выстрелить себе в ногу, о чем я, собственно, упомянул в заключении.
Тоже подход, но это уже крайний случай, если уж совсем никак. Хотя, скоро будет праздник для любителей хранить JSON: www.sqlite.org/src/timeline?r=json
Да, без сомнения POJO лучше, но сути особо не меняет, особенно, если нужны операции фильтрации, сортировки и прочие прелести (а они нужны в большинстве случаев).
Ой, ну ладно. Прям уж архаизм? Имхо, гораздо удобнее хранить сложные структуры в БД, нежели в Map<String, Map<String, Map<String… >>>>>>>>>> =) К тому же, :memory: хранилище в БД никто не отменял. Тот же SQLite прекрасно может в память!
Прям с языка сняли. Только я бы не деффиренцировал на корею, китай и индию. Это уже глобальная статистика.
Ну не совсем так. В последней альфа версии плагина были добавлены именно бэкпорты некоторых API, включая Stream и DateTime.
jackOptions { enable = true }Кодогенерация пока не поддерживается.
Что касается Model слоя: приложение вообще ничего не должно знать о сущностях DTO, DBO а так далее. Это все лучше вынести в, так называемый, Repository слой. В котором выполняются мапинги данных, принятия решений о том, откуда эти данные брать (из кэша, БД или сети) и так далее. Наружу торчит только Observable<List> getRepoList(String name);
При этом я ни в коем случае не говорю что статья плохая, статья отличная, особенно учитывая их скудное количество в русскоязычном сегменте.