Стандарт разработки приложений под Android

    Разработчик Андроида сталкивается с большим количеством файлов и ресурсов предназначенных для разных частей программы. Даже он сам через месяц не может вспомнить, какой файл или ресурс к чему относится.
    Предлагаемый ниже материал основан на моем опыте разработок многих проектов для Андроида и опробован уже в нескольких проектах. В результате простых правил нагромождение файлов и ресурсов превращается в удобочитаемый проект, экономит время и нервы. Особенно оказалось удобным при работе в команде, когда к проекту могут присоединяться новые программисты. В Eclipse вы легко находите любые ресурсы, поскольку они становятся уникальными, легко находимыми и сортируются в понятном порядке в любых списках. Общие удобные правила позволяют легко читать чужой код и находить нужные ресурсы.

    Большинство из указанного является моими личным мнением.



    Стандарт разработки приложений Android



    Названия всех файлов


    Имя файла пишется маленькими буквами, отражает читабельное название элемента, возможно несколькими словами. Пробел заменяется знаком подчеркивания.

    Расположение файлов пользователя на SD карте


    Корневой каталог для всех файлов пользователя, кроме временных:
    /sdcard/название проекта/, например /sdcard/TalentMania/

    Каталог для музыки:
    /sdcard/название проекта/sound/, например /sdcard/TalentMania/sound/
    Каталог для MIDI:
    /sdcard/название проекта/midi/, например /sdcard/TalentMania/midi/
    Каталог для графики:
    /sdcard/название проекта/img/, например /sdcard/TalentMania/img/

    Подкаталоги для файлов различных активити:
    /sdcard/название проекта/img/название активити/, например /sdcard/TalentMania/img/guitar/

    Расположение временных файлов — использовать стандартные функции класса File:
    createTempFile(String prefix, String suffix, File directory)
    Creates an empty temporary file in the given directory using the given prefix and suffix as part of the file name.
    createTempFile(String prefix, String suffix)
    Creates an empty temporary file using the given prefix and suffix as part of the file name.

    Расположени файлов в ресурсах приложения


    Графика и звуки предназначенные для использования в ассетсах (к примеру библиотекой AndEngine) группируются в следующих каталогах:
    MIDI файлы — assets/midi/
    Графика для спрайтов — assets/gfx/
    TTF фонты — assets/font/
    Общие файлы, используемые разными activity распологаются в корне. Файлы используемые только одной activity распологаются в соответствующем подкаталоге, например: assets/gfx/guitar/

    MP3 файлы распологаются в каталоге res/raw/.

    Наименования иконок


    В наименованиях иконок используется префикс описывающий ее тип

    Иконки ic_ Пример: ic_star.png
    Иконки запуска ic_launcher_ Пример: ic_launcher_calendar.png
    Иконки меню ic_menu_ Пример: ic_menu_archive.png
    Иконки статус бара ic_stat_sys_ or ic_stat_notify_ Пример: ic_stat_notify_msg.png
    Иконки вкладок ic_tab_ Пример: ic_tab_recent.png
    Иконки диалога ic_dialog_ Пример: ic_dialog_info.png

    Кнопки


    bt_имя_pressed.png (нажатое изображение) и bt_имя_default.png (изображение по умолчанию)
    xml описывающий анимацию размещаются в каталоге drawable! bt_имя.xml

    Лэйауты


    основные лэйауты соответствуют названиям вызывающих активити.
    ac_название_класса.xml – соответствует названию класса активити AcНазваниеКласса.java.

    Дополнительные view для данного лэйаута соответствуют названиям вызывающих активити + название view ac_название_класса_название_view_название.xml

    view_название_view.xml – общие view для разных лэйаутов.
    adt_название_адаптера.xml – название лэйаута для адаптера списка
    dialog_название_диалога.xml – название диалога

    Наименования элементов в лэйауте


    Название элемента используемого в лейауте —
    AcНазваниеЛэйаутаНазваниеЭлемента

    к примеру: android:id="@+id/AcMenuTemplateTopPanel" показывает что элемент называется “top panel” и предназначен для активити AcMenuTemplate

    Анимация


    файлы описания анимации сохраняются в каталоге res/drawable.
    Для кнопок — bt_имя_anim.png
    Для анимации — anim_имя_активити_имя_анимации.png
    Если анимации много, то удобнее размещать ее в отдельный каталог res/anim

    Графика


    Бэкграунд — bg_ориентация_имя.png.
    Изображение — im_имя.png

    Наименование пакетов


    Активити — activities
    Адаптеры — adapters
    Данные — data
    Диалоги — dialogs
    Интерфейсы — interfaces
    Виды — views

    Наименование классов


    Активити — AcНазваниеАктивити
    Адаптеры для списков — AdtНазваниеАдаптера
    Диалоги — DialogНазваниеДиалога
    Интерфейс- НазваниеИнтерфейсаInterface

    Итог


    Предлагаемый стандарт не является догмой и постоянно подвергается изменениям по мере накопления эмпирического опыта. Надеюсь услышать отзывы и предложения по данной теме. Интересно узнать опыт других разработчиков.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 35

      0
      Имхо: лучше было бы категоризировать сразу с корня карточки.
      /sdcard/games/%name%/ — файлы игр
      /sdcard/apps/%name%/ — файлы софта
      /sdcard/music/ — музыка
      /sdcard/images/ — картинки закладок, временный кеш
      /sdcard/fotos/ — фотки с камеры

      После обильного тестирования софта, зайдя в раздел /sdcard можно дико ужаснуться. Туда пихают все, что хотят и когда хотят. Вообще не понятно, какая папка к какой софтине относится, где мои папки, где чужие.
      Жаль не все такого стандарта придерживаются.
        +1
        Вообще с точки зрения пользователя все данные которые приложениям надо сохранять на SD хорошо бы записывать в /sdcard/data/«что угодно»/«еще что нибудь»/ главное чтоб все это хранилось в одной папке. Я сейчас не говорю фотографии и музыку.
          0
          Если программа будет туда записывать, то пользователь не увидит их, а затем при удалении программы не будет знать, что остался мусор. А так по крайней мере будет видеть каталог с названием программы и может быть вспомнит, что эту программу он удалил и удалит этот каталог вручную.
            0
            А что Вы скажете насчет /sdcard/data/Имя_Проекта?
              0
              В чем отличие между /sdcard/Имя_проекта и предложенном вами /sdcard/data/Имя_Проекта?
                +3
                В том что в корне карточки не наплодится 100+ папок?
                  0
            0
            Софт должен либо ставится как в венде спрашивая куда ему сесть, или как в лине в отведённую ему папку а не куда попало как это сейчас происходит. В корне флешки плодятся какие то левые папки и файлы и карта превращается в помойку.
              0
              да, бардак на флешке раздражает сильно. и бэкапить неудобно.
              0
              Поддерживаю, раздражает большое кол-во папок создаваемых приложениями в корне папки. По мне лучше, чтобы все внутренние данные софта складывались в /sdcard/Android/daata/com.${разработчик}.${приложение}
              Главная проблема возникает, когда приложения скидывают картинки в эти папки, они добавляются в галерею, тк в папке нет .nomedia
              +3
              У меня было несколько проектов где нужно много информации подгружать через инет (музыка, миди и т.д.). Если просто файлы временные на один сеанс, то проще в системном темп директории сохранять, а так прихдится на SD размещать. Если называть корневой каталог на карте названием программы и только в него все размещать, то управлять проще. Если хочешь после удаления программы мусор убрать, то легче удалить один каталог. Это касается только для старых версий андроида. Если есть возможность работать для 2.2, то можно не заморачиваться и использовать следующее:

              If you're using API Level 7 or lower, use getExternalStorageDirectory(), to open a File representing the root of the external storage. You should then write your data in the following directory:

              /Android/data/<package_name>/files/
              The <package_name> is your Java-style package name, such as «com.example.android.app». If the user's device is running API Level 8 or greater and they uninstall your application, this directory and all its contents will be deleted.

              (взято с developer.android.com/guide/topics/data/data-storage.html)
                +3
                >Не забывайте создавать комментарии даже для тех функций которые Вы считаете простыми и очевидными.

                типа того ?:
                /*
                 * Returns authenticated user
                 */
                public function getAuthenticatedUser() {
                    $id = Auth::getInstance();
                    $user = self::_read($id->id);
                
                    return $user;
                }
                

                да уж… куда без комментариев.
                  –1
                  Javadocs в идеале должны быть у каждого метода и класса. Почитайте хотя бы это.
                    +1
                    Ну вот вы сами и почитайте.

                    Every class and nontrivial public method you write must contain a Javadoc comment

                    You do not need to write Javadoc for trivial get and set methods such as setFoo() if all your Javadoc would say is «sets Foo».
                      0
                      Мне кажется, что Вы вырываете фразы из контекста. Оттуда же:

                      Every method you write, whether public or otherwise, would benefit from Javadoc. Public methods are part of an API and therefore require Javadoc.

                      Любой public всегда лучше документировать. К тому же слово require — означает «требовать», в отличии от «do not need», что значит «вам не нужно»
                      –2
                      Почитайте хотя бы вот это.
                      Если код нуждается в коментариях он либо слишком сложный, либо плохой. В любом случае его стоит переработать.
                        0
                        Суть не в понятности и чистоте кода, а в его правильном документировании, что является стандартом.
                        Javadocs — стандарт промышленного программирования на Java.
                    0
                    >Предлагаемый стандарт…

                    Это действительно стандарт именования или Ваше видение вопроса?
                    Если стандарт, линк хотелось бы посмотреть.
                      0
                      Это личное видение вопроса, хотя некоторые мысли возникли когда я был на GDD 2010. Собственно говоря именно после этой конференции у меня возникла идея систематизировать данные и оформить вышеизложенное.
                        0
                        Всё-таки, было бы хорошо как-то обозначить в заголовке, что это your point of view.
                          0
                          Идея хорошая, некоторые вещи взял на заметку.
                          0
                          Для оформления кода достаточно придерживаться этих правил. Конечно, там они в контексте самого проекта Android OS, но для приложений всё то же самое справедливо.
                          0
                          Я со многим почти согласен, но не могу понять почему Вы выбрали такой стиль для именования классов, взять хотя бы активити и адаптеры, Вам не кажется, что логичнее было бы описывать их как ИмяАктивитиActivity (например, MainActivity, SimpleActivity, PhoneActivity, NotesActivity etc.), то же самое для адаптеров (например рассмотрите хотя бы названия стандартных классов для адаптеров — SimpleCursorAdapter, MatrixAdapter etc.).
                            –1
                            В IDE так проще использовать автокомплит.
                              –1
                              При использовании моего метода все указанные ресурсы выстраиваются по алфавиту и по группам, гораздо легче искать.
                                0
                                Возможно, но глаз все-таки режет. С другой стороны — бывало ли у вас в проектах по 20 адаптеров и активити, чтобы были проблемы с поиском?
                                  –1
                                  Да, был такой проект. Не 20, а около того. Если Вы попробуете именно так называть, то при открытии к примеру папки layout вы моментально поймете что к чему. Даже если это чужой проект.
                                    0
                                    К layout'ам я как раз совершенно никаких претензий не имею. Просто, я считаю, что запомнить 10-15 Активити, с которыми Вы работаете, скажем, пару недель будет проще, если их назвать естественным образом. Это всего лишь моё мнение, кому что ближе.
                                      0
                                      В общем, я придерживаюсь мнения Линуса Торвальдса по поводу классов :)
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      +1
                                      извините, вы их что, глазками ищите? поиск не-не?
                                      0
                                      Подписываюсь, даже глазу намного привычнее.
                                        0
                                        Не програмировал на Java, но на C# отношение к View, Model, Adapter или что-то чего много и отосится к какому-то слою всегда вносил просто в отдельный namaspace аналог package.
                                        Почему, потому что подозреваю что все Activity у вас и так уже в отдельном package *.Activities.
                                        Тогда получается полная квалификация имени *.Activity.FooActivity — масло масляное.
                                        Конечно что для любого правила есть исключения и для одного класа пакет не стоит плодить. Просто пытаюсь уменьшить визуальный шум от несущественной в конкретной рабочей ситуации информации.
                                        Если в пакете только Activity, то развернув дерево я вижу только Activity и сосредоточусь только на них.
                                        +4
                                        По поводу пакетов не согласен, т.к. лучше разбивать на пакеты по реализуемому куску функциональности, а не по тому от чего класс наследуется или чем он является (interface и т.д.)

                                        В результате в пакете может лежать и интерфейс и диалог и активити. А называется он будет например image_gallery или image-gallery или imageGallery, кто как привык.
                                          0
                                          По поводу разных состояний (нажато, фокус).
                                          Я использую:
                                          <что-то>_pressed.png
                                          <что-то>_default.png
                                          <что-то>_focused.png
                                          <что-то>.xml — где описываю все эти состояния.

                                          В итоге к png в коде не обращаюсь, только к xml.

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.