Building a Utility Bill Checker App in Unity – Need Advice on UI, Input Handling & Data Design

Web Resources
, ,
1

I’m working on a small educational app prototype in Unity that lets users enter their electricity reference number (such as IESCO, LESCO, etc.) and view a structured, mock-up utility bill on the screen. The app is intended for learning and UI experimentation, but I want it to feel clean, responsive, and close to a real utility app.

Here’s what I’m trying to figure out:

  1. What’s the best way to validate user input (especially numeric reference numbers) using Unity UI?
  2. How should I structure mock data in Unity — ScriptableObjects or plain JSON?
  3. What are the best UI layout practices for simulating a bill view on small screens?
  4. If I wanted to expand this in the future to fetch real bill data using APIs, what networking best practices would apply?
  5. Should I consider any libraries for better form design or dynamic table output?

This project is inspired by live tools like Iesco bill online that already serve real users — I’m just aiming to create a simplified offline version inside Unity for demo purposes.

Any tips on UX flow, architectural setup, or security considerations (for future API use) would be appreciated. Thanks!

2

For validating numeric reference numbers, you can use InputField or TMP_InputField and restrict input to digits only.

  • Use the onValueChanged event to filter non-numeric characters in real time.
  • Example:
public TMP_InputField refInput;

void Start() {
    refInput.onValueChanged.AddListener(delegate { ValidateInput(); });
}

void ValidateInput() {
    refInput.text = new string(refInput.text.Where(char.IsDigit).ToArray());
}
  • Add a simple check for length (since reference numbers usually have fixed digits, e.g., 14–15).

:white_check_mark: Structuring Mock Data

For a small educational app:

  • JSON is simplest and easiest to tweak without recompiling.
    • Store mock bill records like:
{
  "12345678901234": {
    "name": "John Doe",
    "unit": 350,
    "amount": 4580,
    "dueDate": "2025-11-10"
  }
}
  • If you plan multiple mock bills or dynamic demos, ScriptableObjects are great for clean organization in the Unity Editor.

:right_arrow: Rule of thumb:
Use JSON for data you might later fetch or serialize.
Use ScriptableObjects for static, built-in mock data.

:white_check_mark: UI Layout for Small Screens

  • Use a Vertical Layout Group inside a Scroll View for the bill display.
  • Anchor UI elements properly with Canvas Scaler set to Scale with Screen Size.
  • Test with safe area padding on mobile (for notches, etc.).
  • For the bill table: use Grid Layout Group or manually structured RectTransforms with TextMeshPro for better clarity.
  • Keep color contrast high and group related info visually (like amount, due date, and reference no).

:white_check_mark: Expanding to Real Data (Future API Integration)

If you later connect to real APIs:

  • Use UnityWebRequest (or RestSharp / BestHTTP if you want more robust handling).
  • Keep your API key and endpoints in a secure config file, never hard-coded.
  • Always validate and sanitize input before sending network requests.
  • Implement timeouts and error feedback for users (e.g., “Network issue, please retry”).

:white_check_mark: Libraries & Tools

  • TextMeshPro — for clean, professional text layouts.
  • Lean GUI or Modern UI Pack — for easy, responsive UI components.
  • DOTween — for smooth UI animations and transitions.
  • Newtonsoft.Json — for easy JSON parsing and serialization.

:white_check_mark: UX Flow Tips

  • Keep it linear: Enter Reference → Tap View Bill → Display Bill Screen.
  • Add a subtle “loading” animation when showing mock data to simulate real fetch.
  • Optionally allow users to “save” or “share” their mock bill for realism.

:white_check_mark: Security Considerations (for future real data)

  • Validate all input server-side (not just client-side).
  • Use HTTPS for API communication.
  • Never store sensitive data unencrypted.
  • Consider token-based authentication if you plan user accounts later.
  • am also working on a utility tool based website/](https://suiigasbillonlinecheck.pk/) and trying to improve design by following these steps
3 
Input Validation and Data Structure

For **input validation****, the best approach in Unity UI is to use the **`InputField` component's built-in properties** combined with a simple script. First, set the `Content Type` to **`Integer Number`** to immediately restrict input to digits. Then, set a strict **`Character Limit`** (e.g., 14 or 16 digits, depending on the utility like IESCO online bill check islamabad or LESCO) based on the typical length of reference numbers. You should attach a C# script function to the `OnEndEdit()` event of the `InputField`. This function will perform the final validation check—specifically, ensuring the length is exactly correct and potentially checking if the number matches a known mock range. The "View Bill" button should only be enabled (made **interactable**) when this validation passes.

When it comes to **mock data structure**, a hybrid approach is often the cleanest for Unity. Use **ScriptableObjects (SO)** to define your **Bill Data Model** (e.g., a C# class inheriting from `ScriptableObject` with fields like `ConsumerName`, `BillAmount`, `UnitsConsumed`, etc.). This lets you create and edit mock bills directly within the Unity Editor without touching code. For a large set of mock bills, you can use **JSON** and load the data at runtime, parsing it into your same C# Bill Data Model class. **ScriptableObjects** are generally preferred for small, strongly-typed configuration data in Unity, offering better performance and integration than relying solely on JSON.

##  UI Layout, UX, and Networking

To create a **responsive bill view on small screens**, focus on using Unity's layout components effectively. Your main screen should be based on a **Canvas Scaler** set to **`Scale With Screen Size`** (using a common mobile resolution like $1080 \times 1920$ as a reference). Use a **`Scroll Rect`** as the main container for the bill to ensure all details are visible. Within the scroll view, use a **`Vertical Layout Group`** to stack the main sections (Consumer Info, Summary, Details). For displaying key-value pairs (like "Due Date: **2025-01-01**"), use **`Horizontal Layout Groups`**. Crucially, use **padding** and varying **font sizes/colors** to establish a clear visual hierarchy, making the important details (like the total amount) stand out.

For a smoother **UX flow**, implement a simple state machine: Start with the **Input Screen** (Reference No.) $\rightarrow$ **Validation** (button enables when valid) $\rightarrow$ **Loading State** (a quick spinner) $\rightarrow$ **Bill View**. Using **DOTween** is a highly recommended (and free) library if you want to add smooth animations to make the transitions and error messages feel polished and responsive.

Regarding **future API integration** for real data, the key **networking best practices** are to use **asynchronous operations** (like C#'s `async/await` with `UnityWebRequest` or `HttpClient`) to prevent the application from freezing while waiting for a response. For security, **NEVER hardcode sensitive API keys** directly into your code; use environment variables or a configuration system outside of source control. Always enforce the use of **HTTPS/TLS** for encrypted data transmission.