Ну это клево, когда фирма может для разработки мелких андроид игр нанимать профессионалов с зарплатой в 2-3 000$. Но не все так могут. Гораздо проще научиьт человека выдавать код легко проверяемый тестами, чем нанимать супер профи.
Смею предположить что не только мы используем эникейщиков для простых задач… Судя по тому, как много косяк в существующем софте. Видимо программисты пищущие фотошоп, open office и другой софт не настолько круты и не могут гарантировать что их ошибки не дойдут до продакшена. :)
Елинственное, не понятно, почему вы шлете репорт только на мобильной версии.
На десктопе это даже актуальнее, потому что на декстопе отсутствуют встроенные инстурменты оповещения об ошибке.
«В продакшн не попадет» — откуда такое утверждение?
У нас как раз код с похожей ошибкой мог уйти в продакшн, если бы его замаскировали проверкой и выводом в лог.
Метод активирующий вибрацию содержал ошибку в названии. На устройствах программистов просто нет вибрации и ошибку никто не засек.
Засекли, когда на устройстве тестера игра свалилась в исключение.
Была бы там маскировка и вывод в лог — вполне могли пропустить в продакшн, тесте вполне мог не обратить внимание что вибрация не срабатывает когда должна, а уж лог анализировать в его задачи не входит.
А так исключение, баг репорт, фикс. Все счастливы.
Каким образом вы гарантируете, что баг с такой маскировкой не пройдет мимо тестера?
И вообще, зачем молчать о баге на этапе тестирования?
По поводу конкретного примера — как я уже сказал и в этом примере маскировка совершенно лишняя.
Ну и в целом пример значения не имеет. Примеров таких миллиард и простые эникейщики перетаскивают эти првоерки даже не задумываясь как они будут работать в реальном продукте.
Надо ловить исключения.
Надо продолжать работу, если исключение не критичное.
Речь исключительно о пустых проверках. Лучше не делать вообще ничего, чем максировать ошибку бесполезной проверкой.
Пост и не стал бы писать, но количество примеров с пустыми максировками просто зашкаливает. Каждый автор примеров считает своим долгом напихать в код проверок, которые там не нужны.
Проверка из приведенного примера плоха в своей сути.
Нет никакого смысла писать ошибку в лог. Надо либо возбуждать исключение, либо посылать отчет либо еще как-то реагировать. Но уж точно не ограничиваться выходом с записью в лог, которую никто не увидит.
Под встроенным интрепретатором подразумевается не встроенный в ваше приложение(иначе упоминание интрепретатора в правила вообще не имеет смысла), а встроенное в API. Например, в API встроен интрепретатор JS — его использование не запрещено.
При этом понятно, что фильтр проходит целая куча приложений нарушающих это правило.
Но это похоже на русскую рулетку. Большинство разработчиков русскую рулетку не любят и предпочитают следовать правилам.
и объясняется простым требованием при публикации в AppStore:
An Application may not itself install or launch other executable code by any means, including the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple's Documented APIs and built-in interpreter.
Ну а как можно просто взять и уволиться?
Как минимум это не хорошо.
Сам из проекта за год до ухода предупредил руководство что ухожу.
Потому что просто взять и бросить проект на который подписался — это подстава.
И если мы уж так хотим, чтобы нас не подставляло руководство, то и нам руководство подставлять нельзя.
Ну вы же понимаете разницу между сборкой библиотки и сборки пакета?
NDK в теме фигурирует постольку, поскольку сборщик именно файлы jni(относящиеся к NDK) добавляет в сборку, хотя не должен.
Исходники лежат прямо в корне apk.
ADT самый свежий. Регулярно обновляем. Все сборки за последний месяц с исходниками внутри.
Версия NDK значения не имеет. NDK в сборке пакета не участвует.
Заметка нацелена в первую очередь на тех, кто убдет искать способы собрать freetype. То есть на тех, кто уже знает что это такое.
Делать обзор в заметке особого смысла нет — freetype уже подробно разобран, в том числе и на хабре.
Логичное замечание по поводу Хабов. У них действительно немного дургая направленность.
А вот тег помоему вполне уместен, т.к. явовский код к проекту не добавляется и речь именно про с++.
Надо сначала воспроизвести ситуацию. Разобраться в каких случаях добавляется.
Попробовать собрать гугловские примеры с воспроизведением бага.
Но в ближайшие пару недель я этого точно сделать не смогу: прямо сейчас занимаемся публикацией, не спим практически. :) Простонету сил еще и с выявлением причин разбираться.
Вероятно имеется ввиду сборка больших проектов, над которыми работают полноценные команды.
Когда сборка ведется на отдельном сервере и забирается оттуда отделом QA.
Нет смысла. Маленький инди проект, один программист, один художник. Прикручивать автоматизированную сборку нет смысла.
Собрали, сразу потестировали что ничего не отвалилось — и на публикацию.
Мы только подписанные проверяем. Поэтому врядли подпись влияет.
Изменения jni я сравнить не могу. Последние дни у нас SVN сервер в дауне и я не могу сравнить ревизии.
Тут важна не версия Эклипса, а версия ADT. Не сам же эклипс сборкой занимается. ADT самый свежий.
Что характерно, не каждый рах в сборку исходники пихает. Пока не понимаю что влияет.
Смею предположить что не только мы используем эникейщиков для простых задач… Судя по тому, как много косяк в существующем софте. Видимо программисты пищущие фотошоп, open office и другой софт не настолько круты и не могут гарантировать что их ошибки не дойдут до продакшена. :)
Елинственное, не понятно, почему вы шлете репорт только на мобильной версии.
На десктопе это даже актуальнее, потому что на декстопе отсутствуют встроенные инстурменты оповещения об ошибке.
У нас как раз код с похожей ошибкой мог уйти в продакшн, если бы его замаскировали проверкой и выводом в лог.
Метод активирующий вибрацию содержал ошибку в названии. На устройствах программистов просто нет вибрации и ошибку никто не засек.
Засекли, когда на устройстве тестера игра свалилась в исключение.
Была бы там маскировка и вывод в лог — вполне могли пропустить в продакшн, тесте вполне мог не обратить внимание что вибрация не срабатывает когда должна, а уж лог анализировать в его задачи не входит.
А так исключение, баг репорт, фикс. Все счастливы.
Каким образом вы гарантируете, что баг с такой маскировкой не пройдет мимо тестера?
И вообще, зачем молчать о баге на этапе тестирования?
По поводу конкретного примера — как я уже сказал и в этом примере маскировка совершенно лишняя.
Ну и в целом пример значения не имеет. Примеров таких миллиард и простые эникейщики перетаскивают эти првоерки даже не задумываясь как они будут работать в реальном продукте.
Надо продолжать работу, если исключение не критичное.
Речь исключительно о пустых проверках. Лучше не делать вообще ничего, чем максировать ошибку бесполезной проверкой.
Пост и не стал бы писать, но количество примеров с пустыми максировками просто зашкаливает. Каждый автор примеров считает своим долгом напихать в код проверок, которые там не нужны.
Проверка из приведенного примера плоха в своей сути.
Нет никакого смысла писать ошибку в лог. Надо либо возбуждать исключение, либо посылать отчет либо еще как-то реагировать. Но уж точно не ограничиваться выходом с записью в лог, которую никто не увидит.
При этом понятно, что фильтр проходит целая куча приложений нарушающих это правило.
Но это похоже на русскую рулетку. Большинство разработчиков русскую рулетку не любят и предпочитают следовать правилам.
и объясняется простым требованием при публикации в AppStore:
Как минимум это не хорошо.
Сам из проекта за год до ухода предупредил руководство что ухожу.
Потому что просто взять и бросить проект на который подписался — это подстава.
И если мы уж так хотим, чтобы нас не подставляло руководство, то и нам руководство подставлять нельзя.
NDK в теме фигурирует постольку, поскольку сборщик именно файлы jni(относящиеся к NDK) добавляет в сборку, хотя не должен.
ADT самый свежий. Регулярно обновляем. Все сборки за последний месяц с исходниками внутри.
Версия NDK значения не имеет. NDK в сборке пакета не участвует.
Делать обзор в заметке особого смысла нет — freetype уже подробно разобран, в том числе и на хабре.
А вот тег помоему вполне уместен, т.к. явовский код к проекту не добавляется и речь именно про с++.
Попробовать собрать гугловские примеры с воспроизведением бага.
Но в ближайшие пару недель я этого точно сделать не смогу: прямо сейчас занимаемся публикацией, не спим практически. :) Простонету сил еще и с выявлением причин разбираться.
Когда сборка ведется на отдельном сервере и забирается оттуда отделом QA.
Собрали, сразу потестировали что ничего не отвалилось — и на публикацию.
Изменения jni я сравнить не могу. Последние дни у нас SVN сервер в дауне и я не могу сравнить ревизии.
Что характерно, не каждый рах в сборку исходники пихает. Пока не понимаю что влияет.