С первого взгляда 4 вещи кажутся мне странными:
1). вы являетесь слушателем настроек ПОСЛЕ того, как вы запросили контент (так может случиться, что страница может быть загружена ДО того, как слушатель сможет реагировать).
2). loadingScreen.onClose();
- что вы ожидаете от этого?
3). UiApplication.getUiApplication().getActiveScreen().close();
- вы действительно уверены, какой экран закрываете? Похоже, ты неизлечимый оптимист.
4). Я никогда не использовал BrowserFieldListener
, поэтому этот пункт является лишь предположением: BrowserFieldListener
имеет другие обратные вызовы, в том числе и для сбоев. Так что, если BrowserField.requestContent(String url)
не удастся (для этого может быть дюжина возможных причин) - это в конечном итоге вызовет тот же самый обратный вызов, который вы используете?
UPDATE
Полагаю, проблема в том, что все, что вы делаете, происходит последовательно в потоке пользовательского интерфейса. Таким образом, вы нажимаете экран прогресса, делаете sthm полезным, а затем закрываете прогресс - все это происходит в потоке пользовательского интерфейса последовательно. В этом случае вы не даете UI-каркасу возможности реально отобразить / нарисовать экран прогресса. Чтобы нарисовать экран, потоку пользовательского интерфейса нужно БЕСПЛАТНОЕ время процессора. Когда UI-поток доходит до точки, где он может начать рисовать экран прогресса, он обнаруживает, что нет необходимости делать это уже, потому что экран прогресса был закрыт.
Простой (и грязный) обходной путь - вызвать UiApplication.repaint()
сразу после нажатия на экран прогресса. Этот метод делает следующее:
Перекрашивает весь дисплей.
Вызовите этот метод, чтобы перекрасить
весь дисплей. Это делает недействительным, и
затем рисует, каждый экран на
стек отображения.