AL> А чего неудобного в этом деле?

Не в хранилище данных дело. Проблема в изменчивости позиции внутри эхи. В карбонке, например, хранится одинаковое количество сообщений. Когда ты туда заходишь, клиент просто берёт последние N сообщений, у которых получатель стоит на твоё имя. Как здесь запоминать позицию? Единственным вариантом вижу здесь сохранять последний просмотренный msgid и при каждом входе в карбонку искать его последнее вхождение, дабы вычислить индекс.

Ещё есть избранные. У них в базе идёт сортировка в строго определённом порядке. Порядок зависит от того, как давно зафетчили сообщение. Так что если ты клацнешь на звёздочку, то позиция может съехать.

AL> А зачем поверх скиска сообщений запускать слайдер? Я слабо себе представляю разработку под андроид. Это особенности местного UI-строения*

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

Когда ты жмёшь на эху, открывается активити EchoView, в которую передаются параметры (эха: такая-то, станция: такая-то). EchoView запрашивает содержимое эхи и представляет это в виде списка на экране. Когда ты запускаешь слайдер, то в него передаются параметры (список сообщений: [массив msgid], позиция: число). Слайдер ничего не знает о эхе, он воспринимает только массив msgid, поэтому с его помощью можно делать разные фильтры (например, на непрочитанные сообщения и для работы ii-ссылок).

Всё это выглядит как-то так:

MainActivity (станция), низ стека
EchoView (станция, эха)
MessageSlideActivity (станция, список msgid, позиция), вершина стека

Если я помещу обработку позиции в главный экран (фрагмент списка эх), то возникнет путаница и каша в исходниках.
Доверять слайдеру это дело тоже нельзя, потому что надо будет писать собственные случаи для непрочитанных, ii-ссылок и прочего, что сделает кучу геморроя.
Менять экраны в стеке местами нельзя.

ООП весь в своей красе. Компоненты полностью независимы, так что приходится выкручиваться как-то.