David Quinlan er en normal fyr med jobben, og bare litt av koding erfaring. Men han og en venn levde drømmen og cranked ut et enkelt iPhone app i en helg. Her ser du hvordan de gjorde det:
"Thai, salat eller ramen?" Det er lunsjtid på en vanlig torsdag og det slår oss at millioner av mennesker over hele verden grublet det samme spørsmålet. Dette spørsmålet er vår Launchpad gjør oss til en del av tusenvis av mennesker som ønsket å bygge en iPhone-app for "det."
I'ma produkt og markedsføring fyr med litt design og koding ferdigheter.
Roy er en utvikler med noen forretninger peiling. Kombinert, gjør vi et godt team og utfyller hverandres kompetanse godt, men vi bare begynte å arbeide med Objective-C i fjor, som mange andre som prøver ut iPhone utvikling. Vi har allerede bygget et program eller to, så vi er kjent med språket og rammeverk. Men som med alle nye prosjekter, du må som regel gjøre lite forskning for å forstå hvordan de skal nærme seg ulike utfordringer ... særlig i en verden som er definert av 320 × 480 piksler.
I lang tid har vi lekte med ideen om å lage et program for moro skyld. Etter å kaste et par gode ideer (fordi de var for komplisert, eller et raskt søk i App Store viste at noen andre allerede gjør det bra), lunsj lander vi på en enkel og morsom idé hjelpe folk fast mellom beslutninger.
Men mens de fleste ønsker å lage en stor iPhone app, min venn og jeg går et skritt videre, og gjør en pakt for å fullføre prosjektet innenfor en weekend-eller realistisk, ville vår app aldri fullført.
På et stykke papir, scribble vi ut to-tre wireframes og utviklet en disposisjon for noen grunnleggende skjermer. Vi bestemmer på en app som tilbyr inntil tre flere valg. Du kan skrive dine egne svar, for eksempel, thai, salat eller ramen og du bare velge en randomisert valg til svaret på din beslutning. Vi velger å bruke spille kort som tema. Umiddelbart, sirkel vi "må ha"-funksjoner (første prioritet), deretter "liker å ha"-funksjoner (siste prioritet), og til slutt funksjonene som trengte mer undersøker. Vi forlater lunsj torsdag med litt lekser og en plan for å komme sammen på lørdag.
Min lekser inkluderer bestemme utseende og samhandling på hver skjerm. Roy må forskningen noen av Xcode funksjonene vi har ikke hatt en sjanse til å spille med, men i vår "virkelige" arbeidsplasser, hovedsakelig animasjoner og tilfeldig.
På lørdag morgen, møtes vi på en lokal kafé som hadde gratis Wi-Fi, kreve et stort bord slik at vi kan sitte side ved side og grip den første av mange store kopper kaffe. Da skaper vi en felles Dropbox mappe for dette prosjektet-en grunnleggende konto er gratis og kommer med 2GB lagringsplass. Det Dropbox er viktig fordi den gir oss muligheten til flere ting samtidig på samme prosjekt med noen / alle endringer synkroniseres i sanntid. For større prosjekter, kan du vurdere GitHub.
Vi trekker opp en mer detaljert oversikt over hva vi ønsker å oppnå for app våre samt grunnleggende wireframes. Gitt at vi bare har en helg til å fullføre denne app, bestemmer vi å fokusere bare på "må ha"-funksjoner. En utbygger kan alltid problemet funksjonen oppdaterer på et senere tidspunkt å inkludere "kjekt å ha" funksjoner.
Going screen-by-screen, detalj vi elementer på siden, stil behandlinger, layout, tidspunkt, osv. Vi kan også diskutere hva Roy lært om animere kortets flip bevegelse, siden dette var en av de viktigste funksjonaliteten til ca. Vi kort gjennom Quartz 2D og Core Animation bibliotekene, siden vi hadde ikke tidligere gjort noe arbeid med dem. Vi diskuterer også bruke en UIWebView gjengi animasjonen innenfor WebKits CSS. Til syvende og sist finner vi en enkel løsning å bruke standard UIViews og UIButtons. Det UIView klassen har noen animasjon klasse metoder, og en av de innebygde overganger er en flip effekt. Som for tilfeldig, visste vi at de fleste språk gir en tilfeldig funksjon, og Objective-C er intet unntak. I dette app, alt vi ønsket var en enkel metode for å randomize en matrise. Roy fant et par eksempler på dette, men en som skilte seg ut var over på Dr. Touch nettsted. Han beskriver en tilnærming som å implementere en klasse forlengelse metoden slik at du enkelt kan shuffle noen array.
Vi dykket i våre respektive MacBook Pro med en Borg-lignende fokus på våre individuelle kompetanseområder. Jeg åpner opp Photoshop og begynte å bygge skjermene. Den første skjermen er standard bildet. Dette er den aller første skjermen folk ser når programmet starter og begynner å laste. Apps kan bygges i enten stående eller liggende visning. Hvis du velger å bygge din app i liggende visning som vårt, du fremdeles nød å lage et bilde som vises i stående visning. Bare lage din liggende visning og dreie med eller mot urviseren (avhengig av om du vil venstre eller høyre liggende visning). Nå standardbildet belastninger i stående visning, men siden bildene blir rotert, brukeren vil vri iPhone til liggende visning.
Jeg så tilbringe de neste par timer å lage komposisjoner, bakgrunnsbilder, knapper, kort (foran og bak) og info-side. Jeg har også bruke litt tid på å fokusere på app-ikonet. Dette er åpenbart "ansikt" på ca dine et skilt med ære-så du vil sette nøye tenkt ut ikonet bilder. Husk, trenger du ikonet i både 57 × 57 og 512 × 512 størrelser. Når ferdig, laster jeg det til Dropbox slik at Roy kan begynne å bruke kreative elementer.
Da jeg blikket tilbake til Roy's bærbare har han opprettet en ny Xcode prosjekt og er allerede å spille rundt med koden for å animere grønne boksene vende på et klikk. Mens han arbeidet med prototypen på iPhone Simulator, grip jeg Info.plist filen og endre noen av innstillingene - fjern statuslinjen app visningsnavnet, fjerne glans fra ikon, osv. Vi deretter bestemmer det på tide for oss å legge til noen virkelige bilder til prototype vår. Vi satt i bakgrunnsbildet, og baksiden av kortene og navigasjonsknappene. Plasseringen er av (etter mye), men kortene ser bra ut og det er pokkers glatt. Vi gjør noen dårlige matte, men etter hvert få eksakt avstand og plassering at vi ønsker for hvert kort. Vi spiller rundt med timingen av flippen, sette på / av stater for navigering knappen, og nå er det følelsen ganske bra.
Seeing brikkene samles i programmet viser meg at det er et par bilder som må finjustere. Jeg gjør endringer som Roy begynner arbeidet med å tilpasse skjermen og info skjerm. Tilpass skjermen er stedet som gjør at folk kan skrive inn hva de vil vise på forsiden av kortet. Vi begrenser den til 25 tegn ... noe mer enn det og den skriver over / utsiden av kortet. Vi snakker gjennom denne skjermen litt mer i detalj. Samspillet i hvert felt, hvordan tastaturet fungerer, og hvordan vi lagre før du går tilbake til kort. Vi bruker litt tid i Interface Builder ledningsnett nøyaktig hvordan vi ønsker at denne siden skal se ut og handle. Opplysningen siden er helt frivillig, men vi liker å ha den fordi den inneholder flere måter å nå oss.
Wow, syv timer og fire store kaffe senere, har vi mye gjort, men det er fremdeles mye mer å gå. Hva vi har nå er en app som fyrer opp, viser en standard loading skjermen, får folk til en skjerm som viser tre kort (baksiden av kortet viser), de kan velge hvilken som helst / alle kort og kortene vende å vise forsiden av kortet, de kan klikke på en knapp merket "Try Again" for å nullstille kortene, de kan klikke på en knapp merket "Tilpass" som åpner et nytt skjermbilde, "Tilpass"-skjermen lar deg skrive inn tekst i 3 separate felt med maks 25 tegn i hvert felt, og du kan komme til Info skjermen. Vi tilbringer den siste timen av dagen sammen rydde opp koden, og diskutere hva vi har igjen å gjøre i morgen.
På søndag møter vi en annen kaffebar med gratis Wi-Fi. Kaffe først. Vi føler at vi er ca 80 prosent ferdig før vi begynner å jobbe igjen. De viktigste som gjenstår for dagen fremover er redde tilpasset tekst, viser tilpasset tekst på forsiden av kortet, og randomizing teksten. Vi hadde ekstra funksjonalitet ideer, men vi holdt oss ærlige, og holdes omfanget krype til et minimum. Ett eksempel på dette var den metoden for lagring / lagre tilpasset tekst på hver av de tre kortene. Roy kunne ha skapt en SQLite database eller brukes Core Data, men det enkleste tilnærming var å bare bruke den innebygde standardUserDefaults gjenstand funnet i NSUserDefaults klassen. Ved hjelp av denne metoden lagrer verdiene til app innstillinger bare bra for våre behov og sparer oss for mye tid.
Mens Roy jobber med disse elementene, er det en perfekt anledning for meg å forberede noen av de tingene vi trenger senere samme dag. Når du sender inn en app til App Store, er det ikke en enkel opplasting av en fil. Apple krever følgende informasjon for hver app innlevering: Søknad Navn, Søknad Beskrivelse, Device Krav, grunnskole og videregående kategori, eller lyd, Copyright, App Rating, nøkkelord, SKU Antall, Søknad URL, skjermbilder, Marketing Beskrivelse, Support URL, Support Email Adresse, End User License Agreement, og Priser / Tilgjengelighet.
Så prep jeg alle app innsending informasjon mens Roy er opptatt koding bort, først søke i App Store for tilsvarende programmer og navnene deres. Vi liker "Stuck" og heldigvis ingen andre bruker den, så vi gå med det navnet. Jeg oppretter app beskrivelse, legg noen søkeord, sett prisen og bestemme hvor vi ønsker å selge denne app (bare i USA, bestemte land eller globalt). Så jeg registrere et domenenavn (stuckapp.com) skal brukes til søknaden URL / support URL og koblet den til en nyopprettet Tumblr konto. Jeg har også laget den nødvendige støtte for e-postadresse. 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. We copy/paste all the text prepared earlier and then added the screenshots and images. 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.
Vi hadde våre fingrene krysset at App Store ville godkjenne våre ca. 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.
Especially after talking about building an app together for so long, like so many people reading this article, I must say, the fulfillment is immense. We finally did it.
TIPS FOR COMPLETING AN APP OVER A WEEKEND
1. Du kan ikke gjøre det selv. Du kan, men du vil ikke vil. 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. Hva mener jeg? 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
