unicef-youth-section/locast-android

Android Locast client

locast-android's Issues

Cast Image doesn't show in Staff Sync View

There is a placeholder in the Staff Sync view for the cast image, but the associated image doesn't display. I would say that the placeholder could actually be removed in the sync screen.

Cast Add: Need to disable landscape mode

Currently, the New Cast screen will rotate into landcape mode if the phone is reoriented. This isn't a useful orientation for the Cast Add activity.

Force Close On Unsynced Casts Logout Cancel

If you open Unsynced Casts when not logged in and then cancel the log in, it takes you to the Unsynced Casts screen, but not logged in. If by chance they click 'Logout' in this state, it force closes. I'll log this for post-workshop fixing. It's an edge case now, though.

Switching External Libs to Git Submodules

One of our goals is to simplify the compilation of the client. Currently, there's 4 repos that need to be checked out and in sync to get a good compile, and that can be tedious. We've tried repackaging the libs as jars, but in Android jars with resources couse problems with finding the resources saved in the jars. It appears that using submodules in git could be a reasonable solution. Once the first milestone is met of delivering the basic workshop client, we'll investigate migrating the repos to submodules.

Testing AppUpdateChecker

Steve:

I'd like to test this today. Is there an easy way for me to upload the new JSON file and .apk (FTP?), or should I just send them to you for updates?

http://locast.mit.edu/m/unicef_gis.json

What version number should we assign to this release? It's currently got a version code of 26 and Version name of '2.1 UNICEF'. Thinking we bump it to 2.5 UNICEF.

When we deploy tonight and notify stakeholder via email, I'll just give the 'downloadUrl' from the JSON file.

Thoughts?

RB

Cast Add: Multiple Photos Still Captured although not displayed in Client

Taking a new photo in a cast after one has already been taken does not remove previous photo. It is simply added to the list of media (at least this is what appears to be happening in the DB). Depending on the situation, this could either be a bug or a feature :-) It still allows the user to take multiple photos that could then be removed if necessary from the Web UI.

Doesn't seem high priority to me, but in a future release, making it clear that new photos are additive to the Cast would be good.

Nitpick: Clean up compile warnings

Because I'm a bit anal-retentive, it annoys me that there are 50+ compile warnings. When time allows, go through and clean up warnings.

Itinerary/Map List Displays Empty Media Place Holders

The initial Itinerary/Map view displays an empty media place holder. I'm not currently sure what media would be chosen for the display (most recent cast? random?) Does the Itinerary/Map list need a media placeholder?

ItineraryList (Map List) shows useless info

Different phones show different numbers of casts in each map. This may be because the numbers are not updating when we create a new cast, and are just looking at the current state when installed.

The heart and cast count should be removed as they don't apply to this app.

Casts are being duplicated

New casts are being uploaded/duplicated. Fairly easy to reproduce simply by creating a new cast.

Portuguese Translation

Apply pt translations to strings.

OOM: CastEdit: crash after trying to replace photo

Steps to reproduce:

1. Start UNICEF GIS
2. click on a map
3. On CastEdit screen, add a photo
4. take photo, commit and return to CastEdit screen
5. press the photo button
6. take photo, commit

app crashes due to the following:

I/ActivityManager(  133): Starting activity: Intent { act=android.media.action.IMAGE_CAPTURE cmp=com.android.camera/.ServiceEntry (has extras) } from pid 10374
D/CastEdit(10374): updating content://edu.mit.mobile.android.locast.ver2.provider/itineraries/1/casts/86 with draft=true lon=-71.088163 title= lat=42.360825 modified=1326995304210
D/CastEdit(10374): cast URI iscontent://edu.mit.mobile.android.locast.ver2.provider/itineraries/1/casts/86
I/ActivityManager(  133): Displayed com.android.camera/.ServiceEntry: +531ms
E/QualcommCameraHardware(   73): rotaion = 90
E/HTCCamera( 6260): setSaveDone() - mActionScreen == null
D/CastEdit(10374): addMedia(content://edu.mit.mobile.android.locast.ver2.provider/itineraries/1/casts/86/media, local_uri=file:///sdcard/locast/1326995304170.jpg mimetype=image/jpeg title=1326995304170.jpg created=1326995312671 local_thumb=file:///sdcard/locast/1326995304170.jpg modified=1326995312671)
E/dalvikvm-heap(10374): 8957952-byte external allocation too large for this process.
E/dalvikvm(10374): Out of memory: Heap Size=6343KB, Allocated=3517KB, Bitmap Size=8907KB, Limit=20480KB
E/dalvikvm(10374): Trim info: Footprint=6343KB, Allowed Footprint=6343KB, Trimmed=604KB
E/GraphicsJNI(10374): VM won't let us allocate 8957952 bytes
E/AndroidRuntime(10374): FATAL EXCEPTION: main
E/AndroidRuntime(10374): java.lang.OutOfMemoryError: bitmap size exceeds VM budget(Heap Size=7879KB, Allocated=3513KB, Bitmap Size=8907KB)
E/AndroidRuntime(10374):    at android.graphics.BitmapFactory.nativeDecodeStream(Native Method)
E/AndroidRuntime(10374):    at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:694)
E/AndroidRuntime(10374):    at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:494)
E/AndroidRuntime(10374):    at android.graphics.drawable.Drawable.createFromResourceStream(Drawable.java:697)
E/AndroidRuntime(10374):    at android.graphics.drawable.Drawable.createFromStream(Drawable.java:657)
E/AndroidRuntime(10374):    at android.widget.ImageView.resolveUri(ImageView.java:584)
E/AndroidRuntime(10374):    at android.widget.ImageView.setImageURI(ImageView.java:305)
E/AndroidRuntime(10374):    at edu.mit.mobile.android.locast.ver2.casts.CastEdit.onActivityResult(CastEdit.java:461)
E/AndroidRuntime(10374):    at android.app.Activity.dispatchActivityResult(Activity.java:4108)
E/AndroidRuntime(10374):    at android.app.ActivityThread.deliverResults(ActivityThread.java:2914)
E/AndroidRuntime(10374):    at android.app.ActivityThread.handleSendResult(ActivityThread.java:2970)
E/AndroidRuntime(10374):    at android.app.ActivityThread.access$2000(ActivityThread.java:132)
E/AndroidRuntime(10374):    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1068)
E/AndroidRuntime(10374):    at android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime(10374):    at android.os.Looper.loop(Looper.java:150)
E/AndroidRuntime(10374):    at android.app.ActivityThread.main(ActivityThread.java:4277)
E/AndroidRuntime(10374):    at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime(10374):    at java.lang.reflect.Method.invoke(Method.java:507)
E/AndroidRuntime(10374):    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
E/AndroidRuntime(10374):    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
E/AndroidRuntime(10374):    at dalvik.system.NativeStart.main(Native Method)
W/ActivityManager(  133):   Force finishing activity edu.mit.mobile.android.locast.ver2/.casts.CastEdit
W/ActivityManager(  133): Activity pause timeout for HistoryRecord{40aaae08 edu.mit.mobile.android.locast.ver2/.casts.CastEdit}
I/ActivityManager(  133): Process edu.mit.mobile.android.locast.ver2 (pid 10374) has died.

I suspect this means that we'll need to use a resized to thumbnail size before putting it in the ImageView. The ImageCache module should be able to do that efficiently.

Device: HTC Wildfire S (mdpi device, not a ton of memory.)

Cast Create: Itinerary Not Saved with Cast

New Casts don't seem to be saved with the Map/Itinerary data. The Web UI show an empty 'Mapped On' field and the casts can only be viewed by the creating user. Viewing the list of casts for the itinerary does not display the new cast, so I assume the data is not being saved.

CastEdit: cannot interrupt location dialog

The location dialog should be interruptable so that a user can correct mistakes if they notice an error after pressing save

Sync Activity usability: casts disappear before media is sync'd

There's a usability bug with the way that sync happens now. Currently, cast metadata sync and media sync are handled separately. The idea behind the separation was to allow for the app to be more usable (browsing, etc.) while a big upload/download went on. I think this is still useful, but there is no coordination between the two states - media doesn't know when its cast is sync'd and vice versa.

Perhaps there could be a "media dirty" bit in the cast that gets set when the state of the media items are known to be inconsistent with the server.

Disable GPS Locating on Unsynced Cast Edit

When editing a cast that has not yet been synced, the GPS locator restarts and attempts to establish the current location. The original location should be kept and GPS should not be enabled on a cast whose status is unsynced.

Crash on Acquiring Location

When running on device, Location acquisition crashs Activity. It appears to happen after an indeterminate amount of time when the device can' establish the location (I was indoors). After moving to an open area and location was established, app did not crash.

01-13 08:29:50.912: E/AndroidRuntime(2259): Caused by: java.lang.NullPointerException
01-13 08:29:50.912: E/AndroidRuntime(2259): at edu.mit.mobile.android.locast.ver2.casts.CastEdit.setLocation(CastEdit.java:775)
01-13 08:29:50.912: E/AndroidRuntime(2259): at edu.mit.mobile.android.locast.ver2.casts.CastEdit.processIntents(CastEdit.java:190)
01-13 08:29:50.912: E/AndroidRuntime(2259): at edu.mit.mobile.android.locast.ver2.casts.CastEdit.onCreate(CastEdit.java:173)
01-13 08:29:50.912: E/AndroidRuntime(2259): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
01-13 08:29:50.912: E/AndroidRuntime(2259): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2627)

"please wait…" text should be updated

The "please wait…" text in the CastEdit activity that shows while locating gives advice that is against what workshop organizers think is a good idea. It should be updated based on the conversations with the organizers.

Cast Sync: View Context Option doesn't display cast

The long-press on a cast in the Staff Sync Screen displays a view/edit/delete context menu. The Cast View option presents a spinner that never dismisses and the cast information is never displayed. I would say that View could actually be removed for now and just allow Edit and Delete.

tag widget color

As can be seen in , the tag widget text is not readable. The tag theme needs to be updated to match the blue UNICEF theme.

crash when clicking "powered by locast" icon

Incomplete Casts Still Saved as Drafts

A new cast with no data is still saved as a draft. There is code at CastEdit.java:339 that checks the cast and should delete it if not complete, but it does not currently do anything.

Capture Media Date/Time Taken for Display in Web UI

It would be nice to capture the date/time of individual media. Possibility: is this stored in the EXIF info of the media?

NewCast: Thumbnail ImageView clears On device rotation

After taking a photo, if you rotate the device, the Thumbnail ImageView clears.

Cast Sync: Media is no longer uploaded with Cast Sync

Something appears to have happened in the last few days where the Cast Media is no longer uploaded with the cast. The file name appears to be saved to the DB (viewable in Django admin), but the media does not display in the web ui.

Map View Needs to Be Removed from Cast View

The empty map view is still being displayed as part of the cast view - cast_detail.xml

Sync Activity usability: need empty view

In the Sync activity, currently, if there are no casts pending upload, an empty list (no items or indication that there could be items) is shown. There should be a text notice so that people are reassured that the sync finished successfully.

App Saving Drafts?

The application is sometimes uploading casts to the website (or at least the admin portion) before fully localizing, while waiting for the process to finish. Will they be updated if the localization is eventually found?

CastEdit: gave up on finding location

The location discovery code gave up too quickly. I was standing outdoors without a GPS fix.I hit the photo add button, took a photo and returned to the CastEdit activity. The location finding had stopped (evidenced by the system GPS icon going away) even though the text in the cast edit activity claimed it was still finding it never added a location.

GPS Status after establishing location

This is more of a thought than a bug... I noticed that after the location is found, the GPS stays active and keeps updating. Two lines of thought here:

Keeping the GPS active allows the location calculation to improve until the cast is saved

however...

Keeping the GPS active is a significant battery drain.

Do we:

1. Leave as is?
2. shut down the GPS after we've established the lock?
3. Shut down the GPS after n seconds after the lock?

User should be warned that the report's name is missing before getting to save it

User is able to create and save a report without name

1 - Create a report
2 - When prompted to name it, tap on DONE

Expected: User is not able to continue until the report is named
Obtained: User is able to complete creation process but can't save the report.

Sync Issues

• Some complete casts are not uploading, even clicking synchronize on the admin app.
• One cast gave a “synchronization error,” but did not return to the previous list.
• At least one cast uploaded to the admin site with GPS markings, but no picture.
• Some casts are uploading unattached to a map, and thus not showing up on the website.
• I tried an offline test in an environment without GPS; I turned off wifi and took a picture. I saw that the cast (title and picture) were saved in the admin app, but when I turned on the wifi to synchronize, the cast was uploaded to the site without the picture.
• Different phones show different numbers of casts in each map. This may be because the numbers are not updating when we create a new cast, and are just looking at the current state when installed.

sometimes media doesn't upload properly

Upstream bug: mitmel#44

new location finder uses hard-coded provider names

The new location finder in CastEdit uses hard-coded LocationManager.GPS_PROVIDER and such. This will cause the app to crash on devices that don't have the given provider. Instead, the providers should be discovered using location criteria. If we want to ensure that there's GPS, we can do that by checking that it's there, but we shouldn't just assume it is.

Cast Sync Screen: Edit Cast Doesn't Display Image

The long-press on a cast in the Staff Sync Screen displays a view/edit/delete context menu. The Cast Edit doesn't display the image in the placeholder.

GPS Progress Dialog dismisses prematurely on device rotation

When creating a new cast, if the user presses save before a GPS location is set, a modal progress dialog displays to have them wait until GPS lock is achieved. If the device is rotated, the ProgressDialog is dismissed prematurely. From the partner:

If you turn the phone on its side during the “please wait while we add your current location” screen, you lose that message and return to a full-screen of editing the last text box you were in. It is unclear whether or not you are still being localized. And if you try to save the cast again, the application crashes after a bit.
I