LinearLayout в два прохода распределяет пространство. Сначала все контролы опрашиваются на тему сколько им требуется, а затем среди контролов, которые помечены weight разпределяется оставшееся. Соответственно ListView забирает себе максимально, сколько можно при первом проходе. Если ему ставим 0dp, то при первом проходе он исключается из претендентов на пространство и оставшееся (в нашам случае от размещения ImageView) ему отдается при втором проходе.
Т.е. Вы хотите работать по HTTPS? А если сертификат сгенерировать самостоятельно и в приложении самостоятельно обработать проверку сертификата? У нас вроде нормально этот вариант работает.
Как именно предстоит работать с изображениями? Если ложить в папку res, то автоматически будет изображение подстраиваться по экран устройства. Если это какие-то картинки с большим разрешением, то лучше сложить в assets и самостоятельно обрабатывать их. Расскажите подробнее о проекте, тогда решение более подходящее проще подобрать будет.
У меня в каталоге /extras/android/support/v7/ лежит gridlayout. Насколько я понимаю, совместимость до SDK 7 (2.1). Правда на stackoverflow пишут про некоторые «особенности» этого варианта. Я использую вот отсюда github.com/dlew/android-gridlayout.
Насколько я понял, среди данных есть и списки. Обратите внимание на наследование от SherlockListFragment. Достаточно сделать лейауты с нужными ID и количество кода значительно сократится — основные моменты (как раз с показом или скрытием списка) уже сделаны. Лоадеры лучше делать от AsyncTaskLoader. Хотя опять же, если бы задача подробнее была описана… Вполне вероятно, что само получение данных лучше сделать через SyncAdapter, сложить в базу, а отображать уже из базы — приложением можно будет пользоваться и из оффлайна.
Точно сказать трудно, но по описанию задачи, когда очень много пересекающего кода похоже, что данные на разных активити одного уровня. Рассортировав их по фрагментам будет удобно изолировать парсинг и отображение каждого набора данных, и при этом отобразить все в приятной форме с современными наворотами интерфейса — взять ActionbarSherlock, ViewPager. С фрагментами значительно проще быстро переделывать интерфейс под «хотелки» бизнеса. Да поддержка различных устройств (телефоны, планшеты) проще делается — иногда достаточно разные лейауты сгенерить в ресурсах.
Сервис будет «висеть» в памяти, если он запущен и не будут вызваны методы stopSelf или stopService. Все же варианты, когда сервис будет остановлен остаются, например принудительно пользователем. Так что это лучше не использовать. Не предназначены сервисы для хранения данных. Лучше все же подумать над архитектурой.
Возможен запуск сервиса в режиме, когда он будет постоянно находиться в памяти. Однако еще раз повторюсь — пользователи не оценят. Может попробовать сделать объекты сериализируемыми? И возможно пересмотреть структуру приложения, уж очень сложно представить нужность хранения контекста — данные лучше отделять от представления.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
