Элемент управления ListView был представлен в .Net Framework 3.5 как замена устаревшему GridView. Новый элемент имеет более расширенный функционал, чем его предшественник, но в тоже время лишен некоторых внутренних механизмов, что впрочем целиком следствие из расширенной универсальности ListView. Среди отличий ListView и GridView можно назвать и гибкую настройку разметки, что позволяет выводить данные не только в табличном виде, но и вообще в любом каком пожелает программист. Благодаря шаблонам ItemTemplate, EditItemTemplate, InsertItemTeplate можно настроить внешний вид при любом из состояний ListView: редактировании или выборе элемента.

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

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

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

Задача:

Реализовать механизм загрузки изображений из Интернета и отображения их в списке. При этом загрузка изображений должна быть реализована в отдельном потоке, во избежания «зависания» UI приложения.

Реализация:

Для реализации поставленной задачи использованы стандартный виджет ListView и адаптер — ArrayAdapter. Для работы с изображениями создан helper-класс ImageManager, который имеет два метода downloadImage() и fetchImage(). Первый загружает изображений из Интернета. Второй — вызывает загрузку изображений в отдельном потоке и устанавливает результат в ImageView.

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

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

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

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

Проблема

Стандартный механизм отображения списков из базы данных в Android выглядит примерно так:

• Activity содержит ListView
• ListView обращается к экземпляру CursorAdapter
• CursorAdapter получает данные из объекта, реализующего интерфейс Cursor
• Cursor получен либо из ContentProvider, либо сразу из SQLiteDatabase

Всё работает нормально ровно да тех пор, пока количество строк в Cursor сравнительно небольшое. Но если в нём 50 тысяч, 100 тысяч и более строк (хотя дело не только в количестве строк, но об этом чуть позже), время от времени список будет притормаживать. Особенно это заметно при «быстрой прокрутке», если у ListView установлено в true свойство fastScrollEnabled.

Доброго дня суток, хабражители.

Сегодня я хочу поделиться с вами секретами анимации элементов списка ListView в Android.

Предисловие

Однажды понадобилось мне выводить в одном ListView карточки разных типов, да еще и полученные с сервера по разным API. Мол, пусть пользователь порадуется и в одной ленте новостей увидит:

• карточки видео, с тамнейлами и описаниями;
• карточки авторов или тегов, с большой кнопкой «подписаться».

Очевидно, что мастерить один большой layout, в котором учитывать все мыслимые варианты карточек — плохо, да и расширяться это будет так себе.



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



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

Всем привет!

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

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

Мы рады представить вам превью-версию Windows-библиотеки для JavaScript 4.0 (WinJS 4.0). В нашем предыдущем релизе (WinJS 3.0) мы фокусировались на том, чтобы обеспечить кросс-браузерную совместимость. С WinJS 4.0 мы начали добавлять новые возможности, чтобы библиотека продолжала быть хорошим фреймворком для разработки как Windows-приложений, так и приложений для веба.



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

• Универсальный опыт взаимодействия – люди хотят, чтобы их приложения работали там же, где и они: на телефонах, планшетах, компьютерах и даже на телевизоре в комнате. Форм-фактор устройств постоянно развивается, чтобы лучше соответствовать потребностям человека: где-то это клавиатура, подключаемая к планшету, с тем, чтобы сделать работу более продуктивной, где-то это подключение телефона к телевизору, чтобы можно было откинуться назад на диване и исследовать контент, и так далее. Элементы управления WinJS облегчают создание отзывчивых приложений, которые не только могут работать на экранах разного размера, но и учитывать разные способы ввода. Мы хотим помочь вам заточить опыт взаимодействия под каждое устройство и форм-фактор, так чтобы вы могли сфокусироваться на создании самих приложений.
• Отличное взаимодействие с другими – WinJS спроектирован с прицелом на совместимость. Мы верим, что у вас должна быть возможность легко использовать вместе WinJS и ваши любимые фреймфорки на JS. Например, WinJS-обертка для AngularJS позволит вам прозрачно использовать WinJS в ваших проектах на AngularJS.
• Мощный ListView – WinJS должен поддерживать вашу разработку приложений, предоставляя лучшие элементы управления. Наша реализация ListView была существенно оптимизирована с точки зрения производительности и поддерживает широкий спектр сценариев. Мы добавили новые возможности, например, поддержку чередования стилей, заголовки и подвалы для списков и улучшенное выделение элементов.

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

Вы можете начать использовать превью WinJS 4.0 сегодня через ваш любимый пакетный менеджер (Bower, npm или NuGet), ссылку на CDN, скачав Zip-архив с нашего сайта или клонировав репозитарий для сборки собственной копии на GitHub.

Далее в статье мы расскажем подробнее об фокусных областях, названных выше. Надеемся, вам тоже понравятся новые возможности WinJS 4.0.

Весной 2015 года в рамках Google Admob был анонсирован новый для них способ отображения рекламных блоков, а именно Native ads (далее нативная реклама), который на текущий момент действует в режиме бета-релиза. Плюс нативной рекламы – это высокая адаптивность к дизайну приложения, которая позволяет показать рекламу таким образом, чтобы она не бросалась в глаза и не мешала работе с приложением. В статье будут отмечены определенные моменты, которые возникли в процессе интеграции Admob Native Ads в собственное приложение (пример того, что получилось показан на картинке, названия удалены), а также приведен практический пример с фрагментами кода (полный вариант при желании можно загрузить и посмотреть тут.

С 2015 года ситуация с Admob Native ads практически не изменилась, нативная реклама по прежнему находится в бета-релизе, с лимитированным доступом для издателей. В официальных доках появились новая редакция и некоторые разъяснения по поводу того, каким образом планируется эти самые Native ads внедрять. Мы, в свою очередь, также не сидели сложа руки, копили материал для очередной статьи, и, как только появилось свободное время, слегка расширили функционал библиотеки admobadapter . А именно, реализовали в ней поддержку прокручиваемой нативной рекламы для RecyclerView, так же как мы делали это в прошлой статье для ListView.

Недавно у меня возникла идея собрать все базовые наиболее часто используемые фичи для ListView в Android и для удобства объединить их в один проект. Как обычно, я отправился в интернет и нашел там замечательную статью и ее переводы на хабре (перевод 1, перевод 2). Не все, на мой взгляд, было нужным и полезным в этой статье, поэтому я включил в конечный проект только то, что мне показалось значимым. Надеюсь, в будущем это пригодится кому-то еще.

Повторное использование ранее размещенных в памяти строк, которые при прокрутке выходят за пределы экрана, ― широко распространенная техника оптимизации использования компонента ListView, изначально реализованная в iOS и Android. Реализация ListView как компонента React Native по умолчанию не содержит непосредственно эту оптимизацию, но имеет ряд других приятных преимуществ. Тем не менее, это отличный образец, достойный изучения. Рассмотрение этой реализации в рамках изучения React также будет интересным мысленным экспериментом.

Списки являются важной частью разработки мобильных приложений

Списки – это сердце и душа мобильных приложений. Множество приложений отображают списки: это и список публикаций в вашей ленте приложения Facebook, и списки бесед в Messenger, и список сообщений электронной почты Gmail, и список фотографий в Instagram, и список твитов в Twitter и т.д.

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

С одной стороны, вы хотите сохранить скорость работы вашего приложения, т.к. прокручивание со скоростью 60 FPS стало золотым стандартом нативного опыта взаимодействия (UX). С другой стороны, вы хотите сохранить низкое потребление памяти, потому что мобильные устройства не располагают избыточными ресурсами. Не всегда просто выполнить оба эти условия.

Поиск идеальной реализации элемента ListView

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

Предыстория

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

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

Как осуществить экспорт данных?

Как видно из скриншота, в элементе меню «Файл» уже все заготовлено для Экспорта и Импорта нашей телефонной книги, осталось написать сам код.

При написании данной программы, у меня еще не было практического опыта работы с XML-файлами на языке С# под платформой .NET. Поэтому я стал искать материал на просторах интернета. Но все мои результаты поисков были не утешительные. Все найденные результаты давали очень грубый и «макаронный» код, который можно адаптировать под свои нужды. Однако, это все же не практично. Такой код не возможно легко использовать в разных проектах.

После чего я решил углубиться в саму особенность работы с XML-файлами на языке C#.

Кому-то материал этой статьи покажется слишком простым, кому-то бесполезным, но я уверен, что новичкам в Qt и QML, которые впервые сталкиваются с необходимостью создания моделей для ListView, это будет полезно как минимум как альтернативное*, быстрое и довольно эффективное решение с точки зрения "цена/качество".

*Как минимум, в свое время ничего подобного мне нагуглить не получилось. Если знаете и можете дополнить — welcome.

О чем шум?

С приходом в Qt языка QML создавать пользовательские интерфейсы стало проще и быстрее… пока не требуется тесное взаимодействие с C++ кодом. Создание экспортируемых C++ классов достаточно хорошо описано в документации и до тех пор пока вы работаете с простыми структурами все действительно достаточно тривиально (ну почти). Основная неприятность появляется, когда нужно "показать" в QML элементы какого-то контейнера, а по-простому — коллекции, и в особенности, когда эти элементы имеют сложную структуру вложенных объектов, а то и другие коллекции.

Интересно?