Î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…