Kategoria: mobiili (maaliskuu 2007)

Version 0.3.2 is available, the only fix is the server password saving.

Version 0.3.1 is available. Only fixed thing is the server port setting.

Version 0.3 is available. Improvements:

• UTF-8 encoding support
• Windows 1251 encoding and decoding support (hi to all my friends in Russia!)
• customizable quit message
• /clear
• /part and /leave can be used with * to denote current channel
• nick changes are shown in windows where the user is
• quit messages shown in windows where the user is
• query windows change target nick automatically if you're on a channel with the user that changes their nick
• password for the IRC server can be set

Tuli tylsää viime viikonloppuna ja aloin naputtaa vihdoinkin IRC-asiakasohjelmaa S60:lle. Varsinkin kun nyt E61 on niin irkkaus voisi olla ihan ookoo sillä taas. PuTTY ei nappaa ihmeemmin, fontitkin rumia jne.

Joten varmaankin tänään tuossa viimeisten testien jälkeen tulee saataville ensimmäinen 3rd edille tehty IRC-asiakasohjelma. Perustoiminnot löytyy ja lisää tulee joskus. Mutta onpahan tehty.

Ja tulee 2nd edillekin jossain välissä.

Watch this space.

Tuhlasin sittenkin hetken iltaa. Muutamia ongelmia tuossa on, olin huomaavinani että T9-kirjoitus samalla kun kanavalle tulee tekstiä poistaa viimeisimmän sanan (ah ihanaa vakiokontrolleja) ja /clear puuttuu ainakin. Eikä toisten nickinvaihdot näy. Hups O:) Mutta niihin korjaus seuraavaksi heti.

Eli saanko esitellä: mIRGGI

And now there's version 0.3b available, with Windows 1251 codepage support for all my friends in Russia. Also UTF-8 sending, nick/quit messages in right windows etc. Enjoy!

Version 0.2 has been released. It contains the following functionality:

• connecting to one server
• joining channels
• query windows for private chatting
• 10k per channel/query backlog
• jumping to desired window with numpad
• ident daemon
• UTF-8 decoding
• T9 can be used
• usually needed commands implemented
• the font is small and nice (at least on tested devices)
• the memory requirements should be very small
• settings for autojoin and autoquery on connection
• will not be bloated with unneeded themes, skins, scripts, now playing -crap etc

Ihmeiden aika ei ole ohi. Forum Nokian foorumissa kysellään kehittäjiltä mitä API-funkkareita pitäisi höllentää jotta niitä voisi käyttää ilman testausta/devcertiä. Kiva. Toivottavasti oikeasti jotain tehdäänkin.

Itse olen ehdottanut jo useasti ihan uutta lähestymistapaa koko kapoihin, joka laittaisi käyttäjän päättämään eikä testitaloa, joka ei tiedä yhtään mitä softa oikeasti tekee. Tässä kommenttini foorumille.

I have made this suggestion before and will make it again: make most of the caps user grantable runtime.

What I mean is this:

When an application wants to determine the location of the user, it will use Location API. The user is presented a query "Do you allow the SW to find out your location?" and selections: No, This time, Through this SW use, Always.

This way the USER is in control. THEY will decide if they want to allow the SW to get the information.

And naturally this woul be extended to all areas: reading/writing SMS's, contact information, email, network, camera etc etc etc.

Platform security is a good idea, but the security should come fom the user. Not from some third party testing house that doesn't really know what the SW will do after a month, year, 100 executions etc. And this way you wouldn't have hundreds of disgusted developers screaming at you.

This has already been done for JVM's in many phones and it is not a hard thing to implement.

Also another thing: it is stupid that we must declare the caps in the MMP file when compiling. Think about this:

I compile a SW. I want to test it with a devcert in my device but I also want to give it out. I use e.g. Location API. Now I must compile two versions: one that has one set of caps in the MMP, sign it with devcert, then another version that has another set of caps and sign it with another cert.

Since the functions can already have return values that say "no no, you are not allowed to do this", why should we tell the caps in MMP? Just so that the user can be presented with the list in application install? Not if you did it the way I described above.

Also, it's not nice to see the list when installing. The SW can "make calls or use network." So, which is it going to do? I want to allow it to use network, but not make calls naturally. The user is quite unsure at this point. Also other caps are too broad for the user to grasp, this is why more fine separation and runtime querying would be nice.

But if you're only going to relax APIs, I too vote for at least Location and Cell ID queries to be allowed without devcert/symbian signed testing.

Pitää tässä mainita muutama ärsyttävyys mitä on S60-vakiokamassa huomannut, varsinkin kun on nyt E61:n kanssa leikkinyt:

• selain ei hyväksy urlia kirjoittaessa enteriä hyväksymiseksi vaan pitää painaa vasenta pehmonäppäintä, rasittavaa
• selain ei osaa muuntaa välilyöntejä URLissa %20:ksi vaan lähettää URLin sellaisenaan, jolloin palvelin huutaa Bad request
• selaimeen ei voi asettaa yhteysosoitteeksi ryhmää, joten pitää käyttää "Kysy aina", argh!
• selaimesta ei löydy uuden ikkunan avausta. jos sivusto avaa uuden ikkunan, näiden välillä voi kyllä sitten vaihdella. miksei omaa uutta ikkunaa voi avata vai olenko vain tyhmä?
• asentaa softan, menee heti Valikkoon, hetken päästä päivitetään ja valinta siirtyy ihan muualle kuin missä se oli. ei olisi vaikea laittaa muistiin edellistä kohtaa kun päivitetään
• IMPS-sovellus (eli IM tai Chat riippuen kielestä) ei tue kuin GPRS-yhteyksiä, WLAN anyone? operaattorinuolemista?
• E61:n sähköpostivilkkuvalon asetuksessa on vain kolme vaihtoehtoa: 2 minuuttia, 30 minuuttia, 2 tuntia. miksei vain numerokenttä johon voi valita itse montako minuuttia valo vilkkuu?
• kontaktilistasta nimeä etsiessä vasen/oikea ei liikutakaan kursoria (jotta voisi korjata jonkin kirjoitusvirheen) vaan vaihtaa tabia, pitää pyyhkiä kaikki pois viallisen kohdan jälkeen ja kirjoittaa uusiksi

Pitää päivitellä listaa kun enemmän ärsyttävyyksiä tulee mieleen tai uusia löytyy.

Niin ja se yksi todella ärsyttävä ajattelemattomuus ihmisiltä: kun laitatte softaa jakoon nettiin, miksi hitossa se pitää tunkea zippiin? Toki zippimankelin saa ladattua nyt joihinkin luureihin, mutta silti. Tilansäästöä ei tule ja estetään vain suora asennus luurista. Vieläkö väki kuvittelee että kaikki lataavat tiedostot PC:lle ja siitä tunkevat luuriin? Haloo...

Tuli tuossa tarve lähettää ja vastaanottaa dataa asynkronisesti (siis protokolla asynkroninen, itse komentojen ei tarvitsisi olla). Tuli sitten huomattua myös miten ihanaa se on Symbianilla kun kaiken mahdollisen pitää olla asynkkia.

Jos haluaa vuorotellen kirjoitella ja lukea, ongelmia ei tule juurikaan. Tietysti "aktiiviset objektit" ovat ärsyttäviä käyttää muutenkin, mutta mitään lisähankaluutta tästä ei tule. Mutta sitten jos onkin tilanne jossa kumpikin pää voi lähetellä tietoa miten haluaa, joudutaan tekemään paljon monimutkaisemmin.

Koska luku ja kirjoitus ovat molemmat asynkronisia, tarvitsee joka kutsun jälkeen asettaa olio aktiiviseksi ja odottaa viestiä valmistumisesta. Täten kun normaalisti asetetaan soketti lukemaan dataa ja kertomaan kun jotain tulee, on olio koko ajan aktiivinen. Jos samalla yrittää kirjoittaa, se onnistuu, mutta tästä tulee ihan sama eventti ja on aika hankalaa (ellei mahdotonta) erottaa oliko nyt kyseessä luku- vai kirjoituseventti.

Ratkaisu? Tehdään kaksi oliota, joista toinen lukee ja toinen kirjoittaa sokettiin! Oi kun nättiä. Mahdollisesti myös onnistuisi jonkinlainen select-tyyppinen ratkaisu tai monimutkaisesti erotella onko kyseessä luku- vai kirjoituseventti (en heti keksinyt miten tällainen onnistuisi). Mutta kahden olion käyttäminen tuntuu yksinkertaisemmalta, vaikkakin turhan monimutkaiselta.

Lienee sanomattakin selvää että tuli ikävä .NETin BeginReceiveä ja synkronisia kirjoitus- ja lukuoperaatioita :P