Comments 35
Имхо: лучше было бы категоризировать сразу с корня карточки.
/sdcard/games/%name%/ — файлы игр
/sdcard/apps/%name%/ — файлы софта
/sdcard/music/ — музыка
/sdcard/images/ — картинки закладок, временный кеш
/sdcard/fotos/ — фотки с камеры
После обильного тестирования софта, зайдя в раздел /sdcard можно дико ужаснуться. Туда пихают все, что хотят и когда хотят. Вообще не понятно, какая папка к какой софтине относится, где мои папки, где чужие.
Жаль не все такого стандарта придерживаются.
/sdcard/games/%name%/ — файлы игр
/sdcard/apps/%name%/ — файлы софта
/sdcard/music/ — музыка
/sdcard/images/ — картинки закладок, временный кеш
/sdcard/fotos/ — фотки с камеры
После обильного тестирования софта, зайдя в раздел /sdcard можно дико ужаснуться. Туда пихают все, что хотят и когда хотят. Вообще не понятно, какая папка к какой софтине относится, где мои папки, где чужие.
Жаль не все такого стандарта придерживаются.
Вообще с точки зрения пользователя все данные которые приложениям надо сохранять на SD хорошо бы записывать в /sdcard/data/«что угодно»/«еще что нибудь»/ главное чтоб все это хранилось в одной папке. Я сейчас не говорю фотографии и музыку.
Если программа будет туда записывать, то пользователь не увидит их, а затем при удалении программы не будет знать, что остался мусор. А так по крайней мере будет видеть каталог с названием программы и может быть вспомнит, что эту программу он удалил и удалит этот каталог вручную.
А что Вы скажете насчет /sdcard/data/Имя_Проекта?
В чем отличие между /sdcard/Имя_проекта и предложенном вами /sdcard/data/Имя_Проекта?
В том что в корне карточки не наплодится 100+ папок?
Уже ответили
Софт должен либо ставится как в венде спрашивая куда ему сесть, или как в лине в отведённую ему папку а не куда попало как это сейчас происходит. В корне флешки плодятся какие то левые папки и файлы и карта превращается в помойку.
Поддерживаю, раздражает большое кол-во папок создаваемых приложениями в корне папки. По мне лучше, чтобы все внутренние данные софта складывались в /sdcard/Android/daata/com.${разработчик}.${приложение}
Главная проблема возникает, когда приложения скидывают картинки в эти папки, они добавляются в галерею, тк в папке нет .nomedia
Главная проблема возникает, когда приложения скидывают картинки в эти папки, они добавляются в галерею, тк в папке нет .nomedia
У меня было несколько проектов где нужно много информации подгружать через инет (музыка, миди и т.д.). Если просто файлы временные на один сеанс, то проще в системном темп директории сохранять, а так прихдится на 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)
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)
>Не забывайте создавать комментарии даже для тех функций которые Вы считаете простыми и очевидными.
типа того ?:
да уж… куда без комментариев.
типа того ?:
/*
* Returns authenticated user
*/
public function getAuthenticatedUser() {
$id = Auth::getInstance();
$user = self::_read($id->id);
return $user;
}
да уж… куда без комментариев.
Javadocs в идеале должны быть у каждого метода и класса. Почитайте хотя бы это.
Ну вот вы сами и почитайте.
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».
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».
Мне кажется, что Вы вырываете фразы из контекста. Оттуда же:
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», что значит «вам не нужно»
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», что значит «вам не нужно»
Почитайте хотя бы вот это.
Если код нуждается в коментариях он либо слишком сложный, либо плохой. В любом случае его стоит переработать.
Если код нуждается в коментариях он либо слишком сложный, либо плохой. В любом случае его стоит переработать.
>Предлагаемый стандарт…
Это действительно стандарт именования или Ваше видение вопроса?
Если стандарт, линк хотелось бы посмотреть.
Это действительно стандарт именования или Ваше видение вопроса?
Если стандарт, линк хотелось бы посмотреть.
Это личное видение вопроса, хотя некоторые мысли возникли когда я был на GDD 2010. Собственно говоря именно после этой конференции у меня возникла идея систематизировать данные и оформить вышеизложенное.
Для оформления кода достаточно придерживаться этих правил. Конечно, там они в контексте самого проекта Android OS, но для приложений всё то же самое справедливо.
Я со многим почти согласен, но не могу понять почему Вы выбрали такой стиль для именования классов, взять хотя бы активити и адаптеры, Вам не кажется, что логичнее было бы описывать их как ИмяАктивитиActivity (например, MainActivity, SimpleActivity, PhoneActivity, NotesActivity etc.), то же самое для адаптеров (например рассмотрите хотя бы названия стандартных классов для адаптеров — SimpleCursorAdapter, MatrixAdapter etc.).
В IDE так проще использовать автокомплит.
При использовании моего метода все указанные ресурсы выстраиваются по алфавиту и по группам, гораздо легче искать.
Возможно, но глаз все-таки режет. С другой стороны — бывало ли у вас в проектах по 20 адаптеров и активити, чтобы были проблемы с поиском?
Да, был такой проект. Не 20, а около того. Если Вы попробуете именно так называть, то при открытии к примеру папки layout вы моментально поймете что к чему. Даже если это чужой проект.
К layout'ам я как раз совершенно никаких претензий не имею. Просто, я считаю, что запомнить 10-15 Активити, с которыми Вы работаете, скажем, пару недель будет проще, если их назвать естественным образом. Это всего лишь моё мнение, кому что ближе.
В общем, я придерживаюсь мнения Линуса Торвальдса по поводу классов :)
UFO just landed and posted this here
извините, вы их что, глазками ищите? поиск не-не?
Подписываюсь, даже глазу намного привычнее.
Не програмировал на Java, но на C# отношение к View, Model, Adapter или что-то чего много и отосится к какому-то слою всегда вносил просто в отдельный namaspace аналог package.
Почему, потому что подозреваю что все Activity у вас и так уже в отдельном package *.Activities.
Тогда получается полная квалификация имени *.Activity.FooActivity — масло масляное.
Конечно что для любого правила есть исключения и для одного класа пакет не стоит плодить. Просто пытаюсь уменьшить визуальный шум от несущественной в конкретной рабочей ситуации информации.
Если в пакете только Activity, то развернув дерево я вижу только Activity и сосредоточусь только на них.
Почему, потому что подозреваю что все Activity у вас и так уже в отдельном package *.Activities.
Тогда получается полная квалификация имени *.Activity.FooActivity — масло масляное.
Конечно что для любого правила есть исключения и для одного класа пакет не стоит плодить. Просто пытаюсь уменьшить визуальный шум от несущественной в конкретной рабочей ситуации информации.
Если в пакете только Activity, то развернув дерево я вижу только Activity и сосредоточусь только на них.
По поводу пакетов не согласен, т.к. лучше разбивать на пакеты по реализуемому куску функциональности, а не по тому от чего класс наследуется или чем он является (interface и т.д.)
В результате в пакете может лежать и интерфейс и диалог и активити. А называется он будет например image_gallery или image-gallery или imageGallery, кто как привык.
В результате в пакете может лежать и интерфейс и диалог и активити. А называется он будет например image_gallery или image-gallery или imageGallery, кто как привык.
По поводу разных состояний (нажато, фокус).
Я использую:
<что-то>_pressed.png
<что-то>_default.png
<что-то>_focused.png
<что-то>.xml — где описываю все эти состояния.
В итоге к png в коде не обращаюсь, только к xml.
Я использую:
<что-то>_pressed.png
<что-то>_default.png
<что-то>_focused.png
<что-то>.xml — где описываю все эти состояния.
В итоге к png в коде не обращаюсь, только к xml.
Sign up to leave a comment.
Стандарт разработки приложений под Android