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.
Jag har länge varit skeptiskt till Windows-mobilernas framtid och hade inte trott att det kunde vara något intressant som skulle dyka upp. Men när jag såg Microsofts presentation igår på MWC blev jag imponerad. Gränssnittet och animeringarna är underbara. Det gick att provköra på en stor touch screen och jag tycker att känslan verkligen är klockren. De verkar ha lyckats göra ett gränssnitt som är mer anpassat för mobilen än tidigare windows mobile-versioner. Väl genomtänkt.
Integreringen med andra system är också bra. Visserligen har väl Zune aldrig varit så stort, men det är nu integrerat i systemet. Zune Market finns även kopplat till telefonen. Därutöver är även Xbox Live var kopplat till det samt vanliga Live och Facebook. Alla flöden som dyker upp är snyggt integrerade i gränssnittet som var väldigt minimalistiskt och snyggt.
De säger att de gjort om allt från grunden och att det prestandamässigt ska ligga mycket nära det simulatorn visade idag. Jag är väldigt skeptisk till det, men om prestandan kan vara bra så vill jag jag åtminstone ha en Windows Phone för att testa.
Är det en iPhone-dödare då? Det tror jag verkligen inte, men det ser lovande ut och Microsoft kommer nog kunna behålla en hel del Windows Mobile-användare. Det största problemet lär bli att få företag och utvecklare som vill utveckla för annat än iPhone och Android.
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.
Integreringen med andra system är också bra. Visserligen har väl Zune aldrig varit så stort, men det är nu integrerat i systemet. Zune Market finns även kopplat till telefonen. Därutöver är även Xbox Live var kopplat till det samt vanliga Live och Facebook. Alla flöden som dyker upp är snyggt integrerade i gränssnittet som var väldigt minimalistiskt och snyggt.
