Реализация Qt signal/slot на Android

[qxfusion]

Небольшой вопрос к Вам, а чем не устроил Qt для Android? Ведь при помощи NDK нужной версии он будет работать в т.ч. и для Android 4.0 — и также нативный код не так легко декомпилировать в отличие от Dalvik.

[AlexanderOfitserov]

Если Вы имеете ввиду Necessitas то он имеет массу ограничений, например тянет за собой довольно тяжеловесные Qt библиотеки, должен быть установлен отдельно, имеет ограничения по функционалу (не работал звук насколько я помню), и самое главное то что типичное Qt приложение имеет как правило свой UX, и на Android (look&feel) не похоже.
Моё решение адресовано именно Android API Java разработчикам, просто отдельно взятая технология, реализованная на другой платформе.

[grigoryvp]

Qt в данном случае более лаконичен, хотя для реализации динамического связывания выходит за рамки C++ догенеривая код в процессе сборки проекта с помощью MOC (Meta Object Compiler).

По умолчанию, для совместимости с доисторическими компиляторами. При желании можно заменить механизм сигналов и слотов на то, что больше нравится. Например, на boost::signal, см. документацию.

[AlexanderOfitserov]

Дельное замечание. Спасибо.
Хотя думаю если заменить MOC кодогенерацию на boost::signal отлаживать легче не станет.
То есть лисенеры в данном аспекте более прозрачны, и это я и имел ввиду.

[ixSci]

boost:::signal рядом не лежал с механизмом слотов и сигналов в Qt. К примеру, попробуйте сделать queued connection в boost::signal

[Zigmar]

У них разная функциональность, разные недотатки и достоинства и разные области применения, так что не думаю, что можно однозначно сказать кто то их них лучше или хуже. Да Qt умеет посылать сообщения через event-loopы, что понятное дело выходит за рамки библиотеки boost:::signal которая не никак не привязана к оконной системе. С другой стороны MOC сильно ограничивает — нету проверок времени компиляции, нельзя использовать сигналы/слоты в шаблонных классах, не поддерживаются мощные механизмы вроде binder-ов и т.д.

[mapron]

шаблонное ограничение обычно обходится созданием шаблонного класса-предка для класса с Q_OBJECT. насколько помню, это ограничение именно moc… насчет compile-time — в qt5 частично фиксед) binder-это да, это печаль.

[DZhon]

Насколько я понимаю, в Qt нельзя изменить механизм сигналов и слотов. Все, что говорит документация, так это то, что можно отключить распознавание ключевых слов signals, slots, emit MOC-ом, дабы не вызывать конфликта с другими возможными реализациями, используемыми в проекте. Вы не сможете заставить стандартные Qt-шные виджеты использовать эту реализацию.
Поправьте, если ошибаюсь.

[grigoryvp]

Стандартные виджеты, конечно, не заставишь — хотя бы потому, что они кроме сигналов и слотов используют интроспекцию. Но если Qt исползуется как библиотека, а разработчик не желает выходить «за рамки C++», то можно извратиться :)

BTW, я нигде не говорил что альтернативным способом будет легко или удобно пользоваться. Более того, лично я ни разу в жизни не видел кейса, когда moc кому нибудь бы мешал — в больших проектах на C++ всегда используются какие-нибудь препроцессоры, это тяжелая мя жизни. Но возможность такая есть. Для сектантов и энтерпрайза :).

[ncix]

Как вы его замените? Вся библиотека Qt на этих механизмах завязана.

[Gorthauer87]

Не только и не сколько, он скорее нужен для более полной информации о типах, С++ слишком скудную дает. Если в С++ информацию о типах расширят, то тогда его можно будет выкинуть

[QtRoS]

Кстати, в Qt5 механизм сигналов\слотов начнет работать через указатели на функции. Альтернатива появится такая, если быть точным. Удобство еще больше повысится при этом!

[corristo]

По-моему Вы изобрели databinding

[corristo]

www.vogella.com/articles/EclipseDataBindingEMF/article.html вот пример из EMF/JFace, например.

[AlexanderOfitserov]

Спасибо за ссылку. Честно скажу про JFace Data Binding ранее слышал только краем уха, прочитал подробнее. Да, это также реализация паттерна Observer, да сигналы и слоты то же самое. Но возможности сигналов и слотов гораздо шире и преимущество в лаконичности. Если какой либо объект в любой момент времени вдруг решает что у него что-то изменилось он просто емитит сигнал, например:

public class MegaShooter
private void hardWork() {
  // .....
  Connector.emit(this, "multipleChanges", 123, "123", 123.0123);
  // .....
  Connector.emit(this, "simpleFlagChanged", false);
 }
}

То есть во время работы приватного метода MegaShooter.hardWork() были эмитированы 2 сигнала с сигнатурами multipleChanges(int, String, double) и simpleFlagChanged(boolean), эти изменения в код класса можно внести в любой момент и на его работе они никак не отразятся, до тех пор пока они не будут связаны с подходящими слотами:

public class MainActivity extends Activity {
 private MegaShooter megaShooter = new MegaShooter();
 private AnyOtherObject anyObject = new AnyOtherObject();
 // ......
 @Override
   public void onCreate(Bundle savedInstanceState) {
    // .....
    Connector.connect(megaShooter, "SIGNAL(multipleChanges(int, String, double))",
                                         this, "SLOT(shoot1(int, String))");
    Connector.connect(megaShooter, "SIGNAL(multipleChanges(int, String, double))",
                                         anyObject, "SLOT(anyShoot(int))");
    Connector.connect(megaShooter, "SIGNAL(multipleChanges(int, String, double))",
                                         this, "SLOT(shoot2(int, String, double))");
    // ....
    Connector.connect(megaShooter, "SIGNAL(simpleFlagChanged(boolean))",
                                        this, "SLOT(setFlag(boolean))");
   }
  }
   public void shoot1(int rate, String message) {
   // .....
   }
   public void shoot2(int rate, String message, double d) {
   // .....
   }
   public void setFlag(boolean flag) {
   // ....
   }
}

И получаем тот же binding но малой кровью. Никаких лишних объявлений, никаких интерфейсов реализовывать принципиально не нужно. 4 binding'а, 3 объекта связаны, 4 метода(слота) вызываются.