Running Tracker App

A running tracker app is a mobile app that records the distance, time, pace, and route of each run on your phone on the spot, and shows each signed-in person only their own records. When a run is finished, today's record is added to the list, and other people's records are not visible to one another.

This example shows one thing. A mobile app uses the exact same backend you would use for a web service. Storing records, taking on members, and showing each person only their own records is no different for the web than it is for an app. So this example, too, walks through the whole process of setting up that backend (the data that stores the records, member login, and the permission to see only your own records) from start to finish, and separately points out the two things that differ because it is mobile: deployment, and the connection that brings the login result back into the app.

What we build

Instead of a clothing shop or a blog, this example is a personal running tracker app. There are three screens.

• Sign-in screen: you sign in with Google.
• Record list: a signed-in person sees the running records they have logged so far, most recent first.
• Add a record: you log the distance, time, pace, route, and date of a run.

The heart of it is "each person sees only their own records." A signed-in person is delivered only the records they logged, and other people's records are not visible. This condition is what makes member login and permissions both necessary later on.

Design the screens first, then connect them

Building this app yourself takes two steps. First make the app screens, then hand the work behind those screens to WEEGLOO.

1. Create the screen designs. The screens above were produced by giving an LLM a prompt like the one below. You give it one line on what kind of app you are making, the list of screens and what each screen holds, and a design direction.

Design the screens for a running tracker app. It is a vertical mobile app.

Screens:

• Sign-in: one line introducing the app and a "Continue with Google" button.
• Record list (home): a summary of total distance and number of runs, a list of running record cards (date, distance, time, pace, route thumbnail), and an add-a-record button.
• Add a record: inputs for date, distance, time, pace, notes, and a route photo, plus save.

Make it clean and active, so figures like distance and pace read at a glance. Follow mobile UI conventions.

The three screens in "What we build" above are the result of this prompt. At this point there is no data and no login yet: it is just the screens.

2. Connect it to WEEGLOO. Connect the agent to WEEGLOO (Connect it) and say this.

Integrate this with WEEGLOO.

Without explaining at length what you are making, the agent looks at these screens and sets up what is needed behind them. This hand-it-all-over flow is the same as Integrate it in one sentence.

What WEEGLOO sets up behind the screens

With the single "integrate this" instruction, the agent looks at the screens and sets up these four things. This is the backend that WEEGLOO takes on behind the screens.

1. A data structure to hold running records (Content Type). It holds items such as distance, time, pace, route, and date.
2. Google login (ServiceLogin). It lets app users sign up and log in by themselves.
3. The "only your own records" permission. It lets a signed-in person read, write, and delete only the records they logged.
4. Delivery of your own records. It sends each signed-in person only their own records as a list.

These four are exactly what you need when you build the same service for the web. How to handle each piece on its own is covered one at a time in Add sign-up and login, Divide permissions, and Store and retrieve data. If you want to attach a route map image or a photo as well, you can add a file (Media).

The resources that were actually created

Below are the resources actually created in this example's Stride Space. This is not a walkthrough of setting each one up; it is a look at what appeared in this app as the result of "integrate this."

The structure that holds running records

The first is the structure that holds running records (Content Type), "Run." The values that go into a single run are split into per-item slots.

There is no separate slot that stores average pace. It is a value you get from distance and time alone, so the app calculates and shows it on the spot (the "auto-calculated" on the add-a-record screen).

Google login

The second is the channel members use to log in with Google (ServiceLogin). In this example the name is set to "Stride," and Google is the only login method turned on. A newly signed-in person gets the "Runner" permission below by default. When login finishes, the result comes back to the app through the intermediate bridge page described in Bring the login result back into the app.

The "only your own records" permission

The third is the permission that members receive (ServiceUserRole), "Runner." The rules are as follows.

Because "read" is bound to "only the ones you created," the list shows each person only their own records. Of the four things mentioned earlier, number 3 (permission) and number 4 (delivery) actually come out of this one rule together. Since the records each member can read are only their own, that is precisely the list delivered to that person.

Records and photos

The fourth is each individual running record (Content) and the route photo (Media). These two are not created ahead of time; each one is created under a member's name when they log a run in the app. Below is one record that was actually logged. The "Run" structure above is filled with values, and a route photo is attached alongside it.

The distance 42.195 is a full marathon. The time is held in seconds (here, a 3 hour 53 minute record) and shown in the app as 3:53:00. The route photo is stored separately as a file (Media), and the record holds only a link pointing to that file. The list and cards in "What we build" are what these records look like once several have piled up.

The two things that differ from the web

Everything up to here is the same as the web. A mobile app uses the same backend as is. Only two things differ because it is mobile.

Deployment: the app market is outside WEEGLOO

A web service can put a finished product on the internet with Web Hosting (Put a site on the internet), but getting a finished mobile app into people's hands (listing it in an app market) happens outside WEEGLOO. What WEEGLOO takes on is the data, members, and permissions behind the app screens.

Bring the login result back into the app

The login feature itself is attached the same way as on the web. What differs from the web is the connection that brings the result back into the app after login finishes. The login result can only come back to a web address, so one extra step is needed: a page that acts as an intermediate bridge and passes that result into the app. This technical step is covered in Auth API.

Seeing that it really is only your own records

This app's core condition, "each person sees only their own records," really holds. Below are the home screens of the same app opened with two different accounts. It is the same app, but the total distance, the number of runs, and the records shown in the list all differ.

One account shows only a single 5km run, and the other shows only two runs, a marathon and a 3km. Their records are not visible to each other. Stride holds all three of these records (see The resources that were actually created), but each member is delivered only the records they logged. This is the result of binding read to "only the ones you created" in The "only your own records" permission above.

What to do next

• Add sign-up and login: covers how to add a login that takes your own members separately.
• Auth API: covers the technical step of bringing the login result back into the app.
• Divide permissions: covers how to set permissions so that members handle only their own things.
• Store and retrieve data: covers how to create a data structure and fill it with content.