David Quinlan é um cara normal com o trabalho do dia e apenas um pouco de codificação da experiência. Mas ele e um amigo viveu o sonho e dobrado para fora um iPhone app simples em um fim de semana. Veja como eles fizeram isso:
"Salada tailandesa, ou ramen?" É hora do almoço em uma típica quinta-feira e parece-nos que milhões de pessoas em todo o mundo estão pensando a mesma pergunta. Esta questão é a nossa barra de lançamento, tornando-nos parte de milhares de pessoas que queriam construir uma app iPhone para "aquilo".
Eu sou um cara de marketing do produto e com algum desenho e técnicas de codificação.
Roy é um colaborador com alguma experiência em negócio. Combinada, fazemos uma grande equipa e se complementam as habilidades bem, mas só começou a trabalhar com Objective-C no ano passado, como muitos outros que estão tentando para fora do desenvolvimento do iPhone. Nós já construiu uma app ou dois, então nós estamos familiarizados com a linguagem e frameworks. Entretanto, como com todos os novos projetos, normalmente você tem que fazer uma pequena pesquisa para entender a forma de abordar os diferentes desafios ... especialmente em um mundo definido por 320 × 480 pixels.
Durante muito tempo, nós brincávamos com a idéia de criar um aplicativo para se divertir. Depois de descartar um par de boas ideias (porque eram demasiado complicado ou uma pesquisa rápida na App Store mostrou que alguém já faz isso bem), as terras do almoço nós em uma simples idéia divertida para ajudar as pessoas presas entre as decisões.
Mas enquanto a maioria das pessoas quer criar um iPhone app grande, meu amigo e vou um pouco mais longe, fazendo um pacto para terminar o projeto dentro de um fim de semana ou realista, nosso aplicativo nunca seria concluída.
Em um pedaço de papel, rabiscar a nós dois, três wireframes e desenvolveu um esboço de algumas telas de base. Nós decidimos em um aplicativo que oferece até três escolhas múltiplas. Você pode escrever suas próprias respostas, por exemplo, tailandês, salada ou ramen e você simplesmente pegar uma escolha ao acaso para ver a resposta à sua decisão. Decidimos usar cartas de jogar como o tema. Imediatamente, o círculo que "devem ter" características (prioridade), então o "gostaria de ter" características (última prioridade), e finalmente as características que precisava de mais investigação. Saímos do almoço na quinta-feira com um pouco de casa e um plano para se reunir no sábado.
Minha casa inclui a determinação do olhar, sentir e interação em cada tela. Roy precisa de investigação de algumas das características do Xcode não tivemos a chance de jogar com ainda no nosso "real" de empregos, principalmente animações e randomização.
Na manhã de sábado, nos encontramos em um café local, que tinha livre acesso Wi-Fi, a reivindicação de uma grande mesa para que possamos sentar-se lado a lado e pegue o primeiro de muitos grandes xícaras de café. Então vamos criar uma pasta compartilhada Dropbox para este projeto, uma conta básica é grátis e vem com 2 GB de armazenamento. O Dropbox é importante porque nos permite multitask no mesmo projeto com qualquer / sincronizar todas as alterações em tempo real. Para projetos maiores, você pode querer considerar GitHub.
Paramos em frente de um quadro mais detalhado do que queremos realizar para a nossa aplicação, bem como wireframes básicos. Dado que só temos uma semana para concluir este app, decidimos focar apenas o "devem ter" características. Um desenvolvedor pode sempre emitir atualizações de recursos em data posterior a incluir o "bom ter" características.
Going tela por tela, detalhe que os elementos da página, os tratamentos de estilo, layout, horários, etc Também discutimos o que Roy aprendi sobre animação movimento virar o cartão, uma vez que esta foi uma das principais funcionalidades do aplicativo. Nós revemos o Quartz 2D e bibliotecas Core Animation, uma vez que não haviam feito nenhum trabalho com aqueles. Chegámos mesmo a discutir com um UIWebView para tornar a animação dentro CSS WebKit. Finalmente, encontramos uma solução simples usando UIViews padrão e UIButtons. A classe UIView tem alguns métodos da classe de animação, e uma das transições é construído em um efeito flip. Quanto ao sorteio, sabíamos que a maioria dos idiomas fornecer uma função aleatória, e Objective-C não é excepção. Para os fins desta aplicação, tudo o que queríamos era um método simples para embaralhar um array. Roy encontrou um par de exemplos disso, mas uma que se destacou foi lá no site do Dr. Touch. Ele descreve uma abordagem com que a implementação de um método de extensão de classe para que você possa facilmente shuffle qualquer matriz.
Mergulhamos em nossos respectivos MacBook Pros com um Borg-como o foco em nossas áreas individuais de especialização. Eu abro o Photoshop e começou a construção de telas. A primeira tela é a imagem padrão. Esta é a primeira tela muito as pessoas vêem quando o aplicativo inicia e começa a carregar. Apps podem ser construídas em retrato ou paisagem. Se você optar por construir seu aplicativo no modo paisagem como a nossa, você ainda precisa criar uma imagem padrão que exibe no modo retrato. Basta criar a sua visão da paisagem e girar no sentido horário ou anti-horário (dependendo se você quer para a esquerda ou da paisagem à direita). Agora o padrão carrega a imagem no modo retrato, mas desde as suas imagens é rodado, o usuário vai torcer o iPhone a paisagem.
Eu, então, passar o próximo par de horas criando composições, imagens de fundo, botões, cartão (frente e verso) e da página de informações. Eu também gastar algum tempo incidindo sobre o ícone do aplicativo. Esta é, obviamente, a "cara" do seu aplicativo, uma medalha de honra, assim que você vai querer pôr o pensamento cuidadoso na imagem do ícone. Lembre-se, você terá o ícone tanto no 57 × 57 e 512 × 512 tamanhos. Depois de concluído, eu envio para Dropbox para que Roy pode começar a utilizar os elementos criativos.
Até o momento eu olhar para trás para laptop de Roy, ele criou um projeto Xcode novo e já está a brincar com o código para animar caixas verdes que virar em um clique. Enquanto ele está trabalhando no protótipo do simulador do iPhone, eu pegar o arquivo info.plist e editar algumas das configurações - remover barra de status, nome de exibição app, retire brilho de ícone, etc Em seguida, decide que é hora de acrescentar alguns imagens reais para o nosso protótipo. Colocamos na imagem de fundo, frente e verso dos cartões e os botões de navegação. O posicionamento está fora (por muitos), mas as placas com bom aspecto e é virar suavemente. Nós fazemos um pouco de matemática ruim, mas, eventualmente, obter o espaçamento de exatas e de posicionamento que queremos para cada cartão. Nós brincar com o calendário do flip, defina a on / off-Membros para o botão de navegação e agora está se sentindo muito bem.
Vendo as peças em conjunto com o aplicativo mostra-me que há um par de imagens que precisa de ajustes finos. Posso fazer alterações como Roy começa a trabalhar na tela de personalização e ecrã de informações. Personalizar a tela é o local que permite que pessoas com o tipo de tudo o que queremos mostrar na face do cartão. Nós limitar a 25 caracteres ... nada mais que isso e escreve sobre / fora do cartão. Estamos a falar através deste ecrã um pouco mais em pormenor. A interação em cada campo, como os atos de teclado, e como podemos salvar antes de voltar para os cartões. Passamos um pouco de tempo no Interface Builder fiação acima exatamente como queremos que esta página para olhar e agir. A página de informações é totalmente opcional, mas nós gostamos de tê-lo porque ele inclui outras formas de chegar até nós.
Wow, sete horas e quatro cafés grande tarde, temos feito muito, mas ainda há muito mais para onde ir. 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. Nós finalmente o fez.
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. O que quero dizer? 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. Teste. Teste. 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 .
Fonte
gizmodo
