Здравствуйте, vsb, Вы писали:
vsb>А какие тебе советы? Бери да переходи. Раз жавер, наверное логичней в андроид. Хотя по-мне он редкостная кака, но для iOS нужен макбук и свитер.
Ну я не жавер, я больше по .NET, сейчас последний год пишу на JVM, но на Scale, с функциональной парадигмой.
Макбук тоже есть)))
Вопрос непосредственно, о том как лучше это сделать. Пытаться придумать свой проект и пилить его=> заливать в store, и потом его показывать в резюме? или пытаться найти компанию которая возьмет без опыта коммерческой разработки.
Сложность в том, что при наличии семьи, я по сути не могу позволить себе падение зп сильно.
Здравствуйте, mAnonym, Вы писали:
A>Ну я не жавер, я больше по .NET, сейчас последний год пишу на JVM, но на Scale, с функциональной парадигмой.
Ну Kotlin похож на скалу, он нынче официальный язык под андроид. В общем зацепок с андроидом у тебя явно больше, чем с Swift-ом. Хотя я не настаиваю, можно вообще обе платформы учить, там много похожих концепций.
A>Вопрос непосредственно, о том как лучше это сделать. Пытаться придумать свой проект и пилить его=> заливать в store, и потом его показывать в резюме? или пытаться найти компанию которая возьмет без опыта коммерческой разработки.
Сначала научись писать приложения на выбранных технологиях, ну очевидно на каких-то своих простеньких учебных проектах, потом попробуй найти подработку во внерабочее время, можно на копейки, в общем напиши несколько приложений, которые будут в магазинах. Это уже будет конкретный коммерческий опыт, с которым ты можешь приходить на позицию выше джуниорской, как мне кажется. Фишка мобильной разработки в том, что большинство проектов крошечные и пишутся силами одного человека (ну бывает +дизайнер), поэтому их вполне можно потянуть самому во внерабочее время. Кстати, может понравится и вообще фрилансером станешь.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, mAnonym, Вы писали:
A>>Ну я не жавер, я больше по .NET, сейчас последний год пишу на JVM, но на Scale, с функциональной парадигмой.
vsb>Ну Kotlin похож на скалу, он нынче официальный язык под андроид. В общем зацепок с андроидом у тебя явно больше, чем с Swift-ом. Хотя я не настаиваю, можно вообще обе платформы учить, там много похожих концепций.
A>>Вопрос непосредственно, о том как лучше это сделать. Пытаться придумать свой проект и пилить его=> заливать в store, и потом его показывать в резюме? или пытаться найти компанию которая возьмет без опыта коммерческой разработки.
vsb>Сначала научись писать приложения на выбранных технологиях, ну очевидно на каких-то своих простеньких учебных проектах, потом попробуй найти подработку во внерабочее время, можно на копейки, в общем напиши несколько приложений, которые будут в магазинах. Это уже будет конкретный коммерческий опыт, с которым ты можешь приходить на позицию выше джуниорской, как мне кажется. Фишка мобильной разработки в том, что большинство проектов крошечные и пишутся силами одного человека (ну бывает +дизайнер), поэтому их вполне можно потянуть самому во внерабочее время. Кстати, может понравится и вообще фрилансером станешь.
Фриланс и подработка во вне рабочее время, как раз меня и привлекает в мобильном направлении. Конечно можно найти и в бэке, но на мой взгляд тяжелее
Спасибо за ответ. Буду пробовать, уже идейка есть для своего приложения
Здравствуйте, mAnonym, Вы писали:
A>Несколько месяцев меня не покидает мысль/желание о переходе с бэкэнд направления в сторону мобильной разработки. A>Сам я больше специализируюсь по бэкэнд, до недавнего времени с использованием .Net/.Net Core, последний год перешел на Scala.
если спец по бэкэнду то вакансий много, практически в любую фирму по мобильным обращаешься
а там уже на месте со временем перейдешь во фронт если захочешь
а чистые фронт GUI программеры на мобильные имхо не нужны или мало нужны, имхо тенденция на самой мобиле фронт на конструкторе
что студент сможет или дизайнер в адобовском вивере наверстает и выгрузит в апк или ипа,
их много (желающих) и туда люди особо (бегинеры) не нужны и зарплаты низкие, а вот игровой сервер и тд там и зарплаты и люди нужны
Здравствуйте, paradoks, Вы писали:
P>Здравствуйте, mAnonym, Вы писали:
A>>Несколько месяцев меня не покидает мысль/желание о переходе с бэкэнд направления в сторону мобильной разработки. A>>Сам я больше специализируюсь по бэкэнд, до недавнего времени с использованием .Net/.Net Core, последний год перешел на Scala.
P>если спец по бэкэнду то вакансий много, практически в любую фирму по мобильным обращаешься P>а там уже на месте со временем перейдешь во фронт если захочешь
P>а чистые фронт GUI программеры на мобильные имхо не нужны или мало нужны, имхо тенденция на самой мобиле фронт на конструкторе P>что студент сможет или дизайнер в адобовском вивере наверстает и выгрузит в апк или ипа, P>их много (желающих) и туда люди особо (бегинеры) не нужны и зарплаты низкие, а вот игровой сервер и тд там и зарплаты и люди нужны
Просто если посмотреть тот же самый linkedin то вакансий под мобилку достаточно много, и если посмотреть наличие удаленных вакансий то тоже достаточно. Я не берусь спорить где больше, но есть и весьма много.
Здравствуйте, mAnonym, Вы писали:
A>Решил спросить совет у сообщества, буду рад любым советам.
Мобильные приложения пишут кто на чём горазд.
Я сторонник "родного" подхода — т.е., не использовать third-party frameworks, которых нонче (по памяти, наверняка не все вспомнил):
* React Mobile — JavaScript
* Xamarin — C#
* Qt Mobile — C++
* Ionic (это такой Angular под мобильные) — опять JavaScript
Так вот, про фреймворки я не помощник, я их отрицаю.
Про "родной" подход:
iOS:
Swift если брать то сразу версии 5, не оглядываясь на предыдущие.
Objective-C неплохо бы знать, чтобы понимать в легаси, которого, понятно, миллион
C++ — да, библиотеки на C++ используются в хвост и в гриву; можно, наверно, и без них.
Xcode как среда разработки. AppCode от JetBrains хвалят, но я не пробовал.
Android:
Kotlin, конечно же. Они со Swift похожи до степени смешения, поэтому у меня переход в обе стороны сравнительно бесшовный
Java — опять же, для Legacy
C++ — опять библиотеки
Android Studio как среда разработки
Ну и мой любимый подход — ядро на C++, а на Swift/Kotlin уже UI. В качестве архитектурной парадигмы хорошо подходит MVVM. Тогда две версии приложения, iOS и Android, имеют довольно большую общую часть на С++, ну и "родной" интерфейс, ограниченный исключительно возможностями платформы.
Здравствуйте, Dair, Вы писали:
D>Здравствуйте, mAnonym, Вы писали:
A>>Решил спросить совет у сообщества, буду рад любым советам.
D>Мобильные приложения пишут кто на чём горазд.
D>Я сторонник "родного" подхода — т.е., не использовать third-party frameworks, которых нонче (по памяти, наверняка не все вспомнил): D>* React Mobile — JavaScript D>* Xamarin — C# D>* Qt Mobile — C++ D>* Ionic (это такой Angular под мобильные) — опять JavaScript
D>Так вот, про фреймворки я не помощник, я их отрицаю.
D>Про "родной" подход:
D>iOS: D>Swift если брать то сразу версии 5, не оглядываясь на предыдущие. D>Objective-C неплохо бы знать, чтобы понимать в легаси, которого, понятно, миллион D>C++ — да, библиотеки на C++ используются в хвост и в гриву; можно, наверно, и без них. D>Xcode как среда разработки. AppCode от JetBrains хвалят, но я не пробовал.
D>Android: D>Kotlin, конечно же. Они со Swift похожи до степени смешения, поэтому у меня переход в обе стороны сравнительно бесшовный D>Java — опять же, для Legacy D>C++ — опять библиотеки D>Android Studio как среда разработки
D>Ну и мой любимый подход — ядро на C++, а на Swift/Kotlin уже UI. В качестве архитектурной парадигмы хорошо подходит MVVM. Тогда две версии приложения, iOS и Android, имеют довольно большую общую часть на С++, ну и "родной" интерфейс, ограниченный исключительно возможностями платформы.
Спасибо большое за ответ.
Я насколько понимаю Вы тоже переходили с системного/бэкэнд в мобильную разработку? Насколько переход был безболезненный, особенно в финансовом плане?
Здравствуйте, mAnonym, Вы писали:
A>Я насколько понимаю Вы тоже переходили с системного/бэкэнд в мобильную разработку? Насколько переход был безболезненный, особенно в финансовом плане?
профессионально не занимался. Т.е., написал для хобби пару штук на Ruby on Rails, но это так, баловство.
Занимался разработкой пользовательских приложений на С++ под Linux. Потом Linux внезапно стал мобильным (были такие поползновения в начале 00х), UI на Qt (сегодняшнее развитие этого нонче называется Sailfish). А потом с мобильного Linux/Qt ушёл в мобильный Windows Mobile и Palm, где тоже C++. А потом "случился" iPhone, овладел им. А потом так же "случился" Android.
В финансовом плане я никогда в жизни не переходил на зарплату меньше.
D>Так вот, про фреймворки я не помощник, я их отрицаю.
тут не соглашусь. набирает обороты Fluter. посмотрите в эту сторону, потому как перспективно.
кстати, Google для Fluter взял один в один концепцию FMX (FireMonkey) из Delphi.
XAMARIN хуже Delphi FireMonkey, поэтому если и брать то FireMonkey.
вот пример приложения для знакомств, сделанное на Delphi https://youtu.be/WEsEhGfrW-g
присутствует и в Google Play и в App Store
Здравствуйте, wamaco, Вы писали:
D>>Так вот, про фреймворки я не помощник, я их отрицаю. W>тут не соглашусь. набирает обороты Fluter. посмотрите в эту сторону, потому как перспективно.
Вот открыл я приложение Алибаба, которое у Flutter написано первым, типа как реклама.
И это довольно простое приложение весит, на минутку, 218 мегабайт. Написанное нативно было бы 25–30.
Мой любимый пример с фреймворками — это Facebook app (React Native), который на iOS весит 250 мегабайт, и ещё Messenger к нему отдельно, размером примерно столько же.
VK app, который умеет ровно всё то же самое, что Facebook app и Messenger, весил до недавнего времени типа 35. Сейчас, впрочем, только что проверил, уже 150, тоже, небось, на фреймворк перешли.
А ещё vk сильно быстрее.
Моё приложение, с полноценной оффлайновой навигацией и разным таким прочим — 73 мегабайта в AppStore.
Ненене, Дэвид Блэйн, ненене.
Отдельный вопрос — а как в Flutter добавить использующиеся в компании (в продуктах под Windows и Linux) C++-библиотеки, например?
Здравствуйте, susumanin, Вы писали:
D>>Ненене, Дэвид Блэйн, ненене.
S>Сегодня кто-то из рядовых юзеров смотрит сколько весит приложение перед тем как его поставить?
Я смотрю
У нас, конечно, эпоха Bloatware, но надо же хоть кому-то что-то с этим делать хотя бы не увеличивая энтропию?..
A>Решил спросить совет у сообщества, буду рад любым советам.
Переходи на Kotlin и пиши хоть под Android (Kotlin JRE), хоть под iOS (Kotlin Native). GUI, разумеется, будет свой в каждом случае, но язык один, который отлично стыкуется с кодом как на Swift, так и на Java.
S>Сегодня кто-то из рядовых юзеров смотрит сколько весит приложение перед тем как его поставить?
Да. Как-то проскакивало исследование, утверждавшее что время загрузки приложения из стора более сорока секунд крайне раздражает многих пользователей вплоть до обрыва закачки. Если ты не фейсбук или алибаба, который и так, и так скачают, то размер очень важен. При прочих равных, конечно.
D>Я сторонник "родного" подхода — т.е., не использовать third-party frameworks, которых нонче (по памяти, наверняка не все вспомнил):
Всё бы хорошо, если б не постоянная деградация качества Xcode. Сижу на нём с четвертой версии. По моим впечатлениям, по скорости, удобству и стабильности пик развития пришелся на Xcode 5. Далее — непрерывное грехопадение. В современных версиях что-то ломается каждый час. А еще это аспирантское поделие под названием Swift, который дико концептуален и красив на бумаге, а на практике — сплошные овраги с ABI, отвалом совместимости и взглюками то toolchain'а, то поддержки опять же в Xcode. Поражает это долбанное двуличие — сторонним разработчикам свифт втуливается как основной язык, и в то же время сам iOS/Mac и родные приложения под них пишутся классическими методами. Возьми и подизассемблируй сам. Свифта почти не найдешь.
Если дела будут так продолжаться, то не удивлюсь, что через пару лет сторонние средства разработки и фреймворки могут, наконец, стать удобнее родных. А они будут так продолжаться — новое содомитское руководство эппла, похоже, ничего не интересует, кроме бабла. Дух прорывной компании испаряется.
D>* Xamarin — C#
Вполне годно для корпоративщины. iOS – это не только игрушки и инстаграмчики. Есть и вполне серьёзные программные комбайны для iPad, чтобы работу работать. В топах их, понятное дело, не найдешь, у них своя дистрибуция и монетизация. Для казуальных сценариев, наверное, лучше не брать.
D>* Qt Mobile — C++
Неплохое решение, если уметь готовить. Великолепный оффлайновый навигатор maps.me в пример. Подход, ИМХО, требует сверхдофига "build-fu", но если предметная область вопиюще требует крестов (САПР-ГИС-BIM–Дизайн-Графика-Видео-DSP), то почему бы и нет.
D>Objective-C неплохо бы знать, чтобы понимать в легаси, которого, понятно, миллион
Трудно сказать, что окажется legacy через несколько лет, когда голимый хайп спадет, конъюнктурщикам на iOS ловить станет нечего, и останутся старожилы с серьезными успешными проектами. Objective C — эдакий Shang Tsung в мире языков. За кажущейся неказистостью, краткостью спецификации и простотой начального вкатывания стоит такая мощь перевоплощения в любую парадигму, открываемая на высоких уровнях опыта, что он еще свое покажет на длинной дистанции. А по таким качествам, как forward-backward-compatibility и бесшовность интеграции с C++ ему вообще нет равных.
PS. Кстати, чуть не забыл. Посмотрите на индекс TIOBE. Свифт за последний год резко упал в популярности, а Objective C снова поднимает голову.
Здравствуйте, mAnonym, Вы писали:
A>Решил спросить совет у сообщества, буду рад любым советам.
Если есть месяца два можно просто взять и написать чтонить. Вот пример мое приложения написанного за полтора месяца с изначально нулевыми знаниями в мобильных приложениях https://airwatch.andmed.org/airwatch
Сам я бэкендер и сказать что возникло желание уйти во фронт с головой неправда. Но есть что показать теперь и кругозор расширяет сильно. Андроид неизашел мне совсем. Айос жить можно. Строго субъективно
Здравствуйте, serj.e, Вы писали:
SE>. Поражает это долбанное двуличие — сторонним разработчикам свифт втуливается как основной язык, и в то же время сам iOS/Mac и родные приложения под них пишутся классическими методами. Возьми и подизассемблируй сам. Свифта почти не найдешь.
Не первый раз слышу плохие отзывы о свифте. Я свой хелловорлд написал на нем, вот возникло сейчас желание переписать на обджектив чтобы сравнить так сказать. Не то чтобы он не понравился, нет, лучше джавы, но вот например столкнулся с тем что runtime exceptions в свифте напр npe не кэтчатся принципиально в отличие вроде как от обджектив. Пару раз были проблемы с guard то есть вынесенное из условия присваивание само по себе позволило пофиксить компиляцию. Возможно не осилил (спецификацию не штудировал да) но по итогу просто стал его применять в самых простых случаях. Плюс такое ощущение что сильно меняется. Там получается каждый год выходит новая версия и чтото ломают. Надеюсь обджектив постабильнее
Здравствуйте, serj.e, Вы писали:
D>>Я сторонник "родного" подхода — т.е., не использовать third-party frameworks, которых нонче (по памяти, наверняка не все вспомнил): SE>Всё бы хорошо, если б не постоянная деградация качества Xcode. Сижу на нём с четвертой версии. По моим впечатлениям, по скорости, удобству и стабильности пик развития пришелся на Xcode 5. Далее — непрерывное грехопадение.
Падение качества Xcode есть, увы, да. Но, вроде, стало как винда — чётные мажорные версии нормальные, нечётные — ну так. Ужасен был Xcode 7, баг на баге. Нонешний 10 вполне нормальный, у меня с ним каких-то особых проблем нет.
SE> А еще это аспирантское поделие под названием Swift, который дико концептуален и красив на бумаге, а на практике — сплошные овраги с ABI, отвалом совместимости и взглюками то toolchain'а, то поддержки опять же в Xcode.
Опять не сталкивался. Хотя на Swift мы только полгода пишем, до этого только Objective-C был.
SE> Поражает это долбанное двуличие — сторонним разработчикам свифт втуливается как основной язык, и в то же время сам iOS/Mac и родные приложения под них пишутся классическими методами. Возьми и подизассемблируй сам. Свифта почти не найдешь.
Дык, на пользователях отладить, а потом уже отлаженным инструментом и пользоваться можно!
D>>* Xamarin — C# SE>Вполне годно для корпоративщины. iOS – это не только игрушки и инстаграмчики. Есть и вполне серьёзные программные комбайны для iPad, чтобы работу работать. В топах их, понятное дело, не найдешь, у них своя дистрибуция и монетизация. Для казуальных сценариев, наверное, лучше не брать.
Ну если мы пишем опердень на мобильные, то, наверно, да, можно.
D>>* Qt Mobile — C++ SE>Неплохое решение, если уметь готовить. Великолепный оффлайновый навигатор maps.me в пример. Подход, ИМХО, требует сверхдофига "build-fu", но если предметная область вопиюще требует крестов (САПР-ГИС-BIM–Дизайн-Графика-Видео-DSP), то почему бы и нет.
Если предметная область требует крестов — то Xcode умеет кресты искаропки.
Android Studio задорнее, но тоже умеет через JNI.
D>>Objective-C неплохо бы знать, чтобы понимать в легаси, которого, понятно, миллион SE>Трудно сказать, что окажется legacy через несколько лет, когда голимый хайп спадет, конъюнктурщикам на iOS ловить станет нечего, и останутся старожилы с серьезными успешными проектами. Objective C — эдакий Shang Tsung в мире языков. За кажущейся неказистостью, краткостью спецификации и простотой начального вкатывания стоит такая мощь перевоплощения в любую парадигму, открываемая на высоких уровнях опыта, что он еще свое покажет на длинной дистанции. А по таким качествам, как forward-backward-compatibility и бесшовность интеграции с C++ ему вообще нет равных.
Тут подпишусь, да. Сам, узнавая Objective-C при C++- бэкграунде был приятно удивлён в своё время. Отличный язык. Взбешивали поначалу квадратные скобки, но потом привык
SE>PS. Кстати, чуть не забыл. Посмотрите на индекс TIOBE. Свифт за последний год резко упал в популярности, а Objective C снова поднимает голову.
Интересно, да.