David Quinlan är en vanlig kille med vanliga jobb och bara lite kodning erfarenhet. Men han och en vän levde drömmen och vevas en enkel iPhone app i en helg. Här är hur de gjorde det:
"Thai, sallad eller ramens?" Det är lunchtid på en typisk torsdag och det slår oss att miljontals människor över hela världen har funderat på samma fråga. Denna fråga är vår Launchpad, gör oss till en del av de tusentals människor som ville bygga en iPhone app för "det."
I'ma produkt och marknadsföring kille med lite design och kodning färdigheter.
Roy är en utvecklare med några affärer smartare. Kombinerad gör vi ett bra team och kompletterar varandras kunskaper väl, men vi bara börjat arbeta med Objective-C förra året, liksom många andra som provar iPhone utveckling. Vi har redan byggt en app eller två, så vi är förtrogen med språket och ramar. Men som med alla nya projekt, har du brukar göra lite forskning för att förstå hur man skall närma de olika utmaningar ... speciellt i en värld som definieras av 320 × 480 pixlar.
Under längst tid, har vi lekte med idén att skapa en app för skojs skull. Efter att kasta ett par goda idéer (eftersom de var alltför komplicerad eller en snabb sökning i App Store visade att någon annan redan har det bra), lunchtid landar vi på ett enkelt, roligt att idén hjälpa människor fastnat mellan beslut.
Men medan de flesta människor vill skapa en stor iPhone app, min vän och jag går ett steg längre och göra en pakt för att avsluta projektet inom en helg-eller realistiskt, skulle våra ca aldrig blir klar.
På en bit papper, vi klottra ut två-tre wireframes och utvecklat ett utkast till några grundläggande skärmar. Vi beslutar om en app som erbjuder upp till tre olika val. Du kan skriva dina egna svar, till exempel, thailändska, sallad eller ramens och du helt enkelt välja en randomiserad val att se svaret på ditt beslut. Vi beslutar att använda spelkort som tema. Omedelbart, cirkel vi "måste ha" drag (första hand), sedan "vilja ha" drag (sista hand), och slutligen de egenskaper som behövs mer utredning. Vi lämnar lunch på torsdagen med lite läxor och en plan för att träffas på lördag.
Mina läxor ingår att titta, känna och interaktion på varje skärm. Roy behövs för forskning några av Xcode funktioner vi har inte haft en chans att spela med än i våra "riktiga" jobb, främst animationer och randomisering.
På lördag morgon träffas vi på ett lokalt kafé som hade gratis Wi-Fi, kräva ett stort bord så att vi kan sitta sida vid sida och ta den första av många stora koppar kaffe. Då kan vi skapa en delad Dropbox mapp för detta projekt en Basic konto är gratis och levereras med 2 GB lagringsutrymme. Den Dropbox är viktigt eftersom det tillåter oss att flera saker på samma projekt med någon / alla ändringar synkroniseras i realtid. För större projekt, kan du överväga GitHub.
Vi tar fram en mer detaljerad beskrivning av vad vi vill åstadkomma för våra app samt grundläggande wireframes. Med tanke på att vi bara har en helg att slutföra denna app, beslutar vi att fokusera enbart på de "måste ha" drag. En utvecklare kan alltid fråga funktionen uppdateringar vid ett senare tillfälle att ta med "bra att ha" funktioner.
Going screen-by-skärm, detalj vi element på sidan, stil behandlingar, layout, tidpunkt osv Vi diskuterar vad Roy lärt sig om informationsinsatser i kortets luckan rörelse, eftersom detta var en av de viktigaste funktionerna i ca. Vi granskar kortfattat Quartz 2D och Core Animation bibliotek, eftersom vi tidigare inte hade gjort något arbete med dessa. Vi diskuterar även använda en UIWebView att göra animationen i WebKit's CSS. I slutändan hittar vi en enkel lösning med standard UIViews och UIButtons. Den UIView klass har vissa metoder animation klass, och en av de inbyggda övergångar är en flip effekt. Vad gäller randomisering, visste vi de flesta språk ger en slumpmässig funktion, och Objective-C är inget undantag. I detta app, allt vi ville ha var en enkel metod att randomize en matris. Roy hittade ett par exempel på detta, men en som utmärkte sig var över på Dr Touch hemsida. Han beskriver en strategi för att genomföra en metod klass förlängning så att du enkelt kan blanda en array.
Vi dyker in våra respektive MacBook Pros med Borg-liknande fokusera på våra olika kompetensområden. Jag öppnar Photoshop och började bygga skärmar. Den första skärmen är standard bilden. Detta är den allra första bilden folk ser när app startar och börjar lasta. Apps kan byggas i antingen stående eller liggande vy. Om du väljer att bygga din app i liggande format som vårt, måste du ändå skapa en standard bild som visas i stående format. Enkelt skapa dina visuella miljön och vrid medsols eller motsols (beroende på om du vill åt vänster eller höger landskap view). Nu standardbilden belastning i stående format, men eftersom dina bilder vrids, användaren kommer vrid iPhone till liggande vy.
Jag spenderar sedan ett par timmar att skapa comps, bakgrundsbilder, knappar, kort (fram och baksida) och info sidan. Jag ägnar också tid att fokusera på App ikonen. Detta är naturligtvis "ansikte" på din app-ett Lagens Väktare, så du vill lägga noggrant tänka till ikonen bildspråk. Kom ihåg att du behöver ikonen i både 57 × 57 och 512 × 512 storlekar. När de är färdiga, jag ladda upp det till Dropbox så att Roy skulle kunna börja använda den kreativa element.
När jag blick tillbaka till Roy's laptop, han skapade en ny Xcode projekt och spelar redan runt med koden för att animera gröna lådor att knäppa på ett klick. Medan han arbetar på en prototyp i iPhone Simulator, hugg jag Info.plist filen och ändra vissa inställningar - ta bort statusfältet, app visa namn, ta bort glansen från ikon, etc. Vi sedan avgöra det dags för oss att lägga till verkliga bilder till vår prototyp. Vi lägger in en bakgrundsbild, fram-och baksidan av korten och navigeringsknappar. Placeringen är avstängd (som en del) men korten ser bra ut och det är nonchalansen smidigt. Vi gör några dåliga matte, men så småningom få exakt avstånd och positionering som vi vill ha för varje kort. Vi spelar runt med tidpunkten för luckan, sätta på / av stater för navigeringsknappen och nu är det känslan ganska bra.
Ser bitar samlas i app visar mig att det finns ett par bilder som behöver finjustering. Jag gör de ändringar som Roy börjar arbeta på att anpassa skärmen och info skärm. Anpassa skärmen är den plats som tillåter människor att skriva vad de vill visa på sidan av kortet. Vi begränsar det till 25 tecken ... något mer än så och det skriver över / utanför kortet. Vi pratar igenom det här skärmen lite mer i detalj. Samspelet inom varje område, hur tangentbordet fungerar, och hur vi spara innan du går tillbaka till korten. Vi tillbringar lite tid i Interface Builder kabeldragning upp exakt hur vi vill att denna sida ska se ut och agera. Den info sida är helt frivillig, men vi vill ha det eftersom det innehåller ytterligare sätt att nå oss.
Wow, sju timmar och fyror stora kaffe senare, har vi mycket gjort, men det finns fortfarande mycket mer att gå. Vad vi har nu är en app som eldar upp, visar en skärm standard lastning, får människor att en bild som visar tre kort (baksidan av kortet visar), de kan välja någon / alla kort och korten vänder för att visa det framsidan av kortet, de kan klicka på en knapp som heter "Try Again" för att återställa korten, de kan klicka på en knapp som heter "Anpassa" som öppnar en ny skärm, "Anpassa" skärmen kan du skriva text i 3 separata fält med en max 25 tecken i varje fält, och du kan komma till Info skärmen. Vi tillbringar den sista timmen av dagen tillsammans städa upp koden och diskutera vad vi har kvar att utföra i morgon.
På söndag träffas vi på ett kafé med gratis Wi-Fi. Kaffe först. Vi känner att vi är cirka 80 procent göra innan vi börjar arbeta igen. Den stora arbete kvar för dagen framåt är rädda anpassad text, visar den anpassade texten på sidan av kortet och randomisera texten. Vi hade ytterligare funktioner idéer, men vi höll oss ärliga, och höll omfattningen krypa till ett minimum. Ett exempel på detta var den metod för att lagra / spara den anpassade texten på alla tre korten. Roy kunde ha skapat en mysql databas eller används Core Data, men den enklaste metoden var att bara använda den inbyggda standardUserDefaults objekt finns i NSUserDefaults klassen. Med denna metod lagrar värden till App inställningar lika bra för våra behov och sparar oss mycket tid.
Även Roy arbetar på dessa poster, är det ett perfekt tillfälle för mig att förbereda några av de saker vi behöver senare samma dag. När du skickar en app till App Store, det är inte en enkel uppladdning av en fil. Apple kräver följande uppgifter om varje app inlämning: Application Name Application Beskrivning, krav Device, primära och sekundära kategorin, underkategorier Copyright, App Rating, sökord Produkt nummer, Application URL, Skärmdumpar, Marknadsföring Beskrivning, Support URL, Support Epost Adress, licensavtal för slutanvändare, och prissättning / Tillgänglighet.
Så prep jag alla app lämna information samtidigt Roy är upptagen kodning bort, först söka i App Store för liknande apps och deras namn. Vi gillar "Stuck?" Och lyckligtvis ingen annan använder det, så går vi med det namnet. I create the app description, add some keywords, set the price and determine where we want to sell this app (just in the USA, certain countries or worldwide). Then I register a domain name (stuckapp.com) to be used for the application URL/support URL and linked it to a newly created Tumblr account. I also created the required support email address. The other items you'll want to prepare in advance are: screenshots (up to five), a large icon (512×512) and, if this is your first time submitting an app, any certificates/provisioning profiles.
Things tend to take longer than you expect, and even though we're basically finished with the app by early Sunday afternoon, we still spend a couple of more hours tweaking it and preparing everything for the App Store submission—cleaning code and fine tuning as we go along. We spend the majority of the day on one computer pushing pixels, formatting, and ensuring the timing and user interaction was exactly as we both wanted. After almost five hours of work on Sunday, we have the app that we both envisioned. We begin testing in the iPhone simulator and then on devices (both iPhone and iPod touch) for stability and functionality. Again, being a simple app, it was easy and quick to test.
After proving its stability, we decide to publish Stuck? to the App Store. My first attempt at publishing another app by myself took two days—attempt, fail, Google, attempt, fail, Google more, etc.—until it finally worked. But the second time around was much easier and faster. Vi kopiera / klistra in all text beredd tidigare och sedan lagt till skärmdumpar och bilder. All in all, we have our app uploaded in about 15 minutes. At this point, we're excited, hungry and tired, but also quite proud that we completed a solid app over a weekend in a coffee shop.
We had our fingers crossed that the App Store would approve our app. And, as amazed as we were that we could finish an app over the weekend, the real surprise came after we submitted to the App Store. We submitted the app on Sunday evening. It changed status from Waiting for Review‚ to In Review, on Monday. On Tuesday, we received an email informing us that our app was Ready for Sale. Approved in two days! That has to be a record‚ especially before the holidays.
Speciellt efter att ha talat om att bygga en app tillsammans så länge, som så många människor som läser denna artikel, måste jag säga, uppfyllelsen är enorm. Vi gjorde slut.
TIPS FÖR ATT FYLLA en app över en helg
1. Du kan inte göra det själv. Du kan, men du vill inte. Helst vill du att samarbeta med någon med en annan, kompletterande uppsättning färdigheter. Partner med någon som känner till och respekterar ditt område av expertis, men är ännu mer säker och kunnig om sin egen kompetens. God kommunikation är tyst i ett försök som detta så att du går igenom perioder av snabb brand frågor bolla idéer med varandra och sedan perioder av tystnad när du arbetar med skilda uppgifter. Det finns mycket att få gjort och multitasking kommer att bli avgörande.
2. Multitask. As suggested above, working with someone who complements your own skills allows you to multitask. What do I mean? For example, in the beginning, once you scratch out a wireframe of an idea, one person can begin coding - putting placeholder buttons and blocks into place. At the same time, the other person can create comps and then cut out each element to use when they get to the right stage. Also, at the tail end of the project, one person can wrap up the project and clean the code while the other prepares all the images and marketing copy for the App Store submission process.
3. Do at least one thing well. Unlike most desktop applications or web project, you have to remember that most good mobile apps fulfill a need that can come anywhere, any time. Your app idea doesn't have to be complicated, but good apps seem to do one or more of these things well:
- Solves a problem; - Is entertaining; - Serves a specific niche; - Engages the user; and/or - Takes advantage of the unique features of the iPhone.
4. Set goals and milestones. Whether your goal is speed to market, just to gain experience, or to build the best damn app that does (blank), clearly state your goals. Initially, it will help you focus on the areas that are important/critical for success. It will also help you later down the road as you face hard decisions about “must-have” features and “like-to-have” features. Remember, you can always issue feature updates so focus on the “must-have” items and do whatever is necessary to meet that goal.
5. Skaffa en Dropbox konto. För små till medelstora projekt, kan du inte slå Dropbox. Det låter dig lagra, dela och synkronisera filer med andra. Stop sharing files back and forth on your USB memory stick. Get a Dropbox account and share files in real time. We abused the hell out of our free, shared Dropbox folder and it worked flawlessly. For larger projects, you might want to give GitHub a try.
6. Test. Test. Test. When you see the finish line, it's easy to gloss over the important step of testing your app. Test in your iPhone simulator, but also try to get your hands on an iPod touch and of course on an iPhone as well. Depending on the complexity of your app, you might want to create a test plan to make sure all the use cases and functional tasks are covered. The last thing you want is to have an app in the App Store that crashes or doesn't work as expected. You may never recover from all the ego-shattering feedback.
7. Understand the App Store submission process. Apple provides a PDF document detailing to submission process. But that document is only available for registered developers. If you've already registered, read that document thoroughly before you begin the upload process. It will give you a good idea of what's involved, but also what you'll need to prepare in advance. Apple also provides some good tips for app store submission and approval .
Källa
gizmodo
