cocos2d
Source code form this lecture:
Capturing Screenshots
November 18, 2010 — DanThere are several different ways to capture iOS screenshots. Since you’ll need to do this for various upcoming final project deliverables, I thought I’d outline several techniques here.
Simulator with Window Decoration
If you want a screenshot with the simulator frame showing, then the easiest way is to utilize OS X’s built in screen capture utility. Simply press Command-Shift-4 (release) then hit the space bar. This will display a little camera icon where the cursor was and will highlight the currently selected window to capture. Once you’ve selected your window, simply click the mouse/trackpad to have OS X save it to your Desktop as a PNG (or press ESC to cancel).
Capture with Decorations
Simulator without Window Decoration
If you’re on the iPhone Simulator, the easiest way to take a screenshot of just the screen is to hold down Control and select “Copy Screen” from the “Edit” menu. This can also be accessed by pressing Command-Control-C.
Copy Simulator Screen
Then, the easiest way to create an image from the clipboard is to open the Preview app (can launch via spotlight) and select “New from Clipboard”.
Paste Simulator Screen
Then you can simply save the image as a PNG.
Directly from iOS Device
There are 2 easy ways to get screen captures from an iOS device — through Xcode or using iOS’s built in screen capture utility. I prefer using Xcode as it takes a lossless PNG images, whereas the device seems to capture lossy JPG images.
To capture using Xcode, plug in your device and bring up the Organizer by selecting “Organizer” from the “Window” menu.
Xcode Organizer
Once open, select your iOS device and then select the “Screenhots” tab. To capture a screenshot, simply press the “Capture” button and the most recent screenshot taken will be displayed in the right panel and all screenshots will appear in the left panel. Though not obvious, you can easily save any image on the left by simply dragging it out of Xcode’s Organizer into a Finder window.
Xcode Capture Screen
To capture using the iOS’s built in screen capture utility simply hold the home button and press the sleep/wake button. You should see an on-screen flash when a capture is taken. The screenshot will then appear in an album in your Photos app, which you can then email or sync off of the device.
Final Project — Progress Report & Code Submission
November 17, 2010 — DanDue Date
Slides and current project source code must be submitted electronically by: Wednesday, November 24th — 11:59pm
Background
With just under a month left before final projects are due, you will be submitting a progress report that describes in detail the overall flow of your application as well as your progress against the final project delivery. You will be expanding your oral presentation into a progress report that documents how the project implementation is progressing.
This progress report will be used for the following:
- As a last chance to make sure that the project is of sufficient scope and make course corrections (if needed)
- To communicate the overall flow and interaction between the various screens of the final app
- To establish a more detailed expectation as to what the final app will look like
- To try to nail down and identify all Apple and third party frameworks/APIs used by the app
- Identify progress against the final project delivery
Please note — the syllabus had originally called out the “Detailed project plan” and “Progress report” as two distinct deliverables. To save time and duplication of effort, both of these items will be condensed into this single progress report and source code submission. Since this progress report will contain the same content (albeit in one document) it will carry the combined weight of both assignments as originally detailed on the syllabus.
Slides
Your progress report should contain the following slides:
- Title slide — name of app & group members
- Overview slide — a couple of bullets that summarize what your app does (you should only need to update this slide if there are significant changes).
- Changes From Proposal — if you’ve dropped or added anything since your oral proposal detail those changes here (e.g. if you’re using different data sources, different APIs, dropping some features and adding others, etc.).
- Significant Completed Tasks — several bullet points mentioning significant accomplishments thus far (e.g. screens that you have started or completed, 3rd party data sources or libraries/frameworks/APIs that you’ve successfully integrated, etc.).
- Significant Incomplete Tasks — detail what large outstanding tasks you have yet to complete.
- Significant Issues — if you’ve hit any roadblocks, setbacks, or do not know how to get started with something, detail those issues here.
- Apple Frameworks Used — bullets detailing what Apple frameworks (or sample code) you’re using.
- 3rd Party Frameworks Used — if you’re using any 3rd party frameworks (e.g. Twitter, Facebook, Core Plot, etc.) call them out here.
- 3rd Party Data Sources — if you are consuming any 3rd party services (e.g. RSS feeds, web services, etc.) document them here.
- Anticipated Final App Flow — here you should document the various screens of your application and illustrate the flow between those screens in the form of a flowchart or state diagram. The boxes should represent the different screens and the arrows should indicate the actions that result in the transition between screens. This chart should include all anticipated final screens of the application.
- For each screen detailed on the flow chart slide, you should provide a slide containing the following elements
- Screenshot — an actual screen capture of that screen taken from either an iOS device or from within the simulator. This should be a screen shot and not a screen mockup — everything appearing in the capture should also appear on the device/simulator when running your submitted code. Note that it is fine if screens or portions thereof are not complete or just have place holders at this time.
- Completed Bullets — based on the screen shot, document what portions of the screen have actually been completed and what was implemented to back them (e.g. if you have a table view with data, explain that the data source has been implemented and where it’s getting its data from). If something is only partially completed (e.g. data in a table might be displayed, but it’s currently canned and not live data) document it as such.
- Incomplete Bullets — If you are missing screens or have not implemented portions of a screen, document what’s left to be completed and how it is going to get done.
- Self Evaluation of Progress — evaluate your progress against what you’ve documented as delivering by the end of the semester. If you feel you’re on schedule say so. If you feel you’re ahead or behind schedule try to specify specifics as to what you feel your ahead or behind on. If behind, please document how you’re going to catch-up.
Example
Below is an example progress report for the Stocks app that’s been used as an example for previous final project deliverables.
Progress Report
Source Code
You must also zip up and hand in your source code thus far. Your source code is not expected to be pretty, nicely formatted, well commented or even free of memory leaks/crashes at this stage. However, your source code should be build-able and run-able.
As a reminder, be sure to remove the build directory and ensure all necessary resources to bundle up the app have been copied into the project.
Submission
Like the previous final project deliverables, your slides must be submitted as a PDF document. Your source code should be zipped up and submitted as well.
If you are working with a partner, only one of you should submit the slides & source code.
Submit using the command:
submit cs491i progressreport slides.pdf project.zip
If authoring on your own machine, you’ll need to transfer the file into your GL account (via SCP) and then SSH into GL and issue the submit command.
Lecture 22 — Interfacing with Apple’s Apps
November 16, 2010 — Dan
Interfacing with Apple's Apps
Source code from this lecture:
Lecture 21 — Game Kit
November 11, 2010 — Dan
Upgrading to iOS 4.2
November 9, 2010 — DanWith an iOS 4.2 release seemingly eminent, I wanted to again remind everyone the ramifications of upgrading from a development standpoint. Generally if you want to do on-device development, then the iOS version on your device must not be newer than the iOS SDK installed. So, what does this mean?
- If you have your own Mac, then all this means is that if you update your device, you’ll likely need to update your iOS SDK.
- However, if you are doing on-device development and are relying on the lab machines to do so, you will not want to apply anything newer than 4.1, as doing so will likely result in the loss of the ability to publish to your device. The lab machines will use the 4.1 SDK for the remainder of the semester.
Lecture 20 — Connecting to the Net
November 9, 2010 — Dan
Connecting to the Net
Source code from this lecture:
- Zipcode.zip
- zipcode-server-side.zip (PHP server-side script & CSV data file)
- WebBrowser.zip
- Emailer.zip
- Dictionary.zip
- WebServer.zip
Rotation Gesture Example
November 9, 2010 — DanI’ve cleanup up and posted another gesture recognizer example that didn’t make the Advanced Events notes. This example utilizes the UIRotationGestureRecognizer class to observe rotations of an image.
UIRotationGestureRecognizer Example
You can grab the source code directly below:
