unicef-youth-section / locast-android Goto Github PK
View Code? Open in Web Editor NEWThis project forked from mitmel/locast-android
Android Locast client
Home Page: http://locast.mit.edu/
License: GNU General Public License v2.0
This project forked from mitmel/locast-android
Android Locast client
Home Page: http://locast.mit.edu/
License: GNU General Public License v2.0
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.
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.
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.
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.
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
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.
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.
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?
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.
New casts are being uploaded/duplicated. Fairly easy to reproduce simply by creating a new cast.
Apply pt translations to strings.
Steps to reproduce:
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.)
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.
The location dialog should be interruptable so that a user can correct mistakes if they notice an error after pressing save
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.
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.
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)
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.
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.
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.
It would be nice to capture the date/time of individual media. Possibility: is this stored in the EXIF info of the media?
After taking a photo, if you rotate the device, the Thumbnail ImageView clears.
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.
The empty map view is still being displayed as part of the cast view - cast_detail.xml
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.
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?
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.
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:
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.
Upstream bug: mitmel#44
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.
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.