?

Log in

No account? Create an account

Предыдущая версия | Обновление

Андроид. Глава 2.

И так продолжим.
Значит с понятием Interface Bulder для Android разобрались. Его тупо нет. Хотя я думаю, что если бы Google задался этим вопросом в серьез, то они бы сделали его правильно и красиво. В конце-концов есть масса положительных примеров, которыми люди пользуются с удовольствием. Но не в этом дело. Мое отношение к встроенному в Eclipse IB - он просто есть. Как есть еще 1000 никому не нужных библиотек. Другое дело это Debug. Во первых, почему все пишущие на C/C++ люди так любят Breakpoint-ы? Нет, я ничего против не имею, но есть одно но, Java не особо позитивно относится к этим вещам, ибо они превращают ее в интерпритируемый язык. Да и система Exception-ов не зря придумана. И наличие StackTrace-а в них тоже не случайно. 99% ошибок Java-ского flow ловится при помощи правильного написания логов и анализа StackTrace-ов. В любом случае народ активно доказывал мне, что Eclipse круче по причине наличия в нем debug-ера. (замечу что IntelliJ Idea 9, также имеет полноценную поддержку Android со всеми Eclipse-овыми приблудами)

Резюмируя все вышесказанное заключу - для Java-ской разработки под Android не важно в какой Ide писать. Хотя если слова XML и Layout вызывают у вас легкий страх - садитесь на Eclipse. Или даже не садитесь, а изучайте как выращивать комнатные растения, а разработку приложений оставьте профессионалам.

Следующий сюрприз, с которым я столкнулся - автогенеренный класс. Я долго тупил над классом с названием R, который содержал в себе еще несколько статических подклассов. Оказалось, что это просто статически прописываемые ссылки на ресурсы, (просто гениально, и зачем придумали stream-ы и методы типа Class.getRecourceAsStream(String)) которые скармливаются всем кому не поподя начиная непосредственно с RecourceManager-а, и заканчивая медиаплеерами и прочей системной ерундой. Хорошо хоть догадались оставить классические методы. У меня тогда возник вопрос, а что делать когда надо как-то категоризировать ресурсы, ответ оказался очевиден - ничего. Ну не поддерживает платформа разбиение рисунков на подкатегории. Более того, не дай бог тебе положить ресурс с левым именем или содержанием не в ту папку. Ты будешь проклят в веках и твое приложение никогда не соберется. С одной стороны - хорошо, приучает программистов не складывать в одну кучу изображения, XML layout-а и пр ерунду, но где полное описание того, что куда можно положить, что бы этот ежик полетел? (про документацию от google поговорим позже) Где возмоность разбить графику или layout по категориям? В результате таких художественных изысков ресурсы именуются типа "about_screen_header_back_button_image_unfocused.png", что естественно не дает легко и непринужденно читать не только код, но и названия самих файлов.
В принципе, графики в проектах обычно немного и это можно пережить. (Хотя, когда приложение состаит из 3-4 независимых flow, каждое из которых насчитывает около десятка различных экранов, должен появиться легкий дискомфорт. Подобное приложение я писал на Blackberry, и эти flow я разделил изначально.) гораздо интереснее дела обстоят с ID компонентов. Представьте себе, что они тоже все складируются в единой куче. С другой стороны, кажется - зачем ноно все нужно? Зачем вообще нужны ID? Объясняю, я еще ни разу не встречал экранных форм со статическим контентом (разве что экраны с информацией о каком-то действии или приложении, или заставки в приложениях) всегда надо как-то управлять элементами, начиная от навешивания событий на нажатие кнопок, и заканчива анимированным показом слайдов. Везде надо получать ссылки на компоненты, для чего и нужны ID. А тепеь пердставьте - у вас в программе 10-15 экранов (нормальные информационные приложения насчитывают и больше) И каждый содержит 5-7 элементов, которыми надо управлять. И того минимум 50 ID падает в единую кучу. У меня не получилось вписать все имена в 20 символов. Более того, под конец я стал путаться в именованиях. Вобщем - идея хорошая, но реализация сырая до безобразия.

Продолжая разговор о ресурсах, отвечу еще на пару вопросов, которые могли бы возникнуть у нормального человека. Первое, что делать, если тебе вдруг понадобились ресурсы формата не поддерживаемого в Android. Например doc, rtf или вообще свой формат. Ответ прост. В Android проекте папка с ресурсами содержит папку raw. также плоскую папку с ресурсами, которые никак не проверяются, но при этом, так же как и остальные, имеют свои уникальные ID. (Написал и задумался, а имеют ли? Не верьте мне на слово, если нужно будет проверьте при случае.) Так же помимо res есть папка assets, куда складываются "классические" ресурсы. Все это безобразие управляется 2-мя менеджерами представленными в классах Recources и AssetManager. Но будьте осторожны, добывать эти классы стоит непосредственно из Activity, Или другого наследника Context, доступного вам. второй вопрос - доступны ли нам ресурсы самой платформы. т.е. стандартные градиенты, иконки и пр вкусности. Ответ - да, для этого есть класс android.R
Продолжение следует...

История версий

Октябрь 2015
Вс Пн Вт Ср Чт Пт Сб
    123
45678910
11121314151617
18192021222324
25262728293031
Разработано LiveJournal.com
Designed by Katy Towell