Android placeholder что это

Android placeholder что это

Полный текст статьи и исходники программы доступны только зарегистрированным участникам сайта.

Прочитайте внимательно условия! В начале каждой статьи указывается, к какому курсу относится данная статья. Например, если статья из 4 курса, значит нужно заплатить за все курсы по четвёртый включительно.

Стоимость регистрации — символические 350 рублей. После регистрации у вас будет доступ ко второму курсу.

Для регистрации сначала необходимо пополнить ЮMoney(бывший Яндекс.Кошелек) 410011383280263 на указанную сумму (или Webmoney-кошелек P894989790291 (старый R390884954122) или QIWI (перевод по никнейму), а затем прислать письмо на адрес alexander.klimoff@gmail.com с указанием, на какой кошелёк вы делали оплату и реквизиты, по которым можно вас определить (не прикрепляйте к письму картинки или файлы). Учитывайте комиссию при переводах.

Не присылайте в письме мои номера кошельков — поверьте, я их знаю и без вас.

В ответном письме вы получите учётные данные для чтения статей из закрытой зоны за второй курс.

Доступ к третьему курсу обучения доступен только после оплаты второго курса и составляет 350 руб.

Доступ к четвёртому курсу обучения доступен после оплаты третьего курса и составляет 350 руб. и т.д.

При оплате сразу всех курсов одновременно (2-9) цена составит 2800 руб.

Доступ даётся как минимум на один год. Для тех, кто оплатил третий и другие курсы, сроки доступа увеличиваются.

Также возможен приём на PayPal (только для зарубежных пользователей). Обратите внимание, что в этом случае стоимость одного курса составляет 7$.

Источник

Android placeholder что это

Glide allows users to specify three different placeholders that are used under different circumstances:

Placeholder

Placeholders are Drawables that are shown while a request is in progress. When a request completes successfully, the placeholder is replaced with the requested resource. If the requested resource is loaded from memory, the placeholder may never be shown. If the request fails and an error Drawable is not set, the placeholder will continue to be displayed. Similarly if the requested url/model is null and neither an error Drawable nor a fallback Drawable are set, the placeholder will also continue to be displayed.

Error

Error Drawables are shown when a request permanently fails. Error Drawables are also shown if the requested url/model is null and no fallback Drawable is set

Fallback

Fallback Drawables are shown when the requested url/model is null . The primary purpose of fallback Drawables is to allow users to indicate whether or not null is expected. For example, a null profile url may indicate that the user has not set a profile photo and that a default should be used. However, null may also indicate that meta-data is invalid or couldn’t be retrieved. By default Glide treats null urls/models as errors, so users who expect null should set a fallback Drawable.

Are placeholders loaded asynchronously?

No. Placeholders are loaded from Android resources on the main thread. We typically expect placeholders to be small and easily cacheable by the system resource cache.

Are Transformations applied to placeholders?

No. Transformations are applied only to the requested resource, not to any placeholder.

It’s inefficient to include resources that have to be transformed at runtime in your application. You’re almost always better off including a version of the resource that’s exactly the size and shape that you need. If you’re loading circular images for example, you may want to include circular placeholder resources with your application. Alternatively you could also consider a custom View to clip your placeholder in the same manner as your Transformation.

Is it ok to use the same Drawable as a placeholder in multiple Views?

Usually, but not always. Any non-stateful Drawable (like BitmapDrawable) is typically ok to display in multiple views at once. Stateful Drawables however, are typically not safe to display in multiple views at the same time because multiple Views will mutate the state at once. For stateful Drawables, pass in a resource id, or use newDrawable() to pass in a new copy to each request.

Источник

Android String Placeholders

This article reviews different ways to create dynamic translatable strings in Android.

Quick reminder

In Android, message strings are extracted to XML files, and the system loads the resources corresponding to the current configuration.

Formatting strings

Let’s say we want to display a dynamic string, such as Player Foo — Score: 42.

We may be tempted to implement that quickly with String.format() .

You will get a compile time error message on the definition.

Error

Multiple substitutions specified in non-positional format; did you mean to add the formatted=»false» attribute?

This error message is misleading, because one may believe that using formatted=»false» is the way to go.

Although the error message now disappears, the real solution is to use a positional format.

When translating strings, the word order will change. For instance, Name: John Smith in English becomes Nom : Smith John in French.

Using positional format prevents translation mistakes.

getString()

Did you know that instead of String.format() , you can use an overloaded version of getString() that handles formatting?

Is that stricly equivalent to the previous code? Let’s look at the Android source!

Almost the same, except that we are using the resource configuration locale, whereas we were previously using the default locale.

Locale.getDefault() is usually equal to mConfiguration.locale , so this won’t really be a problem until you start messing with the default locale.

By the way, you probably know that getString() is also available on Context .

What’s the difference? None. It just delegates to Resources .

If someone knows the story behind this weird shortcut method, let me know. For now, I’ll just assume this is a consequence of Drunk Driven Development.

Professional Translation

Your users deserve better than Google translate. XML resource files should be translated by a professional translator.

This translator will know nothing about your app internals. Therefore, it may be really hard to find out what those %1$s cryptic signs mean.

You can use comments to help the translator.

By the way, if you need excellent quality software translation, I know someone that’s been translating software for more than 25 years. Yes, he is my father 🙂 .

Using placeholders

Another interesting approach is to use named placeholders instead of format specifiers.

I won’t discuss which syntax is better for this kind of problem, let’s just pick a simple one: .

I find this much more readable! Now, you’ll need an API to transform that format to the final string.

Implementing this API is fairly straightforward.

This is just an example implementation, I’ll leave a better one to you as an exercice. An interesting point here is that with() returns this , so you can use it as a fluid API.

Conclusion

I shamelessly stole this idea from Eric Burke, and thought it was worth sharing.

Of course, you may already use Java libraries that can do this. If you are aware of a good one that does a decent job, let me know!

Источник

Полное руководство по Splash Screen на Android

Перевод статьи Elvis Chidera «The (Complete) Android Splash Screen Guide». Но для начала немного истории о проблеме Splash Screen на Android.

Два вида Splash Screen

Google в гайдлайнах Material Design представляет две концепции Splash Screen (или Launch Screen):

1. Placeholder UI
2. Branded launch screen

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

Branded launch screen — собственно и есть то, что большинство разработчиков (по крайней мере Android-разработчиков), именуют Splash Screen. Это некоторый логотип, изображение, реже анимация, которые пользователь на короткое время видит во время старта приложения.

Теперь, прежде чем перейдем к переводу статьи Элвиса, которая рассказывает о Branded launch screen, немного о грустном в лагере поклонников Placeholder UI.

Placeholder не работает даже у приложений от Google

Не смотря на собственные гайдлайны, Google не смог реализовать подход Placeholder UI в собственных приложениях. Я навскидку выбрал три популярных приложения от Google, где по логике должен быть Placeholder UI, но он не работает. Показан переход от холодного старта к рабочему состоянию приложения:

Как видим, во время холодного старта загружается только фон приложения, панель инструментов и строка состояния — либо под цвет фона, либо случайного цвета (как в примере с Play Market).

Причины этому следующие:

1. Сегодня хорошим тоном считается использовать Toolbar , как часть макета панели инструментов. Это дает много плюшек: реакция на прокрутку, анимации и т.д. Но вместе с тем, необходимо использовать тему NoActionBar . Это влияет на то, что цвета главной темы приложения не подгружаются при холодном старте.
2. Проблема в библиотеке AppCompat. Даже если использовать обычный ActionBar для панели инструментов, мы будем наблюдать аналогичный эффект. Переход от @style/Theme.AppCompat.Light.DarkActionBar к @android:style/Theme.Material.Light.DarkActionBar лечит эту проблему, но, вероятно, приложения все еще рассчитаны на поддержку версий до Lollipop.

О подходе Placeholder UI все. Переходим к переводу статьи Элвиса.

Как работать с Branded launch screen

В прошлом в Android не рекомендовалось делать Splash Screen в приложениях. Не было смысла заставлять пользователя ждать n секунд, чтобы показать заставку. И несомненно, что никто не запускает приложение ради заставки (об этом ниже).

Предоставление пользователю контента должно быть вашим приоритетом №1

Когда в Material Design появился раздел под названием Launch Screen (Splash Screen), кто-то из команды Android опубликовал пост о том, как сделать Splash Screen правильно.

В этом посте я рассмотрю четыре основных способа реализации Splash Screen на Android:

1. Используя Launcher Theme (Хорошо)
2. Используя Launcher Theme с предопределенной для Splash Screen Activity (Сойдет)
3. Используя таймеры (Timers) (Плохо)
4. Используя умные таймеры (Smart Timers) (Ужасно)

Используя Launcher Theme

Когда ваше приложение запускается и оно еще не в памяти, может иметь место задержка между тем, когда пользователь нажал на запуск, и тем, когда у Activity вызвано onCreate() . Этот, так называемый «холодный старт» — лучшее время, чтобы показать ваш Splash Screen.

Во время «холодного старта» оконный менеджер пытается отрисовать placeholder UI, используя элементы из темы приложения (app theme), такие как windowBackground . И то, что показывает windowBackground по-умолчанию (обычно белый или черный фон), вы можете поменять на какой угодно drawable, создав тем самым свой Splash Screen. Этот способ показывает Splash Screen только там, где необходимо, и не замедляет пользователя.

Итак, вам необходимо создать кастомную тему, переопределив android:windowBackground , заменив использование стандартной темы на вашу перед вызовом super.onCreate в вашей Activity.

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

Вы должны создать новую тему AppTheme.Launcher . Единственный элемент, который необходимо переопределить — это windowBackground . В файл styles.xml добавим:

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

Определяем drawable launch_screen . Хотя вы могли бы использовать простую картинку, но она будет растянута на весь экран. Вместо этого используем XML-файл:

Пропишите тему для Splash Screen в файле манифеста в вашей стартовой Activity:

Теперь нужно вернуть главную тему в стартовую Activity (если, конечно, мы не хотим, чтобы Splash Screen радовал нас и во время работы приложения)
Самый простой способ сделать это — это вызвать setTheme(R.style.AppTheme) до super.onCreate() и setContentView() :

Все. Вы можете узнать подробнее об этом подходе здесь.

Плюсы:

1. Нет никакой специальной Activity для Splash Screen. Нет задержки времени как в том случае, если бы вы вызывали рабочую Activity из Activity для Splash Screen.
2. Нет искусственных задержек — Splash Screen показывается только тогда, когда приложение загружается.

Минусы:

Я встречал три довольно распространенные жалобы на этот подход:

1. Splash Screen показывается снова если Activity была убита системой и снова восстановлена. В большинстве случаев, этот совсем не проблема, но при желании, если использовать второй способ, этого можно избежать.
2. Некоторым разработчикам необходимо, чтобы после запуска Splash Screen, пользователь попадал на разные Activity, в зависимости от каких-либо параметров. Опять же, для таких задач можно использовать второй способ, но иногда реализация такой промежуточной Activity довольно неряшлива.
3. Невозможно загрузить тяжелые данные/компоненты, когда показывается Splash Screen. Хотя это плохая идея: загружать тяжелые данные или компоненты, пока стартует приложение (есть некоторые исключения, как, например, инициализация некоторых библиотек). Можно попробовать один из следующих подходов.
   • Постарайтесь использовать метод ленивой загрузки, для своих компонентов/модулей/библиотек. За исключением компонентов, которые кровно необходимы для работы приложения, старайтесь ничего не загружать во время запуска приложения, а загружать, когда вам понадобится компонент, или грузите в фоновом потоке сразу после старта приложения. Сохраняйте onCreate() вашего приложения легким насколько это возможно.
   • Используйте кэширование. За исключением той информации, которая быстро меняется, остальное лучше кэшировать. Когда пользователь снова обращается к вашему приложению, вы можете показать закэшированный контент, пока более свежий контент загружается.

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

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

Splash Screen в отдельной Activity c использованием Launcher Theme

Этот способ базируется на первом способе. Он требует отдельной Activity для Splash Screen. Первые два шага пропускаем, они аналогичны первому способу.

Осталось создать Activity для Splash Screen и указать в манифесте для нее тему AppTheme.Launcher . Теперь отредактируем Activity так, чтобы она перенаправляла на другие страницы. Смотрим пример ниже:

Плюсы:

1. Решает первые две проблемы у первого способа.

Минусы:

1. Я видел, как подобная маршрутизация легко становится уродливой.
2. Небольшая задержка между двумя Activity.
3. Опасность забыть и начать делать длительные операции здесь.

Используя таймеры

Это старый добрый подход. Надо просто создать отдельную для Splash Screen Activity, которая будет показываться x секунд. Затем открыть подходящую Activity. Используя такой подход, вы получаете больше гибкости, потому что можете добавить анимацию, кастомные view или любые другие элементы, которые вы можете поместить в макет Activity. Вот минимальная реализация такого подхода:

Плюсы:

1. Появляется возможность показать вашу супер-анимацию, или любой другой кастомный дизайн, который вы хотите. Это имеет смысл для игровых приложений или приложений для детей.
2. Большая гибкость того, что вы можете показать на Splash Screen.

Минусы:

1. Двойной удар — ваша Activity не стартовая Activity не появляется немедленно, после того, как приложение запущено, особенно во время холодного старта. Пользователь ждет во время холодного старта, наблюдая только windowBackground и, затем, просматривая еще Splash Screen до того, как запустится рабочая Activity.
2. Ваша супер-анимация или дизайн обычно восхищает пользователя только первые пару раз. Потом, большинство пользователей находит его скучным, и они хотят получить только контент. Я думаю, что четвертый способ способен исправить это.
3. В большинстве случаев дополнительная задержка неоправданна.

Используя умные таймеры.

Этот подход базируется на третьем способе. Но вместо постоянной задержки, вы запускаете Splash Screen или нет, основываясь на том, первый это запуск или нет. Вот пример, который использует SharedPreferences :

Плюсы:

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

Минусы:

1. Двойной удар — проблемы третьего способа все еще не здесь
2. В большинстве случаев дополнительная задержка неоправданна.
3. Я не использовал этот метод, но, думаю, может быть некоторая задержка при чтении из SharedPreferences .

Это все о Splash Screen. Если я что-то упустил, напишите в комментариях.

Следует заметить, что на Хабре уже была статья (перевод), где речь шла о Splash Screen. Однако затронутый там подход (соответствует второму способу в этой статье), как мы могли убедиться, не самый оптимальный для большинства случаев. Ну и последнее, в Android Oreo якобы добавлено Splash Screen API, что позволит разработчикам легко добавлять Splash Screen в свои приложения, но на данный момент в официальной документации по этому поводу никакой информации нет.

Источник