David Quinlan is een normale man met baan en net een beetje van codering ervaring. Maar hij en een vriend woonde de droom en aangezwengeld een eenvoudige iPhone app in een weekend. Hier is hoe ze het hebben gedaan:
"Thai, salade of ramen?" Het is een typische lunch op donderdag en het lijkt ons dat miljoenen mensen over de hele wereld dezelfde vraag worden peinzen. Deze vraag is onze launchpad, waardoor we een deel van de duizenden mensen die wilden een iPhone app te bouwen voor "dat.
Ik ben een product en marketing vent met een aantal ontwerpen en codering vaardigheden.
Roy is een ontwikkelaar met een aantal business savvy. Gecombineerd maken we een goed team en vullen elkaars vaardigheden goed, maar we gaan werken met Objective-C vorig jaar, net als vele anderen die proberen de iPhone ontwikkeling. We hebben al gebouwd een app of twee, dus we vertrouwd bent met de taal en kaders. Echter, zoals met alle nieuwe projecten, heb je meestal een beetje onderzoek doen om te begrijpen hoe de verschillende uitdagingen aanpak ... vooral in een wereld die door 320 × 480 pixels.
Voor de langste tijd hebben we gespeeld rond met het idee om een app voor de lol. Na het zich ontdoen van een paar goede ideeën (omdat ze te ingewikkeld zijn of een snelle zoekactie in de App Store is gebleken dat iemand anders al doet dat goed), lunch landt ons op een eenvoudige, leuk idee om mensen vastzitten tussen beslissingen te helpen.
Maar terwijl de meeste mensen willen een grote iPhone app, mijn vriend maken en ik ga nog een stap verder, waardoor een pact om het project te voltooien binnen een weekend-of realistisch, zouden onze app nooit voltooid.
Op een stuk papier, we krabbelen uit twee tot drie wireframes en ontwikkelde een schema voor een aantal fundamentele schermen. We besluiten op een app die biedt tot drie meerdere keuzes. U kunt uw eigen antwoorden, bijvoorbeeld Thaise, salade of ramen en kies je gewoon een gerandomiseerd keuze om het antwoord op uw beslissing. We besluiten om gebruik speelkaarten als het thema. Onmiddellijk, cirkel we de "must have" features (eerste prioriteit), dan is de "willen hebben" features (laatste prioriteit), en ten slotte de functies die meer onderzoek nodig. We verlaten de lunch op donderdag met een beetje huiswerk en een plan om samen te komen op zaterdag.
Mijn huiswerk omvat het bepalen van de kijken, voelen en interactie op elk scherm. Roy moet een aantal van de Xcode onderzoek functies die we hebben niet de kans gehad om te spelen met nog in onze 'echte' banen, voornamelijk animaties en randomisatie.
Op zaterdag ochtend, komen we bij een lokale koffieshop dat was gratis Wi-Fi, aanspraak maken op een grote tafel, zodat we elkaar kunnen zitten-by-side en pak de eerste van vele grote koppen koffie. Dan hebben we een gedeelde Dropbox map voor dit project-een Basic account aanmaken is gratis en wordt geleverd met 2 GB opslag. De Dropbox is belangrijk omdat het laat ons toe om meerdere taken tegelijk aan hetzelfde project met een / alle veranderingen te synchroniseren in real time. Voor grotere projecten kan u overwegen GitHub.
We trekken een meer gedetailleerd overzicht van wat we willen bereiken voor onze app als basis wireframes. Gezien het feit dat we slechts een weekend om deze app te voltooien, besluiten we om alleen richten op de "must have" features. Een ontwikkelaar kan altijd kwestie feature updates op een later tijdstip om de "nice to have" features.
Going scherm-voor-scherm, detail we de elementen op de pagina, de stijl behandelingen, layout, timing, enz. We bespreken ook wat geleerd over Roy animeren flip beweging van de kaart, want dit was een van de belangrijkste functionaliteit van de app. Wij kort overzicht van de Quartz 2D-en Core Animation bibliotheken, omdat we nog niet eerder gedaan geen werk met deze. We hebben zelfs bespreken met behulp van een UIWebView te maken binnen de animatie WebKit CSS. Uiteindelijk vinden we een simpele oplossing met behulp van standaard UIViews en UIButtons. De UIView klasse heeft animatie-klasse methoden, en een van de ingebouwde in transities is een flip-effect. Wat de randomisatie, wisten we dat de meeste talen bieden een willekeurige functie, en Objective-C is geen uitzondering. Voor de toepassing van deze app, alles wat we wilden was een eenvoudige methode om een array willekeurig. Roy vond een paar voorbeelden van deze, maar een die erop stond was meer dan op de website van Dr Touch. Hij beschrijft een aanpak waarmee een klasse uitbreiding methode te voeren zodat u gemakkelijk shuffle een array.
We duiken in onze respectieve MacBook Pro's met een Borg-achtige focus op onze individuele terreinen van deskundigheid. Ik open Photoshop en begon gebouw schermen. Het eerste scherm is het standaard beeld. Dit is het eerste scherm mensen zien wanneer de app start en begint het laden. Apps kunnen worden gebouwd in beide portret of landschap te bekijken. Als u ervoor kiest om uw applicatie te bouwen in het landschap als de onze, moet u toch om een standaard afbeelding die wordt weergegeven in het portret te bekijken. Maak gewoon je landschap en draai met de klok mee of tegen de klok in (afhankelijk van of je links of rechts landschap). Nu de standaard afbeelding belastingen in portret bekijken, maar aangezien uw beelden is gedraaid, zal de gebruiker draai de iPhone naar landscape modus.
Vervolgens heb ik besteden de komende paar uur creëren comps, achtergrondafbeeldingen, knopen, kaart (voor-en achterkant) en de info pagina. Ik heb ook enige tijd gericht op de app pictogram. Dit is natuurlijk het "gezicht" van uw app-een badge van eer-dus je zult willen zorgvuldig gedachte gebracht op het pictogram beeldmateriaal. Vergeet niet, moet u het pictogram in zowel de 57 × 57 en 512 × 512 maten. Eenmaal voltooid, upload ik het naar Dropbox zodat Roy kon beginnen met de creatieve elementen.
Tegen de tijd dat ik blik terug naar de laptop van Roy, hij is een nieuwe Xcode project en is nu al te spelen met code om groene vakken die flip animeren op een klik. Terwijl hij werkt op het prototype in de iPhone Simulator, pak ik de Info.plist bestand en bewerk een aantal van de instellingen - Verwijder de statusbalk, app weergegeven naam te verwijderen uit het pictogram glans, etc. Wij dan is het tijd voor ons om te beslissen wat toe te voegen echte beelden van onze prototype. We hebben in de achtergrond afbeelding, de voor-en achterkant van de kaarten en de navigatie knoppen. De positionering is uitgeschakeld (door een veel), maar de kaarten zien er goed uit en het is flipping soepel. We doen enkele slechte wiskunde, maar uiteindelijk krijgt de exacte afstand en de positionering die we willen voor elke kaart. We spelen rond met de timing van de klep, stelt u de aan / uit-landen voor de navigatie-knop en nu is het gevoel redelijk goed.
Het zien van de stukken komen samen in de app toont me dat er een paar beelden die moet fine tuning. Ik veranderingen aanbrengen als Roy gaat werken aan het aanpassen van scherm en info scherm. Het aanpassen scherm is de plaats die mensen in staat stelt in te typen wat ze willen laten zien op het gezicht van de kaart. We beperken het tot 25 tekens ... iets meer dan dat en het schrijft over / buitenkant van de kaart. We praten via dit scherm een beetje meer in detail. De interactie op elk gebied, hoe het toetsenbord werkt, en hoe we slaan alvorens terug te gaan naar de kaarten. We besteden een beetje tijd in Interface Builder bedrading exact hoe we willen deze pagina te kijken en te handelen. De info-pagina is volledig optioneel, maar we willen hem hebben omdat het extra manieren om ons te bereiken omvat.
Wow, zeven uur en fours grote koffie later, hebben we veel gedaan, maar er is nog veel meer te gaan. Wat we nu hebben, is een app die branden op; toont een standaard laad scherm krijgt mensen aan een scherm dat drie kaarten (achterkant van de kaart zien) toont aan, ze kan elk selecteren / alle kaarten en de kaarten draait om aan te tonen van de voorkant van de kaart, ze kunnen klikken op een knop met het label "Try Again" om de kaarten opnieuw, zij het label kunt u op een knop "Customize", dat een nieuw scherm opent, het "Customize" scherm kunt u tekst invoeren in 3 aparte velden met een max van 25 tekens in elk veld, en u kunt het Info-scherm. We besteden het laatste uur van de dag samen schoonmaak code en bespreken wat we hebben verlaten te volbrengen morgen.
Op zondag komen we op een andere koffieshop met gratis Wi-Fi. Koffie eerste. We voelen ons alsof we ongeveer 80 procent gedaan voordat we beginnen opnieuw te werken. Het belangrijkste werk over voor de komende dag is het opslaan van de aangepaste tekst, het weergeven van de aangepaste tekst op de voorkant van de kaart, en randomizing de tekst. We hadden extra functionaliteit ideeën, maar we blijven onszelf eerlijk, en hield de reikwijdte kruipen tot een minimum. Een voorbeeld hiervan is de methode voor het opslaan / opslaan van de aangepaste tekst over elk van de drie kaarten. 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.
While Roy is working on those items, it's a perfect opportunity for me to prepare some of the things we'll need later that day. When you submit an app to the App Store, it's not a simple upload of a file. Apple requires the following information for every app submission: Application Name, Application Description, Device Requirements, Primary and Secondary Category, Subcategories, Copyright, App Rating, Keywords, SKU Number, Application URL, Screen shots, Marketing Description, Support URL, Support Email Address, End User License Agreement, and Pricing / Availability.
So, I prep all the app submission information while Roy is busy coding away, first searching the App Store for similar apps and their names. We like “Stuck?” and luckily no one else is using it, so we go with that name. 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.
Wat is er de neiging om langer duren dan je verwacht, en hoewel we in principe klaar bent met de app door vroege zondagmiddag, besteden we nog een paar meer uren tweaken en bereid alles voor de App Store indiening reinigen code en fine tuning als we mee. We besteden het merendeel van de dag op een computer te duwen pixels, opmaak, en zorgen voor de timing en de interactie van de gebruiker was precies zoals we allebei wilden. Na bijna vijf uur werk op zondag, hebben we de app dat we beiden voor ogen. We beginnen testen in de iPhone simulator en vervolgens op apparaten (zowel de iPhone en iPod touch) voor de stabiliteit en functionaliteit. Nogmaals, dat een eenvoudig app, was het eenvoudig en snel te testen.
Na bewezen stabiliteit, besluiten we te publiceren Stuck? de App Store. Mijn eerste poging om publicatie van een andere app door mij duurde twee dagen-poging mislukt, Google, proberen, falen, Google meer, enzovoort, totdat het eindelijk werkte. Maar de tweede keer was veel makkelijker en sneller. Wij kopiëren / plakken alle tekst eerder bereid en voegde de screenshots en beelden. Al met al hebben we onze app geladen in ongeveer 15 minuten. Op dit punt zijn we enthousiast, hongerig en moe, maar ook heel trots dat we een solide afgesloten app meer dan een weekend in een coffeeshop.
We hadden onze vingers gekruist dat de App Store ons app zou goedkeuren. 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. 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. Wat ik bedoel? 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 .
Bron
gizmodo
