2.1 Komando-lerroko interfazea

Komando-lerroko interfazea edo komando-lerroko aginte-interfazea (ingelesez: command-line interface, CLI) ordenagailu baten erabiltzaile-interfaze mota bat da, erabiltzaileei programa informatiko bati edo sistema eragileari aginduak emateko aukera ematen diona testu-lerro sinple baten bidez.

CLIak modu interaktiboan erabil daitezke, testu-sarrera motaren batean aginduak idatziz, edo askoz modu automatizatuagoan (batch fitxategia), script-fitxategi batetik aginduak irakurriz.

Interfaze hau ia konputazioaren hasieratik existitzen da, antzinatasunean soilik txartel zulatuak eta antzeko mekanismoek gaindituta. Ordenagailuek “terminal tontoak” konektatuta zituzten, eta horien bidez aginduak bidaltzen zitzaizkien ordenagailuari.

Gaur egun, komando-lerroa “terminal emulatzaile” izeneko programekin erabiltzen da, eta horiek komando-interprete bat (shell izenekoa) exekutatzen dute. Interprete hauek, sistema eragilearen arabera, aukera desberdinak izan ditzakete, adibidez:

• Windows-en cmd zaharra edo berriagoa eta hobetua den PowerShell erabil daitezke. Beste batzuk ere erabil daitezke, baina ez daude lehenetsita instalatuta (adibidez bash).

• GNU/Linux sistemetan gehien erabiltzen den interpretea eta banaketa gehienetan instalatuta dagoena bash da. Azken urteetan zsh-k merkatu asko irabazi du Oh-my-zsh frameworkari esker.

• MacOS sistemetan interprete lehenetsia zsh da.

CLI, shell eta terminal emulatzaile kontzeptuak ez dira gauza bera. CLI paradigma bati egiten dio erreferentzia, eta shell edo terminal emulatzaileak programa informatiko espezifikoak dira, normalean elkarrekin CLIa inplementatzen dutenak. Hala ere, hirurak sinonimo gisa erabiltzen dira askotan.

2.2 Erabiltzaile-interfaze grafikoa

Erabiltzaile-interfaze grafikoa, GUI izenez ere ezaguna (ingelesez graphical user interface), erabiltzaile-interfaze gisa jarduten duen programa informatiko bat da, gaur egun irudi eta objektu grafiko multzo bat erabiliz interfazean eskuragarri dauden informazioa eta ekintzak irudikatzeko.

Bere funtzio nagusia ingurune bisual erraza eskaintzea da, ordenagailu baten sistema eragilearekin komunikazioa ahalbidetzeko.

2.2.1 Testu moduko interfazea

Interfaze grafikoak ez dira mahaigaineko inguruneekin jaio, baizik eta aurreko urratsetan ere badaude leihoak edo inguruneak simulatzen dituzten liburutegiak, testu-karaktereak eta koloreak erabiliz.

Kontuan izan behar da interfaze hauek baliabide oso gutxiko makinetan eta interfaze grafikorik ez zuten sistema eragileetan erabiltzen zirela normalean.

2.2.2 Lehen ikerketak eta garapenak

Doug Engelbartek Stanford Research Institute-n (Menlo Park, AEB) 60ko hamarkadan egindako “Giza Adimenaren Handitzea” proiektuak oN-Line System garatu zuen, saguarekin kontrolatutako kurtsorea eta hipertextuarekin lan egiteko hainbat leiho zituen sistema.

Hasierako ikerketa asko ume txikiek nola ikasten duten aztertzean oinarritu zen. Horregatik, diseinua eskuko eta begiaren arteko koordinazioaren oinarrizko mugimenduetan oinarritu zen, komando-hizkuntzak erabili ordez.

GUIa hasieran Xerox PARCen (Palo Alto Research Center) garatu zuten Alan Kay, Larry Tesler, Dan Ingalls eta beste ikertzaile batzuek. Leihoak, ikonoak eta menuak erabiltzen zituen, lehen menu desplegable finkoa barne, fitxategiak ireki, ezabatu eta mugitzeko aginduak onartzeko.

1981ean Xeroxek produktu berritzaile bat aurkeztu zuen, Star izenekoa, PARCen berrikuntza asko txertatuz. Ez zen arrakasta komertziala izan, baina Star-ek etorkizuneko garapenetan eragin handia izan zuen, adibidez Apple, Microsoft eta Sun Microsystems-en.

1979an, Steve Wozniak, Steve Jobs eta Jef Raskin buru zituen taldeak (Xeroxeko langile ohiekin batera) Xerox PARCen ikusitako ideiekin jarraitu zuten eta 1983an “Apple Lisa” ordenagailua merkaturatu zuten, interfaze grafikoa zuen lehen ordenagailua. Ez zen salmentetan arrakastatsua izan, baina “mahaigaineko sistema eragileak” deitu daitezkeen garaiaren hasiera izan zen.

1984an Applek Macintosh kaleratu zuen, Lisa sistemaren eboluzioa zuen sistema eragilearekin, “System” izenekoa, eta bertan gaur egun arte ia aldatu ez diren atal batzuk ikus daitezke.

Hurrengo urtean, Microsoftek Windows 1.0 kaleratu zuen, MS-DOS sistema eragilerako GUI bat, baina ez zen 1990eko Windows 3.0 bertsiora arte bere ospea lehertu.

2.3 Mahaigaineko erabilera masiboa

1990eko hamarkadaren etorrerarekin, ordenagailu pertsonalak (PC, personal computer ingelesez) ezagun bihurtu ziren eta etxeetara eta enpresetara iristen hasi ziren, eta horrek ezagutza aurreraturik ez zuten erabiltzaileen merkatua sortu zuen, erabilera erraztasuna behar zutenak.

“Boom”a Windows 3.11-rekin hasi zen, baina batez ere Windows 95-ekin, sistema eragilearen nukleoa (MS-DOS) ezkutatzea lortu zuen eta hasieratik interfaze grafikoa zuzenean erakusten zuen.

Applek NeXT (Steve Jobsek sortutako enpresa) erosi zuen eta bere sistema eragilea Mac OS 8-ren oinarri gisa erabili zuen. Ondoren, sistema eragilearen arkitektura UNIX estilokoa bihurtu zuten eta horrela Mac OS X aurkeztu zuten 2001ean.

Urte hauetan eta 2000ko hamarkadaren hasieran, erabiltzaile-interfazeak eboluzionatzen joan ziren ordenagailuen potentzia handitzen zen heinean, baina beti mahaigaineko benetako ingurunea simulatzen jarraituz.

GNU/Linux munduan Gnome eta KDE bezalako mahaigaineko ingurune libreak iragarri ziren, paraleloan eboluzionatu zutenak eta ia “gerra” bat sortu zuten haien artean eta erabiltzaileen artean (1. esteka, 2. esteka).

Sistema eragile bakoitzak eta mahaigaineko sistema bakoitzak bere eboluzio propioak egiten zituen, eta arrakasta izanez gero, besteetan “kopiatzen” ziren, kolore, ikono edo leiho-efektuetan “modak” sortuz ere.

2.4 Web-interfazeak

90eko hamarkadaren amaieran eta 2000ko hasieran, interneten gorakadak web atariek ere euren interfazeetan eboluzio handia izatea ekarri zuen.

Kontuan izan behar da garai hartako HTML eta CSS bertsioak ez zirela gaur egungoak bezain aurreratuak, eta javascript-en exekuzio-aukerak ere ez zirela gaur bezain indartsuak. Interfazeak teknologiak berak mugatu zitzakeen

Bestalde, ohikoa da enpresaren irudia aldatzea, logotipo, kolore korporatibo, koloreen modaren arabera… eta horrek guztiak interfazeetan aldaketak eragiten ditu.

2.5 Mugikor-interfazeak

Telefono mugikorren kasuan, bistaratze-sistema estandarrik ez zegoenez, fabrikatzaile bakoitzak bere interfaze propioa sortzen zuen pantailak handitzen, bereizmena eta koloreak handitzen ziren heinean.

Lehen mugikorrek ez zuten pantailarik, gero pantaila txiki monokromoak izaten hasi ziren, batzuetan testu-lerro bakarrarekin.

Ondoren, koloretako pantailak izaten hasi ziren eta enpresa bakoitzak bere sistema eragilea sortu zuen. Enpresa askoren artean sistema eragile bat sortzeko saiakera bat izan zen Symbian, baina azkenean Nokia izan zen garatzailea eta gehien erabili zuena.

2000ko hamarkadaren lehen urteetan PDA-ak (personal digital assistant, poltsikoko ordenagailuak) ere modan jarri ziren, normalean pantaila ukigarri (erresistiboa) bat erabiltzen zutenak eta boligrafo batekin erabiltzen zirenak.

Dena aldatu zen 2007an iPhone-a eta lehen smartphone-ak iritsi zirenean, pantaila ukigarri kapazitiboek (hatzez erabiltzen direnak) protagonismoa hartu zuten. Pantaila hauek, ukigarriak izateaz gain, hainbat hatz erabiliz keinuak egiteko aukera ematen dute, interfazearekin elkarreragiteko modu berriak sortuz.

Applek botoi bakarra aukeratu zuen, eta Android sistema eragileek (adibidez HTC Desire 2009koa) gutxienez lau botoi zituzten sistemako eta unean erabiltzen ari zen aplikazioko funtzio batzuk kudeatzeko.

Aldaketa hauekin, sistema eragileek eta interfazeek aldaketa erradikal bat jasan zuten, erabiltzailearen erraztasuna bilatuz eta interfazearekin elkarreragiteko “keinuak” agertuz:

• Tap: pantaila ukitzea (saguarekin “klik” egitearen antzekoa)
• Double tap: ukitu bikoitza, aplikazioaren arabera zoom bat egin dezake.
• Scroll: hatzarekin gora edo behera arrastatuz interfazean mugitzea.
• Flick: keinu azkarra gora edo behera eginez scroll egiten da; ezkerrera edo eskuinera eginez, mugimendua pantaila gehiagorik badago horren araberakoa izango da.
• Pinch in: zooma gerturatzea.
• Pinch out: zooma urruntzea.

Honekin guztiarekin, orain arte interfazeetan planteatu ez zen “arazo” berri bat sortzen da: gailuaren biraketa. Biraketa horrek aplikazioa egokitu behar du terminalaren posizio berrira, bertikaletik horizontala edo alderantziz pasatuz.

Gailu hauen eboluzioarekin tablet-ak sortu ziren, keinu filosofia bera jarraituz, baina pantaila handiagoek informazio gehiago erakusteko aukera ematen dute. Mahaigaineko interfazeak erabili ordez, mugikorretako interfazeak eboluzionatu ziren.

Leku gehiago dagoenez, ez dira mugikor-aplikazioak “eskalatzen”, baizik eta interfazeek menu edo informazio gehiago gehitzeko aukera dute.

2.6 Errealitate birtuala eta errealitate areagotua

Interfazeen garapenaren hurrengo urratsa errealitate areagotuan (augmented reality) eta errealitate birtualean dago. Nahiz eta orain modan dauden terminoak diruditen, haien ikerketa eta eboluzioa hamarkadak daramatza garatzen.

Lehen urratsak “head-up display” izenekoetan eman ziren, erabiltzaileari informazioa aurkezten dioten pantaila gardenak, pantailaren atzean dagoena ikusten uzten dutenak. Horrela, erabiltzaileak ez du burua biratu behar informazioa lortzeko.

Batzuetan pantaila hau erabiltzailearen eta aginte-panelaren artean egon daiteke, aginte-panelera integratuta edo pilotuaren kaskoan eta begiaren ondoan jarrita.

Bestalde, errealitate birtuala dugu, erabiltzaileari ingurune simulatua eskaintzen diona, bertan mugi daiteke eta batzuetan inguruko elementuekin elkarreragin dezake.

Horretarako, ohikoa da betaurreko batzuk erabiltzea ingurune birtuala erakusteko, eta aginte batzuk edukitzea ingurunearekin elkarreragiteko.

Ingurunean mugitzeko, sistema batzuek trackers erabiltzen dituzte, horrela ingurune birtualean mugi gaitezke aginteak erabili gabe.

Hurrengo urratsa errealitate areagotua da, non elementu birtualak bizitza errealean integratzen saiatzen diren. Ez da berria, urteak daramatza joko eta aplikazioetan existitzen.

Errealitate areagotua eguneroko erabilerarako izan dadin, sistemak pixkanaka eboluzionatzen hasi dira, nahiz eta kostua oraindik altua izan. Gaur egun, ez dago argi zein izango den bere onura eta errendimendua.

Apple Vision Pro kasuan, errealitate areagotuko esperientzia bat agintzen dute, eskuen keinuak erabiliz interfazean mugitzeko.

4.1 Bi ereduen arteko desberdintasunak

Zein sistema aukeratu erabakitzerakoan, bakoitzean dugun ezagutzaren araberakoa izango da, baina jarraian taula konparatibo txiki bat erakusten da:

• XML:
  • Abantailak:
    • Kontzeptuen bereizketa: Ikuspegia eta logika argi bereizten dira
    • WYSIWYG editorea: Android Studiok editore bisual bat du, ikuspegiaren osagaiak kokatzeko aukera ematen duena. Garatzaile batzuentzat intuitiboagoa izan daiteke. WYSIWYG = What You See Is What You Get.
    • Birziklapena: XML txantiloi/layoutak sor daitezke, hainbat activityetan erabil daitezkeenak.
  • Desabantailak:
    • Mugatua: Interfaze konplexuak sortzerakoan, XML formatuak muga batzuk ditu eta Java/Kotlin kodearekin konpondu behar dira.
    • Verbosity: XML fitxategiak konplexuak eta errepikakorrak izan daitezke. Horrek ikuspegi konplexuak mantentzea zaildu dezake.
• Jetpack Compose
  • Abantailak:
    • Sintaxi deklaratiboa interfaze konplexuak sortzea errazten duena
    • Tipatze segurua: Kotlin kodea denez, tipatze-akatsak eta exekuzioan erroreak izateko aukera murrizten da.
    • Modularitatea: Jetpack Compose-k interfazeko osagai berrerabilgarriak sortzea sustatzen du. Honek aplikazioa mantentzea eta eskalagarritasuna errazten du.
    • “Live preview”: Kodean ikuspegia sortzen den heinean aurrebista ikus daiteke.
  • Desabantailak:
    • Ikasketa-kurba hasieran gogorra izan daiteke.
    • Bateragarritasuna: Gaur egun ez luke arazoa izan behar, baina soilik erabil daiteke Android 5.0 (API level 21) edo berriagoarekin.
    • Soilik Kotlin-ekin erabil daiteke.

5.1 Gure lehen proiektua sortzen

Android Studio ireki ondoren, proiektu berri bat sortuko dugu eta “Empty Views Activity” aukeratuko dugu; horrela, sortuko den proiektuak lehen ikuspegi bat izango du testu zentratua duena.

Hurrengo urratsean proiektuaren izena, bidea, programazio-lengoaia eta erabiliko dugun SDK aukeratuko ditugu. Aukeratutako aukerekin, proiektua eta beharrezko fitxategiak sortzen hasiko da aplikazioa funtziona dezan.

Ezkerreko menuan (Android aukera hautatuta) app/res/layout rutaraino zabaltzen badugu, activity_main.xml izeneko fitxategi bat dugula ikusiko dugu, eta klik eginez ikuspegi hau ikusiko dugu:

5.2 “Diseinu”, “blueprint” eta kode ikuspegia

Ikuspegiekin elkarreragitean hiru aukera izango ditugu:

• Diseinu ikuspegia: Erabiltzaileak ikusiko duenaren antzekoena da. Horrela, interfazeak dituen elementuak eta edukia ikus ditzakegu.

• Blueprint ikuspegia: “Cianotipo” edo plano ikuspegia ere deitua. Ingeniaritza planoak simulatzen ditu eta hemen elementu bakoitzaren mota bakarrik ikusiko dugu. Edukitik abstraitzeko eta diseinuan zentratzeko egokia da.

• XML kodea: Ikuspegiaren XML fitxategiaren edukia da. Testua aldatuz aldaketak egin ditzakegu. Parametro zehatz bat aldatu nahi badugu, hau da ikuspegi egokiena.

5.3 Interfazeko osagaiak

5.4 Layout-ak eta constraints-ak

Hasierako ikuspegiarekin, “Hello World!” testua hautatzen badugu, Layout atalean honako konfigurazioa ikusiko dugu:

Horrela, osagai bakoitzaren zati bakoitzak constraint bat izango du, kasu honetan, guraso layout-aren zati bati lotuta. XML fitxategiaren kodea begiratuz gero, bakoitza nola idatzita dagoen ikus daiteke:

<TextView
    android:id="@+id/textView"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Hello World!"
    app:layout_constraintBottom_toBottomOf="parent"
    app:layout_constraintEnd_toEndOf="parent"
    app:layout_constraintStart_toStartOf="parent"
    app:layout_constraintTop_toTopOf="parent" />

Interfazean botoi bat gehitzen badugu, pantailaren behealdean, zentratuta eta nahi dugun posizioan, simulagailuan exekutatzean ez da agertuko nahi genuen posizioan.

Horregatik, interfazean gehitu nahi dugun osagai bakoitzak bere constraintak izan behar ditu beste osagai edo guraso layout-arekin. Ez badugu bat gehitu edo ikuspegian zerbait ez badago ondo, interfazean honako hau agertuko da:

Osagaiak beste osagai batzuei lotuta egon daitezke, baina ez dute zertan elkarri lotuta egon. Adibidez, hurrengo ikuspegian, horizontalean honako hau ikus daiteke:

5.5 Ikuspegi bertikala eta horizontala

Gure gailuek posizioa biratu dezakete, eta beraz, pantailan agertzen diren osagaiak posizio berrira egokitu beharko lirateke.

Horregatik, interfazeak diseinatzerakoan, osagaien posizioarekin zer egin pentsatu behar dugu: posizioz aldatzen diren, ezkutatzen diren, menu gisa bihurtzen diren…

Lehenetsita, gailua biratzean, osagaiak mugituko dira konfiguratutako layout eta constraint-en arabera. Proiektua sortzean sortutako ikuspegian, gailua biratzean hau gertatuko da:

Ikus daitekeenez, “Hello World!” testua ikuspegiaren erdigunean mantentzen da, testuak interfazearekin dituen constraints-ak direla eta.

5.5.1 Ikuspegiak bereizten

Gailuaren posizio desberdinetarako ikuspegi desberdinak izan nahi baditugu, baliteke elementu guztiak ez izatea interesatzen, edo ez egotea leku berean.

Adibidez, iOS kalkulagailuak gailua biratzean aukera gehiago eskaintzen ditu, kalkulagailu zientifiko bihurtuz.

Ikuspegi bat sortzen badugu “landscape” modurako aldaketarik egin gabe, honako emaitza lortuko dugu:

Ikus daitekeenez, botoien kokapena berdina da bi ikuspegietan, baina modu horizontalean ez da erabilgarria. Emaitza ikusgarria izan arren, ikuspegiak ez luke zentzurik izango.

Aldiz, ikuspegi apaisaturako konposizio desberdina egiten badugu, emaitza hobea lortuko dugu, elementuak beste modu batean kokatuta, erabilgarriagoa izanik.

Ikuspegi bereiziak izateko, ikuspegi apaisatua sortu behar dugu dagoen ikuspegiaren gainean. Horretarako, ikuspegiaren editorean, desplegablean klik egin eta “Create Landscape Qualifier” hautatu beharko dugu.

Honek proiektuaren zuhaitzean jatorrizko ikuspegiaren izena duen karpeta bat eta bi fitxategi sortuko ditu: jatorrizkoa eta beste bat, “land” gehituta, apaisatuaren bertsioa dela identifikatzeko.

Honi esker, ikuspegi berri bat sortuko da, jatorrizko ikuspegiaren elementu guztiekin, constraints-ak mantenduz. xml fitxategi berria ikuspegi apaisatuentzako sortutako direktorioan egongo da: app/src/main/res/layout-land.

5.6 Interfazeari funtzionalitatea ematea

Android-erako programatzen nola egiten den sakondu ez arren, adibide txiki bat gehituko da botoi bat eta testu bat nola funtzionatzen duten eta elkarrekin nola elkarreragin ulertzeko.

Ideia da:

• Botoi bat eta TextView bat dituen interfaze bat sortzea.
• Botoia sakatzean, TextView-aren jatorrizko testua desagertzen da eta botoia zenbat aldiz sakatu den erakusten du.

Hau kontuan hartuta, MainActivity.kt fitxategiaren kodea honela geratuko litzateke:

//... imports previos
import android.widget.Button
import android.widget.TextView

class MainActivity : AppCompatActivity() {

    var contador:Int = 0

    override fun onCreate(savedInstanceState: Bundle?) {
        //... código ya existente

        val button:Button = findViewById(R.id.button)
        val text:TextView = findViewById(R.id.textView)

        button.setOnClickListener {
            contador = contador+1
            text.text= (contador).toString()
        }
    }
}

6.1 Sortutako ikuspegi lehenetsia ulertzen

Proiektuak sortu digun ikuspegiak hainbat atal ditu, aldaketak egiteko eta aurrebistan zer gertatzen ari den ulertzeko.

@Composable
fun Greeting(name: String, modifier: Modifier = Modifier) {
    Text(
        text = "Hello $name!",
        modifier = modifier
    )
}

@Preview(showBackground = true)
@Composable
fun GreetingPreview() {
    JetpackTheme {
        Greeting("Android")
    }
}

@Preview(showBackground = true, showSystemUi = true, 
    uiMode = Configuration.UI_MODE_NIGHT_YES)
@Preview(showBackground = true, showSystemUi = true,
    device = "id:pixel_fold")
@Preview(showBackground = true, showSystemUi = true,
    device = "spec:width=411dp,height=891dp,orientation=landscape")

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        setContent {
            JetpackTheme {
                Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->
                    Greeting(
                        name = "Android",
                        modifier = Modifier.padding(innerPadding)
                    )
                }
            }
        }
    }
}

6.2 Elementuen antolamendua

Interfazeak sortzerakoan, elementuen konposizioa/antolamendua (layout ingelesez) pentsatu behar dugu. Dokumentazio ofizialean antzeko adibide bat dago, eta gomendagarria da begiratzea.

Honako interfaze sinple hau suposatuko dugu, ezkerrean interfaze finala nola geratuko litzatekeen eta eskuinean elementuen antolamendua nabarmentzen duen irudia.

Diseinatutako antolamendua ikusita, programazio deklaratibora bihurtzerakoan sortu ditugun atal desberdinak eta osagaiak nola kokatuko diren ulertu behar dugu. Komponenteak nola kokatzen diren ulertzea garrantzitsua da.

Composer-ekin programazioan lehen iterazio bat honela geratuko litzateke. Osagaiak edukiarekin hardcodeatuta daude, eta sortutako funtzioak beti edukia bera erakutsiko du. Bordeak jarrita hobeto ikusiko genuke non hasten den osagai bakoitzak.

@Composable
fun Post() {
    Column {
        Column {
            Text("title")
            Text("subtitle")
        }
        Image(
            painter = painterResource(R.drawable.dragon),
            contentDescription = null
        )
        Text("Lorem ipsum dolor sit amet, conse...")
        Row {
            Column {
                Image(
                    painter = painterResource(R.drawable.goku),
                    contentDescription = null
                )
            }
            Column {
                Text("Author")
                Text("2024-09-01")
            }
        }
    }
}

Kodean, elementuak kokatzeko honako funtzioak erabili dira:

• Column: seme osagai guztiak sekuentzia bertikalean jartzen ditu.
• Row: seme osagaiak sekuentzia horizontalean kokatzeko.

6.3 Elementuen modifikatzaileak

Aurreko funtzioak Composer-en funtzioak erabiliz elementuak kokatzen ditu, baina interfaze atsegina eta azken emaitza lortzeko, elementu bakoitzari modifikatzaileak gehitu behar dizkiogu. Hemen erabakiko dugu “nola polit egin” interfaze hori.

Modifikatzaileak bloke mailan edo elementu mailan gehi daitezke, eta erabilitako adierazpen motarekin kontuz ibili behar da, batzuk besteek baino lehentasun handiagoa dutelako.

Modifikatzaile desberdinak gehituz, kodea honela geratuko litzateke:

@Composable
fun Post() {
    Column (
        modifier = Modifier // FALTA CÓDIGO
    ) {
        Column (
            horizontalAlignment = Alignment.CenterHorizontally,
            modifier = Modifier
                .padding(10.dp)
                .fillMaxWidth()
                // FALTA CÓDIGO
        ) {
            Text(
                text = "title",
                modifier = Modifier.padding(bottom = 15.dp)
            )
            Text("subtitle")
        }
        Image(
            painter = painterResource(R.drawable.dragon),
            contentDescription = null
        )
        Text(
            text = "Lorem ipsum dolor sit amet, conse...",
            modifier = Modifier // FALTA CÓDIGO
        )
        Row (
            verticalAlignment = Alignment.CenterVertically,
            modifier = Modifier // FALTA CÓDIGO
        ){
            Column {
                Image(
                    painter = painterResource(R.drawable.goku),
                    contentDescription = null,
                    modifier = Modifier
                        .clip(CircleShape)
                        .background(color = Color.LightGray)
                        .size(100.dp)
                        .padding(5.dp)
                )
            }
            Column (
                Modifier.padding(start = 10.dp)
            ) {
                Text("Author")
                Text("2024-09-01")
            }
        }
    }
}

Modifikatzaile desberdinak gehitu dira bai zutabe/errenkada mailan, bai azken osagai mailan. Kodea nahiko auto-azalgarria da. Adibideko kodea ez dago osorik, iruzkinak gehitu dira falta den kodea adierazteko, modifikatzaileetan ertzak marrazteko. Ertzak elementu multzo bakoitzaren antolamendua ikustea errazten dute

6.4 Ikuspegi bertikala eta horizontala

Orain arte sortu dugun adibidearekin gailua biratzen badugu, elementuen antolamendua ondo mantentzen da, baina ez dugu scroll-ik. Column osagaiak ez du scroll-a lehenetsita, beraz, modifikatzaile nagusian gehitu behar dugu:

@Composable
fun Post() {
    Column (
        modifier = Modifier // FALTA CÓDIGO
            .verticalScroll(rememberScrollState())
    ) {
        //...
    }
}

Horrela, ikuspegi horizontalean gure aplikazioak scroll izango du, zutabe nagusiari ezaugarri hori gehitu diogulako.

Bestalde, ikuspegiaren konposizioa gailua bertikalean edo horizontalean dagoenaren arabera desberdindu nahi badugu, honela egin dezakegu:

// Uneko konfigurazioa hartzen dugu
val configuration = LocalConfiguration.current

// Egoeraren arabera konposizio desberdina egiten dugu
when (configuration.orientation) {
    Configuration.ORIENTATION_LANDSCAPE -> {
        LandscapeScreenComposition()
    }
    else -> {
        VerticalScreenComposition()
    }
}

6.5 Gai pertsonalizatuak sortzea

Aplikazioa sortzerakoan interesgarria izan daiteke “gai” (ingelesez theme) pertsonalizatua izatea. “Gai” hauek aplikazioaren koloreei, tipografiari… egiten diete erreferentzia. Gai hau desberdina izango da gailua modu “argian” edo “ilunean” dagoenaren arabera.

Proiektua sortzean ui/theme izeneko direktorio bat dagoela ikusiko dugu, MainActivity.kt fitxategia dagoen bide berean. Bertan hiru fitxategi aurkituko ditugu, eta gomendagarria da haien edukia ikustea:

• Color.kt: Aplikazioan erabiliko diren koloreak dituen aldagaiak ditu. Koloreak hainbat modutan defini daitezke eta “Alpha” tartea (opakutasuna) izan dezakete. Kolore sistema propioa sor dezakegu eta hainbat rol erabil ditzakegu aplikazioan.

• Type.kt: Fitxategi honetan tipografiak, letra mota, mota, tamaina… definitzen dira. Lehenetsita hiru eskala daude (“Large”, “Medium” eta “Small”) hurrengo rolentzat:
  • Display: Pantailako testurik handiena, testu labur edo zenbakietarako. Pantaila handietan hobe funtzionatzen dute. Normalean letra “adierazgarriak”, eskuz idatzitakoak erabiltzen dira.
  • Headline: Pantaila txikiagoetan testu laburretarako egokiak. Testu pasarteak edo edukiko atal garrantzitsuak markatzeko erabilgarriak.
  • Title: Erdi-mailako garrantzia duten testu laburretarako erabili behar dira.
  • Body: Testu luzeetarako erabiltzen da. Letra oso adierazgarriak edo apaingarriak saihestu behar dira, irakurtzeko zailagoak izan daitezkeelako.
  • Label: Osagaien barruko testurako erabiltzen da. Adibidez, botoiek LabelLarge estiloa erabiltzen dute.
  Estiloen azalpena eta tipografia desberdinen adibideak hemen eta Github-eko adibide proiektu honetan.
• Theme.kt: Gaiaren fitxategi nagusia da, eta aurreko fitxategietan zehaztutakoa erabiltzen du. Proiektu berri baten fitxategiak honako hau dauka:

package com.example.jetpack.ui.theme    
//... 
private val DarkColorScheme = darkColorScheme(
    primary = Purple80,
    secondary = PurpleGrey80,
    tertiary = Pink80
)

private val LightColorScheme = lightColorScheme(
    primary = Purple40,
    secondary = PurpleGrey40,
    tertiary = Pink40
)

@Composable
fun JetpackTheme(
    darkTheme: Boolean = isSystemInDarkTheme(),
    // Dynamic color is available on Android 12+
    dynamicColor: Boolean = true,
    content: @Composable () -> Unit
) {
    val colorScheme = when {
        dynamicColor && Build.VERSION.SDK_INT >= Build.VERSION_CODES.S -> {
            val context = LocalContext.current
            if (darkTheme) 
                dynamicDarkColorScheme(context) 
            else
                dynamicLightColorScheme(context)
        }
        darkTheme -> DarkColorScheme
        else -> LightColorScheme
    }

    MaterialTheme(
        colorScheme = colorScheme,
        typography = Typography,
        content = content
    )
}

• Shapes.kt: Proiektu berri batean ez da fitxategi hau sortzen, baina adibide honetan bere edukia ikus daiteke. Fitxategi honetan aplikazioan erabil daitezkeen formak alda daitezke.

6.6 Gertaerak Compose-n

Dokumentazio ofizialak dioen bezala, Compose deklaratiboa da eta, beraz, eguneratzeko modu bakarra konposagarritasuna duen elementuari argumentu berriak pasatzea da. Argumentu hauek IU-aren egoeraren adierazpenak dira. Egoera eguneratzen den bakoitzean, berrikomposizioa gertatzen da.

• Konposizioa: Jetpack Compose-k IU-aren deskribapena egiten du konposagarritasun elementuak exekutatzean.
• Hasierako konposizioa: Konposizio baten sorrera, konposagarritasun elementuak lehen aldiz exekutatzean.
• Berrikomposizioa: Konposagarritasun elementuak berriro exekutatzea, datuak aldatzen direnean konposizioa eguneratzeko.

Compose-k jakin behar du zein egoerari jarraipena egin behar dion, eguneraketa jasotzen duenean berrikomposizioa programatu ahal izateko. Compose-k soilik aldatu behar diren funtzioak berrikompilatuko ditu. Horretarako, Compose-ren State eta MutableState motak erabiliko ditugu, Compose-k egoera behatu ahal izateko. Mutablestate funtzioak bere value eguneratu dezake egoera eguneratzeko.

Kontagailuaren adibidea egingo dugu, bere funtzioa honakoa izango litzateke:

@Composable
fun Contador(modifier: Modifier = Modifier) {
    var contador: MutableState<Int> = remember { mutableStateOf(0) }

    Surface(modifier = Modifier.fillMaxSize()) {
        Column(
            horizontalAlignment = Alignment.CenterHorizontally
        ) {
            Text("${contador.value}")
            Button(
                onClick = {
                    contador.value++
                }
            ) {
                Text("Suma!")
            }
        }
    }
}

“contador” aldagaia “MutableState” motakoa da, botoia sakatzean eguneratzen dena, eta Compose-k bere “value” eguneratu dela detektatzean, ikuspegiaren zati hori berrikompilatzen du, balio berria erakutsiz.

7.1 Egoerak XML-rekin mantentzea

Ikuspegiaren egoeren trantsizioak nola funtzionatzen duten jakinda, egoera gorde eta Activity berriro sortzean informazioa berreskuratzeko garaia da. Horretarako bi funtzio erabiliko dira:

• onSaveInstanceState : Activity-a suntsitu aurretik deituko da.
• onRestoreInstanceState: onCreate metodoa deitu eta berehala deituko da.

Aurreko adibidearekin jarraituz, botoia zenbat aldiz sakatu den gorde nahi badugu, honelako zerbait gehitu beharko genuke:

override fun onResume(){
    super.onResume()
    Log.d("Debug","onResume")
    val text:TextView = findViewById(R.id.textView)
    text.text = contador.toString()
}

override fun onSaveInstanceState(outState: Bundle) {
    // Erabiltzailearen jokoaren egoera gorde.
    outState?.run {
        putInt("contador", contador)
    }
    // Beti deitu superklaseari ikuspegiaren hierarkia gorde dezan.
    super.onSaveInstanceState(outState)
}

override fun onRestoreInstanceState(savedInstanceState: Bundle) {
    // Beti deitu superklaseari ikuspegiaren hierarkia berreskuratu dezan.
    super.onRestoreInstanceState(savedInstanceState)
    // Egoera kideak berreskuratu gordetako instantziatik.
    savedInstanceState?.run {
        contador = savedInstanceState.getInt("contador")
    }
}

7.2 Egoerak Compose-rekin mantentzea

Konposagarritasun elementuen bizi-zikloa Jetpack Compose-n desberdina da, berrikomposizioa osagai mailan egiten baita, ez ikuspegi osoan.

Aldagaien egoera berrikomposizioen artean gordetzeko, “rememberSaveable” mota erabiliko dugu. Honek gailua biratzean aldagaien balioa mantentzea ahalbidetuko digu:

@Composable
fun Contador(modifier: Modifier = Modifier) {
    var contador: MutableState<Int> = rememberSaveable { mutableStateOf(0) }
    // ...
}

“rememberSaveable” erabiliz, egoera berrikomposizioan gordetzea ahalbidetzen digu, baina jardueraren bizi-zikloak beste egoera batzuk izan ditzakeenez, ez da beti erabilgarria izango.

Egoera konplexuagoak kudeatzeko, IU egoerak nola gorde eta egoera eta Jetpack Compose dokumentazioan informazio gehiago

Aplikazioen Garapena

9.1 Elkarreraginaren diseinua

Wikipediaren arabera, elkarreraginaren diseinua (IxD laburtuta), “produktuen, inguruneen, sistemen eta zerbitzu digitalen elkarreragileak diseinatzeko jarduna” da. Definizio hau ez da soilik ingurune digitaletara mugatzen, mundu errealera ere aplika daiteke.

Laburbilduz, honela adieraz daiteke:

• Erabiltzaileak zein ekintza egin behar dituen aplikazioa erabiltzean bere helburua lortzeko.
• Ekintza horiek nola egin behar dituen.

Garrantzitsua da sistemak eraginkorrak, efizienteak eta errazak izatea erabiltzeko, bestela, gure aplikazioa ona izan arren, erabiltzaileek ez erabiltzea erabaki dezakete.

Helburua izan behar da erabiltzaileek egin ditzaketen akatsak minimizatzea, erabiltzailearen gogobetetasuna handitzea, frustrazioa murriztea eta, azken batean, pertsonen eta aplikazioaren inguruko zereginak produktiboagoak egitea.

9.2 Erabilgarritasuna

Erabilgarritasuna neologismo bat da (ingelesezko usability, erabilerraztasuna), pertsonak tresna edo objektu bat nola erraz erabil dezaketen adierazten duena. Informatikan, aplikazio, webgune, makina, prozesu… bati aplika dakioke.

Erabilgarritasuna tresna horien azterketari ere egiten dio erreferentzia, normalean garapenaren aurretik edo bitartean, horien erabilgarritasun maila zein izango den zehazteko. Horretarako, proba enpiriko eta erlatiboak egiten dira:

• Enpirikoa: iritzi edo sentsazioetan oinarritu gabe, laborategian edo eremuko lanetan egindako erabilgarritasun-probetan oinarritzen da (adibidez, erabiltzaileekin).
• Erlatiboa: emaitza ez da ona edo txarra, ezarritako helburuen edo antzeko beste sistema batzuen aldean alderatzen da.

Jakob Nielsen, bere Usability Engineering (1993) liburuan, bere “Erabilgarritasun Helburuak”en bost kalitate-osagaiak definitzen ditu:

• Ikasteko gaitasuna: Erabiltzaileek lehen aldiz diseinua ezagutzen dutenean, oinarrizko zereginak nola erraz egin ditzaketen.
• Eraginkortasuna: Erabiltzaileek diseinua ikasi ondoren, zereginak zein azkar egin ditzaketen.
• Oroimena: Erabiltzaileek diseinura itzultzen direnean denbora batez erabili gabe egon ondoren, gaitasuna nola berreskuratzen duten.
• Akatsak: Erabiltzaileek zenbat akats egiten dituzten, akats horiek zenbateraino diren larriak eta nola erraz berreskura daitezkeen.
• Gogobetetasuna: Diseinua erabiltzea zein atsegina den.

9.3 Erabiltzaile-esperientzia

Erabiltzaile-esperientzia (UX) erabiltzailearen eta ingurune edo gailu jakin baten arteko elkarreraginari dagozkion faktore eta elementu multzoa da, zerbitzu, produktu edo gailu horren pertzepzio positibo edo negatiboa sortuz.

Erabiltzaile-esperientzia kontzeptu subjektiboa da, erabiltzailearen elkarreraginarekin batera emozioak, sentimenduak eta markaren transmisioa bezalako alderdi erlatiboak ere egon daitezkeelako…

Hasiera batean, erabiltzaile-esperientziari garrantzia ematen hasi zitzaion informatikan, interneten gorakadarekin eta web orrien garapenarekin batera.

Erabiltzaile-esperientzia ona diseinatzeko, elkarreraginaren diseinu egokia eta interfaze on batetik abiatu behar dugu.

Bestalde, erabiltzaile-esperientzia erabiltzailearen aurreiritziek eta bere esperientziak ere alda dezakete: aplikazio bat beste antzeko baten moduan erabiltzen saiatzea,

9.4 Erabiltzaile-interfazea

Erabiltzaile-interfazea (ingelesez user interface, UI) erabiltzailearen eta produktuaren (aplikazioa edo zerbait fisikoa izan daiteke) arteko geruza da.

Interfaze honetan agertuko dira erabiltzaileak zuzenean elkarreragingo duen elementu guztiak. Elementu horiek gertaerak sortuko dituzte edo produktuan jarduera bat egingo dute, normalean irteera/erantzun bat sortuz.

10.1 Eskakizunen lortzea

Aurrean esan bezala, eskakizunen lortzea proiektuaren hasieran egiten da, edozein programazio mota egin aurretik. Eskakizunak lortzeko ohiko moduak hauek dira:

• Bezeroarekin elkarrizketak.
• Aplikazioa erabiliko duten erabiltzaileekin elkarrizketak.
• Lan-metodologiaren egungo egoera ezagutu eta aztertzea (baldin badute). Proiektua amaitzean, metodologia hori egokitu beharko da.

Era berean, garrantzitsua da analistak eta proiektuaren arduradunak bezeroaren lekuan jartzea, galdera egokiak egiteko eta zer egin nahi den ulertzeko.

10.2 Eskakizunen analisia

Bezeroaren informazioa jaso ondoren, eskakizunen analisia egin behar da; horrela, zalantzak sor daitezke eta, kasu horretan, aurreko urratsera itzuli.

Eskakizun motak bereizteak bakoitzaren irismena ulertzen lagunduko digu, aplikazioaren atal desberdinak kudeatzeko.

Eskakizunak aztertzerakoan, normalean taula bat sortzen da, non honako hauek adierazten diren:

• Eskakizun mota.
• Kategoria, mota desberdinen artean bereizteko.
• Lehentasuna, lehentasunaren arabera ordenatzeko eta noiz landu behar diren jakiteko.
• Mendekotasunak, izan ere, eskakizun batzuk beste batzuen menpe egon daitezke. Beraz, eskakizuna egin aurretik, mendekotasunak amaitu behar dira.
• Izenburua eskakizuna laburbiltzen duen deskribapenarekin.
• Eskakizunaren deskribapena, beharrezkoa den informazio guztia eman behar da, gero garatu ahal izateko.
• Arrazoia eskakizunaren zergatia hobeto ulertzeko.

Eskakizunak idazterakoan, bakoitzarentzat taula bat sor dezakegu honako moduan:

Kasu honetan, “Mendekotasunak” atalean ez da ezer gehitu, aplikazioaren lehen eskakizuna delako.

11.1 Datuen eredu kontzeptuala

Datuen eredu kontzeptuala egiteko, ohikoena da “Entitate-Erlazio eredua” erabiltzea, hau da, gero diseinu logikoa eta azkenik datu-basearen diseinu fisikoa egiteko abiapuntua. Hau beharrezkoa izango da datu-base erlazional bat behar badugu.

Datuen eredua aplikazio askoren oinarrizko zatia izaten da, beraz, eskakizunen bilketa zuzena izan behar da, eta datuen ereduaren diseinua ere bai.

11.2 Erabilera-kasu diagramak

Erabilera-kasu diagramak funtzionalitate bat deskribatzen dute, erabiltzaile baten eta sistemaren arteko elkarreragina konbinatuz, gertaera-sekuentzia bat osatuz.

Erabilera-kasuaren deskribapena egiten denean, zer egingo den azaltzen da, baina ez nola egingo den tekniko mailan. Adierazpen zehatzak erabili behar dira, nahasmenik ez sortzeko; horregatik, sinpletasuna eta argitasuna bilatzen dira.

Adibidez, jarraian bi adibide ikus daitezke: erabiltzaile baten erregistroa eta sisteman autentifikazioa nola irudikatu daitezkeen erabilera-kasu diagramen bidez:

Ikus daitekeenez, ekintza burutu behar denaren ikuspegi abstraktua ematen duten diagramak dira.

11.3 Nabigazio-mapa

Lortutako portaera eta elkarreragin diagramak kontuan hartuta, hurrengo urratsa aplikazioaren topologia eta funtzionalitate desberdinen arteko bideak egitea da. Lortutako emaitza aplikazioaren nabigazio-mapa izango da.

Aplikazio edo web baten nabigazio-mapak eduki nagusien arteko esteken ikuspegi orokor eta laburtua eman behar digu.

11.4 Prototipoak

Aurreko urratsak egiten diren bitartean, paraleloan aplikazioaren itxura eta interfaze-diseinua nolakoa izango den azter daiteke.

Lehen urratsetan, paper gaineko zirriborroak edo aplikazioetan egin daitezke, xehetasun handirik gabe, aurretik ikusitako diseinuekin batera. Zirriborro hauek aplikazioaren ideia orokorra osatzen hasten dira.

Eredu zehatzagoak eta errealitateari hurbilagoak egiteko, prototipo-sistemak erabiltzen dira, hau da, erraz handitu eta aldatu daitezkeen modeloak (irudikapenak, erakustaldiak edo simulazioak). Haien ezaugarri nagusiak hauek dira:

• Erabiltzaile-interfazea izaten dute.
• Sarrera/irteera eta nabigazio funtzionalitatea izan dezakete.
• Horiek egiteko hainbat tresna daude.
• Xehetasun maila desberdina izan dezakete.
• Bezeroak ikusten duena ulertzeko gai da, beraz, feedback-a azkar lortzeko bide bat da.
• Aurreko etapetan aztertu ez diren ustekabeko alderdiak ager daitezke. Beraz, eskakizunen zehaztapena hobetzen eta zehazten laguntzen du.