iPad popover kontrolis 5.1 iOS versijā

Turpinot izstrādāt savu pirmo iPad aplikāciju, nonācu pie nepieciešamības SplitViewControllerī MasterView attēlot kā popover. Izskatīju vairākus tutoriāļus un secināju - easy, būs gatavs pavisam īsā laikā. Tā arī bija - kārtējo reizi varu ieteikt iTunesU Stanford University iOS kursu, kur tieši man nepieciešamo lietu nodemonstrē 7. lekcijā.

Viss jau būtu lieliski un tas nebūtu pat bloga ieraksta vērts, ja vien... ja vien es lietotu iOS 5.0, nevis 5.1 versiju. Kā redzams attēlā, sākot ar iOS 5.1 versiju popover view vairs netiek attēlots kā standarta popovers pāri uz ekrāna jau esošajam skatam, bet gan "uzbrauc" virsū no ekrāna kreisās malas. Diemžēl neviena no iepriekš strādājušajām metodēm:
self.contentSizeForViewInPopover = CGSizeMake(100.0, 100.0);
[popoverController setPopoverContentSize:CGSizeMake(200.0f, 111.0f)];
utt.
vairs nestrādā.

Tad nu šo faktu jāsāk ņemt vērā, izstrādājot turpmāko aplikāciju interfeisus - tomēr ja nu kāds zin, kā apiet šo iOS izmaiņu - priecāšos par pievienotu komentāru! :)

iOS 4 vs iOS5

Jautājums, kas pēdējā pusgada laikā ir radies ne vienam vien iOS izstrādātājam ir - izstrādāt savu iOS app gan iOS4, gan iOS5 versijai, vai arī tikai iOS5, pie viena izmantojot 5. versijas SDK priekšrocības. No vienas puses - jo plašāks versiju atbalsts, jo lielāks potenciālais lietotāju skaits. Tomēr jāņem vērā, ka izstrādājot iOS4 versiju nav iespējams izmantot ne Automatic Reference Counting, ne, piemēram, Apple piedāvāto Twitter framework, ne interfeisu un navigāciju atvieglojošos Storyboards, ne arī citas jaunās iOS5 iespējas.
Lai izdarītu gala lēmumu, es ņēmu vērā vairākus aspektus:
1) Procentuāli cik daudz lietotāju vēl aizvien lieto 4. iOS versiju? Diemžēl viennozīmīgi šo jautājumu atbildēt nav iespējams, tomēr pēdējo 10 dienu laikā publiskotie un atrastie web resursi (David Smith bloga ieraksts, ko par pamatu izmanto arī Onkulis.com) liecina, ka iOS4 lietotāju skaits ir sarucis līdz ~20%.
2) Kurā vidē būs vienkāršāk uzrakstīt aplikāciju? Saprotams, ka iOS 5 sekos arī 6., 7. utt. versijas. Tātad, plānojot aplikāciju uzturēt arī ilgtermiņā, būs nepieciešams nodrošināt arī secīgu versiju pāreju un savietojamību. Arī šis aspekts spēlē par labu iOS 5.
3) Aplikācijas lietotāju loks. 5. iOS iespējams uzstādīt uz visiem iPhone sākot ar 3GS modeli. Protams, izvēloties 5. iOS automātiski tiek nogrieztas iespējas aplikāciju palaist iPhone un iPhone 3G lietotājiem. Tomēr - vai šie lietotāji tik un tā būs ieinteresēti izmantot Tavu aplikāciju? Ja lietotājs ir aktīvs aplikāciju izmantotājs, tad viņš ir saskāries ar ne vienu vien problēmu palaist arī citas jaunākās aplikācijas - līdz ar to aktīvs lietotājs būs jau nomainījis savu 3G modeli uz kaut ko mūsdienīgāku. Savukārt pasīvs lietotājs - diez vai vispār ieinteresēsies par Tevis izstrādāto produktu.
4) Aplikācijas lietotāju loks (2). Noteikti ir lietotāji, kas lieto 3GS, 4 vai 4S iPhone modeļus un vēl aizvien izmanto 4. iOS. Iemesls? Lietotājs nav redzējis jēgu veikt tik vienkāršo upgrade procesu. Tomēr diez vai šādi lietotāji redzēs iemeslu uzstādīt arī kādas citas aplikācijas - līdz ar to arī šie lietotāji diez vai sastāda reālo tirgus daļu.
Šādi varētu turpināt vēl visai gari. Izvērtējot šos aspektus nonācu pie secinājuma, ka, iespējams, būs kādi 10% potenciālo lietotāju, kas dēļ iOS ierobežojumiem nevarēs lietot iOS5 aplikācijas, tomēr 90% jeb 9:1 attiecības gadījumā es tomēr priekšroku dodu jaunajām *fīčām aplikāciju izstrādē, nogriežot supportu 1. pauadzes un 3G iPhone modeļiem.

XCode un Core Data

Jau otro dienu savu laiku veltu Core Data apgūšanai. Internets ir pilns ar dažādiem tutoriāļiem, tomēr ne katrs no tiem pasaka dažas svarīgās lietas, ko ievērot izstrādes laikā. Dažas no tām ir:
1) Pirms taisi savu iOS app - ļoti labi pārdomā Core Data struktūru - ja publicētam un reāli lietotam apam nāksies šo struktūru mainīt, rēķinies, ka nepietiks ar atsevišķu entītiju pievienošanu, bet nāksies taisīt arī datu migrāciju no vecā modeļa uz jauno. Īsāk sakot - neaizmirsti, ka Core Data nav SQL datubāze.
2) Ja tiek veiktas izmaiņas Core Data struktūrā, tad arī no iOS simulatora nepieciešams izdzēst iepriekšējo aplikācijas versiju. Pretējā gadījumā programma nestartēsies, norādot dažadas kļūdas, kaut arī vienkārša aplikācijas izdzēšana un atkārtota uzstādīšana problēmu atrisinātu.
3) Kodējot Objective-C kārtīgi ievēro dažādu objektu nosaukumu lielos un mazos burtus. Klases vēlamais nosaukums ir jāraksta ar 1. lielo burtu, pārējiem mazajiem; tāpat arī ir Core Data entītijām. Dažādi "sasaisti atvieglojoši" rīki kā, piemēram, RestKit var neļaut veidot nepieciešamās saites, ja nosaukumu lielie/mazie burti attiecīgajam interfeisam atšķirsies no Core Data entītijas nosaukuma.

Visbeidzot - ja vēl kāds nolēmis cīnīties ar Core Data, tad iesākumam iesaku šo tutoriāli:
http://notatkiprogramisty.blox.pl/2011/10/iOS-Core-Data-and-Xcode-42-Snow-Leopard-English.html

Ļoti skaidri un ērti norādīts, kā CoreData ir lietojams.

XCode nerāda LV burti dictionary izdrukā

Kā dažiem jau ir zināms, jau kopš februāra vidus nodarbojos ar XCode un iOS apgūšanu. Tā, protams, nav viegla nodarbe, tomēr - pats galvenais - virzās uz priekšu. Šajā sakarā esmu nolēmis apkopot vairākas atziņas, kas man būs radušās izstrādes laikā.

Pirmā no šādām atziņām jeb "Grābeklis-1" - grābeklis, uz kura nenovēlu nevienam uzkāpt:

Situācija sekojoša - ir MySQL serveris, no kura ar JSON tiek lasīti dati. Saņemtie dati tiek konvertēti uz NSDictionary. Problēma radās, ja dati saturēja kādu latviešu valodas burtu - tādā gadījumā tas tika nokonvertēts uz UTF-8 sešu simbolu kodējumu, kas pats par sevi nebūtu problēma. Tomēr problēma radās, kad uzskatīju, ka XCode nemāk šo kodējumu atkodēt. Pēc vairāk kā dienas cīnīšanās sapratu, ka patiesā problēma ir pavisam citur, nevis UTF-8 kodējumā - ja XCode konsoles debugošanas logā liek izvadīt NSString vērtību, kura satur LV simbolus, tad izvads ir korekts. Tomēr ja tos pašus LV simbolus satur NSDictionary, tad izvadot vārdnīcas vērtības konsolē LV burti tiek pazaudēti, attēlojot tikai to UTF-8 kodējumus.
Secinājums - rēķinieties, ka XCode debugger logs, izvadot string vērtības, LV simbolus var attēlot gan normāli (NSString gadījumā), gan tikai to UTF-8 kodējumu (NSDictionary gadījumā).