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

на layout есть куча других layout
во торых layoть есть кнопки. эти кнопки имеют один и тот же id
как перебрать все эти кнопки , чтоб изменить у них , допустим видимость?

не нужно задавать один и тот же айди.
Такой вопрос уже был, поищи на форуме - что-то типа "перебор элементов" или просто "перебор"

тут такой поиск...
ничего не нашел...

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

Код: Выделить всё

String[][] idOfCheckboxes = { { "cbMon1", "cbTue1", "cbWed1", "cbThr1", "cbFri1", "cbSat1", "cbSun1" },
			{ "cbMon2", "cbTue2", "cbWed2", "cbThr2", "cbFri2", "cbSat2", "cbSun2" },
			{ "cbMon3", "cbTue3", "cbWed3", "cbThr3", "cbFri3", "cbSat3", "cbSun3" },
			{ "cbMon4", "cbTue4", "cbWed4", "cbThr4", "cbFri4", "cbSat4", "cbSun4" },
			{ "cbMon5", "cbTue5", "cbWed5", "cbThr5", "cbFri5", "cbSat5", "cbSun5" }};
	public void loadDefaults(){
		int i, j;
		for (i = 0; i < NumUpd; i++) {
			for (j = 0; j < DayWeek; j++) {
				arrCb[i][j].setChecked(false);
			}
		}
		for (j = 0; j < DayWeek; j++) {
			arrCb[0][j].setChecked(true);
			arrCb[3][j].setChecked(true);
		}
		arrCb[1][0].setChecked(true);
		arrCb[2][0].setChecked(true);
		arrCb[4][0].setChecked(true);
	
	}

скопирую сюда свой код. Разбирайся

ни гугль, ни яндекс не дали ответа, но на идею подтолкнули
чтоб заполнить пробел, покажу свой вариант
дано:
куча лэйоутов, вложенных один в другой, и идин за другим...
один их лэйоутов (назовем его Л1) динамически заполняется лэйоутами (Л2) описанными в отдельном xml
число их заранее не известно
задача: поменять видимость кнопок во всех Л2

Код: Выделить всё

//делаем "глобальный" поиск Л1, т.к. он у нас один (id такой единственный) - находим без проблем
//вместо RelativeLayout может быть любой контейнер
//получаем контейнер or
 RelativeLayout or = (RelativeLayout) findViewById(R.id.Л1);
//в этом контейнере определяем количество "ребёнков", статических + вставленных программно Л2
            int j=or.getChildCount();
            for (int i = 0; i < j; i++) {
//в каждом ребёнке ищем нужный нам элемент
                Button button = (Button) or.getChildAt(i).findViewById(R.id.buttonXXX);
//если есть и другие "ребёнки"-контейнеры или просто элемены, в которых однозначно нет нужных нам элементов, делаем проверку
                if (button!=null) button.setVisibility(View.GONE);
            }

убираю комменты (для наглядности)

Код: Выделить всё

RelativeLayout or = (RelativeLayout) findViewById(R.id.Л1);
 int j=or.getChildCount();
     for (int i = 0; i < j; i++) {
                Button button = (Button) or.getChildAt(i).findViewById(R.id.buttonXXX);
               if (button!=null) button.setVisibility(View.GONE);
           }

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

Код: Выделить всё

//ищем глобально первй нужный элемент
Button button=(Button) findViewById(R.id.bunnonXXX);
//методом подбора количества .getParent(), определяем нужный нам родительский контейнер контейнеров (у меня 3 )
                ViewGroup viewGroup=(ViewGroup)button.getParent().getParent().getParent();
                int t=viewGroup.getChildCount();
                for (int z=0;z<t;z++){
                    Button buttoX=(Button)viewGroup.getChildAt(z).findViewById(R.id.buttonXXX);
                    if(buttonX!=null) buttontoorder.setVisibility(View.GONE);
                }

для ViewPager это подходит, только там есть еще пара дополнительных заморочек...

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

Foenix писал(а):чем простое решение не подходит? ты в топике не говорил, что это "заранее неизвестно"
вообще, что значит - "неизвестно" в программе? когда ты элементы экрана пусть даже динамически создаешь, то должна быть структура , которая у тебя в программе во время выполнения будет их содержать, и точка! и по этой структуре и нужно "ходить" в цикле.

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

я конечкно могу вычислить и хранить количество, как таковое количество мне не нужно, и оно меня не спасает.
структура есть в базе,но зачем обращаться часто к базе , когда есть на экране и в принципе в памяти, и какая разница, пробежаться по структуре, хранимой в каком-то объекте (List, array...), или по структуре , которая отображается на экране?
тот же цикл for..
если даже нужным мне элемента присваивать id, а т.к. программно id задаются в виде int, то это головняки по их отслеживанию
если б можно было букво-цифровое, тогда упростилось б.
хотя тоже решаемо.
основная сложность когда это в ViewPeger, там ещё сложнее, потому как доступ есть только к 3 (или 2) экранам.
возникает куча проблем с отслеживанием ...
в ViewPage я использую при добавлении нового элемента присваивании ему id, и это не большой, но головняк.
потому как, для того, чтоб соотнести добавленный элемент с элеменот из базы я присваиваю элементу id из базы.
а так как в базе id может быть любым, то не исключена возможность дублирования элементов через n-ное количество времени
и тогда приплыли...
можно идентифицировать через Tag, но для поиска фсё равно цикл for...
а то, что получилсь - просто

2Foenix
а ты знакома с такой прогой как dbForge for mysql?
для работы с mysql вещь суперовская, если много работаешь с mysql рекомендую попробывать
поключается базе как угодно, по ssh, даже можно через тунель в Putty.

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

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

assan писал(а): и какая разница, пробежаться по структуре, хранимой в каком-то объекте (List, array...), или по структуре , которая отображается на экране?
тот же цикл for..

А тут обрадую еще больше. Обращение к элементу массива на порядки быстрее findViewById. Поиск элемента по ИД - это очень медленная операция и делать ее желательно только один раз.

KamiSempai писал(а):
assan писал(а):я конечкно могу вычислить и хранить количество, как таковое количество мне не нужно, и оно меня не спасает.
структура есть в базе,но зачем обращаться часто к базе , когда есть на экране и в принципе в памяти...
Я вас обрадую, базы данных для этого и делаются, что бы к ним часто обращались.
assan писал(а): и какая разница, пробежаться по структуре, хранимой в каком-то объекте (List, array...), или по структуре , которая отображается на экране?
тот же цикл for..
А тут обрадую еще больше. Обращение к элементу массива на порядки быстрее findViewById. Поиск элемента по ИД - это очень медленная операция и делать ее желательно только один раз.

-как ни крути, а обращение к базе достаточно долгое особенно когда в цикле идет подключение/отключение, и если есть возможность - лучше найти другой вариант. Особенно если база на sd карте.
с базами уже работаю прилично.

-соглашусь, но в данном месте мне выгоднее использовать findViewById, потому как в конкретном применение время не критично - 0.01с или 0.1с
сдесь вступают в силу наглядность и простота кода.
ЗЫ
можно и на ты, я один пишу...

assan писал(а):-как ни крути, а обращение к базе достаточно долгое особенно когда в цикле идет подключение/отключение, и если есть возможность - лучше найти другой вариант. Особенно если база на sd карте.
с базами уже работаю прилично.

А вот этого делать точно не надо! Циклы, они не для этого.

assan писал(а):-соглашусь, но в данном месте мне выгоднее использовать findViewById, потому как в конкретном применение время не критично - 0.01с или 0.1с
сдесь вступают в силу наглядность и простота кода.

Меня всегда раздражали findViewById. Не вижу в них ничего наглядного. Я лучше один раз запишу найденный View в переменную, вместо копипасты "RelativeLayout or = (RelativeLayout) findViewById(R.id.Л1);", всякий раз когда мне понадобится этот Layout.

assan писал(а): ЗЫ
можно и на ты, я один пишу...

Привычка у меня такая, с незнакомыми людьми на вы говорить.

PS:

assan писал(а):ни гугль, ни яндекс не дали ответа

Это может означать одно из двух:
1) Вы "супер крутой программист" который залез в еще не изведанные дебри.
2) Это велосипеды которыми никто не пользуется.

-полностью согласен, только я имел в виду не циклы for, while и прочие явные циклы.
к примеру когда ViewPage заполняешь данными из базы (три страницы) нет возможности сделать это в одном коннекте.

-я тоже исповедаю эту идею, но я уже писал про цифровые id.
при работе с HTML индексы можно делать буквенно-цифровыми и обращаться напрямую к нужному элементу
(и в таком индексе можно иметь всю информацию о элементе)
хотя если посмотреть R.id то там кажноту имени присваивается цифровой код, очень похожий на размещение в памяти, так, что
findViewById не перебирает, а извлекает из памяти по определенному адресу, т.е. берет "адрес расположенный по адресу".
что не намного дольше простого извлечения из переменной.

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

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

к примеру когда ViewPage заполняешь данными из базы (три страницы) нет возможности сделать это в одном коннекте.

вот это уж вообще явно что-то не то

assan писал(а):-полностью согласен, только я имел в виду не циклы for, while и прочие явные циклы.
к примеру когда ViewPage заполняешь данными из базы (три страницы) нет возможности сделать это в одном коннекте.

Используйте синглтон.

assan писал(а):хотя если посмотреть R.id то там кажноту имени присваивается цифровой код, очень похожий на размещение в памяти, так, что
findViewById не перебирает, а извлекает из памяти по определенному адресу, т.е. берет "адрес расположенный по адресу".
что не намного дольше простого извлечения из переменной.

Это только так кажется. Ведь если мы вызовем метод setId, объект в памяти не переместится. И мало того, может быть сколько угодно объектов с одинаковым id. Как они по вашему должны по одному адресу проживать?
Тут все на много проще id - это что-то вроде уникального идентификатора, генерацию которого на себя взяла IDE. Когда вызывается findViewById начинается поиск по всем вложенным View первого попавшегося View с указанным id. Если повезет, он найдется сразу, если нет, придется пробежаться по всем элементам экрана. И такое пробегание происходит для каждого вызова findViewById. Если View с таким id нет, перебор всех элементов гарантирован.

Foenix писал(а):ты бы ребят с опытом послушал, что говорят
Я тут уж молчу, т.к. у тебя много своих соображений каких-то довольно странных (для меня).

к примеру когда ViewPage заполняешь данными из базы (три страницы) нет возможности сделать это в одном коннекте.
вот это уж вообще явно что-то не то

а ты дебагом смотрела?
onCreateView вызывается первоначально 2 раза, для для первой и второй страницы
если происходит переход на страницу >2 - для 3 страниц, соответственно но номеру страницы и отбираются данные из базы
или это можно сделать иначе?

assan писал(а):а ты дебагом смотрела?
onCreateView вызывается первоначально 2 раза, для для первой и второй страницы
если происходит переход на страницу >2 - для 3 страниц, соответственно но номеру страницы и отбираются данные из базы
или это можно сделать иначе?

интерфейс отдельно, данные отдельно. Как бы грубый способ указан выше KamiSempai (это не вдаваясь в подробности как у тебя там все реализовано).

даже если пробегает перебором, это время не столь критично, если хранить все в синглтоне, и чеоез него обращаться к элемента
кто сумеет оценить разницу в реакции отображения на нажатие кнопки юзером
разница буде меньше 0.1,
а если это все делается фоном на заднем плане, то и вовсе

KamiSempai писал(а):А тут обрадую еще больше. Обращение к элементу массива на порядки быстрее findViewById. Поиск элемента по ИД - это очень медленная операция и делать ее желательно только один раз.

и для этого создали ViewHolder =)

assan писал(а):
Foenix писал(а):ты бы ребят с опытом послушал, что говорят
Я тут уж молчу, т.к. у тебя много своих соображений каких-то довольно странных (для меня).

к примеру когда ViewPage заполняешь данными из базы (три страницы) нет возможности сделать это в одном коннекте.
вот это уж вообще явно что-то не то
а ты дебагом смотрела?
onCreateView вызывается первоначально 2 раза, для для первой и второй страницы
если происходит переход на страницу >2 - для 3 страниц, соответственно но номеру страницы и отбираются данные из базы
или это можно сделать иначе?

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

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

Преребор элементов

Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов

Re: Преребор элементов