Интерфейс наглядный, скажем с Simple Last.fm скробблером я долго тупил, не мог понять работает он или нет, сколько заскробблил и т.д. + ui для планшетов.
Вообще, задумка была сделать скробблер, который будет мотивировать скробблить дальше, то есть с крупными надписями, сколько сегодня заскробблилось, сколько всего + статистика и рекомендации. Все это будет дорабатываться, на этой неделе выложу v0.4 beta :)
А я вот недавно начал и понял, что скроблерров на андроид устраивающих меня нет и в свободное время пилю свой, можете попробовать WAIL Beta буду рад отзывам :)
Печалька в том, что last.fm как-то застрял в своем развитии, их текущее приложение под андроид попахивает разработкой во времена 1.6-2.0, ui сайта тоже староват, но зато работает хорошо.
Самая частая ошибка программиста — «столкнулся с ерундовой проблемой и решил что всем был бы полезен именно мною написанный сервис по ее решению».
Тут надо тщательно все обдумывать, но в голову лезут безумные цифры потенциальной прибыли и всяческие метрики проекта, это да. Было тяжело, но в какой-то момент, я переборол в себе эту болезнь.
Хотя, на самом деле, кого я обманываю, сейчас вот пилю приложение для android, ну вы поняли :)
Имхо, программист не программист, если таким не страдает :D
Паттерны головного мозга. Смысл выделять это в отдельный паттерн? По-моему, это просто вариант реализации «наблюдателя» для конкретной задачи.
«VIP слушатель» — сразу думаешь о «наблюдателе» в котором есть VIP слушатель, приоритетнее остальных
Особенность с еще одним уведомлением об изменении нуууууууу… я бы не использовал такие опасные вещи, сайд эффекты будут восхитительными :)
Во-первых, грузить столько данных за раз, тем более на мобильное устройство, ну это у вас наверное странное странное апи. Как правило, доступ к большому количеству объектов делается со смещением от последнего загруженого (или аналогично), ну ок.
Во-вторых, раз уж вы грузите такие объемы, пихать их все распаршенными в память в любом случае неправильно, т.к. даже если вы сначала запишите весь ответ от сервера в файл или распарсите его целиком налету, то вы же все равно можете выпасть с OutOfMemoryError после его парсинга, решение с файлом и потоковым парсингом всех записей просто сократило вам потребление памяти ~ в 2 раза. Так что, смею заявить, что все предложенные способы упадут с OutOfMemoryError на еще более больших объемах данных.
Как бы сделал я (надеюсь не придется с таким апи работать), я бы последовательно парсил элементы прямо из InputStream от сервера и писал их в БД, зачем? Чтобы минимизировать расходы по памяти, т.к. InputStream освобождается при чтении, а все элементы в памяти мы не храним, пишем все в БД. Соответственно, потом надо будет просто извлекать их уже из БД при отображении в списке.
Естественно, писать в БД можно не прямо последовательно, а накапливая небольшой буфер в памяти. Так же и с чтением из БД при отображении в списке, можно подгружать следующие паки данных из БД пока пользователь не докрутил список до них, можно держать небольшой кеш данных в SoftHashMap чтобы не дергать БД постоянно. Вот как то так :)
Сразу обговорите по поводу серьезных библиотек, которые разработчик хочет затащить в проект (про серьезные, я имею в виду те, которые жестко связывают руки в дальнейшем, например Robospice, ActionBarSherlock (я в курсе про ActionBarCompat), AndroidAnnotations, etc)
Я не против его использования, но только если оно аргументированно. Просто так затаскивать такую библиотеку в проект не стоит, т.к. потом сменить ее на что-то другое (если потребуется) будет очень проблематично, вот и все :)
Могу вас успокоить, у нас в проектах robospice используется. Но скажем, я обычно сам пишу работу с сетью и кешем запросов, т.к. уже не раз наталкивался на особенности работы серверной стороны, то gzip для определенных запросов, то заголовки подменить и т.д. и т.п., ну и кеш, соответственно, тоже часто надо тюнить под проект, естественно, у меня для этого есть свои наработки.
Код порадует глаз, готовлю публикацию в Google Play.
На данный момент поддерживается нуллирование текста, при шаринге текста из других приложений выбирайте Dev null!
P.S. апи очень, очень плохо документировано, долго разбирался :D
P.P.S. ищу дизайнера и тестировщика, в следующих релизах надо сделать поддержку картинок и видео
По портфолио и работе разве что в исходники смотреть, бывают внешне нормальные приложения, а в исходники заглянешь — тьма тьмущая и сразу понятно, почему функционал внедряется медленно и тд и тп. К тому же, как вы поймете, какю роль человек играл в реализации проекта из портфолио, приукрасить в любят.
Поэтому и предлагаю обсуждать на примере реального проекта архитектурные моменты + реализации определённых, интересующих вас вещей.
Качество кода — тестовое задание, небольшой проект на день работы, как по мне — оптимальный вариант.
Тогда хорошо :) Вообще надо избегать предвзятости везде, не только на собеседованиях, понятно, что опыт за плечами и все такое, но лучше быть открытым к диалогу.
Ваш подход немного отличается от предложенного мной, но это отличие важно. Суть в том, что обсуждается реальный проект, который вы вот прямо сейчас открыли на экране и этот проект делали не вы. Это достаточно сильно меняет вещи. Мало кто захочет обсужадть ваш старый проект, по которому вы все знаете и своего мнения по его реализации скорее всего не измените, а кандидат должен быстренько вникнуть и угадать, как вы что в нем сделали, чтобы ответ вам понравился.
Ставьте друг друга в равные положения и обретете понимание в беседе :)
Я извиняюсь за возможную грубость, но я был на подобном собеседовании, я его прошел, но не скажу, что мне это понравилось. Человека было тяжело переубедить в чем то относительно реализаций, т.к. он заранее занял позицию «я уже такое сделал, а ты теперь расскажи как я это сделал и почему я молодец». Естественно, все зависит от того, как вы проводите собеседование, но я надеюсь, вы уловили, то что я хотел вам сказать.
Как добавление к посту: не стоит обсуждать проекты, которые вы сами уже реализовали, скорее всего, ваше мнение будет предвзятым по отношению к ответам кандидата
Вообще, задумка была сделать скробблер, который будет мотивировать скробблить дальше, то есть с крупными надписями, сколько сегодня заскробблилось, сколько всего + статистика и рекомендации. Все это будет дорабатываться, на этой неделе выложу v0.4 beta :)
Печалька в том, что last.fm как-то застрял в своем развитии, их текущее приложение под андроид попахивает разработкой во времена 1.6-2.0, ui сайта тоже староват, но зато работает хорошо.
Единственное, что напрягает — лаги карты в android версии даже на нормальных девайсах: нексус 4 и нексус 7.
Спасибо вам за прекрасный сервис, хоть кто-то еще делает действительно полезные вещи :)
Тут надо тщательно все обдумывать, но в голову лезут безумные цифры потенциальной прибыли и всяческие метрики проекта, это да. Было тяжело, но в какой-то момент, я переборол в себе эту болезнь.
Хотя, на самом деле, кого я обманываю, сейчас вот пилю приложение для android, ну вы поняли :)
Имхо, программист не программист, если таким не страдает :D
Непонятно, почему MC не делает Personal Licence по аналогии с JetBrains, получили бы приток разработчиков на свои же платформы.
Паттерны головного мозга.Смысл выделять это в отдельный паттерн? По-моему, это просто вариант реализации «наблюдателя» для конкретной задачи.«VIP слушатель» — сразу думаешь о «наблюдателе» в котором есть VIP слушатель, приоритетнее остальных
Особенность с еще одним уведомлением об изменении нуууууууу… я бы не использовал такие опасные вещи, сайд эффекты будут восхитительными :)
Не принимайте близко к сердцу :)
Во-первых, грузить столько данных за раз, тем более на мобильное устройство, ну это у вас наверное странное странное апи. Как правило, доступ к большому количеству объектов делается со смещением от последнего загруженого (или аналогично), ну ок.
Во-вторых, раз уж вы грузите такие объемы, пихать их все распаршенными в память в любом случае неправильно, т.к. даже если вы сначала запишите весь ответ от сервера в файл или распарсите его целиком налету, то вы же все равно можете выпасть с OutOfMemoryError после его парсинга, решение с файлом и потоковым парсингом всех записей просто сократило вам потребление памяти ~ в 2 раза. Так что, смею заявить, что все предложенные способы упадут с OutOfMemoryError на еще более больших объемах данных.
Как бы сделал я (надеюсь не придется с таким апи работать), я бы последовательно парсил элементы прямо из InputStream от сервера и писал их в БД, зачем? Чтобы минимизировать расходы по памяти, т.к. InputStream освобождается при чтении, а все элементы в памяти мы не храним, пишем все в БД. Соответственно, потом надо будет просто извлекать их уже из БД при отображении в списке.
Естественно, писать в БД можно не прямо последовательно, а накапливая небольшой буфер в памяти. Так же и с чтением из БД при отображении в списке, можно подгружать следующие паки данных из БД пока пользователь не докрутил список до них, можно держать небольшой кеш данных в SoftHashMap чтобы не дергать БД постоянно. Вот как то так :)
Правда я не люблю, когда библиотеки вносят «магию» в проект, уж лучше самому написать обертки для подобных вещей, это не сложно.
Я не против его использования, но только если оно аргументированно. Просто так затаскивать такую библиотеку в проект не стоит, т.к. потом сменить ее на что-то другое (если потребуется) будет очень проблематично, вот и все :)
Могу вас успокоить, у нас в проектах robospice используется. Но скажем, я обычно сам пишу работу с сетью и кешем запросов, т.к. уже не раз наталкивался на особенности работы серверной стороны, то gzip для определенных запросов, то заголовки подменить и т.д. и т.п., ну и кеш, соответственно, тоже часто надо тюнить под проект, естественно, у меня для этого есть свои наработки.
Из накипевшего, под windows phone недавно вообще пришлось запилить свою библиотеку для загрузки и кеша картинок: https://github.com/artem-zinnatullin/jet-image-loader/ (это к фразе о своих библиотеках)
QR код (линк):
Enjoy!
Ссылка на гитхаб: https://github.com/artem-zinnatullin/dev-null-android
Код порадует глаз, готовлю публикацию в Google Play.
На данный момент поддерживается нуллирование текста, при шаринге текста из других приложений выбирайте Dev null!
P.S. апи очень, очень плохо документировано, долго разбирался :D
P.P.S. ищу дизайнера и тестировщика, в следующих релизах надо сделать поддержку картинок и видео
Скриншоты:
Поэтому и предлагаю обсуждать на примере реального проекта архитектурные моменты + реализации определённых, интересующих вас вещей.
Качество кода — тестовое задание, небольшой проект на день работы, как по мне — оптимальный вариант.
Ставьте друг друга в равные положения и обретете понимание в беседе :)
Я извиняюсь за возможную грубость, но я был на подобном собеседовании, я его прошел, но не скажу, что мне это понравилось. Человека было тяжело переубедить в чем то относительно реализаций, т.к. он заранее занял позицию «я уже такое сделал, а ты теперь расскажи как я это сделал и почему я молодец». Естественно, все зависит от того, как вы проводите собеседование, но я надеюсь, вы уловили, то что я хотел вам сказать.
Как добавление к посту: не стоит обсуждать проекты, которые вы сами уже реализовали, скорее всего, ваше мнение будет предвзятым по отношению к ответам кандидата