Он считает: у многих, кто говорит об этом, есть личная заинтересованность в выживании нативных мобильных приложений.
А тех, кто подобные статьи пишет, можно обвинять ровно в том же — они заинтересованы как раз в веб, а так же в основании, на котором можно заказчику оправдать, разработки его проекта как веб-приложения или на каком-то «фонгепе», которое будет тормозить, выедать батарею, греть девайс и полностью зависеть от того, какой браузер и какой версии установлен на смартфоне.
Ладно хоть в ведре теперь в основном хром, а в версиях до лолипопа каждый производитель пихал туда свою реализацию браузера и по этой причине такое приложение могло вовсе не работать и приходилось (или так оно и осталось?) в приложение тянуть еще и браузер свой. Это я еще не говорю за полную ущербность самой системы. На примере андроида: ОС запускает ява-машину, в ней запускает приложение веб-браузер, затем в этом браузере запускается конечное приложение. Это как запускать на компе виртуальную машину, а в ней уже запускать игру и ожидать, что производительность будет хотя бы сравнима с запуском напрямую.
Браузерные/фонгепные аппы в андроиде видно сразу по корявому интерфейсу и тормозам, они всегда ущербные. Пока браузер не станет ОС, такого не будет, а когда станет, то еще придется вытеснить с рынка существующие ОС, иначе повторит судьбу винды.
По ходу проблема так и висит (ВМ у меня с аттестатом):
Response 01/26/2015 04:01 AM)
Due to a temporary technical issue, your recent withdrawal to WebMoney request has been declined.
We are sorry for any inconvenience this matter may have caused you.
Once the service has been restored, please contact us to approve your request.
Sincerely,
Marianne
Payoneer Customer Approval Department
Date Create: 01/26/2015 04:00 AM / Date Last Updated: 01/26/2015 04:01 AM
Для блокировки рекламы есть прога sADBlock, можно написать собственный скрипт на NeoSoM или подобном — грохать окна с рекламой, окна про апдейты у меня такой скрипт и давит, а с хостами, как мне кажется, играть можно бесконечно, они просто будут все новые и новые адреса добавлять.
Это Вы еще забываете о том, что может преследоваться и цель скомпрометировать JailBreak как таковой, мол смотрите, кто себе брейкнул телефон, тому грозят страшные вирусы! Ой! Ой! Не надо делать JailBreak! :)
Да, на 16+ уже появился и Equalizer, с помощью которого можно и визуализировать и фильтровать по частотам. Но у меня именно min-sdk=9 и он точно выше 10 не будет поднят ближайшее время… Буду еще сию либу мучить. Как показал тест-апп она реально Low Latency.
4) А для LAME вроде как не требуется коммерческая лицуха (но я в этом вопросе — неспециалист), если апп в итоге некоммерческий, бесплатный на маркете будет, и показ ин-апп рекламы не предвидится. А вот если юзать официальный «франхоферовский» МР3-энкодер, то там уже есть лицензия и зависит она как-то от количества, то ли сжимаемых треков то ли еще чего, не помню точно, но как-то так.
5) Так у меня же тоже AudioRecord для записи, я же исходник привел, а AudioTrack — для воспроизведения. И в AudioRecord тот лиснер таки не работает, во-первых я воочию на практике убедился в этом, тестируя код на НТС, надо учитывать что, возможно, это просто не всех НТС касается, во-вторых на SO о том же пишут.
Странное дело, но в статье:
— в первом методе создания уведомления оно создается с помощью билдера, но при этом в конце используется deprecated метод getNotification() вместо build();
— метод создания уведомления с произвольным отображением написан с использованием deprecated методов, вместо билдера, как предыдущем методе;
— утечки и много попаболи на 100% обеспечены благодаря хранению ссылки на активити в статик-поле;
— хранение lastId и notifications в обычных полях практически бесполезно в разрезе перезапуска приложения при активных уведомлениях, а notifications в статье вообще никак не используется;
— со styles.xml напутано;
— android:launchMode=«singleTop» может привести к неожиданным последствиям, его назначение не раскрыто полностью, хотя это и не цель статьи;
— * This source code was highlighted with Source Code Highlighter — с какого сайта копипейстилось?
Все это как-то не вяжется с заявлением
Давно занимаюсь разработкой под Android
Боюсь данная статья больше вреда принесет неопытным разработчикам, чем пользы. Автор явно поспешил с ее публикацией.
Таки путь есть — Application Context является очень даже синглтоном. В статье же использован Base Context, да еще и в статик-поле хранится — это недопустимо.
Таки да, ошибка тут по 10, но вот про values-v9 — указано верно. Т.е. до 9 апи — юзать стили по-умолчанию, а до 9-го апи — это 2.2/Froyo и ниже, смысла создавать проекты с нижним СДК лвл 8 нет уже давно, таких девайсов в обиходе крайне мало осталось. Т.е. если нижний СДК лвл >=9, то это вообще не требуется, в общие стили сразу внести те, что в values-v9 и все.
Да, спасибо, об этом я действительно умолчал. Подозревал что есть изменения с 5м СДК, кстати это мб баг, который позже исправят и придется еще и values-v22 создавать.
Во-первых, статья об уведомлениях и их билдере, и эту тему я раскрыл, за исключением клонирования темы уведомлений (стили для TextView и пр) согласно установленной темы на устройстве, о чем прокоментировал andkulikov.
Во-вторых, как я написал — так эту проблему я решил для себя и я не писал, что это правильно, но на самом деле, данная ситуация — это вообще отдельная тема, для статьи в тч. Можете попробовать написать, я так понимаю у Вас на эту тему больше опыта.
В-третьих, в моем частном случае юзер авторайзится лишь раз и получает «вечный» токен. Т.е. выяснить запущено ли приложение по факту авторизации я не могу. Идея с сохранением состояния в SharedPrefs, например, куда можно сохранить не факт авторизации, но факт запуска приложения (типа, а зачем нам кузнец isAppRunning()?), как Вы и предлагаете, мне не нравится и вот почему: если мы запишем туда true, что апп запущен, но по какой-то причине апп упадет, его грохнет система, его грохнет какой-то cleaner или антивирус, сядет батарея, случится внезапный ребут, вобщем разное может случиться, это же ведро, то там так true и останется, и тогда вся логика в пролете, потому что мы будем думать, что апп таки запущен. В моем же решении, как раз статик благополучно при этом умрет и в нем будет false, что и требуется. Да, нет защиты по поводу мультипоточности, это решаемо.
Ладно хоть в ведре теперь в основном хром, а в версиях до лолипопа каждый производитель пихал туда свою реализацию браузера и по этой причине такое приложение могло вовсе не работать и приходилось (или так оно и осталось?) в приложение тянуть еще и браузер свой. Это я еще не говорю за полную ущербность самой системы. На примере андроида: ОС запускает ява-машину, в ней запускает приложение веб-браузер, затем в этом браузере запускается конечное приложение. Это как запускать на компе виртуальную машину, а в ней уже запускать игру и ожидать, что производительность будет хотя бы сравнима с запуском напрямую.
Браузерные/фонгепные аппы в андроиде видно сразу по корявому интерфейсу и тормозам, они всегда ущербные. Пока браузер не станет ОС, такого не будет, а когда станет, то еще придется вытеснить с рынка существующие ОС, иначе повторит судьбу винды.
4) А для LAME вроде как не требуется коммерческая лицуха (но я в этом вопросе — неспециалист), если апп в итоге некоммерческий, бесплатный на маркете будет, и показ ин-апп рекламы не предвидится. А вот если юзать официальный «франхоферовский» МР3-энкодер, то там уже есть лицензия и зависит она как-то от количества, то ли сжимаемых треков то ли еще чего, не помню точно, но как-то так.
5) Так у меня же тоже AudioRecord для записи, я же исходник привел, а AudioTrack — для воспроизведения. И в AudioRecord тот лиснер таки не работает, во-первых я воочию на практике убедился в этом, тестируя код на НТС, надо учитывать что, возможно, это просто не всех НТС касается, во-вторых на SO о том же пишут.
— в первом методе создания уведомления оно создается с помощью билдера, но при этом в конце используется deprecated метод getNotification() вместо build();
— метод создания уведомления с произвольным отображением написан с использованием deprecated методов, вместо билдера, как предыдущем методе;
— утечки и много попаболи на 100% обеспечены благодаря хранению ссылки на активити в статик-поле;
— хранение lastId и notifications в обычных полях практически бесполезно в разрезе перезапуска приложения при активных уведомлениях, а notifications в статье вообще никак не используется;
— со styles.xml напутано;
— android:launchMode=«singleTop» может привести к неожиданным последствиям, его назначение не раскрыто полностью, хотя это и не цель статьи;
— * This source code was highlighted with Source Code Highlighter — с какого сайта копипейстилось?
Все это как-то не вяжется с заявлением Боюсь данная статья больше вреда принесет неопытным разработчикам, чем пользы. Автор явно поспешил с ее публикацией.
Во-вторых, как я написал — так эту проблему я решил для себя и я не писал, что это правильно, но на самом деле, данная ситуация — это вообще отдельная тема, для статьи в тч. Можете попробовать написать, я так понимаю у Вас на эту тему больше опыта.
В-третьих, в моем частном случае юзер авторайзится лишь раз и получает «вечный» токен. Т.е. выяснить запущено ли приложение по факту авторизации я не могу. Идея с сохранением состояния в SharedPrefs, например, куда можно сохранить не факт авторизации, но факт запуска приложения (типа, а зачем нам кузнец isAppRunning()?), как Вы и предлагаете, мне не нравится и вот почему: если мы запишем туда true, что апп запущен, но по какой-то причине апп упадет, его грохнет система, его грохнет какой-то cleaner или антивирус, сядет батарея, случится внезапный ребут, вобщем разное может случиться, это же ведро, то там так true и останется, и тогда вся логика в пролете, потому что мы будем думать, что апп таки запущен. В моем же решении, как раз статик благополучно при этом умрет и в нем будет false, что и требуется. Да, нет защиты по поводу мультипоточности, это решаемо.