Вообще, Metal действительно очень хорошо работает под маками, например, в Heroes of the Storm Metal дает прирост производительности чуть ли не в 2 раза, по сравнению с OpenGL. Да, это не хорошо так резко указывать deprecated на технологии, однако, Metal очень перспективен, необходимо как можно скорее переводить все на него и будет счастье юзерам)
Можно ещё это почитать, не то чтобы готовая библиотека, но один из подходов асинхронного подхода, который позволяет забить на повороты экрана: https://m.habrahabr.ru/post/328512/
Не так уж и увеличит. Количество людей, которые реально будут пользовать смартфоном в качество пультов от всего будет настолько меньше от общей массы, что никто из производителей не будет заморачиваться. Тем более что это не удобно. У меня пульт на телеке сдох, пришлось некоторое время телефоном тыкать, это капец как неудобно, нужно всегда помнить о телефоне и брать его с собой, или идти за ним, если забыл в другой комнате, а пульт тихо и мирно лежит рядом с девайсом, которым управляет.
Когда дают тестовое задание на 10-20 часов, после выполнения которого просто говорят: «Вы нам не подходите», да еще и без объяснения причины… Для таких людей есть отдельный котел)
Хм, идея хорошая, но реализация подкачала. Я уже некоторое время думаю над своим решением, и концепцию офлайна я уже придумал. Ваша же статья привела меня к несколько другой мысли. В общем, пойду работать дальше, возможно, довольно скоро, приведу свой вариант)
Из всего кросплатформенного я ставлю именно на реакт. Во-первых, родитель в лице фэйсбука уже достаточно весомый аргумент, а во-вторых, теперь они каждый месяц собираются с другими командами, что бы обсуждать дальнейшее развитие продукта. Вот уже буквально недавно дали возможность создавать проекты вообще без единой строчки нативного кода. Да и уже в таком сыром виде, инструмент уже очень много может.
Еще какой оверхед, особенно при использовании MVP:
1) Мы пишем всю верстку на XML, прописывая тонны параметров, и еще и IDшники.
2) Потом мы в активити еще цепляем все это (и лучше через butter knife, а то уж больно много писать)
3) Потом мы пишем интерфейсы, которые будут управлять состоянием
4) Оверрайдим интерфейс в активити, где в методах уже пишем логику, которая будет изменять состояние объектов (буквы, цифры, возможности нажатия кнопок)
5) И, наконец, уже в презентаре мы будет вызывать методы интерфейса.
В 5 разных местах мы по чуть чуть пишем логику 1(!) экрана. Я с радостью выброшу хотя бы 1 пункт из списка, и вообще откажусь от XML.
Да, я так и делаю, то был пример с оф. туториала react native =) Да и в любом случае, style обычно так сильно разрастается, что в любом случае приходится выводить отдельную константу под это.
Прощу прощения. По большей части это опечатки, т.к. пишу по ходу мысли, я не из тех кто долго-долго думает над текстом и пишет 33 черновика. Я пишу на вдохновении, а потом перечитываю пару раз свой текст. Конечно, проверяю и спел чекером, но от слова в не правильной форме это не спасает, а внимательно вчитываться в каждую букву на 3-4 раз уже невозможно. Буду работать над языком.
Хм, интересная идея, подумаю над этим. По поводу assets, я не понял, зачем это нужно, как я понял мы спокойно можем создать свою папку с картинками и прочим, импортировать их в js коде и оно будет работать что на андроид, что на iOS, разве не так?
Скриншоты я брал с оф. туториала react native, а там айфон(
По поводу работы: JS компилируется в obj-c для iOS и в java для андроида. С рантайм, естественно, страдает, смысл в том, что для андроида (iOS глубоко не изучал) есть 1 активити, которая и запускается при старте, и в эту активити потом отправляется скомпилированный JS код. Во всяком случае во время разработки (SDK я еще не собирал) происходил билд приложения, потом оно запускает эту активити, потом эта активити показывает процесс компиляции JS. Во время первого запуска рантайм увеличивается раза в 2. После, этот процесс намного быстрее. Как допишу приложение, расскажу как оно в готовом виде работает.
Читаю про redux, но пока в своем тестовом проекте не знаю куда и зачем его прицепить. Потом, как закончу приложение, я сделаю еще 1 общий обзор с глубоким обзором react native, может быть и до redux доберусь. А если и не доберусь, то, надеюсь, люди подскажут где и зачем его использовать.
Можно ещё это почитать, не то чтобы готовая библиотека, но один из подходов асинхронного подхода, который позволяет забить на повороты экрана:
https://m.habrahabr.ru/post/328512/
1) Мы пишем всю верстку на XML, прописывая тонны параметров, и еще и IDшники.
2) Потом мы в активити еще цепляем все это (и лучше через butter knife, а то уж больно много писать)
3) Потом мы пишем интерфейсы, которые будут управлять состоянием
4) Оверрайдим интерфейс в активити, где в методах уже пишем логику, которая будет изменять состояние объектов (буквы, цифры, возможности нажатия кнопок)
5) И, наконец, уже в презентаре мы будет вызывать методы интерфейса.
В 5 разных местах мы по чуть чуть пишем логику 1(!) экрана. Я с радостью выброшу хотя бы 1 пункт из списка, и вообще откажусь от XML.
По поводу работы: JS компилируется в obj-c для iOS и в java для андроида. С рантайм, естественно, страдает, смысл в том, что для андроида (iOS глубоко не изучал) есть 1 активити, которая и запускается при старте, и в эту активити потом отправляется скомпилированный JS код. Во всяком случае во время разработки (SDK я еще не собирал) происходил билд приложения, потом оно запускает эту активити, потом эта активити показывает процесс компиляции JS. Во время первого запуска рантайм увеличивается раза в 2. После, этот процесс намного быстрее. Как допишу приложение, расскажу как оно в готовом виде работает.