4. Concept of Applications

4. Concept of Applications • What constitutes an application? • Design process • Example • Packaging applications • Symbian OS application development • Summary

So What Is an Application? • In an abstract sense: • A piece of software that something specific and useful? • Set of programs? • Someting that gives device more capabilities? • Runs on top of underlying specific hardware and infrastructure software? • Technically: • Bootstrap? • Simple main() ? • A class implementing certain predefined methods that override platform’s methods? • A collection of classes that form a complex configuration? • A combination of executables and other files (e.g. graphics, auxiliary data files, etc)? • Something else, what?

App code App code App code App code Application and Software Stack Application Facilities - Applications- UI and application specific libraries • Middleware • Communications stacks • - Abstract access to lower-level facilities • Low-level Software • Kernel • - Device drivers

App code Or only simply….? Application Facilities - Applications- UI and application specific libraries • Middleware • Communications stacks • - Abstract access to lower-level facilities • Low-level Software • Kernel • - Device drivers

Concern: Depth of Integration • Independent applications that share nothing are simple to implement • Applications share data • Common format; should one app’s extensions be understandable by another app? • Applications share (library) code • Common facilities can be reused relatively safely • Applications are intertwined • E.g. a MMS can be sent from different applications • Common infrastructure interface; sometimes menu items that should be generated on-the-fly, ... • Sometimes features can be difficult to associate with some particular application (themes, ringing tones, ...) • Complexity increases in both design and testing

Concern: Application priority • Application priority determines how important a certain application is • Implemented with threads and thread priorities • Thread priority determines how responsive a thread is when it is running • However, starting a thread can be slow • If rapid actions are needed, one must have the thread already running • Keeping the most important applications (or related infrastructure) constantly running? • Especially if some resources are required, they can also be reserved in advance • Saving data when an application is shut down? Or saving data more often so that applications can be shut down at any phase of the execution? Automatic shutdown of low-priority applications? • Further testing challenges as more and more combinations enabled!

Concern: Usability • Importance demonstrated by e.g. CACM theme issue (5 articles) • 3 dedicated to usability, user experience, design involving users, etc. • 2 with wider focus • Consistency of user experience and differences to workstation usage patterns • Short duration • Focused actions • No long-lasting sessions • Complexity in interaction design • Can be considered a design driver, at least indirectly • Adequate performance • Practical to perform common tasks, whereas rarely needed properties can be harder to perform • Also related to application priorities and depth of integration • May be predefined for an independent application developer

Content and goals • What constitutes an application? • Design process • Example • Packaging applications • Symbian OS application development • Summary

Scoping Performance management UI design Memory layout and data structures Communication and I/O Workflow

Scoping • Fundamental purpose of the application • What it does • What it does not • For a mobile version of a workstation application, a subset of features to be selected • Relative priority to be given to features; the priority will then guide the development iteratively • Priority should therefore be based on the importance of the feature to the user • Easiness of activities performed seldom can be compromized • Scoping can be helped with paper protos, mock-ups, or running prototypes

Importance of Performance • General responsiveness metrics needed (how fast an application starts, shuts down, opens file, etc) • Forces to consider sequences of events that occur when the user performs an action • Test all assumptions with a real device; do not trust the emulator • Start with key features, then advance to less critical ones • Assume that more will be expected in the future • Use e.g. an old hardware platform for less capable executions • Focus on real bottlenecks, not on the ones that one can most easily find or fix • It is the overall performance that counts • Rule of thumb: Start with data structures, their layout in memory, algorithms, UI design

User Interface Design • Study key use cases and features that characterize the application • Scoping as already discussed • Innovations that can be device or application specific • End-user productivity gained with the designed interface (ease-of-use) • End-user responsiveness (the feel of being in control) • The device keeps the user informed and does not halt at random times • Fooling the user • Problems • Tendency to repeat actions if seemingly nothing happens • Device specific design of UI • Small screen, clumsy keyboard • ”One size fits all” vs. application-specific features and devices

Data Model and Memory Concerns • Data representation bears great significance to memory consumption • Disk or memory? • Static vs. dynamic? • Stack vs. heap? • Implementation techniques can also have an effect to this • Dynamically linked libraries and the necessary loading facilities • Virtual machine and its implementation • Inheritance and virtual function table • Applied design patterns • Methodology used in the development • …

Communication and I/O • Local (e.g. files) and remote resources (e.g. services offered by a server in a network) to be considered • Local access is usually relatively fast • Remote access commonly introduces a longish round-trip time • Level of abstraction in communication significant • binary streams -> text streams -> XML forward only readers and writers -> XML document object model • Also affects development time • Costs of a connection • Download a lot of data when WLAN is available, use local proxy when only GPRS can be used

Content and goals • What constitutes an application? • Design process • Example • Packaging applications • Symbian OS application development • Summary

Scoping Performance management UI design Memory layout and data structures Communication and I/O Workflow

Scoping

Scoping .... Cont’d • Calendar entries • Reminders • Contacts • Day-week-month view • Import/export (synchronization) • Lunar phase • Connectivity/group features • Time zones • Repeated events • Overlapping treatment • Public holidays • Automatic meeting coordination • ”Date” operations

Performance • Implementation of a mock-up • First build for a real device • Also tested with the device

UI Design

Data Structure?

I/O and Communication • Server Synchronization? • On the fly update with e.g. SMS? Or only pull when the user has suitable connectivity access?

Content and goals • What constitutes an application? • Implementing applications • Example • Packaging applications • Symbian OS application development • Summary

Developmentworkstation Source code Device runnable Cross-compilation Emulatorcompilation Packing Mobile device Emulator Download Emulator runnable Device installable Device runnable Packaging Applications + Auxiliaries

Problem: How to deliver? • Users of mobile devices may not have a computer readily available • Delivery of applications should therefore not be based on loading an application from web to a host computer and then download it to the device • Over-the-air delivery of applications • Long loading times • People may not realize the trustworthiness of the download site • What happens if the phone is flashed? • Memory cards • What if the device type changes? • Issues related to digital rights management • Can the application be copied? • How about auxiliaries?

Technical Implementation • Platform-specific installation packages • Java: JAR; Midlet suite • Symbian: SIS • Windows: CAB • Linux: DEB • Installation managers implemented in devices can control installation at installation-time • Certificates for controlling who is responsible for implementation • Signing programs common (e.g. Symbian Signed) • User can usually override • Platform specific security schemes to prevent unauthorized access to device’s resources at run-time • Sandbox security (Java) • Capability based security (Symbian)

Createprojectdefinition file Build foremulator Debug Create makefile/workspace Done Run ok? no yes no yes Code Build fordevice Run ok? Process

AppArch CApaDocument CApaApplication UI Control Framework CCoeEnv CCoeControl CCoeAppUi CEikonEnv CEikAppUI CEikDocument CEikApplication Eikon/Uikon Application CExAppView CExAppUI CExDocument CExApplication Application Structure

Device (type) Specific Features • Many, if not all, platforms define a wrapper layer that inherits CEik* and from which CMy* must be inherited • Series 60 -> CAkn* • Qkon -> CQkn* • Can lead to confusing problems as forgetting the wrapping layer can result in compilable applications that fail in execution • Example: An application crashes when opening a menu • Challenge: How to implement systems that are portable between devices offering similar yet different facilities

Sample Application

Auxiliary Files and Definitions • Project Definition File • Application Definition File • Resource File • Version information • Default file name for saving application data • Menu structure of the application • Constant strings to ease localization • UI and Panic related constants • *.HRH • *.PAN

DLL Entry Point // DLL entry point, return that everything is ok GLDEF_C TInt E32Dll(TDllReason /*aReason*/) { return KErrNone; } EXPORT_C CApaApplication* NewApplication() { return (new CQAApplication); }

… or an EXE(depending on Symbian version) LOCAL_C CApaApplication* NewApplication() { return new CQAApplication; } GLDEF_C TInt E32Main() { return EikStart::RunApplication(NewApplication); }

CQAApplication class CQAApplication : public CAknApplication { public: // from CApaApplication TUid AppDllUid() const; protected: // from CEikApplication CApaDocument* CreateDocumentL(); }; CApaDocument* CQAApplication::CreateDocumentL() { // Create QA document, and return a pointer to it CApaDocument* document = CQADocument::NewL(*this); return document; } TUid CQAApplication::AppDllUid() const { return KUidQAApp; // Return the UID }

CQADocument class CQADocument : public CAknDocument { public: static CQADocument* NewL(CEikApplication& aApp); static CQADocument* NewLC(CEikApplication& aApp); ~CQADocument(); CEikAppUi* CreateAppUiL(); CQAEng* Model(); private: void ConstructL(); CQADocument(CEikApplication& aApp); CQAEng * iModel; }; CEikAppUi* CQADocument::CreateAppUiL(){ CEikAppUi* appUi = new (ELeave) CQAAppUi; return appUi; }

CQAAppUi class CQAAppUi : public CAknAppUi { public: void ConstructL(); CQAAppUi(); ~CQAAppUi(); void HandleCommandL(TInt aCommand); // from CEikAppUi private: CQAAppView* iAppView; CQAEng* iModel; }; void CQAAppUi::HandleCommandL(TInt aCommand) { switch(aCommand) { case EQAAsk: iModel->Reset(); iAppView->DrawNow(); break; case EQAAnswer: iModel->Select(); iAppView->DrawNow(); break; case EAknSoftkeyExit: case EQAQuit: Exit(); break; default: User::Panic (_L("QandA"), EQABasicUi); break; } }

CQAAppView class CQAAppView : public CCoeControl { public: static CQAAppView* NewL(const TRect& aRect); static CQAAppView* NewLC(const TRect& aRect); ~CQAAppView(); void SetModel(CQAEng * aModel); void Draw(const TRect& aRect) const; // from CCoeControl private: void ConstructL(const TRect& aRect); CQAAppView(); CQAEng * iModel; };

CQAEng class CQAEng : public CBase { public: static CQAEng* NewL(); // Two-phase constructor. ~CQAEng(); // Destructor. TPtrC Question(); // Reference to current question. TPtrC Answer(); // Reference to current answer. void Select(); // Allows one to answer to a question. TBool Used(); // Identifies whether the answer is visible. void Reset(); // Defines new question and and answer. protected: void ConstructL(); // Constructors. CQAEng(); private: // All questions and answers implemented as arrays. CDesCArrayFlat * iQuestions, * iAnswers; // Current question and answer are indices to the arrays. TInt iQuestion, iAnswer; TBool iUsed; // Identifies if the answer has been selected. };

Generating an Installation Package ; qanda-simple.pkg ; ;Language; standard language definitions &EN ; standard SIS file header; application name and id. #{"qanda-simple"},(0x01005b97),1,0,0 ;Supports Series 60 v 0.9 (0x101F6F88), 0, 0, 0, {"Series60ProductID"} ; Files to copy; Application and compiled resource file. "..\..\..\epoc32\release\armi\urel\qanda-simple.APP" -"C:\system\apps\qanda-simple\qanda-simple.app" "..\..\..\epoc32\release\armi\urel\qanda-simple.rsc" -"C:\system\apps\qanda-simple\qanda-simple.rsc"

Summary • Application concept is fundamentally about connecting new (application specific) features to the existing device infrastructure • Application priority is affected by • the importance of keeping the application in execution • the priority of threads used for implementing the application • Five principal topics form the guideline for application design • Scoping • Performance • Proper UI design • Internal data representation • Communication model • Symbian solution: Collection of matching classes

4. Concept of Applications