
David Quinlan er en normal fyr med mit job og bare en smule af kodning erfaring. Men han og en ven levede drømmen og forkrøppet en simpel iPhone app i en weekend. Her er, hvordan de gjorde det:
"Thai, salat eller ramen?" Det er frokosttid på en typisk torsdag, og det forekommer os, at millioner af mennesker over hele verden, er overvejelserne om samme spørgsmål. Dette spørgsmål er vores søsætning, gør os til en del af de tusindvis af mennesker, der ønskede at bygge en iPhone app for "det".
Jeg er produkt og markedsføring fyr med nogle design og kodning færdigheder.
Roy er en udvikler med nogle business savvy. Kombineret, vi gør et stort hold og supplere hinandens kompetencer godt, men vi begyndte først at arbejde med Objective-C sidste år, ligesom mange andre, der afprøver iPhone udvikling. Vi har allerede bygget en app eller to, så vi er fortrolige med sproget og rammer. Men som med alle nye projekter, du normalt nødt til at gøre lidt forskning for at forstå, hvordan man griber de forskellige udfordringer ... specielt i en verden defineret af 320 × 480 pixels.
For den længste tid, har vi legede med tanken om at oprette en app for sjov. Efter at kassere et par gode ideer (fordi de var for kompliceret eller en hurtig søgning i App Store viste, at en anden allerede gør det godt), middagstid lander vi på en enkel, sjov ide til at hjælpe folk med at komme i klemme mellem beslutninger.
Men mens de fleste mennesker ønsker at skabe et stort iPhone app, min ven og jeg går et skridt videre, hvilket gør en pagt om at afslutte projektet inden for en weekend-eller realistisk, ville vores app aldrig får afsluttet.

På et stykke papir, vi kradse ud to-tre wireframes og udviklet en skitse til nogle grundlæggende skærme. Vi beslutter, om en app, der giver op til tre flere valgmuligheder. Du kan skrive dine egne svar, for eksempel, thai, salat eller ramen-og du blot vælge et randomiseret valg at se svaret på din beslutning. Vi beslutter at bruge spillekort som tema. Straks, vi cirkel "must have" funktioner (første prioritet), så "gerne have" funktioner (sidste prioritet), og endelig de funktioner, som havde brug for mere efterforskning. Vi forlader frokost på torsdag med lidt hjemmearbejde og en plan om at mødes på lørdag.
Mine lektier omfatter fastsættelsen af udseende, føle og samspil på hver skærm. Roy er behov for forskning i nogle af de Xcode funktioner, vi har ikke haft en chance for at spille med endnu i vores "rigtige" job, hovedsageligt animationer og randomisering.
Lørdag morgen, mødes vi på en lokal café, der var gratis Wi-Fi, hævder et stort bord, så vi kan sidde side om side og fange den første af mange store kopper kaffe. Så vil vi skabe et fælles Dropbox mappe til dette projekt-en Basic-konto er gratis og leveres med 2 GB lagerplads. Det Dropbox er vigtigt, fordi det giver os mulighed for at multitaske på det samme projekt med nogen / alle ændringer synkronisering i realtid. For større projekter, kan du overveje at GitHub.
Vi trækker en mere detaljeret beskrivelse af, hvad vi ønsker at opnå for vores ca samt grundlæggende wireframes. I betragtning af at vi kun har en weekend til at fuldføre denne app, vi beslutter kun at fokusere på de "must have" funktioner. En bygherre kan altid udstede indslag opdateringer på et senere tidspunkt at omfatte "nice to have" funktioner.
Going screen-by-screen, vi nøje elementer på siden, stil behandlinger, layout, tidspunkter osv. Vi skal også diskutere, hvad Roy lært om informationstiltag i kortets klappen bevægelse, da dette var et af de vigtigste funktioner af de ca. Vi kort gennemgå de Quartz 2D og Core Animation biblioteker, da vi ikke tidligere havde gjort noget arbejde med dem. Vi har endda diskutere med en UIWebView at gøre animationen i WebKit's CSS. I sidste ende finder vi en simpel løsning ved hjælp af standard UIViews og UIButtons. Den UIView klasse har nogle animation klassens metoder, og en af de indbyggede i overgangene er en flip-effekt. Hvad angår randomisering, vidste vi de fleste sprog giver en tilfældig funktion, og Objective-C er ingen undtagelse. I forbindelse med denne app, var alt hvad vi ønskede en simpel metode til at randomisere et array. Roy fundet et par eksempler på dette, men en, der stod ud var over på Dr. Touch's hjemmeside. Han beskriver en metode til at kunne gennemføre en klasse udvidelse metode, så du nemt kan blande alle array.
Vi dykker ned i vores respektive MacBook Pro med en Borg-lignende fokus på vores individuelle fagområder. Jeg åbner Photoshop og begyndte at bygge skærme. Den første skærm er standard billede. Dette er den allerførste skærmbillede folk ser, når app starter og begynder læsning. Apps kan bygges i enten stående eller liggende visning. Hvis du vælger at bygge din app i landskabet som vores, er du stadig nødt til at oprette en standard billede, der vises i stående format. Du skal blot oprette din landskabet og rotere med uret eller mod uret (afhængigt af om du vil til venstre eller højre landskabet). Nu standardbilledet belastninger i stående format, men da dine billeder er roteret, at brugeren vil sno iPhone til liggende visning.
Jeg så bruge de næste par timer at skabe comps, baggrundsbilleder, knapper, kort (for-og bagside) og info side. Jeg vil også bruge lidt tid på at fokusere på ca ikonet. Det er selvfølgelig den "ansigt" i din app-et tegn på ære, så du ønsker at lægge nøje overveje i ikonet billedsprog. Husk, skal du ikonet i både 57 × 57 og 512 × 512 størrelser. Når først færdig, jeg uploade det til Dropbox, så Roy kunne begynde at bruge de kreative elementer.

Af den tid, jeg blik tilbage til Roy's bærbare computer, har han skabt en ny Xcode projekt og spiller allerede rundt med kode til at animere grønne bokse at vende på et klik. Mens han arbejder på prototypen i iPhone Simulator, jeg fat Info.plist fil og redigere nogle af indstillingerne - fjerne statuslinjen, app visningsnavn, fjerne glans fra ikon, osv. Vi beslutter derefter er det tid for os at tilføje nogle virkelige billeder til vores prototype. Vi lægger i baggrundsbilledet, for-og bagsiden af kortene og navigationsknapperne. Positioneringen er slukket (ved en masse), men kortene se godt ud og det er pokkers gnidningsløst. Vi har nogle dårlige matematik, men til sidst får den nøjagtige afstand og placering, som vi ønsker for hvert kort. Vi leger med timingen af klappen, indstille on / off stater til sejlads på knappen, og nu er det følelse pretty good.

Seeing stykkerne samles i app viser mig, at der er et par billeder, der skal finjustering. Jeg foretage ændringer som Roy begynder arbejder på at tilpasse skærmen og info-skærmen. Tilpas skærmen er det sted, der giver folk mulighed for at skrive i, hvad de ønsker at vise på forsiden af kortet. Vi begrænse det til 25 tegn ... noget mere end det, og det skriver i / uden for kortet. Vi taler gennem denne skærm en smule mere i detaljer. Samspillet i hvert område, hvor tastaturet fungerer, og hvordan vi sparer før de går tilbage til kortene. Vi bruger en smule tid i Interface Builder ledninger op nøjagtigt, hvordan vi ønsker denne side til at se og handle. Den info side er helt valgfrit, men vi vil gerne have det, fordi det omfatter flere måder at nå os.
Wow, syv timer og fours store kaffe senere, har vi en masse gjort, men der er stadig meget mere at gå. Det, vi har nu, er en app, at brande sig, viser en standard loading skærmen, får folk til en skærm, der viser tre kort (bagsiden af kortet, der viser), og de kan vælge / alle de kort og kortene vender for at vise forsiden af kortet, kan de klikke på en knap der hedder "Try Again" for at nulstille de kort, de kan klikke på en knap der hedder "Tilpas", der åbner et nyt skærmbillede, på "Tilpas" skærm giver dig mulighed for at indtaste tekst i 3 separate områder med en max på 25 tegn i hvert felt, og du kan komme til Info-skærmen. Vi bruger den sidste time af dagen sammen rense kode og diskutere, hvad vi har tilbage til at udføre i morgen.

On Sunday, we meet at another coffee shop with free Wi-Fi. Coffee first. We feel like we're about 80 percent done before we start working again. The major work left for the day ahead is saving the custom text, displaying the custom text on the face of the card, and randomizing the text. We had additional functionality ideas, but we kept ourselves honest, and kept the scope creep to a minimum. One example of this was the method for storing/saving the custom text on each of the three cards. Roy could have created a sqlite database or used Core Data, but the easiest approach was to just use the built in standardUserDefaults object found in the NSUserDefaults class. Using this method stores the values to the app's settings just fine for our needs and saves us a lot of time.

Mens Roy arbejder på disse punkter, er det en perfekt mulighed for mig at forberede nogle af de ting, vi får brug for senere på dagen. Når du indsender en app til App Store, er det ikke en simpel upload af en fil. Apple kræver følgende oplysninger for hver ca indsendelse: Application Name, Application Beskrivelse, Enhed Krav, primære og sekundære kategori, underkategorier, Copyright, App Rating, søgeord, SKU Number, Application URL, skærmbilleder, Marketing Beskrivelse, support URL, Support Email adresse, Slutbrugerlicensaftale, og prisfastsættelse / Tilgængelighed.
Så jeg prep alle app indsendelse oplysninger, mens Roy er optaget kodning væk, først søge i App Store for tilsvarende apps og deres navne. Vi kan godt lide "Stuck?", Og heldigvis ingen anden, der bruger det, så går vi med dette navn. Jeg opretter app beskrivelse, tilføje nogle søgeord, indstille prisen og bestemme, hvor vi ønsker at sælge denne app (kun i USA, visse lande eller hele verden). Så jeg registrere et domænenavn (stuckapp.com), der skal bruges til ansøgningen URL / support URL og knyttet det til et nyoprettet Tumblr konto. Jeg har også skabt den nødvendige støtte e-mail-adresse. De andre elementer, du ønsker at forberede sig på forhånd: screenshots (op til fem), en stor ikon (512 × 512) og, hvis det er første gang, du indsender en app, certifikater / provisioning profiler.
Ting har en tendens til at tage længere tid end du forventer, og selv om vi dybest set er færdig med den app i begyndelsen af søndag eftermiddag, vi stadig bruge et par timer mere tweaking og tilberedning af alt for App Store indsendelse-rengøring kode og finjustering vi går langs. Vi bruger størstedelen af dagen på en computer presse pixels, formatering og sikre timing og brugerinteraktion var præcis, som vi begge ønskede. Efter næsten fem timers arbejde om søndagen, har vi den app, at vi begge forestillede sig. Vi begynde at teste i iPhone-simulatoren og derefter på enheder (både iPhone og iPod touch) for stabilitet og funktionalitet. Igen, er en simpel app, det var nemt og hurtigt at teste.
Efter at bevise sin stabilitet, beslutter vi at offentliggøre Stuck? til App Store. Mit første forsøg på at offentliggøre en anden app, som jeg selv tog to dage-forsøg, mislykkes, Google, forsøg, mislykkes, Google mere osv., indtil det endelig virkede. Men i anden omgang var meget lettere og hurtigere. Vi copy / paste al tekst udarbejdet tidligere og derefter tilsættes de screenshots og billeder. Alt i alt har vi vores app uploadet i cirka 15 minutter. På dette punkt, er vi glade for, sultne og trætte, men også ganske stolt over, at vi gennemført en solid app over en weekend i en café.

Vi havde fingrene krydset, at App Store vil godkende vores ca. Og så overrasket som vi var, at vi kunne afslutte en app over weekenden, den virkelige overraskelse kom efter vi har sendt til App Store. Vi har forelagt app søndag aften. Det ændrede status fra Venter på Review, In Review, på mandag. Tirsdag, modtog vi en e-mail informere os, at vores app var klar til salg. Godkendt på to dage! Det må være en rekord, især inden ferien.
Især efter at have talt om at opbygge en app sammen så længe, som så mange mennesker at læse denne artikel, må jeg sige, Opfyldelsen er enorm. Vi gjorde det.

TIPS for at gennemføre en APP på en weekend
1. You can't do it yourself. You can, but you wouldn't want to. Ideally, you want to partner with someone with a different, complementary set of skills. Partner with someone who knows and respects your area of expertise, but is even more confident and knowledgeable about their own skills. Good communication is implied in an effort such as this so you'll go through periods of rapid fire questions bouncing ideas off each other and then periods of silence as you work on separate tasks. There's a lot to get done and multitasking will be key.
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. Get a Dropbox account. For small- to medium-sized projects, you cannot beat Dropbox. It allows you to store, share and synchronize files with others. 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 .
Kilde
gizmodo