Разработка мобильных приложений для нескольких платформ (без кроссплатформенного фреймворка!)

Question

Мы являемся разработчиками относительно сложного неигрового приложения для iPhone 3, и мы начинаем амбициозную переписку, чтобы лучше использовать iOS 4. В приложении есть существенный социальный элемент, поэтому мы начали думать, что мы хотели бы сделать его доступным на как можно большем количестве современных мобильных платформ:

• iPhone / IOS
• Android
• Windows Phone
• BlackBerry OS
• Symbian

Существует несколько подходов к кроссплатформенной разработке, и все они имеют ограничения. Ни одно решение не может использовать все функциональные возможности устройства так, как это делает нативное приложение. Учитывая сложность нашего приложения, я просто хотел бы максимизировать «логическое» повторное использование кода, не прибегая к кроссплатформенной структуре. Я предполагаю инструменты, которые сделают разработку и тестирование приложений для нескольких платформ более плавными. Что мы можем сделать, чтобы разработка на 5 платформах заняла менее чем в 5 раз больше усилий?

Answer 1

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

Answer 2

Я знаю, что вы сказали, что нет кроссплатформенных фреймворков, но, возможно, вам стоит посмотреть:

Напишите всю основную логику в javascript.Юнит тест по желанию.Затем используйте такие инструменты, как Appcelerator, чтобы превратить эту логику в собственный код.

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

Для платформ, которые они не поддерживают прямо сейчас, вы можете найти конвертер js в нативный код или способ размещения среды js на этих платформах.

Answer 3

Я согласен с Бет.Я разработал продукт, основанный на том же мыслительном процессе.У меня есть java-сервер, работающий на сокете, в котором есть клиентская библиотека, которую клиентское приложение использует для подключения к серверу.Клиент абстрагирует часть сокета и предоставляет простые API-интерфейсы для вызова клиентских приложений.

Сервер оборудован для параллельной обработки нескольких клиентских подключений, концепция пула потоков.

Теперь, посколькубыть клиентской библиотекой Java, вы можете запустить ее только на Android.Чтобы заставить это работать на других платформах, вы можете запустить эту часть клиента на J2EE.Таким образом, вы создаете третий средний слой.После этого все другие платформы могут подключаться с помощью браузера.

После этого вы можете использовать библиотеки JSON to Object для представления вашего объекта (на стороне сервера) JSON.Я еще не сделал этого, но сделаю это через несколько недель.

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

Answer 4

Ни один из них не будет хорошо играть вместе. Это не отвечает их интересам.

Лучше всего, чтобы все было глупо и все было просто. Простота всегда побеждает, когда вы пытаетесь изолировать несколько враждебных интересов.

Найдите в XML все данные, а затем получите 5 двоичных файлов для чтения или отправьте их на веб-сервер через PHP. Все эти мобильные платформы будут прекрасно работать с XML, потому что в их интересах это сделать. Беспокойство о брендинге и внешнем виде ПОСЛЕ ТОГО, КАК вы получаете основные функции с нуля.

ПРИМЕЧАНИЕ : Javascript - это последнее, на что вы должны обратить внимание в начале. Он редко играет одинаково на всех платформах. Поэтому убедитесь, что ваш уровень JS не зависит от уровня данных. НЕ ИНТЕГРИРУЙТЕ ИХ. Это было бы плохо. Вы хотите, чтобы ваш Android JS потенциально отличался от JS, который вы нажимаете на Blackberry, например. Потому что вы не будете знать, как это будет странно, пока не попробуете и не протестируете свои методы.

Answer 5

В настоящее время я думаю об этой проблеме, и мое решение будет заключаться в том, чтобы разместить все стороны логического сервера и использовать такой подход, как Model-View-Presentation, серию событий, инициируемых пользовательским интерфейсом, которые вместо этого должны быть специфичными дляклиент

Answer 6

Что ж, вы можете посмотреть на JQTouch , SensaTouch или, может быть, подождать некоторое время, чтобы увидеть jqueryformobile , чтобы наконец опубликовать.Если вы не спешите, я бы уже начал работать в jQuery, поскольку два из трех из этого списка (будут) основаны на jQuery в качестве плагинов