deks
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
HeMet
В Оксигене есть традиционный конструктор, но в рассматриваемом случае класс унаследован от Objective-C класса UIView. Там традиционная для Cocoa схема инициализации alloc/init. Так как никакой обертки над нативным классом не сделано, пользуем ту же схему. У Ксамарина же над контрольями сделаны обертки, что с одной стороны облегчает их использование, унифицируя с шарповым окружением, а с другой стороны - ухудшает interop с платформой.
Например, в дельфях для меня очередным show stopper'ом стала невозможность заделать custom cell для использования с нативным списком - баз кастомизации нативные контролья довольно страшные. Почти все что пишется на iOS кастомизируется именно таким образом. Если нативный контроль еще можно обернуть и заюзать в дельфях (есть и проекты TMS, и open source), то чего делать с невозможностью адекватного переопределения классов неясно.
Добавлено:
kaz_av
Да, планы CPU native от ремобджектов интригуют. Но вот делать традиционный win32 я смысла не вижу - есть дельфи, есть лазарус. К тому же будущее win32 платформы очень туманное - то оно legacy в win8, то не очень. В любом случае, в стор от МС такие приблуды не возьмут. Ну и на arm оно не работает.
Сделать CPU native компиляцию с#?
В общем, у меня фантазии кроме Linux Server не хватает. А Linux Server - это существенная часть серверного рынка, вполне себе сегмент для работы DataAbstract/SDK серверов. Особенно, если используя Sugar и исходники Mono собрать сервер без Mono Runtime. Я бы с удовольствием перевел бы домашний сервер вообще на роутер. Щас у меня все крутится на RPi и NAS Synology (хотя mono и староватый, 2.10.х). |
