PiRho Knowledgebase - Recent changes [en-gb]

Restoring Android Studio 3 AVD Manager

Dex — Mon, 17 Aug 2026 10:29:35 GMT

Restoring Android Studio 3 AVD Manager

Dex — Mon, 17 Aug 2026 08:59:32 GMT

Created page with "'''Summary:''' Android Studio 3.0 was designed around a 2017-era Android SDK. Attempting to use Android Studio 3.0 with modern SDK components can result in missing AVD Manager functionality, Gradle synchronization failures, emulator incompatibilities, and a generally unstable development environment. This article documents the investigation, diagnosis, reconstruction, and validation of a fully functional Android Studio 3.0 environment capable of running Android 8.0 Oreo..."

New page

'''Summary:''' Android Studio 3.0 was designed around a 2017-era Android SDK. Attempting to use Android Studio 3.0 with modern SDK components can result in missing AVD Manager functionality, Gradle synchronization failures, emulator incompatibilities, and a generally unstable development environment. This article documents the investigation, diagnosis, reconstruction, and validation of a fully functional Android Studio 3.0 environment capable of running Android 8.0 Oreo (API 26) virtual devices. == Symptoms == * Android Virtual Device (AVD) Manager missing or unavailable. * Android-specific tooling partially disabled. * Emulator installed but not fully integrated into Android Studio. * Gradle project synchronization failures. * Dependency resolution failures. * Modern SDK components installed alongside Android Studio 3.0. == Environment == === IDE === <pre> Android Studio 3.0.0 Build 171.4408382 </pre> === Operating System === <pre> Windows 10 </pre> === SDK Location === <pre> S:\Android\Sdk </pre> == Initial Observations == Although Android Studio appeared to function, the installed Android SDK contained components from wildly different generations. == Root Cause == The underlying issue was a version mismatch. Android Studio 3.0 expects components contemporary with its release period: <pre> 2017 </pre> The SDK, however, had accumulated components from approximately: <pre> 2017 - 2026 </pre> == Reconstructing a Period-Correct SDK == === Android Studio === <pre> Android Studio 3.0.0 </pre> === Java === <pre> OpenJDK 1.8.0_152 </pre> === SDK Tools === <pre> 26.1.1 </pre> === Platform Tools === <pre> 26.0.0 </pre> Direct download: <pre> https://dl.google.com/android/repository/platform-tools_r26.0.0-windows.zip </pre> === Build Tools === <pre> 26.0.2 </pre> === Android Platform === <pre> Android 8.0 (API 26) </pre> === Emulator === Recommended: <pre> Android Emulator 27.2.9.0 Build ID 4773671 </pre> === HAXM === <pre> Intel HAXM 7.8.0 </pre> == Verifying SDK Functionality == === List Targets === <syntaxhighlight lang="dos"> avdmanager.bat list target </syntaxhighlight> === List Devices === <syntaxhighlight lang="dos"> avdmanager.bat list device </syntaxhighlight> == Creating a Test Device == <syntaxhighlight lang="dos"> avdmanager create avd ^ -n Test26 ^ -k "system-images;android-26;default;x86" </syntaxhighlight> == Launching the Emulator == <syntaxhighlight lang="dos"> emulator.exe -avd Test26 </syntaxhighlight> == Verifying ADB Connectivity == <syntaxhighlight lang="dos"> adb devices </syntaxhighlight> Expected: <pre> emulator-5554 device </pre> == Restoring AVD Manager == After rebuilding the SDK using period-correct components and configuring Java correctly, Android Studio regained full AVD functionality. == Final Working Configuration == <pre> Android Studio 3.0.0 Java 1.8.0_152 SDK Tools 26.1.1 Platform Tools 26.0.0 Build Tools 26.0.2 Platform Android API 26 System Images Oreo x86 / x86_64 Emulator 27.2.9.0 HAXM 7.8.0 </pre> == Lessons Learned == * Validate components individually. * Avoid mixing SDK generations. * Keep legacy SDKs isolated. * Archive known-good components. == Related Topics == * Android Studio Legacy Environment Preservation * Android SDK Version Compatibility * Intel HAXM Configuration * Android Emulator Troubleshooting * Gradle Dependency Resolution * Software Archaeology and Environment Reconstruction

A Taxonomy of Applications

Dex — Thu, 13 Aug 2026 09:09:12 GMT

Created page with "'''Summary:''' The term ''application'' encompasses a wide variety of software delivery models, execution environments, architectures, and deployment mechanisms. Over the decades, the software industry has introduced numerous application technologies, including desktop applications, web applications, browser plugins, widgets, mobile applications, progressive web applications, hybrid applications, and runtime-hosted solutions. This article provides a structured taxonomy..."

New page

'''Summary:'''
The term ''application'' encompasses a wide variety of software delivery models, execution environments, architectures, and deployment mechanisms.

Over the decades, the software industry has introduced numerous application technologies, including desktop applications, web applications, browser plugins, widgets, mobile applications, progressive web applications, hybrid applications, and runtime-hosted solutions.

This article provides a structured taxonomy of application types, explaining how they relate to each other and identifying the common architectural patterns that exist beneath the terminology.

== Context ==

Many discussions about software architecture become confusing because different classifications are mixed together.

For example:

* A Progressive Web App is often compared to a Native App.
* A Single Page Application is often compared to Electron.
* A Widget is often compared to an Application.
* A SaaS Platform is often discussed as though it were an application technology.

In reality, these concepts frequently describe different aspects of the application ecosystem.

A useful taxonomy helps clarify these relationships.

== What Is A Taxonomy? ==

A taxonomy is a system used to classify and organise related concepts.

Rather than treating every application technology as a unique category, a taxonomy identifies shared characteristics and groups technologies accordingly.

For example:

<pre>
Animal
├── Mammal
├── Bird
└── Reptile
</pre>

Similarly:

<pre>
Application
├── Native
├── Web
├── Hybrid
└── Runtime Hosted
</pre>

The objective is not to determine which approach is superior, but to understand how each approach relates to the others.

== The Application Family Tree ==

<pre>
Applications
│
├── Native Applications
│
├── Web Applications
│
├── Hybrid Applications
│
├── Runtime Hosted Applications
│
├── Component Applications
│
└── Cloud Delivered Applications
</pre>

Each branch contains further subcategories.

== Native Applications ==

Native applications execute directly against a platform's operating system APIs.

<pre>
Application
│
▼
Operating System
│
▼
Hardware
</pre>

=== Examples ===

* Windows Applications
* Linux Applications
* macOS Applications
* Android Applications
* iOS Applications

=== Characteristics ===

* Platform specific
* Direct operating system integration
* High performance
* Full device access

=== Typical Technologies ===

* Win32
* WinUI
* Cocoa
* Swift
* Kotlin
* GTK
* Qt

== Web Applications ==

Web applications execute within a web browser.

The browser acts as a runtime environment and abstracts operating system differences.

<pre>
Application
│
▼
Browser
│
▼
Operating System
</pre>

=== Traditional Web Applications ===

Examples:

* Content Management Systems
* Webmail
* Intranets
* E-Commerce Platforms

Architecture:

<pre>
Browser
│
Server
│
Database
</pre>

=== Single Page Applications (SPA) ===

Examples:

* React
* Angular
* Vue

Architecture:

<pre>
Application
│
▼
Browser
│
▼
API Services
</pre>

=== Progressive Web Applications (PWA) ===

PWAs are a specialised form of web application.

They add:

* Service Workers
* Offline Support
* Push Notifications
* Installability

A PWA is therefore:

<pre>
Web Application
+
Extended Browser Capabilities
=
PWA
</pre>

== Hybrid Applications ==

Hybrid applications combine technologies from multiple categories.

They typically use web technologies while maintaining access to native capabilities.

=== Electron ===

<pre>
Application
│
▼
Chromium
│
▼
Node.js
│
▼
Operating System
</pre>

Examples:

* Visual Studio Code
* Discord
* Slack

=== Cordova ===

Packages a web application into a native mobile application.

=== Capacitor ===

A modern evolution of Cordova with improved platform integration.

=== MAUI Hybrid ===

Combines native application components with web-based user interfaces.

=== Common Characteristics ===

* Shared codebases
* Multi-platform deployment
* Access to native functionality
* Additional runtime layers

== Runtime Hosted Applications ==

Runtime-hosted applications target an intermediary runtime rather than a platform directly.

This category includes many technologies that are often incorrectly grouped elsewhere.

<pre>
Application
│
▼
Runtime
│
▼
Platform
</pre>

=== Examples ===

* Java Applications
* .NET Applications
* Electron Applications
* Browser Applications
* AIR Applications
* Web Runtime Environment Applications

The runtime provides:

* Storage
* Networking
* Security
* Rendering
* Platform abstraction

=== Characteristics ===

* Platform independence
* Consistent APIs
* Simplified portability
* Runtime dependency

== Component Applications ==

Some software is not intended to function as a complete standalone application.

Instead, it provides functionality within another application.

=== Widgets ===

Widgets are small applications designed to perform specific tasks.

Examples:

* Weather Widgets
* Stock Tickers
* Calendar Widgets
* System Monitors

=== Web Parts ===

Web Parts provide reusable functionality within larger platforms.

Examples:

* SharePoint Web Parts
* Dashboard Components
* Enterprise Portal Modules

=== Browser Extensions ===

Extensions add capabilities to an existing application.

Examples:

* Password Managers
* SEO Toolbars
* Developer Tools Extensions

=== Modern Components ===

Many modern systems use:

* React Components
* Vue Components
* Web Components
* Widgets

Although implemented differently, the concept remains similar.

== Cloud Delivered Applications ==

Cloud delivery describes how software is provided rather than how it is built.

=== Software as a Service (SaaS) ===

Examples:

* Microsoft 365
* Salesforce
* ServiceNow
* Google Workspace

A SaaS solution may internally use:

* Native Applications
* Web Applications
* PWAs
* Mobile Applications
* Hybrid Applications

It is therefore best viewed as a delivery model rather than an application type.

== Historical Branches ==

Several technologies occupy important positions in application history.

=== HTML Applications (HTA) ===

HTAs combined:

<pre>
HTML
+
Scripting
+
Desktop Trust
</pre>

They can be viewed as an early hybrid application technology.

=== Java Applets ===

Applets were runtime-hosted applications delivered through browsers.

=== Adobe AIR ===

AIR brought web technologies onto the desktop by supplying a runtime environment.

=== Silverlight ===

Silverlight combined browser hosting with runtime-based execution.

=== Flash Applications ===

Flash was both:

* A runtime platform
* An application delivery mechanism

Its influence can still be seen in modern web application development.

== Another Way To Classify Applications ==

Applications can also be classified according to where execution occurs.

=== Local Execution ===

<pre>
Application
│
▼
User Device
</pre>

Examples:

* Native Applications
* Mobile Apps
* Desktop Applications

=== Browser Execution ===

<pre>
Application
│
▼
Browser
</pre>

Examples:

* Web Applications
* SPAs
* PWAs

=== Runtime Execution ===

<pre>
Application
│
▼
Runtime Environment
</pre>

Examples:

* Java Applications
* Electron Applications
* AIR Applications

=== Distributed Execution ===

<pre>
Client
│
▼
Services
│
▼
Infrastructure
</pre>

Examples:

* SaaS Platforms
* Cloud Applications
* Enterprise Systems

== Common Architectural Patterns ==

Most application technologies share one of a small number of execution models.

=== Direct Execution ===

<pre>
Application
│
▼
Operating System
</pre>

=== Hosted Execution ===

<pre>
Application
│
▼
Host Environment
│
▼
Operating System
</pre>

=== Distributed Execution ===

<pre>
Client
│
▼
Services
│
▼
Data Sources
</pre>

These patterns appear repeatedly throughout computing history.

== Why Taxonomy Matters ==

A structured taxonomy helps developers and architects:

* Compare technologies fairly
* Select appropriate architectures
* Understand trade-offs
* Identify shared concepts
* Avoid terminology confusion

For example:

* A PWA is not a competitor to SaaS.
* A Widget is not a competitor to Electron.
* A Runtime is not an Application.
* A Browser is not merely a renderer.

Each occupies a different position within the overall ecosystem.

== Key Takeaways ==

* Applications can be classified according to architecture, runtime, hosting model, or delivery mechanism.
* Many technologies overlap across multiple categories.
* Web applications, native applications, hybrid applications, and runtime-hosted applications solve similar problems using different approaches.
* SaaS is a delivery model rather than an application technology.
* Widgets, components, extensions, and Web Parts are specialised application forms.
* Most modern application platforms are evolutionary refinements of concepts explored over many decades.
* Understanding the taxonomy of applications provides a clearer foundation for architecture and design discussions.

== Related Topics ==

* [[Applications Demystified]]
* [[The Evolution of Application Delivery]]
* [[Application Design for Multiple Platforms]]
* [[Runtime Environments]]
* [[Progressive Web Applications]]
* [[Hybrid Applications]]
* [[Software as a Service]]
* [[Web Runtime Environments]]
* [[Application Architecture]]

Application Design for Multiple Platforms

Dex — Thu, 13 Aug 2026 09:02:41 GMT

Created page with "'''Summary:''' Modern software is expected to run on an increasing number of platforms. Users may access the same application from desktop computers, laptops, tablets, mobile devices, kiosk systems, web browsers, and cloud-hosted environments. Historically, organisations developed separate applications for each platform. While this approach provides maximum control, it can significantly increase development and maintenance costs. This article explores the two primary a..."

New page

'''Summary:'''
Modern software is expected to run on an increasing number of platforms. Users may access the same application from desktop computers, laptops, tablets, mobile devices, kiosk systems, web browsers, and cloud-hosted environments.

Historically, organisations developed separate applications for each platform. While this approach provides maximum control, it can significantly increase development and maintenance costs.

This article explores the two primary approaches to multi-platform application design: platform-specific development and portable application design. It examines the strengths, weaknesses, and architectural considerations of each approach and provides guidance on choosing the most appropriate strategy.

== Context ==

The challenge of supporting multiple platforms is almost as old as software development itself.

An application may need to support:

* Windows
* macOS
* Linux
* Android
* iOS
* Browser-based environments
* Embedded systems
* Virtual desktop environments

The fundamental question becomes:

<blockquote>
Should the application target the platform directly, or should it target an abstraction that hides platform differences?
</blockquote>

How this question is answered shapes the entire architecture of the solution.

== Platform-Specific Design ==

Platform-specific design creates separate applications for each supported platform.

<pre>
Windows Application
│
▼
Windows

Android Application
│
▼
Android

iOS Application
│
▼
iOS
</pre>

Each application is developed using technologies native to that platform.

=== Examples ===

{| class="wikitable"
! Platform
! Typical Technologies
|-
| Windows
| Win32, WinForms, WPF, WinUI, .NET
|-
| Android
| Kotlin, Java
|-
| iOS
| Swift, Objective-C
|-
| macOS
| Swift, Cocoa
|-
| Linux
| GTK, Qt
|}

=== Advantages ===

* Maximum performance
* Deep platform integration
* Direct access to operating system features
* Native user experience
* Immediate access to new platform capabilities

=== Disadvantages ===

* Multiple codebases
* Increased development effort
* Increased maintenance costs
* Feature parity challenges
* Larger development teams

=== Typical Use Cases ===

Platform-specific design remains appropriate when:

* Maximum performance is essential
* Hardware integration is required
* Platform-specific user experiences are important
* Operating system features are heavily utilised

Examples include:

* Professional video editing software
* CAD applications
* Games
* Device drivers
* Operating system utilities

== Portable Application Design ==

Portable application design takes a different approach.

Instead of targeting individual operating systems, the application targets a shared runtime or abstraction layer.

<pre>
Application
│
▼
Runtime
│
▼
Platform
</pre>

The runtime is responsible for adapting platform-specific behaviour.

From the application's perspective:

<pre>
Application Logic
│
├── Windows
├── Android
├── iOS
├── macOS
└── Linux
</pre>

becomes:

<pre>
Application Logic
│
▼
Runtime
│
▼
Supported Platforms
</pre>

This significantly reduces duplicated development effort.

== The Role of the Runtime ==

A runtime acts as an intermediary between the application and the platform.

Responsibilities may include:

* File access
* Storage
* Networking
* Notifications
* Device integration
* Security
* Window management
* Rendering

Conceptually:

<pre>
Application
│
▼
Platform-Neutral APIs
│
▼
Runtime Environment
│
▼
Platform-Specific APIs
│
▼
Operating System
</pre>

The application primarily interacts with the runtime rather than the operating system directly.

== Common Portable Architectures ==

=== Browser-Based Applications ===

The browser is one of the most successful runtime environments ever created.

<pre>
Application
│
▼
Browser APIs
│
▼
Browser
│
▼
Operating System
</pre>

The browser abstracts significant platform differences.

As a result, a properly designed web application can operate on many operating systems with minimal modification.

=== Progressive Web Applications ===

Progressive Web Applications extend traditional web application capabilities.

Additional features include:

* Offline operation
* Background processing
* Local storage
* Notifications
* Installation support

A PWA remains fundamentally a web application but gains application-like behaviour.

=== Electron Applications ===

Electron uses a bundled browser runtime.

<pre>
Application
│
▼
Chromium
│
▼
Node.js
│
▼
Operating System
</pre>

Developers can create desktop applications using web technologies while maintaining a relatively portable codebase.

=== Cross Platform Frameworks ===

Modern frameworks provide platform abstraction while still producing native deployments.

Examples include:

* Flutter
* React Native
* Avalonia
* Uno Platform
* .NET MAUI

These frameworks seek to provide a balance between portability and native capability.

== Designing Around Abstractions ==

One of the most important architectural decisions is identifying which layer owns platform-specific behaviour.

=== Poor Separation ===

<pre>
Application
├── Windows Logic
├── Android Logic
├── iOS Logic
└── Linux Logic
</pre>

Over time, this approach often becomes difficult to maintain.

Every new feature may require changes across multiple sections of the codebase.

=== Better Separation ===

<pre>
Application
│
▼
Service Layer
│
▼
Platform Adapter
│
▼
Operating System
</pre>

The application remains largely platform agnostic while platform-specific concerns are isolated.

This approach improves:

* Maintainability
* Testability
* Portability
* Long-term scalability

== User Interface Considerations ==

The user interface is often the most visible challenge in multi-platform design.

Different platforms have different conventions.

=== Native Experience ===

Users generally expect applications to behave similarly to other applications on their chosen platform.

Examples include:

* Menu placement
* Navigation patterns
* Input behaviours
* Accessibility features

Ignoring platform conventions may create a poor user experience.

=== Consistent Experience ===

Some organisations prioritise consistency instead.

Examples include:

* Microsoft Office
* Adobe Creative Cloud
* Browser-based enterprise applications

Users encounter similar interfaces regardless of platform.

Both approaches are valid depending on business requirements.

== Offline-First Design ==

Modern multi-platform applications increasingly adopt an offline-first model.

Traditional architecture:

<pre>
Application
│
▼
Server
</pre>

Offline-first architecture:

<pre>
Application
│
▼
Local Data Store
│
▼
Synchronisation Layer
│
▼
Server
</pre>

The application interacts primarily with local data.

Synchronisation occurs separately.

Benefits include:

* Improved responsiveness
* Better reliability
* Reduced network dependency
* Enhanced mobile support

This design is increasingly common in mobile, cloud, and distributed applications.

== Web Runtime Environments ==

An emerging architectural pattern involves hosting applications within a dedicated runtime environment that implements or extends standard Web APIs.

Conceptually:

<pre>
Application
│
▼
Standard Web APIs
│
▼
Web Runtime Environment
│
▼
Operating System
</pre>

In this model:

* Applications target standard browser capabilities.
* Platform differences are handled by the runtime.
* Platform-specific implementations are hidden behind a consistent API surface.
* Applications remain largely unaware of the underlying operating system.

This approach builds upon concepts previously explored by browsers, HTAs, AIR, Electron, mobile runtimes, and progressive web technologies.

== Choosing The Right Approach ==

There is no universally correct solution.

The best architecture depends upon:

* Target audience
* Supported platforms
* Performance requirements
* Security requirements
* Offline requirements
* Team expertise
* Budget constraints
* Long-term maintenance goals

A useful guideline is:

<blockquote>
Target the highest level of abstraction that still allows the application to meet its requirements.
</blockquote>

This often produces the best balance between portability, flexibility, and maintainability.

== Common Misconceptions ==

=== Portable Means Less Powerful ===

Portable applications can often provide capabilities comparable to native applications.

The difference usually lies in the abstraction layer rather than the application's functionality.

=== One Codebase Solves Everything ===

A single codebase may reduce duplication, but architectural complexity still exists.

Platform differences do not disappear simply because they are hidden behind a framework.

=== Native Is Always Better ===

Native applications provide advantages in some scenarios.

However, portability, maintainability, deployment simplicity, and development speed may be more important than maximum performance.

== Key Takeaways ==

* Multi-platform application design requires balancing portability and platform integration.
* Platform-specific applications provide maximum control but increase complexity.
* Portable architectures reduce duplication through abstraction layers and runtimes.
* Browsers are among the most successful runtime environments ever developed.
* Modern frameworks continue the long-standing industry goal of write-once, run-anywhere software.
* Offline-first design is increasingly important in modern application architectures.
* Successful architectures separate application logic from platform-specific implementation details.
* The best solution is usually the simplest architecture that satisfies the application's requirements.

== Related Topics ==

* [[Applications Demystified]]
* [[The Evolution of Application Delivery]]
* [[Progressive Web Applications]]
* [[Cross Platform Development]]
* [[Runtime Environments]]
* [[Offline First Design]]
* [[Application Architecture]]
* [[Web Runtime Environments]]
* [[Software Portability]]

The Evolution of Application Delivery

Dex — Thu, 13 Aug 2026 08:59:37 GMT

Created page with "'''Summary:''' The history of software development is, in many ways, the history of application delivery. For decades, developers have searched for the ideal balance between performance, portability, usability, security, maintainability, and deployment simplicity. Each generation of application technology emerged to solve the limitations of the one before it. Some technologies disappeared, some evolved, and some continue to influence modern application design. Understan..."

New page

'''Summary:'''
The history of software development is, in many ways, the history of application delivery. For decades, developers have searched for the ideal balance between performance, portability, usability, security, maintainability, and deployment simplicity.

Each generation of application technology emerged to solve the limitations of the one before it. Some technologies disappeared, some evolved, and some continue to influence modern application design. Understanding this evolution provides valuable insight into why modern application architectures look the way they do today.

== Context ==

Although technology changes rapidly, the challenges faced by software developers remain surprisingly consistent:

* How do users obtain the application?
* How is the application updated?
* How portable is it?
* How much access does it need to the underlying system?
* How can development effort be reduced?

Many "new" technologies are simply different answers to these same questions.

== A Timeline of Application Delivery ==

<pre>
1990s
├── Native Desktop Apps
├── Browser Websites
└── HTAs

2000s
├── Java Applets
├── Flash
├── AIR
├── Widgets
└── Silverlight

2010s
├── Mobile Apps
├── SPAs
├── Electron
└── PWAs

2020s
├── Cross Platform Frameworks
├── Web Runtime Environments
├── MAUI
└── Browser-hosted Applications
</pre>

Each generation attempted to improve upon the strengths and weaknesses of its predecessors.

== The 1990s: The Age of the Desktop ==

=== Native Desktop Applications ===

During the 1990s, native desktop applications dominated personal computing.

Examples included:

* Microsoft Office
* Lotus Notes
* CorelDRAW
* Adobe Photoshop

Applications were typically installed from:

* Floppy disks
* CD-ROMs
* Corporate network shares

Typical architecture:

<pre>
Application
│
▼
Operating System
│
▼
Hardware
</pre>

=== Strengths ===

* Excellent performance
* Rich user interfaces
* Deep hardware access
* Extensive operating system integration

=== Challenges ===

* Manual installation
* Difficult updates
* Platform dependency
* Software distribution costs

=== Browser Websites ===

As Internet access became widespread, websites evolved beyond static documents.

Developers began building systems that accepted user input and generated dynamic content.

Examples included:

* Early webmail systems
* Online shopping platforms
* Corporate intranets

This introduced a new concept:

<blockquote>
The application lives on the server rather than the user's computer.
</blockquote>

This dramatically simplified deployment.

=== HTML Applications (HTA) ===

Microsoft recognised that many developers wanted the flexibility of web technologies with the power of desktop applications.

HTAs attempted to bridge this gap.

An HTA provided:

* HTML user interfaces
* JavaScript and VBScript
* Desktop integration
* Reduced browser security restrictions

Conceptually:

<pre>
Web Technologies
+
Desktop Trust
=
HTA
</pre>

Many ideas later found in hybrid applications can be traced back to HTAs.

== The 2000s: Rich Internet Applications ==

As internet connectivity improved, developers sought to deliver richer experiences through the browser.

This era became known as the age of the Rich Internet Application (RIA).

=== Java Applets ===

Java Applets promised:

<pre>
Write Once
Run Anywhere
</pre>

Applications executed within the browser using the Java Runtime Environment.

Developers could create:

* Interactive interfaces
* Games
* Business applications

However, browser compatibility, performance issues, and security concerns eventually reduced adoption.

=== Flash ===

Adobe Flash became one of the most influential technologies of the era.

Flash enabled:

* Animation
* Video
* Interactive applications
* Browser games

For many years, Flash offered capabilities that standard web technologies could not.

Entire websites were sometimes built exclusively in Flash.

=== Adobe AIR ===

Adobe AIR extended Flash beyond the browser.

Developers could create:

* Desktop applications
* Media tools
* Business systems

using familiar web technologies.

Architecture:

<pre>
Application
│
▼
Adobe AIR
│
▼
Operating System
</pre>

AIR demonstrated that web technologies could be used for desktop application development.

=== Widgets ===

Widgets represented a different approach.

Instead of building large applications, developers created small, focused applications designed to perform a specific function.

Examples included:

* Weather widgets
* RSS readers
* Clocks
* System monitors

Platforms included:

* Opera Widgets
* Yahoo Widgets
* Apple Dashboard Widgets
* W3C Widget specifications

Many widget concepts later influenced modern component-based application design.

=== Silverlight ===

Microsoft Silverlight attempted to provide a .NET-based alternative to Flash.

Features included:

* Rich interfaces
* Multimedia support
* C# development
* Browser integration

Silverlight gained significant enterprise adoption before HTML5 ultimately reduced the need for browser plugins.

== The 2010s: Mobile and the Return of the Application ==

The introduction of smartphones fundamentally changed software delivery.

=== Mobile Applications ===

Apple's App Store and Google's Play Store transformed application distribution.

Advantages included:

* Easy installation
* Automatic updates
* Device integration
* App monetisation

This period saw a return to native application development.

Developers often maintained separate:

* iOS applications
* Android applications
* Web applications

This increased development costs considerably.

=== Single Page Applications (SPAs) ===

Meanwhile, web applications continued to evolve.

SPAs moved much of the application logic into the browser.

Popular frameworks included:

* Angular
* React
* Vue

This produced experiences that felt increasingly similar to desktop applications.

Architecture shifted from:

<pre>
Page → Request → Page
</pre>

to:

<pre>
Application → API → Data
</pre>

=== Electron ===

Developers soon realised that modern web applications looked and behaved remarkably like desktop software.

Electron formalised this idea.

By combining:

<pre>
Web Application
+
Chromium
+
Node.js
</pre>

developers could deploy desktop applications using web technologies.

Electron became popular because organisations could reuse existing web development skills.

=== Progressive Web Applications ===

PWAs represented a different response to the same challenge.

Instead of bringing browsers to the desktop, they brought desktop-like capabilities to web applications.

Features included:

* Offline support
* Push notifications
* Home screen installation
* Background synchronisation

A PWA remained fundamentally a web application while behaving more like a traditional app.

== The 2020s: Convergence ==

Modern application development is increasingly focused on platform convergence.

The distinction between native, web, and hybrid applications continues to blur.

=== Cross Platform Frameworks ===

Modern frameworks attempt to reduce duplicated effort.

Examples include:

* Flutter
* React Native
* Uno Platform
* Avalonia

The objective remains:

<blockquote>
One codebase, multiple platforms.
</blockquote>

=== Web Runtime Environments ===

A growing trend is the use of runtime environments that host applications and abstract platform differences.

In this model:

<pre>
Application
│
▼
Web APIs
│
▼
Runtime Environment
│
▼
Operating System
</pre>

The application primarily targets a consistent API surface rather than individual operating systems.

This approach continues the ideas explored by browsers, HTAs, AIR, Electron, and hybrid frameworks.

=== .NET MAUI ===

.NET MAUI represents Microsoft's current approach to unified application development.

Applications can target:

* Windows
* Android
* iOS
* macOS

from a shared codebase.

MAUI reflects the industry's continuing pursuit of platform-independent development.

=== Browser-Hosted Applications ===

Browsers have evolved into highly capable application platforms.

Modern browsers provide:

* Local storage
* Offline caching
* Device integration
* Notifications
* Hardware acceleration

As a result, many applications that once required native deployment can now execute entirely within a browser.

== Recurring Themes Throughout History ==

Several patterns repeatedly appear throughout the evolution of application delivery.

=== Reduce Deployment Friction ===

Every generation attempts to make deployment easier:

<pre>
Floppy Disk
↓
CD-ROM
↓
Download
↓
Browser
↓
App Store
↓
Cloud Service
</pre>

=== Increase Portability ===

Technology continually moves toward platform independence.

<pre>
Platform Specific
↓
Cross Platform
↓
Platform Agnostic
</pre>

=== Balance Power and Security ===

Every application model must balance:

* User convenience
* System access
* Security

Many technologies declined because they became difficult to secure.

=== Reuse Existing Skills ===

A recurring industry goal is reducing the need to maintain multiple codebases and specialist teams.

Many modern frameworks exist primarily to maximise code reuse across platforms.

== Have We Solved The Problem? ==

Not entirely.

The software industry continues to search for the ideal balance between:

* Native performance
* Web portability
* Development efficiency
* Security
* User experience

Every generation offers improvements, but no approach completely eliminates trade-offs.

Consequently, application delivery continues to evolve.

== Key Takeaways ==

* Most application technologies emerged in response to specific limitations of previous generations.
* The industry frequently alternates between local execution and browser-hosted execution models.
* Many modern technologies revisit ideas first explored decades earlier.
* Cross-platform development remains a consistent objective throughout computing history.
* Application delivery mechanisms change, but the underlying challenges remain remarkably similar.
* Understanding historical solutions helps architects avoid repeating past mistakes and identify genuinely new innovations.

== Related Topics ==

* [[Applications Demystified]]
* [[Progressive Web Applications]]
* [[Single Page Applications]]
* [[Cross Platform Development]]
* [[Runtime Environments]]
* [[Hybrid Applications]]
* [[Software Architecture]]
* [[Web Runtime Environments]]

Applications Demistified

Dex — Thu, 13 Aug 2026 08:57:23 GMT

Applications Demystified

← Older revision		Revision as of 08:57, 13 August 2026
Line 1:		Line 1:
	~~= Applications Demystified =~~

	'''Summary:'''		'''Summary:'''
	Applications have existed for as long as computers have been capable of running software, yet the term ''application'' has become increasingly ambiguous. Today an application may be a traditional executable, a web site that behaves like a desktop program, a mobile app installed from a store, a Progressive Web App (PWA), or a hybrid solution combining several technologies.		Applications have existed for as long as computers have been capable of running software, yet the term ''application'' has become increasingly ambiguous. Today an application may be a traditional executable, a web site that behaves like a desktop program, a mobile app installed from a store, a Progressive Web App (PWA), or a hybrid solution combining several technologies.

Applications Demistified

Dex — Thu, 13 Aug 2026 08:57:04 GMT

Created page with "= Applications Demystified = '''Summary:''' Applications have existed for as long as computers have been capable of running software, yet the term ''application'' has become increasingly ambiguous. Today an application may be a traditional executable, a web site that behaves like a desktop program, a mobile app installed from a store, a Progressive Web App (PWA), or a hybrid solution combining several technologies. This article explores the major application delivery m..."

New page

= Applications Demystified =

'''Summary:'''
Applications have existed for as long as computers have been capable of running software, yet the term ''application'' has become increasingly ambiguous. Today an application may be a traditional executable, a web site that behaves like a desktop program, a mobile app installed from a store, a Progressive Web App (PWA), or a hybrid solution combining several technologies.

This article explores the major application delivery mechanisms, explains how they differ, and demonstrates that most solutions ultimately consist of the same building blocks: code, a user interface, a runtime environment, and a method of delivery.

== Context ==

The software industry often introduces new terminology to describe evolving approaches to application delivery.

Terms such as:

* Native Application
* Web Application
* Single Page Application (SPA)
* Progressive Web App (PWA)
* Hybrid Application
* Widget
* Cloud Application
* Software as a Service (SaaS)

are frequently used interchangeably despite referring to very different concepts.

In reality, most application technologies attempt to solve the same challenge:

<blockquote>
How do we deliver software functionality to users in a way that is efficient, maintainable, portable, and user-friendly?
</blockquote>

Understanding the evolution of application delivery helps architects and developers make informed design decisions rather than simply following current trends.

== What Is An Application? ==

At its simplest, an application consists of four elements:

<pre>
Application
│
├── User Interface
├── Business Logic
├── Data
└── Runtime Environment
</pre>

The runtime environment provides the services the application requires to operate.

Examples include:

* Windows
* Linux
* macOS
* Android
* iOS
* Java Runtime Environment (JRE)
* .NET Runtime
* Web Browser

Different application technologies primarily differ in the runtime they target.

== A Taxonomy of Applications ==

<pre>
Applications
│
├── Native Applications
│ ├── Windows
│ ├── macOS
│ ├── Linux
│ ├── Android
│ └── iOS
│
├── Web-Based Applications
│ ├── Traditional Web Apps
│ ├── SPAs
│ ├── PWAs
│ └── SaaS Platforms
│
├── Hybrid Applications
│ ├── Electron
│ ├── Cordova
│ ├── Capacitor
│ └── MAUI Hybrid
│
└── Historical Technologies
├── HTA
├── Java Applets
├── Widgets
├── AIR
└── Silverlight
</pre>

== Native Applications ==

A native application is compiled specifically for a particular operating system and executes directly against that platform's APIs.

=== Characteristics ===

* Direct access to operating system functionality
* High performance
* Deep platform integration
* Platform-specific development tools
* Platform-specific deployment mechanisms

=== Examples ===

{| class="wikitable"
! Platform
! Typical Technologies
|-
| Windows
| Win32, MFC, .NET, WinUI
|-
| macOS
| Cocoa, Swift
|-
| Linux
| GTK, Qt
|-
| Android
| Kotlin, Java
|-
| iOS
| Swift, Objective-C
|}

=== Advantages ===

* Excellent performance
* Rich operating system integration
* Full access to device capabilities

=== Disadvantages ===

* Multiple codebases may be required
* Higher development and maintenance costs
* Platform-specific expertise required

== Web-Based Applications ==

Web applications execute within a web browser rather than directly on the operating system.

Historically, a web application was little more than a website capable of processing user input. Modern web applications can be remarkably sophisticated and often rival desktop applications in functionality.

=== Traditional Web Applications ===

Traditional web applications generate pages on a server and return fully rendered responses to the browser.

Examples include:

* Early SharePoint sites
* Webmail systems
* Content Management Systems
* E-commerce platforms

Typical architecture:

<pre>
Browser
│
HTTP
│
Web Server
│
Database
</pre>

=== Single Page Applications (SPA) ===

Single Page Applications move much of the application logic into the browser.

Examples include:

* React applications
* Angular applications
* Vue applications

Typical architecture:

<pre>
Browser
│
├── User Interface
├── Business Logic
└── API Calls
│
▼
Backend
</pre>

This model often provides a more responsive user experience by reducing page reloads.

=== Progressive Web Applications (PWA) ===

A Progressive Web Application is a web application enhanced with browser technologies that allow it to behave more like an installed application.

Common features include:

* Offline support
* Service Workers
* Push Notifications
* Installation from the browser
* Home Screen integration

A PWA remains fundamentally a web application.

<pre>
Web Application
+
Manifest
+
Service Worker
=
Progressive Web App
</pre>

=== Software as a Service (SaaS) ===

SaaS describes a delivery model rather than a specific technology.

Examples include:

* Microsoft 365
* Salesforce
* ServiceNow
* Google Workspace

A SaaS platform may internally use:

* Traditional web applications
* SPAs
* PWAs
* Hybrid technologies

The defining characteristic is that the software is consumed as a service.

== Hybrid Applications ==

Hybrid applications attempt to bridge the gap between web technologies and native platforms.

The objective is usually:

<blockquote>
Write once, deploy everywhere.
</blockquote>

=== Electron ===

Electron combines:

<pre>
Application
+
Chromium
+
Node.js
=
Desktop Application
</pre>

Examples include:

* Visual Studio Code
* Discord
* Slack

Advantages:

* Cross-platform
* Familiar web technologies

Disadvantages:

* Large deployment size
* Significant memory usage

=== Apache Cordova ===

Cordova packages web applications inside a native mobile container.

This allows:

* HTML
* CSS
* JavaScript

to access selected device capabilities.

=== Capacitor ===

Capacitor evolved from the Cordova model and provides modern native integration for web applications.

It is commonly used with:

* Angular
* React
* Vue

=== .NET MAUI Hybrid ===

.NET MAUI Hybrid combines native desktop or mobile interfaces with embedded web technologies.

This approach permits organisations with existing web development experience to leverage their skills while still producing native deployments.

== Historical Technologies ==

Many modern application platforms are built upon ideas first explored decades ago.

=== HTML Applications (HTA) ===

HTAs were introduced by Microsoft as trusted desktop applications based on Internet Explorer technologies.

Characteristics included:

* HTML user interfaces
* JavaScript and VBScript support
* Windows integration
* Reduced browser security restrictions

An HTA can be viewed as a web application running with desktop-level trust.

=== Java Applets ===

Java Applets allowed Java applications to execute within web browsers.

Their promise was:

<pre>
Write Once
Run Anywhere
</pre>

Despite early popularity, browser support gradually disappeared due to security, performance, and usability concerns.

=== Opera Widgets and W3C Widgets ===

Widgets attempted to provide small, focused applications that could be installed independently or embedded into larger environments.

Examples included:

* Desktop widgets
* Dashboard widgets
* Mobile widgets

Many widget concepts later influenced modern application component architectures.

=== Adobe AIR ===

Adobe AIR combined:

* Flash
* HTML
* JavaScript

with desktop deployment capabilities.

AIR was particularly popular for media-rich applications before the decline of Flash technologies.

=== Microsoft Silverlight ===

Silverlight was Microsoft's browser-hosted application framework.

It provided:

* Rich user interfaces
* .NET programming
* Multimedia capabilities

Silverlight was eventually superseded by modern web standards and HTML5 technologies.

== Common Themes ==

Although application technologies vary greatly, most share a common structure:

<pre>
Application
│
▼
Runtime
│
▼
Operating System
</pre>

The primary differences are:

* Where the runtime exists
* Which APIs are exposed
* How the application is delivered
* How the application is updated

The business logic itself is often remarkably similar.

== Choosing the Right Approach ==

No application technology is universally superior.

Considerations include:

* Performance requirements
* Platform targets
* Offline requirements
* Security constraints
* Development cost
* Existing team skills
* Long-term maintainability

The best solution is often the one that balances business requirements with technical constraints rather than the newest or most fashionable technology.

== Key Takeaways ==

* An application consists of code, data, a user interface, and a runtime environment.
* Native applications execute directly against operating system APIs.
* Web applications execute within a browser.
* PWAs are enhanced web applications rather than a separate application type.
* Hybrid technologies attempt to combine the benefits of native and web approaches.
* Many modern solutions are evolutionary improvements upon ideas explored decades earlier.
* Understanding application delivery mechanisms helps architects make informed design decisions and avoid reinventing previous mistakes.

== Related Topics ==

* [[Progressive Web Applications]]
* [[Single Page Applications]]
* [[Software as a Service]]
* [[Runtime Environments]]
* [[Application Architecture]]
* [[Offline First Design]]
* [[Opera Widgets]]
* [[Microsoft HTA]]
* [[Cross Platform Development]]