1 / 30

UI Environments

UI Environments. J2ME .NET Compact Framework nods to: Shwetak Patel, Heather Mahaney, Gillian Hayes. Agenda. UI Environments J2ME .NET Compact Framework HW 3. Intro to J2ME. J2ME – Java 2 Micro Edition Introduced by Sun in 1999 for mobile devices Scaled down version of J2SE

fallon-pittman
Download Presentation

UI Environments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UI Environments J2ME .NET Compact Framework nods to: Shwetak Patel, Heather Mahaney, Gillian Hayes

  2. Agenda • UI Environments • J2ME • .NET Compact Framework • HW 3

  3. Intro to J2ME • J2ME – Java 2 Micro Edition • Introduced by Sun in 1999 for mobile devices • Scaled down version of J2SE • Smaller footprint • No heavyweight classes • (swing, awt, etc) • Highly optimized runtime environment

  4. J2ME Architecture • KVM - Kilobyte Virtual Machine • 40 – 80 KB in size • For devices with 160 KB of memory and 16 or 32-bit RISC/CISC microprocessors OEM Specific API

  5. J2ME Architecture (cont.) • CLDC - Connected Limited Device Configuration • Provides core lower level functionality • Bare minimum IO and utilities • Currently consists of java.io, java.lang, java.util, java.microedition.io OEM Specific API

  6. J2ME Architecture (cont.) • MIDP – Mobile Information Device Profile • MIDP provides the core application functionality for mobile devices • Network connectivity, data storage, and user interfaces OEM Specific API

  7. J2ME Architecture (cont.) • OEM Specific API • Access to proprietary features and functionality • Audio system, camera, lighting system, etc OEM Specific API

  8. J2ME Programming Environment • Sun provides IDE for the “generic” java-enable mobile phone • Most mobile phone companies like Motorola or Nokia have their own IDEs

  9. J2ME Applications • A J2ME app is called a Midlet Midlet life cycle

  10. J2ME UI • MIDP provides some limited UI elements • Form • Alert • Choice and ChoiceGroup • List • StringItem • TextBox • TextField • DateField • Guage • Ticker

  11. J2ME UI vs J2SE UI • MIDP UI elements ARE NOT subsets of AWT/Swing • Interaction with the user is based around a succession of screens • MIDP only has a single command listener

  12. J2ME Canvas • J2ME does allows lower level access to the Canvas • Can create custom graphics and user interfaces by extending Canvas

  13. Lightweight Window Toolkit • Motorola introduced the LWT to address the limitation of MIDP • Works on all Java-enable mobile phone • Similar to J2SE Swing • Layout management with absolute or relative widget placement • Notion of containers • Component Listeners

  14. LWT Hierarchy

  15. Sample J2ME Applications

  16. .NET Compact Framework

  17. .NET Compact Framework Design Goals • Target mobile and embedded devices • Portable subset of .NET Framework • No new ‘compact’ namespaces • Visual Basic .NET & C# compiler support in v1 • Leverage Visual Studio .NET • Run managed .EXEs and .DLLs directly • Debug with Visual Studio .NET • Peacefully co-exist with host OS • Run on native threads, P/Invoke to call native code

  18. Other Differences • Class libraries are a subset (about 25%) • Different size and scalability characteristics • Compact Additions • IrDA support • SQL Server CE managed classes (not available on CF for SmartPhones) • Device-specific controls

  19. Framework Size • Framework size • 1.35MB (ROM) on Windows CE .NET Device • Each application runs its own instance of the Framework; there is no pooling at this time. • Running RAM needs • 1 MB+ (depends on app) • Typical application sizes • 5 - 100 KB • Apps often smaller due to use of platform features in the framework

  20. System.Web System.Windows.Forms • Services • Description • Discovery • Protocols • UI • HTML Controls • Web Controls Design Component Model System.Drawing Cache Security Drawing 2D Printing Configuration Session State Imaging Text System.XML System.Data ADO.NET SQL Client XML Document Serialization Design SQL ServerCE Xslt/XPath Reader/Writers System Collections IO Configuration • Runtime • Interop Services • Remoting • Serialization Security Net Service Process Text Reflection Diagnostics Globalization Resources Threading .NET Compact Framework

  21. Base: Networking • Sockets • Synchronous and asynchronous • Multiple protocols • Streams • Built on top of sockets • Synchronous and asynchronous • HTTP request and response • Use stream model • Requires no user knowledge of HTTP Applications .NET Compact Framework Web Services HTTP Request/Response, Network Stream Sockets Common Language Runtime

  22. Base: Threading • Applications start with an initial thread • Applications can start new threads • Using threads • Responsive UI • Program function segregation • Thread synchronization primitives • App domains exist until all threads exit

  23. Base: Native Code InterOp • Managed  native (P/Invoke) • Calls into existing native code • .NET Compact Framework does marshalling of arguments • Native  managed • P/Invoke and block • MessageWindow Class • Native code can indicate events and transfer data to managed code via message pumps • Microsoft.WindowsCE.Forms.MessageWindow

  24. Windows Forms Support • Great for Rapid Prototyping on Pocket PC • Layout • Manual positioning • Drawing • Polygons, lines, arcs, ellipses, rectangles • JPEG, BMP images • Text and images • TrueType bitmap fonts on Mobile • Most desktop controls • Designer support

  25. HW 3: Starting your IDF • Starting an Interface Division Framework • You’re now going to start generalizing the work you did for HW 2

  26. HW 3: Two major parts • Part I: Support for Initiating Division • You must create a library for applications that: • Provides an interface and functionality for initiating communication with an interface generator • Provides at least two general purpose interactors that applications can instantiate to allow end users to choose how to divide the interface • Manages communication to and from the interface generator

  27. HW 3: Two major parts • Part II: Interface GeneratorYou must generalize the mechanism you created for HW 2 to support a wider variety of interface divisions. Your interface generator should: • Accept a semantic description of the components, including their attributes and desired layout, to include in the interface • This semantic description should be kept in a file separate from your application code • Support at least 3 types of layouts, and at least 7 types of components. • Provide mechanisms for returning information from the interface generator when requested by either the generated interface or the original application

  28. HW 3: Using the Framework • Update your email application to use your framework • Create a simple application that demonstrates your 3 layouts and 7 components

  29. Foreshadowing • HW 4: Adding support for behaviors • HW 5: Allowing users to choose desired interface division and associated behaviors • HW 6: Create a new application using your framework

  30. Next Time • Midterm!

More Related