Был

а как ставить

по умолчанию 1?

Я хз

Честно

Помню что ставил

Как зачем

Не помню

я чет сижу туплю у меня два фрагмента во вьюпейджере и они начинают грузить данные оба

бля и почему то один после второго

и второй фрагмент первее начинает грузить

лок чтоли повесить или синхронизировать вручную или вообще кондишены заюзать

Выглядит как наркоманская архитектура

А понял

Типо только один фрагмент грузит?

А надо чтоб параллельно?

там почти клин ничего наркоманского)

ну да

я просто не понимаю с чего не параллельно то вообще

вот щас выставил вроде параллельн начало

http://stackoverflow.com/questions/35012030/execute-http-request-in-parallel-with-retrofit-2

?

я просто не понимаю с чего не параллельно то вообще

может scheduler-ы заняты, или где-то синхронизация ненужная есть ?

Второе очень может быть

не сихнронизацю вообще не юзал

Какая-то неявная

.callbackExecutor(Executors.newFixedThreadPool(5)) вот так ксттаи задается количество тредов ретрофиту

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

.callbackExecutor(Executors.newFixedThreadPool(5)) вот так ксттаи задается количество тредов ретрофиту

а по дефолту что стоит там, не подскажете?

а вот я тоже хз)

ищу инфу

ну я думаю что точно не 1

Он там по дефолту вообще null стоит

ну так какой ответ то) выживет или нет

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

ну у активити приоритет еще выше

у визибл

ну у активити приоритет еще выше

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

да ну не

не может быть

тоесть если памяти мало то убьется активити?

убьется и востановится

это заметно же будет

еще вопрос у меня

что за хуйня в постмане реквест 500мс

а в приложении 4653ms

как это возможно

тоесть если памяти мало то убьется активити?

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

ну не верю)

я давно читал это путаю может что то

ребят в чем дело может быть что запросы одинаковые а времени требуется в 10 раз дольше

я давно читал это путаю может что то

Так смысл службы как раз в том чтобы работать когда активити прибиты. Еще живучая штука это наследник Application

а в приложении 4653ms

Как ты трекаешь?

через окхттп логинг интерсептор

что за хуйня в постмане реквест 500мс

Вот из постман?

прилоение для рест апи

запросики отправлять

вот 1 в 1 реквесты

запросики отправлять

андроидное?

нет хром экстеншн

нет хром экстеншн

Надо глянуть

а в приложении 4653ms

У меня через моб интернет ответы медленней идут чем через вай фай например

Ребята, подскажите, как в реалме реализовать наследование? Композиция? Или лучше взять другую базу?

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

я на одном вайфае

Можешь ещё с интерфейсами себе жизнь улучшить, но мне и так удобно было.

все отбой я еблан и апи бомжарское

все отбой я еблан и апи бомжарское

?

Alexander, а нет способа без дубликации кода? Просто тут абстракция на абстракции

ERROR: S client not available

все отбой я еблан и апи бомжарское

Мне бы ваши проблемы, у меня рекорд запроса к OneNote API был около 18 секунд. Тушка весила порядка 10-15Кб

у меня ответы в хмл

для начала

бывает что просто так апи ошибку присылает

ну весело там все

Alexander, а нет способа без дубликации кода? Просто тут абстракция на абстракции

Так а где дубликация-то? У тебя просто будет навалено все в одном классе.

ну весело там все

У вас по-крайней мере нет поля "warning", которое вообще не пойми как воспринимать.

:)

A foreground process is one that is required for what the user is currently doing. Various application components can cause its containing process to be considered foreground in different ways. A process is considered to be in the foreground if any of the following conditions hold: - It is running an Activity at the top of the screen that the user is interacting with (its onResume() method has been called). - It has a BroadcastReceiver that is currently running (its BroadcastReceiver.onReceive() method is executing). - It has a Service that is currently executing code in one of its callbacks (Service.onCreate(), Service.onStart(), or Service.onDestroy()). There will only ever be a few such processes in the system, and these will only be killed as a last resort if memory is so low that not even these processes can continue to run. Generally, at this point, the device has reached a memory paging state, so this action is required in order to keep the user interface responsive.

вот тут тут написано что сервис только на нескольких колбеках считается форграунд компонентом

обычно это быстрые колбеки

ну если там конечно что то огромное не создается или уничтожается

вот тут тут написано что сервис только на нескольких колбеках считается форграунд компонентом

обычный сервис живучее активити, а foreground сервис живучее обычного сервиса - как-то так

Ну вон же я написал

сервис на одном уровен с визибл активити только во время обработки 3 колбеков

если онстарт и онкриэйт выполнились то сервис становится бекграунд процессом

It is running an Activity that is visible to the user on-screen but not in the foreground (its onPause() method has been called). This may occur, for example, if the foreground Activity is displayed as a dialog that allows the previous Activity to be seen behind it. It has a Service that is running as a foreground service, through Service.startForeground() (which is asking the system to treat the service as something the user is aware of, or essentially visible to them).

вот фограунд сервис расценивается по приоритетности как активити в онпауз

ты сравниваешь "видимый активити" (ВА) и "фореграунд сервис" (ФС)?

ну пауз это еще видимый но неактивный

ну вот если просто подумать что хуже вырубить активити которая напрямую связана с юзером и не останется незамеченным или вырубить бекграунд таск

и тем более щас сервисы вообще станут ооочень слабыми по приоритетности и времени жизни

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

ну а я про него же говорю )

не поняли значит друг друга

на практике же когда активити становится невидимым, система его прибьет, а службе даст пожить еще)

А как логичнее очистить базу - дропнуть и восстановить таблицы или очистить с помощью delete ?)

drop

я думаю 1 быстрее)

окс, спасибо

А как логичнее очистить базу - дропнуть и восстановить таблицы или очистить с помощью delete ?)

Удаление кажись по факту на размер не влияет БД, нужно что то еще там магическое делать чтобы уменьшилась, логично чтоб уменьшилась

Удаление кажись по факту на размер не влияет БД, нужно что то еще там магическое делать чтобы уменьшилась, логично чтоб уменьшилась

VACUUM, смею предположить?