Народ, такой вопрос, для написание приложение для android, какой софт используете, и есть софт для написание для android и ios?

Все очень сложно, бро

но это не так дорого

как ... ощущения?

Ребят, "не умею Rx" и "не нужен Rx" - это разные вещи

А ты можешь рассказать зачем он? :)

да у меня нет такого, я размышляю взять

ну могу предложить взять i7-6800K, 32 RAM

Без ссд это все можно выкинуть

ssd я думал, что априори стоит

просто я заметил с работой в java-ide прямую зависимость в скорости работы IDE от скорости работы RAM

с ссд мне кажется и i5-6600 с 16 гигами потянет)

поэтому память лучше ставить чем шустрей - тем лучше

32гб слишком мгого

А ты можешь рассказать зачем он? :)

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

А ты можешь рассказать зачем он? :)

не надо плодить огромные AsyncTask, а красивый и маленький код RX все заменит

ну могу предложить взять i7-6800K, 32 RAM

отлично работает

ну можно воткнуть 128 гб ssd и бахнуть RAMdisk туда

Я xeon и ссд взял, а под ксеон самую простую мамку,

Для избавления от пресловутого Callback-hell, в конце концов

и на него засунуть Android Studio и проектики

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

А ты часто на тонком мобильном клиенте делаешь вычисления?

8гб озу, ссд (лучше высокоскоростной), и процессор по возмостям. Тем лучше, тем лучше

А ты часто на тонком мобильном клиенте делаешь вычисления?

У кого-то тонкие, а у кого-то толстые.

Для избавления от пресловутого Callback-hell, в конце концов

Обзервер хелл - не решение

8 озу мало , минимум 16

Обзервер хелл - не решение

Если руки из жопы - то да

У кого-то тонкие, а у кого-то толстые.

А зачем толстый?

не надо плодить огромные AsyncTask, а красивый и маленький код RX все заменит

Асинктаски никто не использует через три месяца практики :)

А зачем толстый?

Бизнес-кейсы разные бывают)

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

Не корми троллей

8 озу мало , минимум 16

Нет. 8 норм

не надо плодить огромные AsyncTask, а красивый и маленький код RX все заменит

Ой ой

@Katella ты из Яндекса?

@Katella ты из Яндекса?

нет)

нет)

Значит я тебя с кем-то перепутал.

:D

Гоу под дос писать студию, вообще 640 килобайт хватит всем

Гоу под дос писать студию, вообще 640 килобайт хватит всем

64 же, нет?

На самом деле 6800к, 32гб рам и 512гб ссд хватит всем

Кстати, неделю писал под андроид на vim

64 же, нет?

640

Ну и в конце концов, даже в тонких клиентах нередко нужно писать простенькие репозитории в духе "запросить из кэша, если в кэше ничего нет - запросить с API и записать в кэш". Rx такую задачу решает в 3 строки и очень читабельно

64 же, нет?

А ты ком-файлом одним собрался писать?

Норм, но как то не то

Вам гугл дал студию, а они в виме пишут...

не хватит 640 - возбудимся и достанем дос/4г

А, точно, точно. Речь шла о 640.

Ну и в конце концов, даже в тонких клиентах нередко нужно писать простенькие репозитории в духе "запросить из кэша, если в кэше ничего нет - запросить с API и записать в кэш". Rx такую задачу решает в 3 строки и очень читабельно

Ммм, читабельно. Твое мнение али показывал кому?

Ммм, читабельно. Твое мнение али показывал кому?

Опыт нескольких проектов

Нет. 8 норм

У меня по 3 эмулятора, до 3х студий запущено плюс рам диск , плюс браузер и все 16 забито под 90%

По этому до 32 буду поднимать

Подскажите как оптимально реализовать атрибут android:onClick во фрагменте куда динамически добавляются button'ы Читал что этой штукой пользоваться во фрагментах нельзя, а писать гору кода для того чтобы найти все view приводимые к button и на них отдельно вешать onClickListener, кажется совсем нерациональным вариантом Как поступают обычно в таких случаях?

Привет! Мне нужно запустить на android с помощью gradle сервер для тестирования api. Подскажите, плиз, как это можно сделать?

Подскажите как оптимально реализовать атрибут android:onClick во фрагменте куда динамически добавляются button'ы Читал что этой штукой пользоваться во фрагментах нельзя, а писать гору кода для того чтобы найти все view приводимые к button и на них отдельно вешать onClickListener, кажется совсем нерациональным вариантом Как поступают обычно в таких случаях?

Все рационально

А представьте, что вы скоро мобилы с 16 гигами озу увидите

У меня по 3 эмулятора, до 3х студий запущено плюс рам диск , плюс браузер и все 16 забито под 90%

Зачем)

А вот в XML писать не рационально и хреново

Подскажите как оптимально реализовать атрибут android:onClick во фрагменте куда динамически добавляются button'ы Читал что этой штукой пользоваться во фрагментах нельзя, а писать гору кода для того чтобы найти все view приводимые к button и на них отдельно вешать onClickListener, кажется совсем нерациональным вариантом Как поступают обычно в таких случаях?

Забудь про онклик

Забудь про онклик

+1 Плохая вещь

Если не хочешь много кода, юзай AnnotationAndroid

@Click(R.id.btn) public void someMethod(View v)

@Click(R.id.btn) public void someMethod(View v)

Такое было?!

Такое было?!

М?

М?

Это встроенная фича?

В AndroidAnnotions

В AndroidAnnotions

А, понял. Спасибо.

Там еще момент есть что кнопки добавляются динамически) а искать их по id, законно ? :)

При компиляции преобразовывается вы findViewById().setOnClick

ERROR: S client not available

Там еще момент есть что кнопки добавляются динамически) а искать их по id, законно ? :)

Как создаёшь так и сразу же ставишь листенер.

Я извиняюсь конечно, но уже загрыв глаза можно угадать что на вопрос "зачем тебе Rx" - тебя уткнут в асинк-таски - ну да ... они не айс,,, есть 100500 решений - более низкого(трейды), равносильного(хандлеры и тд), более высокого(лоадеры) уровня. Universal Image Loader - полностью построен на асинк тасках Loader FrameWork - и еще куча недр самого андроида Просто асинк-таск юзать в чистом виде - садомазо, объясняемое именно тем что его не отсинкать нормально с ЖЦ Активити или Фрагмента. в свою очередь лоадеры - это умная надстройка над асинк тасками которая за тебя решает вопрос ЖЦ. Вот и вся беда асинк-тасков! и гугл не врет что они - всему начало, просто он недоговаривает что они уж больно абстрактны чтоб юзать их голыми руками

Благодарю всех)

Я извиняюсь конечно, но уже загрыв глаза можно угадать что на вопрос "зачем тебе Rx" - тебя уткнут в асинк-таски - ну да ... они не айс,,, есть 100500 решений - более низкого(трейды), равносильного(хандлеры и тд), более высокого(лоадеры) уровня. Universal Image Loader - полностью построен на асинк тасках Loader FrameWork - и еще куча недр самого андроида Просто асинк-таск юзать в чистом виде - садомазо, объясняемое именно тем что его не отсинкать нормально с ЖЦ Активити или Фрагмента. в свою очередь лоадеры - это умная надстройка над асинк тасками которая за тебя решает вопрос ЖЦ. Вот и вся беда асинк-тасков! и гугл не врет что они - всему начало, просто он недоговаривает что они уж больно абстрактны чтоб юзать их голыми руками

Истину глаголишь

Реалм так и не завелся. Короче лажа багнута блин

Единственное что. Лоадеры разрабатывались только для БД, не для сети.

А так если ты будешь сам писать диспатчинг данных между потоками, то тот же таск и напишешь

А так если ты будешь сам писать диспатчинг данных между потоками, то тот же таск и напишешь

угу

Я извиняюсь конечно, но уже загрыв глаза можно угадать что на вопрос "зачем тебе Rx" - тебя уткнут в асинк-таски - ну да ... они не айс,,, есть 100500 решений - более низкого(трейды), равносильного(хандлеры и тд), более высокого(лоадеры) уровня. Universal Image Loader - полностью построен на асинк тасках Loader FrameWork - и еще куча недр самого андроида Просто асинк-таск юзать в чистом виде - садомазо, объясняемое именно тем что его не отсинкать нормально с ЖЦ Активити или Фрагмента. в свою очередь лоадеры - это умная надстройка над асинк тасками которая за тебя решает вопрос ЖЦ. Вот и вся беда асинк-тасков! и гугл не врет что они - всему начало, просто он недоговаривает что они уж больно абстрактны чтоб юзать их голыми руками

Это все справедливо. Просто как всегда все подобные холивары упираются в тезисы "вот это говно, а вот это не говно". А на самом деле и то, и другое - инструменты, имеющие область применимости. Тут уж кому как, а лично для меня и нашей команды разработки так сложилось, что Rx для нас оказался очень удобным инструментом, чтобы полностью абстрагироваться от всей ручной работы по управлению потоками. Ну а бонусом мы получили плюшки ФП - иммутабельность данных, уклон в сторону stateless-логики и т.д

И тормоза от GC :)

Которые ваши юзеры и заметят в первую очередь

Я согласен с тезисом про инструменты

Но Rx это инструмент для сервера

от Rx тормоза GC?

Ему не место на слабых телефонах

от Rx тормоза GC?

Конечно. Знаешь, сколько ок объектов генерирует на каждый чих?

Ему не место на слабых телефонах

А что ты используешь для выкачивания из сети, если не асинком?

Сколько точно не считал. Но пробовал на телефонах с 512 оперы и все гуд ни одного лага

Конечно. Знаешь, сколько ок объектов генерирует на каждый чих?

А можно примеры в цифрах? На футпринт, Rx несомненно оказывает влияние, но это сколько данных надо гонять, чтобы начало тормозить?

Гугл вообще рекомендует циклы через индекс итегрировать, чтобы не флудить

на счет железа, юзаю i7 6700(non k) на 4,8Гц, 16, 250 ссд(500 Кб на чтение, не самый быстрый) == вчера мучал 4 студиями открытыми, 2 емулятора, браузер....хз, все летает. Загрузка от нажатия на кнопку включения 12сек

И не создавать объекты в onDraw/etc

Гугл вообще рекомендует циклы через индекс итегрировать, чтобы не флудить

Лол

А что ты используешь для выкачивания из сети, если не асинком?

В андроиде есть thread!

Лол

Это все справедливо. Просто как всегда все подобные холивары упираются в тезисы "вот это говно, а вот это не говно". А на самом деле и то, и другое - инструменты, имеющие область применимости. Тут уж кому как, а лично для меня и нашей команды разработки так сложилось, что Rx для нас оказался очень удобным инструментом, чтобы полностью абстрагироваться от всей ручной работы по управлению потоками. Ну а бонусом мы получили плюшки ФП - иммутабельность данных, уклон в сторону stateless-логики и т.д

Ок, если вам это помогает и так легче - дай бог, парни

И не создавать объекты в onDraw/etc

Эм

А где

В андроиде есть thread!

Не очень удобно. :/ Ну как по мне. :D

А можно вообще уйти глубже и pthread с socket юзать, линукс же

ага

так и делаю