Незнаю что они там фиксили, но у меня после каждого обновления, стим на OS X (10.9.1) перестает запускаться. Последний раз я его лечил пару недель назад.
Такого рода проблемы рапортуют, ЕМНИП, аж с 2011.
Да, все верно. Но есть ньюанс. Точно так же как андроид может убить активити, с такой же легкостью он может избавится и от самого процесса. Это нормально, когда все что требуется от реста это какие-то недолго живущие и ни на что не влияющие данные. Но а что если вам нужно получить какие-то данные, на основе них что-то записать в БД и, например, записать что-нибудь в файлик?
Из собственного опыта:
В проекте был Universal Image Loader, затем мне понадобился кастом (хитро загружать и обрабатывать картинку). UIL сразу сдал свои позиции, был в последствии выброшен на помойку и заменен Picasso.
Я не думаю что вообще получится откалибровать. Тут нужна камера, а не RGB сенсор, как мне кажется.
И то, я не всегда могу отличить по цвету «Кокос» от «Маслянного попкорна».: )
Безусловно, однако представьте большое приложение, где один стиль может быть применен на компоненты c ралзличными layout_width и layout_height.
Если попытаться применить Ваш подход, то появится дублирование кода. Если сделать исключение, то код будет не однородным. Все это может привести к путанице.
А что если между этими вариантами? Она нужна как и внутреннее хранилище так и для отображения данных в списке.
Думаю стоит пояснить что я имею ввиду под громоздкостью:
мало того, что есть аспект общей громоздкости (нужно написать много boilerplate'а), который, в принципе, можно обойти, так есть еще аспект очень неудобной работы со всякими хитрыми JOIN'ами.
Хотел бы задать вопрос комментирующим:
А часто ли вы используете ContentProvider для работы с данными, при условии что эти самые данные не нужно перекидывать между приложениями?
Мне показался вариант использовать ContentProvider для целей хранения внутренних данных очень громоздким.
Ну зачем минусовать человека?
Лямбды действительно используют invokedynamic.
Тем не менее, как справедливо заметили выше, можно было бы обойтись и без этого.
Так же, думаю, код может завестись и на старых JVM при передаче соответсвующего значения через флаг -target во время компиляции.
Такого рода проблемы рапортуют, ЕМНИП, аж с 2011.
Где нужно управлять самому упрощенной моделью человека.
Игровой процесс напоминает симуляции в первых поколениях.
В проекте был Universal Image Loader, затем мне понадобился кастом (хитро загружать и обрабатывать картинку). UIL сразу сдал свои позиции, был в последствии выброшен на помойку и заменен Picasso.
И то, я не всегда могу отличить по цвету «Кокос» от «Маслянного попкорна».: )
layout_widthиlayout_height.Если попытаться применить Ваш подход, то появится дублирование кода. Если сделать исключение, то код будет не однородным. Все это может привести к путанице.
На мой взгляд это не совсем удобно и не гибко, если я Вас правильно понял.
Думаю стоит пояснить что я имею ввиду под громоздкостью:
мало того, что есть аспект общей громоздкости (нужно написать много boilerplate'а), который, в принципе, можно обойти, так есть еще аспект очень неудобной работы со всякими хитрыми JOIN'ами.
А часто ли вы используете
ContentProviderдля работы с данными, при условии что эти самые данные не нужно перекидывать между приложениями?Мне показался вариант использовать
ContentProviderдля целей хранения внутренних данных очень громоздким.Незнание английского языка в большинстве случаев своеобразный потолок для программиста.
Лямбды действительно используют invokedynamic.
Тем не менее, как справедливо заметили выше, можно было бы обойтись и без этого.
Так же, думаю, код может завестись и на старых JVM при передаче соответсвующего значения через флаг
-targetво время компиляции.