Речь пойдёт только о версии для Android, которая наиболее важна и популярна. Версия для Windows/Linux/macOS мало кому интересна (даже с учётом, что там чуть больше возможностей), поэтому нет смысла с ней возиться, а для iOS и не планировал ничего делать.
А проблема простая. Разработка приложения на уровнe Android API сложна. Даже не так, не столько сложна по своей сути, сколько мелочная и постоянно меняется. Нужно этим профессионально жить, постоянно находиться в потоке. А мне это не особо интересно, да и нет ресурсов.
Немного истории. Изначально весь SZ Viewer хоть и предназначался для запуска под Java Runtime Environment, но разрабатывался на языке Scala. Scala - это язык, который, по моему мнению, лучше и выше уровнем, чем Java.
А наличие Java-основы позволило достаточно немаленький объём кода SZ Viewer (сами протоколы, данные, работа с ELM327 и т.п.) одновременно использовать и для PC, и для Android-приложения.
К сожалению, разработчики Scala сильно недооценили Android, тем самым совершили, на мой взгляд, серьёзную ошибку продвижения, которая в том числе и привела к падению интереса к этому языку. А пользователи языка получили проблемы со сборкой Android-приложений.
Первое время (в 2014 году) состояние дел ещё было терпимым, что позволило развивать SZ Viewer для Android, пусть и достаточно медленно.
Но чем дальше, тем хуже. В значимые моменты перехода приходилось повозиться, чтобы сохранить Android-проект рабочим: в 2017 году (переход с минимума 2.2 на 2.3) и в 2018 году (переход с минимума 2.3 на 4.0).
Сейчас проект собирается, но уже как махровый legacy. Сборка старым sbt с давно устаревшим Android-плагином плохо встраивается в современный процесс Android-разработки. Используемая Scala 2.11 ощутимо устарела, но сохранена из-за сложностей перехода на уровень Java 8 (который нужен для 2.12 и 2.13) для Android. Из-за этого же используется старая версия Android Support Library (почти четырёхлетней давности).
Поэтому развитие ограничивается только совсем небольшими правками Android-кода (в основном исправление ошибок) и улучшением общей протокольной части. И каждый раз я надеюсь, что сборка не сломается.
Скажу больше, я подготовил проект для более современной разработки: уже на базе Gradle в качестве системы сборки и Kotlin в качестве языка, хотя это опять поднимает минимальную версию (скорее всего до 4.3). Начал перенос Android-приложения на эти рельсы. Но в какой-то момент понял, что мне это неинтересно.
И сама разработка под Android не вызывает восторга, да и язык Kotlin у меня вызывает тоску. Scala, возможно, это сложный (в смысле "богатый возможностями"), но целостный язык с мощной коллекционной библиотекой, который изначально разрабатывается образованными и опытными людьми. А Kotlin сразу мною воспринят как язык "колхозников", которые не очень понимали в языках программирования, не разобрались в Scala, поэтому решили сделать свою "улучшенную" версию.
Со временем Kotlin стали подправлять, он стал больше приближаться к Scala (забавно было видеть появление возможностей Scala, которые изначально подвергались критике авторами Kotlin). Похоже, что команда стала посильнее, но основа уже никуда не исчезнет. Для меня сложности писать на Kotlin нет, да и это лучше, чем Java (в целом), но для сугубо хобби-проекта нужен личный интерес, а Kotlin вызывает только уныние. Да и перспективы за пределами Android-программирования не особо видны. Да, они сильно вложились в coroutines, но это ещё не весь язык, да и будущее самой Java-платформы под вопросом.
В общем, перенос Android-части проекта на Gradle + Kotlin я остановил. Как и особо не занимаюсь остальными частями SZ Viewer. С одной стороны жалко всё это выкидывать - работы было сделано достаточно много. Но и не планирую всё это отдавать в open source по личным причинам.
Конечно, есть вариант перехода к Android-разработке не на низком API, а на громоздких фреймворках выше уровнем. Очень много ПО так и создаётся, но оно и выглядит ненативно, занимает много места, медленно и кривовато работает. А суть Android-версии SZ Viewer и была изначально в лёгкости, скорости и нетребовательности к ресурсам, поэтому разработка на уровне Android API для меня приоритетна.
Естественно, я неоднократно приценивался к коммерческому применению, но диагностика для Suzuki потенциала не имеет. Какие-то деньги это, наверное, принесёт, но это того не стоит. Для коммерции нужно делать OBDII + графическую мишуру, это совсем иной потенциал. Но уже много конкурентов, да и в целом меня такая разработка не привлекает.
Есть мысли сделать что-нибудь совсем необычное на базе знаний, полученных при разработке SZ Viewer. Но пока получается гиковые и потенциально очень непопулярные идеи. С другой стороны, лично мне они более интересны, чем развитие надоевшей уже Android-версии.
Еще по этой теме:
- На чём я пишу SZ Viewer (2022) (2022-12-11)
- Nokia 5.3: Android 12 на подходе? (2022-11-07)
- Google Play и Android-приложения без обновлений (2022-04-23)
