David Quinlan è un ragazzo normale, con posti di lavoro al giorno e solo un po 'di esperienza di codifica. Ma lui e un amico ha vissuto il sogno piegato a gomito e una semplice applicazione iPhone in un weekend. Ecco come hanno fatto:
"Thai, insalata o ramen?" E 'ora di pranzo in un tipico Giovedi e ci colpisce che milioni di persone in tutto il mondo stanno meditando la stessa domanda. Questa domanda è il nostro avvio, facendo di noi una parte di migliaia di persone che volevano costruire un iPhone app per "quel".
Sono un ragazzo di prodotto e di marketing con alcune competenze di progettazione e codifica.
Roy è uno sviluppatore con alcuni esperti di business. Combinato, facciamo una grande squadra e si integrano reciprocamente le competenze bene, ma abbiamo solo iniziato a lavorare con Objective-C lo scorso anno, come molti altri che stanno sperimentando lo sviluppo iPhone. Abbiamo già costruito un app o due, per cui siamo a conoscenza della lingua e dei quadri. Tuttavia, come con tutti i nuovi progetti, di solito hanno a che fare una piccola ricerca per capire come affrontare le varie problematiche ... soprattutto in un mondo definito da 320 × 480 pixel.
Per lungo tempo, abbiamo giocato un po 'con l'idea di creare un'applicazione per il divertimento. Dopo aver scartato un paio di buone idee (perché erano troppo complessa o una rapida ricerca su App Store ha dimostrato che qualcun altro ha già bene), all'ora di pranzo ci terre su un semplice, un'idea divertente per aiutare le persone bloccato tra le decisioni.
Ma mentre la maggior parte vuole creare un grande app iPhone, il mio amico e io andare un passo oltre, fare un patto per completare il progetto entro un week-end o realisticamente, la nostra applicazione non si sarebbe mai completato.
Su un pezzo di carta, scarabocchi su due-tre wireframe e sviluppato uno schema per alcune schermate di base. Siamo noi a decidere su una applicazione che offre fino a tre scelte multiple. È possibile scrivere le vostre risposte, ad esempio, Thai, insalata o ramen e basta scegliere una scelta casuale per vedere la risposta alla vostra decisione. Decidiamo di utilizzare le carte da gioco, come il tema. Immediatamente, abbiamo il cerchio "deve avere" caratteristiche (priorità assoluta), allora il "come avere" caratteristiche (ultima priorità) e, infine, le caratteristiche che più bisogno di indagare. Lasciamo il pranzo a Giovedi compiti a casa con un po 'e un piano per ottenere insieme il Sabato.
I miei compiti in particolare di determinare l'aspetto, il tatto e l'interazione su ogni schermo. Roy ha bisogno di ricerca alcune delle caratteristiche di Xcode non abbiamo avuto la possibilità di giocare con ancora nel nostro "veri" posti di lavoro, soprattutto le animazioni e la randomizzazione.
Sabato mattina, ci incontriamo in un negozio locale di caffè che era Wi-Fi gratuito, far valere un grande tavolo in modo che possiamo siedono fianco a fianco e prendere la prima di molte tazze grandi di caffè. Poi possiamo creare una cartella condivisa Dropbox per questo progetto-un account base è gratuito e viene fornito con 2 GB di storage. Il Dropbox è importante perché ci permette di multitask per lo stesso progetto con qualsiasi / tutte le modifiche di sincronizzazione in tempo reale. Per i progetti più grandi, si può prendere in considerazione GitHub.
Ci fermiamo un profilo più dettagliato di quello che vogliamo compiere per la nostra applicazione, nonché wireframe di base. Dato che abbiamo solo un fine settimana per completare questo app, abbiamo deciso di concentrarsi solo sul "devono avere" caratteristiche. Uno sviluppatore può sempre rilasciare aggiornamenti funzione in una data successiva per includere il "bello avere" caratteristiche.
Schermo Going-by-schermo, si dettaglio gli elementi sulla pagina, trattamenti di stile, layout, tempi, ecc Abbiamo anche discutere che cosa Roy imparato a conoscere l'animazione del movimento flip della carta, poiché questa è stata una delle funzionalità di base del app. Abbiamo brevemente in rassegna i Quartz 2D e librerie Core Animation, dal momento che non avevamo fatto in precedenza un lavoro con quelli. Abbiamo anche discutere con un UIWebView per rendere l'animazione all'interno di CSS di WebKit. Infine, troviamo una soluzione semplice utilizzando UIViews standard e UIButtons. La classe UIView ha alcuni metodi della classe di animazione, e uno dei costruita nel transizioni è un effetto flip. Per quanto riguarda la randomizzazione, sapevamo maggior parte delle lingue fornisce una funzione random, e Objective-C non fa eccezione. Ai fini di questa applicazione, tutto ciò che voleva era un metodo semplice per randomizzare un array. Roy trovato un paio di esempi di questo, ma uno che spiccava era finita sul sito Dr. Touch. Egli descrive un approccio con il quale attuare un metodo di estensione della classe in modo da poter facilmente shuffle qualsiasi matrice.
Ci immergiamo nelle nostre rispettive MacBook Pro con un Borg-like concentrarci sulle nostre aree di competenza. I aprire Photoshop e cominciò a costruire schermi. La prima schermata è l'immagine di default. Questa è la schermata molto prima, quando le persone vedono l'applicazione si avvia e inizia a caricare. Applicazioni possono essere costruite sia in verticale o sul paesaggio. Se si sceglie di costruire la vostra applicazione in vista del paesaggio come il nostro, è ancora necessario per creare una immagine di default che visualizza in visualizzazione verticale. Semplicemente creare la vista del paesaggio e ruotare in senso orario o antiorario (a seconda se si desidera visualizzare il panorama a sinistra oa destra). Ora i carichi di immagini predefinito in visualizzazione verticale ma dal momento che le immagini si ruota, l'utente verrà svolta l'iPhone per visualizzare il panorama.
Ho poi passare il prossimo paio d'ore la creazione di composizioni, immagini di sfondo, bottoni, carta (fronte e retro) e la pagina info. Ho anche passare del tempo concentrandosi su l'icona app. Questo è ovviamente il "volto" della vostra applicazione, un distintivo d'onore, così ti vuoi mettere il pensiero attento in immagini icona. Ricordate, è necessario l'icona in entrambe le 57 × 57 e 512 × 512 dimensioni. Una volta completato, ho caricarlo al set in modo che Roy potrebbe iniziare a utilizzare gli elementi creativi.
Con il tempo ho sguardo indietro al laptop di Roy, ha creato un progetto Xcode nuovo ed è già giocando con il codice per animare le caselle verdi che flip su un clic. Mentre sta lavorando sul prototipo in iPhone Simulator, mi afferra il Info.plist file e modificare alcune impostazioni - rimuovere la barra di stato, il nome visualizzato app, rimuovere lucido da icona, ecc Abbiamo poi decide che è tempo per noi di aggiungere un po ' immagini reali al nostro prototipo. Abbiamo messo in l'immagine di sfondo, la fronte e retro delle carte e dei pulsanti di navigazione. Il posizionamento è spento (da un sacco), ma le carte un bell'aspetto ed è flipping senza intoppi. Facciamo qualche calcolo male, ma alla fine ottenere la distanza esatta e il posizionamento che vogliamo per ogni scheda. Noi giocare con i tempi del flip, impostare l'stati on / off per il pulsante di navigazione e ora si sente abbastanza bene.
Vedendo i pezzi si riuniscono in app mi dimostra che ci sono un paio di immagini che ha bisogno di fine tuning. I apportare modifiche come Roy inizia a lavorare sullo schermo la personalizzazione e lo schermo info. La personalizzazione dello schermo è il luogo che permette alle persone di tipo in tutto quello che vogliono mostrare il volto della carta. Ci limitiamo a 25 caratteri ... nulla di più e si scrive sopra / al di fuori della carta. Parliamo attraverso questo schermo di un po 'più in dettaglio. The interaction in each field, how the keyboard acts, and how we save before going back to the cards. We spend a bit of time in Interface Builder wiring up exactly how we want this page to look and act. The info page is completely optional, but we like to have it because it includes additional ways to reach us.
Wow, seven hours and fours large coffees later, we have a lot done, but there's still lots more to go. What we have now is an app that fires up; displays a default loading screen; gets people to a screen that shows three cards (back of the card showing); they can select any/all of the cards and the cards flips to show the front of the card; they can click on a button labeled “Try Again” to reset the cards; they can click on a button labeled “Customize” that opens a new screen; the “Customize” screen allows you to enter text into 3 separate fields with a max of 25 characters in each field; and you can get to the Info screen. We spend the last hour of the day together cleaning up code and discussing what we have left to accomplish tomorrow.
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.
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.
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.
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.
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. 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 .
Source
Gizmodo
