MAD 1 WEEK 1

Lecture Notes: Apps and Web Development

What is an "App"?

●​ Definition: An app is computer software, typically small and specific, designed

for mobile devices. Originally, it referred to any mobile or desktop application.
Today, it primarily denotes small programs that can be downloaded and installed
on mobile devices.

Types of Apps

Desktop Apps

●​ Characteristics:
○​ Standalone programs (e.g., editors, word processors, web browsers, mail
clients).
○​ Often functional offline with local data storage.
○​ May include network connectivity for updates or features.
●​ Development:
○​ Utilize Software Development Kits (SDKs).
○​ Often OS-specific frameworks.

Mobile Apps

●​ Characteristics:
○​ Targeted for phones or tablets with platform-specific constraints.
○​ Constraints:
■​ Limited screen space.
■​ Touch/audio/camera interactions.
■​ Restricted memory/processing power.
■​ Battery consumption considerations.
○​ Often network-dependent.
●​ Development Frameworks:
○​ OS-specific.
○​ Cross-platform tools (e.g., React Native, Flutter).

Web Apps
 ●​ Characteristics:
○​ Platform-independent, works across devices and operating systems.
○​ Strongly reliant on network connectivity.
○​ Offline workarounds can be implemented.

Focus of the Course

●​ Core Components:
○​ Storage: Data handling and formats.
○​ Computation: Indexing, processing, and calculations.
○​ Presentation: User interfaces and rendering.
●​ Example: Email Client
○​ Storage: Server-side email storage, file formats.
○​ Compute: Email indexing, search functions.
○​ Presentation: Display email list, rendering individual messages.

Platforms

●​ Desktop:
○​ Input: Keyboard, mouse, video.
○​ Paradigm: Folders, files, documents.
●​ Mobile:
○​ Interfaces: Touchscreen, voice, tilt sensors, camera.
○​ Self-contained apps for specific functionalities.
●​ Web-based:
○​ Datacenter storage with persistent cloud-based access.
○​ Multi-device usage and synchronization.
●​ Embedded:
○​ Focused on single functions, e.g., IoT devices.

Architectures

Client-Server Model

●​ Server:
○​ Stores and processes data.
○​ Provides data upon request.
●​ Client:
○​ Requests data and displays it to the user.
○​ Handles user interaction.
●​ Network:
○​ Connects clients and servers.
 ○​ Can be local or internet-based.
●​ Examples:
○​ Email, messaging apps, web browsers, databases.

Distributed (Peer-to-Peer) Model

●​ Characteristics:
○​ All peers have equivalent roles, though some may take on special roles
(e.g., master nodes).
○​ Error tolerance with mechanisms for role reassignment on failure.
●​ Examples:
○​ Bittorrent, blockchain systems, distributed file storage like IPFS.

Software Architecture Patterns

●​ Common Patterns:
○​ Model-View-Controller (MVC):
■​ Model: Core data handling, e.g., databases, indexing.
■​ View: User interface for interaction.
■​ Controller: Business logic managing data manipulation.
○​ Other Patterns:
■​ Model-View-Adapter, Model-View-Presenter, MVVM, Hierarchical
MVC.
○​ Purpose: Provide reusable solutions to common design problems.

Web-Based Platforms

Why the Web?

●​ Advantages:
○​ Cross-platform compatibility across OS and hardware.
○​ Sound underlying principles with clear constraints and costs.

Historical Background

●​ Telephone Networks (1890s):

○​ Circuit-switched networks connecting specific nodes.
●​ Packet-Switched Networks (1960s):
○​ Efficient usage by sending data in packets instead of tying up wires.
○​ Led to ARPANet (1969) and other proprietary networks (e.g., IBM SNA).
●​ Protocols:
○​ IP (1983): Standardized headers and packet handling.
 ○​ TCP (1983): Reliable communication, error control, and scaling.
●​ Domain Names (1985):
○​ Easier human-friendly naming system.
●​ HyperText (1989):
○​ Linking documents with embedded formatting hints.

Evolution of the Web

●​ Web 1.0: Static pages with limited interactivity.

●​ Web 2.0 (2004+):
○​ Dynamic content generation.
○​ Client-side computation and rendering.
○​ HTTP used for diverse data types.
○​ Platform-agnostic systems.

Web Mechanics

Web Servers

●​ Role:
○​ Listen on a fixed port, process incoming requests, and return responses.
●​ Protocol:
○​ Govern communication between clients and servers.

HTTP (HyperText Transfer Protocol)

●​ Definition:
○​ Text-based protocol for exchanging hypertext documents.
●​ Structure:
○​ Requests from clients (e.g., GET / HTTP/1.1).
○​ Responses from servers with headers and data.

Simplest Server Example

while true; do
echo -e "HTTP/1.1 200 OK $(date)" | nc -l localhost 1500;
done

Debugging Tools

●​ curl:
○​ Command-line tool for making HTTP requests.
○​ Verbose output shows headers and response details.
 ●​ Example:​
curl -v http://localhost:1500

Protocols

●​ Definition: Agreement on how communication occurs.

○​ Example: Greeting, handshake, exchanging information.
●​ In Web:
○​ Client: Requests data and capabilities it can handle.
○​ Server: Responds with appropriate data in the agreed format.

HTTP Basics

1.​ GET: Requests information from the server (read).

2.​ HOST: Specifies the URL, e.g., localhost:1800.
3.​ User-Agent: Identifies the requesting agent (e.g., curl).
4.​ Accept: Lists MIME types the client can handle.

Loopback Address

Special IPs used for testing a computer's network stack:

●​ IPv4: 127.0.0.1
●​ IPv6: ::1​
Packets sent here are processed locally and don't leave the computer.

HTTP Protocol Basics

●​ Client: Sends requests (GET, POST). Specifies what it can accept.

●​ Server: Responds to requests with data, headers, or status codes.
HTTP Request Types

Type Purpose

GET Retrieve resources.

POST Create new resources.

PUT Update existing resources.

DELETE Remove resources.

HEAD Fetch headers without the

body.

HTTP Status Codes

Informational

Code Description
100 Continue: Request is in
progress.

101 Switching Protocols.

102 Processing: Still working on it.

Successful

Code Description

200 OK: Request succeeded.

201 Created: New resource was created.

202 Accepted: Request received,

processing.

204 No Content: No data in response.

Redirection

Code Description

303 See Other: Use another URI.

 304 Not Modified: No update since last
request.

307 Temporary Redirect: New URI,

temporary.

308 Permanent Redirect: New URI,

permanent.

Client Errors

Code Description

411 Length Required: Body length missing.

413 Payload Too Large: Body too big.

415 Unsupported Media Type: Can't process

type.

416 Range Not Satisfiable: Invalid range.

Server Errors

Code Description

500 Internal Server Error.

 501 Not Implemented: Feature unsupported.

503 Service Unavailable: Server is down.

504 Gateway Timeout: No timely upstream

response.

Latency

Latency is the total time it takes for a request to travel from the client to the server and
back.

●​ Speed of Light:
○​ In vacuum: 3 × 10⁸ m/s.
○​ In copper cable: Approx 2 × 10⁸ m/s.
●​ Time Approximation:
○​ 1000 km takes 5 ms (calculated as: 1,000,000 m ÷ 2 × 10⁸ m/s = 5 ms).
●​ Example Calculation:
○​ Distance: 200 km.
○​ Time one way = 200 km ÷ 1000 km × 5 ms = 1 ms.
○​ Round trip = 10 ms.
●​ Requests per Second:
○​ One round trip takes 20 ms.
○​ Max requests per second = 1000 ms ÷ 20 ms = 50 requests/sec.

Response Size

Response size refers to how much data is sent from the server to the client for a single
request.

Example:

●​ Response Data: 1 KB (includes HTML, CSS, JS, etc.).

●​ Network Speed: 100 Mbps.
 ○​ Convert to megabytes per second: 100 Mbps ÷ 8 = 12.5 MBps.
●​ Time for 1 Request:
○​ 1 KB ÷ 12.5 MBps = 0.08 ms.
●​ Max Requests per Second:
○​ 1 s ÷ 0.08 ms ≈ 12,500 requests/sec.

Simplified Calculation:

●​ 100 Mbps × 1 s = 100 Mb (bits) = 12.5 MB (bytes).

●​ For 1 KB/request:
○​ 12,500 KB ÷ 1 KB = 12,500 requests/sec.

If 10,000 requests/sec exceed the server’s capacity, it will crash.