Запущена кампания по сбору средств для развития CrystaX NDK

И да, там не идиоты - там просто люди, целенаправленно пытающиеся заставить всех писать на Java под Android.

И именно по этой причине они наконец-то выпустили сишную версию гуглоплей сервисов :)

Причем за то, что Android поддерживает C++ - скажите спасибо мне, т.к. если бы я в 2009-ом году не запустил свой проект, подозреваю, что до сих пор Google NDK не поддерживал бы C++.

А говорили царь ушел. Ан нет, он переименовался :)

но вроде там была поддержка wchar_t.

Лучше бы ее не было. Какова размерность wchar_t на платформе А, а какова размерность на платформе Б? В каком стандарте описан этот wchar_t?

Вы правда думаете, что сумеете сделать лучше?

Вы правда думаете, что все желают тянуть монстра в виде Qt к себе в проект?

При этом получаем действительно кроссплатформенное С++ API

Обычно если прога написана на Qt, то этот печальный факт просто прёт изо всех щелей на всех платформах, где Qt не является стандартом и «нативом». Зато действительно кроссплатформенный API, чо. Можно попонтоваться перед девками.

Я уже молчу про усилия, необходимые чтобы написать аналог.

Я молчу про бессмысленность подобных усилий.

Вы уверены, что когда (если) он будет готов, то будет весить в мегабайтах сильно меньше?

Честно: до готовности сабжа нет дела, т.к. намного быстрее и дешевле найти «жабабыдлокодера» (с) для андройда, чем искать нормального крестовика, разобравшегося в сабже и его тонкостях. А если helloworld будет весить хз сколько и тянуть за собой js-двигло для рисования интерфейса, libboost, gnu'тый код и прочее, то очень многих это, мягко говоря, отпугнёт на недосягаемое расстояние.

Как буст поможет укрепить основу?

Boost - это как минимум хороший test suite. Если работает Boost - то скорее всего будет работать и другой софт. Просто в силу сложности самого Boost. А следовательно - Boost помогает укреплять основу.

В смысле отрезали ненужные куски от BSD libc, которую взяли за основу (из википедии), я не специалист в libc, но вроде там была поддержка wchar_t.

Во-первых, в природе нет «BSD libc». Есть FreeBSD libc, есть OpenBSD libc, есть NetBSD libc. Ни одна из них не была взята за основу для Bionic. Bionic делалась с нуля - но при этом надергали много разных кусков откуда придется - кое-что из FreeBSD, кое-что из OpenBSD, кое-что еще откуда-то. При этом на соответствие стандартам особенное внимание не обращалось.

Ну и wchar_t - с ним вообще поступили прекрасно. Обьявили его typedef-ом к char-у, а все функции (wcscmp, wcsncmp и т.п.) сделали пустыми заглушками.

Давайте забудем про bionic, он используется в нестабильном внутреннем API Андроида, которое свои зависимости наружу не выставляет.

Открываем Android NDK r10d: в toolchains, среди прочих, видим: arm-linux-androideabi-4.9, arm-linux-androideabi-clang3.5. Открываем sources/cxx-stl, в котором находим на выбор реализации libc и libc++, в том числе GNU и преславутый bionic.

Лично я сейчас использую GNU libstdc++ для GCC 4.9, никаких проблем с совместимостью, С++11 во все поля. Что именно вам приходится добавлять в своё NDK для совместимости с libc++, чего не предоставляет этот тулчейн?

Я не вижу смысла объяснять это в десятый раз. Кратко - мы обеспечиваем не «номинальное» соответствие стандартам, а «фактическое». Почитайте на странице проекта, там все это расписано. Еще можно почитать предыдущее обсуждение, там это тоже объясняется.

Boost - это как минимум хороший test suite. Если работает Boost - то скорее всего будет работать и другой софт. Просто в силу сложности самого Boost. А следовательно - Boost помогает укреплять основу.

В этом плане я с вами соглашусь.

Ну и wchar_t - с ним вообще поступили прекрасно.

Ну так если нет стандарта на размер wchar_t, то разработчики поступили вполне логично. Сделали так, как им было быстрее и удобнее. Все равно wchar_t должен сдохнуть. А те, кто его использует должны страдать :)

Ну так если нет стандарта на размер wchar_t, то разработчики поступили вполне логично.

Ну как же нет стандарта? Тип этот в стандартах прописан, функции для работы с wide characters тоже. Там, конечно, нет четкого требования «размер wchar_t должен быть N байт» - ну так это касается и других типов, таких как int. Зато там есть требование «an integral type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales» - и typedef на char этому точно не соответствует.

Все равно wchar_t должен сдохнуть. А те, кто его использует должны страдать :)

Видимо, такие соображения были у разработчиков Android. Тем не менее, жизнь такова, какова она есть - существует большое количество кода, использующего wchar и требовать, чтобы все разом его переписали, несколько неразумно. Тем более, что это все-таки часть стандарта.

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

Да, такое может случиться. Впрочем, такое может случиться и с любым другим проектом, который по какой-либо причине не понравится Google/Apple/MS/you name it. Волков бояться - в лес не ходить.

Это защита платформы через vendor-lock, дающий помимо целого рынка ещё кое-какие плюшки.

Безусловно. Вот только vendor-lock выгоден Google, но не выгоден потребителям (т.е. разработчикам под Android). Поэтому Google вправе стараться всех залочить на себя, а потребители вправе пытаться от этой зависимости избавиться в меру сил и возможностей.

Возмущаться на гугл за игру по правилам современного рынка — неправильно, а то он тоже может возмутиться...

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

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

Ну как же нет стандарта? Тип этот в стандартах прописан, функции для работы с wide characters тоже.

Как под виндой запихнуть в wchar_t символ, которому нужно не 16 бит, а 32 бита? Зачем нужен такой тип? Это хуже, чем бомба замедленного действия.

Тем более, что это все-таки часть стандарта.

Соображения были правильные - переносимость с помощью wchar_t достичь никак нельзя. Для переносимости есть utf-8, для быстрой по-символьной работы есть uint32_t.

Как под виндой запихнуть в wchar_t символ, которому нужно не 16 бит, а 32 бита? Зачем нужен такой тип? Это хуже, чем бомба замедленного действия.

Ну так это не проблема стандарта - это проблема MS. Если использовать gcc/clang, то там с wchar_t проблем нет, он 32-битный.

Я не вижу смысла объяснять это в десятый раз.

Честно прочитал полностью страницу проекта, в итоге отвечу себе сам:

Лично я сейчас использую GNU libstdc++ для GCC 4.9, никаких проблем с совместимостью, С++11 во все поля. Что именно вам приходится добавлять в своё NDK для совместимости с libc++, чего не предоставляет этот тулчейн?

Ответ: ничего. У CrystaX NDK вообще нет никаких преимуществ для стандартной библиотеки C++ по сравнению с вышеупомянутым тулчейном, который идёт в коробке с Android NDK. На странице проекта рассказывается только недостатки про Bionic и разные библиотеки C/C++ вроде POSIX и Boost.

Возможно до выхода текущей версии NDK и был смысл поддерживать аналогичные тулчейны, но вопрос стоит есть ли в этом смысл сейчас для стандартной библиотеки C++.

Вы правда думаете, что все желают тянуть монстра в виде Qt к себе в проект?

Смотря какие критерии монструозности и есть ли альтернативы. Уже сейчас libcrystax.so для ARM весит 3.1 Мб. Сколько он будет весить когда заявленные планы осуществятся?

У CrystaX NDK вообще нет никаких преимуществ для стандартной библиотеки C++ по сравнению с вышеупомянутым тулчейном, который идёт в коробке с Android NDK.

Видимо, невнимательно читали. Прочитайте еще раз. А еще лучше - откройте $NDK/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include/bits/c++config.h и самостоятельно оцените, сколько фич там отключено из-за отсутствия поддержки со стороны системы. А затем поищите в $NDK/sources/cxx-stl/gnu-libstdc++/4.9/include, сколько возможностей стандартной библиотеки C++ от отключенных фич зависит. В нашем же NDK мы особенное внимание уделяем тому, чтоб реализация была «полной», а не «номинальной», как у Google.

И это касается только GNU libstdc++. Про LLVM libc++ я вообще молчу - в Google NDK она настолько порезана, чтобы заставить ее хотя бы собираться (не то чтоб работать!), что в результате при ее использовании программа постоянно падает.

Создание репозитория бинарных сборок
C и C++ API для всей функциональности, доступной на данный момент только через Java

Нет, ну нахрена оно нужно? Из-под андроида сейчас можно выдернуть и заменить на что-то другое всё - процессор, ядро линукса, любой низкоуровневый компонент. И все написанные на Java приложения этого просто НЕ ЗАМЕТЯТ. А вот «C и C++ API» после такой замены ляжет и не встанет. XXI век на дворе! Пора завязывать с этим нативным говнокодом!

Уже сейчас libcrystax.so для ARM весит 3.1 Мб.

Это неверно. Вы говорите о размере библиотеки с отладочной информацией. Пострипанная библиотека, которая идет на девайс - 600 kb.

Из-под андроида сейчас можно выдернуть и заменить на что-то другое всё - процессор, ядро линукса, любой низкоуровневый компонент. И все написанные на Java приложения этого просто НЕ ЗАМЕТЯТ. А вот «C и C++ API» после такой замены ляжет и не встанет.

На чем основано такое заявление? На собственной криворукости?

Видимо, невнимательно читали. Прочитайте еще раз.

Поверьте, внимательно. У вас просто вопрос стандартной библиотеки вообще не раскрывается на главной странице, просто упоминается про поддержку. Ну так в Android NDK C++11/14 тоже есть, стоило бы упомянуть в чём отличие. А так за подробностями самому лезть в config.h, до чего дело может вообще не дойти.

Уже посмотрел, у вас действительно там по ходу bleeding edge.

На чем основано такое заявление? На собственной криворукости?

То есть по-существу тебе сказать уже нечего. Браво! Объясняю на пальцах - для запуска нативной программы на процессоре с другой системой команд тебе нужно эту программу перекомпилировать под этот процессор. В противном случае программа не будет работать. Потому что системы команд разные. Это было удобно во времена маленьких программ, больших компьютеров и некоммерческих исследовательских институтов, когда исходный код было удобно раздавать всем желающим. А сейчас необходимость поддержки старых бинарников тормозит процесс развития современных процессоров. Поэтому нативные языки постепенно вытесняются виртуальными средами исполнения типа .Net или Java. Точно так же, как когда-то ассемблер был вытеснен языками программирования высокого уровня.

Полная поддержка Objective-C v2, включая полностью Cocoa-совместимые (по API) фреймворки

включая загрузку xib/nib, со всеми связями, созданными в хакоде? одних только «по API» маловато будет...

и вообще, это легально?

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

upd: кажется, вот это оно: http://www.apportable.com/

Пострипанная библиотека, которая идет на девайс - 600 kb.

Да, прошу прощения, вы правы. Справедливости ради попробовал стрипануть libQt5Core.so, размер уменьшился на 21%.

https://www.youtube.com/watch?v=dSkhtd6L8RM

$40000: Implementation of Cocoa-compatible CoreText, CoreVideo and CoreServices frameworks (Objective-C).

советую планку поднимать. apportable собрали только на эту «фичу» $2.4M

fix: ну т.е., у них все несколько глобальнее, но, по-моему, вы пытаетесь делать то же самое

включая загрузку xib/nib, со всеми связями, созданными в хакоде? одних только «по API» маловато будет...

В идеале - да. Но это, очевидно, не быстрый путь. Тем не менее, сделать основу, достаточную для определенной категории приложений (игр, например), вполне реально за обозримый срок, и затем продолжать допиливать до большей совместимости.

и вообще, это легально?

А почему нет? Запретов на использование API нет, это подтверждено недавним процессом Oracle vs Google. Исходники тоже закрытые не используются. Все, что берется из других проектов, покрывается свободными разрешительными лицензиями.

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

Да, это Apportable. Наш проект с ними никак не связан, если не считать, что а) они используют libcrystax в своем проекте и б) я с ними лично знаком. Тем не менее, это отдельные проекты. Они нацелены только на «Objective-C on Android», наша цель шире. Кроме того, у них коммерческий проект, а у нас - open source.

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

советую планку поднимать. apportable собрали только на эту «фичу» $2.4M

Поднять планку несложно. Сложнее собрать эти деньги.

fix: ну т.е., у них все несколько глобальнее, но, по-моему, вы пытаетесь делать то же самое

В какой-то степени да. Но все-таки не совсем. Наша главная цель - вовсе не только Objective-C. Мы хотим создать надежный «фундамент» для того, чтобы все нынешнее разнообразие языков, фреймворков и библиотек, доступных под другие POSIX платформы, стало доступно и для Android. Objective-C - это только часть наших намерений.

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

тогда вам имеет смысл написать, в чем именно ваша цель шире, и каким образом вы собираетесь ее достигать.

Нам много что имеет смысл сделать - мы и делаем. Просто не все сразу.

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

Видите ли, дело совсем не в деньгах. Деньги мы все равно поднимем - если не на crowdfunding-е, то на коммерческих заказах. И проект наш будет развиваться, и чем дальше, тем больше будет фич и меньше скептиков. Начатая кампания по сбору средств - это не крик отчаяния, это попытка проинформировать людей, что такой проект есть, и привлечь энтузиастов, готовых нам поверить. Способ «прощупать» сообщество. Тот же Apportable тоже не из космоса явился во всем великолепии, над ним работали. Вот и мы работаем, и уверены, что сможем добиться поставленных целей.

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

Поверьте, внимательно. У вас просто вопрос стандартной библиотеки вообще не раскрывается на главной странице, просто упоминается про поддержку. Ну так в Android NDK C++11/14 тоже есть, стоило бы упомянуть в чём отличие. А так за подробностями самому лезть в config.h, до чего дело может вообще не дойти.

Мне казалось, там довольно ясно это описано. Но раз неясно - спасибо за замечание. Я попробую переформулировать и раскрыть эту тему более внятно (на главной странице).

Объясняю на пальцах - для запуска нативной программы на процессоре с другой системой команд тебе нужно эту программу перекомпилировать под этот процессор. В противном случае программа не будет работать. Потому что системы команд разные. Это было удобно во времена маленьких программ, больших компьютеров и некоммерческих исследовательских институтов, когда исходный код было удобно раздавать всем желающим. А сейчас необходимость поддержки старых бинарников тормозит процесс развития современных процессоров. Поэтому нативные языки постепенно вытесняются виртуальными средами исполнения типа .Net или Java. Точно так же, как когда-то ассемблер был вытеснен языками программирования высокого уровня.

А мужики-то не знают! Спасибо, что объяснили нам, сиволапым, как нынче жить должно. Что бы мы без вас делали - ума не приложу.

И на будущее - не равняйте всех по своему уровню. Мы весь этот ваш bullshit про .Net, Java и прочие всемогуторы давно прошли и прекрасно знаем, что и зачем мы делаем.

давать им пользоваться даже таким, как вы

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

давать им пользоваться даже таким, как вы

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

Перечитал. Да, действительно, выглядит как-то не очень хорошо. Прошу прощения. Коряво выразился. Я имел в виду, что будем давать им пользоваться всем, а не только энтузиастам, поддержавших нас на ранних этапах. «Таким, как вы» - имелось в виду «скептически настроенным». Еще раз прошу прощения за корявость. Обычно я перечитываю то, что пишу, перед тем как нажать кнопку «Отослать», но тут как-то не заметил двусмысленности фразы.

и прочие всемогуторы

«Всемогуторы» это пять! Желаю успеха в вашем проекте, положил немножко $ на это благое дело, хотя, во всяком случае пока, необходимости писать под Андроид у меня нет, а без необходимости заставить себя изучать новую платформу не так легко. Все равно, если ваша работа позволит получить больше хороших программ под андрофоны и прочие таблетки, мне будет приятно, что моя скромная толика в этом посодействовала. Удачи!

Все равно, если ваша работа позволит получить больше хороших программ под андрофоны и прочие таблетки, мне будет приятно, что моя скромная толика в этом посодействовала. Удачи!

Большое спасибо! Очень приятно получить такой отзыв. Особенно на LOR :)

Удачи. Нужно!!!

Ну так это не проблема стандарта - это проблема MS.

Ну пусть будет так :)

Если использовать gcc/clang, то там с wchar_t проблем нет, он 32-битный.

А где в стандарте сказано, сколько бит должен быть wchar_t?

Смотря какие критерии монструозности и есть ли альтернативы. Уже сейчас libcrystax.so для ARM весит 3.1 Мб. Сколько он будет весить когда заявленные планы осуществятся?

Откуда мне знать, я не разработчик crystax ;)

А где в стандарте сказано, сколько бит должен быть wchar_t?

В стандартах C и C++ - нигде. Но там такое не сказано ни для одного типа. Зато, как я уже упоминал, сказано, что wchar_t должен быть «an integral type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales». 32 бита этому требованию удовлетворяют, т.к. в них помещается весь Unicode characters set, а 16 - нет. Поэтому gcc/clang соблюдают стандарт, а MS компиляторы - нет.

Поймите меня правильно - я и сам обеими руками за UTF-8 и в своем коде wchar_t не стремлюсь использовать. Однако стандарт на то и стандарт, что его надо соблюдать. Или менять, если не устраивает. А вся эта самодеятельность на местах, когда разработчики компилятора/библиотек решают «вот здесь мы будем поддерживать стандарт, вот здесь - не будем, а вот здесь рыбу заворачивали» - ведет только к негативным последствиям. Стандарты надо соблюдать, а не плодить ублюдков - это мое твердое мнение, выработанное за многие годы профессиональной деятельности.

wchar_t в msvcrt (и winapi) появился когда весь уникод был 16битный USC-2. поменять на другой размер сейчас проблематично, т.к. обратная совместимость.

имелось в виду «скептически настроенным».

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

мой пойнт был исключительно в том, что ваши цели и возможности в отношении objc/cocoatouch слишком непонятно описаны. а для меня эта фича гораздо более интересна, чем C++.

мой пойнт был исключительно в том, что ваши цели и возможности в отношении objc/cocoatouch слишком непонятно описаны

Честно говоря, не вижу что именно непонятно. Если вы имеете в виду, что должно быть что-то, сильно отличающее нас от Apportable (в разрезе использования Objective-C) - то тут вряд ли что-то можно придумать. Мы просто хотим сделать использование Objective-C под Android максимально легким, и портирование iOS приложений - тоже. Ну и сделать это открытым и доступным для использования всем.

Если же вопрос состоит в том, зачем это делать, если это уже сделано в Apportable, то этот вопрос мне непонятен. Зачем было делать Chrome, если уже был Firefox? Зачем было делать Linux, если уже был Windows? Зачем было делать Android, если уже был Symbian, Windows Mobile и прочие? Продолжать можно долго. Хотим сделать просто потому, что ясно видим, как это можно сделать, и испытываем непреодолимую потребность хоть немножко исправить этот кривой мир.

а для меня эта фича гораздо более интересна, чем C++.

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

Если же вопрос состоит в том, зачем это делать, если это уже сделано в Apportable, то этот вопрос мне непонятен.

нет. вопрос как раз именно в этом — вы собираетесь делать то же самое, но по-своему, либо что-то совсем другое?

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

и если получится — это будет просто охренительно. но вопрос именно в том, _что именно_ вы планируете делать. будет ли совместимость с cocoa touch APIs, tools, file formats, ..., можно ли будет разрабатывать в xcode, и деплоить на андроиде, ...

я, кстати, поднобный инструментарий для себя делаю, но без objc и cocoa — у меня собственные API на С. если бы под андроид была полноценная поддержка objc и corefoundation — я бы с радостью воспользовался.

Без обид, но у вас плохие пледжи

вы собираетесь делать то же самое, но по-своему, либо что-то совсем другое?

Тут вопрос в том, что скрывается под словами «то же самое». Если смотреть с некоторого расстояния - да, то же самое. Если же углубиться в детали - нет, совсем другое. Я просто разбирался с Apportable движком, и видел, как там сделано все на низком уровне. Так вот - так мы делать не будем. Мы будем делать по-своему. Как именно - долго расписывать, да и боюсь, что интереса такие низкоуровневые детали не вызовут. Однако для вас, как для пользователя, все будет выглядеть максимально удобно - т.е. привычно, так же, как вы разрабатываете код для iOS.

будет ли совместимость с cocoa touch APIs, tools, file formats, ..., можно ли будет разрабатывать в xcode, и деплоить на андроиде, ...

Да, мы все это хотим сделать. Иначе просто смысла нет, не так ли? Очевидно, что эта дорога длиной в тысячи миль, и идти по ней придется долго, но нас это не смущает. Сперва мы хотим сделать ограниченный набор функциональности, достаточный, тем не менее, для каких-то практических целей (например, разработка игр). После этого можно будет приниматься за другие задачи - тот же UI, к примеру. И очевидно также что чем больше ресурсов мы привлечем (не имеет значения - финансирование или просто добровольное участие других разработчиков), тем меньше будет временной промежуток между этапами.

Программировать мы умеем (у нас большой опыт за плечами), руководить командами программистов - тоже. Мы знаем how to get things done. Мы не вьюноши с горящими глазами, и не собираемся бесплодно мечтать о стране розовых единорогов, пукающих бабочками. Мы просто знаем, как это сделать, и мы это сделаем.

Ну а от вас (не именно от вас, а от сообщества) мы просим помощи в достижении этих целей, причем помощи взаимовыгодной. Мы, конечно, и без добровольной помощи справимся, но все-таки с помощью дело ловчей пойдет. Да и работать приятнее, когда получаешь позитивный feedback. Вот как-то так.

Без обид, но у вас плохие пледжи

А что именно плохо? Я не отрицаю, мы могли сделать что-то не так, все-таки в crowdfunding-е мы новички. Но хотелось бы понять - что именно не так.

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

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

странно, что такой простой вопрос вызвал у вас столько дискомфорта.

Хмм... Нет, дискомфорта вопросы не вызывали. Было только неясно, в чем именно вопрос. Но старался ответить как можно более развернуто. Не исключаю, впрочем, что кое-где формулировки были резковаты - такое случается, когда отвечаешь «гениальным» комментаторам, и резко переключаешься на ответ другому, более спокойному собеседнику. Если так, то еще раз прошу прощения за резковатый стиль.