Как найти путь к устройству

Была ли эта статья полезной?

Как найти путь к файлу, который запускает программу. Урок 29

Иногда в процессе работы на компьютере необходимо найти папку или запускающий файл той или иной программы или игры. Особенно часто такое действие необходимо для русификации программы или добавления в неё кистей или текстур (как в Фотошопе). Для человека, который хорошо разбирается в компьютерах это не проблема, но для начинающего пользователя найти путь к файлу или папке, задача не из легких, а может даже и не выполнима.

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

Существует несколько способов определения пути к файлу или папке программы. Сейчас мы их рассмотрим.

Находим путь к файлу или папке по ярлыку на рабочем столе

Это самый легкий и быстрый способ. Если ярлык программы находится на рабочем столе, то кликаем по нему правой кнопкой мыши и выбираем в самом низу выпадающего списка, который называется контекстным меню, пункт «Свойства».

В открывшемся окне «Свойства» в поле «Объект» вы увидите путь к запускающему файлу программы (с расширением .exe), а ниже, в поле «Рабочая папка» показан путь к папке программы.

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

Как узнать путь, если ярлыка программы нет на рабочем столе

Если ярлыка программы нет на рабочем столе, то он наверняка имеется в меню «Пуск». В Windows XP или Windows 7 можно так же кликнуть по значку программы правой кнопкой мыши и выбрать в контекстном меню пункт «Свойства».

А вот в Windows 10 такой номер не прокатит. Там надо сначала открыть меню «Пуск» найти папку программы, открыть её, кликнуть правой кнопкой мыши по иконке программы, выбрать в самом верху открывшегося списка по строке «Дополнительно», а в следующем списке кликнуть по строке «Перейти к расположению файла».

В открывшемся окне программы наверху в адресной строке будет показан путь к этому файлу.

Его можно скопировать. Для этого необходимо кликнуть правой кнопкой мыши по адресу и выбрать в выпадающем меню пункт «Копировать адрес».

Эти методы особенно актуальны, если у вас нет доступа к скрытым файлам и папкам.

Видео «Как найти путь к файлу»

_____________________________________________________________________________________________________ Удачи!

Источник

3 способа скопировать путь к файлу или папке

В этой инструкции я покажу, как скопировать полный путь к файлу в Windows 10. Иногда нам для поиска информации или работы других программ, необходимо скопировать путь расположения файла, папки или каталога. Чтобы найти определенный файл в иерархии каталогов, необходимо указать абсолютный путь к нему.

Как посмотреть путь к файлу?

Существует несколько способов просмотра и копирования пути к файлам и папкам. Самый простой из них, это использовать клавишу “Shift” ⇒

С помощью Shift

Например, путь к рабочему столу Windows 10 на моем компьютере имеет вид ⇒ C:UsersAlexDesktop, а к папке Temp ⇒ C:Program Files (x86)Temp

Через свойства папки или файла

Следующим способом удобно смотреть расположение папки или документа, но скопировать весь путь не получиться, так как последняя директория в пути не указывается.

Например путь к графическому изображению help.png

E:Фотоматериалы и изображенияИконкиhelp.png

будет выглядеть как ⇒

E:Фотоматериалы и изображенияИконки

Узнаем путь к файлу в командной строке Windows

Для примера создадим документ Word с именем Doc3 и поместим его в любую папку и посмотрим его путь в командной строке.

Как скопировать путь к файлу на Mac

Пути к файлам и папкам на Маке можно узнать так же, как и в Виндовс через Shift, только названия кнопок другие ⇒

В буфер обмена скопируется полный путь к файлу например ⇒

Скопировать полный путь до любого файла достаточно просто и с этим справится любой пользователь ПК или ноутбука.

Абсолютный и относительный пути

Путь (от англ. path) — набор символов, показывающий расположение файла или каталога в файловой системе.

Например, в следующей записи G:EPIM ProНеобходимые программыABBYY FineReader 10.0.102.95 Proreadme.txt

readme.txt — это имя файла, а G:EPIM ProНеобходимые программыABBYY FineReader 10.0.102.95 Pro — путь к нему.

Полный (абсолютный) путь к файлу начинается с логического имени диска. Далее идут имена вложенных друг в друга папок (их может быть сколько угодно много). В последней папке содержится требуемый файл.

Стандартный путь состоит из трех компонентов ⇒

Если присутствуют все три компонента, путь является абсолютным. Полный путь всегда начинается с корневого каталога.

Если буква тома или диска не указана и имя каталога начинается с символа разделителя, то такой путь задан относительно корня текущего диска. В противном случае путь задан относительно текущего каталога.

В следующей таблице показаны некоторые возможные пути к каталогам и файлам ⇒

C:UsersAlexAppData – абсолютный путь к файлу из корня диска C.
AlexAppData – относительный путь из подкаталога.

Источник

Форматы путей к файлам в системах Windows

Традиционные пути DOS

Стандартный путь DOS может состоять из трех компонентов:

Если присутствуют все три компонента, путь является абсолютным. Если буква тома или диска не указана и имя каталога начинается с символа разделителя каталогов, такой путь задан относительно корня текущего диска. В противном случае путь задан относительно текущего каталога. В следующей таблице показаны некоторые возможные пути к каталогам и файлам.

В приведенном ниже примере показано различие между абсолютными и относительными путями. Предполагается, что каталог D:FY2018 существует и вы не установили какой-либо текущий каталог для диска D: из командной строки перед запуском этого примера.

Если вы хотите увидеть комментарии к коду, переведенные на языки, отличные от английского, сообщите нам на странице обсуждения этой проблемы на сайте GitHub.

UNC-пути

UNC-пути (универсальное соглашение об именовании) используются для доступа к сетевым ресурсам и имеют следующий формат:

Ниже приводятся некоторые примеры UNC-путей:

Пути к устройствам DOS

В операционной системе Windows используется унифицированная объектная модель, которая указывает на все ресурсы, включая файлы. Эти пути к объектам доступны из окна консоли и предоставляются на уровень Win32 с использованием специальной папки с символьными ссылками, с которыми сопоставляются устаревшие пути DOS и UNC. Доступ к этой специальной папке осуществляется с использованием синтаксиса пути к устройству DOS, который может иметь одну из приведенных ниже форм:

Помимо использования буквы диска, вы можете указать том с помощью его GUID. Синтаксис будет иметь вид:

Путь к устройству DOS состоит из следующих компонентов:

Описатель пути к устройству ( \. или \? ), который идентифицирует путь как путь к устройству DOS.

Символьная ссылка на «реальный» объект устройства (C: в случае имени диска или Volume в случае GUID тома).

Для UNC-путей к устройствам часть сервера или общего сетевого ресурса образует том. Например, в пути \?server1e:utilities\filecomparer часть server1utilities представляет сервер или общий сетевой ресурс. Это важно при вызове такого метода, как Path.GetFullPath(String, String) с сегментами с относительным путем к каталогу, поскольку переход дальше тома невозможен.

Пример. Способы задать ссылку на один и тот же файл

В следующем примере демонстрируются некоторые способы задать ссылку на файл с использованием API в пространстве имен System.IO. В этом примере создается экземпляр объекта FileInfo и используются его свойства Name и Length, чтобы отобразить имя и длину файла.

Нормализация путей

Практически все передаваемые в API Windows пути нормализуются. При нормализации в Windows выполняются следующие действия:

Нормализация осуществляется неявно, но при необходимости вы можете выполнить ее явно, вызвав метод Path.GetFullPath, который создает оболочку для вызова функции GetFullPathName(). Также можно вызвать функцию GetFullPathName() Windows напрямую с помощью P/Invoke.

Идентификация пути

На первом шаге процесса нормализации осуществляется идентификация типа пути. Пути могут относиться к одной из нескольких категорий:

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

Работа с устаревшими устройствами

Применение текущего каталога

Канонизация разделителей

Все символы косой черты ( / ) преобразуются в стандартные разделители Windows, то есть символы обратной косой черты ( ). Если они присутствуют, последовательность символов косой черты после первых двух таких символов свертывается в один символ косой черты.

Вычисление относительных компонентов

Если обнаруживается одна точка, текущий сегмент удаляется, поскольку он ссылается на текущий каталог.

Если обнаруживаются две точки, удаляются текущий и родительский сегмент, поскольку в этом случае задается ссылка на родительский каталог.

Родительские каталоги удаляются только в том случае, если они не находятся после корня пути. Корень пути зависит от его типа. Это будет диск ( C: ) для путей DOS, сервер или общий сетевой ресурс для UNC-путей ( \ServerShare ) и префикс пути к устройству для путей к устройствам ( \? или \. ).

Удаление знаков

Помимо удаленных ранее разделителей и относительных сегментов во время нормализации также удаляются некоторые дополнительные знаки:

Если сегмент заканчивается одной точкой, эта точка удаляется. (Сегмент, состоящий из одной или двух точек, нормализуется на предыдущем шаге. Сегмент, состоящий из трех или более точек, не нормализуется и фактически представляет собой допустимое имя файла или каталога.)

Если путь не заканчивается разделителем, удаляются все конечные точки и пробелы (U+0020). Если последний сегмент содержит только одну или две точки, к нему применяется приведенное выше правило для относительных компонентов.

Это правило устанавливает, что вы можете создать имя каталога с конечным пробелом, добавив разделитель после пробела.

Создавать имена каталогов или файлов с конечным пробелом нельзя. Наличие конечных пробелов может затруднить или исключить возможность доступа к каталогу. В связи с этим при попытке обработать каталоги или файлы, имена которых содержат конечные пробелы, происходит сбой приложения.

Пропуск нормализации

Как правило, любой путь, передаваемый в API Windows передается в функцию GetFullPathName и нормализуется. Существует одно важное исключение: путь к устройству, который начинается со знака вопроса, а не с точки. Если путь не начинается с последовательности \? (обратите внимание на использование канонической формы с обратной косой чертой), он нормализуется.

Зачем нужно пропускать нормализацию? Существует три основных причины:

Повышение производительности за счет пропуска нормализации в тех случаях, когда нормализация уже выполнена.

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

Регистр символов и файловая система Windows

Особенность файловой системы Windows заключается в том, что пользователи и разработчики, имеющие дело с другими операционными системами, могут сталкиваться с проблемами из-за того, что в именах каталогов и путях не учитывается регистр символов. Это значит, что в именах каталогов и файлов сохраняется регистр строк, используемый в момент их создания. Например, вызов метода

Источник

Путь к файлу

В этой статье я попробую разжевать, разобрать “по косточкам” эту тему настолько подробно и внятно, чтобы стало понятно абсолютно любому человеку, даже если он только вчера сел за компьютер.

Надеюсь, вы уже знаете, что такое файл. Поэтому разбирать этот термин здесь не будем. А будем вести рассказ только о пути к файлу.

Имя файла

Имя файла в операционных системах DOS/Windows состоит из трёх частей:

В первых версиях операционной системы DOS имя (то есть первая часть имени файла) не могла иметь длину более 8 символов. Сейчас это ограничение снято. Однако я настоятельно рекомендую не давать файлам слишком длинные имена. Потому что если полный путь к файлу (о полном пути будет сказано далее) будет превышать 255 символов, то вы можете столкнуться с разного рода неприятностями (особенно в операционных системах вплоть до Windows XP).

Подробнее см. в бесплатной книге Компьютер для чайника.

Полный путь к файлу

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

То есть полный путь файла начинается с буквы диска и заканчивается именем файла. А между ними могут быть имена каталогов. Каталоги в DOS/Windows разделяются косой чертой ().

Например, у нас на диске С есть папка 000, а в этой папке есть папка 010, а в этой папке тоже есть папка 100. А уже в папке 100 есть файл 111.ТХТ. Тогда полный путь к файлу будет такой:

Относительный путь к файлу

С этим вопросом у новичков обычно сложнее. Потому что теорию относительности люди как-то плохо понимают ))))

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

Однако не всегда удобно использовать полный путь, потому что он слишком длинный. И если сейчас для пользователя это не так актуально, то во времена DOS и других подобных операционных систем, где приходилось работать только в командной строке, этот вопрос был очень и очень даже большой проблемой.

Поэтому, чтобы не писать полный путь к файлу для того, чтобы получить к нему доступ, придумали такую штуку как относительный путь.

Сначала давайте вспомним про вложенные папки (каталоги).

Следовательно, у каждой папки могут быть (а могут и не быть) дочерние папки. И у каждой папки (кроме корневого каталога) есть родительские папки.

Следовательно, в общем случае папка может быть родительской относительно своих “детей”, и дочерней относительно своих “родителей”.

А теперь наконец после долгих лирических отступлений перейдём к относительности путей. Итак, снова вспомним наш пример:

С:00010100111.ТХТ

Здесь каталог 010 является дочерним относительно каталога 000, и он же является родительским по отношению к каталогу 100.

Когда вы работаете в командной строке или в Проводнике, то в текущий момент времени вы можете находиться только в одной папке.

Например, вы находитесь в папке 010. То есть выше находятся

а ниже находится каталог

Тогда относительный путь к файлу 111.ТХТ будет таким:

Так можно перемещаться вниз относительно текущего местоположения.

А можно ли перемещаться вверх?

Например, если мы находимся здесь: С:0010100, и в папке 010 у нас есть файл 011.ТХТ, то открыть его можно так:

А если в папке 000 у нас есть файл 001.ТХТ, то открыть его можно так:

Ну и так далее. Надеюсь, смысл вы уловили.

Как прописать путь к файлу

Вернёмся к полному пути, который мы рассмотрели выше:

Если у вас есть такие папки и в этих папках есть такой файл, то вы можете ввести этот путь в командной строке, или прописать путь к файлу в адресной строке Проводника и нажать ENTER. Тогда файл откроется (если, конечно, у вас есть программа, которая сможет его открыть и с этой программой связан тип этого файла).

Командную строку можно вызвать комбинацией клавиш WIN+R или через меню ПУСК-ВЫПОЛНИТЬ.

Когда вы откроете командную строку, то можете непосредственно в ней ввести команду (в нашем случае командой будет путь к файлу) и нажать ENTER.

Если же вам любопытно немного помучиться и представить, как люди работали в DOS, то вы можете открыть командный интерпретатор. Для этого в командной строке наберите CMD (для Windows 2000 и выше) или COMMAND (для Windows 95/98/ME) и нажмите ENTER.

Если что-то осталось непонятным, то опять же отправляю вас к книге Компьютер для чайника.

Неправильный путь к файлу

Наверняка при работе за компьютером вы получали сообщение о том, что файл не найден, что указан неправильный путь или что-то типа того (см. рис. выше).

Причины подобных ошибок могут быть следующими:

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

Источник

Путь к файлу

В операционных системах UNIX разделительным знаком при записи пути является «/». В Windows — «». Эти знаки служат для разделения названия каталогов, составляющих путь к файлу.

Например, в следующей записи адресации /home/user_viki/foo/bar.txt часть bar.txt — это имя файла, а /home/user_viki/foo — путь к нему.

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

Связанные понятия

Упоминания в литературе

Связанные понятия (продолжение)

Жёсткой ссылкой (англ. hard link) в UFS-совместимых файловых системах называется структурная составляющая файла — описывающий его элемент каталога.

В информатике трансклюзией называют включение одного электронного документа или его части в другие электронные документы посредством гипертекстовой ссылки. Трансклюзия обычно подразумевает отображение документа, на который делается ссылка. Документ (запись) отображается автоматически и доступен конечному пользователю. Кажется, что в результате трансклюзии образуется единый сложный документ, в то время как на самом деле его части были оперативно собраны из разных источников, которые могут храниться.

Источник

Время на прочтение
5 мин

Количество просмотров 265K

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

Итак, начнем с теории.

Терминология

Гугл нам говорит, что есть следующие понятия:

1. Внутренняя (internal) память — это часть встроенной в телефон карты памяти. При ее использовании по умолчанию папка приложения защищена от доступа других приложений (Using the Internal Storage).
2. Внешняя (external) память — это общее «внешнее хранилище», т.е. это может быть как часть встроенной памяти, так и удаляемое устройство. Обычно это часть встроенной памяти, как удаляемое устройство я видел в последний раз на андройде 2.2, где встроенная память была около 2Гб, и подключаемая память становилась внешней (Using the External Storage).
3. Удаляемая (removable) память — все хранилища, которые могут быть удалены из устройства без «хирургических» вмешательств.

До версии KitKat 4.4 API не предоставляло функционала для получения путей к внешней памяти. Начиная с этой версии (API 19) появилась функция public abstract File[] getExternalFilesDirs (String type), которая возвращает массив строк с путями к внутренней и внешней памяти. Но как же быть с нашей SD Card, которая вставлена в слот? Путь к ней мы опять не можем получить.

Результаты поиска

Чтобы ответить на поставленный вопрос я обратился к всезнающему гуглу. Но и он мне не дал четкого ответа. Было рассмотрено множество вариантов определения от использования стандартных функций, которые ведут к внешней памяти, но ничего общего с удаляемыми устройствами хранения данных они не имеют, до обработки правил монтирования устройств (Android же на ядре Linux работает). В последних случаях были использованы «зашитые» пути к папке с примонтироваными устройствами (в различных версиях эта директория разная). Не стоит забывать, что от версии к версии правила монтирования меняются.

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

Описание кода

Был создан класс MountDevice, который содержит в себе путь к устройству, тип устройства и некий хэш.
Типов устройств выделено два (внутреннюю память я не стал трогать, так как к ней доступ можно получить через API системы).

public enum MountDeviceType {
    EXTERNAL_SD_CARD, REMOVABLE_SD_CARD
}

И был создан класс StorageHelper, который и осуществляет поиск доступных карт памяти.

В классе StorageHelper реализовано два способа поиска — через системное окружение (Environment) и с использованием утилиты Linux mount, а точнее результата ее выполнения.

Способ первый — Environment

При работе с окружением я использую стандартную функцию getExternalStorageDirectory() для получения информации о внешней памяти. Чтобы получить информацию о удаляемой памяти, я использую переменную окружения «SECONDARY_STORAGE«.

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

String path = android.os.Environment.getExternalStorageDirectory()
		.getAbsolutePath();
if (!path.trim().isEmpty()
		&& android.os.Environment.getExternalStorageState().equals(
				android.os.Environment.MEDIA_MOUNTED)) {
	testAndAdd(path, MountDeviceType.EXTERNAL_SD_CARD);
}

// Получаем ремувабл
String rawSecondaryStoragesStr = System.getenv("SECONDARY_STORAGE");
if (rawSecondaryStoragesStr != null
		&& !rawSecondaryStoragesStr.isEmpty()) {
	// All Secondary SD-CARDs splited into array
	final String[] rawSecondaryStorages = rawSecondaryStoragesStr
			.split(File.pathSeparator);
	for (String rawSecondaryStorage : rawSecondaryStorages) {
		testAndAdd(rawSecondaryStorage,
				MountDeviceType.REMOVABLE_SD_CARD);
	}
}

Вариант решения взят со stackoverflow. Ответ где-то там внизу.

Способ второй — mount

Так как у меня долго не получалось заставить систему мне сказать путь к удаляемой памяти, я решил искать в сторону примонтированных устройств. В системе есть файлы конфигурации, в которых описаны правила монтирования внешних устройств. Все бы хорошо, но на Android версии 4.* к этому файлу простым смертным доступа нет, поэтому рассматривать этот способ не буду.

Вернемся к утилите mount. При запуске без параметров команда возвращает список смонтированных файловых систем. Удаляемые устройства имеют обычно формат файловой системы FAT, то будем выделять строки, в которых есть характеристика «fat«. Внешняя память будет характеризоваться параметром «fuse«.

Примечание: при использовании такого способа не всегда корректно (скорее всего я что-то не учел) определяются типы смотнтированных устройств. Разницу замечал на разных версиях Android. Поэтому этот способ можно использовать как дополнительный.

try {
	Runtime runtime = Runtime.getRuntime();
	proc = runtime.exec("mount");
	try {
		is = proc.getInputStream();
		isr = new InputStreamReader(is);
		br = new BufferedReader(isr);
		while ((line = br.readLine()) != null) {
			if (line.contains("secure"))
				continue;

			if (line.contains("asec"))
				continue;

			if (line.contains("fat")) {// TF card
				String columns[] = line.split(" ");
				if (columns != null && columns.length > 1) {
					testAndAdd(columns[1],
							MountDeviceType.REMOVABLE_SD_CARD);
				}
			} else if (line.contains("fuse")) {// internal(External)
												// storage
				String columns[] = line.split(" ");
				if (columns != null && columns.length > 1) {
					// mount = mount.concat(columns[1] + "n");
					testAndAdd(columns[1],
							MountDeviceType.EXTERNAL_SD_CARD);
				}
			}
		}
	} finally {
		...
	}
} catch (Exception e) {
	...
}

Вариант решения взят со stackoverflow. Ответов там несколько примерно одинаковых.

Про дублирование

Многие замечали в директории монтирования устройств такую картину:

/storage/sdcard0/
/storage/emulated/0/
/storage/emulated/legacy/

И что самое интересно, все это одна и та же внешняя карта памяти. Такое дробление начинается с версии Jelly Bean и сделано это для поддержки многопользовательского режима работы системы. Более подробно тут. И вот, чтобы не получать одну и туже карту памяти как различные устройства, необходим способ определения идентичности. Если бы был доступ к конфигурации монтирования, то и вопросов не было. Но доступа нет. Поэтому я тут подсмотрел решение с расчетом хэша для каждого устройства:

1. создаем StringBuilder
2. записываем в него общий размер устройства и размер используемого пространства устройства
3. обходим содержимое корня устройства
4. записываем имя каталога
5. записываем имя файла и размер
6. вычисляем hash

private int calcHash(File dir) {
	StringBuilder tmpHash = new StringBuilder();

	tmpHash.append(dir.getTotalSpace());
	tmpHash.append(dir.getUsableSpace());

	File[] list = dir.listFiles();
	for (File file : list) {
		tmpHash.append(file.getName());
		if (file.isFile()) {
			tmpHash.append(file.length());
		}
	}

	return tmpHash.toString().hashCode();

}

Пример использования

/* Получаем базовый путь */
if (!mPreferences.contains(PREFS_BASEBATH)) {
	// Если еще не сохранялся в настройках, то пытаемся найти карты
	// памяти
	ArrayList<MountDevice> storages = StorageHelper.getInstance()
			.getRemovableMountedDevices();
	// проверяем съемные карты памяти
	if (storages.size() != 0) {
		setBasePath(storages.get(0).getPath() + mAppPath);
	} else if ((storages = StorageHelper.getInstance() // Проверяем
														// внутреннюю
														// память
			.getExternalMountedDevices()).size() != 0) {
		setBasePath(storages.get(0).getPath() + mAppPath);
	}
} else {
	// Вытаскиваем из сохранненых настроек
	mBasePath = mPreferences.getString(PREFS_BASEBATH, context
			.getFilesDir().getParent());
}

Заключение

Подробные рассуждения по этому вопросу понимания памяти в Android, некоторые советы можно прочитать тут.

Исходный код всего класса

расположен

еще нигде не расположен. На днях постараюсь разместить на gitHub.

Кто еще какими способами пользуется?

UPD1: Исходный код класса на bitbucket