Från desktop- till mobilmiljö Riktlinjer för att skriva enkelt översättbar programkod

Transkript

1 Från desktop- till mobilmiljö Riktlinjer för att skriva enkelt översättbar programkod Mikael Månsson Magnus Tingne Lunds Tekniska Högskola Lund 15 maj 2008

2

3 SAMMANFATTNING Sammanfattning Dagens mobiltelefoner har kamera, mp3-spelare och videospelare. Det är naturligt att undra hur pass kraftfulla telefonerna blivit. Numera kan man fylla i tidrapporteringen eller läsa e-post på mobiltelefonen på väg till eller från jobbet. Behovet av att kunna använda desktopapplikationer på mobiltelefonen har vuxit fram under senare år. I det här examensarbetet har vi undersökt hur pass kraftfulla vanliga mobiltelefoner är samt hur olika applikationer på desktop- och mobilsystem är. Det visar sig att mobiltelefonerna fortfarande inte är kapabla att köra desktopapplikationer och med hänsyn till detta har vi arbetat fram programmeringsriktlinjer för att slippa behöva skriva om all programkod då applikationer utvecklas med avsikt att användas både på desktop- och mobilsystem. Vi har utfört tester för beräkningskapacitet på olika mobiltelefoner, jämfört dem med desktopsystem och bedömt lämpligheten för serverbaserade beräkningar. Slutligen har vi presenterat användningen av riktlinjerna i form av en exempelapplikation. Abstract The mobile phones of today have cameras, mp3-players and video players. It s only natural to wonder how powerful these phones have become. Now it s possible to complete the time report form or read on the way to or from work. The need of beeing able to use computer applications on the mobile phone has emerged in the last years. In this thesis we have examined how powerful ordinary mobile phones are and how much the applications on desktop and mobile system differ. It appears that the mobile phones still aren t capable of running desktop applications. Considering this we created programming guidelines describing how to write an application without having to rewrite all the code when developing applications intended for use on both desktop and mobile systems. We have performed tests for calculation capacity on different mobile phones, compared it to desktop systems, and determined when server based calculations are appropriate. Finally we have presented the use of the guidelines in the form of an example application. I

4 FÖRORD Förord Detta examensarbete kom till då författarna under sitt sökande efter ett examensarbete kom i kontakt med Johan Pihlgren på Cybercomgroup AB. Johan hade en idé som efter diskussioner med LTH godkändes som examensarbete och arbetet påbörjades. Arbetet har till största delen utförts på Cybercomgroup ABs kontor i västra hamnen i Malmö under perioden oktober 2007 till mars Vi vill tacka våra handledare, Johan Pihlgren på Cybercomgroup AB och Per Holm på LTH, samt alla som hjälpt till med att korrekturläsa detta dokument. Vi vill också tacka Fredrik Hansson och Filip Johansson för deras värdefulla synpunkter vid deras opponering på vårt arbete. - Magnus Tingne & Mikael Månsson, Malmö den 15 maj II

5 INNEHÅLL Innehåll 1 Inledning 1 I Kort presentation av Java 3 2 J2SE - Java 2 Platform, Standard Edition 3 3 J2ME - Java 2 Platform, Micro Edition Användargränssnitt Screen Canvas Begränsningar i MIDP jämfört med Swing Säkerhet Förverifiering Tillstånd och skyddsdomäner Paketering Java Archive Java Application Descriptor Permanent lagring Record Stores File Connection PIM Skillnader i API:t mellan J2SE och J2ME 9 5 Java på mobiltelefoner i framtiden Sun planerar att avveckla J2ME Android och Dalvik virtual machine Java på Apple:s Iphone MIDP Användargränssnitt LIBlets Flera MIDlet:ar Tillståndet Pausad tas bort JavaFX Mobile II Försök 16 6 Jämförelse av beräkningskapacitet mellan dator och mobiltelefon Hårdvara Primtalsteoremet Metod Resultat Analys III

6 INNEHÅLL Kurvanpassning Gränsvärden Uppkoppling III Riktlinjer 22 7 Skriva kod som är enkel att översätta Begränsad hårdvara Opålitliga, långsamma nätverk Mindre feltoleranta användare Använd serverbaserade beräkningar Separering av icke återanvändbar och återanvändbar kod Dela upp logik och användargränssnitt Model/View/Controller-arkitektur Designmönster - Observer Implementation av MVC med hjälp av Observer/Observable Flytta ut filhantering så långt som möjligt Designmönster - Facade Filhantering IV Applikation: Cybercom Contact List 36 9 Presentation av applikationen Kommunikation Synkronisering Sökning Titta på en kontakt Lägga till en kontakt i telefonboken och ringa en kontakt Begränsningar i funktionaliteten Många kontakter Begränsad informationsmängd Flera kontakter med samma namn Övrigt Användning av riktlinjer Databasåtkomst med hjälp av designmönstret Facade Filhantering med hjälp av designmönstret Facade Uppdelning av användargränssnitt och logik Skillnader i koden Sockets Bilder Vector String IV

7 INNEHÅLL V Slutsatser Slutsatser Begränsningar och framtida arbete Återanvändning av kontrolleraren vid användning av MVC Optimera applikationen Prova J2SE till J2ME-översättare Relaterade arbeten A Framework for Developing Wireless Mobile Online Applications Mobile Police Information System Based on Web Services Architectures for Web Services Access from Mobile Devices Developing Java-AWT Thin-Client Applications for Limited Devices samt Toward Seamless Migraton of Java AWT-Based Applications to Personal Wireless Devices Slutlig diskussion VI Appendix 49 A Java-kod 49 A.1 Observer/Observable A.1.1 Observer.java A.1.2 Observable.java Referenser 51 V

8 1 INLEDNING 1 Inledning Fler och fler använder mobiltelefonen för e-post, kalender, tidrapportering och andra interaktiva tjänster som tidigare utförts på datorn. Mobiltelefoner har idag mp3-spelare, kamera och videospelare och de liknar mer och mer vanliga datorer. Det händer att användaren önskar ta med sig datorprogrammet i mobilen och jobba vidare på tåget. Kanske vill han fylla i sin tidrapportering eller ändra ett möte i kalendern. Syftet med detta examensarbete är att undersöka hur pass olika dagens desktopsystem och mobiltelefoner är ur programmerarens synvinkel och att ta fram riktlinjer för hur programmeraren bör programmera för att kunna återanvända så mycket kod som möjligt då desktopprogrammet önskas användas på en mobil plattform. Kanske är telefonerna så pass kraftfulla att det går att köra samma kod som desktopsystemen använder direkt? Vad bör man tänka på då programmet ska finnas för både desktopklienter och mobilklienter som troligtvis kommer dela på samma information i en databas? För att begränsa det stora området har vi valt att inrikta oss på utveckling med Java, dels för att antal javaprogrammerare växer världen över, framför allt inom mobiltelefonin, och dels för att Javas tema Write once, run everywhere möjliggör ett mycket stort utbud av plattformar, både på desktopsystem och mobiltelefoner. De flesta av dagens mobiltelefoner stödjer Java. Rapporten vänder sig främst till J2SE-utvecklare som önskar migrera till den mobila plattformen. De böcker vi funnnit i ämnet är faktaböcker om de olika Java-versionerna. All övrig information har vi hämtat från Internet och mobiltillverkare. Problemet med att använda Internet som källa är att artiklar, bloggar m.m. inte alltid är fullt pålitliga. Det är inte alltid man vet vem författaren är eller vad syftet med artikeln är. Vi har försökt sträva efter objektiv information och har alltid försökt styrka innehållet genom att hitta alternativa källor som påstår samma sak. Vi har försökt använda oss av kända källor i så lång utsträckning som möjligt, såsom Sun Microsystems eller IBM, men även den största självständiga sidan Javaworld, som innehåller en ofantlig mängd artiklar för Javaprogrammerare. Javaworld anger alltid författare, ofta med en liten biografidel, till artikeln vilket höjer förtroendet. Då vår erfarenhet inom Javaprogrammering till största delen fanns inom utveckling för desktopmiljö började vi med att lära oss mer om utveckling på mobiltelefoner med Java. Den naturliga fortsättningen blev att undersöka skillnaden mellan beräkningskapaciteten för mobiltelefoner och desktopsystem för att se hur kraftfulla de var. Vi gjorde utförliga test både med serverbaserade beräkningar och utan. Därefter började vi undersöka och ta fram riktlinjer för utveckling på de små enheterna. T.ex. om vad man bör tänka på för att utnyttja minnet och processorkraften bättre. Efter detta skrev vi riktlinjer för hur återanvändbar och icke återanvändbar kod bör delas upp för bästa återanvändning av kod. För att kontrollera våra riktlinjer utvecklade vi en exempelapplikation, en intern kontaktlista för företaget Cybercomgroup AB, avsedd för användning både på desktopsystem och mobiltelefoner. Kontaktlistan använde sig av gemensam information från en databas. Slutligen undersökte vi vad som troligtvis kommer ske i framtiden med Java på mobiltelefoner. Rapporten är uppdelad i fyra delar. Först kommer en kort presentation av Java där 1

9 1 INLEDNING Java kort introduceras med en lite längre genomgång av Java Micro Edition. Därefter presenteras skillnaderna i versionernas API och slutligen ett kapitel om vad som troligtvis kommer ske i framtiden med Java på mobiltelefoner. Den andra delen handlar om vårt försök där beräkningskapaciteten mellan dator och mobiltelefon jämförs. Här testas även lämpligheten för serverbaserade beräkningar. Efter ett försök kommer riktlinjer för vad man bör tänka på vid utveckling av desktopapplikationer som kommer att översättas till mobilapplikationer. Detta är dels är ett resultat av försök och dels av litteraturstudier. Den sista delen är en presentation av vår exempelapplikation där det går att läsa om hur teorin kan utnyttjas. Vi avslutar med slutsats och diskussion där vi tar upp egna erfarenheter samt en diskussion kring begränsningar i vårt arbete och några relaterade arbeten. 2

10 2 J2SE - JAVA 2 PLATFORM, STANDARD EDITION Del I Kort presentation av Java Java är ett objektorienterat programspråk som skapades av bl.a. James Gosling under första halvan av 90-talet. Det speciella med Java var att det hade inbyggt stöd för objektorientering, var plattformsoberoende samt säkert i det avseende att programmen kördes i en egen avspärrad sandlåda. Java använder en virtuell maskin som kör Javabytekod. Detta för att bland annat uppnå plattformsoberoende. Minneshanteringen är automatiskt med hjälp av en skräpsamlare 1, som rensar upp alla objekt med förlorade referenser. I slutet av 2006 blev Java licensierat som öppen källkod och i december 2007 flyttade Sun källkodshanteringen av vad de nu kallar OpenJDK från företaget TeamWare till Mercurial, detta skedde i samband med att den släpptes till öppen källkodgrupper. För tillfället är OpenJDK baserat på JDK version 7.0 av Java-plattformen. Java har alltid varit gratis att ladda ner och använda, men den gamla licensen har begränsat distribution och förändring. Till exempel har det hindrat Java från att skickas med många Linuxdistributioner och troligtvis har det då undvikits av utvecklare som endast vill arbeta med fri källkod. Java idag är uppdelat i tre versioner anpassade för tre olika plattformar. Java ME, Java Micro Edition, används i mindre inbyggda system som till exempel mobiltelefoner. Java SE, Java Standard Edition, används för desktop- och klientapplikationer. Java EE, Java Enterprise Edition, används till avancerade server-applikationer. Java EE och Java SE skiljer sig inte så mycket, EE bygger på SE och innehåller en mängd extra inbyggda ramverk som löser vanliga problem inom avancerade serverapplikationer. ME är en mycket nedskalad delmängd av SE och skiljer sig avsevärt när det gäller användargränssnitt. I det här examensarbetet har vi fokuserat på att återanvända kod vid övergång från desktopsystem till mobila system och tittar först och främst på SE- och ME-versionerna. 2 J2SE - Java 2 Platform, Standard Edition Standardversionen av Java är utvecklat av JCP 2 och är uppe i version 6 (Mustang). Ett brett API erbjuds med standardpaket för strömmar, filhantering, I/O, språk, användargränssnitt m.m. Användargränssnitten använder Swing (eller gamla AWT), en samling rutiner och komponenter för att rendera ett eget gränssnitt utan att utnyttja det underliggande operativsystemets GUI-stöd. Nästa version, version 7 (Dolphin) planeras släppas i januari 2009 [12]. 1 Garbage Collector 2 Java Community Process 3

11 3 J2ME - JAVA 2 PLATFORM, MICRO EDITION 3 J2ME - Java 2 Platform, Micro Edition J2ME är Java med en optimerad runtimemiljö anpassad för små enheter. Små enheter kan t.ex. vara personsökare, mobiltelefoner, pda:er eller digitaltvboxar. Micro Edition använder sig av konfigurationer, profiler och tilläggs-api för att anpassa programmet till målplattformen. Konfigurationen bestämmer vilken Java Virtual Machine (JVM) som används samt ett urval grundläggande API:er. Här bestäms oftast även minsta tillgängliga mängden minne (både ROM och RAM). Det finns två konfigurationer, Connected Device Configuration (CDC) och Connected Limited Device Configuration (CLDC). CDC används för större enheter som digitaltvboxar medan CLDC används till mindre enheter med mycket begränsat minne och begränsad nätverksuppkoppling. Profilerna utgör en samling av API:er för utveckling på den valda plattformen. På mobiltelefoner är Mobile Information Device Profile (MIDP) den vanligaste. MIDP finns i två versioner, 1.0 och 2.0. Version 3.0 är under utveckling. Efter profilnamnet kallas programmen för MIDlet:ar. Eftersom inte alla telefoner erbjuder all funktionalitet ligger vissa implementationer som exempelvis blåtand i ett tilläggs-api istället för i profilen eller konfigurationen. Java Micro Edition är egentligen en nedskalad version av Java Standard Edition och innehåller samma funktionalitet i begränsad omfattning. Tanken med detta är att det ska gå att skriva samma program för både mobila plattformar och för desktopsystem. De största skillnaderna mellan J2SE och J2ME ligger i användargränssnitt och filhantering. 3.1 Användargränssnitt I detta avsnitt kommer vi att presentera de största skillnaderna mellan att utveckla ett användargränssnitt i J2ME (mer specifikt MIDP) och i J2SE (med Swing 3 ). Det finns huvudsakligen två olika sätt att skapa det som skall visas på skärmen Screen Alternativ ett är att använda klasser som ärver från klassen Screen på ungefär samma sätt som man lägger in t.ex. knappar i ett Swing-gränssnitt. Screen har fyra subklasser: Alert Form List Textbox Form är den mest avancerade av dessa och kan innehålla Item:s, t.ex. StringItem (motsvarande JLabel) eller TextField (motsvarande JTextField) etc. 3 Det vanligaste GUI-toolkit:et i J2SE 4

12 3 J2ME - JAVA 2 PLATFORM, MICRO EDITION Canvas Det andra alternativet är att rita själv genom att ärva från Canvas och implementeras dess paint(graphics g)-metod vilket ger tillgång till Graphics där det finns metoder för att rita allt från linjer till text. Motsvarande sätt att rita fritt i Swing är att antingen skapa ett JPanel-objekt (det går med vilket objekt som helst som ärver från JComponent men JPanel är det mest grundläggande med bara en bakgrund) och anropa dess getgraphics()-metod eller att på samma sätt som i MIDP genom att ärva en JComponent och implementera paint(graphics g) Begränsningar i MIDP jämfört med Swing Eftersom mobiltelefoner har en mycket begränsad yta att rita sina komponenter på så fungerar inte layouthanteraren på samma sätt i MIDP som den gör i Swing (där man för övrigt kan bestämma layouthanterare för sina komponenter, t.ex. FlowLayout som är den grundläggande). I MIDP är principen inte att lägga komponenter (mer eller mindre) exakt där de önskas utan snarare att säga att den här komponenten vill jag ha och låta telefonen själv bestämma hur det blir [28]. På detta sätt förloras principen att javaapplikationer skall se likadana ut oberoende av plattform men det är en uppoffring som får göras för att underlätta utveckling för varierande skärmstorlekar och färger etc. En annan effekt av varierande skärmstorlekar är att man måste vara försiktig om man ritar med hjälp av Canvas eftersom det finns risk att det som ritas inte får plats på alla mobiltelefoners skärmar, och därmed kan de drabbade användarna inte se den information som är utanför. Om detta sker måste man implementera egna rullningslister. Risken att rita utanför finns visserligen i Swing också men normalt är skärmstorleken så stor att det inte brukar vara ett problem. Om man vet att det bara är höjden som kommer att bli ett problem kan man välja att istället för att använda Canvas skapa ett CustomItem och placera detta i en Form. Då kommer vertikala rullningslister att skapas om komponenten inte får plats på höjden. Exempel 3.1 Användargränssnitt i J2ME Antag att vi har ett enkelt användargränssnitt i J2SE med en JButton-knapp med texten Tryck och en JLabel. När man trycker på denna knapp kommer det en Alert som säger att etikettens kommer text att ändras när du trycker på OK. När OK trycks försvinner Alert:en och en ny text visas på etiketten. Motsvarande i J2ME hade varit en Form innehållandes ett StringItem som har ett Command (knappkommando) med texten Tryck. Trycker man på denna knapp visas en ny Displayable, nämligen en Alert som säger samma som Alert:en i J2SEprogrammet. När OK trycks slussas man vidare till nästa Displayable som i detta fall är en ny Form innehållandes ett StringItem med den nya texten 3.2 Säkerhet För att kunna köra ett program på en mobil plattform får programmet inte kunna sprida virus över den trådlösa uppkopplingen, dels för att det skulle bli dyrt, men även förö- 5

13 3 J2ME - JAVA 2 PLATFORM, MICRO EDITION dande för alla uppkopplade. Programmet ska helst inte kunna behandla den personliga informationen hur som helst, och inte kunna använda uppkopplingen hur som helst, då denna oftast kostar pengar. Dessutom ska inte program få lov att styra andra program, detta kommer dock att ändras i MIDP3.0 (se 5.4). Detta har man lyckats uppnå med Java och MIDlet:ar genom att låta en MIDlet:s livscykel kontrolleras av applikationshanteraren. Det går inte att anropa exit() för att avsluta eller exec() för att köra externa processer. En MIDlet är strikt förbjuden att gå utanför JVM:ens gränser. Innan en MIDlet får köra går den igenom en förveriferingsprocess där alla förbjudna åtgärder leder till att programmet inte får startas. Detta gör det omöjligt att anropa kod i andra MIDlet-svitar (programbunt) Förverifiering I J2SE utförs en bytekod-verifiering innan klassfiler laddas. Verifieringen förhindrar program som modifierar JVM:en att laddas. Eftersom minnet oftast är tämligen begränsat för J2ME-applikationer har denna process delats upp i två delar. Den första delen körs på utvecklingsmiljön (vanligtvis ett desktopsystem) där alla klassfiler kontrolleras och skickas vidare till den andra delen, som är betydligt mindre och lättare. Denna del utförs på själva enheten och körs då klasserna laddas. Om en klassfil inte blivit förverifierad laddas den inte Tillstånd och skyddsdomäner MIDlet:ar måste ha tillstånd att exekvera känsliga operationer. Det är fritt att definiera tillstånd (permissions) för att skydda känslig funktionalitet. Det enda som kräver ett fördefinierat tillstånd är nätverksanslutningar. Det går att kontrollera att en metod har tillstånd att exekvera med hjälp av ett anrop till en metod i MIDlet-klassen. Denna kan generera en fråga till användaren om han vill tillåta metoden att köra. Det finns två typer av tillstånd: Tillåtna tillstånd och användartillstånd. Den sistnämnda är av typen där användaren måste tillfrågas. Den finns i tre varianter: Blanket, som innebär att användaren endast behöver svara en gång för hela Midletsviten Session, som innebär att användaren behöver svara en gång per invokation Oneshot, där användaren måste svara varje gång tillståndet behövs En viss MIDlet-svit tillhör en skyddsdomän, och denna bestämmer vilka tillstånd som är uppfyllda, ej uppfyllda samt för vilka användaren måste tillfrågas. Det finns en standarddomän som kallas den otillförlitliga domänen, där det enda kravet är att användaren måste frågas för HTTP och HTTPS anslutningar. [28] Det går även att lägga in en lista av tillstånd som krävs för att MIDlet:en ska köras eller överhuvudtaget installeras i JAD eller JAR-filen. Se avsnitt för mer information. 6

14 3 J2ME - JAVA 2 PLATFORM, MICRO EDITION 3.3 Paketering En MIDlet-svit är en samling MIDlet:ar och består av två filer. Den ena är Applikationsdeskriptorn, JAD, och den andra är ett arkiv, JAR, som innehåller alla klassfiler och resursfiler för sviten. *.jar-filer en *.jar-fils innehåll *.jad-fil Figur 3.1: En MIDlet-svit inuti Java Archive En JAR-fil är ett helt vanligt komprimerat arkiv av filer byggt på Zip-tekniken. Arkivet innehåller alla klassfiler, bilder och ljud som används och information som behövs för att köra MIDlet:en. Denna information finns i en manifestfil. Filen är uppbyggd av namn:värde par. Ett exempel på ett Chatprograms MANIFEST.MF: Manifest-Version: 1.0 MIDlet-1: Chat, Chat.png, Chat MIDlet-Name: Chat MIDlet-Version: 2.0 MIDlet-Vendor: Moon Microsystems Created-By: 1.4.2\_04 (Sun Microsystems Inc.) MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-2.0 7

15 3 J2ME - JAVA 2 PLATFORM, MICRO EDITION Följande attribut finns tillgängliga, endast de sex första krävs, resten är valfria: MIDlet-Name: MIDlet-svitens namn. MIDlet-Version: MIDlet:ens version. Godtyckligt versionsnummer (x.x.x). MIDlet-Vendor: Tillverkarens namn. MIDlet-n: Detta attribut finns för varje MIDlet i sviten. Innehåller displaynamn, ikonfilnamn samt klassnamn. Ikoner måste vara i png-format. MicroEdition-Configuration: Beskriver J2ME-konfigurationer som denna MIDletsvit kan köra på. MicroEdition-Profile: Beskriver J2ME-profiler som denna MIDlet-svit kan köra på. MIDlet-Description: MIDlet-svitens beskrivning. MIDlet-Icon: Ikonen för hela MIDlet-sviten. MIDlet-Info-URL: Används för att hänvisa till ytterligare information på webben. MIDlet-Data-Size: Antal bytes MIDlet-sviten kräver. MIDlet-Permissions: Ange tillstånd som krävs för MIDlet:en här. MIDlet-Permissions-Opt: Tillstånd som kan användas men inte krävs av MIDlet:en. MIDlet-Extensions: Tilläggs-API:n som krävs. JAR-filen kan också bli digitalt signerad [42]. I så fall finns signaturinformationen i manifestfilen. Varje fil i arkivet listas tillsammans med dess kontrollsummor. Det är kontrollsummorna som är signerade. Då Javaruntime:en laddar klasser laddas endast de vars signaturer är giltiga Java Application Descriptor Attributen i JAD-filen används för att enheten eller användaren ska kunna bestämma om MIDlet-sviten ska laddas eller ej. Applikationsdeskriptorn är en fil utanför JARpaketet och är därför snabb och lätt att läsa och undersöka individuellt utan att själva arkivet laddas ner. Attributen är i stort sett de samma som i JAR-filens manifestfil, dock innehåller JAD-filen minst två ytterligare attribut: MIDlet-Jar-URL, URL:en till JAR-filen för MIDlet-sviten samt MIDlet-Jar-Size, JAR-filens storlek i bytes. En annan funktion med applikationsdeskriptorn är möjligheten att lägga till applikationsspecifika attribut. T.ex. skulle en URL kunna läggas in som: Chat.url: Inuti MIDlet:en kan man sedan komma åt värdet med hjälp av ett anrop till getappproperty() i MIDlet-klassen, t.ex.: String url = getappproperty("chat.url"); I det fall då URL:en behöver ändras räcker det att ändra i applikationsdeskriptorn, och använda samma JAR-fil som tidigare [31]. Detta är en stor fördel då MIDlet:en distribuerats till många användare. 3.4 Permanent lagring Permanent lagring innebär data som inte försvinner då programmet avslutas. Datan försvinner endast då programmet tar bort den eller då programmet tas bort. I J2SE finns möjligheten att skriva på fil, även hela objekt, med hjälp av serialisering. ME:s tillvägagångssätt skiljer sig lite från SE:s eftersom det finns så många olika typer av 8

16 4 SKILLNADER I API:T MELLAN J2SE OCH J2ME hårdvara i enheterna. Den vanligaste av lagringsmetoderna är att använda så kallade Record Stores, som egentligen är små databaser. Det går även att lägga bilder etc. direkt i JAR-filen och komma åt dem med hjälp av en InputStream. Det går dock inte att skriva filer till JAR-filen på samma sätt Record Stores En Record Store är som sagt en liten databas som innehåller små bitar data som kallas poster (Records). Dessa databaser är mycket små. Det går att sätta in, läsa, söka och sortera poster. Det är dock inte en relationsdatabas och det går inte att använda SQL. Den minsta möjliga posten är endast 8 kb, och det gör detta väldigt optimerat för små mängder data. Egentligen består en post endast av en bytevektor. Det lättaste sättet att lagra information är att utnyttja String-klassen eller en ByteArrayOutputStream för att generera bytevektorer. Varje post, som kan liknas vid en rad i en konventionell databas, har ett unikt id, vilket kan liknas vid en autoinkrementerande primärnyckel. Förfrågningar till databasen sker genom klassen RecordEnumeration som filtrerar ut det som efterfrågas. En Record Store kan även delas mellan flera olika MIDlet-svitar File Connection Moderna telefoner har ofta stora inbyggda minnen för att lagra bilder, filmer och musik, men de kan också erbjuda möjligheten att använda ett externt flash-kort (SD, Compact Flash, Memory Stick) som extra minne. Då man arbetar med flera GB data så är Record Stores väldigt ineffektiva, och därför har man utvecklat ett tilläggs-api som tillåter användaren att se minnesutrymmet i form av ett vanligt filsystem, med kataloger och filer. Det som skiljer sig i hanteringen från desktopsystem är att det finns möjlighet att deteketera att nya filsystem ansluts eller tas bort. Användaren kan sätta in eller ta bort minneskort när som helst, vilket påverkar tillgängligheten [28] PIM PIM 4 data är personlig information som telefonnummer, namn, e-postadress, händelser o.s.v. [28]. Informationen sparas i PIM-databaser. I ME är PIM tillgängligt via ett tilläggs-api och representeras av flera så kallade PIM-listor. I varje lista finns PIMföremål som innehåller den personliga informationen. Oftast existerar redan hanterare av dessa data för enheten (exempelvis den inbyggda telefonboken i en mobiltelefon), men det går utmärkt att hantera informationen i en egen MIDlet. 4 Skillnader i API:t mellan J2SE och J2ME Fokus på det här examensarbetet är att hitta generella riktlinjer för hur man bör utveckla ett program för ett desktopsystem för att inte behöva skriva om så mycket kod då önskemålet finns att även kunna köra programmet på ett mindre, mobilt system. Det finns en hel del klasser i J2SE, och endast bråkdelen av dessa finns tillgängliga i J2ME, 4 Personal Information Management 9

17 4 SKILLNADER I API:T MELLAN J2SE OCH J2ME ofta med nedskalad implementation för att vara anpassade för de små enheterna. Det som finns kvar att arbeta med i CLDC 1.1 är: java.lang Här finns i stort sett alla de vanliga klasshöljena för primitiva datatyper (t.ex. Integer, Long) samt String och StringBuffer. Viktiga systemklasser som System, Object och Class finns här. Systemklasserna skiljer sig något från de i standardversionen. Det finns ingen finalize()-metod i Object. Denna anropas för ett objekt precis innan det blir uppstädat av Garbage Collectorn, och i denna är det lämpligt att städa upp och frigöra resurser som använts. Reflektion stöds inte, vilket tex. RMI 5 kräver. Det finns dock tilläggs-api för att få RMI och därmed JINI 6 funktionalitet. Det finns ingen möjlighet att ladda klasser dynamiskt under körning, dvs. genom att skriva sin egen klassladdare. Detta går ej pga. säkerhetskäl i CLDC. Applikationshanteraren som kör MIDlet:ar har en egen klassladdare som ej går att modifiera eller ens använda utifrån. Runtime erbjuder i stort sett bara metoder för att ta reda på hur mycket minne som programmet använder. Det går inte att anropa externa processer med metoden exec(). System erbjuder faktiskt en outputström som kan användas för att skriva ut på en konsol då man kör med emulator. På en telefon finns oftast ingen konsol, och därför saknas också inputströmmen. Klasser: Runnable, Boolean, Byte, Character, Class, Double, Float, Integer, Long, Math, Object, Runtime, Short, String, StringBuffer, System, Thread, Throwable java.io Eftersom målplattformen inte är ett desktopsystem så är oftast input/output inte densamma. Många av klasserna från SE är bortplockade. Konceptet lokala filsystem finns ej i CLDC och därför har alla klasser som har att göra med filhantering tagits bort. Som sagt sker filhantering med hjälp av Record Stores, File Connection eller PIM. Serialisering av objekt är inte tillgängligt. Det går alltså inte att skriva ett objekt på en ström. Det går att komma åt resursfiler från JAR-filen med hjälp av metoden: getresourceasstream() som ligger i klassen Class. Man får då tillbaka en InputStream. Klasser: DataInput, DataOutput, ByteArrayInputStream, ByteArrayOutputStream, DataInputStream, DataOutputStream, InputStream, InputStreamReader, OutputStream, OutputStreamWriter, PrintStream, Reader, Writer. java.util Util i J2SE innehåller många användbara hjälpklasser som plockats bort pga. deras omfattande storlek. Mest drabbade är Collection-klasserna. 5 Remote Method Invocation. - Tillåter metoder att köras av en annan, avlägsen JVM 6 JINI - Utnyttjar RMI för att möjliggöra kraftfulla distribuerade system 10

18 5 JAVA PÅ MOBILTELEFONER I FRAMTIDEN Collection-API:t är borttaget, dock så finns fortfarande Vector, Hashtable och Stack kvar. MIDP använder klasserna Timer och TimerTask för att starta en tråd vid ett visst tillfälle. Det finns ett generöst utbud av klasser för att hantera tid och datum. Date beskriver en tidpunkt, Calender räknar fram dagar, minuter o.s.v. och TimeZone representerar olika tidszoner. Klasser: Enumeration, Date, Hashtable, Random, Stack, Timer, TimerTask, TimeZone, Vector. java.microedition Detta paket finns endast i ME och innehåller för CLDC endast klasser för att kommunicera över nätverk. Den kvarvarande funktionaliteten som innebär avancerad nätverkskommunikation finns i MIDP. I MIDP finns även ett fullständigt API för att skriva användargränssnitt för små enheter. Det skiljer sig dock avsevärt från SE:s AWT och Swing för anpassning av de små skärmarna. Klasser i CLDC: Connection, ContentConnection, Datagram, DatagramConnection, InputConnection, OutputConnection, StreamConnection, StreamConnectionNotifier, Connector 5 Java på mobiltelefoner i framtiden 5.1 Sun planerar att avveckla J2ME James Gosling, Suns vice VD, berättade i en presskonferens att Sun försöker driva utvecklingen mot en enkel monolitisk version av Java [39]. Idag är fragmentering största problemet med Java Mobile. Fragmenteringsproblemet uppstår p.g.a. Java Mobiles begränsningar som kräver en massa tillägg för att få den extra funktionalitet som de flesta mobiltillverkare kräver. Detta leder till att ingen utvecklare kan få någon garanti att ett program som fungerar på en mobil kommer att fungera på en annan. Detta drabbar Javas tema write once, run anywhere. We re trying to converge everything to the Java SE specification. Cell phones and TV set-top boxes are growing up. berättade James Gosling. I april 2007 köpte Sun SavaJe [44], som hade lyckats att i stort sett få J2SE att köra på en mobiltelefon. När Sun nu äger implementationen är de ett steg närmare sitt mål och vill försöka få alla att så småningom övergå till J2SE. Genom att få alla att köra standardversionen av Java som innehåller den mesta funktionaliteten undviks fragmenteringen och översättningsarbete mellan mobila applikationer och desktopapplikationer blir minimal. Själva övergången tror sig Gosling själv kommer ta ca 10 år. Ett mellansteg på vägen är Suns nya JavaFX Mobile som baseras på dels Java ME, Java SE och SavaJe. 11

19 5 JAVA PÅ MOBILTELEFONER I FRAMTIDEN 5.2 Android och Dalvik virtual machine Android är en mjukvaroplattform för mobila enheter baserat på Linux och är utvecklat av Google och Open Handset Alliance [7]. Plattformen tillåter utvecklare att skriva kod i Java som utnyttjar Google-utvecklade mjukvarubibliotek men stöder inte program utvecklade i native kod. Det intressanta med Android är att den innehåller en egen tilläggsmodul; Android Java SDK som innehåller en virtuell maskin (Dalvik Virtual Machine, DVM) för att köra J2SE program på den mobila plattformen. DVM är registerbaserad och är optimerad för att köra med låga minneskrav. Genom att låta den virtuella maskinen förlita sig på det underliggande operativsystemets processisolering, minneshantering och stöd för trådar tillåter DVM att man kör flera instanser av den virtuella maskinen samtidigt. Det är inte helt korrekt att kalla DVM för en virtuell Javamaskin eftersom det inte är Javabytekod som exekveras. Då class-filerna genererats av en J2SE-kompilator konverteras dessa med ett verktyg till Dalviks körbara filer:.dex. Många ser ett problem [20] med att Android inte kommer använda sig av standard Java, eftersom det kommer ge upphov till ytterliggare fragmenteringsproblem. Program skrivna till Android kommer endast att fungera på Android. Det kan vara svårt att se varför någon skulle vilja skriva mjukvara som endast fungerar till en telefon och för att sporra utvecklarna har Google utlyst ett pris värt 10 miljoner dollar [4] till det bästa programmet vid utgivning. Android använder sig varken av Swing eller AWT för användargränssnitt utan istället sitt eget grafikpaket som bygger på OpenGL ES. Det finns bl.a. färdigt stöd för att spela upp de flesta mediafiler m.m. Google har satsat mycket på att göra det enkelt för programmerarna och ett färdigt API och ett utvecklarverktyg (plugin till Eclipse) med emulator finns tillgängligt för nedladdning. Ett enkelt HelloWorld-program i Android Java fins i kodexempel 5.1. Kodexempel 5.1 HelloWorld i Android Java import android.widget.textview; public class HelloAndroid extends Activity { /** Called when the activity is first created. */ public void oncreate(bundle icicle) { super.oncreate(icicle); TextView tv = new TextView(this); tv.settext("hello, World"); setcontentview(tv); 5.3 Java på Apple:s Iphone Apple:s VD Steve Jobs sa nej till både Java och Flash för itouch och iphone eftersom han ansåg att de inte håller måttet när det gäller energisnålhet m.m. för enheterna [29]. Endast en dag efter att Apple släppt sitt utvecklingstoolkit beslöt sig Sun för att själva 12

20 5 JAVA PÅ MOBILTELEFONER I FRAMTIDEN implementera en virtuell maskin till plattformarna. Den virtuella maskinen kommer vara en variant av Java Micro Edition men optimeras för iphone för att kunna utnyttja dess finesser. 5.4 MIDP3.0 Den största utmanaren till Android tros bli den nya versionen av MIDP, MIDP3.0 [37]. Den utvecklas av en expertgrupp bestående av 71 företag med Motorola i spetsen [38]. Den introducerar en del nya saker jämfört med de tidigare versionerna. Vi kommer här presentera ett urval av dessa ändringar. Då MIDP3.0 inte finns ute på marknaden än är den enda källan till information om denna den specifikation som finns ute för allmän granskning samt diverse bloggar där personer har tolkat vad de nya sakerna kommer att betyda. Vi hänvisar intresserade läsare till specifikationen om de vill ha en mer utförlig beskrivning än vad vi presenterar här, specifikationen finns i [34] Användargränssnitt Ändringar i användargränssnittet är de ändringar som märks tydligast för användaren och det kommer komma en del förbättringar i användargränssnittet i MIDP3.0. Några exempel är: Flikar Det kommer att finnas inbyggt stöd för flikar i den nya Screen-klassen TabbedPane. Varje flik innehåller en Screen vars innehåll visas då fliken är vald. Kommandon läggs antingen till i de separata flikarna eller i TabbedPane-skärmen och om samma kommando finns i båda två kommer det bara att visas en gång. Flikarna visas med antingen en ikon eller en text som beskriver vad den innehåller. Hur användaren navigerar i flikarna är upp till implementationen av applikationen men den måste ha stöd för både horisontell (för att byta flik) och vertikal (för att bläddra i flikinnehållet) navigering. Utökad kontroll över kommandon I MIDP3.0 kommer det kunna styras var kommandon placeras på ett mer noggrant sätt än i MIDP2.1. I tidigare versionen kunde man tipsa mobiltelefonen om var man ville att de skulle placeras genom att tilldela dem en viss typ och en prioritet. I MIDP3.0 kommer det kunna anges mer exakt genom att få tillgång till vilka placeringar som är möjliga och kan sätta kommandon till att använda dessa platser. Utöver de vanliga programmerbara knapparna som används i MIDP2 kommer man också kunna att tilldela kommandon till en del fysiska knappar om detta tillåts av mobiltelefonen. Till exempel kan programmet eventuellt få tillstånd till att ändra vad som händer när man trycker på bakåtknappen som finns på de flesta mobiltelefoner. En annan ny sak inom kommandona som tillkommer är underkommandon. Det kommer gå att skapa ett menysystem bland de programmerbara knapparna med hjälp av den nya klassen Menu som är en subklass till Command. Som exempel kan vi tänka oss en ett menysystem med en programmerbar knapp som får alternativen: Exit och Send Via. Om man bläddrar till Send Via får man de nya valen: Bluetooth och SMS. 13