Google Android - это несложно

Всем привет! Значит, что есть в программе: база данных связанна с ListView, привязал к пунктам ListView контекстное меню, в котором есть пункт "Редактировать запись". При нажатии на этот пункт открывается EditActvity, где мы что то редактируем жмем "окей" и возвращаемся на главную Activity (метод startActivityForResult). EditActvity вызывается в методе SelectItemId (отвечает за то, какой пункт контекстного меню нажат), а возвращаемся c данными мы в метод onActivityResult. Но тут возник вопрос как передать ID нажатого item ListView в метод onActivityResult (чтобы далее присвоить ему отредактированные данные). Я сделал это через публичную переменную, все работает, но правильно ли это с точки зрения ООП? (Имею ввиду может можно как эти два метода "подружить" через интерфейс или класс). Заранее извиняюсь за запутанное объяснение, только начинаю разбираться и ООП слабое место(.

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

в метод startActivityForResult передается интент, в который можно положить всё что угодно (ну или почти всё). Далее в onActivityResult берём интент (data) и оттуда вытаскиваем, то что туда положили.
Урок же есть: http://startandroid.ru/ru/uroki/vse-uro ... resultcode
ну и да в случае с бд скорее всего нужно делать, как написано выше.

Пардоньте ребята, урок я понял хорошо, возможно плохо объяснил проблему, вот фрагмент кода главной активити И вот у меня не получается передать переменную acmi1 = (AdapterContextMenuInfo) item в метод onActivityResult. Подскажите пожалуйста как мне это можно сделать, остальное мне вроде понятно.

у вас путаница в коде. Не ясно мне - зачем передавать такое?
и во вторых, в большинстве случаев это getSupportLoaderManager().getLoader(0).forceLoad(); лишнее. LoaderManager может сам следить за обновлением курсора.

Foenix писал(а): "Возвращаться с данными" из активити не нужно, нужно записывать изменения в базу данных, а потом закрывать редактирующую активити.

А почему? startActivityForResult - плохо работает?
За использование SQLite нужно платить тратой ресурсов и на самам деле не так много случаев, когда база действительно нужна... есть json, обычный file, xml, shared preference и т.д.

Подскажите пожалуйста как мне это можно сделать, остальное мне вроде понятно.

объявите ее как private в классе Activity(не в методе, т.е. в самом верху ), добавьте методы setAcmi1 и getAcme1, все. Когда устанавливаете значение вызываете set*, когда хотите взять -get*.

P.S. вообще я тут согласен с Инной, че то вы там совсем нагородили... заканчивайте уже и начинайте новые проект... Попробуйте к этому через 2 недели потом вернуться и понять

А почему? startActivityForResult - плохо работает?
За использование SQLite нужно платить тратой ресурсов и на самам деле не так много случаев, когда база действительно нужна... есть json, обычный file, xml, shared preference и т.д.

во-первых, насколько я поняла из описания и кода - автор УЖЕ использует бд
во-вторых, зачем передавать данные в активити, а ПОТОМ записывать их в таблицу если это можно сделать сразу? Вообще говоря - так принято делать - в андроиде все записывается именно в момент нажатия на кнопку "назад"
а в-третьих - мне так надоело объясняться.. делайте, что хотите.. храните где хотите данные, хоть на луне, передавайте их куда заблагорассудится.. что-то я устала

Foenix писал(а):

А почему? startActivityForResult - плохо работает?
За использование SQLite нужно платить тратой ресурсов и на самам деле не так много случаев, когда база действительно нужна... есть json, обычный file, xml, shared preference и т.д.

во-первых, насколько я поняла из описания и кода - автор УЖЕ использует бд
во-вторых, зачем передавать данные в активити, а ПОТОМ записывать их в таблицу если это можно сделать сразу? Вообще говоря - так принято делать - в андроиде все записывается именно в момент нажатия на кнопку "назад"
а в-третьих - мне так надоело объясняться.. делайте, что хотите.. храните где хотите данные, хоть на луне, передавайте их куда заблагорассудится.. что-то я устала

Большое спасибо за объяснения, а также приношу извинения за то, что имел наглость утомить Вас)). По поводу использования БД. Предполагается по мере моего продвижения, вынести БД на сервер, а пока я просто учусь взаимодействовать с это самой БД (насколько это обоснованно? жажду услышать)). По поводу "если это можно сделать сразу", я правильно понял я открываю EditActivity там вношу изменения в БД, а потом уже возвращаюсь с отредактированной базой и соотвественно ListView? Если так, то большое спасибо, я что-то не догадался(.

volboy писал(а):Большое спасибо за объяснения, а также приношу извинения за то, что имел наглость утомить Вас)). По поводу использования БД. Предполагается по мере моего продвижения, вынести БД на сервер, а пока я просто учусь взаимодействовать с это самой БД (насколько это обоснованно? жажду услышать)). По поводу "если это можно сделать сразу", я правильно понял я открываю EditActivity там вношу изменения в БД, а потом уже возвращаюсь с отредактированной базой и соотвественно ListView? Если так, то большое спасибо, я что-то не догадался(.

не принимайте на свой счет, я прошу прощения
да, при закрытии нужно сразу менять данные в таблицах и когда вы вернетесь на предыдущую активити, в том случае,е сли вы использовали контент-провайдер и курсор-лоадер, то измнения в листвью сами отобразятся.
Обоснованность использования бд в приложении - это вопрос архитектуры приложения, так в общем нельзя сказать определенно. Однако, я лично могу признать только три способа хранения данных - файл, преференсес и бд (уроки есть, вебинары есть). Все остальные тут названные xml, json - От лукавого. Спорить об этом не хочу (это я не вам).

и про "трату ресурсов" при использовании sqlite не верьте. Отличный, быстрый и понятный способ хранения данных. Тут вопрос - цели и удобства хранения. Где удобно, с какой целью определитесь - там и храните. Файл - это неструктурированное хранение, преференсы - структурированное, но данные скажем там единичног характера, сохранить что-то между запусками приложения, похож на ini файл в виндах, а таблицы - структурированное, быстрый и понятный доступ.

Foenix писал(а):и про "трату ресурсов" при использовании sqlite не верьте. Отличный, быстрый и понятный способ хранения данных. Тут вопрос - цели и удобства хранения. Где удобно, с какой целью определитесь - там и храните. Файл - это неструктурированное хранение, преференсы - структурированное, но данные скажем там единичног характера, сохранить что-то между запусками приложения, похож на ini файл в виндах, а таблицы - структурированное, быстрый и понятный доступ.

Не верьте? вообще то это факт.
Я бы советовал почитать вот это: http://docs.blackberry.com/en/developer ... 781_11.jsp
Работа с базой тем более с sqlite3 -это ресурсы и значительно большие чем с xml, в Android ресурсы ограниченны.
В частности:

Most of the processing time of SQLite databases is taken up by reading and writing to storage. Less data generally means fewer reads and writes. The SQLite database engine caches frequently accessed database pages. By storing less data, you can increase the probability that the SQLite database engine retrieves requested data more quickly from the cache instead of from the relatively slow storage access.

Foenix писал(а):. Однако, я лично могу признать только три способа хранения данных - файл, преференсес и бд (уроки есть, вебинары есть). Все остальные тут названные xml, json - От лукавого. Спорить об этом не хочу (это я не вам).

Это в смысле? xml и json структурированное хранилище и зачем мне создавать 10 файлов с одной строкой, если я могу создать один? Не важно что и кто может или нет признать, есть назначение, как раз обычый файл наименнее рекомендуемая структура. xml и json -это тот же преференс но с более гибкой структурой.

Foenix писал(а):таблицы - структурированное, быстрый и понятный доступ.

это сегодня день такой? Таблицу реляционной базы данных очень не правильно использовать с целью структурированного хранилища. Как минимум потому, что это не дает никаких преимуществ по сравнению с xml, который от этой таблицы отличается отсутсвием необходимости поддерживать соединие и все. Sqlite3 -это много таблиц связанных отношениями. В остальных случаях есть средства мониторинга работы приложения в Android, чтобы наглядно убедится на сколько это не эффективно поддерживать соединение с бд в которой одна таблица, еще и открывать/закрывать ее при каждой записи.

P.S. Похоже у кого -то фанатизм в исопльзовании бд... на самом деле - это просто стиль программирования, но не нужно говорить, что в этом есть что -то хорошее... конечно в обычном приложении те затраты не существенны, но, я опять приведу в пример преферанс - играть нужно не для победы, а правильно! И если потери не большие - это не повод закрывать глаза на них. Когда объем данных выростет очень важна оптимизация и разделение, тем более в ограниченном мире Sqlite3...

Артем, я уже говорила, что не провожу исследований на манер что будет быстрее в моей программа на 1 миллионную секунды. Мне достаточно вот этого
http://stackoverflow.com/questions/5213 ... 69#5213569

И ты сам посуди , то ты говоришь об 1 табличке, то о растущем объеме данных..

и если ты покажешь, где гугл говорит, чтоб юзать xml вместо sqlite.. я пожалуй, почитаю ссылку)

кто автор рекламируемой тобой статьи? какое имеет отношение BlackBerry Java SDK - 6.0 к системе андроид? какого года эта статья?

Foenix писал(а):Артем, я уже говорила, что не провожу исследований на манер что будет быстрее в моей программа на 1 миллионную секунды. Мне достаточно вот этого
http://stackoverflow.com/questions/5213 ... 69#5213569

И ты сам посуди , то ты говоришь об 1 табличке, то о растущем объеме данных..

Во первых я не отказывался от использования базы, а выступал против фанатизма... ну да - почитал:

It will be easier to:
Retrieve data
Filter data
Sort data

Правильно. Но я сильно сомневаюсь, что под data имеется ввиду запись в базу строк вида "пользователь/like или ссылка/статья". Я именно говорю о том, что если в приложении не планируется использование более одной таблицы - писать в базу очень не хорошо, потому, что когда приложение выростет и придет надобность в "много" таблиц единственным решением оптимизации - было бы удаление этой таблицы... Мне ничего не мешает использовать json в целях preferences сохраняя like юзера и выполнять транзакцию, когда он закончил, а не дергать базу каждый раз. Так и говоря о ListView я не буду писать статьи в базу из json ответа сервера и читать от туда до тех пор, пока какая то там явно не нужна.

Foenix писал(а):кто автор рекламируемой тобой статьи? какое имеет отношение BlackBerry Java SDK - 6.0 к системе андроид? какого года эта статья?

&nbspДля начала - этот документ довольно признанная рекомендация - стандарт в мобильной разработке. Google рекомендует или не рекомундует использовать xml/json вместо sqlite3 хотя бы потому, что о чем речь вообще? Есть четкое понимание реляционной базы данных, и ее целевого назначения. Которое даже из ссылки(которую ты привела) - востановление/фильтрация/сортировка данных и факт в том, что это правда. То о чем я тут пытаюсь сказать - нет смысла записывать в базу пар ключ/значение даже если ключ и значение -это набор других ключей/значений... По русски вложенных хеш таблиц.
&nbspПо поводу срока давности документа и смысла того, что он несет, я тебе могу порекомендовать хоть и новое издание, но довольно старых идей - http://www.books.ru/books/mysql-optimiz ... ie-734220/ (думаю ты прекрасно понимаешь, что название базы на которой даются примеры значения не имеет )имеено это является источником информации. Меня в данном случае не интересует, что рекомендует google(хотя бы потому, что он не касается вопроса оптимальности хранения данных вообще) просто потому, что есть довольно изученная теория реляционных баз и это не вопрос Android(который следует им вообщето..).
&nbspИменно потому я и говорю о "больших" таблицах, что это именно причина не плодить кучу мелких и не нужных. Зачем нам программирование ради программирования или база данных ради базы данных? Да ты права не существенны потери в производительности в большинстве случаев. Вот только почему не сделать сразу правильно? И что будет с производительностью, когда в этой базе окажется десяток таких недотаблиц, а потом придется создавать действительно реляционную структуру...

P.S. дело в том, что в полноценном мобильном SDK - блекбери как бы пионеры и на них от части ровнялись многие крупные вендоры сегодня Хотя думаю ты заметила, что это общие рекомендацие, просто собранные в одном месте, но используемый везде... А может с какм -то пунктом ты не согласна?

не принимайте на свой счет, я прошу прощения

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

volboy писал(а):

не принимайте на свой счет, я прошу прощения

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

я сегодня тут где то уже давал эту ссылку - https://parse.com/products/core#howitworks попробуйте, почитайте, поиграйте... в итоге поймете как оно работает, сервис довольно грамотный.
Вообще по поводу почитать тут уж слишком большая тема и лучше отталкиваться от задачи. В общих чертах - https://cloud.google.com/developers/art ... -solutions Относительно базы - попробуйте parse.com и разберитесь в исходниках SDK, как оно работает.