# Background

## Types of Sign UP flows

Different apps will have different signup flows. Here are some few examples:

* **Signup > Login > Home screen** : In this flow after signup the user will be redirected back to the login page to log in before using the app.
* **Signup > Home screen** - Here after signup the user is automatically logged in.
* **Signup -> Verify Email > Login > Home screen** - After signup the user will be sent an email with a link to click to verify their email address. After the verification the user will return to the login page to log into the app.
* **Signup -> Verify Phone number > Enter phone code > \[ Login > ] Home screen** : In this flow as part of the signup process the user will enter their phone number which a code will be sent. The user will need to enter the phone code before they can proceed. In this flow after the phone code verification the user may be logged in automatically or will be sent to the login screen.

There may be several variations of this or other different flows. But for the purpose of this tutorial we will look at the first flow whereby after signup the user will be directed back to the login screen to log in.

## Persisting login session&#x20;

When a user logs into your app, you may want to keep them logged in so that even when they close the app or restarts their phone, they can still get into the app without logging in again. Such session may persist for a very long time until the user explicitly logs out, re-install the app or clears the app cache and data.&#x20;

In order to persist such login session you need to be able to store some info on the user's phone that on app launch you can use to determine if the user should be sent straight into the app or to the login screen.

{% hint style="info" %}
The ability to write to local storage is one of the features that currently gives AppGyver an urge of competitive tools. A lot of the no/low-code tools don't have this feature making it hard to persist login sessions. \
\
\&#xNAN;*Note that there are some workarounds to persist login sessions if a tool doesn't support local storage. You can store such information on a server. But its simple and the app launch is faster if you're using local storage.*
{% endhint %}

## Page structure

Below is a screen transition diagram showing the pages and transitions between them.

In this tutorial will have 3 pages, a LOGIN, SIGNUP and HOME pages.&#x20;

The **LOGIN** page will be set as the **Initial view** of the app. This means whenever the app is launched this will be the first page to visit. On this page the will be a button for the user to go to the SIGNUP page if they're a new user. Clicking the back button on the LOGIN page will quite the app.

On the **SIGNUP** page a user can click on a button to go back to the LOGIN page if they already have an account. Clicking the back button will also return the user the to LOGIN page.&#x20;

A user will be directed to the **HOME** page if they're already logged in or after logging in from the LOGIN page.

![](https://1990900596-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAt7rtTFHf56GLwoUyJ%2F-MB-uw--iJ_QqGLN7xgm%2F-MB0QuVq1iZr257ZW44z%2Fimage.png?alt=media\&token=a4e5a3d8-58af-40ab-a0bd-e754ac662e54)

## Data structures

The app will have the follow data structures

#### Storage

* **`persistedUser`** - This will be an object with the fields `token`(text), `id` (text) and `expires`,(number) to match the login endpoint created in bubble. Whenever a log in is successful the app will store the corresponding response values into this object on the device.

#### App Variables

* **`authUser`** - An object with the fields `token`, `id`, `expires`. This will just be a copy of the **`persistedUser`** device variable. This variable is used so that instead of always going to the device storage to retrieve the token and user id we can simply reference this object.&#x20;
* **`currentUser`** - This is an object that stores the retrieved User from our backend database. In this tutorial we only have the fields `email` and `name` plus the `id` retrieved during the log in.

#### Page Variables

* LOGIN page - `email` and `password`, bound to the input fields.
* SIGNUP page - `name`, `email` and `password`, bound to the input fields&#x20;

## Create App Variables

We can now create our app variables like below. Go to any page in your app and click on VARIABLES. Under the APP VARIABLES create to objects variables, `authUser` and `currentUser` as shown below.

![](https://1990900596-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAt7rtTFHf56GLwoUyJ%2F-MB5gK2JhFCxpBWQU3gW%2F-MB5j8f4AXz_PZwgHBkx%2Fimage.png?alt=media\&token=b8058826-4e92-450c-a159-a4c23011e59a)

## Flow Functions

Install the following flow functions which we will need for the app logic

![](https://1990900596-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAt7rtTFHf56GLwoUyJ%2F-MB5jjJO2UsUL7L7lGxx%2F-MB5nZfnkqr4Yr8gEN36%2Fimage.png?alt=media\&token=77a5b494-a3d5-4d20-9b6a-c9d04c9fdb0d)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://seanhoots22.gitbook.io/tutorials/appgyver-3rd-party-authentication-with-bubble/setup-appgyver/untitled.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
