shebanoff 22 янв 2013 в 18:01

Разработка iOS приложений на Ruby

10 мин

28K

Ruby*Разработка под iOS*

Туториал

Перевод

+19

Комментарии 37

bsideup 22 янв 2013 в 18:42

Я тоже изначально искал варианты, как бы не учить Objective-C для разработки под iOS. В итоге совершенно не жалею.

Так же лично мне остались непонятны вопросы:

Можно ли из Objective-C вызывать код, написанный на Ruby?
Примеры методов с количеством аргументов около 4-5 (а такие есть)
Производительность .each do
Довольно таки смешно смотрится gem для cocoapods для того, чтобы использовать cocoapods, в то время когда cocoapods сам является ruby-приложением:)

shebanoff 22 янв 2013 в 18:55

Я чуть-чуть запутался. Вы в итоге сидите на RubyMotion? :) Нашли какие-нибудь профиты для себя в этом случае (например, совместная кодбаза с руби-проектами, либо что-то подобное)?

clayallsopp.com/posts/mixing-objective-c-and-ruby/
Что именно Вам не понятно? Внешний вид? Перенос строки, видимо :)
Наверное стоит замерить вручную. Для этого взять github.com/Watson1978/RubyMotion-Benchmark и что-то аналогичное для Вашей любимой реализации «настоящего» Ruby.
Является руби-гемом*. А вся суть в одном файле, это просто адаптация github.com/HipByte/motion-cocoapods/blob/master/lib/motion/project/cocoapods.rb

bsideup 22 янв 2013 в 19:04

Нет, я в итоге выбрал native:)

Я так понимаю делается всё же не костылём, но всё равно надо вручную все подписи используемых Ruby-классов генерировать?
Да, мне почему-то показалось, что это будет затратней, чем синтаксис Objective-C в этом отношении (особенно вложенные вызовы)
Я поздно понял что неправильно сформулировал вопрос. Интересно, во что оно генерируется, скажем так.
Ясно, спасибо:)

shebanoff 22 янв 2013 в 21:15

А в повседневной жизни используете руби?

Подробнее ответить не смогу, т.к. нахожусь вне контекста
У меня вообще вызывает отвращение вся эта ситуация с аргументами ;)
Ведь в Objective-C тоже есть блоки. Может в них?

Буду рад, если ответит кто-то более опытный.

awoland 22 янв 2013 в 22:01

3. Генерируется нативный arm- и i386- код. (Там вроде все завернуто в виде llvm-ruby компилятора.) Причем в качестве целевой платформы поддерживаются как устройство, так и симулятор.

shebanoff 22 янв 2013 в 22:02

Блин, действительно. Я почему-то начал переводить в уме в структуры Objective-C, хотя зачем — не понятно

farcaller 23 янв 2013 в 01:06

1. Ну почему, на крайний случай всегда есть NSInvocation :-)
2. Нет, синтаксис попроще
3. Машинный код с кучей вызовов в RoxorVM. В целом – еще одна обертка вокруг Objective-C Runtime. Простые операции а ля 2 + 2 компилятся как есть.

farcaller 23 янв 2013 в 01:03

1. github.com/farcaller/BackInMotion (куски рантайма MacRuby для повышения юзабельности)

НЛО прилетело и опубликовало эту надпись здесь

shebanoff 22 янв 2013 в 21:08

Вы слегка неправильно восприняли контекст. Во-первых, не «Controller», а "ViewController". Во-вторых, это инструментарий iOS, а не RubyMotion. RubyMotion, как упомянуто в статье:

— это набор инструментов для разработки под iOS на языке Ruby. Он состоит из среды выполнения, которая реализует функционал Ruby внутри iOS.

А вообще MVC (MVVC/MVVM) — это хороший паттерн, он используется во многих местах, и в Рельсе в том числе. Профит от него очевиден и понятен: разделение Модели (бизнес-логики), Представления (интерфейса) и Поведения (реакции на нажатия кнопушечек и прочего).

НЛО прилетело и опубликовало эту надпись здесь

PapaBubaDiop 22 янв 2013 в 21:00

Что только не придумают, лишь бы родной язык не учить.

shebanoff 22 янв 2013 в 21:11

;) Мы, Рубисты, народ вообще странный. Основная причина для существования RubyMotion — теплые чувства к руби, и необходимость переключения контекста.

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

egormerkushev 23 янв 2013 в 11:43

«После близкого знакомства с ним становится понятно, почему Ruby гораздо более привлекательный для этих целей язык, чем Objective-C.» — забавное утверждение всё-таки. Может, надо указать, что привлекательнее именно и только для ruby-программистов?

shebanoff 23 янв 2013 в 11:47

Это перевод, я не в праве менять суть. К тому же, момент спорный: я слышал подобные утверждения не только от рубистов.

P.S.: а Вы провели то самое «близкое знакомство»? Может быть и Вам станет интересно? ;)

DarkDeny 23 янв 2013 в 14:27

Подтверждаю это мнение. После шарпов ObjC довольно трудно воспринимать, а на руби очень приятно программировать.

moborb 23 янв 2013 в 12:01

5. Можно ли вызывать ObjectiveC блоки из Ruby кода?

В сети решений не нашел и придумал свой уродливый костыль:
github.com/dodikk/RubyMotionTestApp/blob/master/vendor/BlockBuilder/BlockBuilder/NSObject%2BBlockForRuby.m

Нормального решения не подскажете, часом?

moborb 23 янв 2013 в 12:06

6. Есть ли в Ruby аналог ключевого слова "__weak". Если нет, то как избегать циклических ссылок при работе с делегатами?

shebanoff 23 янв 2013 в 12:12

Попробуйте задать свой вопрос в гуглгруппе. Но судя по всему — нет.

moborb 23 янв 2013 в 12:26

Про блоки — уже пробовал . Пока глухо.
Про weak — нагуглился WeakRef, но завести с пол-оборота не вышло.

farcaller 23 янв 2013 в 12:45

5. Адекватными методами – нет. Есть приватный метод -invoke для вызова блока без аргументов. С аргументами – фактически это FFI.

moborb 23 янв 2013 в 12:58

Не понял, что есть «FFI». Молви человеческим языком, будь добр.

>>> Есть приватный метод -invoke
Насколько я понял, это на стороне ObjC, что, по сути, эквивалентно моему костылю.

Так как же правильно готовить memory management на стороне RubyMotion? Особенно без поддержки __weak?
Методом «don't worry — пусть себе течет»?

farcaller 23 янв 2013 в 13:24

FFI – это рубишный гем, который позволяет вызывать функции С.

В данном случае я имел в виду, что вызов блока с аргументами требует знания ABI (бинарного интерфейса). Так же как компилятор RM делает трамплины для Objective-C методов – надо делать их и для блоков. Но во время компиляции этой информации еще нет.

invoke. Можно вызывать на любых «блоковых объектах». В том числе и со стороны руби. У него типичная сигнатура «v@:», для которой гарантированно есть трамплин :)

Weak – это больная тема. Я помню пару лет назад ее мусолили в MacRuby, и тогда Лаурент писал что-то вроде того, что «или GC сам все сделает как надо, или это архитектурная проблема вашего приложения».

Как в RM обстоят дела со сборкой мусора, я, если честно, не имею ни малейшего понятия. Это, собственно, основная коммерческая информация RM. Насколько я помню, указатели в RM как раз таки со слабой связанностью, и если закинуть ссылку на объект в указатель – то это будет некий «unsafe_unretained». Плюс, всегда можно написать свой класс WeakRef, благо Objective-C в данный момент позволяет.

А вообще тема интересная, я даже захотел ее покопать (странно, что раньше оно мне не попадало в голову).

moborb 23 янв 2013 в 14:37

>>> Насколько я помню, указатели в RM как раз таки со слабой связанностью, и если закинуть ссылку на объект в указатель – то это будет некий «unsafe_unretained».
Proof никакой не подкинешь? У самого нагуглить не особо получается.

>>> «или GC сам все сделает как надо, или это архитектурная проблема вашего приложения»
И на что мне переползать с уютных делегатов? Делать все через NSNotificationCenter?

>>> и если закинуть ссылку на объект в указатель – то это будет некий «unsafe_unretained». Плюс, всегда можно написать свой класс WeakRef, благо Objective-C в данный момент позволяет.

Ну, это понятно
Тесты пока не успел на сие написать. О результатах отпишусь, если интересно. Ну, и ты тоже держи в курсе, ежели желание «покопать» перерастет в действие ))

bsideup 23 янв 2013 в 18:59

И на что мне переползать с уютных делегатов? Делать все через NSNotificationCenter?

Есть ещё вариант с github.com/bsideup/TLSignals для уведомлений:)

moborb 23 янв 2013 в 17:51

>>> Плюс, всегда можно написать свой класс WeakRef, благо Objective-C в данный момент позволяет.
Вариант «в лоб» не проканал — тест «Returns nil if not stored otherwise» валится.
github.com/dodikk/MotionBlocks/blob/master/MotionBlocksTests-Ruby/spec/WeakRef_spec.rb

Следовательно, ObjC не совсем позволяет. Очень надеюсь что где-то ошибся…
* Может, вместо строк лучше использовать более честный объект? С литеральными массиами поведение такое же.
* Шаманство с garbage collector тоже не помогло

>>> Я помню пару лет назад ее мусолили в MacRuby, и тогда Лаурент писал что-то вроде того, что «или GC сам все сделает как надо, или это архитектурная проблема вашего приложения».
Про RubyMotion он примерно то же самое говорит. Но полноценной замены делегатам пока не предлагает.

farcaller 23 янв 2013 в 19:15

Окей, я поигрался.

Нативный __weak не работает (вернее работает, но как __unsafe_unretained, ссылаясь на мусор).

Но, MAZeroingWeakRef работает отлично! (как только у него оторвать «фиксы» для использования нативных методов)

Еще есть интересная плюшка с необнулением объектов – RM все кидает в autorelease pool, а создать свой нельзя (потому что он тоже кидает его в авторелиз :) ). Решается так:

id Autoreleased(id(^block)(void))
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    
    id ret = block();
    
    [pool release];
    return ret;
}

farcaller 23 янв 2013 в 20:24

В общем, вот гем: github.com/farcaller/motion-memorymanagement

DarkDeny 23 янв 2013 в 14:26

Использую RubyMotion + RubyMine уже полтора месяца. Балдею от легкости разработки. Хотя конечно мешает отсутствие или недостаточность документации по программированию под iOS на Ruby, все идет на ObjC, так что приходится сначала вникать в ObjC, а потом понимать как это можно сделать на motion.

moborb 23 янв 2013 в 15:59

>>> Использую RubyMotion + RubyMine уже полтора месяца. Балдею от легкости разработки.
И как, не «течет»/не тормозит?

DarkDeny 23 янв 2013 в 16:35

Не торозит, а насчет «течки» пока рано говорить — потребляемые объемы малы. Я еще на достаточно ранней стадии разработки. (не туда ответил в первый раз)

DarkDeny 23 янв 2013 в 16:34

(удалено)

AlexMac 23 янв 2013 в 23:35

Да, Ruby для iOS, это мягко говоря неожиданно. С другой стороны, идея очень интересная. Глядишь, и руби станет мега языком не только для веба, но и еще для мобильных устройств. А если еще и сделают версии для Android и Windows Phone, то вообще цены не будет.