Все началось с Kotlin. Случайно попалась статья про новый язык, что на нем можно писать под Android. Соприкоснувшись с темой, узнал что изначально приложения под Android пишутся на JAVA. Решил узнать на сколько трудоемко писать приложения под Android, в чем преимущества платформы на практике. Ведь по сути приложения JS и приложения Android выполняют одну и туже функцию. Заодно решил провести эксперимент. Что можно сделать за 12 часов, не зная что такое JAVA и тонкости разработки под Android, используя как помощник только Google. Пришла идея, которую развил в постановку задачи.
Взять из внешнего сервиса список всех Аэропортов мира и по коду Аэропорта получить от внешнего сервиса он-лайн табло с информацией о статусах рейсов. В 100% приложений, которые лежат в google play и реализуют такую функцию, нужно проходить цепочку действий, искать внутри приложения. Я лично, не нашел агрегатор, который позволял бы на первой странице ввести любой Аэропорт и получить его он-лайн табло. Идея и приложение само по себе простое, но это функция которой пользуется любой кто совершает перелет. Доступ к такой информации должен быть мгновенным.
Нашел потрясающий сервис, который открывает много возможности в части разработки под Авиацию. developer.flightstats.com Зарегистрировался получил на месяц бесплатный аккаунт.
Действовал интуитивно, полагаясь на свой опыт разработки в JavaScript. Набросал скетчи экранов в Photoshop. Составил требования к приложению.
Дальше был Я, Google и Android Studio.
Из опыта понимаю что код нужно организовывать. Интуитивно определил структуру проекта. Выделил следующие группы(Models, Stores, Views, Fields, API, Adapters) Двигало мной в этот момент бессознательное, вернее опыт. Дальше начал развлекаться с Layouts. Android Studio очень интуитивный редактор, это одна из причин которая подвигла попробовать написать Android приложение. Если kind of intellij idea – значит все комфортно. Плюс редактор лежит в бесплатном доступе, никаких ограничений, развивается и обновляется регулярно. Layouts сложились на раз два. Ни одного глюка за весь период работы, все на своих местах.
Момент который меня насторожил в самом начале, в 90% источниках, поиск и работа ведется по ID компонента. Обще принято, работа с ID это bad practice, в Android оказалось нормальной практикой. Погуглил, одно из лекарств DataBinding, отличная вещь, позволяет уйти от findViewById. Но, принцип в начальной стадии и еще год назад связь работала в одну сторону. Звучит странно, DataBinding но в одну сторону. Нужно было писать свою реализацию чтобы DataBinding был полноценный. Опираясь на реализации в JS, удивил концепт, который на текущий момент предлагает Data Binding Library(можно увидеть в большинстве случаев в сети), в ViewModel размещается логика по обработке handlers от визуальных компонент, которые в свою очередь могут иметь прямой доступ к данным которые лежат в ViewModel. С виду какой то гибрид контроллера и ViewModel.
Далее пошли вопросы коммуникации, то что нагуглилось с первого раза повергло в шок. Чтобы сделать обычный AJAX запрос нужно было тянуть строк 70 кода. Создавать фоновый процесс и там уже творить магию соединения, а потом через буфер собирать ответ. «Не может быть, чтобы было так сложно!» и продолжил поиск. В одном из результатов попалась статья про Retrofit2. С Retrofit стало все веселее и в целом жить можно в части коммуникаций. Определился с интерфейсами взаимодействия с сервером и начал сопрягать данные с визуальными компонентами.
С фильтром spinner(он же combobox) пришлось повозиться, возможно из-за неопытности. По ходу возникала куча вопросов от конвертации одного типа в другой до как реализован ООП в JAVA, но все элементарно находилось в stack overflow с ответами и примерами, плюс интуиция. В целом все шло как по маслу, кроме некоторых моментов. Чего не ожидал, что получу головную боль с датой. Почему то JAVA(или может быть это у меня так вышло) по defaul выдавала все в UTC.
В целом каких то совсем непреодолимых моментов не было из-за которых возникал полный стопор. Что не понял(зачем это сделали как dafault поведение?!) При изменении ориентации экрана(или конфигурации), ваша View которая присутствует на экране уничтожается и в новом повернутом экране заново пересоздается(фоном идет масштабная работа). Что порождает головную боль если у Вас в классе View(она же «Активность») есть динамические данные, они просто теряются при уничтожении View и с этим что-то надо делать. Дайте эту возможность, но опционально, для тех кто хочет подменять экраны при повороте. Интересно услышать мнение Android разработчика по этому поводу, возможно я не вижу всей картинки в целом.
Потрясла производительность интерфейсов при большой нагрузке. Для теста сделал 8 spinner, в каждый забросил 4000 записей(в каждой записи еще набор свойств) и приложение даже не крякнуло. При такой ситуации, JS приложение напряглось бы, и если бы еще нужно было отображать все записи сразу, и иметь доступ работы с ними, то большая вероятность поймать зависание экрана или вообще «Опаньки». Пришлось бы тащить буферизацию вывода или решать как то алгоритмически. Но есть задачи когда нужен весь объем и сразу.
Многопоточность и фоновые процессы, на лету. Что в JS нужно можно делать с помощью webworkers, но там свои трудности, которые при разработке под Android решаются на раз, два. Причем фоном можно тягать действительно весомые объемы. Это огромное value для разработки off line приложений с сложными инженерными расчетами.
Приложение под браузер имеет свой потолок по производительности, если речь идет о высоко нагруженных интерфейсах(вывод одновременно большого объема данных) или когда фоном нужно делать объемные вычисления. Здесь перед Android приложениями снимаю шляпу. Но если Вам нужно делать что-то средне статистическое, то javascript возьмет свое скоростью разработки.
Признаю, трудоемко писать под Android и требует в разы больше времени чем написание приложений на JS, но google интенсивно развивает и наращивает платформу. Неделя сидения за книгами и теорией Android разработки скорее всего убило бы идею попробовать сделать Android приложение и не дала бы навыков и опыта полученного за эти 12 часов. Реально столкнуться с проблемами и увидеть мир изнутри, получить первую оценку возможностей Android приложений и в будущем, столкнувшись с задачами трудно реализуемыми в JS, иметь в запасе знания куда можно еще бросить свой взгляд. Практика — быстрый путь к достижению навыков и опыта.
Что получилось: Android-приложение для просмотра он-лайн табло любого аэропорта мира.
При наличие других 12 часов, есть желание развить идею дальше.
Игорь
Постановка задачи
Взять из внешнего сервиса список всех Аэропортов мира и по коду Аэропорта получить от внешнего сервиса он-лайн табло с информацией о статусах рейсов. В 100% приложений, которые лежат в google play и реализуют такую функцию, нужно проходить цепочку действий, искать внутри приложения. Я лично, не нашел агрегатор, который позволял бы на первой странице ввести любой Аэропорт и получить его он-лайн табло. Идея и приложение само по себе простое, но это функция которой пользуется любой кто совершает перелет. Доступ к такой информации должен быть мгновенным.
Нашел потрясающий сервис, который открывает много возможности в части разработки под Авиацию. developer.flightstats.com Зарегистрировался получил на месяц бесплатный аккаунт.
Действовал интуитивно, полагаясь на свой опыт разработки в JavaScript. Набросал скетчи экранов в Photoshop. Составил требования к приложению.
Форма «Поиск»
- Приложение должно загружать список всех аэропортов мира в компонент типа «Выпадающий список».
- Дать возможность с помощью фильтра выбирать аэропорт, переключать время UTC/LT(местное время)
Форма «Результат»
- Вывод данных в виде таблицы
- Сортировка по времени Прилет\Вылет
Разработка
Дальше был Я, Google и Android Studio.
Из опыта понимаю что код нужно организовывать. Интуитивно определил структуру проекта. Выделил следующие группы(Models, Stores, Views, Fields, API, Adapters) Двигало мной в этот момент бессознательное, вернее опыт. Дальше начал развлекаться с Layouts. Android Studio очень интуитивный редактор, это одна из причин которая подвигла попробовать написать Android приложение. Если kind of intellij idea – значит все комфортно. Плюс редактор лежит в бесплатном доступе, никаких ограничений, развивается и обновляется регулярно. Layouts сложились на раз два. Ни одного глюка за весь период работы, все на своих местах.
Момент который меня насторожил в самом начале, в 90% источниках, поиск и работа ведется по ID компонента. Обще принято, работа с ID это bad practice, в Android оказалось нормальной практикой. Погуглил, одно из лекарств DataBinding, отличная вещь, позволяет уйти от findViewById. Но, принцип в начальной стадии и еще год назад связь работала в одну сторону. Звучит странно, DataBinding но в одну сторону. Нужно было писать свою реализацию чтобы DataBinding был полноценный. Опираясь на реализации в JS, удивил концепт, который на текущий момент предлагает Data Binding Library(можно увидеть в большинстве случаев в сети), в ViewModel размещается логика по обработке handlers от визуальных компонент, которые в свою очередь могут иметь прямой доступ к данным которые лежат в ViewModel. С виду какой то гибрид контроллера и ViewModel.
Далее пошли вопросы коммуникации, то что нагуглилось с первого раза повергло в шок. Чтобы сделать обычный AJAX запрос нужно было тянуть строк 70 кода. Создавать фоновый процесс и там уже творить магию соединения, а потом через буфер собирать ответ. «Не может быть, чтобы было так сложно!» и продолжил поиск. В одном из результатов попалась статья про Retrofit2. С Retrofit стало все веселее и в целом жить можно в части коммуникаций. Определился с интерфейсами взаимодействия с сервером и начал сопрягать данные с визуальными компонентами.
С фильтром spinner(он же combobox) пришлось повозиться, возможно из-за неопытности. По ходу возникала куча вопросов от конвертации одного типа в другой до как реализован ООП в JAVA, но все элементарно находилось в stack overflow с ответами и примерами, плюс интуиция. В целом все шло как по маслу, кроме некоторых моментов. Чего не ожидал, что получу головную боль с датой. Почему то JAVA(или может быть это у меня так вышло) по defaul выдавала все в UTC.
В целом каких то совсем непреодолимых моментов не было из-за которых возникал полный стопор. Что не понял(зачем это сделали как dafault поведение?!) При изменении ориентации экрана(или конфигурации), ваша View которая присутствует на экране уничтожается и в новом повернутом экране заново пересоздается(фоном идет масштабная работа). Что порождает головную боль если у Вас в классе View(она же «Активность») есть динамические данные, они просто теряются при уничтожении View и с этим что-то надо делать. Дайте эту возможность, но опционально, для тех кто хочет подменять экраны при повороте. Интересно услышать мнение Android разработчика по этому поводу, возможно я не вижу всей картинки в целом.
Awesome
Потрясла производительность интерфейсов при большой нагрузке. Для теста сделал 8 spinner, в каждый забросил 4000 записей(в каждой записи еще набор свойств) и приложение даже не крякнуло. При такой ситуации, JS приложение напряглось бы, и если бы еще нужно было отображать все записи сразу, и иметь доступ работы с ними, то большая вероятность поймать зависание экрана или вообще «Опаньки». Пришлось бы тащить буферизацию вывода или решать как то алгоритмически. Но есть задачи когда нужен весь объем и сразу.
Многопоточность и фоновые процессы, на лету. Что в JS нужно можно делать с помощью webworkers, но там свои трудности, которые при разработке под Android решаются на раз, два. Причем фоном можно тягать действительно весомые объемы. Это огромное value для разработки off line приложений с сложными инженерными расчетами.
Приложение под браузер имеет свой потолок по производительности, если речь идет о высоко нагруженных интерфейсах(вывод одновременно большого объема данных) или когда фоном нужно делать объемные вычисления. Здесь перед Android приложениями снимаю шляпу. Но если Вам нужно делать что-то средне статистическое, то javascript возьмет свое скоростью разработки.
Резюме
Признаю, трудоемко писать под Android и требует в разы больше времени чем написание приложений на JS, но google интенсивно развивает и наращивает платформу. Неделя сидения за книгами и теорией Android разработки скорее всего убило бы идею попробовать сделать Android приложение и не дала бы навыков и опыта полученного за эти 12 часов. Реально столкнуться с проблемами и увидеть мир изнутри, получить первую оценку возможностей Android приложений и в будущем, столкнувшись с задачами трудно реализуемыми в JS, иметь в запасе знания куда можно еще бросить свой взгляд. Практика — быстрый путь к достижению навыков и опыта.
Что получилось: Android-приложение для просмотра он-лайн табло любого аэропорта мира.
Послесловие
При наличие других 12 часов, есть желание развить идею дальше.
Игорь
