Про MVVM ну бред же полный. Создаем Активити, вызываем setContentView(R.layout.main), после этого у нас всё event-driven без каких-либо байндингов. Хотите байндингов — пишите собственную модель, пишите собственный OnTextChangeListener и т.д. — всё руками, ничего из коробки и похожего нет.
Как быстро вам ответили по поводу таблета? Апликуха была платной?
Получил письмо ***BlackBerry App World Notification — Product Approval *** 29.02, нажал на кнопочку «Post for sale» и до сегодняшнего дня ничего нового не получил (хотя в описании написано, что до 24 часов всё должно быть готово). Да и моя апликация вроде даже еще не появилась в их маркете…
Мне кажется автор знает об альтернативах. И, возможно он ими и пользуется.
Не вижу проблем в написании собственного велосипеда в целях самообразования при переходе с .net на java. Если тема велосипеда интересна, то и писать будет не скучно. Если будет писать не скучно, то быстрее изучишь и вероятнее глубже, чем поверхностное шаблонное кодирование простых примеров.
Другое дело, когда велосипеды пишутся для использования в продакшене, когда и так уже туча других готовых. Тут, конечно, во вред будет по многим причинам.
простота и атомарность — библиотечка представляет собой 1 java-файл, для добавления в проект достаточно просто добавить файлик к своим исходникам.
Если это не является самым главным критерием, то можно использовать spring-jdbc
Делает во многом тоже самое. Если используете maven, достаточно будет прибавить к проекту только зависимость
Всё верно написано. Самое ужасное в универе это сидеть на предмете и не понимать зачем оно мне вообще? Как можно хотеть что-то выучить, если ты даже не представляешь, чем это тебе пригодится? Самый простой пример это математика. Без всяких объяснений возникают векторы, матрицы, трансформации. Зачем они мне как программисту? Ведь, достаточно привести пример трансформации матриц в openGL, которые меняют положение предметов и у большинства программистов сразу появится стимул и желание понять что такое матрица и как же работают трансформации. Или же показать вычесление пересечений летящий пули с целью, как вычесление точки пересечения вектора с прямой. Два простых примера и у всех учащихся есть видимая и практическая цель изучения математики.
На деле такие практические примеры показывают крайне редко. У большинства преподавателей цель искучительно дать материал, а не научить его. Вроде бы программа обучения в универе и составляется для постепенного изучания, но предметы от этого более связанными не становятся.
Мне, в своё время, хватило прочитать книгу Рефакторинг от Фаулера, чтобы перестать писать длинные методы без особого разбиения. Первые главы книги сразу разъясняют почему не надо писать методы длиной больше 20 строк и как от этого избавиться в коде, который уже есть. Если новичку нравится программирование и он не глуп, то с большей вероятностью, книги будет достаточно, чтобы он перестал писать свой поток сознания.
Можно даже сделать так, что кто-то из более опытных программистов сядет с новичком и они вместе отрефакторят какой-то его кусок кода. Думаю, после такого показа новичок почувствует разницу между до и после и поймет как надо делать правильно.
Вам надо бы плагин для браузера написать, который за пользователя сам всё кликает (отчаяно надеялся увидеть ссылку на плагин в топике :) )
В Машине Тьюринга самое занимательное это как раз её «анимация». В университете был предмет, по которому были небольшие задачки на машине тьюринга. А так как в ручную писать лень, то использовались всякие симуляторы. Так вот самое большое удовольствие было после написание алгоритма, спустить симуляция и наблюдать как каретка движется туда сюда и меняет символы пока не перепишет всё до финального результата. По мне так это самое живое представление работы алгоритма.
Главное, чтобы музыка не мешала остальным. У нас в офисе если кто-то слушает музыку, то только в наушниках (правда, можешь из-за этого что-то пропустить или не помочь колеге). До этого было радио на целую комнату — довольно часто мешало\отвекало.
Один препод в универе, рассказывал, что с музыкой вообще не может работать, только в тишине.
В каком-то софтварном журнале читал такое определение архитектуры: это то, что мы хотим сделать правильно с самого начала.
Т.е. по идее это такие вещи, которые после начала кодирования изменить сложно.
Итого, чтобы получить близкую к идеальной систему, надо хорошо продумать базовые компоненты (используемые фреймворки, интернализацию, логирования, слои) и на базе этих компонентов с помощью TDD строить оставшееся. Таким образом сложно изменяемые части скорее всего будут сделаны правильно от начала, а остальное через TDD с большей вероятностью будет сделано также качественно.
Как-то странно работает плагин. Установил, подумал не работает. Оказывается работает, но чтобы пролистать одну вкладку надо сделать 5 «прокруток» колеса. Не знаю может это связанно с мышью (Logitech Performance Mouse MX) или с кол-вом вкладок (примерно 25). Сделал чувствительность 1 не помогло (все равно надо минимум 2 раза прокрутить колесо). Попробовал сделать чувствительность 100, стало еще хуже.
А возможность листать вкладки мне в хроме больше всего не хватало в сравнении с Оперой.
Всё верно. Поэтому в конце статьи и привел ссылку на SwingStates для всех желающих, которые хотели бы более глубоко изучить такой подход к написанию пользовательских интерфейсов.
Например, можно параллельно поддерживать в одном диалоге несколько разных View. Достаточно одновременно иметь несколько конечных автоматов, каждый из которых будет помнить своё состояние. Здесь есть замечательный пример как это выглядет.
Я пока еще сам полностью не разобрался с SwingStates фреймворком, но в некоторых ситуациях он действительно может помочь при написании сложных диалогов.
Опять же в SwingStates есть специальные дебаг-конечные-автоматы, с помощью которых можно очень наглядно увидеть, что у вас происходит в диалоге.
P.S. Добавил в код примера реализацию с помощью MVC.
По ссылке пример почти польностью статического диалога без каких-либо сложных связей между компонентами. Не вижу как бы MVP помогло упростить приведенный мной пример. Был бы рад, если бы вы могли привести код реализации с использованием MVP.
в тех репортах крайне мало информации. Часто бывает так, что какой-то баг проявляется только на определенных девайсах и без этой информации те репорты будут почти к ничему.
Без такой штуки не обойтись. Пользователи как-то неохотно отправляют стэктрейси и уж тем более почти никогда не пишут, что же они делали в момент крэша.
Думал Flurry с их системой событий (events) уж точно поможет в исправлении ошибок, а на деле там присылают только имя класса в котором возникло исключение и название метода откуда выбросили исключение (что естественно почти никак не помогает). Но с Acra можно и этого добиться, теперь каждый event я еще складываю в ErrorReporter.getInstance().putCustomData("eventId", eventParams); и тогда при репорте получаю последние события, которые совершил пользователь.
Отчасти это вина разработчиков. Вот тут об этом говорится подробно и с цифрами.
И самый главный злодей потребления энергии это именно интернет. Написал я как-то тут одно приложение, которое делало запрос каждые 10 секунд. И так уж получилось, что я забыл отключать эти запросы, когда приложение сворачивалось или получало onPause (например при блокировке экрана). Ну и как бы из-за этого телефон с _выключенным_ экраном умер часа за 3.
Так что как выход, я бы еще порекомендовал следить за приложениями, которые слишком часто лезут в интернеты.
Главная проблема блокнота, это то, что не всегда он есть с тобой. Часто бывает так, что едешь в трамвае, обдумываешь идею, бац! что-то в голову пришло, достал сотовый, добавил в TODO-лист что надо и по приходу домой\на работу у тебя это уже есть в веб-интерфейсе.
В gmail как раз есть TODO лист. Если еще вести отдельные списки под каждый проект, то получается удобно и организованно.
Получил письмо ***BlackBerry App World Notification — Product Approval *** 29.02, нажал на кнопочку «Post for sale» и до сегодняшнего дня ничего нового не получил (хотя в описании написано, что до 24 часов всё должно быть готово). Да и моя апликация вроде даже еще не появилась в их маркете…
Не вижу проблем в написании собственного велосипеда в целях самообразования при переходе с .net на java. Если тема велосипеда интересна, то и писать будет не скучно. Если будет писать не скучно, то быстрее изучишь и вероятнее глубже, чем поверхностное шаблонное кодирование простых примеров.
Другое дело, когда велосипеды пишутся для использования в продакшене, когда и так уже туча других готовых. Тут, конечно, во вред будет по многим причинам.
Если это не является самым главным критерием, то можно использовать spring-jdbc
Делает во многом тоже самое. Если используете maven, достаточно будет прибавить к проекту только зависимость
На деле такие практические примеры показывают крайне редко. У большинства преподавателей цель искучительно дать материал, а не научить его. Вроде бы программа обучения в универе и составляется для постепенного изучания, но предметы от этого более связанными не становятся.
Можно даже сделать так, что кто-то из более опытных программистов сядет с новичком и они вместе отрефакторят какой-то его кусок кода. Думаю, после такого показа новичок почувствует разницу между до и после и поймет как надо делать правильно.
В Машине Тьюринга самое занимательное это как раз её «анимация». В университете был предмет, по которому были небольшие задачки на машине тьюринга. А так как в ручную писать лень, то использовались всякие симуляторы. Так вот самое большое удовольствие было после написание алгоритма, спустить симуляция и наблюдать как каретка движется туда сюда и меняет символы пока не перепишет всё до финального результата. По мне так это самое живое представление работы алгоритма.
Красота же www.youtube.com/watch?v=E3keLeMwfHY
Один препод в универе, рассказывал, что с музыкой вообще не может работать, только в тишине.
Т.е. по идее это такие вещи, которые после начала кодирования изменить сложно.
Итого, чтобы получить близкую к идеальной систему, надо хорошо продумать базовые компоненты (используемые фреймворки, интернализацию, логирования, слои) и на базе этих компонентов с помощью TDD строить оставшееся. Таким образом сложно изменяемые части скорее всего будут сделаны правильно от начала, а остальное через TDD с большей вероятностью будет сделано также качественно.
в коде это выглядело бы так:
Выглядит намного читабельнее, чем инициализация через {{}}
А возможность листать вкладки мне в хроме больше всего не хватало в сравнении с Оперой.
Я пока еще сам полностью не разобрался с SwingStates фреймворком, но в некоторых ситуациях он действительно может помочь при написании сложных диалогов.
Опять же в SwingStates есть специальные дебаг-конечные-автоматы, с помощью которых можно очень наглядно увидеть, что у вас происходит в диалоге.
P.S. Добавил в код примера реализацию с помощью MVC.
Думал Flurry с их системой событий (events) уж точно поможет в исправлении ошибок, а на деле там присылают только имя класса в котором возникло исключение и название метода откуда выбросили исключение (что естественно почти никак не помогает). Но с Acra можно и этого добиться, теперь каждый event я еще складываю в
ErrorReporter.getInstance().putCustomData("eventId", eventParams);и тогда при репорте получаю последние события, которые совершил пользователь.И самый главный злодей потребления энергии это именно интернет. Написал я как-то тут одно приложение, которое делало запрос каждые 10 секунд. И так уж получилось, что я забыл отключать эти запросы, когда приложение сворачивалось или получало onPause (например при блокировке экрана). Ну и как бы из-за этого телефон с _выключенным_ экраном умер часа за 3.
Так что как выход, я бы еще порекомендовал следить за приложениями, которые слишком часто лезут в интернеты.
В gmail как раз есть TODO лист. Если еще вести отдельные списки под каждый проект, то получается удобно и организованно.