Majid Jabrayilov Mecid

Спасибо за то что перевели мой пост.

А с StoryBoard/Xib через Xcode работаете?

Она даже не доходит до уровня Xcode.

В качестве языка Obj-C используете?

Про Swift конечно же, с Obj-C все хорошо. Но новые проекты начинаем на Swift'e делать.
А какие у вас текущие задачи по Swift и когда будет следующий EAP Build?

Сделайте нормальное дополнение для лейблов параметров функций.

Из всего этого зоопарка осмелюсь довериться только Amazon.

Естественно дописать) либу же целую выпиливаем.
В любом случае спасибо за проделанную работу.

Согласен, но не всегда нужно данные закешировать.
К примеру пользователь делает поиск по введенному слову через API.

Плюс что делать с данными которые вернулись в момент изменения конфигурации, когда фрагмент уже был уничтожен?

да, я так и делаю. Но при использовании Clean архитектуры, View в данном случае фрагменты, не должны сами данные кешировать.

Слишком много кода придется переписать, если я вдруг решу выпилить из проекта Moxy, а это уже не есть хорошо.

Хорошее предложение, но бывают результаты, которые не нужно кешировать. Они нужны здесь и сейчас.

Это все хорошо, но использовать библиотеку для построения Архитектуры…
За это дядюшка Боб может и в угол поставить))

ОК, а что делать с данными которые не закешированы.
Чтобы не потерять их при смене конфигурации, я обычно кладу их в Bundle.
Однако при использовании данного подхода, Activity/Fragment не лучшее место для сохранения состояния.

Start/Stop вызывается довольно часто, к примеру при переходе к следующей Activity у текущей будет вызван Stop, а потом при возвращении будет вызван Start, в итоге если в Presenter мы грузим данные при onStart будут выполнены лишние запросы.

1. Вы каждый раз пересоздаете Presenter?
2. Почему только Start/Stop?

А что такое VIPER? по сути это все та же Архитектура Дядюшки Боба.
Зачем только для нее новое название придумали? Из-за Router?

А как вы боритесь с жизненным циклом Fragment/Activity?

А почему Router в Activity? Мне кажется он должен быть в Presenter.
Странно, что View может управлять переходами.

Я один читал только про Катю?

Делать миграцию на Parse Server нет никакого смысла, половина функционала не поддерживается.
Лучше уж тогда с нуля свое решение написать чем допиливать.

Слишком мало Кати в этот раз…

Про Катю получилось однозначно лучше!

Я про Xamarin.Forms

Разработка приложений по гайдлайнам Google/Apple с использованием Xamarin превращается в ад.
Он подходит только в случае если вы копируете приложение под все платформы, не реализуя нативный вид.

Только если вы дотнетчик, в остальных случаях лучше использовать нативные средства разработки.

Ну так вся фишка в Xamarin.Forms, нужна нативность UI на разных платформах.

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

С каких пор Pebble Steel работают на Android Wear?

Ждем когда появится Java…

Зачем нужен был ещё один велосипед? Только из-за названия класса? В продакшине логи лучше отправлять в аналитику, не нашёл такого функционала у вас.

Сам факт того, что пришлось просить компанию Perforce о многом уже говорит.

Обещали, но не добавили.

SHIFT + F12
CMD + E

Android Priority Job Queue очень хороший продукт, сейчас он был форкнут и продолжает развиваться. Хотя там уже все почти есть, не хватает только отмены задач.

Советую обратить внимание на github.com/path/android-priority-jobqueue

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

1 задача = 1 библиотека.

Вот мой набор для работы с БД.
cupboard — bitbucket.org/qbusict/cupboard
provigen — github.com/TimotheeJeannin/ProviGen