Ну третьесторонние либы в зависимости от версии андроида используют разные методы AlarmManager'a

Ну третьесторонние либы в зависимости от версии андроида используют разные методы AlarmManager'a

ну то есть делают тоже самое что можно сделать самому руками, только при этом могут добавить свои баги

и возможно еще своих багов добавляют ;-D

Я пользуюсь либой evernote android job и мешающих мне багов пока не заметил

Ну в либах код, в теории, затестирован

А вот твой точно такой же код

100% будет с багами

+ она использует JobScheduler на апи 21+

Да ещё и им будешь пользоваться только ты

Это значит, что все баги словишь тоже только ты

мой не будет )) но общую идею я поняла

мой не будет )) но общую идею я поняла

Хахаха

Хахаха

(раскланивается)

Ну в либах код, в теории, затестирован

Это если либа широко используема

мой не будет )) но общую идею я поняла

Я думал я один пишу идеальный код)

А если ты нашел либу которую использует 2 тела, то оно решает только их проблемы

Ну да

Потом туда залезаешь, а там 5к методов из которых тебе нужны 2

Речь не о такихлибах

А да. Ещё надо issue смотреть

Перед использованием

Правило #1

Просмотри все issue

почему?

вроде до 21 версии можно было устанавливать период вызовов и там было все по-честному. А в последних версиях слишком часто нельзя делать alarm. Это сделано для экономии батареи.

Смотрел. Там не все так хорошо как хотелось, но оно все равно работает

Короче меня устраивает

Ну в либах код, в теории, затестирован

если на это надеяться... на это лучше не надеяться

стоит ещё помнить, что очень по-разному на разных девайсах всё это работает. я клал в ряд штук 5 - почти на всех всё было по-разному. на одних лениво срабатывал очень JobScheduler, на других всегда моментально. так что это всё очень неустойчиво

@LionZXY о, ты даже позитивный комментарий пингвиненку не пожалел?

Ну естественно

Я низкие оценки ставлю только когда совсем какашка

Только ради бабла/на спех сделано

тут не тот случай)

Есть приложение на VIPER, есть экран, на котором предоставляется список моделек, есть экран с информацией о выбранной модельке (той же, что и в списке) и дополнительными моделями. Есть ли резон передавать всю выбранную модель (она маленькая, около 5-6 полей примитивных) через Router в новый фрагмент (с новыми модельками и инфой о выбранной) или передавать только id и вытягивать снова ?

По логике роутер не должен передавать много данных

Имхо, архитектурно правильно, скорее всего, второе

По логике роутер не должен передавать много данных

Видел просто пример, где в navigateToXXX передавали модельки. У себя сделал так же, но в самом роутере уже передавал в аргументы фрагментам только id, ибо больше ничего было не нужно особо

Люди спасите, ничего не помогат с СО...http://image.prntscr.com/image/bfe1b628cba44d7497c657b8b2e234fa.png

О

Эт боль

Осознаешь что за ошибка?

Или объяснить?

мне пришлось добавить compile 'com.android.support:appcompat-v7:25.3.1' compile 'com.android.support:animated-vector-drawable:25.3.1' compile 'com.android.support:customtabs:25.3.1'

чтобы отстала

Осознаешь что за ошибка?

ну типа дублируется где-то зависимость, с другой версией причем

Ага

Перебирать библиотеки надо

Где скрещивание идет

По хорошему

Ага

это фейсбучная сдк притащила на горбу

Ну все даунгрейдить тогда надо

Все библиотеки

это фейсбучная сдк притащила на горбу

Очень сильно советую не использовать SDK соц сетей

В продакшене

у них достаточно вменяемые REST APIшки, чтобы ими пользоваться

Retrofit ;)

И WebView для авторизации

Очень сильно советую не использовать SDK соц сетей

+

И WebView для авторизации

вот это неоч

Могу рассказать, что да как там, ибо за свою жизнь на*бался с ними более чем достаточно

ERROR: S client not available

вот это неоч

могу опять же, рассказать, зачем так делать

И WebView для авторизации

Вот это не оч [2]

btw, у фейсбука есть апи чтобы поделиться постом из фейсбука же?

Вот это не оч [2]

поэтому я пилил библиотеку для авторизации в ВК — и не оф. сдк, и не WebView.

В браузере могут быть печеньки, кидаем интент на авторизацию, а он берет, и автоматически логинится под авторизованным аккаунтом. Аналогично, у некоторых сетей вообще не предусмотрено деавторизации

поэтому я пилил библиотеку для авторизации в ВК — и не оф. сдк, и не WebView.

Не расскажете, чем WebView не угодил ?

В браузере могут быть печеньки, кидаем интент на авторизацию, а он берет, и автоматически логинится под авторизованным аккаунтом. Аналогично, у некоторых сетей вообще не предусмотрено деавторизации

какой при этом редирект урл?

Могу рассказать, что да как там, ибо за свою жизнь на*бался с ними более чем достаточно

а где читать про фейсбучный рест?

Не расскажете, чем WebView не угодил ?

Тем, что в нём всегда нужно заново вводить логин/пароль, и эти данные доступны приложению.

а где читать про фейсбучный рест?

Вроде как на офф сайте

Тем, что в нём всегда нужно заново вводить логин/пароль, и эти данные доступны приложению.

Не, не всегда

Никто не мешает в рамках приложения куки использовать

Не, не всегда

Речь о кастом табс?

Речь о кастом табс?

нет

Так у вебвью свои куки.

+

Так у вебвью свои куки.

Ну да, логично

Один раз в приложении зашли, во второй - сможете при условии того, что ничего не терли, по проторенной дорожке сразу авторизоваться

Один раз в приложении зашли, во второй - сможете при условии того, что ничего не терли, по проторенной дорожке сразу авторизоваться

nope, не буду заходить просто, не хочу слить свой аккаунт.

Так чем в итогде СДК хуже РЕСТа?

Так чем в итогде СДК хуже РЕСТа?

Тем что архитектуру щелкает как орешки

тем, что приходится подстраиваться под стремный callback-hell либо пилить свой адаптер для того, что используешь

Так чем в итогде СДК хуже РЕСТа?

Код VK и Facebook — это пиздец.

да тем же JSONObject в VK Sdk

??

я не понимат

Это если что, значило примерно следующее - sdk соц сетей распидорасят вашу архитектуру, а еще - вы получите 10 багов бесплатно

А чем плох джсонobject?

Или что там?