Кроссплатформенный фреймворк подходит для всех вещей в мобильном приложении как нативный?

Question

Я работаю в iPhone SDK. Мне нужно конвертировать из него в Crossplatform, которая может быть телефонной или титановой. Как разработчик приложений для iPhone, у меня есть несколько вопросов, основанных на Cross Paltform. Пожалуйста, рассмотрите вопросы для других платформ Androidи т. д. Также. Я уже видел Ссылка на стек в стеке .

1) Возможно ли получить одинаковые функциональные возможности всех API, которые есть в iPhone SDK через HTML5 и javascript?

2) Если Apple выпустит новую версию iPhone SDK, будут ли включены новые API-интерфейсы как можно скорее в кроссплатформенном режиме?

3) Если приложение в некоторых ситуациях дает сбой, могу ли я сразу исправить с помощью отладки устройства, как мы это делаем на нативномЯзык?

4) Приложения, разработанные на платформе Cross, будут одобрены компанией Apple legaly. Например, если я хочу транслировать в прямом эфире на iphone, ограничения упоминались на веб-сайте Apple. За ним последовала кроссплатформенность?

5) Будет ли приложение, разработанное кроссплатформенным, занимать больше памяти? Iупомянуть размер сборки устройства для магазина приложений? Если мы разработаем то же самое с помощью цели C, уменьшится ли размер?

*** Мой вывод: когда мы хотим разрабатывать простые приложения для нескольких устройств, подходит кроссплатформенность.Я прав? *** Я надеюсь, что использование родного языка (iphonensdk, Android) позволит избежать многих ненужных вещей.

Answer 1

1. Нет.
2. Если API можно сделать доступным , это зависит от того, насколько быстро его разработчики реализуют.
3. В принципе, да, поскольку эти платформы используют ограниченный набор возможностей ОС для запуска веб-технологий (в большинстве случаев). Эта «оболочка» ведет себя как любое собственное приложение. Однако к контенту применяются правила языка разработки фреймворков. Может быть сложнее по сравнению с нативной разработкой отследить ошибки, так как они должны «пройти оболочку». Например, ошибки HTML могут снова и снова приводить к одной и той же ошибке для включающего их веб-просмотра, несмотря на разный источник.
4. Propably.
5. Сложно сказать. Это может зависеть от структуры. Я не стал бы беспокоиться о коде, так как другие ресурсы, такие как изображения, обычно более тяжелые. Но вполне может быть так, что эти платформы приносят образы, необходимые для их элементов пользовательского интерфейса, поскольку они не полностью полагаются на элементы ОС. По сравнению с нативным приложением, которое вообще не требует дополнительных ресурсов, кроссплатформенное приложение с той же функциональностью может занять больше памяти.

Что касается вашего заключения: вы правы. Однако Я бы по-прежнему рекомендовал любому разрабатывать нативные приложения, когда это возможно. Кроссплатформенные фреймворки, как правило, медленнее во время выполнения и в некоторых случаях создают очень уродливые приложения. Я знаю несколько примеров приложений, которые были созданы с различными кроссплатформенностями, и мне не нравится ни одно из них. Они просто не чувствуют себя хорошо . Частично это связано с их элементами пользовательского интерфейса, которые не выглядят и не выглядят так, как вы ожидаете, на платформе, на которой вы находитесь.

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

Answer 2

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

Соображения относительно пользовательского интерфейса, которые могут быть сделаны / обработаны нативным приложением, а также функциональность и скорость, получаемые благодаря его естественному выполнению, ИМХО, значительно перевешивают выгоду от необходимости писать его 2 или 3 раза.

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