SpyDeX

Неужели единственный выход это идти джуниором?

Если цель посмотреть - работать не обязательно. Если цель работать - идите в контору. Если самому не лень разбираться (читай - способен чему-либо учиться самостоятельно) - берите туториалы по любому популярному фв. Читайте код, разбирайтесь, смотрите практику и цель кода. Для старта - фэтфри, ларавел. Потяжелее YII, симфони, зенд.

На developer.android.com примера нет

ага, у этих негодяев ваще ничего нет, зачем они только живут?..

$result = [0, 14, 1, 10]; //пример
if ( in_array(0, $result) && in_array(10, $result) ) {
    echo 'В предложении присутствуют приветствие и имя ассистента';
}

php.net/manual/ru/function.in-array.php

Вообще, для такой задачи есть устоявшаяся схема:

categories (id, name) - категории (отечественный, зарубежный и т.д.)
items (id, category_id, базовый набор атрибутов) - в вашем случае авторы
attributes (id, name, type, ...) - возможные атрибуты
categories_attributes (category_id, attribute_id) - атрибуты, допустимые для категории
items_attributes (item_id, attribute_id, value) - собственно значения атрибутов

Такая схема легко расширяется, может содержать дополнительную информацию - признак обязательности атрибута в описании, список допустимых значений атрибута для типов "один из списка", "несколько из списка", единицы измерения и т.д.

По заявлению Android хранить в Shared Preferences с private mode безопасно. Небезопасно это на рутованных устройствах, ибо там к файлу Shared Preferences можно получить доступ (без рута андройд не пускает в папку приложения).

Так что если что-то серьезное - то лучше шифровать. Как шифровать? Я бы сам хотел увидеть ответ профессионала.

У себя я сделал так: генерирую сессионны ключ AES, беру информацию, шифрую ее на сессионном ключе, результат сохраняю в приватный файл. Далее сессионный ключ шифрую на постоянном ключе RSA и сохраняю результат в файл. Сам же ключ RSA храниться в KeyStore. Почему нужен сессионный ключ? Потому что RSA может шифровать только небольшое кол-во инфы (245 байт вроде на ключе в 2048 бит).

Получается что инфа зашифрована сессионным ключом, который в свою очередь зашифрован ключе который храниться в KeyStore. Сам же KeyStore, как я понял, является аппаратным хранилищем (по крайней мере в современных устройствах) и доверять ему можно. Доступ к сохраненному ключу доступен только инстансу вашего приложения, да и то не сам ключ, а только возможность им оперировать. То есть просто так спереть инфу, без модификации вашего приложения, не получиться.

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

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

кто такой "язык андроид"?!

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

Правильно ли я понимаю что для хранение файлов их нужно разбивать по папкам,

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

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

А на боевых серверах использование хранилища в локальной файловой системе и вовсе нонсенс. Там эта проблема не стоит в принципе.

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

допустим на сервер пользователь с Ником username заливает файл file.mp4, и я сохраняю этот файл по пути u/us/use/user/usern/file.mp4 и такой путь формируется для каждого пользователя

Опять неправильно.

Во-первых, никогда, НИКОГДА не доверяйте данным, пришедшим от пользователя. Сохраняете загруженный файл – сгенерируйте имя сами. А оригинальное имя не возбраняется сохранить и в другом месте. Если понадобится дать возможность пользователю сохранить файл под оригинальным именем, это делается в несколько строк.

Во-вторых, Ваша сегментация слишком агрессивная. Если представить, что юзернейм может состоять только из строчных латинских букв и цифр (итого алфавит 26+10=36 символов), то такое хранилище сможет вместить 36 ^ (1 + 2 + 3 + 4 + 5) = 36^15 = 2.21 * 10^23 файлов без повторений. А что если юзернейм короче 5 символов? А что если он переименуется?

Помните "во-первых"? Так как нам нужно самим придумать имя файла, почему бы не воспользоваться либо UUID и сгенерировать уникальное (с высокой достоверностью) значение вида 28c5a6d8-f7b5-440f-aeaa-150e4fd0bebc, а его уже сегментировать? Например, два сегмента по два символа датут прикольные ссылки вида 28/c5/28c5a6d8-f7b5-440f-aeaa-150e4fd0bebc и возможность разместить 65 тысяч файлов так, чтобы они были по одной штуке в директории :)

Есть также вариант использовать не UUID, а посчитать контрольную сумму файла и взять её в качестве имени. Практическая ценность такого хеша, правда, тоже стремится к нулю :)

если будет 2 одинаковых названия файла у одного пользователя то просто добавляю к новому файлу номер (file1.mp4)

Если речь идёт о Джанге, то она сама так делает, это штатная функция хранилища.

С помощью ContentResolver получаешь данные контактов
Заполняешь ContentValues необходимыми данными
Затем записываешь изменения в резолвер
https://developer.android.com/reference/android/pr...