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! :)
Rāda ziņas ar etiķeti Apple. Rādīt visas ziņas
Rāda ziņas ar etiķeti Apple. Rādīt visas ziņas
trešdiena, 2012. gada 30. maijs
pirmdiena, 2012. gada 2. aprīlis
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.
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.
otrdiena, 2012. gada 6. marts
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.
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.
piektdiena, 2012. gada 2. marts
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ā).
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ā).
trešdiena, 2010. gada 10. februāris
Vai ir vērts iegādāties neoriģinālās datoru baterijas?

Dotais jautājums bieži vien ir nodarbinājis daudzu portatīvo datoru lietotāju prātus. Tā kā arī man ir plānots tuvākajā laikā nomainīt datora bateriju, tad veicu sīkāku googlējumu dotajā jomā.
Mans labākais atrastais raksts par minēto tēmu nāk no ComputerWorld.
Tiem kam slinkums lasīt - rakstā secināts, ka, ja netiek pirktas pašas lētākās baterijas, tad problēmām nevajadzētu rasties. Tā ka - laikam jau pasūtīšu no kāda cita tirgotāja, nevis pirkšu no Apple.
otrdiena, 2009. gada 20. oktobris
Apple uzrāviens

Tas, kas pēdējās dienās ir noticis ar Apple - to ir grūti aprakstīt un vārdos izteikt. Gan fantastiskie finansu rādītāji ar 47% peļņas pieaugumu - tagad, krīzes laikā!!! Un nu vēl jaunie iMac, MacMini, MacBook, jaunā Magic Mouse! Grūti to visu aprakstit un diez vai ir pat nepieciešams. Lai nu kā - zinu, ka ātrāk vai vēlāk, tomēr jaunu iMac, droši vien jau ar 27 collu ekrānu, nāksies gādāt. Jo tikko iznākušais ir patiešām - WOW! :)
otrdiena, 2009. gada 9. jūnijs
iPhone 3GS Latvijā jau jūlijā
Vakar, kā jau es, uzmanīgi sekoju līdzi Apple WWDC konferencei, kuras laikā papildus citām brīnišķīgām lietām tika prezentēts arī jaunais "iPhone 3G S". Nospriedu, ka beidzot būtu īstais laiks arī man tikt pie iPhone, tomēr ne TUAW, ne Engaged nepublicēja datumu, kad iPhone būt pieejams Latvijā. Nu ko - šodien nosūtīju meilu LMT ar jautājumu:
"Sakiet, lūdzu, kad Latvijā būs pieejams jaunais iPhone 3GS?"
saņēmu atbildi:
"Šobrīd mūsu rīcībā nav šādas informācijas. Aicinam sekot jaunumiem LMT mājas lapā: http://www.lmt.lv/lat/sakumlapa".
Protams, viss jau būtu ok, ja vien neizrādītos, ka prezentācijas laikā ir bijis arī šāds slaids:

Hm... interesanti, ka Apple prezentē iPhone parādīšanos LV jau 9. jūlijā, kamēr paši izplatītāji LMT par to vēl neko nemaz nezin...
"Sakiet, lūdzu, kad Latvijā būs pieejams jaunais iPhone 3GS?"
saņēmu atbildi:
"Šobrīd mūsu rīcībā nav šādas informācijas. Aicinam sekot jaunumiem LMT mājas lapā: http://www.lmt.lv/lat/sakumlapa".
Protams, viss jau būtu ok, ja vien neizrādītos, ka prezentācijas laikā ir bijis arī šāds slaids:

Hm... interesanti, ka Apple prezentē iPhone parādīšanos LV jau 9. jūlijā, kamēr paši izplatītāji LMT par to vēl neko nemaz nezin...
sestdiena, 2009. gada 24. janvāris
Vienkārši labs teikums
Steve Jobs, 1997:
“If you look backward in this business, you’ll be crushed. You have to look forward.”
“If you look backward in this business, you’ll be crushed. You have to look forward.”
ceturtdiena, 2009. gada 22. janvāris
Lēts iPhone

Vakar, kad Apple paziņoja savus ceturkšņa finansu rādītājus (jā, jā, tie bija labāki kā prognozēts, kas after day treidā akciju cenu pacēla brīžiem pat vairāk kā par 10%), pie viena notika arī conference call, kura laikā tika jautāts, vai:
1) Apple piedāvās low-end jeb lētos iPhone telefonus?
2) Vai Apple plāno tirgū piedāvāt tā saucamos NetBookus?
Uz pirmo atbilde bija noraidoša: We're not going to play in the low-end voice phone business. That's not who we are, that's not why we're here. Goal is not to lead unit sales, but to build the world's best phone.
Kaut arī esmu 99.998% Apple patriots, tomēr uzskatu, ka "the world's best phone" vēl aizvien ir kur augt, tomēr nevar noliegt, ka iPhone ir bijis stūrakmens telefonu biznesā. Veiksmi viņiem un gan jau nākamās paaudzes iPhone kādu dienu ieguls arī manā rokā.
Arī uz otro jautājumu atbilde bija vairāk vai mazāk noraidoša, tomēr tāda, kas ļauj cerēt, ka varbūt - kādreiz. Drīzāk gan Apple, ja izgatavos konkurentu NetBookiem, tad tas kārtējo reizi būs kaut kas revolucionārs, kas mainīs cilvēku priekšstatu par to, kādam ir jābūt īstam NetBookam. Apple atbilde par NetBookiem:
We're watching that space, but from our [point of view] the products are based on hardware that's much less powerful, software technology that's not good, cramped displays. We don't think that people are going to be pleased with those type of products. It's a category we watch, we have some ideas here, but we think the products there now are inferior and won't provide the kind of experience people want.
Nu ko - gaidīsim - gan jau Apple gatavo mums kaut ko interesantu! :)
trešdiena, 2009. gada 7. janvāris
trešdiena, 2008. gada 17. decembris
Last Macworld
Šodienas ziņas, kas izplatījušās pa internetu liek patiesi aizdomāties, kas notiks ar Apple - kompāniju, kuru vērtēju visaugstāk. Šodien Apple izplatījuši paziņojumu, ka 2009. gada MacWorld būšos pēdējais šāda veida pasākums, jo kompānijai esot visai daudzi citi varianti, kā sasniegt savus patērētājus. Taisnība jau ir, bet ne jau par to ir stāsts. Stāsts ir par faktu, ka pēdējo MacWorldu nevadīs Steve Jobs, bet gan mārketinga viceprezidents - Filips Šillers. Protams, visu cieņu Šilleram, bet šāds pavērsiens tomēr vēl aizvien vairāk liek aizdomāties, ka Stiva veselība vairs nepavisam nav tāda kādu to Apple ir centies attēlot, savukārt Apple bez Stīva pašlaik ir visai grūti iedomāties. Protams, plāni, noteikti, ka ir un diez vai šāda kompānija var pazust vienā dienā, tomēr droši neko nevar apgalvot.
svētdiena, 2008. gada 7. decembris
Alumīnija MacBooku RAM nesaderība
Šodien atradu rakstu par jauno alumīnija MacBooku RAM savietojamību - visai daudziem lietotājiem, kas MacBookos ievieto ne no Apple pirkto RAMu, dators sāk gļukot un uzkārties. Vienīgais, ko varu ieteikt - vai nu RAMu pirkt no Samsung, vai arī pagaidīt līdz FirmWare upgrade - gan jau problēma tiks atrisināta. Sīkāka informācija - TUAWā.
Abonēt:
Ziņas (Atom)
