i have never done embedded (i dont know if thats what you call this) programming and know nothing about it. my question:
is it possible to have two devices sharing a wireless connection (no internet, just between themselves, perhaps bluetooth, but i dont know what ever is best) ?
is it possible to have one editing a file and the other person editing the same file and they can see changes in real time? sort of like google docs?
does this exist already?
what can i do to get started regarding this kind of programming?
to clarify:
i want two people with iphones or any other hand held device, to be able to edit a text file at the same time and see each other's changes in real-time. how do i do this?
There are a bunch of slightly strange assumptions hidden in your questions. I'll try to unpick them as best as I can.
You've used "embedded" programming in a strange way. Usually this would suggest some kind of low-power devices used in settings without direct user interaction in some sense (e.g. factory controllers, refrigerator controllers, sensor nodes), performing a very specific task, but you've gone on to talk bout people editing files. What exactly would be the user interface here? What would make this embedded programming? I think you need to describe an application before any advice can be offered.
If you actually mean embedded devices, then whether they can connect wirelessly to one another is going to depend on the nature of the device. Similarly, the protocol/technologies involved will depend on the device. Embedded programming tends to be very much device-specific. There certainly exist wireless sensor nodes, for example, that incorporate small radio transceivers for serial comms.
Google docs already exists. Without a clearer problem description it's difficult to say whether what you want exists already or not.
I think you should really figure out exactly what kind of programming it is that you want to do before we can offer points as to how to best get started with it. Maybe look up a definition of "embedded programming" and see how this relates to your goals such that you can reformulate your questions a little more clearly.
I'm not sure how "real time" would fit into this scenario either. This term is used and abused in many ways. Things are only ever real-time with respect to some constraint, usually defined in terms of the application.
(Note: This might have been more appropriate as a comment, but I felt there was too much to respond to in order to sum up within character limits, and I hope correcting some of the confusion constitutes something of an answer, given the limitations of the question).
Two devices can share a connection like this. It's done all the time. There are many many protocols for this. Weather or not it is wired or wireless or uses the Internet doesn't really matter for 90% of this.
This is sort of doable, but not really. You really have a race condition when two people are editing at the same time. This is generally avoidable by locking out small parts of the document at from all but one editor at a time (like only one person being able to edit one cell of a spreadsheet at a time), but this has problems too (like of the one active editor is taking way too long -- this is a problem seen in many source version control systems too).
1 already exists in many many forms. 2 sort of exists in many forms, but the problems I mentioned are impossible to completely overcome.
The way you asked this question leads me to believe that you are very far from being able to do this. In addition, you didn't tell us anything about what you do know how to do. Can you write a simple text editor for an iPhone (or anything else)? Simple text editors from scratch that aren't crappy aren't easy to write.
What you need to do, if you really want to do this, is to come up with a protocol for the two (or more) devices to talk to each other in. To do this it is probably best if you figure out what type of communication is available between the devices and which of those you will use and what features it does not provide that you will need on top.
You could try to send patches of the file (or something similar) between the two devices as edits are made, but then you'll have to decide what to do in the event of a collision (edits near the same place).
Alternately you could have the two devices exchange permission to make edits (like in token ring networks).
You still have a problem if the two devices lose communication with each other during the editing of the file, though. With the token ring type setup you stand the possibility of losing the token and neither being able to automatically recover easily. Whatever you do you end up with the problem of the two ending up with different ideas of the file's contents.
"iphones or any other hand held device" - the technology stack to do that doesn't exist today. You have to co-ordinate between multiple languages and systems. (Okay, maybe you want to write that software, but it's a huge undertaking).
Your best bet would be to create a web page that all of the mobile browsers can work on and save a text file from.
Of course it's possible. Bluetooth does this. Wi-Fi does this if you join an ad-hoc network.
Of course it's possible. Just run the Google Docs server on one of the devices.
It might.
Way too vague.
Related
I'm writing an iPhone game and I am trying to write some requirements documents. I have never written requirements before so I got the book Software Requirements. I have not finished it yet, but I forsee some issues, as this book is targeted towards a business. My main question is I am the only person involved with this game and I feel the main purpose of the requirements document should be to nail out as many conceptual ideas of how the game works as I can before I am deep into design or construction. Does anyone have suggestions on how I should lay this out, should I still try to mimic the template provided in the book where it makes sense, or since I am both the sole developer and product owner, should I just stick to game concepts?
You're right that traditional SRS documents don't really fit games documentation all that well. Games instead have a general Game Design Document. It's usually created before any work on the game begins, and it's often edited as the development process goes to keep straight the intended end-result and specifics of the game.
While business software requirements documents are like contracts between a client and developer on what to produce, game design docs are more often specifications from the designer to the artists and programmers on what exactly they need to develop.
There is no specific layout to use. But you should consider who you're writing the document for. Is it for a class, for yourself, for peers after the project is done? The level of detail and the kind of things you include will be different depending on your audience. The format itself is very flexible, as long as it's coherent.
Brenda Brathwaite has a good blog entry on this subject which you might find helpful.
There is a semi-recent article from gamedev.net on the subject as well.
[Poor Jacob, you just read a book on the topic, and, collectively, the SO community writes another one for you, along with extra links, and probably with diverging views ;-) ]
Although I'm not familiar with the book you mention in the question, I think that the following suggestion may help you both take seriously, but also relax a bit, about the all too important question of requirements.
Being a "team of one", it is particularly important, and somewhat paradoxical, that you go through the effort of formalizing the requirements. However, rather than putting too much emphasis on the form, you may find an Agile approach to developement (and hence to requirements gathering) more appropriate. With regards to requirements, one of the main advantages of this approach, is flexibility, i.e. the understanding that while they should be formalized (with limited time/effort), requirements should be allowed to change (within limits) as part of an iterative process towards production of the target product.
In very broad terms, this generally go as follows:
write "user stories", these are individual "cards" (yes, physical cards, say 4 inches by 5 inches, are good, for you can then move then around, sort them etc.)
each story tells a particular feature of the application, here the game, from the end-user's perspective. You can/should start all cards with "As a user, I need the game to..." then follow with a particular feature, for example "... show my high score on the same page as the global high-scores are kept [because ... here optional reasons for why user may want this feature].
review each story and assign a rough estimation of the time involved in implementing it
review each story and assign a priority level (scale may vary, but something simple like "Must have from Version 1.0", "Should eventually be in there, for sure", "Would be nice to have" and "Maybe nice to have...")
organize releases, on the basis of what you can do within say 2 or 3 weeks, maximum. If a particular feature were to take too long, schedule it for a later release.
implement the features assigned to the current release
iterate through this release cycle, reviewing the requirements as you go, for the relative importance of features, and also the need of new features may become evident as with the insight provided by using the [incomplete/imperfect] intermediate releases.
Books like the one you describe are focused at a different audience, but there is value in the general concepts presented. Fully developed requirements documents are not as common as you might think. Don't let anyone think that you are a 'bad developer' for not having the most detailed requirements.
Requirements docs might be more important if you need to communicate the requirements with a co-developer.
If you are the sole developer I would strongly recommend that you spend your efforts on the design and implementation of the game, over requirements. If you have a good idea of what you build then let this flow as you build it.
Documentation can help you. The question is what is going to be most beneficial. Maybe design decisions are more critical than requirements for you but not for others. You'll maybe want to have a list of things that people have requested or ideas that you think of but cannot implement straight away. Sometimes a whiteboard can be handy for sketching out things, it's not just a tool for collaboration with other people.
Here's just a general approach...
Solidify the concept...write it in plain English first (ex: The game is a first person shooter. You kill zombies and hunt for treasure.)
Get a paper pad and pencil and draw out the general flow of the game and the main screens the users will encounter...main menu, options screen, help, etc. Make sure it makes sense.
Go to a site like mockingbird and create the detail wireframes for your screens...
Print these out and do some paper prototyping...i.e. put the printout in front of you and 'click' on a button...then bring up the appropriate screen...then click on another button, etc.
Once that makes sense, you can try to start coding your game.
Personally I believe you should use your own way to do this. The most commonly available one's will not match with your requirement. They might be suitable for a common commercial server application but not for a game. And since iPhone gaming is a new trend you may have to look in a different perspective.. You may not be able to fill a document with standard requirements and you may have different set of New type of requirements.
Just a suggestion... Sign up with Google Sites, and create a private site with documentation of the game, requirements, technical aspects, work log, etc... You can share it with select people, and it always keeps edit history.
I like it better than a Wiki because it is more structured, and just plain simple to use.
How do you design a UI like Facebook?
Is it hard to implement a custom skin into a iphone app? How is it done?
Do I need to follow apple's guideline? What if I don't want to?
How do you design a UI like Facebook?
Facebook's iPhone app appears to be built around using UITableView in various guises. It looks like it adheres to the Apple Human Interface Guidelines.
Is it hard to implement a custom skin
into a iphone app? How is it done?
Skins are just graphic elements that are designed to have their image components swapped out. They are not difficult to implement.
Do I need to follow apple's guideline?
What if I dont want to?
Apple will not penalize you for a non-standard interface. The only interface restrictions are (1) some issues of obscene content and (2) you can't create the illusion that the device itself is broken, has crashed or otherwise failed.
A bit of advice. Don't use non-standard interfaces.
Good interfaces are almost by definition standardized so that users don't have to think about them. Novel interfaces slow users down even if they have no problems otherwise. Just try switching rapidly between Mac, Windows and Linux sometimes. None of the interfaces has major problems per se but having to stop and think how to do something in each particular interface is a pain. You can create the same problem by using a good but non-standard interface within an app.
That is assuming of course that you can actually create a good interface. There are far, far more ways to make bad interfaces than there are to make good ones. Most interfaces fail even those designed by interface gods. The standardized interfaces are the result of tens of thousands of hours of testing and years of experience. You're unlikely to whip out something really new and useful your first time out.
If you try something novel I suggest you mock it up first and then test let people test it without giving them any instruction. You'd be surprised how complex it can get. We used to just make photoshop mockups and then ask test users what they thought each element did or which element they would choose to accomplish a particular task. We were surprised at how poorly our (the developers) perception of the interface overlapped with the perception of the users.
In sum, a novel interface is more likely to hurt your app than help it.
With regard to how to build an app like Facebook, check out Three20. In particular, the TTLauncherView is the class that implements the Springboard-like grid of icons.
3- You don't need to follow the AHIG. But be careful if you don't, because it's very easy to go wrong doing so. Users like to not have to learn anything new. They know the typical Apple software UI, so if you use it, users will know how to use your app as soon as they buy it. If you don't use it, it is important to make sure that the UI is exceedingly easy and intuitive, and looks good to an iPhone user's eyes (and fingers).
Are there any guidelines on pitfalls to avoid while developing iPhone applications?
Sure, thousands. The same is true for any software development. Unfortunately, the easiest way to enumerate them is to write them down on a sheet of paper while waiting for a friendly soul to release you from the one you just fell into.
However:
Don't try to reinvent the wheel. The iPhone API is very complete -- you just have to LOOK for the facility you need. Things are NOT always implemented the way you would expect. Read the guides, carefully. Look at the tutorials and analyze how they work. (Try changing a line here or there in the tutorial to see what difference the change makes.) The single biggest mistake I have made in 1 year of iPhone development is not trying hard enough to find the iPhone way of doing something.
Don't ignore memory management; master it early and often. Use the Object Allocation and Leaks tools in Instruments to check for memory leaks frequently. I'd recommend checking after you complete each feature or view; more often than that if you keep finding bugs. Eventually you may understand it so well you can stop doing this.
Don't just use the default build settings. Play around with them to understand what they do. Figure out certification and distribution. GET INTO THE DEVELOPER PROGRAM QUICKLY -- it can take a while to push through that pipeline. [ AND when you get that notification that you need to renew, get it on instantly -- there have been problems with that process. ]
Don't neglect to read the Human Interface Guidelines (HIG) carefully. If they say not to do something -- DON'T DO IT. Apple will reject applications that misuse their iconography.
Don't stint on marketing. Yes, the App Store puts your app in front of millions of people... In theory. But the odds of getting front-paged are slim. There are a lot of great apps on the App Store that haven't sold much because no one knows about them.
Don't rest on your laurels. If a new technology comes out, find out if it makes your job easier; if it does, take the time to learn it. Personal example: I'm just now trying to switch from SQLite-based data management to Core Data, because I was in a hurry at the time I started my most recent project; now I wish I had slowed down and thought about it.
Don't go into your design thinking (for example) "How do I implement my concept with a table view?" It's true that table views are natural for many informational and utility applications, but don't be constrained. Instead, think about what users will want to be able to do, how you can make it easier for them -- put things together that will be used together, etc. If you've never explored the concept of Use Cases, read up on them.
Don't hesitate to build composite views. Many of the questions I have seen here on Stack Overflow have to do with putting a toolbar at the top of a table, or having an image in the background of a text field. I understand the desire to do things the easy way, and as I state in #1 above, if there is an easy way, use it. But in many cases the solution is just to layer a couple of views with appropriate placement and transparency.
Think about what might be Apple-approved from the start.
App Rejected is one of several useful sites to help understand Apple's mostly undocumented standards. (One more.) (A previous question on app store rejection reasons.)
A few quick examples:
Using a UIWebView can get your app a 17+ rating.
Coding with an undocumented/private API = rejected
Version number < 1.0 might= rejected
Not enough feedback about network success/fail = rejected
Too much network use = rejected
Clearly limited free version vs full version = rejected
The word 'iPhone' in the app name = rejected
The above links contain many more examples, and more details about those examples.
Don't neglect the programming guides. While the documentation is quite extensive, the programming guides contains a veritable trove of useful tips and "insider" information that simply cannot be gleaned from reading method definitions. I spend just as much time reading the guides for a technology (say, Core Data) as I do actually implementing it.
Don't assume you know what a method does. If you have any degree of doubt about the functionality of a method, it is well worth your time to go look it up in the documentation to verify.
Wonderful examples from #Amagrammer above.
I would love to add that the first place to start is iPhone development is Photoshop. This is still the best advice I can give to anyone who is starting out. I now use OmniGraffle because it has awesome stencil templates.
What I find is that even for super simple app's, draw up your prototype and look for usability issues and work flow issues. It is 100x quicker to redraw your app than re-code it. I have fallen into this trap numerous times and now actually draw up some pretty simple functionality to see what it will look and feel like.
This advice will save you 10s maybe even 100s of hours in hopefully getting your app right first time and getting you to think through what the issues are. Throwing away code sucks and I have done it not because the code was bad but because it made the usability or solution worse. I think the best of us end up throwing code away and prototyping your design definitely will help in having to RTFM for something you did not have to build in the first place.
If you don't have an great designer, and can't do great design by yourself, then don't even start iPhone app development. This rule only applies if you want/need to make money with your apps.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What is your method of "mapping out" an idea before creating it?
Say I wanted to take on a big project, for example at the scale of a site like Facebook or MySpace. What planning/design steps should I take before I start the actual work?
For example, should I map everything out page by page (their functionalities, data, etc.)?
For a large project first think of a one-liner to description of your site (try to not use any buzzwords here). Next think of three design maxims (rules your design Should never conflict with). Then draw a few views and think up a few user cases (1 day) then work in code for 2 weeks (this will be a throw away prototype so just work as fast as you can forget about bugs and details, don't worry about code smells or design patterns, just make as much as you can), then revaluate all the steps above and throw away your two week prototype, and begin your project in a serious manner applying solid engineering and design. After a month has gone by evaluate your(team) moral and get feedback. If it all seems to be going ok, continue, you got a long ride ahead, otherwise just give up, do a postmortem, and start over with new goals.
I always start with the user interface design. I figure out what the user should be able to do and what controls I will give them to do it. Once I get that laid out in a way I like it, then I start with the code "wiring".
Make a list of all the features that site have.
Make a list of nice to have features.
Make a list of the weakness of the site.
Order that list and prioritize the items that will be built first.
Identify what will be possible to do and what is not.
Meet with your customer and present these results.
Usually I do a mindmap of
problem I am trying to solve,
translated into exact requirements,
then mapping that to user workflows.
The cross linking features of mindmapping softwares make it lot easy. Since mindmapping is 'kind of freeform', I end up concentrating on the 'task' rather than 'representation' (e.g which type of UML diagram should I use to represent this) ?
Once initial ideas are clear then I can work on project plan, spec/design documents using UML for more low level details. This approach usually works well for me.
To see if it works for you or not, you can use FreeMind (opensource mindmaping software, good but currently limited functionality). Then You can try Mindmanager or iMindmap for mindmaping. Both integrate well with other Office products.
Usually I start out by grabbing my scratchbook and just start writing down what I want as in terms of features, this should be quite detailed. And can be quite messy with every thing scrambled together, if so, when you're done make an 'official version' of you're ideas on paper (REAL pen and paper works best for this in my opinion).
Then I start making some scetches of how the pages would look like, what information it must contain and translate that to a global database design. Then work that global design to a more advanced level where all pages come together, with relations between tables and stuff.
After that I build up the most important pages on a code framework (I always make use of a framework, if you don't then forget the framework part), and by 'most important pages' I mean in for example a blog that would be the posts. After that build the not-so-important pages, in case of a blog that could be an archive of posts.
If you have that done, put the code together with a design, or do that while coding if you do not seperate code from HTML/CSS/JS.
Oh and yes, do NOT expand your first idea along the way. Just write that down and implement that afterwards. So if, in case of the blog again, you think half way you want Youtube tags in you're BB-code, write it down. Add that later, offcourse before you're initial site releases.
That's my workflow, at least a basic basic, basic description of it.
Start with "paper prototypes", i. e. take a pencil and sketch each page very roughly. This lets you start from the user perspective, which I think is a good idea.
You can then use the sketches for a first hallway usability test and later as the basis for "wireframes" you would give a web designer to work from.
If you've gone through the complete site once, you probably have a good idea of what the backend should be able to do. You can now use your page sketches and compile a list of the actions a user can trigger by clicking on things. This is the raw material for designing the server-side API that the frontend can call.
Using the calls that need to be served, you can design the backend: What functionalities group nicely, what data needs to be fetched, what do you need to store between page calls (== Session variables) etc.
In this process, I have fared quite well by postponing technology decisions (frameworks, protocols etc.) and even class structure etc., until I've gone through the whole thing once in terms of "what things should do what to what other things" (I guess there's a better term).
I think I would start with an open-source SNS solution that comes close to what you need and then figure out how to add use-specific plug-ins, modules, and themes that achieve your purposes. There are a lot of em out there. Building from scratch is going to take a lot more effort and planning. Most SNS functionality is not worth re-inventing. Focus on what will make your site unique and build upward toward that.
I'm a fairly visual person when it comes to designing software so I sketch out dataflows, class hierarchies, UI and flow charts on whiteboards and paper first.
Butcher paper and colored pens can be particularly fun to use as it's 3 feet wide and comes in 100 foot rolls. When you've got a design that's satisfying or sufficiently complete, tear it off the roll and pin to the wall. Update as necessary.
That technique has worked for some large refactors as well as new projects.
You could start with something very simple and then add features a little at a time. You may reach a point where you want to start over, but the groundwork you did will be beneficial. Or you can try to do the whole thing at once, in which case you'll need the advice already given in the other replies.
One more idea: Specify those features you are not going to include, and other restrictions. These are called constraints, and are as important as the rest of the plan, as it gives you boundaries so you know when you're done planning!
If you work for the same company as this person, start by getting everything in writing so you aren't the one to take the fall when the inevitable happens...
(See end for summary of updated question.)
I want to convey to groups of people (kids or adults) how a computer program written in a high-level language works, and what the relationship is of that program to the computer as a consumer device as they know it (a TV-like box that "does" typing and "internet").
I want to do it without computers. Not because I don't have them, but because I want a fun, physical activity that involves people the way acting, dance, music, sports, and capture-the-flag are fun.
I have read Teaching beginner programming, without computers here on stackoverflow; its reference to Computer Science Unplugged comes closest, but most of the activities there are either too complex, require too many props, or focus on specific computer science concepts.
I have also read Games that teach Programming Fundamentals but almost nothing matched my description in my first paragraph above.
And just for good measure, I have read Should functional programming be taught before imperative programming? so I am open to activities to teach either of those.
Keep in mind these requirements, some of which are subjective:
physical
no props (or very few)
fun
involves as many of the senses as possible
simulates the experience of writing a program and running it on a computer
no computers anywhere in the picture
is a game (competitive or cooperative)
It occurs to me that one source of material might be those team-building games that companies send you on. But those are designed for team-building, not teaching what writing and running a computer program is. But maybe you get the idea. Another way of looking at this question is to suggest what search terms I should use to find more answers -- though I usually can pick good search terms, an implicit "or" of "computers" and "games" will not find what I want because that combination is reserved for something totally different.
Update:
Thanks for responses so far!
I have now clarified that I'm interested in simulating the operation of a high-level-language program rather than either how the machine operates (1's and 0's) or specific concepts
With that clarification, you will be able to say specifically whether your game suggestion or game found teaches about functional or about imperative programming
With that clarification, please also respond to the part about games to teach the relationship of a computer program to the computer. What needs to be taught is that other consumer devices that physically look similar do not have "programs" -- why?
Your direct answers are much appreciated; if you can also find more ready-to-use sources beyond Computer Science Unplugged that will be great too
See my comments on answers so far, all of which are made in the spirit of thanks for what you've written, and not meant to be critical in any way.
Fundamentally, computers only do a few, very simple things:
They can do basic math,
They can move data from one place to another,
They can loop, and
They can make simple decisions.
The power of computers lies in the fact that they can do these simple things millions of times per second.
At the physical game level, I believe this is about all you can teach. Beyond that, I believe computer simulations and/or multimedia presentations are required (or, at the very least, a whiteboard).
1. Human Bubble Sort
Just test the Human Bubble Sort => ask a group of people - I'd recommend from min. 4 to max. infinite :-) - to sort themselves on the Bubble Sort principle, based on the alphabetical order of their family name.
Example : https://www.youtube.com/watch?v=8QD-R_MfDsQ
Works for kids and grownups.
2. Human Frenzy Robot
With physical people, paper sheets, and arrows + symbols written on them, reproduce the principle of the Frenzy Robot in real life. Look for "lightbot" on Google - I cannot post more than two links yet. I've just created my account to answer here :-)
3. Primo
For very young kids (after 4 years old), I really like Primo, a programmable small toy you put in motion on a grid => http://www.primotoys.com/
You could demonstrate thread locking by having two teams competing to get two halves of a key that opens the door to some reward (sweets for kids etc.). Each team grabs half the key each and then neither can open the door. If they cooperate then they both get the reward.
This might be a bit advanced - not sure now having re-read it.
It really was fun in CS Class: The Living Turing Machine.
You need:
Some place to place the formal rules of the machine, in the beginning it's pure chaos :-D
Humans:
a. A bunch of people that stand in line and simulate the linear memory, you just need a way to distinguish between 'ones' and 'zeros'. We did this by standing in the foreground or in the background, but I could also imagine other ways...
b. One person for every state of the machine
c. A 'reading head' which moves left or right on the memory.
Now you just need sample programs, start simply, for example with inverting a pattern. Then go on to more complex programs like increment/decrement.
For inspiration : an example of how physical people can materialize the Bubble Sort algorithm through dance => https://www.youtube.com/watch?v=lyZQPjUT5B4