Можно ли эффективно заниматься разработкой мобильных приложений, работая только с эмуляторами?

#windowsphone #android #ios

Планирую попробовать себя в разработке под мобильные платформы. Но т.к. их несколько
(iOS, Windows Phone, Android), то располагать оборудованием под каждую систему для
меня проблематично. Можно ли полностью заменить аппараты на этих платформах эмуляторами
при разработке? Не возникнут ли проблемы при тестировании приложений?    

Ответы

Ответ 1

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

В эмуляторе по умолчанию (до версии API=10 по-моему), наличествовал джойстик/стрелочки.
В одной аппе автор (лет 5 назад, когда реальных аппаратов было еще мало) использовал
этот джойстик, в реальном мире джойстиками оснащены единичные аппараты. Результат понятен.
На эмуляторе не выкидывается эксепшн если в UI потоке начать читать через HTTP, на
реальном устройстве выше ICS выкидывается эксепшн с требованием разместить чтение вне
UI потока.
На эмуляторе невозможно протестировать всякие разные датчики (уже говорилось выше)
Эмулятор не поддерживает прием многотомных (multipart) SMS сообщений - можно принимать
только single part SMS сообщения

С другой стороны, и это важно подчеркну, без эмулятора тоже совсем туго. Можно насоздавать
тучу эмуляторов и проверить свое приложение в разных экзотических случаях (например
как будет работать если не будет карты памяти, что будет если разрешение экрана будет
минималистичным и т.д.)


Ответ 2

До поры-до времени можно...
но до той поры, пока заказчик не скажет вам, что у него на 4 айфоне не работает,
а вы ему начнете доказывать, что у вас на симуляторе работает.
А дело в том, что, на пример, для iOS симулятор, это даже не "эмулятор", как таковой.
он не эмулирует устройство. Программы, запускаемые на нем, предварительно компилируются
для архитектуры x86, в то время, как на реальных "ай-дивайсах" ARM архитектура.
Что касательно Андроида, то тут дело чуть получше.
Эмулятор запускается действительно как виртуальная машина с эмуляцией архитектуры, и пр.
В случае андроида приложения будут наоборот медленнее работать на эмуляторе. Так
же на эмуляторе будет возникать несколько больше ошибок, чем на реальном устройстве
(с чем это связано я еще не выяснил, но проверено экспериментальным путем). 
А еще на устройствах, чаще всего, не стоковый, оригинальный андроид, а немного(или,
иногда, много) модифицированный производителем, что значит, что на реальных устройствах
некоторые приложения будут работать немного не так, как на оригинальном андроиде.
Но все же без эмуляторов не обойтись(если вы не готовы купить по устройству из каждой
категории для iOS, и по одному на каждое разрешение экрана для Андроид).


Ответ 3

Я сам недавно только начал писать под ios. Такие вещи как камера, аксилерометр протестировать
будет невозможно, а также нужно учесть что pc мощнее телефона и приложение на симуляторе
будут работать быстрее, чем на телефоне.
Т.е. может получиться что на телефоне приложение грузиться долго, а на эмуляторе
мгновенно. 
Т.е. для того чтобы заниматься этим на высоком уровне, конечно нужно иметь устройства,
но начинать можно и с эмуляторов.


Ответ 4

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

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


Ответ 5

Насчет тестирования - сейчас Apple и Microsoft при сертификации приложений в свои
маркетплейсы сами тестируют на разных девайсах. За это и берут 30% с продаж. Например,
для моего приложения под Windows Phone 7 мелкомягкие тестили на двух HTC, нокии и самсунге.

Пишут ли на С++ под iOS и Windows Phone?

#cpp #ios #windowsphone

Знаю,что под Android пишут. А у iOS и Windows Phone есть аналог NDK, или если писать,
то исключительно на ObjC и C#?
    

Ответы

Ответ 1

Пишут. 



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



На iOS все очень просто и удобно: C++ спокойно сосуществует в одном проекте и даже
в одном файле с Objective-C. Возможно использовать как C++ из кода Objective-C, так
и наоборот. Все стандартные библиотеки Objective-C могут быть доступны из C++. Естественно,
есть некоторые тонкости, связанные с именованием файлов и подключением заголовочных
файлов,а так же с памятью, так как в Objective-C есть сборка мусора, а в C++ нет, но,
в целом, это мелочи, разработка достаточно проста и удобна. Не уверен, возможно ли
это со Swift.



Под Windows Phone я напрямую не разрабатывал. Насколько мне известно из общения с
WinPhone-программистами, чистый C++ там нужно подключать к проекту в виде динамической
библиотеки (.dll) со всеми вытекающими проблемами. При этом, саму программу можно писать
на C++/CLI (managed C++).



В сравнении с Android разработкой: 


Разработка под iOS на C++ в разы удобнее. 
Под WinPhone я бы сказал - примерно сопоставима по проблемам, но эти проблемы в корне
различны.


Ответ 2

Пишут
http://habrahabr.ru/post/137469/
https://msdn.microsoft.com/en-us/library/windows/apps/hh974580.aspx
По идее должно быть проще, чем в андроиде. Интересно было бы услышать комментарии
людей которые писали кросс-платформенные приложения под эти три платформы.


Ответ 3

На iOS на чистом C++ обычно не пишут, т.к. большинство API написанно на Objective-C.
Однако пишут на Objective-C++, который по сути является надстройкой над C++.

Падение приложения при возврате после перехода по внешней ссылке

Разрабатываю приложение для Windows Phone системы, на странице имеется кнопка типа HyperlinkButton , при ее нажатии приложение переходит на определенный Url запуская стандартный браузер, после этого приложение закрывается, и нельзя вернуться в него нажав кнопку Back.
Так же, при совершении данной операции через проект запущенный в VS 12 кнопка Back возвращает в приложение. Но если сделать те же действия в приложении запущенном не через VS(через это приложение задеплоиное на телефоне) то оно закрывается.
В чем может быть причина? В каком направлении копать?
Провел эксперимент с состояниями(suspending /resuming), только на этой станице где переход по Url осуществляется происходит такое, на других все работает нормально. При переходе в suspending все хорошо, как только делаю resuming - валится ошибка такая.
A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in WinRT information: GetNavigationState doesn't support serialization of a parameter type which was passed to Frame.Navigate. A first chance exception of type 'Name.Common.SuspensionManagerException' occurred in A first chance exception of type 'Name.Common.SuspensionManagerException' occurred in mscorlib.ni.dll A first chance exception of type 'Name.Common.SuspensionManagerException' occurred in mscorlib.ni.dll

Ответ

В общем то немного покопав информации в интернетах нарыл такую вещь, что при переходе из одной страницы на другую( посредством Frame.Navigate) необходимо передавать в качестве параметра простейшие данные(строки, числа), большие объекты программа при сворачивании в стек не записывает, оттого и валится такая ошибка.

Можно ли эффективно заниматься разработкой мобильных приложений, работая только с эмуляторами?

Планирую попробовать себя в разработке под мобильные платформы. Но т.к. их несколько (iOS, Windows Phone, Android), то располагать оборудованием под каждую систему для меня проблематично. Можно ли полностью заменить аппараты на этих платформах эмуляторами при разработке? Не возникнут ли проблемы при тестировании приложений?

Ответ

Я жесткий противник выкладывания на продакшн приложений не прошедших тестирования на реальном девайсе, хотя аз грешен сам таковые выкладывал :) Потом расхлебывал очень долго и муторно - подчеркну: расхлебывал всегда. Приложение может прекрасно работать на эмуляторе и вообще не запускаться на реальном устройстве или работать не так - примеров хоть отбавляй. Чтобы быть конкретным приведу примеры из мира Android: В эмуляторе по умолчанию (до версии API=10 по-моему), наличествовал джойстик/стрелочки. В одной аппе автор (лет 5 назад, когда реальных аппаратов было еще мало) использовал этот джойстик, в реальном мире джойстиками оснащены единичные аппараты. Результат понятен. На эмуляторе не выкидывается эксепшн если в UI потоке начать читать через HTTP, на реальном устройстве выше ICS выкидывается эксепшн с требованием разместить чтение вне UI потока. На эмуляторе невозможно протестировать всякие разные датчики (уже говорилось выше) Эмулятор не поддерживает прием многотомных (multipart) SMS сообщений - можно принимать только single part SMS сообщения С другой стороны, и это важно подчеркну, без эмулятора тоже совсем туго. Можно насоздавать тучу эмуляторов и проверить свое приложение в разных экзотических случаях (например как будет работать если не будет карты памяти, что будет если разрешение экрана будет минималистичным и т.д.)

Пишут ли на С++ под iOS и Windows Phone?

Знаю,что под Android пишут. А у iOS и Windows Phone есть аналог NDK, или если писать, то исключительно на ObjC и C#?

Ответ

Пишут.

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

На iOS все очень просто и удобно: C++ спокойно сосуществует в одном проекте и даже в одном файле с Objective-C. Возможно использовать как C++ из кода Objective-C, так и наоборот. Все стандартные библиотеки Objective-C могут быть доступны из C++. Естественно, есть некоторые тонкости, связанные с именованием файлов и подключением заголовочных файлов,а так же с памятью, так как в Objective-C есть сборка мусора, а в C++ нет, но, в целом, это мелочи, разработка достаточно проста и удобна. Не уверен, возможно ли это со Swift.

Под Windows Phone я напрямую не разрабатывал. Насколько мне известно из общения с WinPhone-программистами, чистый C++ там нужно подключать к проекту в виде динамической библиотеки (.dll) со всеми вытекающими проблемами. При этом, саму программу можно писать на C++/CLI (managed C++).

В сравнении с Android разработкой:
Разработка под iOS на C++ в разы удобнее. Под WinPhone я бы сказал - примерно сопоставима по проблемам, но эти проблемы в корне различны.