Вы видите копию треда, сохраненную 13 июня 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Предыдущий тред тут:
https://2ch.hk/pr/res/726626.html (М)
Коротко о главном:
1) Мобильная разработка - это весело.
2) Android Studio & Java - легитимный набор, проверенно временем и поддерживается гуглом.
А также о неглавном:
3) PhoneGap/Ionic/Titanium/ReactNative - имя им javascript, принципы у них разные, первые три попытка в кроссплатформенность одного кода, ReactNative проповедует другой подход, а именно написание разного кода но на одном языке. Популярность у них разная как и размер комьюнити.
4) Xamarin - мультиплатформенная разработка. Попытка серебряной пули на C#. Довольно популярный. Куплено Microsoft. Теперь есть бесплатная версия.
5) BugVM (RIP RoboVM) - идейный наследник ксамарина, а теперь уже и его часть но на Java. Учитывая что Microsoft убила RoboVM, встречаем опенсорсный BugVM.
Отдельного упоминания стоят:
1) Kotlin - Java от JetBrains, новый и стильный язык, куча синтаксического сахара прилагается, есть стримы и делегаты. Хотите писать на котлине? Добро пожаловать в JetBrains и Avito.
Где брать инфу:
Интернет-ресурсы
1) http://developer.android.com/index.html
Наша библия. Документация/небольшие примеры/гайды. Но только на инглише, но это плюс. Минус в том, что это все таки документация с небольшими примерами и гайдами и искать там реализацию чего-то хоть немного сложного нету смысла. Раздел Training как раз для старта.
2) http://stackoverflow.com/
Пользуюсь чаще чем первым сайтом. Можно найти практически все.
3) Есть два вполне вменяемых русскоязычных ресурса. Для старта подходят очень даже.
http://startandroid.ru/
и
http://developer.alexanderklimov.ru/android/
Второй еще и условно бесплатный. Главный плюс - это русский язык, простые гайдики, но переводы классов иногда заставляют фейспалмить.
4) http://habrahabr.ru/ - редко но метко, можно найти годные статьи по каким-то реализациям, или переводы с developer.android. Хотя чего тут объяснять.
5) https://www.udacity.com/ - в треде очевидцы говорили что есть годный курс, но я лично не смотрел.
Книги, их никто не читает, но все советуют только одну
1) The Busy Coder’s Guide to Android Development - в отличии от остальных книг она обновляется, а так как ведро не стоит на месте а хуярит семимильными шагами, то я бы и не советовал другие книги.
А теперь, так как заебали уже всех, гайд для:
>"Я хуярил на делфи 5 лет назад а теперь хочу вкатится в андроид":
Чтоб быстро хоть как-то вникнуть в джаву берешь и гуглишь javarush или codingbat.com.
Можно Эккеля "Философия java" почитать.
Или Хорстманн "Java. Библиотека профессионала" до 7 главы.
Что тебе нужно понять в самой жабе.
Энтри лвл.
1) ООП - сам принцип нужно именно понять, так как ооп язык.
2) Типы данных. Примитивы и ссылочные.
3) Структуры данных - Массивы/коллекции - без них никуда. Полезно почитать про алгоритмы работы коллекций и их сложности.
4) Дженерик типы, они как раз юзаются в коллекциях.
5) Классы/интерфейсы и все вытекающие.
Уже можно быдлокодить потихоньку и учить андроид параллельно с тем что ниже.
Дальше
6) Потоки ввода/вывода (streams). Не путать с тредами(threads).
7) Threads, особо не нужно вникать(в java.util.concurrent можно не лезть, в ведре все равно особо не пригодится), но нужно понять как работает многопоточка и что такое Runnable.
8) Прочитать про паттерны что-то. Начать с listener, adapter, singleton, iterator так как на каждом шагу. Ну и по накатанной.
Уже сделаешь что-то нормальное.
Дальше.
9) Работа с Sqlite, нужна будет в любом случае.
10) Работа с json.
Привет клиент-серверка.
Пишите в треде что добавить.
Мне тоже, но у меня плохо получается находить такие.
Спасибо, посмотрел. Я 19+, а NEW_DOCUMENT флаг 21+, вроде оно почти то же самое, что NEW_TASK.
Хватит плодить говнокодеров.
Добавь про принципы SOLID, MVP, MVC, MVVN паттерны а также книгу Блоха Effective Java.
Не поверишь, читаем :D
Отсоси
>Хватит плодить говнокодеров.
Ты так говоришь будто бы от меня или тебя что-то зависит. Я все время натыкаюсь на пликухи где у апликейшн класса или активити пишется паблик статик метод гетКонтекст и потом юзается внутри разных модулей.
>SOLID, MVP, MVC, MVVN
Как-то ты немного хуево приоритеты расствил.
Солид еще ладно, но это как мантра.
>MVP, MVC, MVVN
Сейчас в каждой второй статье этого говна навалом.
>книгу Блоха Effective Java
Давай тогда еще паттерны Gof, и еще кучу всего из мира программирования.
> где у апликейшн класса пишется паблик статик метод гетКонтекст
И как же по другому получить контекст приложения из статик мест? Можно конечно сделать ехал синглтон через синглтон с DI, но я на это дохуя времени потрачу.
> у апликейшн класса пишется паблик статик метод гетКонтекс
Ничего плохого в этом нет, в iOS такое метод есть по умолчанию (UIApplication.sharedApplication)
Не надо у быдлоты ложное впечатление простоты программирования, и андроид разработки в частности создавать. Пишем все сюда, и GOF, и Java Concurrency in practice. Также можно добавить Макконелла, т-ща Фаулера. А то потом это говно начитается стартандроида, насоздает за полгода неподдерживаемое говно и тебе на новом месте работы приходится его расхлебывать.
Про фрагменты писать в ходе современных дискуссий аж в самой шапке моветон
https://corner.squareup.com/2014/10/advocating-against-android-fragments.html
Возвращаясь к теме меня-мудака и кучи фаргментов, после баттернайфа стало получше, спасибо. Что еще можно сделать и нужно ли юзать Glide.clear(%imageViewName%); в onDestroyView ?
В жопу, покажи мне хоть одно адекватное приложение с таким подходом. Почему гуглы пилять передачу контекста аргументами, а ты такой дохуя умный решил пиздануть статик переменной?
Если пофилософствовать то в этом говне Google виноваты в частности, нахера было God Object создавать такой. После частичного изучения IOS возникло впечатление, что там меньше индусов к Api подпускали.
Шли в жопу свою работу если так дела обстоят
>тебе на новом месте работы приходится его расхлебывать.
Так всегда, правда я и в своем коде не уверен. Но пытаюсь писать без брейнфака.
>Java Concurrency in practice
Ну это ты уже тралишь. Явно лишнее. Хотя может понадобится на каких-то своих йобавелосипедах. Но тогда еще и литературу по с++ добавить можно.
Гугловцы и провайдеры и async-таски используют и на java пишут,
но мы то знаем что это параша.
>И как же по другому получить контекст приложения из статик мест?
Я тебе уже отписал на сообщение, но потом понял что меня смутило, каких нахуй статик мест? Я даже не помню чтоб у меня такие были. Статик методы только для генерации статик данных и всяких фабрик использую, ну еще всякие утилсы.
Потому что ты говно пишешь, которое работает только из-за того что аппликейшн класс это синглтон.
>>743371
Не такая параша как статический гетконтекст.
> покажи мне хоть одно адекватное приложение с таким подходом
Ой, нашел.
https://github.com/DrKLO/Telegram/blob/06473773a6f415c23fbd93d51996393b7e3ea626/TMessagesProj/src/main/java/org/telegram/messenger/ApplicationLoader.java
> public static volatile Context applicationContext;
телеграм - не адекватное приложение
Будь тоньше.
А если ты и вправду думаешь что это хороший пример, то самое время вытаскивать голову из жопы.
Уже ответил два поста придурок.
Хотя бы базовые принципы должны все знать, что такое mutex, синхронизация. Типы ссылок (сильные, слабые, атомик...). Синхронайзд методы, эксекуторы. Это все на практике не раз мной использовалось. На одних асинк тасках и интент сервисах без знания основ далеко не уедешь.
> Вопрос из разряда почему нельзя называть переменные с большой буквы.
Значит ты признаешь себя безпруфным-кукаретиком,
который "где-то что-то слышал", но так и не понял почему?
другой-анон
Ну хуй знает, тот же атомик сам по себе костыль. В джаве во всяком случае.
А так из перечисленного это основы, а в книге вангую начинабтся семафоры и пошло поехало.
Для обычных апликух я даже хз зачем это юзать.
А потом 95% херачат в коде handler в виде анонимного внутреннего класса. Чем хуево это, думаю не стоит объяснять?
Вы какие-то дауны. Нет правда, тебе самом логика не подсказывает что делать статик геттер для поля которое без самого экземпляра класса не существует неправильно?
Этот трюк работает только с апликейшн который синглтон.
Но с таким успехом можно педалить методы и в активити, и вызывать из только внутри адаптеров на этих активити.
Оно сработает, но за такое в лицо плевать нужно.
Atomic не костыль а вполне себе употребимая вещь в определенных ситуациях http://stackoverflow.com/questions/3964211/when-to-use-atomicreference-in-java
правильное использование Bitmap, в том числе не использование оперативки для размещения изображения. Использование библиотеки андроида, там почти всё есть. В крайнем случае можно на c++ вынести обработку, нативная память не учитывается
Ты про андроид хендлер сейчас?
Ты про то что будет ссылка на парент класс?
На самом деле озадачил, всегда хуярил андроид хендлеры как анонимные.
Понял, но я вообще говорил о атомиинтеджерах и тд.
> Но с таким успехом можно педалить методы и в активити
Во первых, хули ты сваливаешь все в один котел, мы с тобой говорим конкретно про Application.
> без самого экземпляра класса не существует неправильно?
Во вторых ты видимо не вкурсе, что
1) На все приложение есть только ОДИН экземпляр Application
2) Он создается один раз и не разрушается никогда (на него есть статические ссылки даже внутри Android)
3) Его метод onCreate(...) вызывается ВСЕГДА до создания любых активитей/провайдеров/ресиверов
Про них.
Любой внутренний не статик класс содержит неявную ссылку на внешний класс. В результате получаются мемори лики. Кстати любители ещё часто асинхронный таски хуячить в виде анонимных внутренних классов любят
Ты такой долбоеб что мне даже впадло тебе что-то писать.
Вот ты умудрился поумничать, но не прочитал то что пишу я. Похуй что тут я назвал сингтоном сингл энтити.
>Этот трюк работает только с апликейшн который синглтон.
Но также можно делать с активити, один в один, если юзать геттер в элементах которые отвечают только этому активити(мы так и делаем когда передаем его через конструктор но нахуй это нам, у нас же есть статик геттеры)
Не пизди друг. Если у тебя в приложении например активити создаётся в отдельном процессе, то для неё отдельный новый экземпляр аппликейшена создаётся. Соответственно правильнее говорить создаётся один аппликейшена для каждого процесса. Нубье суда, ещё и пальцы гнет.
Ну я об этом написал
>Ты про то что будет ссылка на парент класс?
Получается иннер класс и внешний держат ссылки на друг друга и всегда висят в памяти?
>Если у тебя в приложении например активити создаётся в отдельном процессе
Ой блять ты как собрался ссылками между процессами обмениваться?
Нахуй ты это вообще сюда приплел?
Кого ебет, суть в том что это говно не работает.
Хуйню потому что написал. С процессами видно не работал, приложения визитки одни делал.
Плиз хватит маневрировать и просто ответь на вопрос:
"Что конкретно плохого в использование статической ссылки на Application?
Чини детектор, я делал приложения с несколькими процессами и знаю как это работает.
Так что ты меня на понт не возьмешь ;)
Еще раз, к чему ты приплел процессы?
Какая нахуй разница, сколько процессов если мне нужно допустим получить путь на локальный-кэш-каталог?
И что?
Это ДВА РАЗНЫХ ПРОЦЕССА, они располагаются В РАЗНОЙ памяти.
Формально У КАЖДОГО процесса, есть только ОДИН экземпляр Application.
Эту Хуйню потому что написал:
"Во вторых ты видимо не вкурсе, что
1) На все приложение есть только ОДИН экземпляр Application"
>The Application class, or your subclass of the Application class, is instantiated before any other class when the process for your application/package is created.
Kotlin Koans - набор тестов для обучения
https://kotlinlang.org/docs/tutorials/koans.html (также есть плагин для Idea)
Вот сравнение одного и того кода для Android на 4 языках (да АНОН сейчас есть выбор)
https://github.com/SidneyXu/AndroidDemoIn4Languages
Вот видосики на youtube (под попкорн)
https://www.youtube.com/playlist?list=PLVe-2wcL84b8pj7VOoa-6L9Q0sDjibdoF
http://www.philosophicalhacker.com/2015/07/14/why-static-references-to-application-contexts-are-probably-not-the-best-idea/
Они до тебя знать не знали, что приложение в Android может работать в нескольких процессах.
Ой, кто-то сохранил мой пост. Держись товарищ, наше дело правое :)
То что кто-то не может во второй абзац в доке, их проблемы, нет? Но суть не поменялась, новый процесс запускает новый аппликейшн.
Всю статью можно свести к одной фразе: "Статическая ссылка на Application мешает Unit-тестированию".
Удивительно что ты сам не мог это сформулировать (может ты не пишешь тесты).
Ну и автор подтвердил что утечки памяти в таком случае это миф.
Никто и не говорил про утечки памяти.
И ты не понял сути, юнит тесты как следствие забивание хуи на принципы программирования - говнокод.
И нет, тесты я не пишу.
Пока буду юзать джаву, как разберусь может и котлин испытаю.
Там в настройках нужно в бубен побить - дебаг мод включится. Вниз, вперед, вниз, вперед, a попробуй.
А почему у тебя это вызывает такую трудность? Что ты пробовал и в чем возник "затор неосиляторства"?
Как объяснить людям что так делать не правильно, когда они кричат "но работает же"?
> Пишите в треде что добавить.
Android Game Development
http://docs.unity3d.com/ru/current/Manual/android-GettingStarted.html
https://docs.unrealengine.com/latest/INT/Platforms/Android/index.html
Двачую этого чистюлю
Ну это такая хорошая практика делать все иннер классы в адаптерах и активити статиком, чтоб не было неявных ссылок.
Пользуйся и других учи.
Но это говнокод!
Просто я, учивжий жабу и прогу в целом, увидев такой подход внутри себя почувствовал негодования, я никогда не говорил что это не работает. Но я всегда буду говорить что это неправильно.
> Но это говнокод!
Говно-код - это то что в огромных количествах генерируют джуны (без присмотра старших).
А уж точно не статик-геттер в Appication.
Не знаю, но мне оно кажется вырвиглазным дерьмом.
Также можно делать статик ссылки на шаред преференсы и тд через апликейшн.
Сроки?
А можно как-то сделать так, чтобы я кидал апк на свой кирпич, запускал его и видел, из-за какой строки оно крашится и текст ошибки?
Поискал в гугле - нашел, что нужно поставить adapter.hasStableIds(true) - действительно, теперь Recycler скроллится очень плавно, но зато глючит просто пиздец как.
К примеру notifyItemChanged приводит к удалению элемента списка.
В списке из 50 разных элементов отображаются только 2 и они чередуются.
Откатываться к обычному списку или есть решения?
>Но вдруг оказалось, что его производительность при скролле весьма хуевая.
Ох помню спорили в скайпе что наоборот он производительнее.
Если честно я и сам не замечал хуевость работы ресайклервью, у тебя елементы убер тяжелые или что?
CardView внутри которого ImageView, linear layout из 10 TextView.
При скролле неприятно тормозит, причем так, как будто сборщик мусора охуевает.
Переделаю завтра на обычный список - скорее всего тормозить не будет.
Точно, нагуглил, что стактрейс можно засунут ьв логкат, а логкат сохранить! Не знал об этом раньше.
А можешь рассказать про фабрик.ио, я что-то гуглил, так и не понял, что это?
fabric.io - когда выпустишь приложение, эта штука будет собирать багрепорты в фоне. Причем такие же подробные как и LogCat.
>выпустишь
В смысле, через гугл плей или просто когда залью его в этот фабрик?
Я хотел отслеживать краши до релиза. Добавил метод, пожмакал его, добавил другой метод, пожмакал.
Я так понял, залитые туда приложения не приватные и доступны всем? Приватность вроде за деньги или я не понял?
fabric.io - это всего лишь программный модуль, который ты можешь вставить в свое приложение, чтобы получать информацию о крашах.
> инфлейты в onBindViewHolder
Это же пиздец, разве нет?
Я бы на твоем месте запихнул в айтем ресайклервью, но с wrap_content по высоте. Он хотя бы сможет переиспользовать вьюхи песен в рамках одного вьюхолдера, а не в каждом бинде их инфлейтить.
Ну и вместо setVisibility сделал бы viewTyp'ы.
Твоя реализация будет и на обычном ListView лагать, вот че.
Не делай инфлеты, вставь recyclerView прямо в элемент списка. Его адаптер будет на каждом бинде переиспользовать свои вьюхи.
setVisibility(GONE) вызывают перерасчет разметки элемента списка, что тоже будет затормаживать скролл. Вместо него используй разные viewType и разные вьюхолдеры.
>>743764
1. RecyclerView работает через NestedScrollView, а у него проблем с вложенностью нет.
2. У него же wrap_content, там скролла не будет, он займет всю высоту своих элементов.
Ага, спасибо. Завтра сделаю - отпишусь.
Спасибо, гуру!
>setVisibility(GONE) вызывают перерасчет разметки элемента списка, что тоже будет затормаживать скролл.
Тут поподробнее.
Это как-то тупо делать две разных вью если мне допустим нужно добавить убирать какую-то мелочь. Тогда вьютайпов будет дохуя.
Да и у него рейсайклервью внезапно тоже должен вызывать перерасчет элемента списка.
>2. У него же wrap_content, там скролла не будет, он займет всю высоту своих элементов.
Вспомнил что не так давно это не работало из коробки и взлольнул.
> Вспомнил что не так давно это не работало из коробки и взлольнул.
Но теперь то работает!
> Да и у него рейсайклервью внезапно тоже должен вызывать перерасчет элемента списка
А, ну да. А еще чет я загнул с визибилити, ведь несколько реквест лейаутов скомпануются через isLayoutRequested и отработают один раз.
Да и я первый раз слышу что нельзя сет визибилити в итемах делать, так что хз.
Даже на стековерфлове в примерах так делают.
У тебя есть ресайлервью с итемами в которых будет ресайлервью. Уже во вложенном ресайклервью делаешь обычный адаптер с инфлейтом в онкриейтвью, но не в онбинд.
Это же костыль, не ? Не проще ли просто сделать проверку на то, уже был заинфлейчен или нет лэйаут ?
Ну такое, такой проверкой ты просто будешь эмулировать работу листа, учитывая что еще нужно делать проверку сколько итемов показать, сколько спрятать.
Так что ресайклервью заюзать выглядит ровнее чем руками педалить велосипед.
Вопрос по 2-му скрину.
Вот код
http://ideone.com/rkImys
telegram.me/AndroidChan
val intent = Intent(this, MyService::class.java)
P.S.
Советую убрать "abstract" перед "class MyService" иначе у тебя упадет при старте.
> Этот трюк работает только с апликейшн который синглтон.
Верно. Аппликейшен существует всегда во время работы приложения в единственном экземпляре. Так в чём проблема сделать его синглтоном?
> Но с таким успехом можно педалить методы и в активити, и вызывать из только внутри адаптеров на этих активити.
Типо ты приравнял два разных случая и это уже называется аргументом? Активити не всегда существует во время существования процесса, одной и той же активити может быть много, это потенциальная ошибка и новая условность в стиле "этот метод работает только когда существует активити, не вызывайте его в другое время, спасибо".
Пиздец, нашёл, до чего доебаться.
Найс пердёж в лужу.
> setVisibility(GONE) вызывают перерасчет разметки элемента списка, что тоже будет затормаживать скролл.
После getView вернее, его аналога в RV, я им не пользовался будет перерасчитываться разметка независимо от того, вызывал ты setVisibility или нет. Это очень быстрая операция, явно не туда смотреть нужно.
Хуй знает, я в скайпе сижу, но там скорее всего нету или очень мало двачеров, а тут даже название намекает на какую-то хуйню.
>Активити не всегда существует во время существования процесса
Если юзать статик геттер для активити контекста в каком-то адаптере который заведомо в этой активити все будет работать.
>Так в чём проблема сделать его синглтоном?
В том что апликейшн тут сингл энтити. А синглтон создается при первом обращении, тут же апликейшн создается просто ДО первого вызова.
Я статью уже кидал, работать то оно работает, но это виляние жопой и говно по большому счету с точки зрения красоты кода.
> Если юзать статик геттер для активити контекста в каком-то адаптере который заведомо в этой активити все будет работать.
А если активити 2 штуки?
Ну и про эту условность я уже говорил.
> В том что апликейшн тут сингл энтити. А синглтон создается при первом обращении
Не обязательно. С точки зрения работы вм это так, но вообще синглтон не обязан быть ленивым.
> Я статью уже кидал, работать то оно работает, но это виляние жопой и говно по большому счету с точки зрения красоты кода.
В статье тоже просто мнение-по-поводу, а не весомые аргументы. Как и у тебя. Тебе не нравится — ок.
Вот такой тебе вопрос: а если у меня есть синглтон, который работает с ресурсами (строки и картинки достает, например) или с сервисами системными, как ты предлагаешь его инициализировать? Контекст в getInstance + ленивая инициализация? Ради одной красоты придётся терять другую.
>А если активити 2 штуки?
>Ну и про эту условность я уже говорил.
Есть такой ньюанс, но опять же я сам видел что люди такое делают.
>Не обязательно. С точки зрения работы вм это так, но вообще синглтон не обязан быть ленивым.
Вот только это не совсем синглтон.
>В статье тоже просто мнение-по-поводу, а не весомые аргументы. Как и у тебя. Тебе не нравится — ок.
Там тебе прямым текстом написали что ломает инкапсуляцию. Это не мнение, но очевидный факт, и да инкапсуляция это не про работу программы, следовательно ее можно ломать?
>Контекст в getInstance + ленивая инициализация? Ради одной красоты придётся терять другую.
Так и делал бы, андроид сдк сделан так что контекст будет откуда подтянуть.
> App.getShardInstance();
> (нарушение) красоты кода
Так и представляю:
Проект из over100 классов "джуниор-говно"-лапша-кода, а тебя ебет только статик геттер.
P.S.
Ребята вы уже заебали сратся на эту тему.
Я вижу статики в апликейшене хуярят все ИТТ?
> Вот только это не совсем синглтон.
По сути — одно и то же. Лёгким добавлением 1 метода он превращается в псевдо-синглтон. Формально он был создан не как синглтон, но по своему функционированию он ничем не отличается.
> Там тебе прямым текстом написали что ломает инкапсуляцию. Это не мнение, но очевидный факт, и да инкапсуляция это не про работу программы, следовательно ее можно ломать?
Синглтоны тоже ломают икапсуляцию, получается?
> Так и делал бы, андроид сдк сделан так что контекст будет откуда подтянуть.
Факт в том, что для ленивой инициализации тебе придётся городить больше лишнего кода, вместо того, чтобы сделать всё просто и наслаждаться этим.
>Синглтоны тоже ломают икапсуляцию, получается?
Синглтон так-то в какой0то мере антипатерн.
>Факт в том, что для ленивой инициализации тебе придётся городить больше лишнего кода, вместо того, чтобы сделать всё просто и наслаждаться этим.
Вся сложность будет в получении контекста на самом деле для гетинстанса(сейчас мы говорим про твой синглтон для доступа к ресурсам), но сам посмотри, если не тулить работу с ресурсами где попало читай классах отвязанных от андроид сдк, то даже кода особо больше не будет.
Синглтону нередко требуется работать с андроид сдк, а тянуть до него контекст — лишний гемморой.
Хотя я изначально реализацию синглтона имел в виду со всеми даблчекедлоками.
Зачем делать WeakReference, когда можно просто сделать метод release(), вк отором обнулить всю хуйню, и вызвать его в onDestroy() активити, сервиса, фрагмента...
А что такого? Там же не сложная операция, а по сути одна строчка смысл которой сводится к:
mySuperHandler.activity = null; Это никак не сомжет навредить удалению, или я чего-то не выкупаю?
onDestory у активити не вызывается же только в одном случае, когда процесс полностью умирает. А если процесс умирает, то уже нечему утекать.
Вот такая хуйня с картами, ничего не крашится, но они очень лагают.
Сохранить можно куда угодно раньше так тестил бд, и по сути считать ее тоже можно, а потом дублировать записи из нее в свою бд.
Но вот прям создать бд с нуля по тому что у тебя в экстернал сторейдж плохая идея, да и не думаю что возможно.
Ну и забыл добавить, что работать ты все равно будешь со своей базой а не той которая на диске, но можешь делать бекапы в нее время от времени.
Анон лучше не надо, это решение из прошлого века, юзай Android Backup.
В Android 6.0 и выше придется каждый раз проверять что у тебя есть права на запись карты памяти и если их нет запрашивать явно у юзера.
И сейчас юзер может спокойно их НЕ дать или в любой момент забрать.
У меня сейчас build target 22, все разрешения по умолчанию включены.
Проблема в том, что мне нужно хранить кучу всякой инфы, которая очень важна для пользователя.
И он сильно разочаруется, если после удаление и установки приложения эта инфа пропадёт.
Ну погугли придурок, может слова именитых программистов донесут до тебя правду и ты не будешь вылазить из под шконки со своими картинками?
Почему вы сами это в облаке не храните?
Андроид бекап дали чисто для удобства, сохранять бд в экстернал сторейдж костыль.
> может слова именитых программистов донесут до тебя правду и ты не будешь вылазить из под шконки со своими картинками
Ох, лол. Как я с тебя проиграл.
Как думаешь, кто изображен на моей картинке?
Ты какой-то ебанутый если думаешь что кто-то прогеров в лицо знает.
А синглтон антипатерном считаться может, так что увы ты идешь нахуй.
Что мне это даст?
Сейчас это приложение замечательно работает и на 4.3 и на 6.0.1.
Вырубать разрешения смысла нет.
Т.к. их всего два и без них приложение потеряет смысл.
Случайные пользователи - могут и рубануть, если вспомнят про такую функцию.
По факту - это абсолютно никому не нужно.
Мы тебе тут рабочие решения пытемся подсказать, а не хуйню которая вылетит от действий самого юзера.
Под твои нужды нужно делать бекенд. Тем более почему тебе андроид бекап не нравится?
Спасибо! Пойду посмотрю как с её помощью забэкапить sqlite базу.
Я на своем нексусе могу и тебе (с твоим 22) рубануть :)
Ты тогда будешь вместо карты-памяти получать заглушку.
Да уж. Если пользователи увидят при запуске приложения: "Разрешить доступ к файлам, фото и мультимедиа на устройстве" - то очевидно, большинство ответят нет.
Хотя приложение ничего криминального не делает.
Про разрешение GPS - вообще молчу. Хотя не шпионит, ага.
Плохая эта идея - runtime permissions.
Самое тупое, что для MediaStore.ACTION_IMAGE_CAPTURE тоже нужен рантаим пермишн камеры, хотя мы переходим вообще в другое приложение.
Соси хуй быдло
> Плохая эта идея - runtime permissions.
Хорошая, правильная и давно необходимая.
Нехуй запрашивать у пользователя двадцать разрешений во время установки. Запрашивай при необходимости. Когда пользователь захочет поставить фоточку на аватарку, тогда и проси соответствующее разрешение. Не даст — показывай диалог с объяснением.
Использовать API 22 — это тупиковый путь. Либо адаптируйся к изменениям, либо вон из профессии. Пиши какой-нибудь ынтырпрайз на JEE: там всё тихо и спокойно, никаких изменений.
Анончик, спасибо, я поставил крашлитикс, и теперь могу видеть, где упала моя хуйня. Здорово!
А можно еще как-то видеть, где моя хуйня все сделала правильно и не крашнулась? Ну типа
public void onClick(View v) {
Log.d(TAG, "вызываю метод onClick");
}
Я пока вижу вариант в тоасты это засунуть. Или это в фабрике тоже можно откуда-то вывести? Я не нашел.
Пользователи действуют иначе - им нужно, чтобы всё работало.
В моём случае невозможно запросить разрешения где-то, кроме как при старте приложения.
Т.к. оно постоянно пишет данные в базу (база может быть большая, она лежит в external storage).
Приложению важно с момента запуска знать координаты пользователя.
Всё как всегда - пользователь не должен знать, что там внутри.
Кстати, помню, что для google maps api v2 тоже требуется Write external storage.
С версии Google Play Services 8.3 оно больше не нужно.
Вот наверное весело людям объяснять, что разрешение на доступ к файлам нужно для кеширования карт. 99% Не поймут ничего, остальные подумают, что их хотят наебать.
Используй Timber. Подсадишь ему специальное дерево, которое скидывает логи в крашлитикс.
Сомневаюсь, тогда люди будут пидорить fabric.io запросами в вечном цикле.
Им это вряд ли всралось.
Конечно. Когда ты пишешь Timber.d/i/e/... вызывается метод log твоего дерева, и тaм можно вызвать Crashylitics.log или что там есть.
Таки зашел в админку крашлитикса, там есть и обычные ивенты, просто всегда юзал только краши.
разве дядя боб одобряет синглтон?
Мне кажется в google-services.json все написано за нас, у тебя версии грейдла и плагина гугловских сревисов не протухли?
Всю жизнь я учил языки методом: "качаю книжку и читаю с первых страниц/смотрю туториал с первой серии". В итоге писал кучу хелловорлдов, но так толком нихуя и не выучил, ибо все дропал. Хотя интерес был, но угасал из-за монотонных заданий для нубов со всякими массивами, циклами и т.д, и т.п.
Сейчас учу ведройд методом "хочу отправку смс в приложении -- гуглю "how to sent sms android programming" и чуть ли не копирую код, попутно пытаясь понимать, что за что отвечает. Хочу еще какое-нить говно -- гуглю и копипащу". Но понимаю, конечно, не все. С Джавы порой вообще охуеваю, видя вообще доселе неизвестные методы и операторы. Но тем не менее, после небольшого пердолинга все работает и приложение получается.
Ну и вот сам вопрос: какой способ обучения лучше? Вот так вот дальше ставить себе задачи и прорываться через гугл или пересиливать себя и читать учебники от корки до корки, чтобы знать всю мат.часть. Ведь, например, если проблемой неработающей программы будет проблема с потоками какими-нибудь, я этого никогда не узнаю и не допру, потому что это сложная тема и я ее еще не изучал.
И если идти по второму пути, то каков шанс не соснуть на собеседовании, когда я почувствую себя достаточно крутым и захочу устроиться на работу?
Надеюсь на твою помощь и мудрость, анон
Книжка по джаве + что то типа старт андроида для основ и потом читать/пробовать всякие крутые штуки
1) делаешь запрос на сервер (допустим в asynctask).
Один раз при показе активити (пробрось onCreated в презентер).
2) данные загружаются -> преобразуются -> сохраняются в базу
3) asynctask кидает broadcast-message (или через ContentResolver.notifyChange)
4) обработчик (допустим cursorloader) читает данные из базы и показывает пользователю.
P.S.
Как вариант можешь отключить поворот.
Здраво рассуди "что дает пользователю поворот экрана, является ли это преимуществом?",
а не делай просто "потому что можешь" (потом придется это все поддерживать и отлаживать).
O_o Эти локальные переменный в начале метода "аля паскаль",
пробудили у меня воспоминания из далекого детства :)
Ты опять с импортами проебался - проверь что туда точно передается наследник
android.location.LocationListener (или скинь файл целиком).
@Override
public long getItemId(int position) {
return position;
}
Он вообще имеет смысл ?
ИМХО, бери телефон, под планшеты обычно после заказа под телефон просят сделать. Или, как лучше, и то и то
Спасибо, хорошая идея
Утечка идет скорее при переходе на новый экран ( я вроде заюзал flow, соответственно, юзаю unbind, удаляю все данные из адаптера даже, черт его знает что делать )
Хотя сейчас вроде как смотрю, и просто некоторое количество переходов загрузка памяти растет, а потом останавливается на каком-то уровне. Но по-моему 60мб это пиздец как много для двух экранов с параллакс хэдерами в одном из которых есть список из 25 элементов каждый с картинкой
Флов не юзал и не планирую, так что ничем помочь не могу. А 60 метров на два экрана разве что с картой может быть.
Поправь если ошибаюсь, объявлять переменные вначале метода общепринятое правило.
Да вроде везде использую правильные контексты, ничего никуда не должно улетать лишнего.
Использую glide, но там вроде подобного нету. Пикассо просто для примера привел
Хм, может в Pascal (там это на уровне языка) или Basic.
Сейчас занят что-бы пруфы искать, но насколько я помню из "чисты код" и "рефакторинг" Фаулера:
1) лок. переменные надо как можно ближе к месту использования
У Фаулера была мысль вообще их не заводить, а получать лок. данные через отдельный метод.
2) их НЕ рекомендуется использовать повторно, особенно для др. целей.
Для этого в разных языках есть val/let - одноразовое присваивание.
Советую тебе вырубать модули и смотреть ушла ли утечка.
Убери релейтив и посмотри, таким образом поймешь где копать.
Наоборот, это может помочь, вот были у тебя элементы {"id": 1}, {"id": 2}, {"id": 101}, а потом стали элементы {"id": 103}, {"id": 2}, {"id": 101}, он будет уверен в закешериванных шутках и не будет играть лишних анимаций.
Там только view и есть, лол. И тестовые данные. Больше ничего. Вообще думаю запилить все по-новой чтобы не ебаться
Ой добавь меня ^urbillgates2002ANUSli\xsvePUNCTUMAf?com
Я твое репозиторий выкачаю и перезалью на github, аночиками на радость.
Ну для начала методы нужно разбивать на методы-задачи, тогда и переменная будет сначала и не перечить словам Фаулера.
Сука не тупи блять, вью у него только есть.
Выпили ресакйлервью и посмотри, если не будет то начинай выпиливать глайд и тд и тп.
Хороший маневр, только это никак не связано с требование принудительно описывать переменный в начале метода.
Ты кстати про второй пункт забыл.
Не забыл, если у тебя метод решает какую-то задачу, то переиспользовать их в другой задаче внезапно не будет возможности.
Да и я боюсь сам компилятор оптимизирует работу с переменными. Тут правда я уже совсем не шарю как, но вполне возможно он определит что твоя переменная уже не используется но создалась новая. В форе он же определяет что переменная создается новая и не создает ее.
Есть там такое точно, влючено ли по дефолту? Вряд ли
http://ideone.com/bVClzY
Блять, как же в ведре немного запутано все это. Вот под EE с джавой, мне кажется, проще.
JetBrains есть еще где тулинг подкрутить, у тебя показывается не "исходная" ошибка, а лишь следствие.
На самом деле проблема в том что у mLocationManager тип "LocationManager?", а smartcast не работает так это изменяемая переменная.
(теор. другой поток может занулить ее между проверкой и использованием).
Так что можешь спокойно убрать "if (mLocationManager != null) {"
Пофиксить ошибку можно так:
1) mLocationManager?.removeUpdates(mLocationListeners[y])
или так в твоем это случае лучше не делать
2) Вынести mLocationManager в "companion object" и пометить его "lateinit" (пик 1)
P.S.
Вопрос "зачем ты хранишь статическую ссылку на LocationManager?", а пожалуй задавать не буду.
> вполне возможно он определит что твоя переменная уже не используется но создалась новая.
Я тебе по секрету так скажу, на уровне байткода вообще переменных нет. Есть регистры, компилятор их число минимизирует.
По секрету себе сам скажи, я внезапно на ассемблере даже писал, но то что в памяти выделяется место под него при инициализации факт, а компилятор оптимизирует это дело.
Не слушать людей на stackoverflow, которые предлагают освобождать ресурсы/останавливать сервис в методе onDestroy активити или фрагмента.
Метод onDestroy вызывается перед тем, когда активити будет уничтожено.
Зачастую не тогда, когда мы это ожидаем (слишком поздно, с задержкой, когда система решит его вызвать).
Я просто не понял был ли твой пост сарказмом.
Сам в ондестрой нихера не делаю, если уж что-то важное стопать нужно то через онпауз онрезюме.
> освобождать ресурсы
Слишком размытый термин (хотя сложно представить что можно освобождать в onDestroy)
Всякое говно типа синглтона который хранит в себя ссылки на активити, очень тупой пример, но тем не менее.
Уже обсуждали тут как хендлером сделать мемори лик, и описывали что можно просто очищать хендлер в онДестрое.
Ну и что за нахер, когда мне от сервиса анбайндится? И почему по гугловскому гайду для GoogleApiClient'a нужно конектится на старте, а отключаться в стопе
Там же основной заеб видима ли твоя активити.
Ну и по факту только онПауз гарантированно вызывается, это можно посмотреть по схеме лайфсайкла.
Слушая Google, а не рамдомных сосачеров.
Правильно тебе все гугл говорит, после Android 3.0 между pause/stop нет никакой разницы
(кроме случая перекрытия твоего активити, другим "полупрозрачным").
Давай разберем все тобой написанное, складывается впичатление...
Что тебе конкретно не понравились?
Ты моя маленькая девочка считал себя умнее разрабов из гугла?
Эта маленькая девочка написала все как по доке, еще и объяснила чем чревато что-то делать в онСтопе.
И уже исходя из твоих слов
>по гугловскому гайду для GoogleApiClient'a нужно конектится на старте, а отключаться в стопе
>Правильно тебе все гугл говорит, после Android 3.0 между pause/stop нет никакой разницы
Ты сам перечишь гуглам если что.
Чаще всего встречаются "полезные советы" про AudioRecorder:
Если вызвать release в ondestroy, то не факт, что он освободится до того, как в другой активити/фрагменте его будут снова юзать. Ведь мы не знаем, когда будет вызов ondestroy. В итоге имеем рандомные краши время от времени на рандомных устройствах.
При этом куда не плюнь - в ondestroy все release вызывают.
С сервисом тоже можно наебаться - активтити закрылось, сервис еще не грохнули, потом его начали перезапускать И В ЭТОТ МОМЕНТ ГРОХНУЛИ В onDestroy.
В итоге сервис не запущен, а должен быть.
Но масштабы проблемы куда шире, это не ограничивается примером с AudioRecorder и сервисом.
*поправка AudioRecord
Так блять, онСтарт нового активити вызывается не относительно онДестроя предыдущего.
Там вроде только между онПауз(1) - онКриейт(2) - онСтарт(2) - онРезюм(2) есть зависимость. Хотя тут мог ошибиться.
Он написал
> Ну и по факту только онПауз гарантированно вызывается
Ну давай вместе посмотрим:
https://developer.android.com/intl/ru/reference/android/app/Activity.html#ActivityLifecycle
Как видишь на картинке, после Android 3.0 активити не может быть убита до вызова onStop().
Так что теперь "onStop() тоже считается гарантированно вызываемым".
Окей, спасибо.
какая то хуевая архитектура, так как сохранять прогресс закгрузки при перевороте, только ретеин фрагмент и т.п.?
А кто не писал? Я про байткод далвика говорю.
И как это помогало?
Вообще не плохо сделали нужно признать.
Алсо, студию обновили и выслали оповещение на почту, лол. Первый раз такое вижу.
Мне это не говорит нихуя.
У меня меню все на китайском теперь.
а мой ты каток, навошта гэта табе
Аноны, подскажите, переписывал по туториалу, после все скомпилировалось, я закрыл. Сегодня открыл - и вылазит пикрелейтед. В xml совсем хуй. Подскажите пожалуйста где ошибка.
Вот что бывает когда не знаешь что пишешь, точно, спасибо.
пересоздать активити
Только покупай чехол сразу, и советую еще стекло. Задняя панель сделана из плохого пластика - царапается очень легко, прямо таки очень.
Также как купишь телефон установи програмку checkR и купи провод юсб-а на тайп-си, и проверь его этой програмкой.
Сам все эти грабли испытал на себе.
Только сейчас дошли руки. Спасибо тебе большое.
Нужно летнюю практику в универе закрывать, взяли по знакомству на позицию ведра. А так как я котлин не учил, то вот так получается
Ну он определенно не говно, с кабелем мозгоебка но от него есть профиты, время зарядки например.
5ка уже говно мамонта.
Поддержка ближайшие 2 года (+ preview сборки)
VS
micro USB
Что бы выбрать?..
Тем более смирись, будущие за USB-C.
Вот уже и музыку через него можно слушать на Nexus5X
https://www.indiegogo.com/projects/aero-digital-earphone-upgrade-to-hifi-music-now#/
> гуру
Нет, ну да похуй.
Я из вьюхи предпочитаю, ибо 1) там 100% есть контекст, 2) все таки запуск активности, это операция показа каких-то данных, хоть и в другом окне. Да и вдруг тебе придется заменять запуск активити на добавление фрагмента?
Не морочь себе голову: "Single responsibility principle" + "Dependency Injection".
Выносишь код навигации в отдельный класс (NavManager), а в презентер прикидываешь его через Dagger2 (или другой DIF).
В презентере уже просто дергаешь его методы.
Потроха NavManager пишешь как удобнее и проще, потом если будешь переписывать - придется менять один класс.
P.S.
Кстати в Application есть интересный метод registerActivityLifecycleCallbacks
https://developer.android.com/reference/android/app/Application.html#registerActivityLifecycleCallbacks(android.app.Application.ActivityLifecycleCallbacks)
Он может помочь "неявно связать" NavManager и твои активити (но это так для информации).
P.P.S.
Глянь MVVM, там реально гораздо меньше бойлеплейта чем в MPV/MPC.
т.е. будет тупо класс NavManager с методами openActivity1(), ..., openActivity666() ?
Раз ты юзаешь MVP, значит у тебя на каждом активити есть как минимум один рутовый Presenter.
Бьюсь об заклада что почти везде у тебя соответствие XXXActivity == XXXPresenter (если нет, то это легко исправить).
Значит можно вычислить активити из названия класса презентера.
В итоге можно иметь один метод:
public <T extends Presenter> void open(Class<T> presenterType, Arguments args);
вызываться он будет, к примеру navigator.open(LoginPresenter.class, ...);
или на Kotlin:
fun <refied T:Presenter> open(args: Arguments)
navigator.open<LoginPresenter>(...)
Здесь кстати соблюдается "open/closed principle" - при добавление нового окна, не придется менять интерфейс.
Кстати если не хочешь делать через название активити можно, тупо сделать switch/case.
Это плохое решение в рамках MVP.
Если всё приложение реализовывать на MVVM, то ок.
Лучше создать в activity статичный метод create(Context context), который будет создавать её, и вызывать его из V.
> MVVM, там реально гораздо меньше бойлеплейта чем в MPV/MPC
С увеличением сложности приложения MVVM начнет ограничивать тебя, она не такая расширяемая, как MVP.
Мобильщики вообще макаки же. Это что-то уровня программирования на пыхе или жс.
Утешай себя этим почаще, JavaScript-макака.
Нет, слишком много тонкостей системы нужно знать. Слишком много багов в сдк.
Тут реально решает опыт.
>Ждать пол года
>Брать телефон маньше чем через несколько месяцев после релиза.
Плохо, брат, плохо у тебя с логикой.
До выхода новой модели осталось четыре месяца (пускай даже пять). Это больше, чем уже прошло со времени выпуска 5x. (Мы ведь помним, что апдейты системы будет выходить в лучшем случае два года).
Плюс, 5x имеет несколько неоднозначную начинку. Ходят слухи, что новая модель должна быть более сбалансированной.
По крайней мере я, руководствуясь такими рассуждениями, подожду до октября, а там уже решу, что брать.
> Это плохое решение в рамках MVP.
> С увеличением сложности приложения MVVM начнет ограничивать тебя
Пруфов конечно не будет.
Я к MVVM пришел эволюционно путем от MVP,
когда устал писать кучу однотипных методов которые просто гоняли данные.
Читаю книгу Android Big Nerd's ranch (Busy Coder’s это ёбаный справочник, а не учебник).
Блядь, ctrl+enter нажал.
Так вот, читаю и делаю оттуда упражнения, книга годная, но хотелось бы что-то ещё почитать об отделении логики обновления View и взаимодействия с моделью.
Смотрел пример TodoList приложения от гугла, ничего не могу понять. Какие есть годные материалы по данной теме?
> Я ещё и половины базовой программы не изучил
Тогда явно не стоит. Изучи основы, привыкни к SDK (он тут со своими особенностями).
Когда поймешь, что именно тебя не устраивает в стандартном подходе (и почему), тогда и можно уже в архитектурные дебри углубляться.
Ребят, накатил стандартную DrawerLayout активность от студии, на уже созданное приложение, как перекрасить статусбар, чтоб он не становился оранжевым как на пикрелейтед, а был прозрачным?
сделать прозрачный статусбар во всем приложение, это делается в пару строчек в теме приложения, погугли
Если сставить на новое приложение, то статус бар прозрачным становится при открытии выдвижной панели.
У тебя иконки уёбищные, да еще и стоят криво.
5 месяцев это дохуя, ждать не имеет смысла, учитывая что тут у людей зарплаты в баксах, можно взять сейчас, и еще через пол года.
Да и не забывай что только ебанутые закажет только что выпущенный телефон проебывая гарантию(а так и будет закажи ты его читерством с америки), брак штука серьезная. А если подождешь одзывов месяц то как раз будет тебе пол года. Не выебуйся в общем.
У 5х однозначная начинка, средний смартфон, чего там неоднозначного. Вот материал пластика - говною.
> учитывая что тут у людей зарплаты в баксах, можно взять сейчас, и еще через пол года.
Как толсто.
Чего толстого? Намек что тут никто не работает? Так нахуй тогда тебе такой дорогой телефон если у тебя денег немного? Для себя тебе китаец + эмулятор хватит на ближайший год. А там если не зацепишься то уже прости но что-то явно не так.
Я в Европе, так что с гарантией проблем нет.
Для личного использования меня устраивает мой китайфон абсолютно. Но для разработки хочется новый (физический) девайс. Поэтому пока и не тянет менять устройство, вот и хочу посмотреть, каков будет новый нексус
>Я в Европе, так что с гарантией проблем нет.
Если ты в европе то и телефон менять раз в пол года не проблема, не выебуйся. Всегда можно сказать - давайте подождем новую модель, учитывая как их клепают.
Радости у людей, словно они в тот градл заходят для чего-то помимо прописывания депенденсиса с примером на гитхабе.
Да-да я нуб и долбоеб, градл пушка и тд и тп, но хватит пиздеть, наверное никто ничего сложнее флейворов не делал.
Не пали годноту быдлу.
Настройка CI, тестов, flavors и build variants, dexing, shrinking, apt.
Переход на котлин особой разницы не принесёт, но хоть автодополнение будет работать.
Загрузка картинок заранее ( до того, как они непосредственно подгружаются в элемент списка )
>build variants
>dexing
>shrinking
Это ебучий шаблон который переносится из проекта в проект, как гитигнор и прогвард.
С флейворами конечно интереснее, но они не везде нужны.
С CI не приходилось еще работать.
А смысл в чем? Оно кеширует все что ты загружаешь не забываем про размер кеша. Зачем кешировать то что возможно даже на экране выводится не будет?
Ты главное их снимать не забывай
потому что он загружает непосредственно во ViewHolder, а нужно бы заранее и из пула доставать потом. Быстрее же.
Оно загружает в кеш и потом отдает тебе.
Т.е. зашел на список - подгрузило из инета.
Перезашел в это список - подгрузило из кеша.
10 метров не так много же. И в каком смысле при каждом пересоздании? Предыдущие 10 мегабайт не очищаются или что?
CrimeLab.get(this)
CrimeLab - синглтон. Метод принадлежит Activity. Собственно претензии к
public static CrimeLab get(Context context) {
if (sCrimeLab == null) {
sCrimeLab = new CrimeLab(context);
}
return sCrimeLab;
}
private CrimeLab(Context context) {
mContext = context.getApplicationContext();
mDatabase = new CrimeBaseHelper(mContext)
.getWritableDatabase();
}
Разве нет риска с таким вызовом CrimeLab.get(this) (вместо CrimeLab.get(this.getApplicationContext()) при очередном get() получить CrimeLab с протухшим содержимым?
Из памяти сначала. Если там нет, то из кэша.
Будут. Делай поля
Нет.
Упс. Разобрался.
именно
Снова я, привет.
Теперь вылетает такой exception
java.lang.RuntimeException: Unable to create service: kotlin.UninitializedPropertyAccessException: lateinit property mLocationManager has not been initialized
Caused by: kotlin.UninitializedPropertyAccessException: lateinit property mLocationManager has not been initialized
Во-первых, работает мало кто. Во-вторых, зп в долларах — у пары человек на всю доску, максимум.
какой ужасный синглтон
Ну, видимо, я не такая талантливая петушатина
>Выпустил в гп первое приложение, когда учился в школе.
Так вот андроид-маркет засрал своими поделиями.
google почитай, говорят запросы помогают. Шапка тебе нахуй дана, уебан ?
>>746729
Ну это уже просто ПИЗДОС (других слов нет), ты программист или домохозяйка?
MAT для кого сделали?
Да даже в самой Android Studio/IDEA есть этот гребанный график потребления памяти,
мог бы туда посмотреть (вызвав сначала GC) и дамп там же сделать.
да разницы то, лол, факт есть факт, утечка есть, она в recyclerView, даже более - связана с имагами
> да разницы то, лол, факт есть факт, утечка есть
Маленький ты мой лол, ты это тоже по диспечеру удивил или тебя или в отчете MAT?
> да разницы то
Разница в том что у нас тут есть сборщик мусора, который удаляет ссылки когда ему удобнее,
а ни когда объект уже не используется.
Соответсвенно если не нажимать вручную "perform GC", то "визуально" куча уменьшаться не будет
тк он будет освобождать память только что бы сразу ее отдать новым объектам.
т.е. ты хочешь сказать, что то, что у меня в диспетчере на планшете видно, что каждый onResume кол-во оперативы занятой приложением возрастает на 10мб может быть нормальной работой ?)
Да, даже несмотря на это, то же самое и в студии показывается, по +10мб при onResume
ты блять по делу способен что-нибудь сказать ? Или тебе приспичило просто попиздеть, говном облить и не сказать ничего, содержащего хоть какую-то ценность ?
Ну а нафига мне тестовый пример с адаптером в 5 строк в котором учат делать список однострочных TextView ?
>>746817
Я подумал ты спрашивал про то как с базой работать а не про списки.
https://guides.codepath.com/android#adapterviews
нет, про списки :)
Сделай полноэкранный режим, тогда статус бар не будет мешать
ресайклер больше нравится :) Но правда вот такие моменты пиздос ебут
Не знаю. Я сейчас покопался в коде чувака, либу которого использую ( для хэдеров, футеров, удобной имплементации холдеров и прослушки клика ) и понял, где может быть собака зарыта.
Этот человек ставит онКлики на itemView и не убирает их никогда
по крайней мере при выходе в бэкграунд они могут остаться в памяти а новые - добавится потом при возвращении и onresume, если я правильно понимаю
Ебать, ну точно одни нюфаги everywhere.
Ему сказали использовать тулзы для анализа, нет он сидит и фантазирует.
А че, не видно что-ли, вон гуру писал, к которому ты обращался
Кстати напоминаю: до главного события Android мира осталось 2 часа.
https://events.google.com/io2016/
Ждем ободряющей речи от Сундара. Интересно чем он решил нас удивить?
Может язык платформы поменяют на Kotlin или Swift или GO?
Хотел подколоть и сделать скрытый текст, но вместо этого выделил :)
На хаскелле
В общем главное активити представляет собой список песен, доступных для воспроизведения. При нажатии на элемент выплывает фрагмент, в котором есть кнопка play/pause и seekBar для перемотки и отображения прогресса. Помимо этого при нажатии запускается сервис (в том же процессе), в котором работает MediaPlayer (занимается непосредственно воспроизведением музыки). В этом сервисе создается второй поток, из которого я раз в секунду отправляю в активити бродкаст, в котором содержится текущая позиция(прогресс) MediaPlayer'а. Приняв в активити бродкаст, извлекаю из него позицию и задаю ее как текущий прогресс seekBar'а во фрагменте. Если хочу остановить воспроизведение из фрагмента (нажать на кнопку play/pause) или перемотать песню изменив положение seekBar'а, то использую binding вместо бродкаста и просто вызываю публичную функцию для паузы/перемотки, которые прописаны в сервисе.
Норм я все организовал? Есть смутное подозрение что это немножко быдлокод, подскажите как лучше сделать.
Все аудиплееры что я видел в опенсорсе - говнокод. Статическая ссылка на забайнденный сервис, ммм.... Мне кажется лучше на сикбар просто повесить анимацию и паузить ее когда сервис скажет.
Текстовая версия будет? А то ивенты от гугла еще более унылые, чем последние от эпла.
> я раз в секунду отправляю в активити бродкаст
Лучше уж у биндера колбэк дергать, не? Чтоб gc не охуевал подчищать за тобой интенты.
>>746969
А если повесить анимацию разве не получится расхождения между реальной позицией воспроизведения и отображаемой? Я стримлю музыку с вк, и вполне возможно что где-то воспроизведение будет останавливаться -> нужно это как-то учитывать, каждую секунду чекая все ли нормально. Кстати, чем грозит ссылка? Сервис у меня останавливается, если закрывается активити, что может произойти?
Т.е. запилить метод в сервисе, который будет возвращать текущий прогресс и обращаться к нему раз в секунду из активити?
Да. Либо сделать универсальный коллбэк, который будет иметь onPlayStart, onPlayPause, onPlayStop, onPositionChanged, чтобы синхронизировать изменения, которые инициирует плеер, с ui.
Хуй знает.
Но думаю через сервис прослойку. У обоих сервисов есть aidl, чтобы дергать rpc, вот они и будут друг другу эти методы дрочить. У сервиса в главном процессе будет дергать oonPlayStart(), onPlayPause(), onPlayStop(), onPositionChanged(), который будет прокидывать их в ui. У сервиса в другом процессе будут дергаться play(), seek(), pause(), stop().
Ну, ты можешь использовать бродкасты.
>>746741
Нет, приложение хоть и было хуёвым, но более-менее вменяемым. Оно до сих пор там есть, просто дело было 4.5 года назад уже.
А написал я потому что охуели нынче школьники. Сейчас миллион материалов по программированию под андроид, ссылки в оппосте, видео, миллион готовых решений. Нет, не хочу, хочу "сап посаны, я школота, накидайте мне гайдов :)))". У меня такого не было, хотя я каким-то выдающимся себя не считаю. Наоборот, по сравнению с местными я днище уже, тем более во время универа я разработку забросил.
Умный Дилдак от гугла на агдроиде конечно же.
Сможешь с ним разговаривать когда будешь садиться на него.
Еще больше изврата прямо по ссылке http://google.com/io
А ДАВАЙЕТ ВОЗЬМЕМ ХОРОШЕЕ ОТ ТЕЛЕГРАМА И ЗАХУЯРИМ ТУДА АВТООТВЕТЫ?
Запилил коллбэк для обновления сикбара, для этого в активити создал поток, который обращается к сервису и обновляет сикбар, но почему-то код работает даже тогда, когда я выполняю обновление позиции сикбара прямо в параллельном потоке, хотя такого быть не должно, т.к. ни один поток кроме главного не имеет доступа к UI. Что я сделал не так?
> для этого в активити создал поток
Ты уверен, что он это отдельный поток, а не хендлер на главном?
Реквесты по изменению/добавлению ссылок можете оставить здесь или на гитхабе.
Ну учитывая что там я пишу про кскамарин и джаваскрипт, то это не слишком соответствует тематике, наверное стоит почистить.
А нет, все ок, почистил, молодец.
Там разметка удобная.
Да, я даже нашел топик с такой же ситуацией http://stackoverflow.com/questions/5161951/android-only-the-original-thread-that-created-a-view-hierarchy-can-touch-its-vi. Попытался как ОП того топика обновить текст для TextView внутри этого треда и так же получил вылет приложения а-ля "Только главный тред может работать с UI". В топике никто не объясняет почему так происходит, лишь предлагают запустить поток методом runOnUiThread что мне тащемта не нужно, ибо сикбар обновляется и так. Я конечно сделаю по-православному и запилю хендлер, ну или runOnUiThread, но хотелось бы понять что не так. Могу кинуть код метода run если что.
Из тваеий мамки)))
Ты уж пожалуйста либо поясни что не так, либо уебывай
Потому что вьюхи это ресурс (классы) в которых у методов нет синхронизационных секций,
тк они рассчитаны на использование с одного потока.
Если ты не понимаешь чем череват многопоточный доступ к объекту, который его не поддерживает,
то иди читай "Java Concurrency in Practice".
При этом разработчик Android понадеялись на адекватность разработчиков (видимо зря) и
не стали делать проверки правильности треда в каждом методе.
Ты кажется не понял меня, я понимаю чем чреват многопоточный доступ, я не понимаю почему seekBar является исключением и прекрасно обновляет свою позицию даже не из главного потока, хотя делать этого не должен. Потому что изменение позиции seekBar не рассматривается как изменение состояния UI? По каким-то другим причинам? В этом вопрос.
Да при чем здесь "изменение состояния", это объект который не поддерживает многопоточный доступ - ВСЕ.
То что там что-то работает (конкретно на твоем телефоне) это просто совпадение.
Использование объекта с неправильного потока, НЕ вызывает АВТОМАТИЧЕСКИ исключение.
Тут видимо просто забыли добавить проверку (или посчитали не нужным, тк НЕадекватов как-ты единицы).
Няша, я просто пытаюсь понять почему данное вью ведет себя неправильно в данной ситуации. Про то, что вьюхи не поддерживают многопоточный доступ и так делать низзя я тоже знаю.
>Использование объекта с неправильного потока, НЕ вызывает АВТОМАТИЧЕСКИ исключение
А разве CalledFromWrongThreadException это не то самое исключение?
Оно не происходит автоматически, вот тут есть метод checkThread()
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.1.1_r1/android/view/ViewRootImpl.java/#6355
Его дергает вью при обновление и оно уже бросает исключение.
Соответственно если это метод не вызван перед выполнением, то у тебя все отработает.
Но это уже будет undefined behavior.
Спам-лист
Нет, когда они отцепятся от адаптера все почистится. А так только дрочить сборщик этими референсами будешь.
У меня просто странная ситуевина, количество занимаемой оперативы увеличивается примерно на 60кб внезависимости от того, сколько элементов в ресайклере, при триггере onPause - onResume. Не думаю, что критично, но хочется причину найти
Вроде как некоторые кастомные вьюхи не ресайклятся самостоятельно
p.s. Возможно, что виноват flow, не так давно начал его юзать, но вроде как по исходникам он особо там не должен ничего сохранять каждый раз по-новой
Мда, представляю какая у тебя там каша спагетти, лазанья - выбирай сам.
Видимо забота о контролирование сложностью проектов НЕ для тебя.
Но это в принципе норм для нюфагов, надеюсь только что никто это поддерживать не будет.
Нет, поддерживать это буду я, то небольшой учебный стартап. В принципе то каши и нету, и выглядит приятно вполне. Единственная проблема - вот эта вот утечка и сохранение state-ов. Со всем остальным, что есть, работать я уже давно научился.
Фактически, там получается классический набор ( по кр. мере для меня ) для клиент-серверки: rx, retrofit, flow, butterknife, ну и vk/fb/gmaps/gcm )
Проблемы только с view-частью, там мерзкий lifecycle порой покоя не дает, все еще не привык к нему нормально :( Все думаю записаться на курсы какие-нибудь, где построют теорию вменяемую, но времени нету. Только только 11 класс заканчиваю, плюс хочу на стажировку пойти на пару месяцев куда-возьмут, или, в идеале - джуном. Благо уже даже в gplay публиковал свой "ужас". Но то был совсем бешеный пиздец, еле-еле добили до конца приложение. За три недели кое-как сделали не самый простой заказик и теперь только под своим началом что-либо клепаем
Можешь посмотреть если хочешь, кинь сюда линк на свой гитлаб - добавлю. Только закоммичу через пару дней вменяемую версию с окончательным перекатом с фрагментов на flow
Хм, не хочу никого осуждать, скажу только imho: меньше -> лучше
(меньше библиотек, меньше зависимостей, меньше состояний/мутабильности, меньше кода == меньше сложность).
Чем ниже сложность - тем проще поддерживать ПО (и через год не появится желание переписать с нуля).
Тебе бы пойти куда-нибудь работать (не обязательно сразу в yandex), чтобы тебе это взрослые-авторитетные дяди объяснили.
> в onResume восстанавливать в том же состоянии, в котором он и был
Вот тут очевидно что у тебя слишком много состояний, почему так (перегруженный UI, много промежуточных стейтов)?
> Тебе бы пойти куда-нибудь работать (не обязательно сразу в yandex), чтобы тебе это взрослые-авторитетные дяди объяснили.
С чего ты взял, что везде работают взрослые авторитетные дяди?
Относительно 11-классника, это кто угодно закончивший вуз + >2 года опыта.
Я долго думал как бы получше сделать этот экран, в итоге сделал его с RecyclerView, который уже содержит в себе хэдеры, футеры и прочее. Так что не то чтобы много состояний.
я и не нацелен на то чтобы "сразу в яндекс". Собственно от стажировки/работы джуном я просто хочу опыта, дальше скорее всего фриланс
на каком девайсе? если на каком-нибудь нексусе с 2gb оперативы, 50 отожраных метров - это норма
на каком девайсе? если на каком-нибудь нексусе с 2gb оперативы, 50 отожраных метров - это норма
Практически никогда. Серьёзно. Если возникнет ситуация, когда им нужно пользоваться, — у тебя уже будет достаточно опыта и ты уже сам поймёшь.
вроде видел как адаптер в него пихали для ресайклера, не уверен
Единственно верный вариант: https://developer.android.com/reference/android/accounts/AccountManager.html
Никаких shared prefs и sqlite для хранения credentials.
Не куки, а пропуск в брюки.
Костыли костылями, но сранный мейзу мне сейчас сбивает паддинги у текстинпутедиттекста например. С учетом того, что они явно заданы в стиле.
А в случае если нужно хранить очень много инфы пользователя ?
Дойчебанк и люксофт для дойче - куча вакансий на эту тему.
Xamarin - это как PHP, но только в мире мобильной разработки.
Конечно нет, нужно быть программистом в третьем колене. Как и везде собственно.
А почему бы не писать приложения на js? В чем подводные камни? Сразу и на яфон и под андроид.
Никаких подводных камней. Сплошные плюсы.
Я вообще думаю, что нужно Linux на JavaScript переписать: сразу же столько новых возможностей появится и коммьюнити будет больше.
Ты debug-сборку в Play отправлять собрался?
Вроде как далеко не весь функционал удобно на js писать, но то мое ИМХО, особо не вникал.
assembleRelease должен собрать нормальную сборку, но я не уверен, не пользуюсь инстант раном.
Я всегда для релизов юзаю "генерейт сайнинг апк". Хуй знает, может это глупо, но уже привычка.
assembleRelease - юзаю чтоб sha1 посмотреть.
>>749423
Удобнее singningConfig прописать в градле и делать assembleRelease.
Просто я ньюфаг и ебусь с этой парашей уже 2 дня.
https://www.youtube.com/watch?v=1tDsf7Sw6-U
Надоело пилить AsyncTask в каждой Activity. Хочу такую библиотеку чтобы в одну строчку можно было указать url картинки и ид вьюшки. Недавно случайно наткнулся на Volley, но на деле там не то, что обещают. Еще увидел android-query(https://code.google.com/archive/p/android-query/), но не нашел для нее примеров использования. Знаю еще, что есть picasso, но чем-то она меня отталкивает.
А мне нужно реализовать ListView с картинкой и строками в каждом пункте (как на пике). Важный момент: адрес картинки у меня возвращается кастомным методом, указывая который в качестве аргумента конечно словит исключение.
Что посоветуете?
>Удобнее singningConfig прописать в градле и делать assembleRelease.
Куда оно апк помещает в таком случае?
> Что посоветуете?
Повеситься.
> Хочу такую библиотеку чтобы в одну строчку можно было указать url картинки и ид вьюшки
Glide, Picasso, Universal Image Loader
Отталкивает, не нравится — ну тогда напиши свою либу и не задавай глупых вопросов.
> адрес картинки у меня возвращается кастомным методом, указывая который в качестве аргумента конечно словит исключение
Подъезжая к вокзалу, у меня слетела шляпа. Прекрасный повод переписать по-нормальному.
Это скорее всего какие-то коды символов. Так что то там иконки тупо текстом получаться.
Ты как-то странно объясняешь, может ты чего-то не понимаешь, что значbт менять API? Если ты про xyi.pizda/api/weather?city=tagil и хочешь получить в геленджике, а не тагиле, то надо просто запрашивать xyi.pizda/api/weather?city=gelendjik, никакой смены API.
ну я не догоняю просто
тип в видосике сделал менюшку, в которой меняет город и показывает его погоду
а я не догоняю как он это делает
ведь для этого надо загонять новую АПИ
линк на видосик: https://www.youtube.com/watch?v=1tDsf7Sw6-U
Кому ты пиздишь? Апк будет в папке app.
Тебе уже ответили, что делать. Думать и васяновидосики за тебя смотреть никто не собирается.
Сделай функцию генерации урла для запроса, если поп рсотому то:
return String.format("xyi.pizda/api/weather?city=%s", cityName);
В реальных проектах это конечно не так делается.
но ведь тогда надо будет загонять новую АПИ
просто я задаю АПИ строкой и из него все парсю
вот видосик: https://www.youtube.com/watch?v=1tDsf7Sw6-U
тип в видосике сделал менюшку, в которой меняет город и показывает его погоду
а я не догоняю как
АПИ ведь загонять придется новую
нет
>>749969
бросай свои паршивые васяновидосы и дуй на udacity смотреть официальный курс от гугла.
Тем более, что на курсе они делают ровно тоже самое и скорее всего твой васяновидос оттуда все слизал подчистую
Если у тебя нет хотя бы $5k на рекламу, то никакх.
Стор завалин фритуплейным парашей погорло, а ведь есть еще фирмы которые зарабатывают копипастой успешних игр.
Знаю одну такую, там работают сотни "разработчиков", которые конвеером выпускают это гавно.
Google их конечно переодически банит, но их это не останавливает - больше сотни аккаунтов (и это только одна фирма).
Что в твоем понимании представляет из себя API ? Ты уверен что понимаешь значение этого слова ?
Можно конечно было бы сначала считать только ключи, и ходить в DataSnapshot по этому ключу по необходимости, каждый раз десериализуя объект, но это как то звучит левачно.
>>750332
Да flow мало используется, нахуй ты его вообще брал. Тебе даже его никто не советовал здесь.
Firebase это бд, которая позволяет напрямую из андроида работать с ней без апи, я правильно понял?
Ну как без апи, у нее есть rest api, но соль в том, что через сдк она самообновляемая. Т.е. на объект вешаешь листнер, и этот колбек отработает, как только с этим объектом что-то случится.
Да и до полноценной бд как до берлина. Фильтрация у меня чет не запахала, сортировка только по одному полю. Для серьезных проектов не подойдет, но для какого-нибудь мелкого проекта думаю сойдет.
где то была стата, что 5% разработчиков, собирают 90% прибыли, остальные сосут хуи. Вот и думай, попадешь ли ты в эти 5%
Анончики, задаваю этот вопрос сразу в 2х тредах по C# и Java.
Есть знания в области геймдева со стороны 3D графики.
Хочу начать изучать кодинг.
И вот вопрос:
Что же будет перспективнее и более реально в соотношении время обучения/возможности на этом зарабатывать? На чем реальнее и перспективнее будет делать простые игры для мобилок?
Как вариант это уже более-менее знакомый мне Unity + C#
Либо Java + другой движок
И в чем из этих языков будет проще отстраниться от конкретно геймдева в сочетании с движком и уйти просто в кодинг, не завязанный на играх вообще?
Он оказался удобным дофига. Плюс абстракция то будет поболее, чем со фрагментами. И практически полная замена EventBus-а сервисами ( flow-овскими )
И да, в 17 треде советовали вроде ( помню что было, точно не припомню, может и в 16 ). Принципиально иной подход, но он блять удобен и более кампактен + абстрагирован. И под mvp тот же заточен больше
pkg: /data/local/tmp/com.huy.pesda
Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]
Installation failed since the APK was either not signed, or signed incorrectly.
If this is a Gradle-based project, then make sure the signing configuration is specified in the Gradle build script.
Error while Installing APK
Эх, сейчас бы в 2016 на русском гуглить. Можем, конечно же.
У меня по нему один вопрос неделю остается, но на крайняк сделаю кэширование в локальной бд, благо это просто + всяко оффлайн режим пилить нужно будет. В остальном же помимо state-а меня flow устраивает более чем
После IO появилась та же хуйня от firebase.
https://developers.google.com/cloud-messaging/android/android-migrate-fcm#import_your_gcm_project_as_a_firebase_project
Уже есть тысячи вариаций архитектуры мвп с активити и фрагментами, зачем нужны ноунейм фловы?
Нет на полном серьезе? Если бы это было нормальное решение коммьюнити бы уже его продвинуло, но нет.
Бля, это не новые технологии, я уверен их файрбейс тот же гсм.
Ну посмотри что-ли, может поймешь, когда прикинешь как это по-сравнению с фрагментами профитно.
Ну ты же хочешь понять, зачем нужны ноунейм фловы. Мое дело сказать, твое - решат что будешь делать. Я просто говорю, что использовать flow, ИМХО, профитнее
Уже полгода делаю в нем проект. Это аналог лейаута из айос. Там в принципе очень удобно, если понять, для чего он тебе. .
кхм
То конечно хороший перекат, я люблю рекурсию, но...
Есть аналог - cassowary-layout..
Удвою.
Вы видите копию треда, сохраненную 13 июня 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.