Error Operation could not be completed. (Cocoa error 134100.)
När du ändrat i dina CoreData-modeller så blir det alltid fel och det brukar normalt räcka med att köra en reset på iPhone Simulator, men den här gången räckte det inte. En timme senare inser jag att det här behöves köra en “Clean all targets” så fungerade allt igen. Litet litet tips…
För att byta mellan set av strängar kan du antingen göra en fullfjädrad localization. Ett alternativ att använda hantera strängar och språk manuellt i appen. Du kanske bara vill hantera olika sträng-set på ett överskådligt och uppdelat sätt.
Skapa en strings-fil:
Välj New File -> Strings File och döp filen till något du känner igen. Om det handlar om att separera språk så kan du exempelvis kalla den se.strings eller en.strings.
Sen fyller du på med nycklelvärden och strängar enligt:
Om du sedan vill hämta ut någon sträng – exempelvis “start”-strängen vilken ska översättas till “Hem” (i från ovan fil som heter se.strings) använder du bara:
NSLocalizedStringFromTable(@”start”, @”se”, nil);
Det första värdet är alltså namnet på “nyckeln”, det andra vilken fil, eller tabell, du vill läsa ifrån.
Du kan skicka med vilka parametrar du vill i dina push-notiser. Förutom badge-nummer, notisljud och notistext kan du skicka med extra-data som din app kan plocka upp i det NSDictionary-objekt som du tar emot via:
Om du skapat ett Coredata-objekt med en uppsättning attribut och automat-genererat en klass kan det hända att du vill ändra en set-funktion. I mitt fall ville jag exempelvis nyligen uppdatera “tid för senaste updatering” samtidigt som jag favorit-markerade ett objekt.
I och med att alla Coredata-attribut är @dynamic kan du inte sätta värden som om det vore en vanlig @property utan du använder dig av Key Value Coding:
Det viktiga här är, för det första, att du använder willChangeValueForKey och didChangeValueForKey. Sen kan du använda setValue: forKey: vilket jag fått att fungera för NSString-attribut, men inte för NSNumber – så använd setPrimitiveValue: forKey: istället. Vad jag förstått är det generellt att föredra.
Hade en app som fungerade perfekt med SBJSON-encoder/decoder (som jag har sett och hört fler använda med goda resultat). Det har varit så för mig väldigt länge…
MEN… Helt plötsligt fick jag felmeddelanden utan att ha ändrat någon närliggande kod. Det klagades på att key-values inte var rätt separerade osv.
Det verkar som att den decodern inte klarar av för långa strängar och när json-flödet växte så gav den upp. Jag hittade istället TouchJSON vilken fungerade perfekt. Decodar på följande vis:
Efter att ha rensat upp och strukturerat om min projektfil och tillhörande resurser slutade mitt projekt helt plötsligt att fungera. Det enda felmeddelandet jag fick upp var:
Failed to launch simulated application: Unknown error.
Efter att ha spenderat någon timme med att lista ut varför, kollat /var/log/system.log och googlat inser jag att många har haft samma problem, men inte alla hittar lösningen. Vanligtvis kan det räcka med att tömma cache:n i XCode eller reset:a iPhone Simulator, men i mitt fall räcker det inte.
Vad löste då problemet?
Jo, det var så enkelt som att vissa mappnamn inte är okej. Jag hade först döpt en resurs-mapp, som använder sig av folder-references, till Resources och därefter ExternalResources – båda vållade problem. Sen döpte jag mappen till samma namn som appen vilket också gav problem tills jag slutligen valde namnet Material. Och helt plötsligt fungerar projektet precis som det ska.
Konstigt att XCode inte kan ge ett korrekt felmeddelande när man försöker kompilera och testköra, men nu vet jag åtminstone att jag inte ska döpa externa resursmappar till något med resources eller något som innehåller app-namnet.
iPhone-appar med många bilder som kanske uppdateras under utvecklingsarbetet kan ställa till det. Det finns två metoder i XCode för att hålla reda på resurser – antingen med mappreferenser eller enkelt grupperat – båda medför problem. Särskilt när du uppdaterar redan existerande bilder.
Efter att manuellt ha lagt till eller tagit bort filer hittade jag den här artikeln på majicjungle.com som innehåller en smidig lösning. Det går ut på att du lägger till ett skript som körs varje gång du kompilerar. Scriptet kör bara en “touch” på resurskatalogen med exempelvis bilder, vilket leder till att XCode ser att katalogen är uppdaterad och tar med den nya versionen i bundle:n.
För att lägga till scriptet så behöver du bara:
Högerklicka på din target, välj “New Run Script Build Phase” enligt bilden ovan.
Byt shell till tcsh och gör en touch på din resurskatalogs sökväg, baserat på var den ligger i förhållande till projektfilen (se bild). I mitt fall lägger jag dem oftast i samma katalog och skriver därför följande: touch -cm ${SRCROOT}/Resources
Flytta ordningen så att scriptet körs först av allt i the build phase (se bild).
Klart!
För mig fungerade det här klockrent både vid skapande och uppdatering av bildresurser. Hur fungerar det för er? Ni kanske har något annat tips?
Du kan ha ställt in allting rätt för din profile, men det fungerar ändå inte.
Det kanske är fler som listat ut att det räcker med en enda “expired” provisioning profile för att det inte ska fungera. Det behöver inte ens vara profile:n för just den appen du ska köra – det fungerar ändå inte. Lösningen är dock enkel – det är bara att ta bort den profile:n som har gått ut så fungerar det igen.
När deadlines:en haglar är det svårt att ta sig tid till att blogga. Däremot har jag fått lite mer tid till iPhone-spelande då jag flyttat utanför tullarna igen, så jag här följer en lista på mina favoriter vad gäller spel just nu, istället för en ambitiös bloggpost.
I en nyligt publicerad artikel på TechCrunch och även på AppleInsider framkommer rykten om att det skett ytterligare en policyförändring som innefattar fler typer av appar – de som anses vara för grundläggande. Appar som inte är mer än en RSS-läsare ges som exempel på de som kan få problem i granskningsprocessen.
Jag har själv inga problem med att man tar bort appar som inte är appar – exempelvis de som bara rakt av är använder sig av en webbvy eller listar ett rss-flöde. Att kvalitén på AppStore håller någon slags rimlig grundnivå tycker jag är bra. Men de närmsta dagarna kommer vi nog få veta mer exakt vad det här innebär och vilka typer av appar som det här berör.
MWC har kickat igång och i och med Adobes satsning på mobilplattformar, senast iPhone var de självklart på plats. Med min bakgrund som flashutvecklare är Adobe:s iPhone-satsning självklart intressant att hålla koll på. En av de som arbetar med iPhone och mobil-exporten i största allämnhet var där och jag passade på att fråga ut honom.
Tydligen har Adobe c:a 400 flashutvecklare som just nu testar deras iPhone-inriktning. Och till skillnad från vad man kan se på Adobe:s hemsida menade han bland annat att det just nu finns 40 st appar på AppStore som är gjorda via Flash, fast de har inte rätt att publicera namnen på dessa på adobe.com. Det är intressant! Jag skulle gärna veta vilka fler appar som gjorts och se om de är bättre än de exempel som finns på adobe.com.
Jag frågade även om prestandan och tog upp att jag inte var helt nöjd med prestandan på de spel jag sett exporterade till iPhone och provat på en 3G. Han höll med men tillade att samma spel flyter bättre på exempelvis en Android-telefon, samtidigt han även sa att de jobbar vidare med optimering samt koppling till iPhone:s GPU. iPhone-exportmöjligheter kommer finnas i Flash CS5, men han sa att det kommer vara beta-stadie även på det och han ville inte ge någon tidsram för när systemet kan anses vara komplett. Adobe arbetar även på ett white paper för optimering rent generellt som ska underlätta för utvecklare att skriva hårdare optimerade program och spel.
Har inte sett det här själv förut men såhär ser export-rutan ut. Du behöver alltså bara fylla i dina grunduppgifter från iPhone Developer Programme, lägga in certifikatet och sen exporteras en färdig app. Att kompilera direkt till telefonen kommer inte fungera, men allting förbereds så att det bara är att dra och släppa till iTunes för att installera på din iPhone.
Passade även på att kolla in källkoden på ett av programmen som använde multi-touch och jag måste spontant säga att det såg ganska enkelt ut att programmera.
När jag frågade vad han trodde om Flash för iPhone sa han bland annat att han förstår att Apple inte vill ta in Flash av strategiska skäl.
I samband med iPad-vakan på Carnaby förra veckan kodade jag snabbt ihop en app, så fort den nya utvecklingsmiljön släppts för allmänheten. iPad-appen visade en bild på mig i röd mössa och en adress till min hemsida – något som vanligtvis inte imponerar på någon.
På plats var dock iPhone24 som bevakade eventet och bilder på min kreation lades upp med formuleringar som ”Världens första iPad-app är svensk” och ”den redan nu legendariska appen”. Allting med glimten i ögat såklart.
Redan på kvällen började det spridas på twitter och när jag vaknade dagen efter och som vanligt började med att kolla twitterflödet ser jag retweets och mentions. Jag blev dock väldigt förvånad då mitt namn så småningom dök upp i flödet tillsammans med MacWorld, som publicerat en artikel med rubriken ”Svensk ligger bakom första iPad-appen”.
Jag blev ännu mer förvånad när även Metro Teknik ringer upp mig samma dag för en intervju – en intervju som publicerades i onsdags med rubriken ”Svensken som gjorde första appen till iPad”.
De senaste dagarna har jag blivit gratulerad till den lyckade PR-kuppen, vilket är väldigt roligt, men det roligaste för min egen del är att “PR-kuppen” var lika oplanerad som utfallet var oväntat.
Huruvida det tillhör världens första kompilationer kan ifrågasättas. Det mest intressanta i min mening är dock att en sån här, till synes ointressant, app kan få spridning och även nå traditionella medier. Detta skulle dels kunna visa på det enorma intresset för iPad. Men det bekräftar framförallt att journalister, på ett annat sätt än tidigare, bevakar vad som bedöms vara intressant genom att hålla koll på aktiviteter inom sociala medier.
Avslutningsvis, var detta en väldigt rolig vecka för en utvecklare som vanligtvis inte syns så mycket i medier. Nästa gång det händer hoppas jag dock kunna visa upp en app som i sig är imponerande.
