Personalizing Mobile Web Applications

Designing a Mobile Web App that Learns Your Preferences

When a user opens a mobile web app, the first thing that matters is how quickly the app feels familiar. If the device displays data that the visitor already cares about, the experience feels natural and the need to type becomes a memory. This is the heart of personalization: storing a user’s chosen settings and loading them automatically whenever the session starts. A simple yet powerful example is a stock‑quote page that remembers which tickers a visitor wants to see.

Because mobile screens are small and keyboard input is awkward, reducing the amount of data that must be typed on the device is a huge win. Instead of asking the user to enter a list of symbols each time, the app can keep that list in a secure data store and fetch it when the login succeeds. The result is a faster, less frustrating interaction that keeps users coming back.

In this project the core components are: a lightweight Access database that holds user credentials and their preferred symbols; Forms Authentication that verifies the user’s identity; a login page that validates credentials against the database; a main page that displays the user’s name and the live quotes for the stored tickers; and a small set of controls that let the user update or refresh their list. The entire stack runs inside a classic ASP.NET Mobile Page, making it compatible with older WAP browsers and modern mobile browsers alike.

The database schema is intentionally minimal. A table called tblUser stores the user id and password. For a production site you would hash the password and apply proper access controls, but for demonstration the plain text field keeps the example straightforward. A second table, tblStock, keeps a comma‑separated list of symbols for each user. When the app loads, it reads that list, splits it into individual tickers, and queries Yahoo’s CSV service for the latest price.

To keep the data secure, the connection string points to a local Access file but the same code can be changed to use SQL Server or even an XML file if that fits your environment. The OleDbConnection object opens a session to the database, and two OleDbCommand objects handle the read and update operations. By parameterizing the queries you protect against SQL injection and keep the code clean.

The web.config file is the gateway that turns on Forms Authentication. The loginUrl attribute directs the browser to login.aspx when an unauthenticated user attempts to hit any protected page. The deny users="?" line blocks anonymous access entirely. Once a user submits the login form, the handler checks the supplied credentials against tblUser. If the count of matching rows equals one, the user is redirected back to the page they originally requested.

Because the app is built for mobile devices, it uses the System.Web.UI.MobileControls namespace. The MobilePage base class automatically chooses the best rendering format (WML, HTML, or CHML) based on the user agent. This eliminates the need to write separate pages for each device type.

Beyond the technical setup, the user experience is key. The login screen is a single form with two fields and a button. Once authenticated, the default page greets the user by name and shows a text box populated with the stored comma‑separated list. Underneath that are three controls: one to update the list, one to refresh the quotes, and one to sign out. The layout is simple, but the data flow is robust: each button click triggers a server‑side event that interacts with the database, fetches new quotes, and rebinds the ObjectList control.

When a user updates their list, the code writes the new string back to tblStock and immediately fetches the quotes again. The refresh button just re‑executes the quote retrieval routine with the same stored list. Because all interactions occur on the server, the client never needs to handle any JavaScript, keeping the page lean and fast on even the lowest‑bandwidth networks.

In a production scenario, you would replace the plain text password with a hashed version, use HTTPS to encrypt all traffic, and perhaps cache the Yahoo CSV responses to reduce external calls. Nonetheless, this skeleton demonstrates how Forms Authentication, a simple database, and mobile controls combine to give users a personalized, frictionless experience on their devices.

Implementing User Preference Storage and Dynamic Quote Retrieval

With the authentication layer and database tables in place, the next step is to connect the user’s data to the visual elements of the app. The main page - named default.aspx - contains several key controls: a label for the user name, a text box that holds the symbol list, a command button to update the list, another to refresh the quotes, an ObjectList that displays the results, and a sign‑out button. All controls are part of the MobileControls library, ensuring consistent rendering across devices.

The page’s code‑behind begins by creating a connection to the database. A single connection string points to the Access file, and two command objects are prepared: one for reading the symbol list, another for updating it. The connection and commands are kept at class level so they can be reused across event handlers without re‑instantiating them each time.

During the Page_Load event, the code first checks whether the request is a postback. On the initial load, it retrieves the authenticated user’s name via Context.User.Identity.Name and assigns it to the label. It then calls GetSymbolsForUser(), a helper that runs a parameterized query against tblStock to fetch the comma‑separated string. The returned string is displayed in the text box, giving the user a clear view of what will be queried next.

The heart of the dynamic quote retrieval lies in FillQuotes. This method takes the comma‑separated string, splits it into an array, and loops through each ticker. For each symbol it constructs a URL that points to Yahoo’s CSV feed, sends an HTTP request, and reads the first line of the response. The line is split again on commas to isolate the price. All data is stored in a DataTable with two columns: StkSymbol and StkPrice. Once the table is fully populated, it is bound to the ObjectList control, which automatically renders a table for the mobile device.

Updating the user’s preferences is straightforward. When the update button is clicked, the Command2_Click event runs. It takes the current text from the box, sets it as the first parameter of the update command, and uses the user’s name as the second parameter. The command executes against the database, persisting the new list. After the update, FillQuotes is called again to display the latest quotes for the new symbols.

Refreshing the quotes without changing the list is equally easy. The refresh button triggers Command3_Click, which simply calls FillQuotes with the current list. Because the list comes from the text box, any changes the user made are automatically reflected.

The sign‑out flow is handled by Command1_Click. It calls MobileFormsAuthentication.SignOut() to clear the authentication cookie and then redirects the user to the login page. From the user’s perspective, a single tap brings them back to the initial screen, ready for another session.

All of this logic is wrapped in a small set of reusable methods, making the code easy to read and maintain. The use of parameterized queries protects against injection, and the separation of concerns - data access, business logic, UI binding - keeps the code modular. If you decide to move to SQL Server, only the connection string and a few command text changes are needed; the rest of the flow remains identical.

Because the application uses server‑side processing for every interaction, the mobile device never needs to run any heavy JavaScript or maintain a complex client‑side state. This design is ideal for older WAP browsers or environments where bandwidth is at a premium. At the same time, the app feels responsive: as soon as the user hits “Refresh,” the latest quote appears, and any changes to the list are reflected immediately.

In practice, you might extend this pattern to other types of user preferences: news feeds, weather alerts, or custom dashboards. The core idea - authenticate, store a minimal set of user‑specific data, and retrieve it on demand - remains the same. By applying this model, you give each visitor a tailored experience that feels intuitive from the first touch, reducing friction and boosting engagement on mobile web applications.