ну да, они все ставили в морозильник. Вроде обычный, без спецэффектов.
Честно говоря быстро не нашел нужной серии, ибо на работе не совсем удобно это делать, но вот одна из серий про охлаждение:
В моем детстве, когда с родителями в жару ездили в поезде — бутылку оборачивали в мокрое полотенце и выставляли за окно. Таким образом лимонад точно охлаждался… может быть казался холоднее, как и трава зеленее… Но метод точно старый и наверняка как-то работал
Я сейчас могу путать серии, возможно пиво охлаждали не один раз, но там тоже фигурировало полотенце и обычный лед. Помню что соленая вода была самая эффективная. Так же там были совсем фантастические методы вроде как прогонки пива через спираль погруженную в азот, но там оно до конца спирали так и не доходило, потому что замерзало )
Такой эксперимент проводили в разрушителях легенд. Правда там охлаждали пиво, но соленая вода реально была самая быстрая. Думаю это из-за двух факторов:
1) соленая вода имеет более низкую точку замерзания, значит бутылка погружается изначально в более холодную среду
2) соленая вода имеет большую площадь соприкосновения с бутылкой, значит охлаждение происходит по большей площади.
Но это мои выводы, я ни капли не физик. Вот если бы автор еще и такйо эксперимент все-таки провел — было бы здорово. А так от меня плюс — это правда интересно
Вот вам пример: в окне имеется карта и список объектов. В портретной ориентации карта у вас сверху, список объектов снизу. При альбомной ориентации — карта справа, список объектов слева.
по первому пункту — ниже уже ответили. Под общим вью подразумевается общий интерфейс View. Когда рассказываешь про MVP главное не путать interface View из ООП и View который рендерится и отображается на экране.
по второму пункту — активность (давайте будем использовать это, вместо слова интерфейс, так мы не запутаемся) имплементирует interface View, а не зависит от него. Это же не абстрактный класс, а именно интерфейс
3. Observable это паттерн в более узком смысле, чем MVVM
Не хочу разводить споров, но не стоит так категорично относиться к MVP
Видимо вы не правильно готовите MVP.
Просто пробегусь по минусам:
Приходится создавать интерфейс View под каждый экран. На больших проектах будем иметь много лишнего кода и файлов, которые затрудняют навигацию по пакетам.
Создайте общий view и используйте его для тех случаев, когда вам не нужны лишние view или конструкции повторяются
Presenter сложно переиспользовать, так как он завязан на View, а она может иметь специфичные методы.
Презентер завязан на интерфейс VIew, а не на VIEW в понимании компонента андроида. Презентер не касается визуальной составляющей, а общается через интерфейсы, которые вообще привязаны к визуальной составляющей только в одностороннем порядке. Это позволяет вам использовать один презентер для разных активностей имеющих набор общих данных но разную визуальную составляющую
Отсутствует определенное состояние. Представим, что мы делаем запрос в сеть, и в этот момент наша активити умирает и создается новая. Данные пришли, когда View еще не привязана к Presenter…
Такое может возникнуть например в случае, когда мы открыли activity, и потом резко повернули экран, чтобы активити пересоздалось. Тогда используйте Observable и получайте уже загруженные данные.
Вот MVVM на мой взгляд как-раз и получается чрезмерно перегруженным и уж очень сильно зависит от VIEW в понимании визуальной составляющей. В своем примере вы приводите пример obsrvable, но о минусах MVVM не упоминаете ) Исходя только из приведенного примера MVVM можно вообще использовать котлиновские callback.
Возможно просто я не умею готовить MVVM ;)
Вот боюсь сейчас перейти грань срача, поэтому если чем-то задену вас — прошу прощенья сразу. Все нижесказанное исключительно мое мнение. Но робот автомат это самое ужасное решение в коробках автомат. Лучшего чего добились в этом направление это VW со своими DSG, но там на коробку дается гарантия всего 150 тыс(!) Причем очень много коробок до этого срока не доживают. Если разобраться в устройстве, то робот это и есть обычная механическая коробка, только скорости переключает «робот». И реально есть проблема с угадыванием когда эту скорость нужно переключить. В общем не стоит сравнивать робота и нормальный 6 ступенчатый автомат. Про вариатор вообще молчу, там машина себя как электромобиль ведет. Вот тут почитайте, все просто про коробки написано, вы сразу поймете о чем я
Сам на механике отводил достаточно и автоматизм имелся. Только когда на нормальный автомат пересаживаешься — этот автоматизм к механике начинаешь воспринимать вот так:
Полностью с вами соглашусь. Опять таки пример из личной жизни, когда люди доказывают, что коробка автомат в авто им совсем не нужна. Им и на механике не сложно, а автомат это просто дорого и бессмысленно. Но вот потом смотришь на этих людей, когда пересаживаются в автомат и начинают удивляться как они раньше не замечали что это очень удобно.
Мне кажется с часами то же самое. Пока не наденешь — можно долго доказывать, что это бесполезно
Ну вот по опыту своих коллег скажу следующее — у меня обычные спортивные часы. Без всяких детекторов сердцебиений и трекеров. Но функцию «часов» они выполняют на ура. Ношу эти часы давно и снимая только на сон. А вот коллеги, которые таскались со всякими смарт часами и фитнес браслетами с них слезли. Потому что наигрались, а поддерживать в них жизнь постоянно заряжая — надоело.
Тут наверное больше дело привычки. Ношу gshock уже лет 5 наверное. Настолько привык к ним, что даже просто выйти в магазин их одеваю. Ну и несомненные плюсы относительно смартфона все-таки есть. Во первых батарейку менял всего один раз, и они не раз выручали наличием встроенного будильника, который в любом случае отработает. Особенно выручало, когда едешь куда-нибудь на рыбалку на несколько дней. Смартфон зарядить негде, а часы не потеряются и не надо переживать что будильник не прозвонит. Дату и время тоже смотрю исключительно по часам. В смартфон дольше и неудобнее лезть. Ну и очень радует функция влагостойкости. Хорошие часы без проблем можно купать, чем я и пользуюсь в бассейне и опять таки на речке/море. Ну и прямую функцию они тоже очень удобно выполняют. Гораздо удобнее вести отчет времени по наручным часам, чем по смартфону
Есть конечно и лишние функции, например барометром в часах так никогда и не пользовался, так же как и высотомером, компас тоже только один раз выручал.
Вот эстетической функции в часах не вижу. Честно-говоря мне все-равно за какую сумму у вас на руке часы.
А вот такой вопрос — наверняка при построении маршрута используется какой-нибудь google Routes. А у них большие ограничения на бесплатное использование. Каким сервисом в итоге маршрут строите?
Интересный GPS модуль вы взяли. У меня опыт только с NEO-6 имеется. В принципе неплохой. Как с качеством приема у вашего? Он значительно дешевле, а я люблю дешевое )
Ну, если я не ошибаюсь самый простенький e-lnk обойдется в 1000 рублей. К сожалению не дешево. И если я не ошибаюсь, то такая цена обусловлена патентом на такой тип экранов.
А вот другой момент — как я понял термометр будет располагаться на улице. Интересно как долго на самом деле он там проживет, если учесть что у нас бывают существенные минусовые температуры
Честно говоря быстро не нашел нужной серии, ибо на работе не совсем удобно это делать, но вот одна из серий про охлаждение:
1) соленая вода имеет более низкую точку замерзания, значит бутылка погружается изначально в более холодную среду
2) соленая вода имеет большую площадь соприкосновения с бутылкой, значит охлаждение происходит по большей площади.
Но это мои выводы, я ни капли не физик. Вот если бы автор еще и такйо эксперимент все-таки провел — было бы здорово. А так от меня плюс — это правда интересно
по второму пункту — активность (давайте будем использовать это, вместо слова интерфейс, так мы не запутаемся) имплементирует interface View, а не зависит от него. Это же не абстрактный класс, а именно интерфейс
3. Observable это паттерн в более узком смысле, чем MVVM
Видимо вы не правильно готовите MVP.
Просто пробегусь по минусам:
Создайте общий view и используйте его для тех случаев, когда вам не нужны лишние view или конструкции повторяются
Презентер завязан на интерфейс VIew, а не на VIEW в понимании компонента андроида. Презентер не касается визуальной составляющей, а общается через интерфейсы, которые вообще привязаны к визуальной составляющей только в одностороннем порядке. Это позволяет вам использовать один презентер для разных активностей имеющих набор общих данных но разную визуальную составляющую
Такое может возникнуть например в случае, когда мы открыли activity, и потом резко повернули экран, чтобы активити пересоздалось. Тогда используйте Observable и получайте уже загруженные данные.
Вот MVVM на мой взгляд как-раз и получается чрезмерно перегруженным и уж очень сильно зависит от VIEW в понимании визуальной составляющей. В своем примере вы приводите пример obsrvable, но о минусах MVVM не упоминаете ) Исходя только из приведенного примера MVVM можно вообще использовать котлиновские callback.
Возможно просто я не умею готовить MVVM ;)
Вот тут почитайте, все просто про коробки написано, вы сразу поймете о чем я
Сам на механике отводил достаточно и автоматизм имелся. Только когда на нормальный автомат пересаживаешься — этот автоматизм к механике начинаешь воспринимать вот так:
Мне кажется с часами то же самое. Пока не наденешь — можно долго доказывать, что это бесполезно
Есть конечно и лишние функции, например барометром в часах так никогда и не пользовался, так же как и высотомером, компас тоже только один раз выручал.
Вот эстетической функции в часах не вижу. Честно-говоря мне все-равно за какую сумму у вас на руке часы.
А вот другой момент — как я понял термометр будет располагаться на улице. Интересно как долго на самом деле он там проживет, если учесть что у нас бывают существенные минусовые температуры