Имхо, делайте нативное. Сколько уже раз мы обжигались на всяких этих кроссплатформенных фрейворках — не передать. Проблема в том, что если приложение сложнее, чем представленные на сайте примеры использования SDK (а чаще всего так и есть), то из «кроссплатформенного» кода всегда будут отсылки на нативные SDK. И вот уже приложение становится не таким уж и кроссплатформенным, и с кучей костылей. Саппорт превращается в дикий ужас, а если фреймворк еще периодически ломает обратную совместимость, то становится вообще невесело. Бывали случаи, когда у версий приложений в итоге оставалось только 20%-30% общего кроссплатформенного кода, и это не криворукость программистов :)
Конечно, есть ситуации, когда у разработчиков уже есть наработанный годами код/паттерны/сниппеты/workarounds для платформы (например, у меня есть такие для Corona SDK, Marmalade SDK, немного для приложений на Sencha ExtJS). В этом случае использование фреймворка часто окупается. Но если до этого вы никогда не писали, скажем, под PhoneGap или что другое, то скорее всего время разработки будет таким же (или даже больше), как если бы разрабатывать нативные версии приложений. Или программист (специалист по данному фреймворку) может уволиться, и придется искать замену, что гораздо легче в случае нативных приложений.
Для себя мы придерживаемся примерно следующей стратегии: «Кросплатформенность для игр — да, да и еще раз да. Кроссплатформенность для приложений — нет, нет, и никогда больше».
Исторически KISS расшифровывается как keep it simple stupid или keep it simple , stupid. А вариации на тему keep it S&S: simple & straightforward, smart & simple, simple silly, sort & simple, super simple, safe and sound и т.д. — подгонка аббревиатуры KISS к ситуации.
Очень интересно. Есть ли отзывы от реальных пользователей (или их родителей)? Может быть, есть какая-то еще статистика? Мне это интересно еще и потому, что подрастает маленький программист и необходимо придумывать всякие соответствующие игры.
Верно. Просто там не совсем четко указано, где используется k из определения A, а где k из определения B. Во второй строке импликации B->A написано: k (из определения A) = k0 (которое равно k из B, что ТС не указал) + q, т.е. это действительно любоеk>k0, как того требует определение A.
Всё верно в доказательстве, интуитивно можно понимать так:
Определение по Коши: для любого ε можно найти номер k0, начиная с которого любые два члена последовательности близки.
Ваше определение: для любого ε можно найти номер k, начиная с которого конкретные два члена последовательности близки (а именно k и k+p).
Понятно, что из определения по Коши следует Ваше определение. Но и наоборот тоже верно в силу неравенства треугольника: если два элемента близки к конкретному третьему (x_k в Вашем определении), то эти два элемента обязательно близки между собой.
На мой взгляд, определение по Коши интуитивно понимается лучше. Но это сугубо личное мнение.
Очень, очень вовремя! Как раз на прошлой неделе из Lodsys звонили: хотели отчислений за нарушение патента по использованию in-app purchases. Мы расстроились, особенно после этого: bit.ly/1bl7tyW, но сейчас вновь есть надежда :)
Ректор университета просмотрел смету, которую ему принес декан физического факультета, и вздохнув, сказал:
— Почему это физики всегда требуют такое дорогое оборудование? Вот, например, математики просят лишь деньги на бумагу, карандаши и ластики. И, подумав, добавил:
— А философы, те еще лучше. Им даже ластики не нужны.
DispFixRot=FixedPortrait не всегда работает правильно на Анроиде. Лучше в main.cpp пропишите
s3eSurfaceSetInt(S3E_SURFACE_DEVICE_ORIENTATION_LOCK, S3E_SURFACE_PORTRAIT_FIXED);
Конечно, есть ситуации, когда у разработчиков уже есть наработанный годами код/паттерны/сниппеты/workarounds для платформы (например, у меня есть такие для Corona SDK, Marmalade SDK, немного для приложений на Sencha ExtJS). В этом случае использование фреймворка часто окупается. Но если до этого вы никогда не писали, скажем, под PhoneGap или что другое, то скорее всего время разработки будет таким же (или даже больше), как если бы разрабатывать нативные версии приложений. Или программист (специалист по данному фреймворку) может уволиться, и придется искать замену, что гораздо легче в случае нативных приложений.
Для себя мы придерживаемся примерно следующей стратегии: «Кросплатформенность для игр — да, да и еще раз да. Кроссплатформенность для приложений — нет, нет, и никогда больше».
P.S. В Новую Зеландию отправите посылочку? :)
Отпишите, кто возьмет.
k (из определения A) = k0 (которое равно k из B, что ТС не указал) + q, т.е. это действительно любое k>k0, как того требует определение A.
Определение по Коши: для любого ε можно найти номер k0, начиная с которого любые два члена последовательности близки.
Ваше определение: для любого ε можно найти номер k, начиная с которого конкретные два члена последовательности близки (а именно k и k+p).
Понятно, что из определения по Коши следует Ваше определение. Но и наоборот тоже верно в силу неравенства треугольника: если два элемента близки к конкретному третьему (x_k в Вашем определении), то эти два элемента обязательно близки между собой.
На мой взгляд, определение по Коши интуитивно понимается лучше. Но это сугубо личное мнение.
1. На чем написан backend?
2. Нормально ли работает WebView, нет ли проблем на реальных девайсах?
3. Есть ли заинтересованность со стороны инвесторов?
Удачи в развитии и продвижении!
P.S. Извините, не могу удержаться:
1. Button
2. ???
3. Profit
:)
— Почему это физики всегда требуют такое дорогое оборудование? Вот, например, математики просят лишь деньги на бумагу, карандаши и ластики. И, подумав, добавил:
— А философы, те еще лучше. Им даже ластики не нужны.
s3eSurfaceSetInt(S3E_SURFACE_DEVICE_ORIENTATION_LOCK, S3E_SURFACE_PORTRAIT_FIXED);