Dintre noutățile aduse de iOS SDK5.0, una care mi-a atras în mod deosebit atenția este prezența noii clase UIPageViewController, care permite crearea unei cărți digitale simulând experiența oferită de o carte reală.

UIPageViewController este de fapt un container al cărui rol principal este cel de a gestiona o colecție de view-controllere (care reprezintă paginile cărții digitale), facilitând navigarea între ele.

Opțiuni de afișare

Tranziții

O tranziție reprezintă efectul folosit pentru animarea navigării de la o pagină (adică un view-controller) la alta. Momentan nu este disponibilă decât o singură opțiune – cea care produce un efect asemănător cu cel din iBooks.

Orientarea navigării

Orientarea pe care se face trecerea între “pagini”. Aici există două opțiuni:

- pe orizontală (UIPageViewControllerNavigationOrientation.Horizontal) – trecerea se face de la stânga la dreapta, sau invers;

- pe verticală (UIPageViewControllerNavigationOrientation.Vertical) – trecerea se face de sus în jos, sau invers.

Mai mult…

Substitution API este de fapt un nume mai pompos pentru a descrie funcționalitatea oferită de metoda HttpResponse.WriteSubstitution(callback) care, în loc să scrie un șir de caractere în stream-ul răspunsului, ”scrie” un placeholder (înlocuitor) ce constă din funcția dată ca parametru care, atunci când răspunsul este trimis către client, este executată iar poziția ei în răspuns este înlocuită cu rezultatul execuției. Astfel, acest procedeu răspunde nevoii de actualiza dinamic porțiuni dintr-o pagină (sau dintr-un UserControl – .ascx) cache-uită folosind API-ul de output caching.

Datele problemei

Avem următoarea sarcină de lucru: trebuie să prezentăm o pagină al cărei conținut nu se schimbă foarte des și este același, indiferent de utilizatorul autentificat, fiind astfel un candidat foarte bun pentru output caching. Totuși, există o mică zonă din pagină care poate varia: link-ul de log-in (care apare dacă utilizatorul nu e autentificat), sau de log-out (care apare dacă utilizatorul este autentificat). Problema este că, odată salvat răspunsul în cache, acel link va rămâne același din momentul primei accesări a paginii, indiferent utilizatorul se autentifică sau nu ulterior. Mai mult…

În ceea ce privește debugging-ul și profiling-ul, PHP oferă un suport standard nesemnificativ, golul fiind umplut însă de o serie de extensii și instrumente precum:

- XDebug – o extensie PHP care oferă facilități precum profiling, code coverage, remote debugging, afișarea stack trace-urilor, afișarea îmbunătățită a rezultatelor produse de var_dump etc.;

- APD – Advanced PHP Debugger – este tot o extensie de PHP care oferă un API pentru debugging;

- DBG – software disponibil atât gratuit, cât și cu plată;

- FirePHP – permite tipărirea mesajelor în consola Firebug, folosind apeluri de funcții executate în scripturile PHP;

- Zend IDE, care vine cu propriul său debugger etc.

Primii pași

Atunci când începem un proiect este bine să avem un mediu de dezvoltare configurat corespunzător, astfel încât să putem fi notificați din timp de eventualele probleme apărute, oricât de nesemnificative ar putea fi. Astfel, când dezvoltăm o aplicație în PHP trebuie să ne asigurăm ca nivelul de raportare a erorilor este cel mai ridicat posibil și că, evident, PHP-ul este configurat să afișeze erorile. Setările necesare ar putea fi făcute dinamic la începutul unui script, după cum urmează:

ini_set('display_errors', 'On');
error_reporting(E_ALL);

Merită menționat faptul că, începând cu PHP5, este disponibilă constanta E_STRICT, care, printre altele, activează emiterea avertizărilor referitoare la metodele deprecated folosite în programul vostru. Astfel, linia 2 ar deveni:

error_reporting(E_ALL | E_STRICT)

Mai mult…

Una din sarcinile pe care le-am avut de îndeplinit recent a presupus, printre altele, și gestiunea unor fișiere aflate pe alte mașini (ex: listarea directoarelor, descărcarea fișierelor necesare, procesarea lor, încărcarea lor pe o altă masină etc.). Pentru ce aveam nevoie, o soluție bazată pe protocolul SFTP era deci cea mai indicată, iar singura soluție open-source pentru platforma .NET pe care am putut-o găsi a fost SSH.NET (SharpSSH nu funcționa corespunzător și nici nu mai este dezvoltată de ceva vreme, iar o soluție platită nu își justifica în nici un fel costurile în cazul de față).

SSH.NET este un proiect complet nou, foarte bine scris care, din câte observ, primește din ce în ce mai multă atenție (paradoxal însă, am dat destul de greu de el). Fiind însă destul de slab documentat (pe undeva e și normal să fie așa, focusul fiind momentan pe dezvoltare) m-am gândit că ar fi bine sa ilustrez într-o serie de două articole modalitatea de utilizare a acestei librării pentru a lucra cu SFTP, respectiv SSH în C#/.NET.

Conectarea

Întâi de toate, trebuie să aflați ce modalități de conectare suportă server-ul la care vă conectați. Odată ce aflați aceste detalii, veți configura o instanță a uneia dintre clasele:

- PrivateKeyConnectionInfo – pentru autentificarea folosind o pereche de chei;

- PasswordConnectionInfo – pentru autentificarea folosind un nume de utilizator și o parolă;

- KeyboardInteractiveConnectionInfo – pentru a folosi modalitatea de autentificare interactivă (care, în particular, poate funcționa asemănător modalității de autentificare cu parolă).

pentru a vă putea autentifica.

Mai mult…

Un subiect interesant pentru orice programator, indiferent de limbajul de programare pe care il folosește, îl reprezintă procesarea documentelor HTML, iar expresiile regulate, deși sunt o abordare destul de întâlnită, nu reprezintă întotdeauna o soluție potrivită.  De multe ori (mai ales atunci când avem nevoie să efectuăm operații complexe sau sensibile, cum ar fi validările) se impune folosirea unui procesor HTML pentru a citi, modifica sau produce un document, unul din aceste procesoare fiind SimpleHtmlDom, despre care am ales să scriu în continuare.

Pentru a nu da acestei expuneri un aer plictisitor de manual școlar, am ales să exemplific conceptele folosind un site aflat în producție, alegând în acest scop www.realitatea.net. Voi extrage din pagina principală a acestui site următoarele elemente:

- titlul paginii HTML;

- toate foile de still incluse;

- toate scripturile externe incluse;

- articolul principal: titlu, fotografie și conținut;

- cele mai noi știri: titlu si link.

Mai mult…

Sau problema lipsei lui MapMoveEnd, ca să fiu mai exact. Mai întâi, însă, permiteți-mi să trasez, în linii mari, contextul acestei probleme. În versiunea 2 a API-ului Google Maps exista un eveniment declanșat de hartă, denumit sugestiv moveend. Acest eveniment semnifica finalizarea modificărilor suferite de suprafața afișată de hartă, modificări produse de oricare din următoarele operații:

- pan de hartă (drag & drop, prin intermediul controlului de pan, sau programatic cu ajutorul metodei GMap2.setCenter);

- zoom de hartă (folosind rotița de la mouse, prin dublu clic, folosind controlul de zoom, sau programatic cu ajutorul metodei GMap2.setZoom).

Nu are rost să menționez cât de util poate fi , și chiar este, un astfel de eveniment. Problema este că acesta a dispărut în versiunea 3, apărând în schimb o serie de alte evenimente:

- center_changed – declanșat de fiecare dată când centrul hărții se schimbă;

- bounds_changed – declanșat atunci când box-ul hărții se schimbă;

- idle – atunci când harta nu mai primește evenimente, după o secvență de pan sau zoom.

Mai mult…

Înainte să abordez subiectul central al acestui articol, aș dori să vorbesc un pic despre ceea ce stă la baza funcționării tehnologiei MonoTouch. Ei bine, MonoTouch expune o interfață C# prin intermediul căreia putem folosi librăriile din CocoaTouch, oferind în același timp acces la un subset al API-urilor din .NET. Cu alte cuvinte, la baza funcționării acestui framework stă un engine de interoperabilitate (asemănător mecanismului P/Invoke) care asigură comunicarea între codul C# scris de dezvoltator si API-urile scrise în C și Objective-C, API-uri ce compun SDK-ul oferit de Apple pentru platformele iOS. Întregul sistem este, evident, ceva mai complex decât atât, mai multe informații putând fi găsite aici.

Foarte important de reținut este faptul că putem folosi aceste mecanisme pentru a consuma orice librărie scrisă în Objective-C, care nu este încă expusă prin intermediul framework-ului MonoTouch. Acesta este și cazul librăriei AdMob, pe care Google o livrează compilată doar ca binar pentru Objective-C, impunându-se deci nevoia creării unui binding.

Nu voi prezenta toți pașii necesari scrierii unui astfel de binding, aceștia fiind descriși aici cu lux de amănunte. Voi atașa în schimb sursele necesare, prezentând, evident, instrucțiunile și exemplele de rigoare.

Mai mult…

Ce este NLog

NLog este o platformă gratuită de jurnalizare pentru .NET și Mono care oferă facilităţi avansate precum:

- procesarea mesajelor primite, îmbunătățirea lor cu diverse informații contextuale (precum momentul de timp al înregistrării, informații despre firul de execuție, informații despre proces etc.) și formatarea acestora conform regulilor dorite;

- suportă diverse modalități de jurnalizare: în fișiere pe disc, într-o bază de date, în EventLog-ul sistemului de operare, pe rețea, pe e-mail etc.

- opțiuni de rutare a mesajelor, incluzând: buffering, jurnalizare asincronă, load balancing, failover etc.

- ușor de configurat, incluzând și o extensie de Visual Studio ce face mai comodă crearea fişierelor de configurare.

Este disponibil sub licență BSD, iar sursa poate fi descărcata de pe GitHub.

Ce este un target pentru NLog și cum scriem un astfel de target

Pe scurt, un target pentru NLog reprezintă o destinaţie a mesajelor trimise de aplicaţie, un target putând fie să stocheze mesajele, fie să le afişeze, sau să le trimită mai departe. Puteti găsi aici o listă de target-uri suportate de NLog în momentul de față.

Totuși, necesitățile unui proiect nu pot fi acoperite mereu de componentele standard, tocmai acesta fiind motivul pentru care NLog ne oferă posibilitatea de a ne crea propriile target-uri. În continuare voi descrie, deci, pașii necesari în crearea unui astfel de target, alegând pentru exemplificare dezvoltarea unui target care salvează în baza de date mesaje personalizate ce descriu operațiunile efectuate într-un sistem.

Mai mult…

Cand am inceput sa dezvolt N!mobiliare, una din primele probleme pe care le-am avut era modalitatea in care voi expune si consuma datele necesare aplicatiei. Mi-era clar deja ca va trebui sa dezvolt niste servicii web, dar nu imi doream sa folosesc nici SOAP nici XML, ci JSON. WCF/Odata a fost primul lucru catre care m-am uitat, insa nu era complet suportat de MonoTouch la vremea respectiva.
As fi putut sa abordez problema asa cum e descris aici, insa varianta pe care am mers a fost ServiceStack, un framework pentru servicii web .NET, foarte performant si foarte bine scris. Motivele principale pentru care l-am ales au fost:

- permite expunerea si consumarea serviciilor in format JSON, XML, dar si SOAP, fara a fi nevoie sa scriu nicio linie de cod in plus;

- cererile facute serviciilor si raspunsurile returnate sunt POCO-uri simple, care pot fi scrise separat si apoi folosite de catre orice aplicatie client;

- ruleaza inclusiv pe platforma Mono;

- foarte simplu de utilizat si imi place faptul ca ofera o arhitectura bazata pe mesaje/contracte intre client si server, fata de abordarea standard care incurajeaza tratarea serviciilor web ca apeluri normale de functii.

Mai multe detalii puteti gasi aici si aici, inclusiv exemple de utilizare.

Mai mult…

Acum cateva zile, luand masa alaturi de colegii de servici, una din ideile vehiculate pe parcursul conversatiei a fost cea a dezvoltarii interfetelor aplicatiilor web folosind integral tehnologii precum Flash sau Silverlight (in sensul de inlocuitor la o scara semnificativa a combinatiei HTML/CSS/Javascript).  Trebuie sa admit ca am fost putin reticent la inceput, insa dupa ce am reflectat putin mai mult asupra problemei, mi-am schimbat pozitia intr-un adept al acestui concept.

Unul dintre motive este faptul ca actualul mod de realizare al frontend-ului (intefetei) unei aplicatii web este un proces anevoios, consumator de timp, resurse, nervi si, cel  mai important, este bazat pe tehnologii care fie nu sunt standardizate, fie nu sunt evoluate pana la un nivel care sa permita un flux de lucru comod. Lucrul cu aceasta combinatie (HTML/CSS/Javascript, dupa cum am precizat si mai sus) nu pare deloc natural si intr-o oarecare masura e ca si cum ai servi in acelasi timp, o sticla de bere, cateva pahare de vin si un shot de tequilla: sunt momente in care habar nu ai ce faci, incep sa delirezi, iar a doua zi te lupti cu o durere de cap teribila.

Lasand gluma la o parte, consider ca avem de-a face cu o problema serioasa, intrucat fiecare producator fie interpreteaza asa cum doreste standardele, fie isi creaza propriile standarde si forteaza introducerea acestora pe piata. Pe langa acest fapt, actualele tehnologii lasa de dorit in puncte importante, precum:

- implementarea layout-urilor nebanale (e o adevarata placere sa realizezi un layout lichid cu 3 coloane, nu?;));

- zona de comunicatii (Ajax nu este mereu de ajuns si nici nu are o implementare 100% standard, iar limitarea ei exclusiv la domeniul curent nu este tot timpul oportuna);

- posibilitati relativ limitate de exprimare (de exemplu, pentru construirea unor grafice direct in browser e necesara fie folosirea SVG, sau VML, in functie de browser, EVIDENT).

Mai mult…