Взаимодействие с UI распараллеливает в Java/J2ME
У меня была похожая проблема с новой версией Android Studio (3.3). Если вы только что обновили программное обеспечение и вдруг оно перестало работать, откройте файл build.gradle и удалите эту строку:
apply plugin: 'com.android.application'
android {
...
defaultConfig {
...
vectorDrawables.useSupportLibrary = true // This line here
}
...
Это исправило проблему для меня.
5 ответов
Относительно Java, что Вы описываете, похож на SwingWorker (рабочий поток).
Когда программа Swing должна выполнить продолжительную задачу, она обычно использует один из рабочих потоков, также известных как фоновые потоки.
Программа Swing включает следующие виды потоков:
- Начальные потоки, потоки, которые выполняют код начального приложения.
- Поток отправки события, где весь код обработки событий выполнен. Большая часть кода, который взаимодействует с платформой Swing, должна также выполниться на этом потоке.
- Рабочие потоки, также известные как фоновые потоки, где трудоемкие фоновые задачи выполняются.
Правило единственного потока:
После того как компонент Swing был понят, весь код, который мог бы влиять или зависеть от состояния того компонента, должен быть выполнен в диспетчеризирующем событие потоке.
При использовании в контексте J2EE необходимо быть осторожными при ссылке на SwingWorker от EJB.
Относительно J2ME это зависит при разработке приложения как стандартного MIDlet, который будет работать на любом MIDP-поддерживающем устройстве, или например как на RIMlet, основанное на CLDC приложение, которое использует определенные для BlackBerry API и поэтому будет работать только на устройствах BlackBerry.
Поскольку в отличие от классов UI MIDP, RIM подобна Swing в том смысле, что операции UI происходят на потоке события, который не ориентирован на многопотоковое исполнение как в MIDP. Для выполнения кода потока события приложение должно получить блокировку на объекте-событии или использовать invokeLater () или invokeAndWait () – дополнительная работа для разработчика, но изощренность идет с ценой.
Но для LCDUI, можно получить доступ к форме от нескольких потоков.
Существует много профилей Java ME. Если Вы имеете в виду MIDP затем Display.runSerially то, что Вы хотите.
Для AWT (Swing) Вы использовали бы EventQueue.invokeLater (SwingUtilities.invokeLater только необходимо из-за Java 1.1, не имеющего EventQueue метод - 1.2 собирается праздновать свой десятый день рождения). Для Общего API DOM использовать DOMService.invokeLater.
Независимо от того, что утверждает, что API GUI может сделать о потокобезопасности, они, вероятно, неправы (некоторые требования Swing удалены в JDK7, потому что они не реализуемы). В любом случае, код приложения вряд ли, чтобы быть ориентированным на многопотоковое исполнение.
Если Вы разрабатываете под SWT, это выполняется посредством asyncExec () метод Экранного объекта. Вы передаете объект, реализующий Выполнимый, таким образом, поток UI выполняет изменения, сделанные в другом потоке.
Это - пример, одолженный отсюда
public void itemRemoved(final ModelEvent me)
{
final TableViewer tableViewer = this.viewer;
if (tableViewer != null)
{
display.asyncExec(new Runnable()
{
public void run()
{
tableViewer.remove(me.getItem());
}
}
}
}
Для j2me приложений Вы, вероятно, хотите сохранить это простым. Главное состоит в том, чтобы затронуть, компоненты UI только в конечном счете распараллеливают. Прямой способ сделать это состоит в том, чтобы использовать invokeLater или invokeAndWait. В зависимости от Ваших библиотек у Вас не будет доступа к чему-то большему чем этому. В целом, если они не обеспечиваются в Вашей платформе, это, вероятно, приравнивается к тому, чтобы там быть никакой поддержкой потока и не быть проблемой. Например, ежевика действительно поддерживает его.
Я могу засвидетельствовать, что инструментарий MIDP UI действительно поточно-ориентированный, поскольку у меня есть большие MIDlet со сложным графическим интерфейсом, работающие на миллионах телефонов почти всех производителей. , и я никогда не видел проблемы в этом отношении.