Прощай, Smeegol

ну я ж поэтому и написал.. будущее платформы туманно без возможности делать 1 бинарник для всех версий платформы.. придется либо отказываться от новых фич, и линковаться к старой версии библиотеки, либо отказываться от поддержки старых версий. что в андроиде смерти подобно — 2.2 даже не на 50% устройств.

если бы были C-style APIs — можно было бы как-то выкручиваться, типа dlopen/dlsym. с opengl это ведь обычное дело - API расширяется, совместимость есть в обе стороны, через расширения, которые через dlsym линкуются. т.е. хоть какой-то рабочий метод.

кстати, а кто знает как в ипхоне сделано? ObjC такое позволяет, в стиле жабы?

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

живой пример - в deadbeef/android используется Service.setForeground(boolean isForeground) на <2.0, и Service.startForeground(int id, Notification notification) на >=2.0

Пиши PyQt.

В нем и смотри из скриптов номер версии. :)

> ну я ж поэтому и написал.. будущее платформы туманно без возможности делать 1 бинарник для всех версий

А вот тут связывается будущее платформы и один бинарник.

Помоему, это только ваши тараканы.

> Только если все равно приходиться писать программу под api разной степени полноты, то какая разница в один это модуль компилируется или в разные?

ну давай посчитаем. сейчас у меня используются функции из 3 api levels. значит надо будет собирать 3 бинарника. размер установочного пакета вырастает с 500K до 1.5M, размер распакованый - с 2.5 до 7.5М.

и это я бережно к ресурсам отношусь, и код на 99% native. у многих пакеты по 5-7 мегабайт, и больше.

скрипт инсталяции ставит то что нужно

что произойдет после обновления OS? юзера попросят переустановить все проги? что если проги удалены из маркета/репозитория?

> Помоему, это только ваши тараканы.

это суровые реалии разработки под мобильные платформы.

QMetaMethod::invoke тебя спасет

> скрипт инсталяции ставит то что нужно

что произойдет после обновления OS? юзера попросят переустановить все проги? что если проги удалены из маркета/репозитория?

Увеличении версии никак не повлият на работу старых. Как работали так работать и будут.

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

> QMetaMethod::invoke тебя спасет

выше писали, что это прокатит только с маленьким процентов от общего количества методов.

>> Помоему, это только ваши тараканы.

это суровые реалии разработки под мобильные платформы.

Суровые реалии - это инетмагазин, который предлагает пакеты только под твою платформу и твой текущий апи.

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

Увеличении версии никак не повлият на работу старых. Как работали так работать и будут.

сценарий:

у юзера стоит os с api level 1
юзера ставит приложение, которое умеет api levels 1,2,3
юзеру обновляют ps на level 3
приложение будет уже установлено, бинарники будут использовать api level 1, т.к. установочный скрипт установил «то что нужно» для os level 1

мнение теоретика, или таки практика?

Дались им эти нетпуки. Пилили бы под планшеты.

>> Увеличении версии никак не повлият на работу старых. Как работали так работать и будут.

сценарий:

у юзера стоит os с api level 1

юзера ставит приложение, которое умеет api levels 1,2,3 юзеру обновляют ps на level 3 приложение будет уже установлено, бинарники будут использовать api level 1, т.к. установочный скрипт установил «то что нужно» для os level 1

Но работать то не перестало.

> мнение теоретика, или таки практика?

Переход на личности? Вы хотите сказать что ситуация иная?

> Но работать то не перестало.

бесспорно. но и лучше работать не начало. а юзеры будут ждать, что после обновления с андроида 1.6 на 2.2 начнут нормально работать в плеерах headset media buttons, пропадут лаги музыки при скроллинге в браузере, и т.п.

ты первый начал тараканами обвинять. я хочу лишь сказать что ситуация именно такая, как я описываю. ибо описываю с практической стороны, с которой я сталкиваюсь.

Метафизический вопрос: кто и на каких основаниях выбирает тот или иной метод?

приложение выбирает. на основании «использовать последнее из того что есть».

его величество рынок

>> Но работать то не перестало.

бесспорно. но и лучше работать не начало. а юзеры будут ждать, что после обновления с андроида 1.6 на 2.2 начнут нормально работать в плеерах headset media buttons, пропадут лаги музыки при скроллинге в браузере, и т.п.

Если прогамма не входила в обновляемую систему, то с чего вдруг? А если входила, тогда и будет.

> ты первый начал тараканами обвинять. я хочу лишь сказать что ситуация именно такая, как я описываю. ибо описываю с практической стороны, с которой я сталкиваюсь.

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

>проект Netbook UX не оправдал своих надежд.
ВНЕЗАПНО! :)
Я плакаль...

> Если прогамма не входила в обновляемую систему, то с чего вдруг? А если входила, тогда и будет.

с того, что на андроиде это работает. программа, которая умеет 2.3, после обновления os будет автоматически юзать новые фичи. и это очень круто. а если этого сделать нельзя — это support nightmare.

>>если я слинкуюсь с библиотеками qt 4.6 — программа на компе с qt 4.3 взлетит?

Да, если будете использовать только api от Qt4.3

> Просто я невидел других, озабоченных такой же проблемой.

да все разработчики под андроид озабочены.. чтобы не потерять пользователей - надо поддерживать 1.6 and up.

Хотят что бы работало быстро. Пусть обновляются.

так ведь обновления os не от желания пользователей зависят, а от производителя железки.

Все намного проще .. пишем и собираем под минимально приемлемую версию( по фичам) , на старших заводится без проблем . проблема надумана. Я под WM никогда не собирал проги старше чем под 5.0 , чтобы везде работало.

это замечательно. такое даже gtk не может. спасибо за инфу, надо будет попробовать.

> пишем и собираем под минимально приемлемую версию

тогда программа будет по фичам ограничена наименьшей поддерживаемой версией os. в случае с андроидом - нельзя будет нормально ловить события от headset media buttons, к примеру (потому что это фича 2.2+). это действительно критично. проблема не надумана. но проблема не во всех программах есть. многим прогам ведь достаточно и api 1.6 с головой.

Те программы , которым нужен старший андроид обычно по требованиям пишут какой им нужен. Например файрвол раньше 2.1(или 2.2) вообще не заведется. А еще проще , если нужна какая-то фича нового андроида , то оставляется старая версия для старых андроидов(1.0) , а новая(2.0) уже в требованиях имеет новый андроид. Для старых версий дистров\ядер\кед новые фичи тоже обычно не впиливают , только багфиксы

А если совсем все плохо , то на крайний случай можно слинковаться статически с кутями , но это крайний случай конечно.

моя программа в требованиях пишет >=1.6, но умеет использовать возможности 2.2 и 2.3, когда они есть.

Кстати , кто знает , если ли тулкиты с которыми можно выборочно статически линковаться ? Т.е. QString статикой( новая киллер фича появилась в бете) , а остальное динамикой?

>> Просто я невидел других, озабоченных такой же проблемой.

да все разработчики под андроид озабочены.. чтобы не потерять пользователей - надо поддерживать 1.6 and up.

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

#ifdef же или в cmake'е врубать модули или не врубать, как у нас сделано

Qt Mobility 1.0.1 Released

http://labs.qt.nokia.com/2010/06/23/qt-mobility-101-released/

Note: We now realize that introducing QtMultimedia in Qt 4.6 was a premature step, given our desires to make Qt more modular. These APIs in Qt’s QtMultimedia library will be deprecated and no longer maintained after Qt 4.7, given that the same APIs will be present in the Qt Multimedia module. Therefore, it is reccommended that the QtMultimediaKit module be used for new code. An associated blog on making Qt more modular was published earlier on our Qt 4.7 post.


Qt Mobility 1.2 Technology Preview

http://labs.qt.nokia.com/2010/12/24/qt-mobility-1-2-technology-preview/

If you wish to build Mobility from source for other platforms, you will need to first build Qt. Qt binaries, as provided in Nokia Qt SDK, cannot be used to build Mobility. Mobility 1.2 requires Qt 4.7.0 as a minimum.
__________________

следовательно, разговоры про обратную совместимость не более чем форумные понты.

«две логики» - это слишком громко сказано. у меня эти «логики» - это 10 строчек кода на жабке, обернутые в удобный класс, который универсально работает на всех api levels.

и это не хак вовсе, а официальный метод работы. описанный в официальных доках, с примерами, и рекомендациями делать именно так.

ifdef - это compile-time. а надо run-time.

Ну блин, сложно несколько бинарей сделать для разных версий? Там в MeeGo же есть на основе SuseStudio собиралка

И кто этим пользовался серьезно? Всё правильно сделали.

спросил у коллеги, который девелопил под iphone — он рассказал как то же самое делается на iphone.. там есть вот такое:

[code] So when you want to call methods which are only available in iOS4.x and were not in iOS 3.0 you will have to check for availability like this:

if ([tableView respondsToSelector:@selector(setBackgroundView:)]) { [tableView setBackgroundView:myBackgroundView]; }

[/code]

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

вот и интересно, какая официальная позиция nokia/intel/meego на этот счет.

> Ну блин, сложно несколько бинарей сделать для разных версий?

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

> И кто этим пользовался серьезно? Всё правильно сделали.

Бггг ))
Спасибо , а мог ведь и сразу на личности перейти ))

В ObjC с его демонической диспетчеризацией это делается очень легко, но вообще говоря это изврат. Проще просто не использовать фишки нового API. Но вообще в Qt есть немного не нативная (ибо плюсы), но интроспекция так что то что ты хочешь вполне реально. Но на мой взгляд вместо ада поддержки ты окажешься в аду отладки. Я не помню какой из этих кругов ближе к центру…

у юзера стоит os с api level 1

юзера ставит приложение, которое умеет api levels 1,2,3

юзеру обновляют ps на level 3

приложение будет уже установлено, бинарники будут использовать api level 1, т.к. установочный скрипт установил «то что нужно» для os level 1

А нельзя собрать 3 пакета, и в каждом прописать требования к мин. версии ОС? Тогда после обновления ОС инсталлятор предложит заодно и приложение обновить до версии, использующей более «кузявый» API.

> Но на мой взгляд вместо ада поддержки ты окажешься в аду отладки. Я не помню какой из этих кругов ближе к центру…

именно в qt, или вообще? на андроиде все ок.

это все теоретизирование. т.е. да, есть много способов как это сделать. но интересен тот самый единственный, который будет официальным в meego. о нем был исходный коммент :)

> В ObjC с его демонической диспетчеризацией это делается очень легко, но вообще говоря это изврат

я пока еще не увидел менее «извратного» способа в этом треде.

> Кстати , кто знает , если ли тулкиты с которыми можно выборочно статически линковаться ? Т.е. QString статикой( новая киллер фича появилась в бете) , а остальное динамикой?

И как ты себе представляешь взаимодействие программы и тулкита, если они используют разные версии одного и того же класса?

Скажем, передаёшь ты ту же строку какому-нибудь объекту тулкита. И что объект-получатель будет с этой строкой делать? Все методы QString-а остались в твоём приложении, причём некоторые/многие запросто могли выкинуться при компиляции как неиспользованные, а по-другому до содержимого строки не добраться никак.

> «две логики» - это слишком громко сказано. у меня эти «логики» - это 10 строчек кода на жабке, обернутые в удобный класс, который универсально работает на всех api levels.

и это не хак вовсе, а официальный метод работы. описанный в официальных доках, с примерами, и рекомендациями делать именно так.

А как автоматизация тестирования в таких случаях реализуется? Разные тесты, или тесты одни, но с разными либами?