1. JSONView
2. Advanced REST client Application
3. REST Console

Must have

Una approccio ingiustificato da parte di Apple che nonostante tutto continua a trincerarsi dietro un silenzio assordante. Un pratica che io non comprendo e che aborro dal profondo. Questa incuria dei suoi developer che nonostante tutto sono di gran lunga i più fanatici sul globo. Una pratica che permea l’azienda di Cupertino fin dalle origini e che non accenna a diradarsi. L’uscita di iOS5 e XCode 4.2 ne è l’esempio lapalissiano.

Su questi aspetti avrò modo di ritornarci nei successivi post. Dicevamo XCode lento, che fare? Non molto purtroppo, a parte i soliti consigli da mentecatti come “compra più RAM” o “cambia mac” gli unici che mi sento di suggerire veramente sono:

1. Limitare il numero di cocurrent build operation
2. Disabilitare l’indexing del codice

Come si dice “di più ninzò”

Qualche fonte:

• http://stackoverflow.com/questions/5410191/hidden-features-of-xcode-4
• http://developer.apple.com/library/ios/#releasenotes/DeveloperTools/RN-Xcode/_index.html
• http://stackoverflow.com/questions/7780663/why-are-xcodebuild-and-xcode-4-2-so-slow

Dopo lunghe ricerche mi sono imbattuto su un forum dove sono riportate le seguenti specifiche non ufficiali:

• 3G iPhone w/ A-GPS ~ 8m
• 3G iPhone w/ wifi ~ 74 m
• 3G iPhone w/ Cellular positioning ~ 600m
• iPhone4 w/ A-GPS ~ 7m

Qualche fonte:

• http://stackoverflow.com/questions/312775/how-accurate-is-the-triangulated-gps-of-the-non-3g-iphone
• http://forums.arcgis.com/threads/21917-iOS-Android-GPS-Accuracy
• http://stackoverflow.com/questions/824403/iphone-gps-performance

Ultimamente sto valutando delle alternative più leggere e moderne. Dopo qualche ricerca mi sono imbattuto in due framework interessanti:

1. AFNetworking – A delightful iOS and OS X networking framework
2. MKNetworkKit - Full ARC based Networking Kit for iOS 4+ devices

Sicuramente da valutare.

I crash log del simulatore sono posizionati in questa cartella:

~/Library/Logs/DiagnosticReports/

I file da considerare sono quelli con estensione .crash. Ovviamente

for (id subview in self.webView.subviews)
{   
   if ([[subview class] isSubclassOfClass: [UIScrollView class]])   
   {       
      ((UIScrollView *)subview).scrollEnabled = NO;       
      break;   
   }
}
 
// oppure così (anche se è meno sicuro perché non è certo
// che la scroll view si trovi sempre nella prima posizione)
[[webView.subviews objectAtIndex:0] setScrollEnabled:NO];

E con iOS 5? beh le cose si semplificano di un pelo…

self.webView.scrollView.scrollEnabled = NO;

o no?

1. non ci sono colori nel comando status
2. non c’è l’auto completamento dei comandi di git
3. non ci sono nel prompt delle indicazioni sul branch in uso

$ git config color.ui true

$ mkdir /tmp # se non esiste già
$ cd /tmp
$ git clone git://git.kernel.org/pub/scm/git/git.git
$ cd git
$ git checkout v`git --version | awk '{print $3}'`
$ cp contrib/completion/git-completion.bash ~/.git-completion.bash
$ cd ~
$ rm -rf /tmp/git
$ echo -e ">> .profile

$ git stat[tab]

GIT_PS1_SHOWDIRTYSTATE=true
 
if [ -f /opt/local/etc/bash_completion ]; then
    . /opt/local/etc/bash_completion
fi
 
PS1='\[\033[32m\]\u@\h\[\033[00m\]:\[\033[34m\]\w\[\033[31m\]$(__git_ps1)\[\033[00m\]\$ '

export CLICOLOR=1
export LSCOLORS=GxFxCxDxBxegedabagaced

Beh che dire, tutta un’altra storia!!!

1
2
3
4
5
6
7

#pragma mark - UITableViewDelegate Methods
 
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *cell = [self tableView:tableView cellForRowAtIndexPath:indexPath];
    return cell.frame.size.height;
}

In pratica ricaviamo la cella corrente dal data source e recuperiamo la sua altezza effettiva. Attenzione a non cadere nel subdolo tranello di richiedere la cella corrente direttamente alla tableView (o a self.table) in questo modo:

1
2
3
4
5
6
7
8

#pragma mark - UITableViewDelegate Methods
 
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
    // errore!
    UITableViewCell *cell = [tableView cellForRowAtIndexPath:indexPath];
    return cell.frame.size.height;
}

Facendo così si manderà il programma loop! Questo perché la cella non è ancora presente nella tableView ma solo nel datasource. Se si tenta di recuperare la cella direttamente dalla tableView questa, essendone priva, ne richiederà una nuova al data source che a sua volta richiamerà tableView:heightForRowAtIndexPath:indexPath per ottere l’altezza e così via in un circolo senza fine. Anzi no con una fine: EXC_BAD_ACCESS!

Per finire piccola nota sulle performance:
in effetti questo metodo non è molto efficiente in quanto ogni singola cella viene creata due volte, la prima per misurare l’altezza e la seconda volta per  poter essere aggiunta alla tabella. E’ chiaro che ci sono ampi margini di miglioramento. Magari li vediamo in un prossimo articolo

Per farlo è necessario definire una propria funzione “MYLog” in un header comune o nel file .pch in questo modo:

1

# define MYLog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);

__PRETTY_FUNCTION__ e __LINE__ sono due macro che hanno proprio lo scopo di visualizzare il nome del metodo e la linea. Ci sono anche altre macro che si posso utilizzare ad ognuno la sua scelta.

Se invece vogliamo fare in modo che queste informazioni siano stampate solo in DEBUG basta aggiungere un if in questo modo:

1
2
3
4
5

#ifdef DEBUG
#   define MYLog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);
#else
#   define MYLog(...)
#endif

Niente di più semplice e funzionale.