Когда использовать Adobe AIR против обычных приложений для настольных компьютеров, например. VB, C #

Question

Интересно, что лучше использовать Adobe AIR по сравнению, например, с приложениями VB / C #?

• Я не думаю, что Adobe AIR быстрее / эффективнее, верно?
• БД мудрый. SqlLite против MSSQL Express, оба бесплатны, 1 с открытым исходным кодом, но MSSQL более мощный? это быстрее?
• в AIR вам все еще нужно создать одно приложение для Интернета и другое для приложений Windows? так что он все равно будет похож на использование Windows Apps и Web Apps. Вы, вероятно, можете поделиться классами / библиотеками?

Answer 1

Я проделал небольшую работу с Air, и я дам вам несколько причин для ее рассмотрения:

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

2. распространение и обновление вашего программного обеспечения будет быстрым, Air проделала огромную работу по созданию механизма / опыта обновления приложения

3. это супер-веб-платформа для приложений с надежной защитой песочницы для пользователя

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

Answer 2

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

Как ни больно говорить: никто не решает использовать AIR вместо собственных приложений. Обычно решение принимается за время и командные навыки (зачем нанимать 3/4 разработчиков, когда у вас может быть 1?).

Легче иметь единую среду разработки, чем пытаться портировать код на C #, Objective-C и c ++. Однако эти нативные технологии ОС всегда превосходят AIR. Производительность AIR на OSX особенно распространена.

Таким образом, в вашем конкретном случае у вас есть веб-приложение, которое вы хотите перенести на рабочий стол, вам нужно будет поддерживать 2 приложения (1 веб, 1 AIR), хотя, если вы пошли по собственному маршруту, вы должны были бы поддерживать 4 отдельных приложения (по 1 на каждую платформу)

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

Answer 3

Я думаю, что масштабируемость была бы хорошей причиной. Ваше приложение будет работать «в облаках», и все пользователи будут использовать одни и те же данные. Обновление приложения проще, так как вы обновляете только облако, а не каждый пользователь. То же относится и к данным, используемым приложением, которые вы можете постоянно обновлять для всех.

Хотя дело не в силе. Более того, 50 000 человек используют ваше приложение одновременно, постоянно обновляя их с самой последней версией вашего приложения. (Предпочтительно без ошибок.) У него есть свои преимущества, хотя с этой техникой тоже есть несколько проблем. Но в целом это зависит от типа создаваемого приложения.