Comments 16
Платформа для создания многоплатформенных приложений.
Это BaaS обычный.
На счет mobile SEO: Mobile Action довольно неплох.
Хорошая попытка, но список выглядит довольно… странно.
К примеру, пункты 22-21 потеряли актуальность, их правильнее заменить официальными и гораздо более удобными Material icons. Пункты 37-38 скорее вредны, чем полезны, — в свете AppCompat 21, и, в особенности 22.2.
Большая часть упомянутых тулзов притянута к Android, прямо скажем, за уши. В частности, это касается большинства упомянутых иструментов прототипирования и «расширений».
Глянул, а у автора на первых двух страницах все статьи переводные. Возникает вопрос — вы по какому принципу выбираете материалы для перевода? Заявки принимаете? Если да, то вот вам отличный кандидат: github.com/futurice/android-best-practices. Пользы для сообщества (и в особенности для начинающих Android разработчиков) будет несоизмеримо больше.
К примеру, пункты 22-21 потеряли актуальность, их правильнее заменить официальными и гораздо более удобными Material icons. Пункты 37-38 скорее вредны, чем полезны, — в свете AppCompat 21, и, в особенности 22.2.
Большая часть упомянутых тулзов притянута к Android, прямо скажем, за уши. В частности, это касается большинства упомянутых иструментов прототипирования и «расширений».
Глянул, а у автора на первых двух страницах все статьи переводные. Возникает вопрос — вы по какому принципу выбираете материалы для перевода? Заявки принимаете? Если да, то вот вам отличный кандидат: github.com/futurice/android-best-practices. Пользы для сообщества (и в особенности для начинающих Android разработчиков) будет несоизмеримо больше.
я как раз хотел английский попрактиковать :-) цель выглядит неплохо
а не многовато для одной статьи на Хабре?
в общем, если этот комментарий наберёт несколько плюсов, переведу на этой неделе :-)
а не многовато для одной статьи на Хабре?
в общем, если этот комментарий наберёт несколько плюсов, переведу на этой неделе :-)
Касаемо best practices — может ли мне кто на пальцах объяснить, почему Use Fragments to represent a UI screen. Про то, что я смогу запросто использовать один фрагмент в разных вариантах компоновки, мне рассказывать не надо, все легко разрешается и без фрагментов. Просто сколько я уже работаю над приложением, все никак не пойму что же в них такого.
не Вы один :-) corner.squareup.com/2014/10/advocating-against-android-fragments.html
хотя некоторые приятные вещи типа удобного backstack и дешёвых (по реализации) анимаций они дают
хотя некоторые приятные вещи типа удобного backstack и дешёвых (по реализации) анимаций они дают
Спасибо за интересную ссылку.
В общем, автор пришел к тому же, что и я: фрагменты необходимы только для красивой бесшовной анимации между экранами, либо (это я уже от себя) как элемент SDK, чтобы сторонние разработчики могли легко интегрировать элементы интерфейса в свои экраны, не нарушая иерархии своих Activity.
Но, как показывает практика, если нет требования о стопроцентной плавности UI, можно анимацию перехода и на Activity реализовать. Так, в приложении Google IO паттерн Navigation Drawer работает с Activity, каждая из которых имеет в своем составе Drawer, а переход осуществляется через fade in/out контента параллельно с анимацией самого Drawer'a. В приложении, над которым я работаю, я применил похожий подход, когда элементы одной Activity подводятся анимацией к реперным точкам, запускается новая Activity с отключенной анимацией перехода и копиями вышеупомянутых элементов в тех же реперных точках, а затем элементы разводятся анимациями по своим местам. Да, чуть-чуть лагает, но не настолько, чтобы погружаться в ад фрагментов.
В общем, автор пришел к тому же, что и я: фрагменты необходимы только для красивой бесшовной анимации между экранами, либо (это я уже от себя) как элемент SDK, чтобы сторонние разработчики могли легко интегрировать элементы интерфейса в свои экраны, не нарушая иерархии своих Activity.
Но, как показывает практика, если нет требования о стопроцентной плавности UI, можно анимацию перехода и на Activity реализовать. Так, в приложении Google IO паттерн Navigation Drawer работает с Activity, каждая из которых имеет в своем составе Drawer, а переход осуществляется через fade in/out контента параллельно с анимацией самого Drawer'a. В приложении, над которым я работаю, я применил похожий подход, когда элементы одной Activity подводятся анимацией к реперным точкам, запускается новая Activity с отключенной анимацией перехода и копиями вышеупомянутых элементов в тех же реперных точках, а затем элементы разводятся анимациями по своим местам. Да, чуть-чуть лагает, но не настолько, чтобы погружаться в ад фрагментов.
ну, лично у меня от фрагментов были примерно такие же ощущения, как от функционального анализа в универе :-)
то есть сначала не понимал, потом не понимал, а потом привык :-D
то есть сначала не понимал, потом не понимал, а потом привык :-D
Пара фрагментов может быть на одном экране, при этом их можно менять в рамках одной активности. Разве плохо что к примеру два фрагмента на одной активности имеют раздельный код, в своих классах?
И о каком аде фрагментов вы говорите?
И о каком аде фрагментов вы говорите?
В рамках одной Activity можно и View использовать. У них тоже будет отдельных код в своих классах. Ну вот если вам нравится их использовать, расскажите мне, пожалуйста, почему? Неужели только из-за того, что два фрагмента умещаются на одной Activity? Должны же быть весомые преимущества? Я серьезно не понимаю и хочу разобраться уже долгое время.
Что касается ада — это я про диаграмму по вышеприведенной ссылке.
Что касается ада — это я про диаграмму по вышеприведенной ссылке.
Да читал я уже пару раз эту старую статью. И не вижу там никакого ада. Activity если расписывать, то получится аналогичная картина, с её onPostCreate и прочими невидимыми проблемами.
Для вас удобнее менять вьюшку динамически в рамках активности? А как же backStack и прочие уже готовые вещи? А как же сохранение состояния самого класса (setRetainInstance)?
Не надо смотреть на фрагмент как на весомое преимущество, смотрите на него как удобное дополнение, который позволяет:
1. писать код более структурированно
2. иметь плавную анимацию с коробки (поправьте если не прав, с анимацией почти не работал, просто слышал об этом)
3. иметь из коробки такие вещи, как backstack, сохранение состояния и подобное
4. и в конце концов, он более легковестный, чем Activity
В рамках одной Activity можно и View использовать. У них тоже будет отдельных код в своих классах.
Для вас удобнее менять вьюшку динамически в рамках активности? А как же backStack и прочие уже готовые вещи? А как же сохранение состояния самого класса (setRetainInstance)?
Не надо смотреть на фрагмент как на весомое преимущество, смотрите на него как удобное дополнение, который позволяет:
1. писать код более структурированно
2. иметь плавную анимацию с коробки (поправьте если не прав, с анимацией почти не работал, просто слышал об этом)
3. иметь из коробки такие вещи, как backstack, сохранение состояния и подобное
4. и в конце концов, он более легковестный, чем Activity
Раньше я был бы с вами полностью согласен, сейчас же привык писать на фрагментах. Да и разделение кода, выполняющегося на одном экране между несколькими компонентами воспринимается лучше на мой взгляд. Хотя, как отметил mairos в своём комментарии, проблемы с ними действительно есть.
Да, заявки принимаю. На эту, как я понял, уже есть желающие, но если что-то ещё придумаете, что может быть полезным — пишите, пожалуйста, в личку.
Мне показалась интересной вот эта серия Developing for Android. Никаких особых откровений, конечно, но как вечернее чтиво — более чем достойно. Вполне в формате ресурса, особенно если сравнивать с 40 полезных инструментов, Карл!
Пункты 20 и 27. Эти компании после поглощения IBM и Oracle соответственно превратились в VAS данных платформ.
Их с очень большой натяжкой можно назвать полезными инструментами, так как там даже зарегистрироваться сложно, пока не получишь пару звонков от Enterprise продавцов.
Полезные сервисы для push уведомлений должны быть
1) Доступны в полном самообслуживании (зарегался, получил SDK, через 15 минут послал первый пуш)
2) Хорошо документированы
3) Поддерживать не только Android, чтобы по мере роста своей экосистемы не нужно было менять решение.
Из примеров таких Jeapie, ZeroPush, для игроделов будет полезен PushWoosh
Их с очень большой натяжкой можно назвать полезными инструментами, так как там даже зарегистрироваться сложно, пока не получишь пару звонков от Enterprise продавцов.
Полезные сервисы для push уведомлений должны быть
1) Доступны в полном самообслуживании (зарегался, получил SDK, через 15 минут послал первый пуш)
2) Хорошо документированы
3) Поддерживать не только Android, чтобы по мере роста своей экосистемы не нужно было менять решение.
Из примеров таких Jeapie, ZeroPush, для игроделов будет полезен PushWoosh
Sign up to leave a comment.
40+ полезных инструментов для разработчика приложений под Android