WildЗнакомый советует данные из курсора маппером преобразовывать например в массив, тогда вью станет более универсальным
все зависит от того, надо ли тебе подобные усложнения. кроме того, что есть универсальный вью? вьюха это xml файл с гуем - он по определению универсален в силу того, что в андроиде нет байндинга. т.е. один и тот же вью ты можешь заюзать в куче мест и всунуть внутрь других вью. не универсален именно процесс ручного байндинга на данные.

WildХотелось только лишь, чтобы скажем ListActivity не был завязан на конкретный тип источника данных
если тебе действительно это нужно, то да - конвертируй данные из источника в Collection<User>

Wild1. Есть некая вью...При установке значения в поле - оно отражается на экране (в соотв. текстовом редакторе)
при редактировании значения на экране - значение меняется в соотв. поле
это как раз тот датабайндинг, которого в гениальном андроиде нет (почти). по факту тебе будет нужно
1) найти все контролы по их id
2) установить их значения в исходные
3) при валидации и/или перед сохранением записать текущие значения обратно в доменный объект


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

Но в целом да, оперировать бизнес-объектами удобней, чем курсором.

TrogloditЕсли посмотреть в сторону ContentPrivider, то возможности, которые предоставляет данная технология,в определенных случаях
contentprovider это средства обмена данными между процессами. любимые инженеры гугл нерусским языком пишут

авторYou don't need to develop your own provider if you don't intend to share your data with other applications....
You also need your own provider if you want to copy and paste complex data or files from your application to other applications


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


Troglodit превосходит объектный подход, а в некоторых единственный (например любое приложение может оперировать контактами из девайса, а возможность получать уведомления об изменении записей в БД это вообще уберфича).
это совсем другая область применения, кэп

TrogloditПовторюсь еще раз Андроид-это отличная архитектура
не надо лозунгов. архитектура как архитектура, со своими тараканами, коих приличное количество.

Troglodit, которой просто надо следовать, и тогда вы получите гибкость
давайте плодить говнокод на тот случай если внезапно нам понадобится гибкость




Trogloditминимальные ресурсы на затраты.
это фразу вообще не смог осмыслить

TrogloditДело не только в разных приложениях, у вас может быть несколько потоков, фрагментов и пр., не связанных друг с другом, при этом отлично взаимодействующими.
внутри одного приложения eсть куча самых разных способов обеспечить взаимодействие без контентпровайдеров. например roboguice events. то что оно там будет на какие-то микросекунды медленней - плевать, зато код в разы лаконичней и проще.

Trogloditприведенный вами ниже код как раз отлично заменяется объектами, гибкость которых зависит от задачи.
так ото ж

Trogloditздесь же на форуме, если поискать, народ использует ORM фреймворки, удивляюсь как это хибер еще не затащили на Андроид и прочие навороты, а потом удивляются как все тормозит
все тормозит, потому что все тормозит, а не только потому что это мы все такие криворукие. создатели андроида очень сильно спешили в свое время, почитай интервью той же Dianne Hackborn. и да, необходимость все делать руками и писать уродливые конкатенированные запросы к sqlite удручает. потому народу хочется байндинга, ioc-ов, и хоть какой-никакой activerecord, уже не говоря про орм.


Troglodit разработчики тоже считали, что рекомендации гугла по дизайну-это чушь слоновья.
рекомендации гугла сам гугл уже неоднократно менял. особенно переход от 2.3 к 3/4 стал особо радикальным. и чем дальше, тем веселее. все больше и больше deprecated то тут, то там. так что создается впечатление, что они сами нихера не определятся, как дальше быть. ты например в курсе, что поведение AsyncTask менялось трижды!!! Сначала они запускались строго последовательно (Thread Pool = 1) , потом (начиная с андроид 1.6) параллельно, затем в Honeycomb снова последовательно.
так что не надо делать ошибку, полагая, что там сидят некие небожители, точно знающие окончательную ИСТИНУ - любое "рекоммендуемое" средство нужно трезво оценить

TrogloditЯ говорил о 4 -й версии, которую имхо можно назвать полноценной
она стала более дружелюбной к пользователю. с точки зрения программиста (в целом) только добавилось геморроя

Troglodit, то что было раньше-это как мрачное средневековье, оно было и о нем лучше не вспоминать.
как-то трудно не вспоминать о том, что по состоянию на 4 марта 43% смартфонов имеют версию 2.3 и, что характерно, большинство из них ничего более нового никогда не получат.

TrogloditДело не в том, насколько удобен продукт для программиста
этот вопрос все же имеет академический интерес. Если продукт сделан через жопу, или частично через жопу, следует это признать.

Trogloditнужно следовать советам разработчиков (даже если они и меняются)
если под советами разработчиков подразумевать примерчики из апи, то нет - не стоит следовать им слепо.


Troglodit. И кстати, в конкатенации sql нет ничего адского, иногда это сильно облегчает жизнь, когда sqlite оптимизатор начинает тупить
не ясно, какая связь между конкатенацией sql и тупежом оптимизатора. это совершенно перпендикулярные вещи.

TrogloditНасчет биндингов и прочего, я не знаю уровень ваших задач, но в небольших и средних задачах проще написать велосипед
велосипед редко проще, чем решение "искаропки".

Troglodit, либо сделать, о ужас, все руками.
ну да, терпению и труд все перетрут.