• Home
  • About

Objective-C 2.0 – Direttive del compilatore

spacer Sono alle prese con lo sviluppo di un’app per iPhone e siccome mi trovo a dover utilizzare, per forza di cose, le direttive messe a disposizione dal linguaggio, ho pensato che può essere utile avere una lista che le elenca e che ne spiega il significato. Ho trovato anche un post in rete molto interessante che in pratica fa la stessa cosa, e quindi ne approfitto per diffondere anche io nel panorama italiano.

Let’s go !

@class

Dichiara una classe senza dover utilizzare l’istruzione import con il relativo file header. Viene utilizzato per le class forward declaration.

@class DevMeClass;

@protocol @required @optional @end

Definisce l’inizio della dichiarazione di un protocol. Opzionalmente può dichiarare altri protocol ai quali è conforme come segue:

@protocol DevMeProtocol

 

  • @required: dichiara i metodi come metodi required.
  • @optional: dichiara i metodi come metodi optional. La classe che implementa il protocollo può decidere se implementare o no il metodo opzionale. Le classi che fanno uso del protocollo devono verificare che il metodo opzionale esista prima di utilizzarlo.
    [object respondsToSelector:@selector(optionalProtocolMethod)];
  • @end: dichiara la fine del protocollo.

@interface @public @package @protected @private @property @end

Definisce l’inizio di una classe o category.

Dichiarazione di una classe.

Le classi in Objective-C devono derivare direttamente o indirettamente dalla classe NSObject. La direttiva @interface per la dichiarazione di una classe può opzionalmente dichiarare che la classe è conforme ad altri protocolli.

@interface DevMeClass : DevMeSuperClass <DMProtocol, anotherDMProtocol> {
  // instance variables can be
@public
@package
@protected
@private
}
 
// property declarations
@property (atomic, readwrite, assign) id aProperty;
 
// public instance and/or class method declarations
@end

Dichiarazione di una category

La direttiva @interface non può aggiungere variabili d’istanza ma può opzionalmente dichiarare la conformità ad altri protocolli.

@interface DevMeClass (CategoryName) <DMProtocol, anotherDMProtocol>
 
// property declarations
@property (atomic, readwrite, assign) id dmProperty;
 
// method declarations
@end

Direttive

  • @public: dichiara la variabile d’istanza pubblica. Le varibili pubbliche possono essere lette o modificate con la notazione punto
    devme->bestBlog = true;
  • @package: dichiara la variabile d’istanza pubblica all’interno del framework che definisce la classe ma privata all’esterno.Funziona sui sistemi a 64 bit, su quelli a 32 bit si comporta esattamente come @public.
  • @protected: dichiara la variabile d’istanza protetta e quindi accessibile solo dalla classe che la definisce e dalle sue eventuali derivate.
  • @private: dichiara la variabile d’istanza privata e quindi accessibile solo dalla classe che la definisce.
  • @property: dichiara una proprietà la quale può essere accessibile con la notazione punto. Può essere eseguita dalle specialio parole chiave che ne definiscono l’esatto comportamento. Possono essere:
    • readwrite (default), readonly). Genera il getter e il setter (readwrite), solo il getter ((readonly).
    • assign (default), retain, copy. Si applica solo alle proprietà per cui è possibile effetuare un cast sul tipo id. assign, assegna il valore passato; retain, invia un release alla variabile d’istanza, invia retain al nuovo oggetto e assegna l’oggetto retained alla variabile d’istanza; copy invia un release alla varibile d’istanza, invia copy al nuovo oggetto e assegna l’oggetto copiato alla variabile d’istanza. Negli ultimi casi si è responsabili della deallocazione dell’oggetto.
    • atomic(default), non atomic. Le proprietà atomic sono thread-safe mentre le non-atomic possono essere accedute simultaneamente. Le non atomic sono pià veloci delle atomic e spesso usate nelle applicazione single thread.
    • weak (default), strong. Sono disponibili se la funzionalità ARC (automatic reference counting) è abilitata. La chiave strong è sinonimo di retain, mentre weak è sinonimo di assign.
  • @end: dichiara la fine della dichiarazione dell’interfaccia.

 

@throw @try @catch @finally

Vengono utilizzate per la gestione delle eccezioni.

@try {
    // code that might throw an exception &hellip; like this one:
    NSException *exception = 
        [NSException exceptionWithName:@"DevMeException"
                                reason:@"Test exception!"
                              userInfo:nil];
    @throw exception;
}
@catch (CustomException *ce) {
    // handling ...
}
@catch (NSException *ne) {
    // generic NSException handling ...
 
    // to simply re-throw the caught exception in a catch block:
    @throw;
}
@finally  {
    // after try or catch
}

@synchronized

Asscirua che il codice presente all’interno del blocco può essere disponibile solo ad un thread alla volta.

-(void) syncMethod:(id)object {
   @synchronized(object) {
      // code that works with locked object 
   }
}

@autoreleasepool

Nelle applicazioni in cui è abilitato ARC (Automatic Reference Counting) è necessario usare @autoreleasepool al posto di NSAutoreleasePool. Non bisognerebbe dichiarare una variabile all’interno di un blocco @autoreleasepool e continuare ad usarla dopo il blocco.

-(void) dmMethod {
    @autoreleasepool {
        // code that creates a large number of temporary objects
    }
}

@encode

Restituisce il carattere stringa della codifica di un tipo.

-(void) encMethod {
    char *enc1 = @encode(int);                 // enc1 = "i"
    char *enc2 = @encode(id);                  // enc2 = "@"
    char *enc3 = @encode(@selector(aMethod));  // enc3 = ":"
 
    // practical example:
    CGRect rect = CGRectMake(0, 0, 100, 100);
    NSValue *v = [NSValue value:&rect withObjCType:@encode(CGRect)];
}

@compatibility_alias

Consente di generare un alias per una classe. Il primo parametro è il nome dell’alias della classe, il quale può anche non esistere. Il secondo parametro è il nome della classe. a cui l’alias fa riferimento.

@compatibility_alias AliasClassName ExistingClassName

@string

Dichiara un oggetto NSString. Per tale oggetto non è necessario gestirne la memoria.

-(void) devmeMethod {
    NSString* str = @"Ciao questo &egrave; il blog di devme.";
    NSUInteger strLength = [@"Hello world!" length];
}

The end

Siamo giunti alla fine….per ora naturalmente. Sentitevi liberi di comunicare eventuali errori delle direttive. Nel frattempo, direttamente dal blog da cui ho tratto ispirazione, trovate la stessa lista in pdf spacer .

Stay tuned!

  • Condividi sudel.icio.us
  • Condividi suFacebook
  • Hai trovato qualcosa di buono? Condividilo su StumbleUpon
  • Condividi suTechnorati
  • Vuoi iscriverti ai commenti per questo post?

Ti è piaciuto?   Vota

Tags: iphone, objective-c, programming

spacer Art of Programming | mulp | spacer dicembre 22, 2011 3:24 pm | spacer Commenti (0)

Chroot: come creare un ambiente a 32-bit su AMD 64

spacer Mi è capitato pochi giorni fa di dover far fronte a questo problema: eseguire un software basato su perl 5.8.8 sparito ormai dalle più attuali distribuzioni ubuntu per essere precisi. La mia, che non è la ultimissima versione, la lucid, mette a disposizione il pacchetto perl 5.10.x.x, per ovviare avrei dovuto fare il downgrade del pacchetto perl, con tutti i problemi annessi e connessi. Per altro il SW è supportato solo su architetture a 32 bit, praticamente non avevo chance. Come fare a risolvere ? Semplice, creando un ambiente a 32 bit, attraverso il comando chroot. Vediamo come.

Dopo una breve ricerca, ho trovato che il pacchetto perl 5.8.8 è presente nella distro ubuntu hardy quindi ho battezzato quella versione come target del mio ambiente a 32 bit.

#1. Installare il pacchetto debootstrap il quale contiene una serie di script utili:

mulp@devme:~$ apt-get install debootstrap

Per saperne di più del comando vi rimando al seguente link

#2. Installare il pacchetto dchroot il quale contiene una serie di comandi utili alla creazione e all’accesso su diversi ambienti chroot:

mulp@devme:~$ apt-get install dchroot
mulp@devme:~$ mkdir /devme/chroot

Posizionatevi quindi nel punto del file system in cui desiderate creare fisicamente l’ambiente.

#3. Editare il file /etc/dchroot.conf e aggiungere la seguente riga:

hardy_i386 /devme/chroot/hardy_i386

Assicuratevi che il percorso sia corretto.

#4. Ci siamo. Siamo pronti a creare il nuovo ambiente. Eseguire il seguente comando:

mulp@devme:~$ debootstrap --variant=buildd --arch i386 hardy /devme/chroot/hardy_i386 http://archive.ubuntu.com/ubuntu/

Al termine dell’esecuzione avrete il nuovo sistema installato. Per ulteriori dettagli sul comando debootstrap vi rimando al man di sistema, aggiungo solo che il parametro variant indica il tipo di sistema che si vuol creare, in questo buildd. Il nuovo sistema creato avrà installati i pacchetti base-system.

#5. Procediamo ora alla configurazione del nuovo sistema. Eseguire i seguenti comandi:

mulp@devme:~$ cp /etc/resolv.conf /devme/chroot/hardy_i386/etc/resolv.conf
mulp@devme:~$ cp /etc/apt/sources.list /devme/chroot/hardy_i386/etc/apt/
mulp@devme:~$ chroot /devme/chroot/hardy_i386/
mulp@devme:~$ apt-get update
mulp@devme:~$ apt-get install gnupg locales dialog
mulp@devme:~$ apt-get update
mulp@devme:~$ locale-gen it_IT.UTF-8
mulp@devme:~$ tzconfig
mulp@devme:~$ exit

In sostanza si ereditano alcune configurazioni dell’ambiente principale all’interno di quello appena creato. Il primo comando consente di poter navigare dal nuovo ambiente e il secondo mette a disposizione le source list di apt affinché sia possibile aggiornarlo. Vengono installi alcuni comandi fondamentali e impostato il locale corretto. Ricordatevi di modificare il file sources.list se la distro del vostro sistema differisce dall’ambiente creato.

#6. A questo punto per accedere all’ambiente appena creato si utilizza il comando dchroot -d oppure dchroot -d- c hardy_i386 se avete a disposizione più ambienti. Vi accorgerete che il comando di cui sopra richiedono i diritti da superutente. Affinchè sia possibile accedere da utente normale, è necessario copiare alcuni file di configurazione dall’ambiente centrale in quello appena creato:

mulp@devme:~$ cp /etc/passwd /devme/chroot/hardy_i386/etc/
mulp@devme:~$ sed 's/\([^:]*\):[^:]*:/\1:*:/' /etc/shadow | tee /devme/chroot/hardy_i386/etc/shadow
mulp@devme:~$ cp /etc/group /devme/chroot/hardy_i386/etc/
mulp@devme:~$ cp /etc/hosts /devme/chroot/hardy_i386/etc/

Il comando sed rimuove le password criptate dal file shadow. Dal momento che stiamo facendo login in un’ambiente chroot non sono necessarie. In questo modo evitiamo anche di duplicare il file delle password su due ambienti diversi.

#7. Se si vuole poter eseguire il comando sudo è necessario copiare i seguenti file:

mulp@devme:~$ cp /etc/sudoers /devme/chroot/hardy_i386/etc/
mulp@devme:~$ chroot /devme/chroot/hardy_i386
mulp@devme:~$ dpkg-reconfigure passwd
mulp@devme:~$ passwd &lt;username&gt;
mulp@devme:~$ apt-get install sudo

E infine aggiungere la seguente riga nel file /etc/sudoers nell’ambiente chroot.

# Members of the admin group may gain root privileges
%mulp ALL=(ALL) ALL

#8. Procediamo con il mapping di alcune directory che sono utili all’interno dell’ambiente chroot. Editare il file /etc/fstab e aggiungere le seguenti righe:

/home         /devme/chroot/hardy_i386/home        none    bind      0 0
/tmp          /devme/chroot/hardy_i386/tmp         none    bind      0 0
/media/cdrom  /devme/chroot/hardy_i386/media/cdrom none    bind      0 0
/dev          /devme/chroot/hardy_i386/dev         none    bind      0 0 
proc-chroot   /devme/chroot/hardy_i386/proc        proc    defaults  0 0
devpts-chroot /devme/chroot/hardy_i386/dev/pts     devpts  defaults  0 0

Assicuratevi di effettuare la modifica sul file /etc/fstab dell’ambiente principale e che esistano tutti i mount point. Quindi eseguire il comando:

mulp@devme:~$ mount -a

#9. Infine, se volete che di fianco nel prompt appaia l’indicazione dell’ambiente chroot editate il file /devme/chroot/hardy_i386/etc/debian_chroot e aggiungete la seguente riga:

hardy_i386

Se il file non esiste createlo.

Stay tuned!

  • Condividi sudel.icio.us
  • Condividi suFacebook
  • Hai trovato qualcosa di buono? Condividilo su StumbleUpon
  • Condividi suTechnorati
  • Vuoi iscriverti ai commenti per questo post?

Ti è piaciuto?   Vota

Tags: 32 bit, 64 bit, amministrazione, chroot, linux, perl, ubuntu

spacer OS linux OS | mulp | spacer ottobre 24, 2011 11:42 am | spacer Commenti (0)

Android: Contacts API

spacer A partire dalla versione 2.0 la piattaforma Android ha migliorato notevolmente le API per la gestione dei contatti, favorendo lo sviluppo di applicazioni che
gestiscono account provenienti da diverse fonti. L’idea principale è che per gestire differenti contatti provenienti da fonti diverse (gmail, telefono, sim, facebook, etc) 
viene utilizzata una funzione di aggregazione che in automatico riconosce i contatti simili, e li presenta come una singola entità.

La struttura dei Contatti su basa su 3 tabelle principali: contacts, raw contacts e data.

spacer

Data è una tabella generica che memorizza le informazioni legate ad un raw contact, nome, foto, indirizzo email, gruppo di appartenenza, numero di telefono, etc. Ciascuna riga è identificata da un MIME type che ne identifica il tipo.
Ad esempio, il tipo Phone.CONTENT_ITEM_TYPE indica il numero di telefono, mentre Email.CONTENT_ITEM_TYPE indica l’indirizzo email. E’ possibile estendere i tipi predefiniti estendendo la classe ContactsContract.CommonDataKinds.
Raw Contacts memorizza le informazioni dell’insieme di Data che descrivono le informazioni di una persona associate ad una singola sorgente di contatti. Si consideri ad esempio, una riga della tabella che memorizza informazioni relative ad un account google, facebook, etc. Contacts rappresenta l’aggregazione di uno o più raw contacts che descrivono la stessa persona, memorizzate all’interno di un singolo Contact.
In fase di visualizzazione dei contatti all’utente, un’applicazione dovrebbe agire a livello di Contacts poiché è l’entità che fornisce una visualizzazione aggregata dei contatti dalle varie fonti.

Inserimento di un numero di telefono

Per inserire un numero di telefono utilizzando le nuove API dei contatti è necessario ottenere l’ID del raw contact sul quale si vuole aggiungere l’informazione, quindi creare un nuova entry nella tabella Data:

package it.devme.contacts;
import android.provider.ContactsContract.CommonDataKinds.Phone;
...
    ContentValues values = new ContentValues();
    values.put(Phone.RAW_CONTACT_ID, idRowContact);
    values.put(Phone.NUMBER, mobileNumber);
    values.put(Phone.TYPE, Phone.TYPE_MOBILE);
    Uri uri = getContentResolver().insert(Phone.CONTENT_URI, values);
....

Aggregazione dei contatti

In fase di sincronizzazione dei contatti da diverse fonti, è possibile che più contatti identifichino la stessa persona pur con sottili differenze nei dati. Ad esempio, il caro Mario Rossi, potrebbe essere sia il nostro collega di lavoro che il nostro caro amico, in questo modo si avrebbero due contatti diversi con i relativi dati. Per evitare tali sovrapposizioni, il sistema rileva queste condizioni e aggrega i contatti in modo tale da combinarli in uno singolo, aggregato.

 

Aggregazione automatica

Non appena un raw contact viene aggiunto o modificato, il sistema cerca di rilevare eventuali sovrapposizioni con altri raw contact, in modo tale da cercare di aggregarli. Se non viene rilevato nessun contatto, allora verrà creato un’unico contatto contente i dati iniziali. Se viene trovato un contatto allora i dati di entrambi verranno aggregati in un solo contatto. Altrimenti nel caso di più match verranno scelti quelli ‘più vicini’ all’originale. In generale, il match tra due contatti avviene se viene soddisfatta una delle seguenti:

  • hanno lo stesso nome
  • hanno lo stesso nome ma in ordine differente (es. "Mario Rossi", "Rossi Mario")
  • uno dei due ha un diminuitivo dell’altro (es., "Roberto Verdi", "Rob Verdi")
  • uno di due ha solo il nome o cognome  e fa match con altri raw contact. Questa regola è poco affidabile e viene utilizzata assieme ad altre regole verificando anche il match rispetto ad altri dati, come il numero di telefono, email, nickname o altro. (es, Mario ["fulmine"] = Michela Bianchi ["fulmine"])
  • almeno uno dei due contatti non ha il nome ma condividono il numero di telefono, l’indirizzo email o il nickname. (es, Roberto Verdi [robin@devme.it] = robin@devme.it).

I confronti tra nomi non sono case-sensitive per evitare errori ovvi, così come i confronti tra numeri di telefono nei quali non vengono considerati caratteri come ‘+’, ‘#’ etc.

Aggregazione esplicita

In alcuni casi però potrebbe non essere richiesta l’aggregazione automatica dei contatti, per requisiti di una certa applicazione o altro. In questi casi si ricorre all’aggregazione esplicita, attraverso l’utilizzo delle API dei contatti è possibile specificare diversi modi di aggregazione dei dati e alcune eccezioni.

 

Aggregation modes

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.