Member Avatar for toomutch

Am interested in developing a mobile app for work - want to send our engineers some job details to the calendar on their mobile device, then have them 'tick a box' when it is complete and log an entry back to the server in the office.
I've been doing some tinkering with my own android device, just to see what I need to learn, but before I get too far, are there any benefits to developing for Andriod over Blackberry or an Apple device?

I need to consider
a) cost (as far as I can see Andriod is free to publish apps, but need to pay to publish for BB?)
b) ease of distribution (can I just send the guys a weblink, or does it need to be published to an app store)
c) ease of programming (haven't done anything like this before, so steep learning curve expected whichever I choose)

I have been programming (mainly for pleasure) for 30+ years and have been taught Basic and Cobol, and then have self taught VB6 / VB.Net, SQL, Linux, Unix and a bit of C++ and have also tinkered with Arduino (makes it sound really geeky when I list it all like that!).

Any advice gratefully received
Toomutch

  • 3 Contributors
  • 2 Replies
  • 284 Views
  • 2 Months Discussion Span
  • Latest Post Latest Post by Thomos859

Dani AI

Generated

As described, the requirement is: dispatch job details to an engineer’s device, surface them in a calendar-like way, allow a simple “tick” to mark completion, and log that back to a central server. The high‑level choice is between native per‑platform apps, a cross‑platform/hybrid app, or a web/PWA. Each path has strengths and tradeoffs for calendar access, offline logging and distribution.

Native (iOS/Android/etc.) gives the most reliable access to the system calendar, background execution, push notifications and fine‑grained permissions — but it means learning the platform toolchain and writing platform UI. Cross‑platform/hybrid (React Native, Xamarin/C#, Cordova/Ionic) lets most business logic be shared and uses plugins for calendar and local storage; it shortens time-to-prototype but can require native debugging. PWAs or simple web pages are quickest to distribute via a link, but cannot consistently write to the native calendar or run robust background sync on every device. The Windows Phone route mentioned by makes sense only if that platform is actually used by the field team.

Distribution and cost: native apps are published via vendor stores and require developer accounts/provisioning; internal deployment can use enterprise/MDM or private distribution to avoid public stores. As suggested, centralize dispatch and logging on a small TLS‑protected REST API so devices only need to sync job state. Protect endpoints with simple auth, implement device identifiers, and treat the server as the source of truth.

A practical, low‑risk path:

  1. inventory engineer devices;
  2. prototype the workflow as a hybrid app or responsive web UI that stores tasks locally and syncs to a REST endpoint;
  3. implement calendar integration via a native plugin or, better, keep an in‑app task list for reliable audit trails;
  4. add offline queueing, retries and optional push notifications;
  5. choose public vs private distribution once the workflow is stable.

Note: calendar writes require user permission and can be edited or deleted by users — rely on server logs and timestamps for final auditing rather than the device calendar alone.

Recommended Answers

All 2 Replies

Member Avatar for caperjack
Edited by caperjack
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.