Android переходит на Swift


Содержание

Google может перевести Android на язык программирования от Apple

Сегодня появилась информация, согласно которой Google рассматривает возможность перевода операционной системы Android с Java на объектно-ориентированный язык программирования Swift от компании Apple, представленный на конференции разработчиков WWDC 2014 и в конце прошлого года ставший открытым и общедоступным. При этом источники утверждают, что полное замещение Java пока не планируется. Вполне возможно, что Google рассматривает такую возможность в связи с судебными разбирательствами с компанией Oracle.

Как отмечает издание The Next Web, Google предстоит проделать колоссальный объём работы, чтобы сделать Swift основным языком программирования в Android, и сделать всю стандартную библиотеку Android совместимой со Swift. Также сообщается, что Google рассматривает язык программирования Kotlin, но он не является приоритетным выбором компании.

153 комментария

BLOODY1987,
Эксперт в разработке ПО, залогиньтесь.
По хорошему это правильный ход. Будет меньше проблем с приложениями и выходить они будут в одни сроки, да и оптимизация будет легче даваться разработчикам.

pro100_LEXA,
Оптимизация? Нее по первому времени я почти уверен, что с ней будут большие проблемы, а в дальнейшем да, возможно будет лучше, но это после длительного срока дебага

wshadw,
Вообще статья похожа на какой то вброс, ибо Google развивает свой язык Go.

evgeniy2,
Язык го совсем под другие задачки. И последним временем гугл на него понемногу кладет.

thp,
Как сказать. Погугли «go language for android». Ну а то, что кладет, это Open Source проект.

evgeniy2,
Присмотритесь к примерам кода. Я, конечно, могу и на плюсах/винапи писать под винду. Но писать на c# мне будет явно удобнее.
Го выглядит, как очень сильно упрощенная и мене производительная замена плюсам.

thp,
По поводу упрощенности плюсов я согласен, а вот насчет производительности, тут можно спорить. А вообще Go мне понравился, такая себе смесь плюсов питона и джаваскрипта :)

Помните как я писал что скоро разница между иОС и андроид останется только в названии?
Мои мысли сбываются.
Теперь буду думать что бы доллар упал до 0.01р

evgeniy2,
Разница между iOS и Android колосальная. В iOS Object-C непосредственно компилится в OS, в то время, как Android, все выполняется в JVM

evgeniy2,
В андроиде есть прекомпиляция кода под текущее железо во время установки программы. В реальном времени код перестал компилироваться начиная с пятого андроида (в киткате тоже можно было это включить).

Советую немного почитать о принципах работы ART.

Romero F.
Тогда уж думай чтобы за рубль давали 30 долларов

evgeniy2,
Google явно не будет использовать Swift. Успокоились? Расходимся..)

Ну ведь нужен был какой-то этап в развитии Android! Эппл уже выкинула книги по Обджект Ц. А вообще лучше бы андроид переделали под более чистый Linux, ближе к Maemo, MeeGo и от него уже танцевали. Хотя понятно, что многомодульность компонентов ядра Linux в Андроид в любом случае будет иметь некую надстройку, это не противоречит принципам Linux. Но вот JAVA, будьте добры, уберите! Создавалась для Ч/Б сотовых телефонов. А теперь и геморрой с оптимизацией, много времени и усилий на допилы прошивок и версий андроид. И проблемы с Oracle из-за того, что они заьрали Java у авторов и лицензировали. OpenJDK под Java. Гуглу нужен конкурс по поиску нового языка программирования. Просто чтобы Apple не схитрил и снова не лицензировал уже открытый Swift ради поимения процента, Google необходимо пилить на каком-то другом языке поверх Linux-трансформера. И все будет тип-топ. Полагаю Android P в 2020 году уже должен полностью базироваться на новом коде. И войдет в историю, как Великая реформа Google OS )).
Но китайцы или финны могут воспользоваться случаем и выкатить по этому поводу новую OS на базе голого Linux с новым языком программирования.

Простым языком Linux — хорошая земля, язык программирования — фундамент, операционная система — дом. Чтобы был нормальным дом, стройте на хорошем фундаменте. Не забываем про хорошие материалы и строителей.

evgeniy2,
Go по-моему мнению не язык, а не знаю что. Говорю как Java-dev, не нрав.

Jaki12345,
Ну а как Java-dev может нравиться зык, в котором ООП нет? :)

Jaki12345,
Как сказать. По мне Golang очень даже хорош!

evgeniy2,
Вот вот BBC чистой воды.

evgeniy2, по сравня с Swift, язык GO это просто игрушка и для Android явно не пойдет, по крайнемере на данной стадии, к тому же у Swift куда больше перспективы, когда Apple делала эго Open-Source, они поставили цели что бы этот язык был везде, на Android’е на Wndows (вместо C#) на серверах вместо PHP, и это рано или поздно случится.
Еще у гугл на Swift скорей всего есть и стратегические планы, они могут приманить на свой Android разработчиков от iOS.

Psymantis,
Я со Swift почти не знаком, так пару статей на хабре прочитал, но утверждать, что это панацея, которая может заменить Java, C# и PHP, я бы не стал.

pro100_LEXA,
Эксперт в разработке ПО, залогиньтесь.
Меньше проблем с приложениями в каком плане?
Выходить в одни сроки с чем? С iOS? Мат часть с тобой не согласна. Концепция запуска и работы приложений на Android не совместим с iOS, разные подходы, если уйти в сторону iOS, то что тогда делать с зоопарком приложений с плеймаркета? Через эмуляторы и прослойки запускать?
Оптимизация? У вас немного не правильное понимание этого слова в корне. Оптимизировать даже использование воды в бачке унитаза можно.

InExtremo, меньше работы в плане того что не нужно будет переписывать алгоритмы с одного языка на другой. Это ускорить портирование как минимум на 30%, если обе платформы используют один язык, хоть и используют разные SDK с разными шаблонами OOP.

pro100_LEXA,
Не будет меньше проблем. Андроид на свифте и айос на свифте это совершенно разные вещи, так что не выйдет писать программу одновременно под обе ОС, это все сказки.
Оптимизация? Вы серьезно? Каким она тут боком?

artyomd2009,
На golang вполне легко одна и та же программа собирается под Windows, Linux и Android. Проверено.

pro100_LEXA,
Эксперт в разработке ПО залогиньтесь.

pro100_LEXA,
думаю что этот язык будет на android 10

BLOODY1987,
явно не от хорошей жизни

BLOODY1987,
Почему? Для разрабов выучил один язык пишешь везде

eldar9090,
Глупости. Выучить язык — дело прочтения одной, двух книг. Можно даже просто пробежаться по примерам, и сразу пойти какие-нибудь проекты на github’е посмотреть, на этом же языке.

Поймите, все — процедурные языки одинаковые. Все ООП языки одинаковые. Все функциональные языки — опять же одинаковые.
Взять, те же ООП языки, да спокойно можно переходить между C++, Java, Python, и так далее. Да, есть отличия, вроде статический/динамический язык, управление памятью, и так далее — но по факту, в ООП стиле писать на них — да никакой особенной разности. Да, сейчас в Java всё больше функциональных фишек появляется, и вот это уже дается далеко не всем.

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

OlympusNSP,
Даешь в Java лямбда функции и замыкания в каждый класс! :)

evgeniy2,
В джава же есть лямбда выражения?

artyomd2009,
В восьмой версии появились

artyomd2009,
Только в 8 версии которая толком не используется.

Chaos_Optima,
вы хоть один проект на Java вживую видели?

evgeniy2,
Лямбды, а с ними и замыкания есть. С подключением. (Java 8)


InExtremo,
Спасибо, я знаю, по этому и написал.

OlympusNSP,
Но я же. 6 лет на Комп. науках отсидел. Эх, а можно было 2 книги прочитать и стать экспертом. Какая боль.

InExtremo,
тебе про языки ООП, а ты про науки какие-то, экспертов. Короче идешь в интернет и ищешь Dive into Python. Штудируешь от корки до корки и по. й, что сначала будет ничего не понятно. (далее идет смищной текст копипасты)

Takazaka,
для новичков для Python есть всеобъемлющий Марк Лутц. В целом, достаточно первой его книги — Изучаем Python. Есть ещё две, программируем на Python, но там уже идут конкретные вещи, вроде UI, сети, и тому подобного.
Там всё так сильно разжевали, что даже у новичков не возникает вопросов, что что-то не понятно. Ну а так, для тех — для кого, это не первый, а ещё лучше не второй язык — можно и Dive into Python.

InExtremo,
Стоп. Я сказал то, что если вы хорошо знаете и используете хоть один язык, то другие с такой же парадигмой — изучаются очень быстро и легко. Разумеется, если у вас нет понимания ООП (всей вот этой ерунды, вроде инкапсуляции, наследования, полиморфизма, и прочего, прочего — ну и добавим сюда многопоточность, дедлоки и прочее веселье), то две книжки вам ничего не дадут.

Если человек изучил и понял ООП (разумеется, на каком-то языке), и далее его интенсивно использовал — то проблем изучить другого — вообще никаких. Если человеку вбили функциональщину (что там изучают сейчас, Haskell?), и он действительно на нем что-то написал (какой-нибудь домашний проект), увидел и преимущества, и недостатка, то опять же — очень легко это применяется как в других чисто функциональных языках, так и в смешанных.

Если вы 6 лет изучали языки программирования, то извините — это сплошная потеря времени. Но ведь это не так, скорей всего у вас были микропроцессоры, микроконтроллеры, операционные системы, алгоритмы, и тому подобные дисциплины. Большой пласт матана, физики, куча гуманитарных предметов, и так далее, и тому подобное.

Конечно, скорей всего — был какой-нибудь ООП язык (C++ / Java / C# / Python), возможно был функциональный. Но это не 6 лет изучается, там изучать так долго нечего.

OlympusNSP,
Можно выучить 5-6 естественных языков и общаться на них как джамшут, но лучше освоить 1-2 на хорошем уровне

OlympusNSP,
Выучить язык и выучить синтаксис совершенно разные вещи.

Chaos_Optima,
выучить язык и научится проектированию и реализации — совершенно разные вещи.

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

BLOODY1987,
Действительно глупо. Нужно было сразу C# брать.

thp,
ага, и андроид постепенно превратился бы в виндофон

gen44ik,
При чем тут ос? Фейл виндофона явно не в c#.

gen44ik,
JVM в андроид задумывалась как кроссплатформенность, чтобы приложения были процессоронезависимы. И что в результате? По факту, каждое маломальски ресурсоемкое приложение тащит за собой бинарники и либы в нативном коде процессора. Вопрос, а не проще ли убрать прослойку и вращать нативный код на том же С? Платформ то сейчас четыре осталось — ARM, ARM64, X86, X86_64. А начиная с этого года тенденция к тому, что останется две ARM64 и X86_64. Так зачем JVM?

kostyamat,
Для этого есть Golang и уже работает напрямую. С UI пока только есть проблемы.

kostyamat,
Нет, не проще)
Java/C# и тд не зря языки высокого уровня, это и упрощает всю кашу и возню, но когда дело доходит до работы непосредственно с железом, жестким контролем памяти и производительностью, в дело вступают языки низкого уровня типа того же С/С++. На данный момент прослойки типа JVM не особо то и влияют на производительность, но гораздо упрощают разработку.

thp,
Xamarin вам в помощь, сударь

BLOODY1987,
Глупо вообще использовать java в 2020 году

ff2-01,
глупо писать глупости. :D
Советую почитать те же сравинтельные тесты с другими языками. А по факту яп — это всего-лишь инструмент, гвоздь можно забить и отверткой, но молотком удобнее.

InExtremo,
еще на яп смешные картинки.

ff2-01,
Предложите альтернативные, «не глупые» яп? Я весь внимания?

Skiddy,
Весь внимания? Весь во внимании, сударь.

sleepwalker37,
где вы? Расскажите поподробнее, так интересно! Я весь внимание.

Skiddy,
С#, С++ не предлагаю, т.к. он и так везде есть.

Skiddy,
Pascal же. Там компилятор себя считает априори умнее

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

Niko Bellic 1234,
Глупость какая, медленно работает не из-за виртуальной машины, а из-за того что там куча механизмов проверки + идеология активного использования наследования вместо композиции + сборка мусора, и ещё куча костылей. Ява не для скорости выполнения а для скорости разработки была написана.

Chaos_Optima,
Ява написана для кроссплатформености

BLOODY1987,
ANDROID будет написан на одном языке с IOS. Интересно какие будут преимущества?

neka9991,
Шта, на 1 языке? Иди учи матчасть

Bassardes,
Ядро-то в обоих случаях на C/C++

Если будет хорошая оптимизация, я только за

SMswag,
время покажет, будет посмотреть.

SMswag, каким образом оптимизация относится к языку программирования? Оптимизация зависит от разработчиков софта.

illuzor,
Это из серии вроде сказал чет умное

illuzor,
Любой комментарий, содержащий слова «оптимизация», «инновация» и «курс» является универсальным и подходит к любой новости ☺

illuzor,
Да потому что различные языки программирования предоставляют совершенно разные возможности.

Patrick_vrn,
но они и для разных задач еще

гугл пойдет по наклонной?

wwwMAXiDROM,
Ага, будешь покупать мобилу на андоиде, но с огрызком на задней крышке.


Ярые Andorid пользователи, которые всегда спешат унизить Apple, негодуют. Только не жизнь суицидом не закончите, пожайлуста уважаемые.

xSERSHx, а вы бы и русский выучили бы для начала, ога.

dima55501,
Вы обращаетесь к какой-то группе людей или конкретно к xSERSHx? Если к нему, то нужно писать «вы» с большой буквы, т.к. это будет официальное обращение к одному лицу. Союз «и» и частица «бы» в Вашем предложении ни к месту.

Если это произойдёт, то в минусе будет в основном сам Oracle, так как с разработки на яве уйдут много разработчиков.

abrs,
Ораклу будет норм, уж поверьте.

pro100_LEXA,
Oracle в корпоративном секторе работает. Им на Android-разработчиков глубоко побоку

Vlad_Aero,
Скорее всего.
Только не побобку, когда их патенты без разрешения используют, что правильно.

Mr_Cokol,
всем не побоку, так как юридически это — собственность. Google обвиняли в том, что они не OpenSource библиотеки Java использовали

Vlad_Aero,
Ну да))).

Vlad_Aero,
artyomd2009,
OlympusNSP,
pro100_LEXA,

Это с чего ему норм-то будет. Oracle что Яву сделала открытой? Не фига! Oracle зарабатывает с лицензионных отчислений по Яве от владельца ОС — Мелкософта, Гугля.
Если в ОС не будет Явы, то не будет у Oracle и бабла.

algebra-5,
Я думаю, что если было бы так, то компании пошли бы на мировую.
Мы не узнали бы, так. коротко бы в новостяз мелькнула бы информация.

algebra-5,
Java им в довесок достался от поглощения Sun Microsystem. У них не от Java доход, а от систем для разработки и управления базами данных и еще от ERP-систем. Это все прекрасно гуглится

algebra-5,
Не пишите таких глупостей. Никто за яву никому не платит, потомучто нигде кроме андроида она не идет из коробки. Оракл хочет за это подоить гугл. Но трюк в том, что они не могут доить за использование языка, а только за виртуальную машину/среду исполнения. Поэтому оракл пытается доказать что далвик слизан с jvm, а гугл в свою очередь обьясняет это спецификой джавы.

algebra-5,
Да уже не актуально, Android N перешел на OpenJDK.
При этом он выйдет только в 3 квартале, так что в это году ничего кардинального не произойдет.

Про сути это ничего не поменяет, ведь вряд ли с этим изменится ART. Да и во времена JVM в чисdalJVMтом виде была несовместима с байт-кодом Android-приложений.
Но вот головной боли разработчикам может добавить

Да все будет нормально.

Урааа. Далой байт-код, а то надоело на яве писать

Junior Developer,
хех. Байт-код вряд ли куда денется. Точнее никуда он не денется.

Google может перейти на Swift

Очередной раз появился слух, что Google может перейти с Java на Swift на своей мобильной платформе Android. Походу Oracle из окончательно заебали судебными издержками и возможным штрафом и проще стало перейти на другой язык.

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

Если выбрать какой-то язык типа Go или что-то новое, то понадобиться время, когда пользователи перейдут на новый язык. Даже в случае с Apple до сих пор очень много программ продолжают использовать Objective-C. К тому же, потребуется время, пока программисты выучат язык и неизвестно, понравится ли он им.

Если выбрать .NET, то его знает достаточно большая армия программистов, и на C# полно кода в интернете, но вот только под мобильную платформу мало готовых приложений.

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

Если этот переход состоится, то я с сожалением смогу сказать, что этот день станет смертельным для Java. Без Андроида популярность Java обрушиться как минимум в пару раз, по крайней мере я так думаю. Возможно я ошибаюсь, но глядя на то количество программ, которые написаны на Java для андроида, я могу предположить, что очень много пишут их на Java.

Цукерберг рекомендует:  Цикл - Переменные переменных и цикл в PHP

Если программистов Андроида вынудят перейти на другой язык, такой как Swift, то большинство начнет делать выбор — а стоит ли им вообще продолжать изучать Java и использовать его? Если Google выберет C#, то ситуация будет еще хуже для Java. Если Swift — это гвоздик в крышке гроба Java, то C# может стать осиновым колом.

Допустим, я программист Java. Сейчас я пишу код на Java под андроид, и вполне логично шарить этот же код и под Web или может где-то еще. Если я буду писать на C# код для Андроида, то чтобы экономить деньги и не писать одно и то же дважды, я могу захотеть перевести и Web проекты на .NET.

Я думаю, что Microsoft должны сейчас прийти к Google и сказать — давайте мы заплатим 9 миллиардов, которые хотят Oracle, а вы перейдёте на C# на андроиде. За счет Xamarin этот вариант выглядит вполне привлекательным. В этом случае MS сможет шарить код, который вынуждены будут писать под Андроид, их серверные платформы так же могут пойти вверх в популярности, а Java станет ходячим трупом.

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

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым

Google перейдёт с Java на Swift в разработке для Andro >

Google рассматривает возможность перехода с Java на язык программирования Swift от Apple при разработке приложений для Android. Об этом сообщает The Next Web (TNW) со ссылкой на источники, знакомые с ситуацией. Это происходит на фоне судебных разбирательств поисковика с Oracle, которая обвиняет его в незаконном использовании Java, отмечает издание, пишет vc.ru.

Источники TNW говорят, что представители Google, Facebook и Uber недавно встречались в Лондоне и обсуждали Swift. По словам собеседников издания, соцсеть и сервис для заказа водителя также заинтересовались внедрением технологии от Apple.

Google рассматривает Swift для Android в качестве языка нативной разработки. Сейчас таковым является Java. В конце 2015 года Apple открыла доступ к исходному коду Swift, а значит, Google свободно может использовать язык для разработки в Android, отмечает TNW. Но компании придётся проделать серьёзную технологическую работу, в частности, адаптировать все свои библиотеки под Swift, а также переписать все свои приложения и API, которые в своё время писались под Java.

Источники TNW также говорят, что Google в качестве языка нативной разработки для Android рассматривает ещё одно решение — Kotlin. Компания в настоящее время использует этот язык в Android Studio. Его преимуществом перед Swift является полная совместимость с Java, но, по словам собеседников TNW, в Google считают Kotlin не столь продуктивным.

В Google отказались от комментариев, объяснив это текущим судебным разбирательством с Oracle. Судебные тяжбы между двумя компаниями начались в 2010 году, когда разработчик обвинил поисковик в незаконном использовании принадлежащих ему технологий Java для разработки в Android и других продуктов. Oracle потребовала от Google $6,1 млрд, однако суд счёл эту сумму слишком высокой и снизил её до $1 млрд.

В конце марта Oracle решила вновь попытаться повысить сумму иска — почти в 10 раз, до $9,3 млрд. В такую сумму ущерб оценил эксперт, нанятый компанией. Google, в свою очередь, наняла своего специалиста, который оценил ущерб Oracle в $100 млн. Следующее заседание по делу Java состоится 9 мая.

Apple представила Swift летом 2014 года на конференции WWDC в качестве замены Objective C. Сейчас эту технологию используют Lyft, Vimeo, Pixelmator и другие компании.

Swift может стать основным языком разработки под Android

Судебные иски Oracle по поводу использования языка программирования Java в операционной системе Android заставляют Google искать альтернативы. В новой версии платформы, известной как Android N, разработчики решили отказаться от Java API в пользу свободного пакета OpenJDK, но это может быть только началом. Как сообщает The Next Web, сейчас интернет-гигант рассматривает вариант перехода на язык Swift, созданный компанией Apple. Не так давно он получил статус открытого проекта с возможностью бесплатного использования.

Инструменты для разработки Android-приложений на Swift существуют уже давно, но для обеспечения полной поддержки нового языка программирования Google придется создать для него среду выполнения, переписать все стандартные API и внести необходимые изменения в Android SDK. Этот процесс может занять очень много времени.


Еще один вариант для перехода — объектно-ориентированный язык под названием Kotlin, который полностью совместим с Java. Он может сильно облегчить задачу Google, но в настоящий момент разработчиков не устраивает низкая скорость компиляции.

Недавно Google также намекнула на возможные варианты названия финальной версии Android N.

Подписывайтесь на наш нескучный канал в Telegram, чтобы ничего не пропустить.

Язык программирования Apple Swift портировали на Android

В репозитории Modocache на GitHub стала доступна первая версия языка программирования Apple Swift, которая позволяет компилировать приложения для операционной системы Android. Пока что это только первая версия инструмента с высоким уровнем нестабильности, но начало уже положено.

Проект Swift был представлен командой разработчиков Apple на WWDC 2014. Именно тогда случился качественный скачок вперед и компания показала свой проект, над которым работала пять лет — совершенно новый язык программирования. Apple постаралась создать язык, который будет избавлен от громоздкого наследия Objective-C. Swift был заложен в платформе NeXt, которая стала основой для OS X, а затем и iOS. Разработчики могут видеть в реальном времени результаты своего программирования.

Возможность создавать Swift-приложения для операционной системы Android, которая является самой популярной мобильной ОС в мире, открывает большие возможности для разработки кросс-платформенного софта, в первую очередь — для портирования iOS-приложений на платформу Google.

Пока что версия Swift с возможностью портирования ПО для Android не является даже альфа-версией. Однако даже такой релиз говорит о том, что разработка на Swift для «гуглофонов» теоретически возможна, а значит движение в сторону расширения возможностей использования языка будет продолжаться.

В декабре прошлого года Apple Swift, напомним, стал языком программирования с открытым кодом. Открытость означает, что программисты смогут, изучив исходные тексты языка программирования, расширить его за счет выпуска дополнительных инструментов для разработчиков. Кроме того, вероятно, мы увидим Swift-приложения для операционных систем других производителей.

По слухам, Google хочет сделать Apple Swift «первоклассным» языком программирования для Android

Поделитесь в соцсетях:

В обозримом будущем язык программирования Apple Swift, исходный код которого с недавних пор открыт, может стать ключевым для операционной системы Android. О намерении компании Google сделать Swift «первоклассным» языком программирования для Android сообщает ресурс TNW, ссылаясь на собственные надежные источники.

Сейчас наиболее востребованным среди разработчиков на Android является язык Java, и источники TNW оговаривают, что Swift призван вовсе не заменить Java, по крайней мере на первых порах. И хотя возникшие примерно шесть лет назад разногласия между Oracle и Google по поводу использования Java в Android не урегулированы и по сей день, что, определенно, дает массу поводов для беспокойств, источники говорят, что Google видит в Swift более высокий потенциал для роста по сравнению с Java. А открытость Swift в разы увеличивает его привлекательность для Google с точки зрения адаптации к мобильной платформе Android.

Кроме поискового гиганта интерес к Swift проявляют не менее именитые компании Facebook и Uber. Последние также отводят разработке Apple центральное место в собственных продуктах.

Сейчас существует множество доводов в пользу потенциально успешной реализации замыслов Google, если таковы на самом деле имеются, а не являются плодом чьего-то богатого воображения. Вместе с тем, это потребует колоссальных усилий, а сам процесс отнюдь не будет «однодневным». К примеру, нельзя просто взять и скопировать, простите за избитую фразу, Swift на любую платформу. Собственно, в случае с Android понадобится соответствующая среда выполнения – и это только начало. Компании Google также придется создать целиком стандартную библиотеку языка Swift и реализовать поддержку языка в соответствующих API и SDK. Не лишним будет отметить, что некоторые низкоуровневые API для Android написаны на языке C++, с которым у Swift пока нет никакой совместимости. То есть, их нужно будет полностью переписать. Бесполезным Swift будет и в вопросе обеспечения совместимости между высокоуровневыми API на Java, которые также придется переписать.

В целом же использование Swift для написания Android-приложений не является невозможным. Вспомнить хотя бы прошлогодние эксперименты разработчика Ромена Гойе.

По данным GitHub, Swift уже занимает 11 строчку рейтинга самых популярных языков программирования. Кроме того, спрос на разработчиков, работающих с языком Swift, постоянно растет. Помимо Facebook и Uber, возможность применения языка изучает компания IBM. Последняя, в частности, работает над тем, чтобы сделать Swift пригодным для использования в серверных возможностях.

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

Android переходит на Swift

My name is Eric Wing and we’re going to talk about Swift on Android.

Why Swift on Android?

I want to assume everybody can imagine useful cases for having a cross-platform native language like Swift available on Android. I’m using the real Apple Swift. If you’ve heard of the RIM object Silver Swift, this is not that. I’ve given talks about Android before and I’m brutally honest about Android. While the experienced Android developers always thank me at the the end for telling it as it is, people who are not familiar with Android development are in disbelief about how bad things can be and start to question my credentials.

My Background: Worn lots of hats

I’m not just an Android developer but a Cocoa developer, and I’m trying to bridge the words for the audience. I worked on a global satellite communication system called Globalstar (e.g. launching satellites into space with rockets!).

I worked in cross-platform development during the end of the Unix wars and the peak of the Microsoft monopoly. Scientific Visualization was a specialization I had. At the time, certain engineering niches needed higher liability and Windows was too unstable, but all the Unix vendors are dying. Then a solution came with Mac OS X, which promised as real Unix combined with a good GUI. Eventually, my work shifted from porting to Mac to embracing Cocoa to create first class UIS deeply integrated with OpenGL visualization systems.

I got involved in open source projects. It usually related to improving Apple platform support. SDL is the ultimate cross-platform foundation layer used heavily by the video game industry. It provides access to the graphics system, audio, input events, and anything you need to create a game or multimedia app. If you’ve played a cross-platform triple-A game in the past 15 years, it is better than a coin flip that uses SDL. Valve Steam has adopted SDL as a foundational component, it’s important to the video game industry. CMake is a cross-platform meta build system. You list the files that you need to build in a text file, and CMake will create native projects for it like Visual Studio, X Code and Make Files.

I wrote the world’s first full featured bridge between the Lua language and Cocoa. I’ve used many low-level parts of the eject and see runtime that most people don’t even know exists. I understand language bridging.

I coauthored the book Beginning iPhone Games Development, published by Apress.

I worked on some commercial game engines. I was the chief architect of the Corona SDK, which allowed people to write native cross-platform games in Lua. I later co-founded Lanica to build a game engine for accelerator people could write native cross-platform games in JavaScript. Since Android development has many problems, I inadvertently became an Android expert out of necessity.

As far as I know, I was the first to create a proper Swift Android app — February 27, 2020.

Ouroboros: Eternal cycle of life & death. What’s old is new again

Ouroboros is an ancient symbol of a serpent or a dragon eating itself. It represents an infinite cycle or something constantly recreating itself. With this talk, I hope to give you much more than a checklist of things to do. I want you to see the fundamental concepts that allow everything to work. Nothing here is new. We are reapplying old concepts in slightly different ways, when we talk about the Swift Compiler in native code, think about C compilers in native code. When we talk about Android, think about Unix and Linux. Seeing these analogies may help you understand how everything works.

The most important fundamental that keeps reappearing in this talk is C. C makes everything possible. C is like the building block for everything else because it has special properties. C is the most portable language. Every platform has a C compiler, even the web has a C compiler now. The C ABI is stable and everything is built on top of it. Almost all languages have a way to talk to C. Swift in particular, has one of the best. There is software written in C, which all the other languages can use because they all know how to talk to C.

Language vs. Libraries

When we talk about using Swift on Android or any other language for that matter, it is helpful to separate the difference between the language and the libraries because when I talk about using Swift on Android, I do not mean using UIkit on Android. UIkit is a library and one that is unlikely to ever be reported to Android, I’m talking about the language.

There is this fuzzy area with the Swift standard library base, which I boxed in yellow. You can see there are multiple libraries. Swift Core is the only one I call essential. It contains definitions for basic types we take for granted like int, and I believe it contains the Swift runtime. The others are more optional. I want to emphasize that we are getting the base Swift language working on Android and you don’t need the rest to make fully capable, shippable apps with Swift.

Here’s an example. Imagine these apps are written in Swift and all you must use Swift Core, but after that, each uses a different set of libraries. At the top is our native iOS app. It uses all the Swift standard libraries plus Uikit and Core Audio. Next, consider a native Android app written in Swift. This app uses the Swift C standard library, but there is no Uikit or Core Audio on Android, for native Android, we would use the Android SDK and OpenSL ES.

Get more development news like this

Finally, consider a native cross-platform game that goes to a whole bunch of platforms beyond Apple and Android written in Swift. SDL provides us all the functionality we need. SDL even provides audio, but for symmetry, I decided to include OpenAL for 3D Audio.

App Development vs. Server Development

I care about making shippable user facing apps that would be deployed on an app store, not command line server apps. As Mac and iOS developers, you know what I’m talking about: we must do extra things that other don’t. All our resources and dependencies must be deployed with the app. We can’t require users to install things. End users can’t be expect to compile apps from Source.

I bring this up because these are the official instructions for using Swift on Android. There are four steps here. The last two steps are completely wrong (see video) because they’re trying to build a Command line up and install it and run it on Android. You iOS developers should be able to imagine how pointless and useless this is. It masks a whole class of bugs because the environment and conditions this runs in is not like the normal Android environment, we’re going to do things the right way. But first, I must introduce Android development.


Android NDK (Native Development Kit)

All real Android apps must be written using the Android SDK, which is in Java. Android originally was Java only, but had to cave to game developers, they created the NDK, which lets developers create dynamic libraries in C and C++, but the NDK is the bare minimum they needed to do. You still must create a normal Android SDK app and start in Java. You must use Java’s loan library to load the native dynamic libraries and then use Java JNI to cross between languages. You might be asking how Swift fits in.

While the NDK was intended for C and C++, it is for all things related to native code and Swift generates native code. There is nothing new here; old concepts reapplied in a slightly different way.

Swift becomes our stand-in for C and C++. Unfortunately, the Android NDK is awful. Legendary game developer John Carmack of Doom and Quake fame called it “half-baked” and says “It really does suck.” People like to remind me that Carmack has rarely complained about developer environments, even ones that are notoriously famous for being hard, such as the Sega Saturn. This is damning, but this quote went viral because every NDK developer knows this pain. The NDK is a second-class citizen on Android with poor integration. The word on the street used to be that Google only has two full-time engineers working on the NDK.

Why am I getting on Google’s case? Android is eight years old. They’ve ignored our pleas, but reports go into the void. Public ridicule is the only tool we have left. This is one of the riches, most powerful companies in the world with complete market share dominance dominance in mobile. It is shameful, it is bad. I want to give you a taste of what it’s like you’re prepared.

Bionic (Android’s C standard library)

Android does not use glibc. They wrote their own standard C library for Android called Bionic. It doesn’t care about POSIX compliance. It doesn’t even care about ANSI compliance and eight years in Android, it is still terrible.

Lua is an embeddable scripting language. It is renowned for how portable and clean its code base is. Lua has been built on everything. It doesn’t resort to pound dip dash everywhere for different platforms. It is a singular code base written in pure standards compliant ANSI C. To demonstrate how awesome the code base is, somebody build modern day Lua in Boroland Turbo C 1.0 for MS-DOS from 1990 without modifying the source. It built and ran successfully.

Цукерберг рекомендует:  Полно-экранное изображение и навигация

If we try this with a modern Android NDK we get build failure. This is a post from a Bionic engineer. I’m not picking on this engineer. This poor soul is trying to fix this mess, but this gives different insights into why Android is awful.

Let me read an excerpt: “As you may be aware, Android’s C library, Bionic, is a hybrid of code from different sources, home grown, FreeBSD, NetBSD, and OpenBSd. NetBSD files aren’t from a single NetBSD release. hell, they’re not necessarily from any release. I found the bug that had been fixed in Upstream in like, 1996, but we had some random old version of that file.

Terrible performance bug for strlcpy

In a prior project, I wrote a program to run a JavaScript performance to suite called Test262, which goes through 11,000-plus files. I use strlcpy in a hotspot. For a hot loop that should have taken 14 milliseconds, it took 9,000 milliseconds.

On the SDK side, I was trying to get my list of 11,000 files inside a directory in the APK. Little did I know, I walked right into a well-known Android performance bug. Pessimistically, this should take no more than a few seconds. Three hours later, I gave up and killed the process.

Speaking of files, files that ship with your app are ins >fopen and fread on anything in the .apk. Google makes you use a different set of functions. On top of that, they require a parameter that comes from a “God” object from the Java Android Activity or Context class. This means existing cross-platform libraries won’t work without special modification for Android. How many projects want to do this? And it’s ridiculous that this problem even exists.

Dynamic Library System wonky too

Android has wonky behavioral rules for dynamic libraries. I wish I had time to cover this in detail because things are affected by this. It is a common source of breakage and often leads to needing to specially modify cross-platform code.

Another example I’m going to call out is the soname. Soname is a meta data field and dynamic libraries for the Elf Executable and Linker format, which is used on Linux systems and much all Unix systems except Apple. There is a strong convention that put versioning information in the soname on Linux distributions combined with a series of symlinks. This will break on Android. You need to go one step deeper: C++.

Swift & C++ (and how it affects you)

Once upon a time, it was well known that you do not write libraries in C++, but I see a lack of library developers giving talks nowadays, and people seem to be forgetting these important lessons. I have to mention this because Swift uses C++. Swift itself is implemented in C++ and the standard libraries depend on the standard C++ library. Thus, the C++ fitpals are passed onto you. With the adnroid NDK, these problems are much more apparent.

Android NDK and C++

The NDK provides five difference C++ standard libraries you have to choose from. Choice is not a good thing. All are incompatible with each other. The C++ standard library does not guarantee a stable ABI, ever NDK upgrade potentially breaks things. If you use dynamic linking for your shared library of choice, you must bundle it with your app because Android does not ship a copy with the OS. This is in contrast to Apple, which ships you one to spare you this mess.

In the real world, people build library binaries and share them. But people don’t upgrade their NDKs all at the same time, and versions get mixed. People use multiple libraries and each library could be built with a different NDK version. You’d expect that the final application must include a copy of all these different C++ standard library versions that all your different libraries depend on. But Android doesn’t name versions differently, and files will override each other. Some of your libraries will start calling into the wrong version and bad things happen.

In contrast, Microsoft Visual Studio has the common sense to put version numbers in the file name to avoid this problem. we should statically link. This is the warning that Android has in their documentation about static linking. It’s loose. Thanks for nothing, Google. In practice, I personally found static linking to be the better of the two. Unfortunately, modifying this with build system is hard. I’ve successfully modified it in Swift 2 and submitted a patch, but the patch was never incorporated and somebody upstream re-based, the patch is broken now. It’s back to dynamic linking for now.

Let’s build Swift for Android: Dependency hell

We are application developers. The Android NDK provides almost no libraries we are responsible for building every library we need and shipping it with our app.

I showed these instructions earlier and said this mostly works. But you need to know about this gotcha. This is an Android variation of “DLL hell”. The main dependency for Swift Core that we need is libICU, the international components for unicode library, which is written in C++.

ICU is a popular enough library that Android manufacturers or Android itself may use internally. If used, when we try to load our ICU library with load library, the call silently does nothing because the operating system thinks it’s already loaded. If we use the exact same version of ICU with the same build options, things will work, but ICU is notorious for breaking compatibility every version. Throw in Android fragmentation, and it is guaranteed that somebody will be running with a different version.

Now that the versions don’t match, when your code uses ICU, bad things start to happen. If you’re lucky, you’ll get a crash. One way round this is statically link with ICU. But, if you must dynamically link, you should rename the libraries and the symbol names they do not conflict with the version in the operating system. ICU has switches to help mangle names differently because they are at least aware of the problems caused by breaking compatibility all of the time. You need to disable soname versioning because libIC’s build system is overly aggressive about setting it. good news.

Let’s use Swift on Android!

If we made it this far, we have a perfectly usable Swift for Android. Unfortunately, I need to skip foundation for time. It’s not part of the official build yet, but this slide has a few notes on its dependencies.

Earlier I said the official instructions were wrong. We’re going to do it the right way. Remember, all Android apps must use the Android SDK, which is in Java. We need to start in Java and work our way to Swift. We need to create a proper Android Java app and follow the standard techniques to cross into the NDK. We’re going to start in Java, cross into C, and then cross into Swift.

Android/Java

We start in Java. On Android, every Android app must have an activity to start in. An activity is like a window or a view controller. I made this class my starting activity. I’m using the on create method as my starting point. You can think of it as a knit and Cocoa.

Here we must load all dynamic libraries for Swift. Order matters, we load all the dependencies first, then Swift itself, and then our program, which we wrote in Swift.

Remember, we cannot build normal X cable files for Android, everything we write must be built into a dynamic library it can be called from Java. This is the same class as before, but I’ve hidden the on create method we can see this. On start is roughly the equivalent to awake from NIB or applications that finished launching. In here, we want to call a native function that will get us to C. The mechanism that makes this work is Java JNI. JNI is well-documented, it comes down to following a bunch of rules and boilerplate. In this example, I’ve declared that I promise to implement the function called MyMainEntry in C. The native keyword tells Java that this will be a native function.

The Java compiler is now trusting me to fulfill my promise of implementing it. I want to point out the package name declaration here because you will see how it is used in a second.

Now in C: call into swift

This is the implementation for that native function. Notice that the package name is part of the function name. This is one of those rules of JNI.

Now that we are in C, we need to call into Swift. I’m going to do a trick, but it’s a trick based on old fundamentals. Let’s call a function that looks like a C function but is a Swift function behind the scenes. We’ll call it MyMain().

Finally, we’re in Swift and here’s my Swift function. The trick is, the app’s _cdecl parameter. This tells the Swift compiler to make the function you see call in conventions it can be called like any other C function. Notice we declare the function as public. Make sure the symbol is accessible to be called across the dynamic library boundary. We transformed and reduced the problem so it looks like C. Again, there is nothing new here. We took our Swift ideas and transformed it to look like how we would solve it with C in the past. Now that we’re in Swift, we can start having fun and write things in Swift.

We must never block the event loop. Android is event-driven, like iOS. You will need to figure out how you want to use Swift in your app. You’ll likely create more callbacks like this to call Swift for different events. Alternatively, you could spin off the background thread. However, I strongly discourage this unless you know exactly what you’re in for. If you ever need to call system APIs from Swift, you’re in for a world of pain from doing it from a background thread. This is like trying to write a full-feature Cocoa app from a background thread: you are asking for trouble.


Caveats

There’s no objective C runtime on Andro >g_isInit . It is initialized to false. You can see when we first run this program, the top block in the with else gets run because our variable is false. We then set that variable to true. In Android, let’s assume you exit the program with the back button, which is an Android difference compared to iOS.

Let’s relaunch the program. Depending on whether Android purged all the NDK memory between runs or not, our goal variable may or may not get reinitialized. If Android let this memory alone, when you relaunch the program, the dynamic library you loaded is still in memory. Google made the decision to not reload and reinitialize things. In this case, even though this is a brand new start, our global variable is still set the true from the last run. If we take the bottom block of the with else, we will take the bottom block, which is probably not what we are expecting and wrong.

This problem scares me the most because it is subtle and I don’t know how far reaching the implications of this are yet. If you need this pattern, try to design it in a way you can explicitly reinitialize your variables manually at start.

Build Systems (Ugh…)

As somebody who has done cross-platform work, this tweet resonates with me “when you’re trying to ship on 3 platforms, you’re dealing with portability issues. But on 13 platforms, it’s all about build issues”, by Fabian Giesen.

Even at three different enough platforms, the build system differences are crippling. Take X Code, Android Studio, and Visual Studio as three of them. They’re completely alien to one another.

Build systems are the worst. While languages are standardized and cross-platform at least try to minimize the differences, build systems are completely different and the platform vendors have no interest in minimizing the cross-platform pain.

Build System Options

There are three basic techniques to build your projects for Android:

  1. Swift Package Manager. Personally, I haven’t found this useful. The main problem is that things we need to do with Android Studio are a far cry from what Swift Package Manager does.
  2. You can string together the cause to the Swift compiler to build everything yourself. Look at what XCode does and reproduce the commands. Obviously, this is a pain and it’s hard to scale, especially as you need to maintain additional platforms.
  3. CMake.

CMake is well-used by cross-platform projects, even LLVM, Cland, and Swift are using CMake internally. Surprisingly, Android recent announced their support in CMake as part of Android Studio. CMake already has support for each platform’s native build process. For example, it can generate Esco projects. But since Swift is a new language, CMake doesn’t know anything about it. I started implementing support for it. My repo’s on Get Hub if you’d like to help. It’s a work in progress, but there is enough to make shippable applications.

This is a simple CMake script showing how to make a library or executable for Swift code. CMake script isn’t going to win any beauty awards, but the CMake project generation capabilities are unparalleled.

Let’s talk about Libraries for writing Android apps

There are three major categories:

  1. Native Android-only development in Swift
  2. Cross-platform development (non-native GUI)
  3. Cross-platform native GUI

Native Android in Swift

Can we write native Android-only apps in Swift? Yes, but it isn’t pleasant. We must go through JNI. Furthermore, not everything is possible through JNI. For example, you cannot subclass through JNI, you’ll still need the right Java for those cases, unless you resort by code hacks or code generation.

But again, there’s nothing new. JNI has been around for a long time. We know how to deal with it, and the world has come up with all sorts of solutions. But they all come down to the same basic ideas. You can write higher level libraries to encapsulate and hide all the JNI so when you use the libraries, you don’t have to touch JNI. Or, you can develop co-generation tools. While I’m not a huge fan of co-generation because it often introduces new problems (e.g. complex build systems, long build times, and application bloat), you can see high-profile companies have resorted to this on Android.

Cross-platform (C) libraries

Moving beyond pure native Android, let’s look at cross-platform libraries. Again, there’s nothing new. This has been solved many times over. Developers have been doing cross-platform for decades, especially by the video game industry. There’s a C library for everything. And, if there’s a C library, we can use it with Swift.

Here’s a list of the some of the usual suspects: SDL, OpenGL, OpenAL, FreType does fonts, libpng and libjpeg for your image needs, cURL for networking. Chipmunk even provides a physics engine in PureC.

FlappyBlurrr Swift

There’s already more than enough to make full apps in Swift on Android and any other platform you can think of. This is a FlappyBlurrr clone I wrote in Swift using SDL and company.

I’m a FlappyBlurrr perfectionist and most clones are terrible, I focused to get the timing details right (even though I don’t have time to prove it to you). And because our libraries already work cross-platform to everywhere, this program can work everywhere. This even runs hat a smooth 60 frames per second on a Raspberry Pi.

What about (non-native) GUI?

Let’s start easy with non-native GUIs, ones that display the exact same thing no matter what platform you’re on. My favorite is Nuklear. It is pure C, it can be used easily with Swift, and it has zero dependencies, it is easy to drop into a project. It is designed to be easy to adapt to any drawing toolkit. OpenGL is the most common, but it can be adapted to anything.

Here’s a screenshot, and a nice view of it running on Android (see video). This is a particle designer I wrote for the desktop. One aspect I wanted to not is that these non-native GUIs scale linearly with your screen size. I intentionally made the widget small I could fit more, my design is not ideal on a phone. But, it does work and it is surprisingly usable on an iPad or Android tablet. I’m showing this to you to get you to think about your designs if you need to support a wide range of screens, like TVs to phones.

What about cross-platform native GUI?

But I know most of you are native developers. We know how much the native experience can matter to users, and how much better it can be. Is there a cross-platform solution to native GUI?

I know everyone here wishes they could take their Cocoa apps and recompile them everywhere else, but this is a hard problem. If you look at history, there is a long list of serious attempts. Every one of these has failed to achieve the dream. If we look beyond Cocoa, we see that there are very few actual native toolkits out there, and the ones that we can use with Swift are even fewer. But there is one I like, called IUP.

IUP (Portable User Interface), A Hidden Gem

IUP originated as a research project from the same university in Brazil that created the Lua language, but it has since become a production-quality library used in certain circles like the oil industry and scientific visualization.

It uses true native widgets. It is small and focused only on GUI. Most other libraries have become a massive kitchen sink, reinventing everything and has tons of bloat. For us, this is a perfect fit because foundation + IUP has no overlap, like foundation + UIkit.

Цукерберг рекомендует:  Разбираем Underscore.js по косточкам. Метод findWhere

It is written in C, but it is written with language bindings in mind, we can easily use IUP in Swift. It also comes with a textual layout description language called LED, separating code from data, and can be used for per-platform customized layouts.

IUP’s research roots were focused on how to deal with the wide variations between different platforms not only in the widget differences, but on how not all platforms use object-oriented languages. It is very well thought out. Much of the API solution centers around a key value attribute system. Think NS user defaults. This allows API access to native features that may not exist on other all-platforms without constantly breaking the API design, nor preventing you from accessing platform-specific features if you want them.

Squint hard and see…

While some people may not be able to look past the stringy API, this is protocol-oriented design. At least this best can be done within C’s weak type system. I think there are amazing possibilities for a Swift wrapper for IUP. There’s already been talk in the Swift community about what if we could have a GUI API designed around protocol-oriented design.

Here’s a hidden gem that needs polish. And the great news is that the Swift community has already developed many techniques to build nice wrappers. For example, last year’s Try a Swift talk, Swift Eye for the Stringly Typed API by Andy Hope.

IUP drawbacks


But every solution has its drawbacks. For IUP, it has native windows, GTK2, GTK3, and Motif, but no Cocoa. But we can fix this.

This is a screenshot from a Rio program I wrote (see video). The screenshots are from Windows and Linux. This is a work in progress, but here it is, running on Mac.

What about mobile? We can fix that, too. IUP is well-designed. I believe it can do mobile, too. You can look up a YouTube presentation I made on this topic. As a simple example, most other libraries made the mistake of modeling their APIs off of existing desktop APIs and everything is shoehorned into that, and we get things like a Window API. In contrast, IUP created a more ambiguous dialogue API. On the desktop, this may map to an actual Window API. On mobile, we get to decide what makes sense. For iOS, we map dialogue to use UI navigation controller and view controllers, and on Android, we map it to activities.

Demo Program: Create Dialog & Button (recursive)

You don’t need to understand this code, but I want you to know that this is a complete IUP program written in Swift. For clarity, I did not write any high-level Swift wrappers, you are seeing everything. This program creates a dialogue containing a button. When you press the button, it creates a new dialogue with a button and forth.

See the video to see the program running on Ubuntu Linux, Raspberry Pi, Mac, iOS. We are mapping dialogue to use UI Navigation Controller and UI View Controllers under the hood. And finally, Android. Here we map dialogue to activity. And… Surprise! Swift on Windows.

Re-cap of what we just saw

You saw native GUI cross-platform desktop and mobile with a single code base in Swift. If you’d like to help out, my research are in GitHub.

My repos https://github.com/ewmailing/IupCocoa https://github.com/ewmailing/IupCocoaTouch https://github.com/ewmailing/IupAndroid https://github.com/ewmailing/IupEmscripten

Blurrr SDK (My current endeavor)

There is no magic in cross-platform, but there is tedious work involved. I’d like to make cross-platform native development more accessible to more people. I created Blurrr SDK. I want you to leverage my experience in dealing with all the annoying platforms specific to the differences you can focus on your core program. I use Blurrr to help me create all the examples in this presentation.

Blurrr handles the build system challenges using CMake under the hood. Blurrr provides a bunch of deployment-ready pre-built libraries so you can build your app and ship it. I tried to provide a download and go experience for Blurrr itself.

This is the Blurrr workflow (see video). Start it up, open your project, then you get the appropriate native project for the platform you’re on. Then you work on your code, build and run. Currently, I include libraries, like SDL. Blurrr is currently best for games and multimedia apps.

I am very serious about IUP. It is in development but quite capable. I’m still nervous, but I want people to use this, I’m opening up the beta today you can all start playing with it. I’m still trying to get off the ground, I could use your support. I will be doing a game workshop at the Hackathon.

Carlos M. Icaza, June 5, 1966 — May 17, 2020

I want to switch gears and say a few words about my friend, mentor, and former co-founder, Carlos Icaza. He passed away unexpectedly this summer. While he was known by many different groups for different accomplishments, the Swift community knows him as @codinginswift, with 18,000 followers. He held Swift meetups. This one (see video) was in Silicon Valley; he even managed to somehow get the elusive Chris Lattner to show up that night.

I wanted to try to write something in his memory that would have a special significance for events we shared together. In some sense, this is a bucket list of things we wanted to achieve together, but time ran out. For example, he was an expert at splines. We wanted to do a spline project together, but it could never get a high enough priority.

I wanted to leave you with something that inspires you with how much is already possible with cross-platform Swift today.

Q: How that is Apple in these respects, in the same fragmentation and not following standards? Eric: It’s good. Our rules from generally, and all the companies I’ve worked with, Android is about four to 10 times harder.

Q: How about the memory management difference between Android platform and Swift? Eric: If you’re on Swift, you’re using the NDK side of the memory, not the SDK side unless you’re calling in to native widgets. The funny thing about Android memory management is that the Java side is completely managed and Google has done stupid things and they have imposed artificial memory elements for your Java apps. A long time ago, the memory limits were artificially, insanely low and nobody could write real apps with it, the NDK people figured out if you do stuff on the NDK side, you can use all the memory that’s on the device and those limits don’t apply to you. And because Android is bloated and general, they ship with more RAM than their iOS device. you actually, generally, get more memory with Android than you do with iOS.

Next Up: Realm’s Cross-Platform Capabilities

About the content

This talk was delivered live in March 2020 at try! Swift Tokyo. The video was recorded, produced, and transcribed by Realm, and is published here with the permission of the conference organizers.

Eric Wing

Eric has worked a wide range of jobs in the field from automated testing on orbiting satellite systems to scientific visualization with a variety of different operating systems and programming languages. He has been a contributor to projects such as SDL (Simple DirectMedia Layer), OpenSceneGraph, and LuaCocoa. He became the Chief Architect for Corona SDK and then co-founder of Lanica building a native game engine for Appcelerator. And now he is working on his craziest endeavor yet, Blurrr SDK.

Android переходит на Swift

Getting Started with Swift on Android

The Swift stdlib can be compiled for Android armv7 targets, which makes it possible to execute Swift code on a mobile device running Android. This guide explains:

  1. How to run a simple «Hello, world» program on your Android device.
  2. How to run the Swift test suite, targeting Android, and on an Android device.

If you encounter any problems following the instructions below, please file a bug using https://bugs.swift.org/.

Let’s answer a few frequently asked questions right off the bat:

Does this mean I can write Android applications in Swift?

No. Although the Swift compiler is capable of compiling Swift code that runs on an Android device, it takes a lot more than just the Swift stdlib to write an app. You’d need some sort of framework to build a user interface for your application, which the Swift stdlib does not provide.

Alternatively, one could theoretically call into Java interfaces from Swift, but unlike as with Objective-C, the Swift compiler does nothing to facilitate Swift-to-Java bridging.

To follow along with this guide, you’ll need:

    A Linux environment capable of building Swift from source, specifically Ubuntu 16.04 or Ubuntu 15.10 (Ubuntu 14.04 has not been tested recently). The stdlib is currently only buildable for Andro >

Part One: «Hello, world» on Andro >

1. Downloading (or building) the Swift Android stdlib dependencies

You may have noticed that, in order to build the Swift stdlib for Linux, you needed to apt-get install libicu-dev icu-devtools . Similarly, building the Swift stdlib for Android requires the libiconv and libicu libraries. However, you’ll need versions of these libraries that work on Android devices.

The steps are as follows:


  1. Ensure you have curl , autoconf , automake , libtool , and git installed.
  2. Clone the SwiftAndroid/libiconv-libicu-android project. From the command-line, run the following command: git clone https://github.com/SwiftAndroid/libiconv-libicu-android.git .
  3. From the command-line, run which ndk-build . Confirm that the path to the ndk-build executable in the Android NDK you downloaded is displayed. If not, you may need to add the Android NDK directory to your PATH .
  4. Change directories into libiconv-libicu-android : cd libiconv-libicu-android
  5. Run the Swift build script: ./build-swift.sh
  6. Confirm that the various libicuXYZswift.so libraries are located in the armeabi-v7a directory.

2. Building the Swift stdlib for Android

Enter your Swift directory, then run the build script, passing paths to the Android NDK, as well as the directories that contain the libicuucswift.so and libicui18nswift.so you downloaded or built in step one:

3. Compiling hello.swift to run on an Android device

Create a simple Swift file named hello.swift :

To compile it, we need to make sure the correct linker is used. Symlink the gold linker in the Android NDK into your PATH :

Then use the built Swift compiler from the previous step to compile a Swift source file, targeting Android:

This should produce a hello executable in the directory you executed the command. If you attempt to run this executable using your Linux environment, you’ll see the following error:

This is exactly the error we want: the executable is built to run on an Android device—it does not run on Linux. Next, let’s deploy it to an Android device in order to execute it.

4. Deploying the build products to the device

You can use the adb push command to copy build products from your Linux environment to your Android device. If you haven’t already installed adb , you may do so via apt-get :

Once you have adb installed, verify your device is connected and is listed when you run the adb devices command — currently this example works only in devices / emulators with at least Android 7.0, API 24 — then run the following commands to copy the Swift Android stdlib:

You will also need to push the icu libraries:

In addition, you’ll also need to copy the Android NDK’s libc++:

Finally, you’ll need to copy the hello executable you built in the previous step:

5. Running «Hello, world» on your Android device

You can use the adb shell command to execute the hello executable on the Android device:

You should see the following output:

Congratulations! You’ve just run your first Swift program on Android.

Part Two: Running the Swift test suite hosted on an Android device

When running the test suite, build products are automatically pushed to your device. As in part one, you’ll need to connect your Android device via USB:

Как настроить SwiftKey на Andro >

Все знают, что набор текста временами раздражает — со всеми этими опечатками, длинными словами и неизбежными ошибками автоисправления. Мы составили это удобное руководство, чтобы помочь вам настроить беспроблемную работу SwiftKey.

1 — Индивидуальная настройка SwiftKey

Чтобы оптимизировать свою работу со SwiftKey, мы советуем вам тщательно изучить Инструменты и Настройки. Это настоящий командный центр приложения.

Инструменты

Инструменты — это место для материалов и функций, которые вы используете чаще всего. Коснитесь или проведите по меню-«гамбургеру» в левом верхнем углу клавиатуры для быстрого доступа к стикерам, GIF-файлам, темам, календарю и другим настройкам.

Больше информации об Инструментах вы найдете в этой статье.

Настройки SwiftKey

В Инструментах вы найдете большинство повседневно используемых настроек. Но для полного контроля вам стоит открыть собственно настройки SwiftKey.

Из панели «Инструменты»:

  • Коснитесь значка шестеренки («Настройки»), а затем «Настройки» и значок.
  • Откройте приложение SwiftKey непосредственно со своего устройства

В этих настройках вы сможете выполнить тонкую настройку SwiftKey, а также настроить такие элементы, как языковые пакеты/раскладки, опции звука/вибрации и параметры исправления текста.

2 — Языки

SwiftKey поддерживает более 500 языков, поэтому даже если вы говорите на нескольких, вполне возможно, что мы поддерживаем их все! Кроме того, для набора текста можно использовать до пяти языков одновременно, что позволяет меньше переключаться между языками и больше времени уделять общению с близкими людьми.

Загрузка/подключение языков

Начнем с начала: где загрузить и подключить языки?

Это можно сделать в разделе «Языки» в настройках SwiftKey (доступ к ним можно получить либо через панель «Инструменты», либо открыв приложение со своего устройства):


  • Вы увидите длинный список доступных языков, для загрузки просто коснитесь нужного.
  • Загруженные языки подключаются автоматически; одновременно можно подключить до трех языков.

Настройка языковой раскладки

Возможно, вы хотите печатать на немецком, но с раскладкой клавиатуры QWERTY, или на английском с раскладкой QWERTZ. Как изменить языковую раскладку?

Это также можно сделать в разделе «Языки» в настройках SwiftKey. Загрузив языковой пакет, просто коснитесь окошка под ним, чтобы просмотреть список доступных раскладок и выбрать нужную.

Если вы хотите узнать больше об использовании SwiftKey с несколькими языками, ознакомьтесь с этим пояснением с видео.

3 — Персонализация и резервное копирование слов

Улучшите работу со SwiftKey с самого начала благодаря ученой записи SwiftKey.

Учетная запись SwiftKey

Учетная запись SwiftKey — это служба с бесплатной регистрацией, улучшающая работу SwiftKey Keyboard путем использования возможностей облака. В частности, вы можете:

  • Мгновенно подстраивать подсказки под себя, разрешив SwiftKey узнавать, как вы печатаете в различных соцсетях (в том числе в Facebook и Twitter).
  • Безопасно хранить наиболее часто используемые слова и синхронизировать их на всех своих устройствах (вы больше никогда не потеряете выученные слова).

Для использования этой магии вам нужно только:

  • Создайте учетную запись SwiftKey, открыв приложение со своего устройства.
  • Коснуться опции «Персонализация» и выбрать желаемые источники обучения для SwiftKey (вы в любой момент можете вернуться и сделать это снова).
  • Убедиться, что «Резервное копирование и синхронизация» включены.

Конфиденциальность и безопасность данных

Важно, чтобы вы знали, что мы очень серьезно относимся к конфиденциальности и безопасности данных. Учетная запись SwiftKey — это надежная служба с регистрацией и шифрованием, предоставляющая вам полный контроль над вашими данными. Наша продуманная Политика конфиденциальности разъясняет и защищает ваши права и конфиденциальность.

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

4 — Индивидуальная настройка клавиатуры

SwiftKey предлагает множество возможностей индивидуальной настройки набора текста.

Исправление текста

SwiftKey не только исправляет ваши опечатки, но и предугадывает ваше «следующее» слово (т. е. читает ваши мысли!). В этом важную роль играет пробел, который можно настроить на выполнение одного из следующих действий:

  • Всегда вставляет среднюю подсказку
  • Всегда завершает текущее вводимое вами слово
  • Всегда вставляет пробел (снимите галочку с опции «Автоисправление»)

Подсказка: в любом случае вы всегда сможете вводить подсказки непосредственно из строки подсказок.

Эти настройки можно найти на странице настроек «Набор», открыв приложение со своего устройства.

Способы ввода

Если вам хотелось бы набирать текст, безотрывно проводя пальцем по клавиатуре, вам определенно стоит обратить внимание на SwiftKey Flow! Если хотите испытать эту функцию, вы можете сделать это на странице настроек «Набор» > «Жестовый ввод» (доступ к которой можно получить, открыв приложение на своем устройстве).

Подробнее о Flow можно узнать здесь.

В меню настроек «Набор > Голосовой и другие способы ввода» можно также включить или отключить клавишу голосового ввода, обеспечивающую возможность диктовать текст голосом.

Функции клавиатуры

Стоит зайти и на страницу настроек «Клавиши» — доступ к ней можно получить, открыв приложение со своего устройства и выбрав раздел «Набор > Клавиши». На ней можно выбирать и добавлять опции клавиатуры, например:

  • Клавиши со стрелками
  • Цифровой ряд
  • Подсказки эмодзи
  • Дополнительные символы с диакритическими знаками

Кроме того, вы можете выбрать положение цифровой клавиатуры (слева или справа) и выбрать упрощенный доступ к клавише ввода или к панели эмодзи.

Всем любителям точности понравится функция выбора продолжительности длительного нажатия на клавишу (т. е. количества времени, в течение которого необходимо нажимать на клавишу для получения доступа к второстепенным опциям клавиши) — ее можно выставить до миллисекунды!

Звук и вибрация

Одни люди любят звуковые сигналы при каждом касании клавиши, другие их терпеть не могут, но все могут настроить параметры звука и вибрации при нажатии клавиш в разделе «Звук и вибрация» в настройках SwiftKey (доступ к которым можно получить, открыв приложение на своем устройстве и перейдя в раздел Набор > Звук и вибрация). Здесь можно выбрать громкость и продолжительность звуковых сигналов/вибрации, а также включить или отключить их.

Язык Apple Swift портировали на Andro >

На GitGub была опубликована первая версия языка программирования Swift, которая позволяет компилировать приложения для Android.

Авторы проекта отмечают, что пока версия не отличается стабильностью, но возможность создавать Swift-приложения для Зеленого робота открывает большие возможности для разработки кросс-платформенных программ.

Напомним, что Swift был представлен Apple на конференции WWDC 2014. Работа над ним велась 5 лет. В декабре Swift стал языком программирования с открытым кодом. Не исключено, что в скором будущем мы увидим Swift-приложения для других операционных систем.

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих