alex_denkin, так вроде уже 20 лет как в XXI веке живём — Юникод уже везде. К тому же, автора библиотеки зовут Владимир Агафонкин, что как бы намекает...
При том, что QR-код - один из самых быстрых способов передать что-то с десктопа на мобильник. У автора задача обратная, поэтому подошло бы что-то такое же просто и удобное как QR код, только "наоборот". Безусловно, предложенная мною реализация несколько топорна, но в отличие от описанного гипотетического сервиса - уже существует.
То есть нужно что-то вроде QR-кода наоборот: показывает мобильник, считывает компьютер. Понадобится вебкамера, какой-нибудь онлайн-ридер и какая-нибудь программа для генерации QR на смартфоне (ну или 2qr.ru для спартанских условий).
Телодвижений больше, чем со специальным софтом, зато более универсально.
Есть серьёзные аргумент как за, так и против данной «оптимизации». Мы пока воздержимся от того, чтобы рекомендовать отключение файла подкачки или, наоборот, советовать воздержаться от этого.
OSZ Vertex несёт проблемы из поколения в поколение. Как заметили выше, просто перестаёт распознаваться в BIOS. Похоже, компании проще оплачивать обмен, чем искать и исправлять баг. С точки же зрения пользователя, OSZ лучше занести в чёрный список.
Алармы с типом RTC_WAKEUP должны «будить» телефон из спячки. Нюанс в том, что телефон просыпается всего на несколько секунд, и приложение может не успеть обработать данные.
Поэтому при пробуждении приложение первым делом должно получить WakeLock, после чего может не спеша делать свои дела. Разумеется, в конце нужно освободить WakeLock, тем самым разрешая телефону заснуть.
Спасибо за пояснения. Действительно, изображения из ресурсов скриптом рисуются на canvas, и ничего не мешает при этом брать только часть спрайта/группы изображений. Я только опасаюсь, что загрузка большого спрайта вместо маленькой одиночной картинки сильно скажется на производительности (приложение-то мобильное).
Это обычная карта, не игровая, поэтому предсказать направление движения будет сложно, поскольку карта должна двигаться по мановению руки пользователя.
Собственно, проблема с большими кусочками оттуда же: если пользователь подвинул карту на пару пикселей в сторону, в худшем случае начнут параллельно загружаться N маленьких 256×256 кусочков, и пользователь будет сразу видеть, как зарисовывается пробел => приложение выглядит отзывчивым и быстрым.
В случае больших 768×768 кусочков, их нужно будет всего N/3, и загружать их придётся реже, но каждый из них будет грузиться дольше. То есть, для пользователя приложение будет выглядеть быстрым, но при загрузке новых кусков карты будут заметные заикания, которых хотелось бы избежать.
1) Манифест присутствует, его создаёт SDK при сборке приложения. Иронично, что именно он и является корнем проблемы — при большом манифесте приложение невозможно подписать (а до введения подписывания, приложения с большим манифестом не запускались)
2) WebSQL поддерживается PlayBook'ом, но хотелось бы включать все ресурсы сразу в приложение, а не скачивать при первом запуске…
Масштабируемость была бы интересна, но заводить отдельный сервер под это дело не хочется. Гораздо проще один раз загрузить 150 МБ пакет в магазин приложений, чем отдавать такой же объём со своего хостинга каждому пользователю…
Спасибо за набор ключевых слов, но развёрнутая мысль была бы полезнее.
Base64 — просто формат хранения, какое отношение он имеет к вопросу?
Спрайты — приложение не использует CSS для работы с ресурсами (а даже если бы и — то CSS бы получился многомегабайтным). Или Вы не CSS-спрайты имеете в виду?
Архивы — фигурируют в решениях 1 и 3, там же описаны их недостатки.
Картинки — отрендеренные кусочки карты. 20 тыс картинок — это небольшой город при разных масштабах, нарезанный на кусочки 256×256.
Можно, конечно, увеличить размер до 512×512; количество файлов уменьшится в четыре раза, — но всё равно будет очень близко к пределу. Чуть покрупнее карта — и всё.
Если увеличить размер ещё — планшет будет жонглировать полудюжиной картинок 768×768 и приложение станет заметно задумчивее.
А это обидно, учитывая, что проблема, в общем-то, искусственная…
