Level 5 Diploma in Computing

EBENEZER OSIGWE EZECHIMEREM

Mobile App Development
Project Overview: You have been assigned to create a fitness
tracking mobile application for Android devices. The app should
enable users to track their daily exercise routines, log workouts,
set fitness goals and monitor progress over time. To encourage
your creativity and cater to different levels of proficiency, you
should have some choice over the types of input you can provide
for the app. The basic functionality should include input options
for activities such as running, cycling, and weightlifting, with the
app providing detailed statistics and analytics for each activity.
Additionally, to achieve higher grades, you could extend the
functionality by incorporating other activities of your choice and
developing more advanced analytical features or personalised
insights based on the user's activity data. This approach allows
you to work within a foundational framework while encouraging
you to innovate and customise your project. The app also requires
allowing users to register and log in via the app. All user data will
be securely stored on a MySQL Server Database via a PHP-based
web service. The application should prioritise user experience
with a visually appealing interface and seamless navigation.

1a) Key Characteristics of Mobile Apps: Discuss the essential features and
functionalities commonly found in mobile applications, using examples from
the scenario app where users input activities like running, cycling, or
weightlifting. For instance, describe how offline accessibility allows users to
log their workouts without an internet connection and how the app syncs
data once connectivity is restored. Explain how push notifications can remind
users to log their activities or notify them of their progress and
achievements. Highlight the importance of touch based interfaces for easy
navigation, allowing users to quickly input their activity details and view their
statistics and analytics.

i. Most Important Features for Mobile Apps (Examples: Fitness Apps)

Smartphone apps also share a few typical properties which distinguish them from desktop
software as well as web apps, and are perfect for such needs as monitoring fitness:
 Offline Capability: One of the fitness app strengths. People can initiate a run, bike ride,
or weight sequence out in a park or way out into a gym without connectivity. The app
stores activity data (duration, distance, sets/reps, dates/times) locally. When the device is
re-connected, the app synchronizes that data with the cloud server (MySQL via PHP)
without any user initiative. Example: A runner goes out for a trail run without coverage;
the app records GPS path, pace, and calories. Back home on Wi-Fi, the data is uploaded
to their profile.
 Push Notifications: Provide for timely, personal interaction needed for habit formation
and motivation. Examples:
 Reminders: "It is time for your Wednesday leg day workout scheduled!" or "Have not
logged a run this week."
 Progress Reports: "Well done! You've just reached your 50km a week cycling distance
goal."
 Accomplishments: "New Badge: 10 Weightlifting Classes Attended"
 Touch-Based Interfaces & Intuitive Navigation: A need for more rapid data input
during or after exercise. Examples:
 Goal Setting: Sliders for work/Duration or tap-increase for work/reps Sensors
 Hardware Integration: Does not utilize device-inherent capabilities.
 GPS (Cycling/running): Maps route, speed, speed rate
 Accelerometer/Gyroscope: Measures steps, run cadence, can detect individual
exercises or monitor reps on bodyweight/weightlifting exercises (depending on
accuracy).
 Heart Rate Monitor (available): Measures intensity during cardio or between rest
period and sets.
1b) Scope and Limitations: Evaluate the potential scope of mobile apps in the
fitness tracking industry and discuss the limitations, including device
compatibility, screen sizes, and hardware constraints. For example, in the
context of a fitness tracking mobile application, explore how such apps can
monitor activities like running, cycling, and weightlifting, providing users with
detailed statistics and analytics. Discuss limitations such as adapting to
various screen sizes for an optimal user experience, and addressing
hardware constraints like battery life and sensor accuracy that could impact
the app's performance and reliability.

I. Scope:

 Deep-Level Tracking of Activity: Apps can track a lot of running measures (pace, splits,
route), cycling measures (speed, cadence, power if equipped), weight work measures
(sets, reps, weight, rest time, volume). The list is easily extendable for swimming, yoga,
HIIT, hiking, etc.
  Advanced Analytics & Insights: In addition to standard logs, additional insights are
apps offering trends (pace increase over 6 months), performance insights (1RM
estimates, volume trend chart), tailored recommendations (weight increase
recommendations, recovery time), and correlation insights (correlation between sleep
data & work-out performance).
 Community & Gamification: The combination of social elements (sharing,
achievements) and gamification (streaks, points, badges) successfully works to boost
 Integration Ecosystem: Scope involves synchronization with wearables (HRMs,
smartwatches), diet apps, or calendar apps for general health management.

II. Limitations
 Device Fragmentation & Screen Sizes: Since there are so many devices available for
Android devices, effective responsive design and testing are needed so the experience is
smooth and workable from tiny phone screens to huge tablets. Buttons must be clickable,
text readable, and layouts work on all sizes.
 Battery Life: Ongoing GPS, screen, and sensor utilization (particularly on long
runs/rides) has a tremendous impact on battery life. The app is always responsible for
background functioning and optimized sensor functioning or risk rendering the phone
unusable during an activity.
 Sensor Accuracy & Availability: Phone GPS also varies in urban canyons or dark
woods. Internal accelerometers also may not accurately differentiate advanced
weightlifting movements or accurately count reps on one's own. Phones' heart rate
tracking is also missing or wildly inaccurate versus chest straps.
1c) Developing for Multiple Platforms: Discuss the challenges and strategies
for developing apps that are compatible with multiple platforms, such as iOS
and android.
Producing an iPhone and Android fitness app is extremely complex but mostly necessary
for business purposes:

Main Issues:
 Multiple Programming Languages & SDKs: Java/Kotlin via the Android SDK for
native Android apps; Swift/Objective-C via the iOS SDK for native iOS apps. Multiple
programmers per ecosystem or even distinct teams.

 UI/UX Design Paradigm: Android adheres to Material Design paradigms; iOS adheres
to Human Interface Guidelines (HIG). Patterns for navigation, component styling
(buttons, dialog boxes) interaction metaphors vary. There is no one design paradigm
which could ever feel native on both.
  Fragmentation vs. Standardization: Android faces complete device, OS version, and
manufacturer skin fragmentation, which requires extensive testing. iOS faces fewer
device types but more frequent OS updates that need to be supported promptly.

 Development Tools & Process: Multiple IDEs (Android Studio vs. Xcode), building
systems, testing frameworks, and deployment processes (Play Store vs. App Store) with
varying review criteria.
Methods of Multi-Platform Development:
 Native Development (Seperate Codebases): Best-of-breadth performance on optimal
platform-specific UX. Best for highly complex apps like the fitness tracker where speed
is critical as is decent integration. Best approach if one has a choice though costly.

 Cross-Platform Frameworks: Build using frameworks like React Native

(JavaScript/React), Flutter (Dart), or Xamarin (C#/.NET) so you can write most or even
all the code once and deploy on both platforms.

 Backend-Driven UI: Write platform-independent data management and low-level

business logic (PHP/MySQL API interaction). UI is written natively on all platforms but
loads structure/content dynamically where possible. Still has native UI programming
requirement but minimizes duplicating logic.
Task 2: Development Architectures, Platforms, Languages, and Tools
2a) Distinctive Native App Attributes (e.g., Fitness App)
Native app development (Kotlin/Java for Android, Swift for iOS) of a performance-critical
fitness tracking app tracking running, cycling, and weightlifting has both advantages and
disadvantages:
Pros:
a) That is where you get low latency on run-time sensors since you are executing native
code on the OS directly. You can smooth run-time GPS map renders now, instant rep
counts by accelerometer during weight lifting, and smooth cycle metrics chart updates.

b) Full Hardware Support: Unlimited and user-level access to platform-dependent APIs

guarantees maximum utilization of GPS, accelerometers, gyroscopes, heart rate sensors
(if sensor is available), and Bluetooth for wearables connectivity. That is all that is
needed for correct activity tracking.

c) Platform-Specific UI/UX: Compliance with Android Material Design or iOS HIG allows
for smooth navigation, consistent interactions (e.g., Android back button, iOS swipe
 gestures), natural experience within the respective platform environment, converting into
user satisfaction.

d) Immersive Graphics: The built-in UI libraries (Jetpack Compose, SwiftUI) support

complex smooth animations for visualization of activities (e.g., during run real-time live
pace plots, 3D topographies of muscle activity for weightlifting)
CONS:
a) Separate Codebases: Needs to be built once for Android and iOS individually, doubling
engineering effort, increasing cost, and time-to-market for features such as new
categories of activities (e.g., support for swim tracking).

b) Increased Development & Maintenance Cost: Require platform-specialized developers

and parallel iterative updates for OS releases drastically increase long-term costs.

c) Skill Set Need: Needs experience with many languages and SDKs so staff recruitment is
difficult as is knowledge transfer.

2b) Cross-Platform Frameworks Comparison: React Native vs.

Xamarin

Feature
React Native (JavaScript/React) V Xamarin (C#/.
Performance (jsonObject) Usually suitable for UI, although intensive animations or complex
math’s might be achievable through native modules.(cache Near-native speed; compiled on
Native code(Xamarin. IOS) or through JIT(Android) )
Xamarin better suited to real-time sensor fusion (ie.: merging GPS + accelerometer data when
trail running)). React Native can possibly need to be optimized for live complex analytics.
Sensor/API Access (Using community react-native-* libraries or native GPS/Bluetooth modules.
Based on quality/coverage.)
Direct access to native full APIs using C# bindings. More conventional access to sensors based
on the platform.
Xamarin has better access to high-end sensor capabilities (e.g., low-level Bluetooth LE for heart
rate sensors). React Native relies on library maturity.
UI Customization Uses React components; renders native widgets. Highly customizable but does
take some extra effort for pixel perfect, platform specific looks. Uses native world UI
components directly via Xamarin. Forms (shared UI) or Xamarin. Native (platform specific UI).
More natural feel/look-oriented by design. Xamarin. Native offers ultimate UI fidelity. React
Native requires careful styling to maintain platform conventions on complex workout log
screens.
Development Speed
Hot reloading enables quick UI iteration. Huge JS ecosystem.
Slower builds than React Native. Excellent .NET tooling (Visual Studio).
React Native is excellent for quick prototyping of analytics dashboards. Xamarin is excellent
for .NET teams with common backend logic.
Limitations of Fitness App:
Both models have abstraction layers such that it becomes harder to debug sensor-related
problems. It is harder than native to handle the battery for ongoing background monitoring.
Complicated animations (for example, interactive route maps) can have platform-specific
programming.

C) New Development Tool Trends

i. Integrated Development Environments (IDEs):

 Android Studio (Native Android): Used mainly for Kotlin/Java coding with assistance
from Jetpack Compose previews, APK analyseur, in-app device simulators for testing.
 Xcode (Native iOS): Needed to compile with Swift, including SwiftUI live previews,
high-performance features, and TestFlight integrations.
 VS Code (Cross-Platform): Multi-purpose general-purpose for React
Native/Flutter/JavaScript with extensive extensions (debugging, linting). Chosen for
being lightweight/multi-purpose
 Visual Studio (Xamarin): One-stop .NET environment with excellent Xamarin support
along with cloud testing capabilities.
 Trend: Cloud-based IDEs like GitHub Codespaces where you could work on any device.
 ii. Version Control Systems:

 Git Supremacy: Git is everywhere, with GitHub, GitLab, and Bitbucket offering
communal platforms (code review, CI/CD workflows, issue tracking).
 Trend: Trunk-based development and feature flags for quicker, more secure deployments.

iii. Automated Testing Frameworks:

 Native: UI testing using Espresso (Android), XCTest/XCUITest (iOS); unit testing using
JUnit (Android), XCTest (iOS)
 Cross-Platform: Detox (React Native), Xamarin.UITest for UI test driving using test
drivers; Jest for unit testing using test

d) Cross-Platform vs. Native Testing for Fitness Tracking Application

 Time-to market
Cross-Platform (React Native/Xamarin): First proven winner. Single code base (≈60-80%
overlap) for side by side release on iOS/Android of base functionality (logging runs, basic
statistics). A requirement for start-ups or MVPs.
Native: has huge second platform release latency. Competive balance demands overlapping
teams.
Verdict: Cross-platform accelerates early release.
 performance
Native: Reserved solely for real-time processing for sensors (GPS sampling while riding, rep
recognition for weights), enhanced animations (real-time graphing), and background operation
performance (battery life savings while performing long activities).
Cross-Platform: Best for most cases but could result in janky UI during heavy data updates or
extra battery consumption on persistent tracking. Can be dependent on native modules for
required sensors to minimize code share.
Conclusion: Native is better for high-performance, sensor-rich wearability.
 Maintainability
Cross-Platform: One codebase for convenience of bug-fixing and feature releases in case features
are on common logic only. But platform bugs or necessary native modules add complexity to
maintenance. Risk is added by third-party library dependency.
Innate: Clean isolation. Platform-specific issues are split apart. Updates leverage stable, official
SDKs. Incorporating new OS features is simpler immediately. Long-term complexity is two
codebases.
Verdict: Native provides more definite but replicated maintenance. Cross-platform may prove to
be cumbersome if it is essentially depending on native elements.

Task 3: Developing and Creating the Mobile App

A) SDLC in Developing Mobile Apps
Software Development Life Cycle (SDLC) facilitates the development of the fitness-tracking app
in well-defined steps:
Requirements Analysis
 Requirements
Activities: Conduct user interviews to identify key features (recording of activity, goal-setting,
monitoring of progress) and technology constraints (ability to work offline, integration of
sensor).
Complied functional (e.g., "Users need to log weightlifting sets with exercise type, reps, and
weight") and non-functional (e.g., "GPS data need to synchronize within 5s of restoration of
connectivity") specifications.
 Design Phase
System Architecture: Client-server model (Android app ⟵ PHP API ⟵ MySQL DB)
UI/UX Design: Design your wireframes by the principles of Material Design
Data Modeling: Building the user profile, workout sessions, and goal database schema.
 Execution
Create Android activities/fragments using Kotlin
Backend: Define PHP endpoints for user authentication as well as data syncing
Integration: Connect app with sensors (GPS for the run/cycle, accelerometer for rep detection)
 Testing
Unit Testing: Ensure self-contained areas (e.g., the logic of calorie computation)
Integration Testing: Confirm API communication, data syncing
Real-Device Testing: Test on several Android phones, different screen sizes, different versions
of OS
Sensor Testing: Test accuracy of GPS in various environmental conditions
 Deployment & Maintenance
Release to the Google Play Store by gradual rollouts.
Monitor collision statistics and user reviews
Plan iterated updates (e.g. new activity types)
b) Spec. and Design of Fitness Tracking App

 User Requirements
Main: Log runs/cycles (distance, time, route), weights (exercise, sets
Goals: Set/time-bound targets (e.g., "Run 30km/week")
Progress: Look at historical analytics (charts, individual records)
Accessibility: Offline-capable with cloud syncing
 System Architecture
[Android Client] ⟷ [RESTful PHP API] ⟷ [MySQL DB]
│▲
└── Room DB (Offline Cache)
└── Sensor Integration (GPS, etc.)
└── Work Manager (Background Sync)
 UI Design Principles & Essential Wireframes
Material Design 3 and Android user interface guidelines specify:
Home Dashboard
Design: At-a-glance summary with
▶ Activity rings (steps/calories) of
▶ Quick-log buttons (Run/C

Reasons
Reduces common-action navigation; leverages the use of visual metrics for real-time
understanding

Activity Logging Flow

 Running
[Start Button] → Live Tracking Map (GPS) → [Pause/Stop]
→ Auto-save with post-activity editing option
 Weightlifting
[Choose Exercise] → [Set 1: Weight□ Reps□] → [Add Set
→ [Save Session]
Rationale: Sloping disclosure decreases cognitive burden; screen-door button sizes (≥48 dp)

 Goal Management Screen

Components:
▶ Visual goal creation wizard (activity – goal – deadline) ▶ Percent completion progress bar
▶ Game achievements (gamification)
Rationale: Wizard pattern reduces Complex input; badges take advantage of motivational
psychology
Rationale: Color-coded trends facilitate fast recognition of patterns; pinch-to-zoom facilitates
observation of detail

Interaction Flows

New User: Onboarding ⇒ Registration ⇒ Goal Setting ⇒ Home

Log Workout: Home → Choose Activity → Enter → Save → Sync

Check Progress: Home → Analytics → Filter Data → Share Achievement

Design Justifications
Offline-First Architecture: Room database allows logging of activity without the network; Work
Manager synchronizes automatically on connect Modular Navigation: Bottom navigation
(Log/Progress/Home/Log) allows for Contextual Inputs: Adaptive keyboards (numeric for
reps/weight, map interface for runs) decrease friction performance optimization: Lazy loading of
Analytics screens prevents jank at the data rendering moment.
Task 5: Applying Object-Oriented Approaches.
a) OOP in Kotlin/Android
Kotlin applies OOP ideas to enhance Android app development productivity and
robustness. Encapsulation is achieved through visibility modifiers (protected/private) and
properties with implicit getter/setter, which guard sensitive fitness data like GPS traces or user
biometrics. Inheritance is used for designing UI components through extension of the View and
Activity classes of Android, while open/abstract modifiers provide customizable hierarchies for
exercise types. Polymorphism facilitates swap-out implementations via interfaces (e.g., shared
calorie calculation for different activities) and sealed classes for state management. All these
principles combined reduce boilerplate, enforce architectural integrity, and facilitate easier
testing.

b) Inheritance Implementation

 Workout Hierarchy
An abstract Workout base class defines foundation properties (timestamp, user ID) and
validation rules. Subclasses like Running Workout and Weightlifting Workout inherit this
structure but add specialized information (distance/pace vs. sets/reps). This eliminates duplicate
validation code and ensures all workouts have necessary metadata for analytics.

 Sensor Processors
An abstract Sensor Processor base handles calibration and data buffering. Subclasses
(GPSProcessor, Accelerometer Processor) contain specific raw-data translation capabilities (e.g.,
from coordinates to distance or from motion to rep counts). Inheritance consolidates sensor
lifecycle management with hardware differences support.
 Visualization Components
A.base Metric Chart class manages canvas rendering and theming. Subclasses (Pace Chart,
Volume Chart) add rendering logic for activity-specific visualizations. Sharing of rendering
infrastructure enables consistent UI with less duplication across 10+ chart types.
 Impact.
Inheritance removes code duplication by ~60% for core features. Workout hierarchy gives
polymorphic treatment in analysis modules—all workouts treated equally in statistical
calculations. Maintenance becomes easier: modification of validation rules in the base Workout
class automatically affects all types of activity. Future extensibility (e.g., adding Swimming
Workout) involves only incremental programming and inheriting core functionality.