n
что касается выкладки, то у нас в компании для тестирования исопльзуется HockeyApp
Size: a a a
2018 January 17
n
CI настроен так, что каждая новая сборка загружается в хокей, и высылаются уведомления тестированию и заинтересованным лицам
AB
CI настроен так, что каждая новая сборка загружается в хокей, и высылаются уведомления тестированию и заинтересованным лицам
ci/cd от jenkins?)
n
gitlab
AB
я немного зайду вперед и расскажу принцип.
Релизная версия приложения подписывается ключом. Так же в градле файле мы указываем versionCode.
Если на устройство попытаться установить приложение, которое уже присутствует на нем, то
- проверится подпись приложения - они должны совпадать.
если не совпадает, то устройство предложит удалить установленное приложение.
- проверится versionCode - код устанавливаемого приложения должен быть выше, чем у установленного. если не выше - то будет алерт, что пытается установиться старая версия приложения.
Иначе все ок.
Это что касается обновления
Релизная версия приложения подписывается ключом. Так же в градле файле мы указываем versionCode.
Если на устройство попытаться установить приложение, которое уже присутствует на нем, то
- проверится подпись приложения - они должны совпадать.
если не совпадает, то устройство предложит удалить установленное приложение.
- проверится versionCode - код устанавливаемого приложения должен быть выше, чем у установленного. если не выше - то будет алерт, что пытается установиться старая версия приложения.
Иначе все ок.
Это что касается обновления
Это как раз то, что хотел услышал, просто не знал как спросить)
Получается сам механизм обновления не такой уж и сложный?
А "запрос" на проверку актуальной версии реализуется как-то в самом приложении и/или Android платформой?
Миграция БД (SQLite) на сколько я понимаю лежит на плечах разработчика и реализуется в приложении? Получается что также важно соблюсти последовательность установленных версий, чтобы что то в БД не слетело? Грубо говоря:
1 -> 2 -> 3 (изменили имя поля) -> 4 -> 5...
1 -> 2 -> 4 error
Но если частота релизовов высокая, а какое-то устройство "пролежало на полке" с установленно версией (2) и не получало обновления, например, (3), а в этом обновлении, например, переименовали поле. Включили телефон, а на сервере уже лежит версия (4) — получается, что как-то это нужно "проконтролировать"?
Получается сам механизм обновления не такой уж и сложный?
А "запрос" на проверку актуальной версии реализуется как-то в самом приложении и/или Android платформой?
Миграция БД (SQLite) на сколько я понимаю лежит на плечах разработчика и реализуется в приложении? Получается что также важно соблюсти последовательность установленных версий, чтобы что то в БД не слетело? Грубо говоря:
1 -> 2 -> 3 (изменили имя поля) -> 4 -> 5...
1 -> 2 -> 4 error
Но если частота релизовов высокая, а какое-то устройство "пролежало на полке" с установленно версией (2) и не получало обновления, например, (3), а в этом обновлении, например, переименовали поле. Включили телефон, а на сервере уже лежит версия (4) — получается, что как-то это нужно "проконтролировать"?
n
Это как раз то, что хотел услышал, просто не знал как спросить)
Получается сам механизм обновления не такой уж и сложный?
А "запрос" на проверку актуальной версии реализуется как-то в самом приложении и/или Android платформой?
Миграция БД (SQLite) на сколько я понимаю лежит на плечах разработчика и реализуется в приложении? Получается что также важно соблюсти последовательность установленных версий, чтобы что то в БД не слетело? Грубо говоря:
1 -> 2 -> 3 (изменили имя поля) -> 4 -> 5...
1 -> 2 -> 4 error
Но если частота релизовов высокая, а какое-то устройство "пролежало на полке" с установленно версией (2) и не получало обновления, например, (3), а в этом обновлении, например, переименовали поле. Включили телефон, а на сервере уже лежит версия (4) — получается, что как-то это нужно "проконтролировать"?
Получается сам механизм обновления не такой уж и сложный?
А "запрос" на проверку актуальной версии реализуется как-то в самом приложении и/или Android платформой?
Миграция БД (SQLite) на сколько я понимаю лежит на плечах разработчика и реализуется в приложении? Получается что также важно соблюсти последовательность установленных версий, чтобы что то в БД не слетело? Грубо говоря:
1 -> 2 -> 3 (изменили имя поля) -> 4 -> 5...
1 -> 2 -> 4 error
Но если частота релизовов высокая, а какое-то устройство "пролежало на полке" с установленно версией (2) и не получало обновления, например, (3), а в этом обновлении, например, переименовали поле. Включили телефон, а на сервере уже лежит версия (4) — получается, что как-то это нужно "проконтролировать"?
1. запрос в самой системе
2. когда добавляется новая версия апи на сервере, она разграничивается через поддомен, например, api.com/v1/ меняется на api.com/v2/
но это не означает что v1 больше не используется
2. когда добавляется новая версия апи на сервере, она разграничивается через поддомен, например, api.com/v1/ меняется на api.com/v2/
но это не означает что v1 больше не используется
n
то есть необновленные приложения будут пользоваться v1
n
обновившись, они начнут ссылаться на v2
n
ну и бд соответственно поменяется
AB
1. запрос в самой системе
2. когда добавляется новая версия апи на сервере, она разграничивается через поддомен, например, api.com/v1/ меняется на api.com/v2/
но это не означает что v1 больше не используется
2. когда добавляется новая версия апи на сервере, она разграничивается через поддомен, например, api.com/v1/ меняется на api.com/v2/
но это не означает что v1 больше не используется
А если это внутренняя БД (SQLite)?
n
БД ведь привязано к приложению.
Ты ведь не можешь обновить БД, не обновив при этом само приложение.
Если можешь, то расскажи)
Ты ведь не можешь обновить БД, не обновив при этом само приложение.
Если можешь, то расскажи)
AB
БД ведь привязано к приложению.
Ты ведь не можешь обновить БД, не обновив при этом само приложение.
Если можешь, то расскажи)
Ты ведь не можешь обновить БД, не обновив при этом само приложение.
Если можешь, то расскажи)
Да мне бы, первые приложения написать) Спасибо, буду сейчас со всем разбираться.
n
Смотрите еще кое-что
n
из коробки Android поддерживает SQLite через SQLiteOpenHelper.
Скажу прямо, работать с БД напрямую - удовольствие не для слабонервных.
Поэтому, во втором курсе, когда мы уже будет разбирать работу с БД, вместо чистого SQLITE будет гугловская обертка Room.
Она простая, понятная, легко создается, легко настраивается.
Скажу прямо, работать с БД напрямую - удовольствие не для слабонервных.
Поэтому, во втором курсе, когда мы уже будет разбирать работу с БД, вместо чистого SQLITE будет гугловская обертка Room.
Она простая, понятная, легко создается, легко настраивается.
n
В компаниях так или иначе используют обертки, Realm, greenDAO и другие.
Некоторые пишут свои (легион тоже этим занимался)
Но, я настоятельно рекомендую не изобретать велосипед и не углубляться под капот.
Это всегда можно сделать в будущем
Некоторые пишут свои (легион тоже этим занимался)
Но, я настоятельно рекомендую не изобретать велосипед и не углубляться под капот.
Это всегда можно сделать в будущем
AB
из коробки Android поддерживает SQLite через SQLiteOpenHelper.
Скажу прямо, работать с БД напрямую - удовольствие не для слабонервных.
Поэтому, во втором курсе, когда мы уже будет разбирать работу с БД, вместо чистого SQLITE будет гугловская обертка Room.
Она простая, понятная, легко создается, легко настраивается.
Скажу прямо, работать с БД напрямую - удовольствие не для слабонервных.
Поэтому, во втором курсе, когда мы уже будет разбирать работу с БД, вместо чистого SQLITE будет гугловская обертка Room.
Она простая, понятная, легко создается, легко настраивается.
AB
SQLiteOpenHelper... из за того, что нужно для запросов запросы в строках собирать?
Вот оно, что за Room... — буду знать.
Вот оно, что за Room... — буду знать.
n
не только из за этого.
Сам процесс создания такой БД - долгий и мучительный.
Реально, очень долгий. Плюс можно опечататься в запросе, а потом долго искать ошибку.
Сам процесс создания такой БД - долгий и мучительный.
Реально, очень долгий. Плюс можно опечататься в запросе, а потом долго искать ошибку.
AB
не только из за этого.
Сам процесс создания такой БД - долгий и мучительный.
Реально, очень долгий. Плюс можно опечататься в запросе, а потом долго искать ошибку.
Сам процесс создания такой БД - долгий и мучительный.
Реально, очень долгий. Плюс можно опечататься в запросе, а потом долго искать ошибку.
А обертки в Java/Android не сильно на производительность как самого приложения так и запросов к БД влияют?