Android: проверь себя
Неплохой чек-лист с хабра. Жирным отметил то, что я осознал и выучил. Курсивом то, о чем имею представление, но не закрепилось еще.
- Файл AndroidManifest.xml: зачем нужен, необходимые параметры, секции. Здесь нужно рассказать про таг и , рассказать про параметр packageName, про и, про компоненты приложения, которые указываются.
- Структура проекта: assets, res, src, gen, libs. Что лежит в каждой папке, что должно лежать под версионным контролем, а что нет (папка gen никогда не кладется в VCS). Соответственно ассеты, ресурсы (картинки, музыка, лэйауты), java-код, сгенеренный код, библиотеки.
- Компоненты приложения. Activity, Service, BroadcastReceiver, ContentProvider. Зачем нужен каждый, как осуществляется работа, lifecycle каждого компонента.
- Особенности запуска Activity и Service. Что такое Task, Activity Stack. Как принимается решение о запуске процесса Service.
- ContentProvider, зачем нужен, как используется. Доступ и использование ContentResolver. Работа с курсорами. Помнить про managed cursors.
- BroadcastReceiver: статические и динамические, механизмы вызова, lifecycle.
- Межпроцессное взаимодействие. Что такое и зачем нужен Intent, как передавать информацию с его помощью, что такое Bundle и зачем нужен Parcelable. IntentFilter и для чего применяется. Способы взаимодействия Activity и Service(старт, биндинг). AIDL(Android interface definiotn language).
- Построение UI приложения. Что такое Layout и View, какие бывают типы layout'ов(4 штуки), зачем они применяются. Оптимизация UI под различные размеры экранов и плотность пикселей(использование dp).
- Хранение данных в платформе: 4 типа. Internal, External Storage, DB, SharedPreferences. Варианты использование, отличия.
- Локализация. Встроенные средства платформы для локализации, моменты выбора локали.
- Виджеты. Механизм создания виджетов, доступные средства UI в них. Что такое AppWidgetProvider.
- Работа в фоне. Когда использовать Service, когда AsyncTask. Что такое AsyncTask, его связь с UI. Сущность IntentService — что делает и чем полезна.
- Модель безопасности в Android. Разрешения.
- Использование телефонных средств: сенсоров, вибрации, GPS.
- Новинки платформы: Loaders, Fragments, In-app billing.
- Производительность в платформе: best practices. Неиспользование enums до 2.2, использование final и проч. Особенность работы на мобильном: ограничение по памяти и процессоу.
- Поддержка старых версий платформы: доступ до функциональности через Reflection.
- Собственные views: механизмы отрисовки, Canvas.
- Состояния компонент: какие компоненты системы могут сохранять состояния(Activity и View), способы сохранения и восстановления состояний, отличия механизмов для Activity и View.
- Механизмы подписи приложений для публикации в Android Market.
- Android NDK: вызов нативного кода
- Фреймворки для разработки под различные мобильные OS: Titanium, PhoneGap и прочие.
- Наследование в java, интерфейсы, абстрактные классы, классы, внутренние и анонимные. Множественное наследование интерфейсов, когда применяется. Замыкания.
- Модификаторы в java: доступа, синхронизации, прочие(static и final). Влияние final на производительность.
- Collections: типы коллекций(List, Set, Map). Различные реализации, применимость коллекций в тех или иных случаях. Сложность вставки, чтения и поиска в различных реализациях.
- Многопоточность: потоки, способы синхронизации, методы wait и notify. Ключевое слово synchronized, когда используется, что означает.
- Отличия библиотеки классов Java SE и платформы Android.
Android: JAVA
Еще пришлось резко вспоминать Java. И доучивать что там появилось нового за последние 10 лет.
Но язык выучить не проблема. Гораздо сложнее изучить стандартную библиотеку и стилистику. Причем, если необходимость учить язык и библиотеку лежит где-то на поверхности, то необходимость учить методику и стилистику приходит только со временем после тысячи написанного и, главное, переписанного кода и классов.
Вот тогда и приходит понимание вложенных классов, generics, зачем нужный интерфейсы и почему один из столпов ООП наследование надо использовать с умом и ограниченно.
И тут мне очень повезло, что мне посоветовали книгу J. Bloch — Effective Java.
Книга уже предполагает знание Java и учит не языку, а его использованию и хорошим методам. Во время чтения этой книги я целый месяц занимался почти только рефакторингом, нещадно перемешивая методы и классы, вычеркивая, перечеркивая и переделывая код. Зато в конце я даже сам начал в нем разбираться.
Под руку с правильной методикой идет статистический анализ кода. Самый простой пример статистического анализа кода — это, например, подсветка непарнозакрытых скобок. Анализ посложнее — это проверка типов. Но современные анализаторы кода способны уже на многое. Они умеют проверять не только явные ошибки, но ошибки и стиличтические и ошибки проектирования. Даже опечатки в коде могут пытаться найти.
Вот, например, далеко не полный список опций статистического анализатора в IDEA:
По хорошему пользоваться этим надо так: включить все опции и смотреть на warning-и, которые рассыпятся по вашему коду. Естественно нет никакого 100%-правильного стиля программирования. И даже о методиках разводят споры на сотни страниц. Поэтому некоторые опции проверки кода придется отключить, если они уж явно не согласны с вашим стилем. Что-то можно пометить исключениями в коде. Ну а если анализатор говорит, что "этот класс можно сделать и статическим" и вы с этим согласны, то не грех и исправить. Правда сперва нужно прочитать того же Блоха, чтобы понять, почему статический вложенный класс лучше обычного и почему при передаче типов лучше использоваться имя интерфейса, а не конкретного класса.
Анализатор дает совет, от которого невозможно отказаться:
Android: IDEA vs Eclipse
Когда летом я решил заняться программированием под Android, я был резко прерван приёмной комиссией. Пришлось забросить все остальное и отдаться ей. Но на самом деле там часто было интересно и творческо. Но самое главное — я оттуда вынес PyCharm
JetBrains PyCharm — это на самом деле подмножество JetBrains Intellij IDEA — IDE, которая объединяет в себя не Java, Python, PHP, Ruby, Objective C и много чего другого интересного.
И вот когда решил осенью снова вернуться к Android-программированию, я подумал «А вообще зачем этот монструозный неповоротливый Eclipse?». Тем более, что знакомые пацаны говорили, что Eclipse уже не тот и плохо развивается. Когда я поизучал вопрос поглубже, то понял, что единственное преимущество Eclipse в Android-программировании — это то, что сам Google официально поддерживает лишь его. В него встроены визуальные средства и все книги пишут про него.
Но на самом деле программу для андроида можно собрать и в консоли, было бы желание. Eclipse-плагин тянет только прослойку между SDK интерфейсом Eclipse и такую прослойку можно написать для любой IDE.
Ребята из JetBrains тоже озаботились этим. Их прослойка уже вполне рабочая, но пока (в версии 10.5) не включает визуальных компонент. Но
- собрать проект
- смотреть документацию встроенными методами
- устанавливать apk на телефон через adb
- смотреть лог
- дебажить приложение на телефоне
- взломанную IDEA найти не проблема
- Есть бесплатная и открытая IDEA Community Edition. И Android в ней есть. Что там вырезано я так пока и не понял, пока мне хватало всего. Может если бы я мучил Java EE, то тогда бы встретил какие-то ограничения.
Но еще в IDEA CE можно делать только OpenSource проекты. Остальное запрещено лицензией, которую никто не читает.
И через несколько месяцев я могу уже точно сказать, что программировать для Android без Eclipse можно
Новости андроидостроения
На русском языке вышла новая редакция суперкниги.
Android 3 для профессионалов. Создание приложений для планшетных компьютеров и смартфонов
Практически свежак. Перевод на этот раз хвалят. Отпугивает пока только цена. Но в итоге надо будет брать.
Nerd humour
Смеялся:
<@joosa> how do you say float in java? just 1.5f?
<@Gliptic> FloatFactoryFactory.getInstance(FloatFactoryFactory.defaultInstanceDescriptionString).getFactory(Locale.getLocale("en-US")).createBuilder().setString("1.5").getResult()
Невозможно сразу начать писать юнит (модульные)-тесты. Скорее всего к тому моменту, когда программист начинает понимать ценность юнит-тестирования, его стиль не всегда способствует созданию кода пригодного к тестированию «из коробки».
Но не стоит отчаиваться. Тесты писать все равно можно. Используя те же фреймворки. Только это будет уже называться «интеграционные тесты». Это ничуть не хуже «юнит-тестов» (разве, что снобы от программирования морщат носы, когда интеграционные тесты называют модульными) и какая-никакая выгода от них нет.
Но зато когда понимаешь дао модульного тестирования это сразу дает мощный толчок к организации собственного кода и к пониманию откуда растут ноги у некоторых шаблонов, прочищает мозги и повышает удои.
Ну и стоить не забывать, что выгода от тестирования и структуризации кода наступает тогда, когда количество кода перерастает некоторую массу. Хотя для тренировки и обкатки полезно начинать и с мелочей.
Отличная книга про PHP. В отличии от других отличных книг про PHP она не учит писать гостевые книги, дорвеи и дейтинги. Зато она учит писать в общем смысле.
Вообще к пониманию таких вещей подходишь постепенно сам. Это 8 лет назад пишешь первую гостевую книгу и радуешься. Потом пытаешься по этому же принципу написать что-то крупнее гостевой книги и форума. И понимаешь что подход не работает. Можно поднапрячься, написать и все заработает. Но когда придется этот код поддерживать несколько лет, то все чаще возникают ситуации, когда легче написать все заного, чем изменить.
Тут то и приходит понимание, что знание языка — это не только знание синтаксиса и стандартных библиотек. Есть еще много глобальных принципов организации кода, есть некоторые тонкости характерные для данного языка.
Аналогично с вынесенными в заголовок книги «шаблонами программирования». Шаблоны — это не какие-то академические конструкции придуманные бородатыми профессорами в университетах. Любой программист работающий с ООП и написавший что-либо крупнее гостевой книги, наверняка, сам изобрел некоторые из шаблонов. Просто он не знает, что это так называется.
Кроме того, шаблоны обычно написаны кровью предыдущих поколений. Если вдруг область применения шаблона очень похожа на текущую задачу, то не нужно изобретать велосипед, а лучше реализовать этот самый шаблон в собственном коде.
После этого код становится гладким и шелковистым и внезапное озарение заказчика в виде "а давайте еще посчитаем статистику по паре факультет/УГС" будет решено всего одним новым классом или даже одной строчкой кода. А в оставшееся время можно еще что-нибудь почитать умное.
Жаль только, что таких книг мало в основной массе литературы.
Mercurial — хороший компромис между svn и git. Он распределенный и он работает под виндой без шаманства. А еще есть bitbucket.
OAuth2
OAuth2, конечно, избавляет от возни с секретным ключами. Но с наскоку может быть не ясно, как, собственно, этот конечный токен-то получить обратно в приложение.
На этот случай есть замечательная страница в котором перечислены все (?) возможные способы до этого токена добраться. С плюсами и минусами.
