Comments 38
еще планируется добавить поддержу ActionBar Style Generator, Holo Colors Generator и Android Asset Studio, что было бы вообще замечательно
Думаю кнопка скачать даже не обязательна. Собранные воедино полезные библиотеки, со ссылками на документацию и примеры использования — вот что нужно.
Гораздо удобнее сразу получить готовый проект-шаблон, чем руками добавлять либы и конфигурировать Maven
Я лишь хотел отметить полезность сервиса в целом, даже без такой замечательной возможности как подготовка проекта.
Спорный вопрос, я думаю это дело опыта. Например, создание Андроид проекта из архитипа — дело двух минут, ещё пару минут на добавление зависимостей.
Не думаю, есть хороший артифакт, который создает проект, а потом скопипастить нужные зависимости не сложно.
Не понимаю почему этот сервис при выборе Maven добавляет исходники ActionBarShertlock, а не добавляет его как зависимость.
Не понимаю почему этот сервис при выборе Maven добавляет исходники ActionBarShertlock, а не добавляет его как зависимость.
Кто еще какие либы посоветует? я бы добавил Android Query
=) Логотип замечательный, пинком отправляет Андроид назад, в прошлое.
Уж лучше бы R сделали пинающей буквой, хотя бы смысл появился ближе к задумке.
Уж лучше бы R сделали пинающей буквой, хотя бы смысл появился ближе к задумке.
Когда еще этого проекта не было собрал свой pom.xml со всеми мастхев зависимостями. Вот линк gist.github.com/3096710
Хотелось бы видеть в этом проекте фреймворк для тестирования Roboelectric и библиотеку для отображения и кеширования картинок из интернета github.com/novoda/ImageLoader/
Хотелось бы видеть в этом проекте фреймворк для тестирования Roboelectric и библиотеку для отображения и кеширования картинок из интернета github.com/novoda/ImageLoader/
Это что-то вроди cocoapods.org/?
В папке с проектом пишем файлик 'podfile' со списком сторонних проектов, которые бы хотели видеть в проекте, дергаем pod install и воуля — магия дружды скачивает исходники с github (обычно) и распихивает в отдельный подпроект, а на выходе получаем либу с хидерами, которая автоматом прилинковывается к нашему проекту. Добавлять свои «поды» может любой желающий. Пользуюсь уже очень давно. Да и хорошо дружить с системами контроля версий — добавляем только этот самый подфайл в репозиторий и все. Чисто, быстро, аккуратно :)
Теперь, я так понимаю, и у наших маленьких зеленых друзей тоже появилось нечто похожее?
В папке с проектом пишем файлик 'podfile' со списком сторонних проектов, которые бы хотели видеть в проекте, дергаем pod install и воуля — магия дружды скачивает исходники с github (обычно) и распихивает в отдельный подпроект, а на выходе получаем либу с хидерами, которая автоматом прилинковывается к нашему проекту. Добавлять свои «поды» может любой желающий. Пользуюсь уже очень давно. Да и хорошо дружить с системами контроля версий — добавляем только этот самый подфайл в репозиторий и все. Чисто, быстро, аккуратно :)
Теперь, я так понимаю, и у наших маленьких зеленых друзей тоже появилось нечто похожее?
Не нашел документации к ней толковой. Только почти пустая страничка с кратким описанием…
Уже есть мануал в процессе написания на droidparts.org и пара работающих приложений в
/sample. Из последних лучше начать с DroidPartsGram, там всё просто.
Интересная библиотека, спасибо. Фидбек:
1. Неудобны перекрытые стандартные именования классов
public class Activity extends android.app.Activity
Что с одной стороны приводит к путнице с другой стороны — не дает ровным счетом ничего
2. Нет поддержки фрагментов без использования Шерлок
3. Запутанная структура каталогов (одинаковые именования папок с библиотеками и примеров (например папка legasy))
4. Не удалось запустить пример легаси в idea
(какой то ад с org.droidparts.R; у меня сорвало мозг в итоге)
5. Нет простых примеров как например было в гриндроид( работа с сетью, загрузка изображений)
6. Небрежность в именовании классов в совокупности с отсутствием комментариев
типа есть RESTClient2 и RESTClient
7. Сложность расширения
Например я делаю класс RestActivity абстрактным, чтобы его можно было расширять и было видно что перекрывать
А в класс RestService добавляю Интерфейс для кастомных запросов, чтобы если понадобится какая то сложная логика типа аплоада фоток на вконтакте можно было легко ее имплементировать, а если нет — ничего трогать не надо, тут я такого не увидел, или не понял как это реализовывать
8. Матрешки в коде
Либы, завязаннные на разные версии сдк, завзываются друг на друга в итоге что-то вроде
Activity extends android.app.Activity
Activity extends org.droidparts.Activity
Причем пакеты во всех либах названы идентично (org.droidparts) Что в итоге окончательно сносит мозг — классы названы одинаково, пакеты одинаково, папки одинаково — где что — не разобраться без прочтения всех исходников всех библиотек
9. Какие то странные слабодокументированные зависимости от наличия в манифесте чего то там + какие то зависимости от конфига прогвард который лежит непойми где так как все папки названы одинаково и вложены друг в друга, классы названы одинаково, пакеты одинаково ну и так далее
10. Вобщем мне показалось что можно сделать тоже самое напорядок проще и в разы универсальнее без ковыряния в сорцах дроидпартс
11. На уровне ощущений создалось впечатление что как то много сделано запутано, много нерасширяемо и при этом довольно жестко связано друг с другом
Тем не менее библиотека показалась мне интересной и перспективной. Удачи в развитии
1. Неудобны перекрытые стандартные именования классов
public class Activity extends android.app.Activity
Что с одной стороны приводит к путнице с другой стороны — не дает ровным счетом ничего
2. Нет поддержки фрагментов без использования Шерлок
3. Запутанная структура каталогов (одинаковые именования папок с библиотеками и примеров (например папка legasy))
4. Не удалось запустить пример легаси в idea
(какой то ад с org.droidparts.R; у меня сорвало мозг в итоге)
5. Нет простых примеров как например было в гриндроид( работа с сетью, загрузка изображений)
6. Небрежность в именовании классов в совокупности с отсутствием комментариев
типа есть RESTClient2 и RESTClient
7. Сложность расширения
Например я делаю класс RestActivity абстрактным, чтобы его можно было расширять и было видно что перекрывать
А в класс RestService добавляю Интерфейс для кастомных запросов, чтобы если понадобится какая то сложная логика типа аплоада фоток на вконтакте можно было легко ее имплементировать, а если нет — ничего трогать не надо, тут я такого не увидел, или не понял как это реализовывать
8. Матрешки в коде
Либы, завязаннные на разные версии сдк, завзываются друг на друга в итоге что-то вроде
Activity extends android.app.Activity
Activity extends org.droidparts.Activity
Причем пакеты во всех либах названы идентично (org.droidparts) Что в итоге окончательно сносит мозг — классы названы одинаково, пакеты одинаково, папки одинаково — где что — не разобраться без прочтения всех исходников всех библиотек
9. Какие то странные слабодокументированные зависимости от наличия в манифесте чего то там + какие то зависимости от конфига прогвард который лежит непойми где так как все папки названы одинаково и вложены друг в друга, классы названы одинаково, пакеты одинаково ну и так далее
10. Вобщем мне показалось что можно сделать тоже самое напорядок проще и в разы универсальнее без ковыряния в сорцах дроидпартс
11. На уровне ощущений создалось впечатление что как то много сделано запутано, много нерасширяемо и при этом довольно жестко связано друг с другом
Тем не менее библиотека показалась мне интересной и перспективной. Удачи в развитии
Спасибо за фидбек.
1. Сначала классы имели префикс DP, т.е. DPActivity, но я быстро отказался от этой идеи, т.к. Objective-C-style и вообще есть в urbandictionary. (: Называть вроде DroidPartsActivity — тоже неочень.
Текущий вариант — дело правильного выбора при autocomplete. Плюс — нет визуального мусора.
2. Уже есть: droidparts-modern-native
3. В версии 0.8.5 переименованы для удобства пользователей Idea. В Eclipse такой проблемы нет.
4. Навскидку, текущая версия в Idea 12 импортируется. Более подробно не занимался, т.к. то, что Idea делает с Android library-проектами, выносит мозг уже мне.
5. Да, это TODO. Сам функционал есть в примере DroidPartsGram, пока нужно читать код.
6. Небрежность — хм. RESTClient2 наследует RESTClient и добавляет фунционал. По-моему, логично.
7. Не понял идеи и проблемы если честно. Какие ограничения вносит droidparts? Можно на SO: stackoverflow.com/questions/tagged/droidparts
8. Тут накладывается видение структуры проекта Idea. Корневой package name всех модулей — да, одинаковый.
9. Кофиг в Manifest уже документирован
В общем, да, нужно уделить больше внимания описанию особенностей.
Спасибо!
1. Сначала классы имели префикс DP, т.е. DPActivity, но я быстро отказался от этой идеи, т.к. Objective-C-style и вообще есть в urbandictionary. (: Называть вроде DroidPartsActivity — тоже неочень.
Текущий вариант — дело правильного выбора при autocomplete. Плюс — нет визуального мусора.
2. Уже есть: droidparts-modern-native
3. В версии 0.8.5 переименованы для удобства пользователей Idea. В Eclipse такой проблемы нет.
4. Навскидку, текущая версия в Idea 12 импортируется. Более подробно не занимался, т.к. то, что Idea делает с Android library-проектами, выносит мозг уже мне.
5. Да, это TODO. Сам функционал есть в примере DroidPartsGram, пока нужно читать код.
6. Небрежность — хм. RESTClient2 наследует RESTClient и добавляет фунционал. По-моему, логично.
7. Не понял идеи и проблемы если честно. Какие ограничения вносит droidparts? Можно на SO: stackoverflow.com/questions/tagged/droidparts
8. Тут накладывается видение структуры проекта Idea. Корневой package name всех модулей — да, одинаковый.
9. Кофиг в Manifest уже документирован
В общем, да, нужно уделить больше внимания описанию особенностей.
Спасибо!
6. Небрежность в именовании классов в совокупности с отсутствием комментариев
типа есть RESTClient2 и RESTClient
Майкрософт в ActiveX/COM использует такой же подход. До 4х местами цифры доходят.
типа есть RESTClient2 и RESTClient
Майкрософт в ActiveX/COM использует такой же подход. До 4х местами цифры доходят.
Реквистирую фишек по моей библиотеки: github.com/serso/android-common, можно ответить здесь: habrahabr.ru/qa/25939
Пересмотрел все, слишком уж много эти комбаины на себя берут/на себя тянут
В итоге написал свою)
github.com/recoilme/recoilme
— rest api простая работа с вебсервисами (get post put delete на расслабоне)
— asyncimageview — либа для работы с изображениями на базе greendroid допиленная до ума
Планирую потихоньку переносить в нее остальные наработки
В итоге написал свою)
github.com/recoilme/recoilme
— rest api простая работа с вебсервисами (get post put delete на расслабоне)
— asyncimageview — либа для работы с изображениями на базе greendroid допиленная до ума
Планирую потихоньку переносить в нее остальные наработки
В своих проектах (iOS) использую:
'BlocksKit' — musthave
'MTStatusBarOverlay'
'JSONKit' — musthave
'QuickDialog'
'SVPullToRefresh'
'JWFolders'
'RegexKitLite' — musthave
'SDWebImage'
Эти сторонние проекты здорово экономят время разработки и достаточно стабильны.
'BlocksKit' — musthave
'MTStatusBarOverlay'
'JSONKit' — musthave
'QuickDialog'
'SVPullToRefresh'
'JWFolders'
'RegexKitLite' — musthave
'SDWebImage'
Эти сторонние проекты здорово экономят время разработки и достаточно стабильны.
Кстати, что вы используете для PullToRefresh?
А что насчет работы с соцсетями? и oAuth?
Что то никак не хочет стартовать.
Если берешь неполную версию без поддержки 4ой версии — мрёт сразу на экшен баре, так как он ее использует.
Если качаю полную версию, то при построении мрёт на ошибке с библиотекой аннотаций —
Если берешь неполную версию без поддержки 4ой версии — мрёт сразу на экшен баре, так как он ее использует.
Если качаю полную версию, то при построении мрёт на ошибке с библиотекой аннотаций —
Unable to load annotation processor factory '/NeverDroid/ext-libs/androidannotations-2.6.jar' for project com.volhovec.test.app.MainActivity_ com.test.neverdroid.app.MainActivity_ Annotation processor factory path APT Build Problem
Sign up to leave a comment.
AndroidKickstartr — создай современный проект в пять кликов