Need a plan of attack
Mon, 2011-11-07 18:56
Like everyone, I assume I have some good ideas for apps I'd like to make. Some simple, some not. I've still got some work to do with understanding some of the concepts in obj-c and c++ but I figure the best way is to start building something. I went to the effort of sketching on an A3 piece of paper 7 iphone screens and sketching how I thought the app would look and then I read the intro to one of the TicTacToe videos that said it was a bad Idea to jump into a graphical app before you had the code done ... this leads me (ever-so-slowly) to my question.
- What things do I need to keep in mind as I construct an app that will be later ported to Xcode/iphone etc? What sort of input/ouput considerations should I keep in the back of my mind while building something in pure console-based code.
- Also, would it be a good idea to code my app in C++ to better sharpen those tools and then convert it to Obj-C later?
And, in what could be worthy of a separate post, I find that most of my ideas will need a database of some kind to hold stored information. In it's simplest form, think "shopping list" app type scenario. I find that many of the Wibit apps don't address this storage concept (although there was many early videos on reading and writing to files).
Thanks for any advice anyone may have in this area.
I'm thinking that if I EVER sell ANYTHING on iTunes, I would donate a % to Wibit ... but don't get to excited. I'm looking at a market of perhaps 10 people world-wide
Thu, 2011-11-10 00:52
#2
I've never done any iOS development, but the way I like to run projects is via agile.
You take the project and break it down into smaller chunks based on what you want it to do. Ex: as a user I'd like to be able to touch a button to bring up my information. Then you write the code to perform that action. You have to first set out to determine all of your "user stories" (the chunks) and then attack them one by one. There is a lot more to it than that but if its a private project with no deadline or client this'll get you going. It makes something really big seem really manageable.
Thu, 2011-11-10 04:08
#3
Yeah, Agile Development can be pretty neat. We used that all the time when I used to work as Web Developer. Short version of the Wikipedia article is:
1. Set up "User stories" that describes tasks you want to do as a user, make sure they are broken down as much as possible. An example is "As a user I would like to add a note that contains a title, body and date", "As a user I would like to edit a note", "As a user I would like to share notes", "As a user I would like to see a list of notes", "As a user I would like to set completed status on notes" etc.
2. Identify and group the user stories into an efficient structure that can be used to describe your app in terms of objects
3. Code it :)
4. A million other things that's not really important in a private project as rejvanton stated :D
Sat, 2011-11-12 06:33
#4
Thanks all! I'll have to check out the Agile Dev. stuff. For now, I might stick with a small app that I sketch out and make sure it works. I think the mistake is to start too big. I will probably take the move of NOT doing my iOS app and perhaps taking all the Wibit labs and making it my goal to turn them into iOS apps first. That should teach me a lot about development and give me much needed skills.
I might have to think about the read/write aspects a bit more and you cna be sure I'll be back with more questions when that happens.
Tue, 2011-11-15 15:57
#5
Cool, you're gonna have a fun little project :D
I always find myself getting tripped up and having to do alot of refactoring and recoding due to bad or completely lack of planning :P
Wed, 2011-11-16 17:19
#6
The big thing is to not be afraid of the task. Development can be large and complex, but just like anything else... if you manage the large project as a ton of tiny projects then you can manage it better and keep tabs on your progress.
The development practice that works for me is ground up. I dream up the functionallity the program must provide and then I develop my Model layer, which will contain all of the lower level functionallity. You can compare this to our TicTacToe model class where Bryan and I wrote the game logic with absolutly no GUI at all.
After I build all the low level functionallity, then move into the View layer, which is designing user Interface. Drawing sketches of your ideal UI is a GREAT idea. A lot of developers do it. Some take it as far as mocking up the UI in Photoshop (or something like that). This gives you (the developer) and any one else that is working on the project something physical to see and shoot for.
Once your ideas are on paper, then begin to design the UI. Make no serious effort to integrate with code at first OTHER THAN giving your UI elements easy to recall names (like a text label should be called something like lbl_Username and an image img_WiBitLogo). Using prefixes in your variable names will allow you to identify them easier when coding, AND autocomplete will organize them for you. So if you want to access an image but can't remember the name you can just type 'img_' and get a list of all your images.
After your GUI is realized, then work on the Controller layer, which is wiring your GUI to your Model code. This can be painful sometimes (especially in ObjC) but it is where your program comes to life.
Lastly, if you do not plan to port your app, just go ahead and write it in Objective-C. Don't focus on C++, cause not all code translates 100%. Code translation can be a real pain in the ass sometimes.
I hope this helps! And GOOD LUCK!!! We're going to hold you to your promise to donate a % of the earnings to us 
Sat, 2011-11-26 02:54
#7
Progress has been made but boy is it slow. Don't go thinking that slow means I've really got half way there - I"m talking like 0.0001% complete. Even that may be in the wrong direction. I have gotten to the point (in amongst flights, work and other commitments) that I wrote down most of the code to do some functionality. I was then busy for a few days and forgot what the hell the project was in the first place. It would be easier if my job was in the same area ...
I'll post my progress in the other thread ....
Kevin - I think I might continue in the c++ realm for now. I only have a PC with me all the time and the mac is at home so I might tackle that as a complete project. At this stage it can only help me to do a project twice from teh ground up in two languages.
Thanks agian.
Tue, 2011-11-29 09:27
#8
Often times I find out later that I'm closer than I feel to my goal.
I would recommend just focusing on one language at a time for now, and don't try to think to far down the road. Just work on having the confidence to be able to cross any bridge you come across when you get there.
Bryan
Wed, 2012-06-27 07:16
#9
The large factor is usually to not scared of the work. Growth may be big and sophisticated, but just like everything else... just try the larger undertaking like a lot of small assignments then you can definitely keep it in check far better and an eye on how you're progressing
<a href="http://www.ppiclaimco.org/ppi-reclaim"/>visit here</a>
Forum Rules/Features
Welcome to the WiBit.net forums! Check out our terms and features:
Hot Topic(s)
Annoy your friends
Is this something you think someone else would enjoy? Is it not for you, but do you know someone who is down with this type of content? Well share away:
Tweet
The Blog
Don't Let XML Make You a Cheater
This blog is a reminder that cheating in software development can get you into big trouble. Sometimes developers get really really lazy, OR are pressured to write something using overly simplified data structures. Almost every time this happens you are bitten in the butt! Sometimes the problems show up immediately and other times it may take months or years (especially in integrated systems).
- 1 of 78
- ››
I think what you are doing in skecthing out the app screens is great. It's definately the way to go.
The next thing you could/should do before getting into coding is to try to layout the functionality of each screen in some sort of program-flow-diagram. This is so you can map what functions, buttons, actions and other handlers you might need. If you do not plan your code before starting to code it is almost a certainty that you will get lost and start mixing Model/View/Controller code. Once that happends it is easy to get lazy and lost and all of a sudden you might find yourself rewriting alot of code over and over again. If you plan your functions, what they will do and what they will return, you will have a much easier time writing the code.
Regarding input you could "simulate" all the actions on iOS with a terminal app I suppose. You could use terminal commands to be able to do different gestures, touches and swipes. I think the important bit to remember is that the action that is to be performed should not be dependent on the action itself. So if you have an "addNote()" function it should add the note however you call it. If it's a touchEvent that fires the function call or if it's a "click" command from the terminal.
If you do this "planning" you could get away with not writing a terminal app before implementing the GUI. It could still be a good idea though since practice makes perfect :). It is also near to impossible to get the planning part perfect so of course you will have to adjust. But then you will at least have a basic framwork to adjust to. I'm sure you can find some great flow diagram resources on the web. The idea with writing a terminal app first is that it is easier to debug since it will not contain so many confusing elements. It's sort of "starting small and the building on top of that".
Storage can be achieved in different ways. I know very little of iOS programming but I'm sure they must have some SQL/SQL lite database that your app and create and use for data storage. There are probably CRUD (CreateReadUpdateDelete) classes on the web you can use to get started for the database handling. Android and alot of other systems use SQL-lite for data storage.
Hope this helps you some :D