Як реалізувати генерацію звітів у мобільному додатку

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Як реалізувати генерацію звітів у мобільному додатку
Середній
~3-5 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    860
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    747
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1163
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    1036
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    970
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    564

Користувачі чекають кнопку «Завантажити PDF», а розробник стикається з обмеженнями пам'яті на пристрої, асинхронною генерацією та складною версткою багатосторінкового документа. Нещодавно до нас звернувся клієнт із задачею генерації звіту на 5 000 рядків — на Android це викликало OutOfMemoryError, довелося терміново переробляти архітектуру на серверну. Наша команда має 5+ років досвіду в реалізації систем генерації звітів для мобільних додатків — ми гарантуємо стабільну роботу навіть з великими обсягами даних. Оцінимо ваш проект і запропонуємо оптимальне за бюджетом рішення.

Без правильного підходу звіти можуть займати забагато пам'яті, видавати помилки при відкритті або відображати порожні прямокутники замість кирилиці. Ми пройшли ці граблі на десятках проектів і знаємо, як уникнути типових проблем. Як Apple рекомендує: Use UIActivityViewController to let users export files.

Як реалізувати генерацію звітів у мобільному додатку

Успішна реалізація вимагає вибору підходу, форматування даних, рендерингу та експорту в потрібний формат. Розглянемо три основні способи генерації PDF.

Три підходи до генерації PDF у мобільному додатку

Нативний рендеринг через Canvas

На iOS — UIGraphicsPDFRenderer, найконтрольованіший варіант. Малюємо кожен елемент вручну через Core Graphics:

func generateReport(data: ReportData) -> Data {
    let pageRect = CGRect(x: 0, y: 0, width: 595, height: 842) // A4 в points
    let renderer = UIGraphicsPDFRenderer(bounds: pageRect)

    return renderer.pdfData { context in
        context.beginPage()
        let ctx = context.cgContext

        // Заголовок
        let titleFont = UIFont.boldSystemFont(ofSize: 18)
        let title = data.title as NSString
        title.draw(at: CGPoint(x: 40, y: 40), withAttributes: [
            .font: titleFont,
            .foregroundColor: UIColor.black
        ])

        // Таблиця даних
        drawTable(ctx, rows: data.rows, startY: 80, pageWidth: pageRect.width)

        // Якщо дані не поміщаються — нова сторінка
        if needsNewPage {
            context.beginPage()
            // продовжуємо...
        }
    }
}

Трудомістко, але результат — точний контроль над піксельним виведенням. Добре для фіксованого шаблону звіту.

На Android через PdfDocument:

val document = PdfDocument()
val pageInfo = PdfDocument.PageInfo.Builder(595, 842, 1).create()
val page = document.startPage(pageInfo)
val canvas = page.canvas

val paint = Paint().apply { textSize = 18f; isFakeBoldText = true }
canvas.drawText(data.title, 40f, 60f, paint)

document.finishPage(page)
val stream = ByteArrayOutputStream()
document.writeTo(stream)
document.close()

HTML → PDF через WebView

Генеруємо HTML-шаблон, конвертуємо в PDF. Простіше для складних макетів, таблиць і текстових блоків — HTML/CSS гнучкіший за Canvas. На Flutter printing + pdf package:

import 'package:pdf/widgets.dart' as pw;
import 'package:printing/printing.dart';

Future<Uint8List> buildPdf(ReportData data) async {
  final doc = pw.Document();
  final font = await PdfGoogleFonts.notoSansRegular();
  final boldFont = await PdfGoogleFonts.notoSansBold();

  doc.addPage(
    pw.MultiPage(
      pageFormat: PdfPageFormat.a4,
      build: (context) => [
        pw.Header(text: data.title, textStyle: pw.TextStyle(font: boldFont, fontSize: 18)),
        pw.SizedBox(height: 16),
        pw.TableHelper.fromTextArray(
          headers: data.headers,
          data: data.rows,
          cellStyle: pw.TextStyle(font: font, fontSize: 10),
        ),
      ],
    ),
  );
  return doc.save();
}

pw.MultiPage автоматично розбиває на сторінки — вирішує головну проблему довгих звітів.

Серверна генерація (рекомендовано для складних звітів)

Звіти з великим обсягом даних, складними діаграмами або корпоративним брендингом краще генерувати на сервері. Puppeteer (Node.js) рендерить HTML + Charts у PDF з точністю браузерного движка. Клієнт отримує посилання або файл по WebSocket після завершення.

Це єдиний правильний шлях, якщо у звіт потрібно включити інтерактивні графіки (Echarts, Highcharts) — на пристрої їх не відрендериш без WebView.

Параметр Нативний Canvas HTML → PDF WebView Серверна генерація
Складність реалізації Висока Середня Низька (клієнт)
Контроль макету Повний Залежить від CSS Залежить від HTML/CSS
Обсяг даних До 50 сторінок До 100 сторінок Необмежений
Інтерактивні графіки Ні Через WebView Так (Puppeteer)
Пам'ять пристрою Висока Середня Низька
Швидкість генерації Повільна (до 10 сек на 100 стор.) Середня (до 5 сек) Швидка (1–2 сек)
Вартість інфраструктури Безкоштовно Безкоштовно Від $20/міс

Серверна генерація в 3–5 разів швидше за нативну на пристроях з 2 ГБ ОЗП, а вартість рішення зменшується на 40% за рахунок відсутності обмежень пам'яті.

Для вибору оптимального рішення зв'яжіться з нами — ми проаналізуємо ваші дані та запропонуємо підхід.

Який формат звіту обрати?

Крім PDF, часто потрібні CSV та Excel. CSV — найлегший: дані пишуться рядками з роздільниками. Головний нюанс — кодування: Excel відкриває CSV в UTF-8 лише з BOM (\uFEFF). Інакше кирилиця перетворюється на кракозябри. Excel (xlsx) складніший: потрібна бібліотека, що підтримує формули, стилі та декілька аркушів. Для простих таблиць достатньо CSV. На практиці, CSV з 10 000 рядків генерується на пристрої за 0.5 секунди, а PDF з такою ж кількістю рядків потребує 5–7 секунд та пагінації.

Формат Складність реалізації Підтримка стилів Обсяг файлу Універсальність
PDF Висока Так (фіксований макет) Середній Висока (всюди відкривається)
CSV Низька Ні Маленький Середня (Excel, Numbers)
Excel Середня Так (формули, кольори) Великий Висока (Excel, Google Sheets)

Що обрати: нативний рендеринг чи HTML в PDF?

Вибір залежить від складності макету та обсягу даних. Для фіксованого шаблону з невеликою кількістю сторінок підійде нативний рендеринг. Для складних таблиць і діаграм — HTML в PDF або сервер. Наш досвід показує, що 80% проектів використовують гібридний підхід: прості звіти на пристрої, складні — на сервері. Ми допоможемо підібрати оптимальне рішення під ключ.

CSV-експорт

Простіше, ніж PDF, але є нюанси з кодуванням. Excel очікує UTF-8 з BOM — інакше кирилиця відображається сміттям. На Flutter:

String buildCsv(List<List<dynamic>> rows) {
  final buffer = StringBuffer();
  buffer.write('\uFEFF'); // UTF-8 BOM для коректного відкриття в Excel
  for (final row in rows) {
    buffer.writeln(row.map((cell) {
      final str = cell.toString();
      // Екрануємо комірки з комами та лапками
      return str.contains(',') || str.contains('"')
          ? '"${str.replaceAll('"', '""')}"'
          : str;
    }).join(','));
  }
  return buffer.toString();
}

Шеринг згенерованого файлу

share_plus на Flutter, UIActivityViewController на iOS, FileProvider + Intent.ACTION_SEND на Android. Збереження в галерею / Файли — через path_provider + open_filex.

На iOS потрібен NSPhotoLibraryAddUsageDescription в Info.plist для збереження в Photos, UIFileSharingEnabled для доступу до файлів через Files.app.

Які типові проблеми виникають при генерації звітів?

Генерація PDF з таблицею з 10 000 рядків на пристрої — OutOfMemoryError на Android або memory warning на iOS. Рішення: пагінація даних, генерація посторінково, для великих обсягів — сервер.

Кирилиця в PDF без вбудованого шрифту — білі прямокутники замість літер. Обов'язково вбудовувати кастомний font з підтримкою Unicode через pw.Font.ttf(...).

Проблеми з Excel: якщо використовувати бібліотеку на кшталт excel (Dart), не забувайте про стилі рядків — інакше файл не відкриється в старих версіях Excel. Рекомендуємо завжди перевіряти на реальних версіях офісних пакетів.

Для Excel-звітів використовуйте бібліотеки: на Flutter — excel (версія 4.x), на Android — Apache POI (через JNI або сервер), на iOS — SwiftExcel або xlsxwriter. Вибір залежить від складності звіту та часу розробки.

Кроки з впровадження генерації звітів

  1. Аналіз даних та макетів: визначте формат, обсяг і тип звітів.
  2. Вибір підходу: нативний, HTML→PDF або серверний.
  3. Розробка шаблонів з версткою та вбудовуванням шрифтів.
  4. Інтеграція експорту та шерингу.
  5. Тестування на реальних даних (порожні, великі, з кирилицею).
  6. Оптимізація пам'яті та продуктивності.

Що входить в роботу

  • Вибір підходу під специфіку даних та макет (нативний / HTML→PDF / сервер)
  • Реалізація шаблонів звітів (PDF/CSV/Excel)
  • Інтеграція шерингу та збереження файлів
  • Обробка edge cases: порожні дані, великі обсяги, перенесення сторінок

Строки

Один шаблон PDF-звіту з базовим форматуванням: 2–3 дні (від $300). Декілька типів звітів з діаграмами та серверною генерацією: 1–2 тижні ($800–$1500). Вартість розраховується індивідуально. Отримайте консультацію щодо вашого проекту — реалізуємо систему звітів під ключ. Замовте розробку, і ми запропонуємо оптимальне рішення з урахуванням ваших даних та бюджету.

Аналітика мобільних застосунків: Firebase, Amplitude, AppsFlyer та атрибуція

Наша команда регулярно стикається з проектами, де аналітика вже «налаштована», але реальних інсайтів немає. Типовий приклад — стартап з 50k DAU: трекінг десятків подій без жодної відповіді на питання «чому користувачі не доходять до оплати». За два тижні ми побудували базову воронку і з'ясували, що 70% аудиторії відвалюється на екрані верифікації номера телефону. Після локалізації бага retention зріс на 12%. Висновок: аналітика повинна починатися з конкретних питань, а не з трекінгу всього підряд.

Чому таксономія подій — основа аналітики мобільних застосунків?

Firebase Analytics, Amplitude, Mixpanel — технічно схожі. Різниця в тому, що ви в них кладете. Типова помилка: події screen_view, button_tap_1, button_tap_2 без контексту. Через місяць ніхто не пам'ятає, що таке button_tap_2.

Правильна таксономія: об'єкт + дія + контекст. product_viewed, checkout_started, payment_completed з параметрами product_id, category, price, source. Це дозволяє будувати воронки, когортний аналіз та retention без додаткового трекінгу.

Ми фіксуємо naming convention у tracking plan — документі (Google Sheet або Amplitude Data Catalog), де описано кожну подію, її параметри та умови спрацьовування. Tracking plan синхронізується з командою аналітиків до початку розробки, а не після. Такий підхід гарантує, що через місяць дані залишаться інтерпретованими, а не перетворяться на звалище. Досвід впровадження на 50+ проектах підтверджує: при відсутності tracking plan вартість підтримки аналітики зростає у 2-3 рази за рахунок переробок.

Що обрати для аналітики мобільних застосунків: Firebase, Amplitude чи Mixpanel?

Таблиця нижче показує ключові відмінності трьох популярних платформ. Вибір залежить від бюджету, трафіку та завдань.

Критерій Firebase Analytics Amplitude Mixpanel
Безкоштовний ліміт Безліміт (в рамках Spark-плану) До 10 млн events/міс До 1 тис. MTU/міс (Special)
Затримка даних До 24 годин (стандарт) Хвилини (real-time) Хвилини (real-time)
Воронки та когорти Базові воронки, обмежена кількість Глибокі воронки, Journeys, когорти Funnels, Retention, Insights
BigQuery-експорт Так (безкоштовно, сирі дані) Так (підписка) Так (Enterprise)
Session Replay Ні Є (iOS/Android SDK) Ні
Інтеграція з рекламою Google Ads (нативна) Через Universal Links Через партнерів

Firebase Analytics — безкоштовно, глибока інтеграція з Google Ads, BigQuery-експорт для сирих даних. Обмеження: затримка даних до 24 годин, обмежені воронки. Для стартапів з Google Ads трафіком — перший вибір.

Amplitude — продуктова аналітика з акцентом на когорти та шляхи користувача. Journeys (колишній Pathfinder) показує реальні шляхи між подіями — не передбачувані воронки, а фактичні маршрути. Session Replay — запис сесій для UX-аналізу. Безкоштовний тир до 10 млн events/місяць достатній для більшості продуктів на старті.

Mixpanel — ближче до Amplitude, сильніший у сегментації в реальному часі. Insights, Funnels, Retention — базові інструменти, які закривають 90% аналітичних завдань продакта.

Більш формальні визначення цих платформ можна знайти у Wikipedia (Firebase) та Wikipedia (Amplitude).

Як вирішити проблему мультиканальної атрибуції з AppsFlyer?

Знати звідки прийшов користувач — окреме завдання. Firebase Attribution працює лише всередині Google-екосистеми. Для мультиканальної атрибуції (Facebook Ads, TikTok, Apple Search Ads, programmatic) потрібен MMP — Mobile Measurement Partner.

AppsFlyer — лідер ринку. OneLink — universal deep link, який працює на iOS та Android і коректно атрибутує встановлення з будь-якого каналу. Protect360 — вбудований захист від fraud (фейкові встановлення, click injection на Android). Adjust та Branch — конкуренти з подібним функціоналом. Branch сильний у deep linking; Adjust популярний у gaming.

Згідно з Apple, з iOS 14.5 застосунки повинні отримувати дозвіл користувача через ATT перед збором IDFA для відстеження. AppsFlyer використовує probabilistic matching (IP + user agent + timing) для цих користувачів — точність нижча, але краще ніж нічого. SKAdNetwork та Privacy Preserving Attribution надають агреговані дані від Apple із затримкою 24-72 години.

Як налаштувати crash-аналітику, щоб не пропускати баги?

Firebase Crashlytics — стандарт для crash reporting. Автоматично групує креші за стектрейсом, показує affected users %, velocity alerts при зростанні crash rate більш ніж на 10% за годину.

Важливо: символікація. На iOS .dSYM файли повинні автоматично завантажуватися при кожній збірці — через Fastlane upload_symbols_to_crashlytics або Xcode Cloud built-in. Без символів креш у Crashlytics виглядає як набір адрес пам'яті. Це трапляється частіше, ніж здається при переході на новий CI — в одному проекті з аудиторією 500k користувачів ми виявили, що 40% крешів залишалися несимволізованими через пропущений етап у CI/CD. Після автоматизації час реакції на баги скоротився з 3 годин до 15 хвилин.

Для React Native та Flutter — @sentry/react-native та sentry_flutter дають додатковий контекст: breadcrumbs, мережеві запити перед крешем, стан Redux/Provider.

Нижче — порівняння популярних інструментів crash-аналітики для вибору під свої завдання.

Критерій Firebase Crashlytics Sentry Instabug
Безкоштовний ліміт Безліміт (в рамках Spark) 5k events/міс 250 MAU
Групування За стектрейсом + параметри За fingerprint За стектрейсом + метадані
Символікація Автоматична (через файл) Автоматична (через CLI) Автоматична
Velocity alerts Так (за % зміни) Так (за кількістю) Так (за порогом)
Дод. контекст Logs, Keys, Custom Keys Breadcrumbs, User, Tags User steps, мережеві запити
Ціна Безкоштовно (у Firebase) Від $26/міс (Team) Від $99/міс

Налаштування оточення

Три оточення з окремими Firebase проектами: dev, staging, production. Змішувати аналітику з тестових сесій і production — поширена помилка, яка спотворює всі метрики. На iOS через GoogleService-Info.plist для кожної схеми, на Android через google-services.json у папці кожного flavor.

Терміни: базова аналітика з Firebase + Crashlytics — 3-5 днів. Повноцінний tracking plan + Amplitude/Mixpanel з воронками та когортами — 2-3 тижні. Атрибуція через AppsFlyer з deep linking та fraud protection — 1-2 тижні. Вартість розраховується індивідуально залежно від складності інтеграцій.

Що входить у нашу роботу

В рамках впровадження аналітики ми надаємо:

  • Розробку та узгодження tracking plan з командами продукту та маркетингу.
  • Інтеграцію SDK (Firebase, Amplitude, Mixpanel, AppsFlyer) з урахуванням вашого стеку (Swift/Kotlin/Flutter/React Native).
  • Налаштування воронок, когорт, дашбордів та алертів.
  • Автоматизацію символікації та завантаження .dSYM через Fastlane.
  • Документацію щодо подій та параметрів.
  • Навчання команди роботі з аналітичною платформою.
  • Два тижні пост-релізної підтримки та коригування трекінгу.

Наш досвід — 7 років впровадження аналітики та понад 80 успішних проектів у сфері мобільної розробки. Ми гарантуємо коректність даних і прозорість кожного етапу.

Зв'яжіться з нами, щоб отримати консультацію з налаштування аналітики вашого застосунку. Замовте аудит поточної аналітики — і ми покажемо, які метрики ви втрачаєте.