ТЛ; др; В разработке кроссплатформенных мобильных приложений есть большие возможности, в которых отсутствует Corona SDK. Чтобы решить эту проблему, Corona необходимо инвестировать в версию 3, набор мобильных компонентов / виджетов для конкретных ОС, компиляцию C # до Lua и инвестировать в надлежащую, официальную IDE.
Вступление
Если бы мне дали несколько миллионов долларов, чтобы превратить Corona SDK в то, чем, по моему мнению, он должен стать, вот что я бы сделал. В порядке приоритета я бы сфокусировался на создании библиотеки компонентов, создании более строгой схемы для текущего API в Lua и постоянном улучшении существующего рабочего процесса. Все 3 помогут повысить популярность Corona разработчиками, которые специально нацелены на «сначала мобильные устройства», увеличат желание тех, кто работает в агентствах, которые хотят иметь быстрый способ нацеливания на ОС с несколькими устройствами, и, что наиболее важно, расширят возможности Corona для быстрой итерации мобильных приложений. против существующего игрового фокуса.
Почему компоненты?
Существующая библиотека виджетов слишком мала, чтобы полностью удовлетворить потребности серьезных разработчиков мобильных приложений. Большая часть ответственности ложится на разработчиков, чтобы создавать компоненты Android и iOS с нуля. Для клиентов B2B это снижает возможности тех, кто предлагает быстрое решение для нескольких устройств, так как большая часть первоначального контракта Time & Materials должна быть посвящена созданию библиотеки компонентов, которая использовалась при разработке приложения. Это также усложняет оценку времени в фиксированной ставке, потому что вы в основном программируете компоненты YAGNI.стиль и слишком большой риск возлагаются на точные оценки времени разработки для разработки компонентов, которые клиент еще не видел. На этом этапе переход на нативную версию более привлекателен, поскольку в них уже есть эти компоненты, и тогда вас интересует только то, на какие устройства вы ориентируетесь и какая минимальная версия ОС.
Для компаний-производителей это также создает ряд проблем. Для тех, кто хочет перенести как можно больше работы на платформу, они не могут. Google создает компоненты для Android, Apple создает компоненты для iOS, а сторонние разработчики заполняют специализированные пробелы. Для Corona все 3 должны принадлежать только фактической компании, разрабатывающей продукт. Это значительное количество времени, затрачиваемое производственной компанией на создание необходимых инструментов для создания своего продукта, а не просто на создание своего продукта. Для тех, кто ищет быструю подачу своего продукта через мизерный прототип, это уменьшает их желание / быструю способность сделать это.
Долгосрочные прогнозы хуже, так как Google и Apple некоторое время будут поддерживать устаревшие компоненты, тогда как для небольших компаний это бремя обслуживания ложится на них, некоторые из которых они не могут поддерживать, не забирая уже ограниченные ресурсы из критически важных проектов. Поиск сторонних подрядчиков также сложнее для специализированной технологии со специализированным внедрением.
Зачем использовать Corona для создания мобильных приложений, если вы получаете компоненты iOS бесплатно и компоненты Android бесплатно, как с родной скоростью, так и с профессиональными инструментами?
Зачем использовать Corona для создания мобильных приложений, если вы можете просто использовать Twitter Bootstrap / jQuery mobile / Sencha Touch + PhoneGap и при этом сохранить немного повторного использования кода для мобильного веб-сайта и настольного веб-сайта?
Ключевым моментом здесь является «скорость». Библиотека компонентов разумного размера играет важную роль в обеспечении того, чтобы скорость стала реальностью для сервисных компаний, ориентированных на компании B2B и агентства, объединяющие мобильные приложения наряду с дополнительными предложениями.
Почему улучшения Lua API?
Непротиворечивый API прямо пропорционален кривой обучения, доверию разработчиков и масштабируемому росту SDK. Если API остается согласованным, разработчики могут изучить новые функции с меньшими усилиями. Это включает в себя существующую функциональность и новые функциональные возможности, добавленные позже. У многих разработчиков есть проблемы с доверием к коду, который они не написали, и по уважительной причине. Согласованный API делает его хорошо продуманным, и разработчик более склонен создавать стиль поверх API, если он согласован. Наконец, если вы создали API таким образом, что стиль позволяет добавлять новые и другие функциональные возможности, вы уменьшите нагрузку на своих разработчиков и на себя.
Корона в настоящее время составляет около 60%. Это более чем достаточно, но я думаю, что они могут сделать намного лучше.
Почему рабочий процесс?
Даже создатель Doom признает исключительную ценность безумно быстрого, простого и итеративного рабочего процесса Corona. Тем не менее, он не на 100% сплоченный, особенно когда вы объединяете Enterprise и работаете как с несколькими устройствами, так и с несколькими ОС через несколько баз кода с различными системами сборки.
Именно здесь «смерть тысячи порезов» можно превратить в «все мелочи, которые имеют значение». Ничего огромного здесь, только множество небольших улучшений, чтобы сделать все лучше.
Виджеты, Компоненты v3 и v4
Corona уже имеет библиотеку виджетов версии 2 . Это на Github, и вы можете добавить и раскошелиться на содержание своего сердца. Отчасти это было связано с тем, что Corona Labs владела им, они предоставили руководство по API, «съели свою собачью еду», чтобы помочь влиять на то, как ядро Corona API будет удовлетворять компонентам, и это, в свою очередь, помогло определить, как их пользователи создавали приложения. Было 3 основных проблемы.
Во-первых, компоненты недостаточно тщательны. Для создания приложений нам нужна настоящая библиотека компонентов ; многие из них позволяют нам легко удовлетворять требованиям для пользователей и пользователей Android и iOS . В то время как В2В не отражают пользователя, иногда это может быть жизнь или смерть для компаний-производителей. Кроме того, сборка компонентов, специфичных для ОС устройства или x-устройства, занимает много времени. С ориентацией на YAGNI это усложняет повторное использование в проектах для B2B. Как упоминалось ранее, это также накладывает бремя разработки и обеспечения качества на компании-производители.
Во-вторых, виджеты v2 все еще тестируются. Мы все нашли незначительные ошибки как визуальные, так и функциональные, и это нормально и нормально, но они должны быть не только на устройстве, но и на симуляторе. Различия между симуляторами Mac и Windows — это бремя для разработчиков. Не следует упускать из виду инженерные усилия, связанные только с симуляторами. Flash и HTML получили бесплатный билет, потому что движки времени выполнения были похожи на устройстве и на рабочем столе, тогда как нативные решения должны создавать его самостоятельно. У Google и Apple есть эпические ресурсы по сравнению с Corona Labs. Я считаю, что выделение ресурсов здесь не является чем-то легким, но когда разработчики тратят 60% своего дневного кодирования, 10% тестируют на реальных устройствах, остальные 30% занимаются просмотром / тестированием в симуляторе.Возложение бремени компенсации за различную функциональность между Mac и ПК может показаться более разумным, потому что быстрее выполнять итерацию / компенсацию в Lua по сравнению с нативным кодом … но это не работает в долгосрочной перспективе.
В-третьих, виджеты обязаны текущему API Corona. Существует множество событий и базовых классов жизненного цикла, необходимых для создания эффективной, абстрагированной библиотеки компонентов для разработчиков. Корона в настоящее время не имеет их. Вот почему я разбил дорожную карту компонентов на 2 этапа; тот же API, но разные внутренности. Один для текущей реализации, как Corona стоит сегодня, и один на основе будущих API-интерфейсов, которые я изложу более подробно в разделе улучшений Lua. Жизненный цикл компонента v4 не включен в эту эпическую статью, но если вы объедините предложения ECMA 6, модели событий, отличные от IE, и как можно более простые API-компоненты, включающие поддержку моделей, вы получите то, что вам нужно для событий жизненного цикла, что и в Corona. в настоящее время не имеет.
Виджеты v3
Текущая библиотека виджетов v2 хороша. Нам нужен полный v3, написанный с нуля, который поддерживает:
- общий API
- встроенные коллекции / модели
- модель общего события
- встроенная и абстрактная аннулирование
- сетевая / RPC оболочка
- полный набор визуальных компонентов графического интерфейса, x-device
- простая модель стиля, будь то CSS или код на основе
- набор служебных функций для разработки общего графического интерфейса пользователя (события, оформление коллекции, проверка полей, средства форматирования и т. д.), некоторые из которых исчезнут по мере создания собственных эквивалентов в будущем
- совместные усилия по созданию специально для ОС против 1 компонента, который адаптируется к ОС
- встроенная структура MVC
- модульные и функциональные тесты
Лично я не считаю, что v3 должен быть открытым исходным кодом, так как изначально это приводит к ненужным накладным расходам. Позже, когда он станет зрелым и v4 уже на горизонте, конечно. Однако сам фактический исходный код должен быть доступен для разработчиков для отладки, изучения и расширения.
Предполагается, что компоненты будут закодированы в синтаксисе модуля Lua 5.2, который обратно совместим с 5.1. Также предполагается, что как можно больше внутренних абстракций делается для обеспечения полной интеграции любых собственных API-интерфейсов в будущем (т. Е. Scale 9, встроенная аннулирование и т. Д.).
И, наконец, должен быть технический документ, описывающий лучшие практики кодирования компонентов, который уверенно утверждает, что это рекомендуемый способ кодирования Corona. Это посылает сообщение и помогает мягко коралловому населению разработчиков.
Общий API v3
Это влечет за собой стандартный способ взаимодействия с компонентами Corona SDK, поскольку все они соответствуют одним и тем же стандартам и соглашениям. Они задокументированы в белой книге.
Чтобы использовать компонент, следуйте синтаксису модуля Lua 5.2:
local WidgetClass = require "widgetsv3.WidgetClass" local instance = WidgetClass:new()
Соглашения высокого уровня включают методы установки и свойства получения. Учитывая существующий способ построения классов и модулей в Corona без сторонних библиотечных зависимостей, вы используете либо замыкания, либо метатаблицы . Я занимаю жесткую позицию в отношении метатаблиц. Это делает код более сложным для чтения и отслеживания, и излишне многословен для небольшого выигрыша.
Таким образом, способ получить свойства выглядит так:
-- get the value local theLabel = instance.label -- set the value local theAge = 21 theLabel = "Age: " .. tostring(theAge) instance:setLabel(theLabel)
Обратите внимание, что мы следуем точечному синтаксису для получения и двоеточию для установки, чтобы гарантировать, что область действия сохраняется.
Коллекции v3
Для поддержки коллекций, массивов, которые поддерживают фильтрацию, сортировку и изменение событий, соответствующих шаблону Observer , любой компонент, который поддерживает коллекции, также поддерживает тот же синтаксис get / set:
local Collection = require "widgetv3.model.Collection" local List = require "widgetv3.view.List" local people = Collection:new() local myList = myList:setCollection(people) local myListCollection = myList.collection
Дело в том, что люди: addItem (somePersonVO) автоматически обновит представление списка. Что приводит к…
Модель события v3
Существующая реализация событий в Corona и связанные виджеты великолепны. Тем не менее, есть 4 основных вопроса, которые необходимо решить в v3. Эти:
- добавление возможностей диспетчеризации событий в таблицы, которые не являются объектами отображения (addEventListener vs. onSomeCallback = someFunction)
- следуя строгой модели синтаксиса, чтобы добавить согласованность в слишком гибкий Lua
- поддержка встроенного всплытия событий для ненативных событий экранного объекта
- общий набор событий для встроенных общих, обычно используемых для обеспечения согласованного API
Для объектов без отображения, это легко (вроде), уже есть класс для него. Это обеспечивает один и тот же API как для v3, так и для v4, когда это реализовано изначально.
Для строгого синтаксиса, в основном для прослушивания событий:
myList:addEventListener("itemTouched", myListener)
Хотя функция в качестве прослушивателя является допустимым вторым аргументом, большинство из них будут таблицами, если вы будете следовать рекомендациям Белой книги о синтаксисе кодирования. Нет больше слушателя в конструкторе, как v2:
local tableView = widget.newTableView
{
top = 100,
width = 320,
height = 366,
maskFile = "assets/mask-320x366.png",
listener = tableViewListener,
onRowRender = onRowRender,
onRowTouch = onRowTouch,
}
Вместо этого вы просто слушали бы это:
tableView:addEventListener("onRowRender", myListener)
Это включает в себя именование событий; v3 будет использовать «rowRender» против «onRowRender». Это будет соответствовать всем событиям, как собственным, так и компонентным
То же самое касается событий в стиле «обратного вызова», таких как transition.to, который позволяет передавать функцию / таблицу обратного вызова для каждого возвращаемого экземпляра анимации (* ahem *… «id», а не экземпляра). Такая функциональность / синтаксис исчез. Вместо этого вы снова идете:
myTween:addEventListener("onComplete", myListener)
Вы заметите, что в настоящее время переход не поддерживает такого рода API, и при этом переход не возвращает конкретные экземпляры анимации. Вместо этого он управляет внутренними данными и просто предоставляет числовые идентификаторы, с помощью которых вы можете по желанию отслеживать своих собственных подростков и отменять их. Именно здесь часть уровня компонента должна абстрагировать существующий Lua API как для простоты использования, так и для надежды на то, что когда произойдут некоторые изменения в собственном Lua API, компонентный API останется прежним, но производительность улучшится.
Network.setStatusListener имеет тот же синтаксис, чтобы дать краткий и простой способ быстрой проверки доступности нескольких URL. Новый синтаксис, опять же, будет соответствовать стандарту:
local myListener = function(event)
print("reachable:", event.isReachable)
end
network.addEventListener("networkStatus", myListener)
Это также помогает предотвратить еще один способ добавления и удаления прослушивателей событий.
Другой пример включает в себя графику Scale 9 и Scale 3, где вы разрезаете изображение кнопки на 9 частей, чтобы оно могло масштабироваться по вертикали и горизонтали, оставаясь при этом красивым. В настоящее время существует значительный объем накладных расходов, когда Lua делает это по сравнению с исходной обработкой. Если вы сохраняете API и рабочий процесс одинаковыми, переход v4 для тех, кто хочет обновить свои приложения, должен быть плавным … или, по крайней мере, не очень болезненным.
Пузырьки событий уже имеют место для многих событий Corona, включая касание, касание и столкновения. Фактически, разработчик должен остановить распространение специально для визуальной иерархии касания / касания и для распространения столкновений между физическими объектами. Тем не менее, есть 2 проблемы, когда разработчик хочет сделать это самостоятельно.
Во-первых, они должны вручную создавать собственные пользовательские события, даже если они отправляются из класса экранного объекта. Во-вторых, они должны нацелить повторное получение информации о том, на какой стадии процесса барботирования происходит событие.
Честно говоря, меня не волнует эта вторая часть, но она не совсем соответствует стандарту ECMA для всплытия событий. Да, я тут спрятал ссылку на стандарт сценариев ECMA … мы вернемся к этому позже, когда будем использовать ECMA 6 в качестве возможной реализации языка v4 по сравнению с компиляцией C # до Lua … что, если вы знаете что-нибудь о C #, имеет свой собственный способ модели событий. Дело в том, что фреймворк в настоящее время эмулирует его до тех пор, пока нативный API не сможет его обработать или предложить альтернативу.
Наконец, стандартные события должны быть реализованы для всех компонентов, чтобы обеспечить общий API. Например, когда компонент отображается и скрывается, когда он создается впервые и когда он собирается быть уничтоженным. Эти события жизненного цикла имеют решающее значение для больших компонентов, совместно используемых через композицию. Сюда также входят «прикосновение», «изменение» и т. Д.
v3 Недействительность
Я много говорил о недействительности в прошлом, но для тех из вас, кто не знаком с этой концепцией, я немного объясню, как она работает и как она влияет на текущую предлагаемую реализацию для v3 в Lua.
Во-первых, Корона по большей части рисует один раз за кадр. Это означает, что если вы делаете это:
myCircle.y = 100 myCircle.y = 200 myCircle.y = 300
Вы ТОЛЬКО увидите, что круг появляется в любой позиции 300. Это потому, что Corona рисует один раз за кадр, основываясь на текущей частоте кадров вашего приложения (которая составляет 30 или 60). Это означает, что вы можете рисовать от 30 до 60 раз в секунду.
Это и оптимизация, и особенность; Corona берет «последние» преобразованные визуальные свойства, если таковые имеются, и выводит их на экран. Это безумно сложный процесс, сводящийся к одному предложению. Это здорово, Корона делает это. Они могут сделать некоторые из своих собственных недействительных внутри для обработки кода, как указано выше.
Однако компоненты часто выполняют более сложное рисование, чем простое перемещение, изменяя свойства x и y. Кнопка изменит текстовую метку, элемент управления списком перерисовает строку, или for может показать / скрыть раздел содержимого на основе текущего состояния данных, которые редактирует пользователь. Эти изменения будут распространяться; это означает, что форма будет перемещать контейнер, который, в свою очередь, создает дополнительную компоновку для элемента, содержащего метку и ввод текста, что, в свою очередь, переоценивает его внутренности на основе абстрагирования полей собственного текста, которые не существуют в группах Corona… и т. д.
Как вы можете видеть, в более крупных приложениях важно убедиться, что мы не выполняем кучу кода перемещения, изменения размера, измерения или перерисовки более одного раза за кадр, иначе это бессмысленно. Когда у вас есть 3 компонента, хорошо. Когда у вас есть 60, каждая из них запускает 3 сложные схемы компоновки / перерисовки, когда на самом деле отображается только последняя … это проблема производительности И разработка API. Есть редкие случаи, когда вам нужно вызвать перерисовку для целей измерения, и это нормально.
Инвалидация исправляет это. Или, по крайней мере, уменьшает ущерб с точки зрения масштабируемости.
Есть еще две вещи, которые помогают сделать недействительными, это условия гонки и порядок ошибок в работе. Я собрал их вместе, потому что для компонентов GUI они часто связаны
Например, элемент управления List (другое имя для TableView ) может иметь 2 свойства, которые вы можете установить, которые влияют на то, как рисуется список, collection и rowCount (сколько строк показано / нарисовано). Предполагая, что вы знаете, как работает список, вы идете:
myList:setCollection(myBigOleCollection) myList:setRowCount(4)
Теперь, внутренне, вы могли бы подумать, что список сначала настроится сам во внутреннем конструкторе, отрисовывает содержимое списка после получения набора сбора и, наконец, перерисовывает или маскирует себя, чтобы соответствовать новому значению rowCount.
… но что, если вы пошли:
myList:setRowCount(4) myList:setCollection(myBigOleCollection)
Без аннулирования это может либо привести к сбою, либо запустить какой-то сложный внутренний код, который не будет хорошо масштабироваться.
С аннулированием он будет работать и хорошо масштабироваться.
Invalidation в основном устанавливает данные немедленно, но фактически не рисует их до 1 кадра позже.
На данный момент, аннулирование будет следовать стандарту, которому следуют Flash и Flex :
- «Свойства» определяются как методы получения / установки. Они устанавливают внутреннее свойство с тем же именем с префиксом подчеркивания.
- Они также устанавливают грязный флаг в true и вызывают «invalidateProperties»
- invalidateProperties добавляет прослушиватель для enterFrame.
- Через 1 кадр слушатель удаляется и запускается commitProperties.
- commitProperties проверяет все грязные флаги, установленные на true, и применяет их в том порядке, в котором разработчик считает нужным.
- Если грязный флаг уже установлен в true, повторный вызов установщика просто обновляет значение, это фактически не влияет на перерисовку, если разработчик не захочет переопределить это поведение.
Использование enterFrame гарантирует, что мы будем когда-либо вызывать commitProperties только один раз за кадр, и, таким образом, все компоненты будут когда-либо рисовать только один раз за кадр, если разработчик не нуждается в этом специально для целей измерения. В свою очередь, эти изменения могут распространяться на дочерние компоненты, гарантируя, что перерисовка композиции работает как задумано.
Это действительно сложно с ускорением GPU и встроенными маскирующими способностями класса Container , поэтому, что касается v3, предполагается, что разработчик будет делать как можно меньше композиции в отношении массового / частого перерисовывания.
Invalidation только для элементов управления на основе графического интерфейса.
Я включил 2 Gist-файла, которые показывают базовый класс Component без каких-либо ограничений по размеру (ширина и высота + маскировка контейнера + абстракция измерения выходят за рамки этой статьи) и обертку TextField с именем AutoSizeText, которая использует компонент (отсутствие текстового поля пулирование объектов также выходит за рамки этой статьи, сейчас остановимся только на setText).
RPC библиотека
Библиотека network 2.0 великолепна и сохраняет тот же API, что и v1. Однако даже при таком высоком уровне абстракции все еще довольно просто с точки зрения поддержки общего кода, написанного клиентскими разработчиками, использующими веб-службы на основе REST. Разработчики , работающие сиденья концов назад ожидать чего — то , по крайней мере вдоль линий какого AmplifyJS или JQuery или даже предложения Flex SDK с относительно библиотеки удаленного вызова процедуры. Заимствование идей из iOS CoreData , Flex SDK и внутренних компонентов модели Backbone помогает дать вам общее представление о том, с чем приходится сталкиваться разработчику.
Это включает:
- кодировщики для сериализации общих запросов в JSON, XML и обычный REST в дополнение к существующей текстовой и двоичной поддержке (автоматический анализ таблиц Lua в правильном формате для отправки по проводам)
- декодеры для десериализации общих ответов из JSON, XML, REST и простого текста в дополнение к существующей текстовой и двоичной поддержке (автоматический анализ текста / двоичных данных в таблицах Lua, отправленных по проводам)
- настраиваемая обработка ошибок вокруг декодеров, которая добавляет к существующей обработке event.isError и timeout
- поддержка конфигурации параллелизма вокруг существующего идентификатора сети: множественный, первый и последний. (например: если задано значение «последний», и вы делаете 5 запросов HTTP на одну и ту же службу, первые 4 будут отменены).
- общие «результат» и «ошибка» события против 1, которые разработчик должен разобрать. Они отправляются из конкретного экземпляра операции, если разработчик не использует RestService по умолчанию.
Это не малое недоразумение, но в значительной степени является основой любого приложения, которое работает с несколькими веб-службами REST, даже в режиме только для чтения.
Дополнительные виджеты
Библиотека Widgets v2 имела философию о ядре, полезных компонентах, которые позволяют разработчикам использовать их для более сложных компонентов для каждой ОС устройства, а остальные они могут создавать самостоятельно.
v3 занимает позицию разработчика, чтобы дать нулевую причину создавать компоненты устройства с нуля. Вместо этого они должны сосредоточиться на композиции; т. е. «построение их приложения». Чтобы оптимизировать разработку, это также означает, что больше нет гибких компонентов «1 размер подходит всем». Это также означает, что компоненты должны быть разделены не только по устройствам, но и по типу и рынку, таким как Стол против телефона, Kindle против Nexus 7 и т. Д. Процесс должен быть довольно итеративным, чтобы помочь определить компоненты строящееся здание актуально для тех проектов, которые не просто строятся, а «разбиваются». Помните, что более крупные клиенты говорят, что они заботятся о дизайне, но это не так; в конце концов, стандартные компоненты, поставляемые Corona, достаточно хороши.
Эта последняя часть важна по двум причинам. Наличие среднего и младшего разработчика, способного макетировать работающие «прототипы» для отделов продаж, чтобы помочь быстро продать свои идеи, приводит к проблеме «прототип — продукт» для разработчиков. Скажите, что вы хотите, но из-за этого отдел продаж получил продажу. Это, в свою очередь, помогает сделать Corona надежной платформой для продаж и развития.
Вторая причина заключается в том, что разработчики, создающие пользовательские компоненты, имеют возможность внести свой вклад. Опять же, я не чувствую, что открытые источники v3 разумны, и при этом я не верю, что у Corona Labs есть ресурсы для управления такими усилиями. Суть в том, чтобы предоставить разработчикам API базовых компонентов, чтобы они могли следовать им, чтобы они в лучшем случае предлагали его в качестве запроса на извлечение в репозитории Github или, по крайней мере, в блоге об этом, и другие МОГУТ использовать его в своих проектах Corona и воспроизводить этот код. хорошо со стандартными вещами.
Существующая структура скинов v2 была великолепна, но чтобы уменьшить нагрузку на разработчиков и разработчиков компонентов в Corona, она должна быть закодирована для конкретной ОС, на которую они ориентированы.
НЕКОТОРАЯ форма стилей должна быть реализована. Мне также не нравится использовать CSS, когда скининга достаточно для 90% неагентских проектов, но для тех разработчиков, которые хотят просто изменить шрифт, значок и цвет, вы не можете превзойти скорость и полезность стилей на основе CSS. Да, я понимаю, что это добавляет значительный объем работы, но, опять же, мы нацеливаемся на импульс платформы здесь, в v3, чтобы помочь получить обратную связь, поддержка является приоритетом. Таргетинг — это герундия, какого черта у него всего 1 т?
коммунальные услуги
Ни один компонентный фреймворк не обходится без набора утилит. Сюда входят средства форматирования, валидаторы (которые могут использоваться как на уровне графического интерфейса, так и на уровне модели), внешнее кэширование и локальное хранилище. Хотя большинство из них абстрагированы в соответствующем слое (например, валидаторы), все же целесообразно представить их разработчику по нескольким причинам, а именно: их продуктивность, настраиваемая интеграция и облегчение интеграции Corona Labs в компоненты, если они проектируют актуальный API.
These are also the opportune area to take a lead role in abstracting away POTENTIAL (yes, potential, not ensured) future features. For example, abstracting away 9 scale and 3 scale graphics makes it easier to port and/or learn future API’s when it’s made native. Same goes for Bitwise operators, certain API’s that’ll turn into native plugins, and a variety of API’s I’d personally have to organize some of the disparate device querying API’s like system vs. native.
Built in MVC
If you want to create an experimental application framework for the sake of learning how, what, and why users are building with your tech with room to pivot/iterate later one, you release a component set. If you already know and just want them to succeed on larger endeavors, you do the same but include an MVC framework along side it. There are pro’s and con’s to each approach.
The cons to the component-only approach are people don’t take it seriously for larger scale development, it’s harder to sell to potential clients who have ornery W2 space cadet architects at some larger enterprise, and you tend to attract less B2B clients. This last point is because most service companies let their clients usually dictate the tech. The pro’s, however, are you get a lot of flexibility to setting your next direction. Users always surprise you, and component directions can be widely different on your next iteration (somewhat like Widgets v1 and v2 are now). Additionally, you have a quicker time to market since you’re just focusing on a set of widgets, each delivered on a particular milestone release. You don’t have to release them all at once. Finally, those tinkerers you do attract the are the most likely to give you valuable feedback and experiment a lot with your tech.
The cons to the bundling of an MVC framework with associated classes is you’ll have a smaller market at first using it. These are typically a specific demographic, those building larger applications for media companies, but more usually banks, healthcare, and insurance. You also have to have a TON more man power for an initiative that doesn’t include engineers. You have to include a sales person alongside a sales engineer. At first they can handle a few clients, but eventually, they’ll be spending most of their time with 1 or 2. You’ll then need some consultants to help implementation prototypes or help an existing team solve initial development challenges. They’ll usually be one unit with the 2 sales reps… next thing you know you have 3 such teams, each consisting of 4 people. This is not a scalable business model for a product company and yet it’s integral to get to that milestone of tech validity.
The other con is you exclude a segment of your market place who don’t “get it”. I feel like Sencha has done a really good job here; you’ll have some of their users using a few components while others adopt the entire stack. The challenge to solve is how you market it, and how your evangelists balance those 2 demographics in their engagement.
Finally, the other con is time to market is significantly slowed. Everything is integrated and needs supporting classes. It’s a ton of code some of which may be temporary so you really need to spend the time architecting it right, iterating, and getting a close knit set of private alpha testers to provide feedback.
The pro’s, and hence the part of the point of this article, is that people can build scaleable applications on your tech right out of the gate and the larger companies take it seriously. The other pro is, you’ll start attracting those who don’t agree with your MVC philosophy or they do, but it’s not good for their consulting business, so they build their own MVC framework. Both of these help validate your tech in the market place, as well as help sell it.
I have one I’ve started, but naturally I’d prefer if Corona did some market research to determine where on the MVC spectrum their customers lay so one could be built specifically for that market segment right out of the gate and let 3rd parties do their own flavors on top/alongside.
Unit and Functional Tests
I’ve read that Corona has their own unit testing suite internally, which is great. For components, however, it needs to be public for a few reasons. First, so architects take it seriously. Second, for those who build/extend/modify the framework into their own Continuous Integration environments. Third, for the opportunity that the community can potentially find and fix missing/broken tests and add relevant ones as well as keep the existing ones up to date.
I don’t believe functional testing is required, BUT it would be a huge precedent in a later milestone release. Some of the larger automated testing tools like SmartBear, QT, and others that could integrate with the framework. You have to build this testability into the framework, more so than just making it unit testable. It’s a huge endeavor.
Component Conclusions
That handles the introductory component plan. Remember, v3 is an iteration on the existing Widget v2, but with a specific OS focus. The v4 is simply an iteration on top of v3′s foundation to provide a stepping stone for those developer evangelists in v3 to showcase v4. V4 runs atop the Lua and Workflow improvements mentioned below. The hope is the philosophy will be the same, as the API, but taking full advantage of improved native and Lua API’s to provide a more robust component framework. There isn’t really a need to cover v4 in detail because once you get v3, and see where Lua should go, you’ll see v4 is just a component framework with built in MVC on top of an improved/iterated Corona platform.
Why V4: To compete with native implementations from a cost perspective.
Isn’t that what Corona already provides? Not for larger application development, no.
Lua Improvements
There 2 main Lua improvements that have to happen in order for v3 to take off, for a good designer/developer workflow to flourish, and for a v4 to even happen. These are:
- API consistency
- More robust programming language
Without these, you’ll have continued slow growth, and lack of serious community investment to more serious application development atop Corona.
API Consistency
For the current incarnation of Lua, whether this is 5.1 or 5.2, many of the API consistency issues I’ve already mentioned above such as event syntax, but other things like a display.newLine’s stroke width using the “width” property whereas a display.newRect’s stroke width being a strokeWidth property.
The Corona team needs to take a breather, and do an architectural review from an API consistency perspective on their current SDK. Next, they need to publish these naming rules for those building atop it in the form of a white paper. This includes their native plugins. This can simply be a dot release, such as 2.1.
Lua’s actually worse than JavaScript with regards to “everyone doing their own thing”, which is remedied by taking a stand and dictating the standards.
Another Language?
The battle for robust vs. light, strong-typing vs. variant, etc. will continue to rage. Regardless of your opinions and inferences, the facts are those building applications in the Enterprise use robust languages to do so. While many use Python and Ruby and PHP just fine, if you want the guys who make the big money to invest in building mobile applications atop Corona SDK, and thus justifying to investors while you’re spending tons of your money on this break from the gaming philosophy that has primarily driven Corona SDK so far, you need some quarterly profits to show. You get those profits by providing an SDK people will actually use.
For those company demographics, Lua is not the gateway language to use. That’s Java, or even C#.
Reflection and Dependency Injection
A short note on reflection API’s. Right now, Lua’s support for language metadata is pretty horrible. Even if you stick with Lua 5.1, attempting to do runtime Dependency Injection is pretty miserable. The package API’s were some kind of attempt that seems… unfinished? 5.2 doesn’t make it any better. You basically have to find a lexical parser to do runtime parsing of classes at runtime to handle the injection of dependencies with some convention on constructors. I only bring this up because if you say, “Of COURSE our platform supports Inversion of Control!”, you immediately set a lot of Enterprise Java devs mind at ease.
Interpreter Challenges
Beyond the obvious advantage of Lua’s ease of integration with a variety of hardware and native code which forms the crux of Corona SDK’s value for mobile, you can’t easily just swap that out with another language.
You have 2 options here. The first is to bite the bullet, and pick one that provides a long term gain, such as Unity did with C#. The problem with Java & Objective C is that segments a market. You imply you can “build cross platform apps using Objective C vs. just 1″, but that masks really what Corona does, both good and bad. So those 2 languages are out. While C# certainly appeals to the gaming & Microsoft crowd, the Microsoft realm already has mobile solutions with their existing platforms, with a heavy Windows Phone bent.
The other option is create or use existing cross compilers so developers can use more robust languages, but still compile to Lua in the background. This significantly lessens the engineering effort, but increases the communication & leadership requirements around the workflow initiative. Someone has to keep in sync the tooling, the existing SDK features, all the while trying to drive the language philosophy IN FRONT OF those initiatives vs. behind. Rails was built on TOP OF Ruby, just like Django; those frameworks espouse the good in those languages. Without the language being fully baked, you have a starting timeline problem even on Day 1.
Worse, it could be incremental. Examples of those are TypeScript, CoffeeScript, ActionScript 2. ActionScript 2 was created in response to ActionScript 1 not being application developer friendly enough. It fixed a few things in the ECMA Script based language, notably JavaScript’s lack of super, but at the end of the day, still compiled down to a JavaScript ‘esque prototype based language. All compile time checking was runtime based, all classes, like TypeScript does as well, compiled to prototype based implementations for performance reasons (vs. closures), and all packages were name space based. AS2 effectively “bought” time for Macromedia to make ActionScript 3, the ideal (at the time anyway, before Haxe) ECMAScript 6 (known as 4 at the time, heh) based language. This satisfied those ornery, OOP craving Java Developers.
CoffeeScript sought to solve the lack of proper package, class, and built-in scope support for JavaScript. The lack of strong-typing and tooling really makes CoffeeScript less than ideal for those wishing for more support.
…which is what TypeScript satisfies AS WELL AS making ECMA Script 6 easier to use, today, vs. using Google’s Tracer compiler. The problem with TypeScript is that, currently, the only tooling support of significance is in (surprise surprise) Visual Studio.
All of those languages open up problems with “why not just code native JavaScript?”. It’s a good point. Many large scale Sencha applications (most behind a firewall, lulz) are proof you CAN develop large scale, client-side applications, but the point here is SHOULD you? I mention client side since technically, for GUI reasons, client side code can be quite verbose to API style server-side offerings. If your code base is large, and science shows less lines of code is better, what is the happy medium?
Lua already cross compiles, but lacks the OOP constructs we need. No, Lua 5.2′s de-facto module approach is not enough.
One strategy could be have C# compile to Lua, another could be to just pivot and starting using C#. I don’t know enough about the current Lua community demographics to give an effective suggestion, but my gut says just use C# compiling down to Lua for v3 until v4 can be fully baked with it… or not. There are native speed ramifications that C# can offer, but the engineering effort is quite profound. :: flips a coin ::
Bottom line, Lua ain’t it, Java or C# is. ECMA 6 is out merely because it has a web bent. Corona, currently, doesn’t need the web developer demographic. Yes, sharing libraries and having Agencies whipping out cross compiled applications using Corona SDK vs. Appcelerator is great for initial growth and platform relevancy & validation since Agencies are first movers, but that’s not the demographic we want. We want B2B consultancies and software shops. They ain’t going to jive with this Lua nonsense when building larger initiatives.
Workflow
The workflow support, right now, is pretty harsh. My ghetto setup with Sublime and my colleagues support in testing various other implementations randomly found on Github is an indication of how much work there is to do.
Specifically, 3 things need to happen:
- We need an official IDE.
- We need v3 and v4 Components to default to the viewport style scaling for applications.
- We need on-device debugging.
IDE
I don’t care what is chosen; Eclipse, IntelliJ, or even Sublime. Bottom line, we need intellisense & code hinting/completion for both productivity and teaching the API, the ability to set breakpoints and step through code (even just forward as opposed to Lua Glider’s backwards ability), and package/class/refactoring support. This includes the IDE’s ability to know what a class is so when we refactor it, it can change it, not just some “move” option. IntelliJ’s a good example for this, but ultimately anything that even copies 10% of Visual Studio is a win.
This includes v3 and/or v4 API’s. If a cross compilation is chosen, it needs to implement source maps to ensure the compiled code can re-map back to the the development code.
I personally prefer IntelliJ, but it’s slow as all get out on Mac. Eclipse is a stamp of acceptance from large companies, so I’d reluctantly recommend it since you’d at least be immediately perceived as wearing a collared shirt and tie to get into the exclusive enterprise club from a development standpoint. This also spits in the face of the “immediacy” philosophy that Corona SDK currently has, so… I’ll just sit by and let Corona make the hard choices while I critique from afar.
Viewport
A quick note on Viewports. The existing Viewport options in Corona are confusing, and I’d argue all applications, not games, only need 1 option that can be a standard config.lua provided to all (yes, ALL) Corona SDK applications. They should draw to the size they have and allow Corona SDK to scale up based on the existing DPI.
Right now this topic is kind of “flexible” because each game is created differently, for different devices. Apps are not. There is a reason why responsive design took off in the web world: because it works both from a technical perspective, and from a business one. The implementation details are tons easier on Corona SDK, however, and this ability should be capitalized on by further making it more simple: unknown to the developer so they only care about the DPI they are targeting, period.
The existing Corona graphic support of high rez is great, it just needs supplementation with v3 abstracting this away, and the developers responsible for their own form/composition component layouts. To be clear, I’m not suggestion a point based system like iOS does, simply defaulting config.lua to a letterbox scale, a specific device size, and the v3 components will handle detecting the API unless one is set in the config.lua so it can scale accordingly.
The IDE should code gen this for you; developers should NOT be messing with this beyond project setup. Obviously it’d be nice to have more support in the simulator to know what DPI you’re really looking at. The amount of current Stage properties regarding with, height, and scaling are indicative of the current problem we have. Moai style exposure of lower level size constructs are NOT a good thing and this is not congruent with Corona SDK’s ease of use & development speed philosophy.
On Device Debugging
Not much to say here. The use case is I set a break point in the IDE, hit run, it launches on my connected device, and the IDE pauses the runtime on the current break point I set in the code. I can then step through the code and see the variable values.
Conclusions
As you can see, the above is a ton of work, and a multi-year initiative even assuming the capital investment is there. The justification is that the mobile industry has billions in growth, and with the death of Adobe AIR (death by no one caring because of Adobe’s “doubling down” on HTML5 vs. Flash in case I get ravaged in the comments), Corona is ripe to leverage it’s cross platform development and deployment runtime + growing plugin market place to really make some serious growth here.
One thing working with Corona the past 2 years has taught me is that there is always more to learn about our industry, not just by using another technical stack, but also another market segment at the same time, in this case gaming. In doing so, I’ve met a lot of new people who’ve taught me a lot I didn’t know about how products in this vertical work. Given that companies like EA have adopted Corona Enterprise as a vehicle for some of their offerings, it’d be strange to see Corona pivot and go enterprise app dev, opposite of the path Adobe took with the Flash platform. That said, the ground work is there, you just need 3 years, more investment, hard work… and some luck.
Speaking of which, I’ve spent over 2 years having fun with Corona in a hobby capacity, and haven’t made any money on a platform I’ve invested so much time. I don’t mind since it’s been purely a hobby, fun, and a way to get out of my comfort zone (ie game dev vs. application dev). That said, this is not rose colored glasses talk. There is a great opportunity here, and I believe in the platform solving these mobile development problems. Companies are using the HTML stack on top of PhoneGap because they have to, not because they want to. That, and the innovation is going way too slowly for what we need. The simplicity of Corona combined with some API improvements, a solid component set, and a reasonable IDE are all we need, the above is just the ideal. This won’t supplant the existing competition; we’re already in a red ocean here. It WILL however, really create a lot of great opportunities for those wishing to build mobile applications faster and easier.
If you agree with the above, bring the ruckus on the Corona forums. Let ‘em know this is valuable to what your company is building, wants to build… or is the complete opposite of what you believe Corona should focus on.