То что что-то есть это хорошо. Правда надо почитать какое оно и насколько удобно (тут кстати JNI плохой пример для подражания)
По второму пункту как-то не очень понял. Вы заявляете что уже собранная библиотека будет без проблем работать? Как-то с трудом верится, учитывая что JNI учитывает специфику Java VM которой в .NET VM просто не будет.
А я так понимаю что они (нативные) таки отвалятся. Там же все через JNI сделано. Нет Java машины — нет JNI. К сожалению не в курсе позволяет .NET VM добавлять к .NET классам нативный код.
Вы проверьте от кого ваш Nexus получает обновления. В Google.Play есть специальные программки. Для меня например было сюрпризом когда я узнал что от Samsung. Пришлось шиться образом от Google, и сразу стал Android 4.0.4 и позавчера какое-то минорное обновление прилетело.
>> Однако на деле оказалось, что использовать checked exceptions неудобно — куча танцев с бубном из-за того, что throws является частью сигнатуры метода, а значит, ее приходится учитывать при наследовании или реализации интерфейсов.
Можно ссылки с аргументацией? На мой взгляд это наоборот очень удобная фишка компилятора которая заставляет разработчика обработать все ситуации не рыская по документации как например приходится делать при разработке на C#
На самом деле это возможно, только код будет платформозависимым. Копайте в сторону ptrace. Я свой подобный код начал оформлять в виде библиотеки, но пока как-то не закончил. А на статью материал не тянет, ибо там самого текста с теорией мало но очень много исходного кода
почему сразу клозете? есть куча вариантов: только проснулся, где-нибудь среди людей не желающих светиться и т.д. Вообще вспомните вашу практику использования сотового телефона, часто ли вы пользуетесь им в местах где уместен видеозвонок?
Видеозвонки не получат распространения среди меня, т.к. я как-то не горю желанием что бы собеседник видел меня и место где я нахожусь во время разговора. Думаю я не один такой.
Не раскрыт самый интересный аспект — наследование от ViewGroup и самостоятельная реализация onMeasure и onLayout. Там есть некоторые тонкости въехать в которые только по документации не реально. Мне в свое время пришлось читать исходник LinearLayout — очень помог.
Вот кстати интересно Qt для Android умеет использовать родные View или нет. Пока все приложения что были созданы при помощи Qt которые мне попадались их не использовали и выглядели вообще иначе чем все остальное, что крайне раздражало.
Это NDK-то не костыль. Вы пробовали? Все в конечном счете сводится к тому что для того что бы обращаться к различным возможностям системы (а как правило к ним приходится обращаться часто в серьезном приложении) приходится вызывать Java код, что делать при помощи JNI крайне утомительно.
Единственное где оно оставляет более менее приятные ощущения это разработка игр, где в общем-то все что нужно это рисовать на OpenGL Surface
По второму пункту как-то не очень понял. Вы заявляете что уже собранная библиотека будет без проблем работать? Как-то с трудом верится, учитывая что JNI учитывает специфику Java VM которой в .NET VM просто не будет.
Можно ссылки с аргументацией? На мой взгляд это наоборот очень удобная фишка компилятора которая заставляет разработчика обработать все ситуации не рыская по документации как например приходится делать при разработке на C#
Единственное где оно оставляет более менее приятные ощущения это разработка игр, где в общем-то все что нужно это рисовать на OpenGL Surface