A Unified Approach for Cross-Platform Software Development

1
A Unified Approach for Cross-Platform Software
Development

• A Masters defense
• By
• Jeffery Alan Stuart

2
Acknowledgements

• My advisor, Dr. Harris
• My Committee, Dr. Dascalu, Dr. Johnson,
• Deanna
• Peers (Joe, Lance)

3
Outline

• Definitions
• Introduction
• Background
• My Idea
• Implementation of my Idea
• Directions for Future Work
• Conclusions

4
Definitions

• Hardware Platform
• Software Platform
• Application Programming Interface (API)
• Cross-Platform API (Library)

5
Introduction

• Why cross-platform APIs?
• Why is it hard?

6
Introduction

• Current methods (more detail later)
• Preprocessor
• Separate Branches

7
Background

• Cross-platform used to not exist
• UNIX Kernel
• Make (1970)

8
Background

• Two (current) widely-used methods
• Preprocessor
• ifdef _WIN32
• ifdef __POSIX
• Development branches
• Qt_Win32_4.0.0.b.src.zip
• Qt_X11_4.0.0.b.src.tar.gz

9
Background

• Preprocessor
• Used to eliminate non-compatible code at compile
  time
• Hard to read
• Several smaller packages
• Boost Threads
• HawkNL
• MsgConnect
• ZThreads

10
Background

• Why hard to read?
• Code separated
• Some programmers not familiar with preprocessor
  macros

11
Background

• Boost threads
• Threading package (C stdc)
• Conditionally includes member variables in
  structures (really bad!)
• Why?

12
Background

• HawkNL
• Networking library (C)
• Preprocessor used
• for typedefs and
• macros
• Still confusing, hard
• to find defines

13
Background

• MsgConnect
• Networking API (C)
• Preprocessor used for typedefs and macros
• Tries to port Win32 API to Linux (bad)

14
Background

• ZThreads
• Threading API (C)
• Conditionally include platform implementations
• Not necessarily obvious what platform is being
  used
• How to change easily (pthreads for windows)?

15
Background

• Separate Branches
• All platform specific code (sometimes all code!)
  in different branches
• Easy to read, hard to share
• Larger packages tend to use this
• OpenSG
• Qt
• GTK
• POSIX Threads

16
Background

• Several side effects
• Minimizes code sharing
• Sometimes platform-specific access is granted
  (e.g. Qts QWidget)
• Changing design often has unbalanced consequences
  across branches

17
Background

• Design patterns
• Creational patterns
• Structural patterns
• Behavioral patterns
• Important to new idea
• Bridge
• Builder
• Abstract Factory

18
Is There A Better Way?

• Arent the two methods enough?
• Maintain readability and maximize code sharing
• And the new ideas are
• Cores
• Routers

19
Cores

• Generic solution
• Name has significance
• Composition (Inheritance Aggregation)
• When to use/not-use
• Platform-specific data members
• Platform-specific operations
• Diagram shown below

20
Routers

• Generic solution
• Dependency (No real need for inheritance)
• When to use
• Platform-specific operations
• Why? Dont cores work?

21
Core Example

• Platform-Independent Thread class
• Has platform-dependent and platform-independent
  data members
• Has platform-dependent and platform-independent
  operations
• For brevity, the class will be minimally
  functional

22
Core Example

• Thread File
• Has a core
• Relays platform-specific operations to core

23
Core Example

• ThreadCore File
• Virtual
• No platform-specific types
• Non-functional

24
Core Example

• Platform-specific implementation
• Win32

25
Core Example

• Class Diagram for Thread

26
Router example

• File Class
• Name has signifigance
• Only needs a string (char, stdstring) for
  state
• Platform-dependent operations (GetFileAttributes,
  stat)
• For brevity, minimal functionality only

27
Router Example

• File File
• No router member

28
Router Example

• FileRouter File
• No virtual functions
• Primarily static functions
• Constructor/destructor not necessary

29
Router Example

• Platform-specific implementation
• Win32 Implementation

30
Router Example

• Class diagram for File

31
Real Implementation

• Cross-platform library
• The J Toolkit (JTK)
• Uses cores and routers

32
JTK Packages

• Needs to be broad
• Several packages
• Platform specifics a must (networking, OS
  related, hardware related)

33
JTK Base package

• Foundation classes, C primitive wrappers

34
JTK I/O Package

• Primitives for reading/writing
• File I/O, File Descriptors, Pipes

35
JTK Media Package

• Provides media access (Sound card, etc.)
• Show that cores are good for wrapping access to
  hardware, not just software

36
JTK Networking Package

• Networking utilities (Sockets, Address
  lookup/translation)

37
JTK OS Package

• Operating System primitives (Threads, Semaphores)
• Interface to OS for applications

38
JTK Utilities Package

• Cores can be used for more than just
  cross-platform classes
• Specific implementations, optimizations

39
Application

• Motiviation
• Use JTK
• Use platform-dependent services
• Use hardware services
• Code length
• Code readability

40
Application

• Two applications actually
• PCM (Wave-file) player and Server

41
PCM Server

• Serve files to client
• Multi-threaded
• Networked (TCP and UDP)
• Streams audio
• Flow chart on next page

42
(No Transcript)
43
PCM Server

• Just as readable as with other APIs (e.g. Qt)
• No preprocessor statements (besides includes)
• 350 Lines
• Platform specific implementations at least 2-3
  times larger

44
PCM Client

• Streams PCM data from server
• Single-threaded
• Networked (TCP and UDP)
• Uses jtkmediaAudioDevice (sound card access)
• Flow chart on next page

45
(No Transcript)
46
PCM Client

• Very concise and readable
• No preprocessor statements (besides includes)
• 250 Lines

47
Future Work

• Compiler Optimizations
• Extend/Enhance JTK
• New programming environment
• Common API across platforms ()

48
Conclusions

• Even though OOP is popular, imperative
  programming habits stick around
• Cores and routers are innovative and helpful
• Readability is (near) optimal
• Code sharing is (near) optimal

49
QA