Імпорт CSV в Android: де ламається завантаження даних
Імпорт CSV на Android ламається не на кнопці «Завантажити», а на даних.
Файл надходить із 1С, Google Sheets або вивантаження CRM — і в ньому майже завжди є розбіжності: роздільник ; замість ,, кодування Windows-1251 замість UTF-8, десяткова кома в числах, дати у форматі дд.мм.рррр поряд з ISO.
Наївний парсинг CSV за комою на таких файлах дає зсув колонок: один рядок із зайвою лапкою — і всі наступні поля з'їжджають у сусідні стовпці.
Окрема категорія збоїв — великі файли. Вивантаження на 50-100 тисяч рядків, прочитане повністю в пам'ять, валить застосунок на пристроях із 2-3 ГБ ОЗП: система вбиває процес раніше, ніж користувач бачить прогрес.
Обрив з'єднання на середині завантаження погіршує картину — повторний імпорт створює дублі, бо перша спроба частково записала дані.
Excel додає свої граблі: .xlsx — це ZIP-архів із XML усередині, і спроба відкрити його як текстовий CSV дає сміття замість таблиці. А формули, об'єднані комірки та кілька аркушів вимагають явного рішення — який аркуш читаємо і що робимо з обчислюваними значеннями.
Нарешті, помилки імпорту CSV майже ніколи не показуються користувачеві зрозуміло: «не вдалося завантажити файл» не говорить, у якому рядку бита лапка.
Без порядкового звіту з номером рядка та причиною відбракування людина править файл наосліп, а підтримка отримує тікети без діагностики.
Розбираємо, як кожен із цих збоїв закривається на рівні архітектури завантаження та парсингу.
Що дає керований імпорт даних у застосунку
Керований імпорт — це не «кнопка завантажити файл», а конвеєр: розбір структури, валідація рядків, звіт про помилки та транзакційний запис.
Коли він вибудуваний, швидкість імпорту даних перестає залежати від розміру файлу: потокова обробка тримає стабільний темп на десятках тисяч рядків, а прогрес видно користувачеві, а не завмирає на одному екрані.
Надійність завантаження дає передбачуваність: кожен рядок або проходить цілком, або відхиляється зі зрозумілою причиною — без частково записаних записів, які потім доводиться вичищати вручну.
Частка успішних імпортів зростає завдяки попередній перевірці формату, кодування та обов'язкових полів до запису в базу.
Зниження ручного вводу — прямий ефект від зіставлення колонок файлу з полями застосунку. Користувач один раз підтверджує відповідність, далі система запам'ятовує шаблон і застосовує його до наступних вивантажень. Це прибирає передруковування та пов'язані з ним одруки.
Звернення до підтримки падають, коли помилку пояснено на місці: замість «імпорт не вдався» користувач бачить номер рядка, проблемне поле та підказку.
Ми працюємо на Android та iOS з урахуванням обмежень кожної платформи — доступ до файлів, фонова обробка, поведінка при згортанні застосунку.
Що вимірюємо на виході
- Час обробки файлу на еталонному наборі рядків — до і після оптимізації.
- Частка імпортів, завершених без ручних правок.
- Кількість звернень за темою завантаження даних за період.
- Повнота звіту про помилки: скільки відхилених рядків отримали зрозумілу причину.
Ці метрики знімаємо на пілотному наборі даних замовника, а не на синтетиці — так видно реальний профіль файлів і вузькі місця.
Способи завантаження CSV та Excel: порівняння підходів
Вибір способу імпорту визначає, як застосунок поводитиметься на файлі в 200 тисяч рядків і на телефоні з вільними 300 МБ пам'яті.
Нижче — чотири робочі варіанти, між якими реально обирають під час проєктування: вони відрізняються джерелом даних, вимогами до пам'яті та стійкістю до обривів зв'язку.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Імпорт із файлу (локальний вибір) | Разові завантаження, робота офлайн, дані надходять від користувача | Потрібен доступ до сховища, на великих файлах потрібна потокова обробка |
| Завантаження з хмари | Дані лежать у спільному сховищі, потрібна синхронізація між пристроями | Залежить від мережі, потребує авторизації та обробки прострочених токенів |
| Потоковий імпорт | Файли від десятків тисяч рядків, обмежена пам'ять | Складніший у реалізації: читання порядково, без завантаження всього файлу в пам'ять |
| Фонова синхронізація | Регулярний обмін, дані оновлюються без участі користувача | Потрібні планувальник, повторні спроби та дозволи ОС на роботу у фоні |
Що важливо при виборі
Потоковий імпорт читає файл порядково й пише в базу порціями — застосунок не тримає весь набір у пам'яті, тому файл на 200 тисяч рядків проходить без падінь. Локальний імпорт із файлу дає незалежність від мережі, але потребує коректної роботи з дозволами та зовнішнім сховищем.
Хмарне завантаження та фонова синхронізація розв'язують задачу регулярного обміну, але додають вимоги до мережі та авторизації. На практиці їх комбінують: потокове читання як основа, фонова синхронізація як надбудова для повторюваних сценаріїв.
Як ми вибудовуємо імпорт CSV в Android: етапи робіт
Імпорт CSV в Android майже ніколи не зводиться до «прочитати файл і розкласти за полями». Джерела надходять із 1С, вивантажень CRM, таблиць бухгалтерії — з різними розділювачами, кодуваннями, десятковими комами та «шапками» на третьому рядку.
Тому ми ведемо проєкт етапами: кожен наступний спирається на зафіксований результат попереднього, а не на здогадки про те, «як там у клієнта насправді».
Етапи впровадження імпорту
- Аудит даних. Збираємо реальні вивантаження за кілька періодів, а не один зразок. Фіксуємо розділювачі, кодування, формати дат і чисел, порожні рядки, дублі заголовків. На виході — перелік джерел та їхніх відмінностей.
- Схема мапінгу колонок. Зіставляємо поля файлу з полями застосунку: що обов'язкове, що опціональне, де потрібні перетворення. Правила мапінгу описуємо декларативно — нову колонку додаємо правкою конфігурації, а не перезбиранням логіки.
- Реалізація парсера та валідації. Потокове читання замість завантаження файлу цілком у пам'ять, перевірка типів і діапазонів на кожному рядку. Помилки збираються у звіт із номером рядка та причиною, а не валять імпорт цілком.
- Обробка конфліктів. Визначаємо поведінку при збігу ключів: оновити, пропустити, створити дубль. Це рішення фіксуємо до розробки — пізніше воно коштує найдорожче.
- Тестування імпорту на реальних файлах. Проганяємо вивантаження з усіх джерел, включно з «брудними»: биті кодування, зайві колонки, обрізані рядки. Звіряємо кількість і вміст записів до і після.
- Передача та документація. Віддаємо опис форматів, правил мапінгу та поведінки при помилках — щоб підтримку можна було вести без нас.
Порядок етапів невипадковий: аудит і мапінг знімають основну частину ризиків, а тестування на справжніх файлах ловить те, що не відтворюється на синтетиці. Опишіть ваші джерела — повернемося з оцінкою та планом робіт.
Артефакти та документація після впровадження імпорту
Після здачі проєкту у вас залишається не «чорна скринька», а комплект, за яким модуль імпорту можна розвивати, передавати іншій команді та підтримувати без нас. Усе, що ми проєктуємо під час робіт, фіксується в артефактах — від конфігурацій до інструкцій для ваших співробітників.
- Модуль імпорту в кодовій базі — ізольований компонент із точками розширення: додавання нового формату або поля не потребує переписування логіки розбору.
- Схеми мапінгу — опис відповідності колонок файлу та полів застосунку, включно з правилами приведення типів, значеннями за замовчуванням і обробкою необов'язкових стовпців.
- Правила валідації — перелік перевірок на рівні рядка та файлу: обов'язкові поля, діапазони, дублікати, биті кодування. Із зазначенням, яка помилка блокує імпорт, а яка лише позначає запис.
- Документація імпорту — як влаштований розбір, де зберігаються проміжні дані, як читати журнал помилок і за якими ознаками відрізняти збій формату від збою даних.
- Інструкція користувача — покроковий сценарій для співробітника: який файл підготувати, які обмеження за обсягом і структурою, що робити при частково успішному імпорті.
- Регламент оновлення — порядок дій при зміні структури файлу або полів застосунку: хто править схему мапінгу, як перевіряється сумісність зі старими вивантаженнями.
- Набір тестових даних — еталонні файли з коректними та навмисно пошкодженими рядками, щоб регресія ловилася до виходу в прод.
Окремо передаємо журнал рішень: чому обрано таку стратегію розбору, які обмеження за розміром файлу і чому, де вузькі місця при зростанні обсягів. Це знімає головну проблему підтримки — коли через пів року ніхто не пам'ятає, чому правило валідації сформульовано саме так.
Комплект розрахований на те, що далі ви працюєте самостійно або з будь-якою іншою командою. Якщо знадобиться розширення — обговоримо задачу і повернемося з оцінкою та планом.
Кейс: прискорили імпорт прайс-листів у мобільному застосунку
Замовник — дистриб'ютор будівельних матеріалів — прийшов із класичним болем: менеджери вивантажували прайс із облікової системи в CSV на 40-60 тисяч рядків і завантажували його в мобільний застосунок прямо «в полі».
Імпорт ішов порядковим розбором на пристрої, без попередньої перевірки, і на середньому смартфоні займав 6-8 хвилин. Застосунок підвисав, частина сесій обривалася за таймаутом, а якщо у файлі траплялася зайва кома в назві товару, розбір мовчки ламався на середині.
Ми розібрали вузьке місце: клієнт парсив файл повністю в пам'ять і синхронно писав кожен рядок у локальну базу.
Переписали конвеєр — потоковий розбір CSV з пакетним записом транзакціями по 500 рядків, попередня валідація схеми й типів на перших рядках, а важкі файли йдуть на серверну обробку з поверненням готового набору.
Помилки тепер збираються у звіт за номерами рядків, і менеджер бачить, що саме не пройшло, замість порожнього екрана.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Час імпорту прайсу на 50 тис. рядків | 6-8 хвилин | 20-40 секунд |
| Частка успішних імпортів з першого разу | ~70% | 98% |
| Звернення до підтримки щодо завантаження | 30-40 на місяць | поодинокі |
Окремо закрили відкат: перед записом створюється знімок поточного каталогу, тому невдалий імпорт не залишає застосунок у напівзламаному стані — менеджер повертається до попередньої версії прайсу однією кнопкою.
Схожий конвеєр ми збирали для сервісу польових заявок на Android: там імпорт Excel-вивантажень скоротився з хвилин до секунд за того самого обсягу даних.
Чим відрізняється імпорт CSV від імпорту Excel на Android?
CSV — це плаский текстовий формат: рядки, розділені переведенням рядка, і колонки, розділені одним символом-роздільником (кома, крапка з комою, табуляція).
Жодної структури крім порядку колонок у ньому немає, тому парсинг на Android зводиться до коректного розбору роздільників, лапок і екранування: значення з комою всередині обов'язково має бути в лапках, інакше рядок «розвалиться» на зайві колонки.
Окремий головний біль — кодування: файли зі старих вивантажень приходять в однобайтових кодуваннях, і без явного визначення заголовок і кирилиця перетворюються на сміття. Ми визначаємо кодування за першими байтами і підстраховуємося ручним вибором, якщо автоматика не впевнена.
Excel — це вже не текст, а контейнер: книга, аркуші, типи комірок, формули, об'єднані комірки, стилі. Значення комірки може бути обчислюваним, і при читанні потрібно вирішити — брати збережений результат формули чи перераховувати.
Об'єднані комірки ламають табличну сітку: значення зберігається лише в лівій верхній комірці, а решта порожні, і при розборі це виглядає як пропуски даних. Парсер зобов'язаний «протягнути» значення на весь діапазон об'єднання, інакше рядки поїдуть. Плюс кілька аркушів і приховані рядки — потрібно заздалегідь домовитися, що саме вважається даними.
Практичний висновок: CSV дешевший і передбачуваніший у розборі, але бідний на структуру й типи — все приходить рядками, і приведення до чисел і дат лягає на застосунок. Excel багатший, але вимагає повноцінного читання книги та явних правил щодо формул, об'єднань і аркушів.
Надійне рішення — єдиний шар імпорту, який приводить обидва формати до однієї внутрішньої таблиці, а далі валідує рядки однаково. Так користувач може завантажити і csv, і excel, а логіка перевірки та помилок залишається спільною.
Часті технічні сумніви щодо імпорту даних
Імпорт CSV та Excel у мобільному застосунку майже ніколи не зводиться до «прочитати файл і записати рядки». Основні складнощі починаються на обсязі: файл на десятки тисяч рядків не можна тримати повністю в пам'яті — на слабкому пристрої процес вивантажується системою.
Тому потік читається порядково, буферизується й записується батчами в локальну базу в транзакції, а прогрес показується користувачеві. Так імпорт переживає і згортання застосунку, і нестачу пам'яті.
Окрема тема — нестабільна мережа та дублікати. Синхронізація йде ідемпотентними пакетами з ключем запису: повторне надсилання після обриву не створює копій, а конфлікти вирішуються за правилом «остання зміна перемагає» або за пріоритетом джерела.
Безпека закривається на рівні доступу до файлу, шифрування локального сховища та валідації кожного рядка до запису — биті та чужі дані відсікаються на вході, а не після.
Що буде, якщо користувач закриє застосунок під час імпорту?
Імпорт розбитий на короткі транзакції зі збереженням позиції. При повторному запуску процес продовжується з останнього успішно записаного рядка, а не починається заново — уже завантажені дані не дублюються.
Як застосунок відрізнить дублікат від нового запису?
За складеним ключем: наприклад, зовнішній ідентифікатор плюс джерело. Якщо запис із таким ключем уже є, він оновлюється, а не додається вдруге. Це робить повторний імпорт того самого файлу безпечним.
Файл надходить у неправильному кодуванні або з іншим роздільником — імпорт впаде?
Ні. Кодування та роздільник визначаються автоматично, а рядки з невідповідною кількістю колонок потрапляють у звіт про помилки з номером рядка, не перериваючи завантаження решти.
Чи можна обмежити, які дані користувач взагалі може імпортувати?
Так. Права перевіряються до читання файлу, а схема колонок валідується за шаблоном — зайві поля ігноруються, обов'язкові перевіряються на заповненість. Так чужий або пошкоджений файл не потрапить у базу.
Обговоримо ваше завдання щодо імпорту CSV в Android
Імпорт CSV в Android майже ніколи не зводиться до «прочитати файл і розкласти по колонках». Питання починаються з джерела даних: файл надходить з вивантаження 1С, Google Sheets, старої бази або його готує оператор вручну.
Від цього залежить кодування, розділювач, формат дат і те, наскільки брудні дані доведеться чистити на вході.
Щоб повернутися з оцінкою імпорту та планом робіт, а не із загальними словами, нам потрібно зрозуміти устрій вашого сценарію. Опишіть завдання — і ми розберемо його предметно.
Що варто уточнити на старті:
- Звідки береться файл: ручне завантаження користувачем, скачування за посиланням або синхронізація із зовнішньою системою.
- Обсяг і періодичність: разовий імпорт на кілька тисяч рядків або регулярне підкачування великих вивантажень.
- Структура даних: скільки колонок, чи є вкладені довідники, обов'язкові поля, зв'язки між таблицями.
- Що робити з помилковими рядками: відхиляти весь файл, пропускати биті записи або показувати звіт з номерами рядків.
- Куди потрапляють дані: локальна база на пристрої, сервер або хмарне сховище, і чи потрібне зворотне вивантаження.
- Вимоги до доступів: хто з користувачів має право завантажувати та змінювати дані.
Корисно заздалегідь підготувати зразок реального файлу — з тими самими колонками, кодуванням і «брудними» рядками, що й у роботі.
Один такий приклад знімає половину питань і робить оцінку точною: ми бачимо розділювачі, формати дат, дублікати й вирішуємо, де потрібна валідація, а де — нормалізація.
Далі ми повернемося з оцінкою та планом робіт: етапи, терміни, що робимо на стороні застосунку, а що на стороні сервера, і як перевіримо імпорт на ваших даних до релізу. Опишіть завдання у зручному форматі — листування, дзвінок або короткий опис із прикладом файлу.
