На самом деле люди не пользуются календарём (поверьте, не только вашего колледжа касается) не из-за того, что не умеют или не хотят планировать свой день - банально не знают, что календарь для этого хорошо подходит. Поэтому, как только появится причина туда заходить, разберутся и наверняка распробуют.
Я действительно воспринял ваш комментарий с негативной стороны, поскольку до вас два товарища уже пришли в комменты с целью доказать, что их решение лучше (как водится, без какой-либо аргументации), при этом текст был без структуры, наполовину состоял из наездов, а добрая половина статьи была будто проигнорирована (неужели я задел этих людей?). Сейчас я вижу, что у вас желания навязать свою точку зрения нет, потому прошу прощения за агрессию.
В целом я согласен с тем, что сервисы уровня Moodle могут сильно улучшить качество образования в ВУЗах. И я не против, если такой появится, если ниша не занята (мне кажется, конкретно Moodle крайне много юзкейсов покрывает) и если будет достаточно проработан для широкого внедрения.
Но из комментария мне показалось, что всё таки вы планировали акцентироваться на общем клиенте для разных малосовместимых бекендов, а не полноценный сервис. Историю с клиентом я не понимаю как поддерживать, и главное - какими средствами.
Есть единый контракт с данными, не завязанными на конкретный ВУЗ. И для работы нужно поднять бэк, на нём выдавать данные в нужном формате и описать ручки бэка в определённом формате.
Не кажется ли вам утопичной идея, что студенты всей страны (считаю, у ВУЗов такой заинтересованности нет совсем) решат поднимать аж бекенд для подключения собственного учебного заведения?
Что энтузиаст получает за внедрение своего ВУЗа в ваше приложение? Это важно.
Что будете делать, если кому-то надоест хостить своё решение и у вас 1000 пользователей окажется без расписания? Что будете делать, если новый владелец хоста появится внезапно и будет вместо расписания добавлять что-то нехорошее?
В целом, как решаете возможные проблемы с рекламой, треш-контентом, etc. при получении данных с серверов, которые вам ничего не должны, и влияния вы на них не имеете?
Как решите вопрос, что расписание почему-то устаревшее, так как не получается напрямую с сервера?
Как обойдёте сервисы вроде DDOS-Guard? (да, у нас в ИРНИТУ такой есть).
Столько вопросов, и всё ради каких-то святых контрактов...
Кстати, а почему дока по контракту отсутствует? Там сайт есть, но на нём ничего нет.
Легче править ошибки в парсинге и обогащении данных
Чем легче то?
Кода писать столько же. Вернее, у меня меньше, так как контракт - это всего два датакласса, которые не связаны между собой.
Уведомление "обновись, мы пофиксили тебе расписание" отправить - не проблема. Обновиться, когда прилка весит 2,5 МБ - изи, это меньше, чем видосик в соцсети. Заодно куча людей актуализирует версию приложения.
А точно ли вам будет проще достучаться до владельца сервера, который выпустился из ВУЗа, у него появилась работа, жена, дети, и ему до этого сервера уже нет дела? В моём случае, небольшую правку, да даже полное переписывание парсера, можно внедрить самостоятельно - банально исходники парсера имеются, в отличие от.
Данные намного чище
Каво? А аргументы будут, или просто "у меня лучше, у меня контракт!!1"?
У групп, студентов, преподов, аудиторий в расписании есть кафедра и направление
Часто студенты забывают, где учатся? Это достаточно важная информация, чтобы пользователю постоянно об этом напоминать?
У преподов/студентов есть аватарки
Да я и так знаю, как преподы выглядят, спасибо. Тем более некоторых лишний раз видеть не хочется.
Очень интересно узнать, откуда у вас аватарки студентов, насколько обоюдно получаете их, и насколько это адекватная идея в целом - вообще-то это вполне себе персональные данные. Буду рад взглянуть на имеющееся соглашение о конфиденциальности, или вроде того (оно ведь у вас есть, я надеюсь?).
Без своего бэка слишком ограниченные данные и часть вещей вообще не сделать локально. А для другой части нужно выкачивать всё расписание ВУЗа несколько раз в день на каждом девайсе, что очень плохо для серверов ВУЗа.
А вы точно хотя бы скриншот в Google Play видели? Там всё, что выдаётся на обычном сайте, показывается пользователю. Да, весьма в удобном виде.
У меня цель отобразить полезную информацию, а не закошмарить кучей вспомогательной. И для этого не требуется делать 100500 запросов. Создатели сайтов ВУЗов - не дураки, тонна лишней инфы не нужна.
На крайний случай можно просто держать всё расписание в гитхабе и обновлять его скриптом раз в день. Эффект будет тот же.
Нет, это слишком нечасто для многих ВУЗов. Рад, если у вас всё за неделю публикуется, но это редкость.
Отсутствие возможности запросить последнее расписание вручную - это прям большая проблема в вашей идеи. Ваши контракты умеют в превентивное обновление?
По выбору своего UI
Ну тут большинство преимуществ и так имеются в календарях.
Реальный минус моего подхода: ссылки на доп. информацию (группы, аудитории) ведут в браузер, а не в приложение. Но, при добавлении UI, можно просто сменить на DeepLink'и.
Просмотр свободных аудиторий
Не моя зона ответственности. И не ваша. И уж тем более не создателей интеграций.
Кстати, как это будете поддерживать, если аудитория стала занятой вот только что, а у вас обновление данных произойдёт спустя сутки? По клику преподавателя заново "скачивать интернет"?
А если не преподаватель нажмёт?..
У нас был убогий лк, в который не хотелось заходить. Поэтому в целом имеет смысл доступ к сервисам лк через приложение с одинаково удобным интерфейсом для всех ВУЗов.
А сможете разработать контракт, который покроет ВУЗы? Сможете интегрировать весь мир?
Хотя бы с руководством сможете договориться, что логин/пароль от ЛК будет передаваться стороннему приложению?
Утопия. Может всё таки ЛК человеческий лучше сделать?
Не построили удобную систему заметок для себя
OneNote. В нём заведите одну страничку (не более) под дела, связанные с задачами по учёбе. Не благодарите.
Поэтому не вижу проблемы такой фичи. Кому она не нужна - просто не будут пользоваться.
И опять перегруженное приложение, которое всех бесит и всё делает неидеально. Мне это неинтересно, спасибо за предложение.
---
Прошу прощения за сумбур, но по факту статья была прочитана плохо, либо в вашем идеальном мире таких проблем нет - объяснился за себя и за студентов, которым просто хочется рабочее, актуальное расписание, без лишнего гемора.
Ваша идея, как я считаю, очень не проработана - надеюсь, описал проблемы достаточно подробно.
С первых версий в приложении встроена полная защита от возможных проблем - отключение Restricted Bucket и App Hibernation. Всю важную информацию описал на StackOverflow.
Для пользователя это выглядит так: после добавления первого расписания появляется предложение нажать на две кнопки, чтобы отключить эти оптимизации. После их нажатия, приложение начинает логировать время срабатывания WorkManager, и через 12 часов говорит, есть ли проблемы с пробуждением для синхронизации.
В самых первых версиях собирал статистику, насколько тема рабочая - на современных смартфонах всё у всех отлично. Существуют проблемы со старыми MIUI (времён 9-ого Android'а), но и их можно пофиксить через лок замочком в меню последних приложений, этот фикс более-менее известен владельцам этих горе-аппаратов. Это описывается в гайде для основных китайских прошивок, который предлагается прочитать при обнаружении проблем с синхронизацией (описано в предудыщем абзаце).
Как итог, за год существования приложения, ни разу не слышал жалоб от пользователей. А ещё, поскольку расписание добавляется лишь на ближайшие недели, проблемы с синхронизацией можно увидеть в прямом смысле - а значит, при необходимости, просто войти в приложение для обновления.
Не стоит обманываться: шаблон был написан на CMP, но проект пока что Android-only.
Я планирую релиз под iOS (и, соответственно, переезд на CMP), но позже. Когда именно? Ну, сейчас у меня ни макбука, ни айфона, ни аккаунта App Store разработчика - к сожалению, без них не скомпилировать приложение для iOS. Сейчас я планирую ввязаться в авантюру с грантами, чтобы получить эти девайсы для разработки и отладки - надеюсь, не реджектнут)
Desktop и Web не планируется по нескольким причинам:
На этих таргетах нет API для календарей и нет удобной синхронизации в фоне, что рушит основные концепции;
При наличии установленного приложения на смартфоне, можно настроить синхронизацию с календарём - подробная информация лежит по ссылке "синхронизация календарей" в конце статьи. Благодаря такой синхронизации, мы не теряем ни одной фичи приложения, при этом можем смотреть расписание на компьютерах уже сейчас.
Спасибо за наводку! Позабыл про деплой через автоматизацию, действительно выглядит как хорошее решение. Вероятно, затащу к себе, когда отойду от единственного магазина.
Знаю лично двух товарищей, что делали подобные приложения без желания "сделать что-нибудь для курсача".
Насчёт рекламы - поначалу в приложении поддерживался только мой ВУЗ, итоги: реклама через паблики почти не работала (прирост менее 5%), по ссылкам в чатах одногруппников переходят единицы (буквально 1-2 человека скачивают на группу 25 человек, всем остальным впадлу что-то новое пробовать), на уровне ВУЗа никому никакие приложения не нужны. Возможно, в вашем ВУЗе все заинтересованы в таких начинаниях, но мне не повезло.
Ну и, вообще-то, запихать рекламу можно и в приложение для одного вуза. Тут вопрос не в количестве, а в принципах/планах разработчика.
Причём здесь "неправильная оценка рынка" не понял. Звучит как наброс.
Супер! Над скриптами не задумывался, наверное для ВУЗов с редко меняющимся расписанием это отличное решение, и главное - несложное при создании в одиночку.
А насчёт гибкости - с наличием наработок, скорость интеграции будет совсем быстрой, поэтому, если захочется воспользоваться преимуществами приложения, вы знаете, что делать)
Очевидно, никак, к сожалению. К счастью, многие уже отказались от этой практики, большинство ВУЗов имеют нормальное расписание.
Однако основную идею можно использовать, сделав общий гугл календарь. Его можно будет расшарить среди одногруппников, дальше достаточно лишь вносить изменения по необходимости. Работы там не слишком много, найдите отвественного и технически подкованного человека, и в путь.
В текущий момент мне важны быстрые релизы (как небольшие, так и важные обновления), а также набор аудитории в одном месте.
Адаптация для дополнительных магазинов и публикация в нескольких местах - очевидные лишние времязатраты. Вот несколько примеров, где это могло бы повлечь проблемы:
Недавно была неделя, когда приложение начало собирать сравнительно много аудитории (небольшой пиар сработал слишком хорошо) и тогда я не ленился заливать новые билды сразу после добавления улучшения - за неделю я залил 4 обновы. Да, это небольшие правки, но из тысячей мелочей и складывается отличный продукт. К счастью, сейчас я могу себе позволить такое, и единственный магазин - одна из причин.
А ещё, я с января по сегодня аж 6 раз менял иллюстрации на странице приложения. Тоже небольшие правки, но они важны.
Думаю, не стоит объяснять, почему несколько магазинов заставило бы ухудшить показатели скорости обновлений.
Помимо этого, сейчас мне важно накрутить счётчик загрузок: иметь в каждом сторе по 30 загрузок вместо 100+ в одном - ну это какое-то странное решение.
Если проект взлетит, то приложение появится не только в Google Play. Публикация также в RuStore - не проблема. Но на начальных этапах наличие нескольких магазинов для одной платформы - выстрел в ногу.
Здесь, я считаю, не менее важно сравнить с прямыми конкурентами.
Платные курсы? Ох, здесь слишком большой выбор. Заходим в гугл/ютуб и ищем наиболее подходящее по теме, и в 99,9% случаев получаем качество лучше и совершенно бесплатно.
Стажировки? Вряд-ли классный работодатель у дома дойдёт до приложения, которое никак не связано с поиском работы - он быстрее кого-нибудь привлечёт на hh/avito/работару или в пабликах vk. Если работодатель оказался в супераппе для студентов, то, вероятно, имеем дело с ненормальной текучкой кадров или максимально невыгодными условиями.
Скидки? Ну, может быть. У меня не сложилось найти чего-либо полезного, одни "товары для левшей" со скидками по четвергам (как водится, даже по четвергам будет оверпрайс в сравнении с соседними заведениями). Если получилось что-то найти реальное полезное из скидок - ок, валидно. Даже интересно услышать кейсы).
Мемы? Удобнее в вк/тг, притом там они могут быть смешными. Ну, вернее, подходят под индивидуальное чувство юмора, нет цензуры, нет бесконечной привязки к идее "я - студент".
Подслушка? Тоже в вк/тг. Нет ни одной причины иметь отдельную в приложении для учёбы. Тем более в немодерируемом виде.
Короче, суперапп для учёбы бессмысленен, если сравнивать с чем-то отдельным, серьёзным. Он не имеет ни одного преимущества перед отдельными реализациями каждой их этих штучек. А если они вдруг нужны, то почему бы не использовать лучшее?
Для большинства приложений это действительно верное решение, но не для каждого. Например, моё приложение добавляет события в календарь каждые N часов (периодическая работа WorkManager) и после настройки пользователю нет необходимости входить в приложение - это просто не нужно, всё без этого работает. Требуется предотвратить заморозку, чтобы оно не сломалось со временем.
Посчитал важным это указать: итоговый эффект после заморозки будет губительнее Restricted Bucket'а, отключение которого не относится напрямую к статье, но всё же было описано (то самое состояние "без ограничений" в настройках батареи и запрещает выдачу Restricted для приложения). А ещё у Restricted Bucket'а и App Hibernation, кажется, общие корни - появились примерно в одно время и имели схожий по длительности срок до наложения ограничений.
Спасибо за статью, прочитать иногда удобне, чем смотреть)
Помимо этого, в Android 13 появилась настройка расхода заряда батареи для каждого приложения.
Она есть и в 12ом. Состояние "без ограничений" автоматически появляется при выдаче прав через пункт в настройках "Экономия заряда батареи", о котором в статье выше. В этом можно убедиться лично просто подёргав переключалки. Поэтому именно переход в настройки приложения не требуется - можно воспользоваться Intent'ом.
Выдача этих прав через intent наиболее удобным способом требует своеобразный (разрешённый лишь в некоторых случаях) пермишен ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, после его получения достаточно вывести запрос на получение разрешения и нажать на одну кнопку:
Кроме того, в статье не описана проблема App Hibernation - эта фича может полностью заморозить приложение, если им не пользуются, соответственно работа сломается. Способ его отключения и множество других подробностей работы с WorkManager PeriodicRequest я описывал в статье на StackOverflow.
Спасибо за статистику, воспользуюсь при построении следующих проектов.
Есть ли какие-либо другие варианты рекламы для приложений? И если есть, почему не используешь?
Как платят наши площадки в сравнении с западными конкурентами? "Грязные зелёные бумажки" я тоже не против получать.
Немного моей коллекции: nft_ptr, morok_fs (файловая система, имеющая встроенную архивацию данных на основе LLM), hello-world.rs, cargo-mommy
Спасибо и вам за добрые слова :)
На самом деле люди не пользуются календарём (поверьте, не только вашего колледжа касается) не из-за того, что не умеют или не хотят планировать свой день - банально не знают, что календарь для этого хорошо подходит. Поэтому, как только появится причина туда заходить, разберутся и наверняка распробуют.
Буду рад вашей интеграции!
Спасибо! Главное, чтоб к тому времени смартфоны не перестали существовать)
ну и не только смартфоныСпасибо за честный и развёрнутый ответ.
Я действительно воспринял ваш комментарий с негативной стороны, поскольку до вас два товарища уже пришли в комменты с целью доказать, что их решение лучше (как водится, без какой-либо аргументации), при этом текст был без структуры, наполовину состоял из наездов, а добрая половина статьи была будто проигнорирована (неужели я задел этих людей?). Сейчас я вижу, что у вас желания навязать свою точку зрения нет, потому прошу прощения за агрессию.
В целом я согласен с тем, что сервисы уровня Moodle могут сильно улучшить качество образования в ВУЗах. И я не против, если такой появится, если ниша не занята (мне кажется, конкретно Moodle крайне много юзкейсов покрывает) и если будет достаточно проработан для широкого внедрения.
Но из комментария мне показалось, что всё таки вы планировали акцентироваться на общем клиенте для разных малосовместимых бекендов, а не полноценный сервис. Историю с клиентом я не понимаю как поддерживать, и главное - какими средствами.
Не кажется ли вам утопичной идея, что студенты всей страны (считаю, у ВУЗов такой заинтересованности нет совсем) решат поднимать аж бекенд для подключения собственного учебного заведения?
Что энтузиаст получает за внедрение своего ВУЗа в ваше приложение? Это важно.
Что будете делать, если кому-то надоест хостить своё решение и у вас 1000 пользователей окажется без расписания? Что будете делать, если новый владелец хоста появится внезапно и будет вместо расписания добавлять что-то нехорошее?
В целом, как решаете возможные проблемы с рекламой, треш-контентом, etc. при получении данных с серверов, которые вам ничего не должны, и влияния вы на них не имеете?
Как решите вопрос, что расписание почему-то устаревшее, так как не получается напрямую с сервера?
Как обойдёте сервисы вроде DDOS-Guard? (да, у нас в ИРНИТУ такой есть).
Столько вопросов, и всё ради каких-то святых контрактов...
Кстати, а почему дока по контракту отсутствует? Там сайт есть, но на нём ничего нет.
Чем легче то?
Кода писать столько же. Вернее, у меня меньше, так как контракт - это всего два датакласса, которые не связаны между собой.
Уведомление "обновись, мы пофиксили тебе расписание" отправить - не проблема. Обновиться, когда прилка весит 2,5 МБ - изи, это меньше, чем видосик в соцсети. Заодно куча людей актуализирует версию приложения.
А точно ли вам будет проще достучаться до владельца сервера, который выпустился из ВУЗа, у него появилась работа, жена, дети, и ему до этого сервера уже нет дела? В моём случае, небольшую правку, да даже полное переписывание парсера, можно внедрить самостоятельно - банально исходники парсера имеются, в отличие от.
Каво? А аргументы будут, или просто "у меня лучше, у меня контракт!!1"?
Часто студенты забывают, где учатся? Это достаточно важная информация, чтобы пользователю постоянно об этом напоминать?
Да я и так знаю, как преподы выглядят, спасибо.
Тем более некоторых лишний раз видеть не хочется.Очень интересно узнать, откуда у вас аватарки студентов, насколько обоюдно получаете их, и насколько это адекватная идея в целом - вообще-то это вполне себе персональные данные. Буду рад взглянуть на имеющееся соглашение о конфиденциальности, или вроде того (оно ведь у вас есть, я надеюсь?).
А вы точно хотя бы скриншот в Google Play видели? Там всё, что выдаётся на обычном сайте, показывается пользователю. Да, весьма в удобном виде.
У меня цель отобразить полезную информацию, а не закошмарить кучей вспомогательной. И для этого не требуется делать 100500 запросов. Создатели сайтов ВУЗов - не дураки, тонна лишней инфы не нужна.
Нет, это слишком нечасто для многих ВУЗов. Рад, если у вас всё за неделю публикуется, но это редкость.
Отсутствие возможности запросить последнее расписание вручную - это прям большая проблема в вашей идеи. Ваши контракты умеют в превентивное обновление?
Ну тут большинство преимуществ и так имеются в календарях.
Реальный минус моего подхода: ссылки на доп. информацию (группы, аудитории) ведут в браузер, а не в приложение. Но, при добавлении UI, можно просто сменить на DeepLink'и.
Не моя зона ответственности. И не ваша. И уж тем более не создателей интеграций.
Кстати, как это будете поддерживать, если аудитория стала занятой вот только что, а у вас обновление данных произойдёт спустя сутки? По клику преподавателя заново "скачивать интернет"?
А если не преподаватель нажмёт?..
А сможете разработать контракт, который покроет ВУЗы? Сможете интегрировать весь мир?
Хотя бы с руководством сможете договориться, что логин/пароль от ЛК будет передаваться стороннему приложению?
Утопия. Может всё таки ЛК человеческий лучше сделать?
OneNote. В нём заведите одну страничку (не более) под дела, связанные с задачами по учёбе. Не благодарите.
И опять перегруженное приложение, которое всех бесит и всё делает неидеально. Мне это неинтересно, спасибо за предложение.
---
Прошу прощения за сумбур, но по факту статья была прочитана плохо, либо в вашем идеальном мире таких проблем нет - объяснился за себя и за студентов, которым просто хочется рабочее, актуальное расписание, без лишнего гемора.
Ваша идея, как я считаю, очень не проработана - надеюсь, описал проблемы достаточно подробно.
С первых версий в приложении встроена полная защита от возможных проблем - отключение Restricted Bucket и App Hibernation. Всю важную информацию описал на StackOverflow.
Для пользователя это выглядит так: после добавления первого расписания появляется предложение нажать на две кнопки, чтобы отключить эти оптимизации. После их нажатия, приложение начинает логировать время срабатывания WorkManager, и через 12 часов говорит, есть ли проблемы с пробуждением для синхронизации.
В самых первых версиях собирал статистику, насколько тема рабочая - на современных смартфонах всё у всех отлично. Существуют проблемы со старыми MIUI (времён 9-ого Android'а), но и их можно пофиксить через лок замочком в меню последних приложений, этот фикс более-менее известен владельцам этих горе-аппаратов. Это описывается в гайде для основных китайских прошивок, который предлагается прочитать при обнаружении проблем с синхронизацией (описано в предудыщем абзаце).
Как итог, за год существования приложения, ни разу не слышал жалоб от пользователей. А ещё, поскольку расписание добавляется лишь на ближайшие недели, проблемы с синхронизацией можно увидеть в прямом смысле - а значит, при необходимости, просто войти в приложение для обновления.
Не стоит обманываться: шаблон был написан на CMP, но проект пока что Android-only.
Я планирую релиз под iOS (и, соответственно, переезд на CMP), но позже. Когда именно? Ну, сейчас у меня ни макбука, ни айфона, ни аккаунта App Store разработчика - к сожалению, без них не скомпилировать приложение для iOS. Сейчас я планирую ввязаться в авантюру с грантами, чтобы получить эти девайсы для разработки и отладки - надеюсь, не реджектнут)
Desktop и Web не планируется по нескольким причинам:
На этих таргетах нет API для календарей и нет удобной синхронизации в фоне, что рушит основные концепции;
При наличии установленного приложения на смартфоне, можно настроить синхронизацию с календарём - подробная информация лежит по ссылке "синхронизация календарей" в конце статьи. Благодаря такой синхронизации, мы не теряем ни одной фичи приложения, при этом можем смотреть расписание на компьютерах уже сейчас.
Спасибо за наводку! Позабыл про деплой через автоматизацию, действительно выглядит как хорошее решение. Вероятно, затащу к себе, когда отойду от единственного магазина.
Знаю лично двух товарищей, что делали подобные приложения без желания "сделать что-нибудь для курсача".
Насчёт рекламы - поначалу в приложении поддерживался только мой ВУЗ, итоги: реклама через паблики почти не работала (прирост менее 5%), по ссылкам в чатах одногруппников переходят единицы (буквально 1-2 человека скачивают на группу 25 человек, всем остальным впадлу что-то новое пробовать), на уровне ВУЗа никому никакие приложения не нужны. Возможно, в вашем ВУЗе все заинтересованы в таких начинаниях, но мне не повезло.
Ну и, вообще-то, запихать рекламу можно и в приложение для одного вуза. Тут вопрос не в количестве, а в принципах/планах разработчика.
Причём здесь "неправильная оценка рынка" не понял. Звучит как наброс.
Благодарю)
Супер! Над скриптами не задумывался, наверное для ВУЗов с редко меняющимся расписанием это отличное решение, и главное - несложное при создании в одиночку.
А насчёт гибкости - с наличием наработок, скорость интеграции будет совсем быстрой, поэтому, если захочется воспользоваться преимуществами приложения, вы знаете, что делать)
Очевидно, никак, к сожалению. К счастью, многие уже отказались от этой практики, большинство ВУЗов имеют нормальное расписание.
Однако основную идею можно использовать, сделав общий гугл календарь. Его можно будет расшарить среди одногруппников, дальше достаточно лишь вносить изменения по необходимости. Работы там не слишком много, найдите отвественного и технически подкованного человека, и в путь.
В текущий момент мне важны быстрые релизы (как небольшие, так и важные обновления), а также набор аудитории в одном месте.
Адаптация для дополнительных магазинов и публикация в нескольких местах - очевидные лишние времязатраты. Вот несколько примеров, где это могло бы повлечь проблемы:
Недавно была неделя, когда приложение начало собирать сравнительно много аудитории (небольшой пиар сработал слишком хорошо) и тогда я не ленился заливать новые билды сразу после добавления улучшения - за неделю я залил 4 обновы. Да, это небольшие правки, но из тысячей мелочей и складывается отличный продукт. К счастью, сейчас я могу себе позволить такое, и единственный магазин - одна из причин.
А ещё, я с января по сегодня аж 6 раз менял иллюстрации на странице приложения. Тоже небольшие правки, но они важны.
Думаю, не стоит объяснять, почему несколько магазинов заставило бы ухудшить показатели скорости обновлений.
Помимо этого, сейчас мне важно накрутить счётчик загрузок: иметь в каждом сторе по 30 загрузок вместо 100+ в одном - ну это какое-то странное решение.
Если проект взлетит, то приложение появится не только в Google Play. Публикация также в RuStore - не проблема. Но на начальных этапах наличие нескольких магазинов для одной платформы - выстрел в ногу.
Вопрос интересный, спасибо)
Здесь, я считаю, не менее важно сравнить с прямыми конкурентами.
Платные курсы? Ох, здесь слишком большой выбор. Заходим в гугл/ютуб и ищем наиболее подходящее по теме, и в 99,9% случаев получаем качество лучше и совершенно бесплатно.
Стажировки? Вряд-ли классный работодатель у дома дойдёт до приложения, которое никак не связано с поиском работы - он быстрее кого-нибудь привлечёт на hh/avito/работару или в пабликах vk. Если работодатель оказался в супераппе для студентов, то, вероятно, имеем дело с ненормальной текучкой кадров или максимально невыгодными условиями.
Скидки? Ну, может быть. У меня не сложилось найти чего-либо полезного, одни "товары для левшей" со скидками по четвергам (как водится, даже по четвергам будет оверпрайс в сравнении с соседними заведениями). Если получилось что-то найти реальное полезное из скидок - ок, валидно. Даже интересно услышать кейсы).
Мемы? Удобнее в вк/тг, притом там они могут быть смешными. Ну, вернее, подходят под индивидуальное чувство юмора, нет цензуры, нет бесконечной привязки к идее "я - студент".
Подслушка? Тоже в вк/тг. Нет ни одной причины иметь отдельную в приложении для учёбы. Тем более в немодерируемом виде.
Короче, суперапп для учёбы бессмысленен, если сравнивать с чем-то отдельным, серьёзным. Он не имеет ни одного преимущества перед отдельными реализациями каждой их этих штучек. А если они вдруг нужны, то почему бы не использовать лучшее?
Для большинства приложений это действительно верное решение, но не для каждого. Например, моё приложение добавляет события в календарь каждые N часов (периодическая работа WorkManager) и после настройки пользователю нет необходимости входить в приложение - это просто не нужно, всё без этого работает. Требуется предотвратить заморозку, чтобы оно не сломалось со временем.
Посчитал важным это указать: итоговый эффект после заморозки будет губительнее Restricted Bucket'а, отключение которого не относится напрямую к статье, но всё же было описано (то самое состояние "без ограничений" в настройках батареи и запрещает выдачу Restricted для приложения). А ещё у Restricted Bucket'а и App Hibernation, кажется, общие корни - появились примерно в одно время и имели схожий по длительности срок до наложения ограничений.
Спасибо за статью, прочитать иногда удобне, чем смотреть)
Она есть и в 12ом. Состояние "без ограничений" автоматически появляется при выдаче прав через пункт в настройках "Экономия заряда батареи", о котором в статье выше. В этом можно убедиться лично просто подёргав переключалки. Поэтому именно переход в настройки приложения не требуется - можно воспользоваться Intent'ом.
Выдача этих прав через intent наиболее удобным способом требует своеобразный (разрешённый лишь в некоторых случаях) пермишен ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, после его получения достаточно вывести запрос на получение разрешения и нажать на одну кнопку:
Кроме того, в статье не описана проблема App Hibernation - эта фича может полностью заморозить приложение, если им не пользуются, соответственно работа сломается. Способ его отключения и множество других подробностей работы с WorkManager PeriodicRequest я описывал в статье на StackOverflow.
Что-то мне это очень напоминает...
Ещё приложение было, до сих пор работает из APK.
Упс, действительно, из-за разной обрезки скриншотов недоглядел) извиняюсь
Кажется, последняя картинка пункта 2.1 случайно вставлена повторно, вместо неё должен быть вариант без рекомпозиций.