Поиск работы осень 2012 года Bay Area

[Интеррапт]

Да и даже для контор, у которых с ресурсами все в порядке - тоже может пригодиться. На титаниуме уже десятки тысяч приложений написано, включая большие бренды, как EBay, PayPal, NBC и еще много кто.

Преимущества понятны. Понятно, почему вышеприведенные конторы их используют. Однако, опять же, как и ты сам знаешь, high profile приложения сначала появляются на витрине phonegap и titanium, а потом оттуда исчезают тихо. Ну когда элементарный listview с маленькими webviews начинает рендериться в стиле slideshow, то ограничение достигается очень быстро. И таких мин там до фига.

Phonegap - возможно. Titanium - это полностью (100%) нэйтивный UI/UX.

[dotcom]

Phonegap - возможно. Titanium - это полностью (100%) нэйтивный UI/UX.

Ну да, замечательно. Даже нативный код можно превратить в вермишель и тормозить будет получше чистого JS/HTML. Только шаг в сторону в виде элементарного pull-to-refresh превращается в геморой. У меня один разработчик попробовал сделать пример... Оказалось, что в версии titanium'а, которую он скачал, пример уже не работает, а как поправить никто не знает, прикрутить нативные Android-PullToRefresh и PullToRefresh от Twitter'а было забавой, которую он за один не хотел осилить. Я вон на андроидный компонент три дня убил, пока нашел багу с overscrolling'ом у автора. Представляю, как бы я ее искал в Titanium. Это ж был бы ахтунг-капут перед релизом.

[АццкоМото]

Тот же Титаниум - это не закос под нейтивное. Это самое настоящее нейтивное UI где программирование идет через JavaScript и сопутствующие технологии и никак ты не отличишь это от приложения написаного на Android/Java или iOS/Objective-C. В качестве примера Титаниум приложения:

Если аппа написана под одну платформу (и нафига тогда???), то, может, и не отличу. Но, поскольку подход к проектированию интерфейсов совершенно разный у андроида и айос, у кроссплатформенных приложений уши торчат

Пример фейсбука не в тему, они фактически сделали веб контейнер, в котором грузили мобильный веб сайт. Решение для конторы, у которой хватает ресурсов все сделать нейтивно - изначально было очень странное.

Да все это из одной области, по большому счету

[Интеррапт]

Только шаг в сторону в виде элементарного pull-to-refresh превращается в геморой. У меня один разработчик попробовал сделать пример... Оказалось, что в версии titanium'а, которую он скачал, пример уже не работает, а как поправить никто не знает, прикрутить нативные Android-PullToRefresh и PullToRefresh от Twitter'а было забавой, которую он за один не хотел осилить. Я вон на андроидный компонент три дня убил, пока нашел багу с overscrolling'ом у автора. Представляю, как бы я ее искал в Titanium. Это ж был бы ахтунг-капут перед релизом.

Ну нечего менять версию SDK перед релизом. И тем более добавлять новые фичи (типа того же pull-to-refresh) в приложение перед релизом
Никто не спорит, что косяки бывают, особенно если брать чей-то код (вроде того же pull-to-refresh). Платформа молодая довольно, но неплохо развивается. Версия 3.0 (с Alloy) которая недавно вышла - очень даже неплохой продукт.

[АццкоМото]

А я использовал/использую Titanium (наряду с другими инструментами) и из профессии никуда не тороплюсь

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

[dotcom]

Ну нечего менять версию SDK перед релизом. И тем более добавлять новые фичи (типа того же pull-to-refresh) в приложение перед релизом

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

Никто не спорит, что косяки бывают, особенно если брать чей-то код (вроде того же pull-to-refresh). Платформа молодая довольно, но неплохо развивается. Версия 3.0 (с Alloy) которая недавно вышла - очень даже неплохой продукт.

Надо будет посмотреть, что они там наваяли. Они вроде поддерживают Win и BB тоже. К слову, когда уже есть codebase, то идти в обратную сторону к подобным framework'ам еще дороже, чем поддерживать существующее, даже если framework подходит и обещает иметь одну базу под все платформы.

[Интеррапт]

Если аппа написана под одну платформу (и нафига тогда???), то, может, и не отличу.

Там JavaScript компилируется при помощи V8 и зовет родные (для данной OS) компоненты. Т.е. для iOS будет вызываться UIButton для отрисовки кнопки, для Андроида - android.widget.Button и т.п.

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

И да и нет. Они там сделали такую вещь - вся логика (логика приложения, обработка событий от UI и т.п.) - platform-independent (на JavaScript). Интерфейс можешь делать декларативно (через XML, но можешь и руками через код) и, если нужно (а это правильней всего) - создавать разные XML для разных платформ, конфигураций и т.п. (типа как в Андроиде ты можешь разносить ресурсы в зависимости от конфигурации телефона, но в данном случае еще дополнительно можно в зависимости от OS разносить). Ес-но можно и другие ресурсы (картинки, например) добавлять в платформенные директории. Иной раз конечно приходится вставлять и платформенно-зависимый код, но подавляющая часть приложения - платформо-независимая.

[Интеррапт]

Вот так и знал, что ты обидишься.

Не выдумывай

Кстати, ладно еще JavaScript. А вот если с Corona SDK работать (а это архи-популярная платформа для разработчиков игр под мобилки), то там вообще нужно на LUA писать.

[АццкоМото]

Там JavaScript компилируется при помощи V8 и зовет родные (для данной OS) компоненты. Т.е. для iOS будет вызываться UIButton для отрисовки кнопки, для Андроида - android.widget.Button и т.п.

Да это-то понятно, кнопка - она и в Африке кнопка. А если ActionBar или там ViewPager? Я уж не говорю про какой-нибудь ActionSherlock (или как там он зовется - очень полезная хрень)

И да и нет. Они там сделали такую вещь - вся логика (логика приложения, обработка событий от UI и т.п.) - platform-independent (на JavaScript). Интерфейс можешь делать декларативно (через XML, но можешь и руками через код) и, если нужно (а это правильней всего) - создавать разные XML для разных платформ, конфигураций и т.п. (типа как в Андроиде ты можешь разносить ресурсы в зависимости от конфигурации телефона, но в данном случае еще дополнительно можно в зависимости от OS разносить). Ес-но можно и другие ресурсы (картинки, например) добавлять в платформенные директории. Иной раз конечно приходится вставлять и платформенно-зависимый код, но подавляющая часть приложения - платформо-независимая.

Что-то мне кажется, если приложение такого рода, что в нем одна кнопка "Горшочек, вари", по нажатию которой запускаются патентованные алгоритмы, выдающие после восьмисекундного напряжения всех 4х ядер ответ "42" или "сегодня меняй драхмы на тугрики, а тугрики - на динары", то оно имеет смысл. А так... ну какая там логика в типичном приложении? Смех один

[АццкоМото]

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

Ну, геймдев для меня вообще терра инкогнита. Я даже слов таких не знал

[dotcom]

Кстати, ладно еще JavaScript. А вот если с Corona SDK работать (а это архи-популярная платформа для разработчиков игр под мобилки), то там вообще нужно на LUA писать.

Ну так Lua проще Javascript'а то. А если сравнивать V8 и LuaJIT, то первый будет нервно курить в сторонке.

[Интеррапт]

А если ActionBar

http://docs.appcelerator.com/titanium/l ... .ActionBar

или там ViewPager?

Идешь на appcelerator marketplace и забираешь оттуда модуль с ViewPager
https://marketplace.appcelerator.com/ap ... ?697822035

А так... ну какая там логика в типичном приложении? Смех один

Ну если в приложении действительно нет логики и это Hello World в UI исполнении, то тогда действительно не будет проблем портить с одной платформы на другую без всяких Титаниумов.

[АццкоМото]

А если ActionBar

http://docs.appcelerator.com/titanium/l ... .ActionBar

или там ViewPager?

Идешь на appcelerator marketplace и забираешь оттуда модуль с ViewPager
https://marketplace.appcelerator.com/ap ... ?697822035

U R totally missing Z point Я догадываюсь, что ими можно пользоваться. Но ты изначально говорил: вот кнопка, она замаппится на UIButton в iOS и в android.widget.Button в ондроеде. Соответственно, вопрос: куда будет маппиться ActionBar & ViewPager в iOS?

А так... ну какая там логика в типичном приложении? Смех один

Ну если в приложении действительно нет логики и это Hello World в UI исполнении, то тогда действительно не будет проблем портить с одной платформы на другую без всяких Титаниумов.

Ну а где логика есть? Ну там в браузере, в мыле (мыло и то сомнительно). Возможно, в некоторых игрушках. Даже во всяких фейсбуках-гуглоплюсах логики ноль. Нажали кнопку (или получили пуш)-послали запрос-получили ответ-отобразили как-то. Не считать же это какой-то особой логикой, отделенной от UI/UX?

[Интеррапт]

А если сравнивать V8 и LuaJIT, то первый будет нервно курить в сторонке.

Ну так поэтому LUA для игровой платформы используется, а Titanium - в основном для приложений (хотя и для игр тоже, все-таки V8 довольно шустрая штука). У JavaScript комьюнити побольше и различных готовых компонент больше.

[Интеррапт]

U R totally missing Z point Я догадываюсь, что ими можно пользоваться. Но ты изначально говорил: вот кнопка, она замаппится на UIButton в iOS и в android.widget.Button в ондроеде. Соответственно, вопрос: куда будет маппиться ActionBar & ViewPager в iOS?

Если пользоваться андроидными вещами, которых принципиально нет в iOS, то ActionBar вынесется в отдельный XML, в котором даже можно сделать include для остальной части view - которая более портабельная. Аналогично можешь написать отдельный обработчик для этого ActionBar или даже пользоваться общим обработчиком. Например, событие onAboutClick можно повесить из андроидного слоя на ActionBar-е и при этом повесить на какую-то кнопку в iOS.

[Интеррапт]

По поводу ViewPager - просто используешь
http://docs.appcelerator.com/titanium/l ... llableView

который переключается между окнами при помощи horizontal swipe gestures.

[Ljolja]

Ну хоть в чем-то у меня есть опыт! Года три назад я пытался написать одну приблуду на phonegap... Это было реальное испытание на нордическость характера. К сожалению, phonegap его не выдержал!.

вообше говоря phonegap ето jar/js wrapper "написать одну приблуду на phonegap" ... требует изрядной изобретательноcти. phonegap cookies конвертировать не умеет(ел), в остальном работаeт по описанию

А jar здесь при чем?

jar ето upper level wrapper 4 android Мне казалось все андроидные аппс на самом верхнем уровне так или иначе требуют java interface, разве нет?

[АццкоМото]

Если пользоваться андроидными вещами, которых принципиально нет в iOS, то ActionBar вынесется в отдельный XML, в котором даже можно сделать include для остальной части view - которая более портабельная. Аналогично можешь написать отдельный обработчик для этого ActionBar или даже пользоваться общим обработчиком. Например, событие onAboutClick можно повесить из андроидного слоя на ActionBar-е и при этом повесить на какую-то кнопку в iOS.

Ну, отлично. Делаем мы в итоге два юая, а чуть копнем дальше, выяснится, что обрабочик выглядит примерно так (жаваскриптом не владею)
onAboutClick() {
switch (getPlatform()) {
case ANDROID:
return onAndroidAboutClick();
case IOS:
return onIosAboutClick();
default:
// Shit, need to find better solution some time later
killMyself();
}

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

[dotcom]

Ну так поэтому LUA для игровой платформы используется, а Titanium - в основном для приложений (хотя и для игр тоже, все-таки V8 довольно шустрая штука). У JavaScript комьюнити побольше и различных готовых компонент больше.

LUA, понятно, как скрипт используется в engine'ах. Меня угораздило в свое время на Unreal Script программировать, который был "вдохновлен" Javascript'ом. Ну так это была вещь! Посмотрел, как народ сейчас скриптует в Lua. Так ведь небо и земля. Человеческий язык. В смысле, что язык для людей сделан.

[Интеррапт]

А jar здесь при чем?

jar ето upper level wrapper 4 android Мне казалось все андроидные аппс на самом верхнем уровне так или иначе требуют java interface, разве нет?

А... ты об этом. Ну как бы и да и нет. Не совсем понимаю, что такое java interface в данном контексте, но JAR - это просто ZIP файл с манифестом и .class файлами. Андроид упаковывает все в APK файл (который собственно похож чем-то на JAR, он тоже является ZIP архивом, в нем есть META-INF директория с манифестом). Но при этом, например, отсутствуют .class файлы, вместо них один classes.dex, с Java кодом в Далвик формате, а так же в нем может быть platform-dependent код (для разных архитектур), ну и ес-но ресурсы.

[АццкоМото]

jar ето upper level wrapper 4 android Мне казалось все андроидные аппс на самом верхнем уровне так или иначе требуют java interface, разве нет?

WHAT???!!!!

[Интеррапт]

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

Такой код тоже может попадаться, ес-но. Но при грамотном подходе к проектированию UI - будет попадаться намного реже, чем ты думаешь. Ацко, ты же не думаешь, что я дурак и буду выбирать инструменты, которые мне добавят головной боли, вместо того, чтобы уменьшить ее?
И таки да, я вначале оцениваю, что мол скорее всего мне в этом случае Titanium не нужен и лучше сразу идти в Android/iOS напрямую, а вот в этом случае - сэкономит время.

[АццкоМото]

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

Конечно, я так не думаю. Я думаю, что тут играет роль комбинация кучи факторов. Каких точно - не знаю, но вот предположения:
- Есть какая-то специфика проектов
- Платформенные UI guidelines часто приносятся в жертву унификации энторфейса между платформами
- Просто интересно пощупать что-то новое
- Интересно сделать не "в лоб", как сделали бы другие, а с подвыподвертом
- Если делать с Титаниумом, то тебя не заменить каким-нибудь Ацко за полцены

[Ljolja]

onAboutClick() {
switch (getPlatform()) {
case ANDROID:
return onAndroidAboutClick();
case IOS:
return onIosAboutClick();
default:
// Shit, need to find better solution some time later
killMyself();
}

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

за такой код уважаюший себя работодатель поставит Вам 2ку на интервью .
Правильный код:

Code: Select all

onAboutClick() {
try
onAndroidAboutClick();
except 
log msg "ети уроды пользуют наш апп не на android"
try
onIosAboutClick();
except 
log msg "у них даже не ios"
return to user "we are so so MUCH apologize for the inconvenience, we are working hard to make your user experience more enjoying than you can imagine, please come again "
}

[Интеррапт]

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

Конечно, я так не думаю. Я думаю, что тут играет роль комбинация кучи факторов. Каких точно - не знаю, но вот предположения:
- Есть какая-то специфика проектов
- Платформенные UI guidelines часто приносятся в жертву унификации энторфейса между платформами
- Просто интересно пощупать что-то новое
- Интересно сделать не "в лоб", как сделали бы другие, а с подвыподвертом
- Если делать с Титаниумом, то тебя не заменить каким-нибудь Ацко за полцены

Хе-хе, всего понемногу Правда про job security я в данном случае не думал.
Ну еще один пункт забыл добавить, что таки хочется по возможности иметь один codebase.