Вопрос: А если убрать observableArrayList и написать observableList?

Ответ: Это будет не копия, а просто обертка.

Так, давайте, чтобы нам ничего не мешало, я подписку на изменения выкину. И обратно верну на верх изменения списка. Хотя это непринципиально.

Итак, было два элемента. Потом сделал обертку и в исходную коллекцию добавляю данные. Пока в эту не добавляю.

Вот смотрите.

run: == 7 2 2 3 3 4   7 2 2 3 3 4 СБОРКА УСПЕШНО ЗАВЕРШЕНА (общее время: 0 секунд)

Видите? Данные одинаковы. Это же одна коллекция. Это одна обертка.

А теперь я и в observableдобавляю данные – в olist.

run: == 7 2 2 3 3 4 7 9   7 2 2 3 3 4 7 9 СБОРКА УСПЕШНО ЗАВЕРШЕНА (общее время: 0 секунд)

Две печатаются – в listи olist. А ничего не должно меняться. Это одна коллекция. Вы с ней можете работать что по имени list (это обертка, она все-равно в курсе всех изменений), что по имени olist (это тоже самое – через обертку).

Это удобно. Рассинхронизации у нас не происходит. Данные одни. А вот теперь я подписываюсь на изменения и пытаюсь посмотреть. Меняю listи меняю olist. В общем два изменения. Сколько увидим invalidate?

run: == invalidate! 7 2 2 3 3 4 7 9   7 2 2 3 3 4 7 9 СБОРКА УСПЕШНО ЗАВЕРШЕНА (общее время: 0 секунд)

Почему одно? Да потому что если вот это закомментировать

 и запустить, то у listкак не было возможности сообщать об изменении, так и нет. А получается, что когда мы в нее добавляем эту коллекцию то… мы же добавляем не через обертку и получается, что обертка не в курсе, что произошли изменения. Если бы через нее прошел вызов, она сказала бы: «А!».

Вот эту строчку я убираю

и буду через обертку добавлять.

Вот если так через обертку работает. Коллекция-то одна. Какая мне разница? Я могу, что так работать с коллекцией, что через обертку. Но в плане коллекций все будет тоже самое. Она сообщает не только??????вариант. Потому что «add»обертки – он как раз в себе этот функционал и поддерживает. Он говорит: «изменилось».

Вопрос: Почему сделали оба варианта?

Ответ: А нет идеального варианта. А смысл, например, делать копию? Я говорю: «мне не нужна копия». Ну правильно. Тогда не делай, но если ты копию не сделаешь, то тогда ты можешь ошибиться воспользоваться старым вариантом коллекции и не увидишь изменений. А здесь ты сделал копию – это старая коллекция – никаких событий. А там как бы обертка… Но в общем не знаю. Они думали наверно и решили оставить два варианта.

Вам уже самим разбираться. Но с коллекциями мы еще поработаем.

События JavaFX

Но самое для нас сейчас интересное – это как в JavaFXобрабатываются события.

Они выстроили события в иерархию. Есть такие интерфейсы, которые мы видели в Swingи подписывались на события в Swingс помощью интерфейсов. Давайте посмотрим следующие в JavaFX:

· javafx.scene.input.ContextMenuEvent

· javafx.scene.input.DragEvent

· javafx.scene.input.GestureEvent

Видите? Это совсем другая история. Это классы, а не интерфейсы. Здесь получается, что для того чтобы могли обрабатываться события – у нас иерархия классов. Здесь они ушли от интерфейсов. Т.е. все события выстроились в иерархию. В Swingтакого не было.