perkinss / beachcomber Goto Github PK

We previously listed both GPS and location-services as required device capabilities. There are two models of the iPad, the 'wifi' model and the 'wifi + cellular' model. The wifi only model has only wifi-based location services, but no GPS. the 'wifi + cellular' model has wifi-based, cellular-based, and gps-based location services.

The question is: what level of location services do we require to use the app? If location services are turned off, do we still allow the user to take photos with no location annotation?

Images larger than the screen are not resized so that the full image is displayed on screen.

We should write a notification to the Notifications Area if the app is in the background when upload completes, and write it to the screen (as it does now) if the app is in the foreground.

Need to slide the view up until the keyboard gets dismissed, so the user can see what they are entering.

Users can put the app into the background and then go to settings and turn off the location services for Beachcomber. The app should check when the app comes to the foreground or when they click the camera button after coming back to foreground, whether gps is on, and if it's off should ask if it's ok to turn it on.

The photo detail view, which allows the user to choose a category and composition, is presented inside a UIScrollView. When the 'done' button from the category or composition picker is pressed, the scroll view rapidly scrolls downward for no apparent reason. This does not occur if the cancel button is pressed.

The service call gets a uid from the service (It's just a sequence)
Once a UID is obtained, it should be displayed for the user. The first idea is to just put it in a label with an explanation of what it is to be used for.
(It is supposed to be used in the public gallery so that users can see what they've uploaded to the system. E.G. "Filter on: Userid" They will also be able to filter on location, category, and composition... )

Once the service is deployed, you will be able to call http://dmas.uvic.ca/CoastBusterIDService to obtain a new id.

The way we thought it should work:

1. When saving a new photo, use the coastbusterID as the first part of the filename. If there is no coastbusterID yet, just leave it blank, so the first time a photo is taken, there won't be any id, and the filenames will be "_xxxxx.jpg" and "_xxxxx.txt"
2. When they go to upload to ftp, the device code first checks whether there is an id, and if there isn't one, it calls the service to get one.
3. The returned coastBusterID is saved on the device
4. The saved coastBusterID is displayed in a label in the main interface so that the user will see it and be able to use it in the web UI to filter uploaded images and see just what they've uploaded.
5. Then the files get renamed with "_xxxxxx.jpg" etc. and uploaded to the ftp directory.

If you have a better way to do it that might be more efficient, design could be changed...

In the upload view, if no images are selected and the upload button is pressed, the app crashes.

The user is presented with the option to upload current photos and respective metadata to the NEPTUNE FTP server.

When you take a picture, it immediately shows up in the edit table. But, if you then go to the upload table, it doesn't show up. It only shows up if you put the app to the background, give it time to write the file, and then bring it to the foreground again.

When taking a photo, and tapping the "Use" button, the interface seems to hang waiting a few seconds before it opens the PhotoDetailViewController

It's now CoastBuster...

I am not sure whether this is a good idea or not, but perhaps we should show that the app is consuming system resources when it's in the background and running an upload

Need to modify placement of view objects so that textfields are visible while editing.

When you take a few pictures so that there are about 10 or so in the list, and you select, say the last one in the list, then scroll up, you will see that another has been selected.

Then when you upload, the one that was selected gets uploaded; as well as some others, but not the one that wasn't selected.

We need to add a default string like "Select a category"

When an image is taken, GPS information needs to be recorded in the NSMutableDictionary data structure. This will be used in the data upload functionality.

After the user takes a photograph and clicks "Use", the save dialogue opens. Currently the only option is to save the photo. We need to add a cancel button that deletes the info from our photos collection and puts them back on the home page.

If you try to run it by deploying it adhoc, it will tell you it can't install it because the version is not compatible, even though the versions are compatible.

If running on the device using Xcode it builds without errors or warnings but then on launch pops a message that says:

Could not launch "Beachcomber.app"

No such file or directory (/Users/sperkins/Library/Developer/Xcode/DerivedData/Beachcomber-efmdfefkwxcraydbtkntnyaizsnz/Build/Products/Debug-iphoneos/Beachcomber.app/Beachcomber)

Consulting forums says that deleting the DerivedData directory, restarting Xcode, reattaching the device resolves the problem. It did not in our case. Another suggestion was to rename the project and then give the same name to the Bundle display name in the Info.plist. This did not help either.

Currently whenever a view controller is presented (i.e. by clicking any button that shows a new view), a new view controller object is allocated and initialized. This should be stored, and created lazily for efficiency.

All the saved entries disappear when the device is restarted.

default image orientation for a camera is landscape, with the camera button on the right. When a user takes a picture using the iPhone with the camera button on the right, the image is displayed in the expected orientation. If they take a picture with the home button at the bottom, the image is displayed with the "correct" default camera orientation: that is, it appears to have been rotated clockwise.
However, the iPhone default orientation is portrait. And, iPhone users expect the app to understand what's up and what's down when the picture is taken by the orientation of the phone, the way the Apple products do. We should probably change the image's orientation to match the user expectations for iPhone rather than matching expected default camera orientation

User must accept terms of use on first launch

On the android version, when the user clicks upload they are asked whether they would like to delete the photos after upload (I'll post the actual string in a minute), and if they click the Yes button in the Yes/No dialog the photos and metadata are deleted after upload.
We should add this functionality to the iPhone version

The time stamp that is submitted with the metadata for each image is currently in the user's time zone. This should be changed to UTC or some similar standardized time zone.

Get the app to work on iPhone 5 nicely, if it doesn't take too much effort.
Determine whether further development is needed (and how much) in order to get it to fit the larger screen
Also: Will the current app run ok in ios6?

THere's a setting in the info.plist that should make the app request permission.

One of the requirements for upload (and deletion) is to be able to select a number of entries and then click the upload or the delete button and have the action performed on all selected cells in the table.

Detail view currently shows full sized image. It should show a small thumbnail so that the input fields are more prominent.

Leaving iOS4 behind now, we can just have a single multi-selection list for editing the photo list and for selecting to upload

Currently the photo is shown full size, which means the user has to scroll to see the entire photo.

Images in the left side of both table views (PhotoTableViewController and PhotoSelectionViewController) are all different sizes. It would be tidier if we could make these the same size. Could be as simple as adjusting the thumb nails so they always have 1:1 proportion.

One of the requirements is to have access to help/instructions and information about the app and NeptuneCanada from the home page.

The contents that are supposed to be displayed are located in the internal wiki:

http://internal.neptunecanada.ca/display/DS/BeachComber+App+Help+Documentation

if category and composition are empty we should not allow save; prompt to choose something.