Developing a Mobile Application for Task Management
Jira has everything — except it's inconvenient for field workers on mobile: installers, service technicians, builders. They won't open task in browser in the middle of a job site. Need simple app: got task → did it → confirmed with photo.
Push Notifications as Workflow Foundation
Task assigned → worker gets push with details. Deadline in 2 hours → reminder. Task overdue → notification to manager. Task completed → notification to customer or assigner.
This is basic event-driven workflow, implemented via FCM with priority: high for assignments and overages. Deadline reminders — server scheduler Bull Queue.
Important for B2B apps: employee might have app store blocked or uses corporate Android (AOSP without Google Services). Then FCM doesn't work. Solution — support Huawei Push Kit (hms_push_kit) and WebSocket fallback when app is open, SMS for critical notifications.
Data Model and Task Hierarchy
Task structure depends on domain. Typical for construction or service:
- Project → Stage → Task → Subtasks
- Task has: executor, watchers, priority, deadline, checklist, attachments, comments, location
Task state machine: new → in_progress → review → done | rejected. Transitions — via app actions. Each transition generates event → push to task subscribers.
On backend — event sourcing for tasks: store not just current state but history of all changes. Gives audit log and ability to "rollback" erroneous change.
Completion Confirmation with Media
Worker completed task → need to attach photo as proof. Critical function for construction, cleaning, maintenance.
Photo upload directly from camera: ImagePicker on Flutter, compress via flutter_image_compress to 1–2 MB (full size unnecessary for proof), multipart upload to S3.
Geo-tag mandatory — worker must physically be at job site. Server-side check: distanceBetween(taskLocation, photoLocation) < 500m. If distance larger — warning but don't block (sometimes objective reasons).
Video up to 60 seconds — for technically complex tasks. Upload via resumable upload (AWS S3 Multipart Upload) — mobile network can interrupt.
Offline Mode
Field workers often work in poor internet zones: construction sites, industrial facilities, basements. App must work offline.
Strategy: Hive (Flutter) or Room (Android native) for local storage. Network loss — all actions (status change, comments, photos) written to local queue. Connection restored — sync via background worker (WorkManager on Android, BGProcessingTask on iOS).
Sync conflicts: if manager changed task while worker was offline — LWW (Last Write Wins) by timestamp. For critical fields (status) — server merge with both sides notified.
Analytics and Reporting
Manager sees dashboard: tasks by status, overdue percentage, worker load, average completion time by type. On Flutter — fl_chart for charts.
Export reports to Excel/PDF — generated on server (library exceljs or puppeteer for PDF), link sent via push: "April report ready, download".
Development Timeline
| Scale | Features | Timeline |
|---|---|---|
| MVP | Tasks, statuses, push | 6–8 weeks |
| Standard | + Media proofs, offline, analytics | 12–16 weeks |
| Enterprise | + 1C integration, corporate SSO, MDM | 20–26 weeks |
Cost calculated individually after detailed requirements.