Finalising the requirements for the Georeporter Android Client

[Rajul Bhatnagar]

Proposed Deliverables:

Required

• Android 2.2 and above supporting client.

• Navigation fixes/enhancements.

• A full featured Tablet optimized UI.

• Internationalization Support.

• Viewing of issues in a neat Map.
  
  
• Improved Network handling.
  

• General UI/UX improvements and bring it inline with Android UI guidelines.      

• Submitted issue tracking.

• Searching for issues based on keywords.

• Audio recording in submitted reports.
  
  
• Sharing of submitted issues onto social networking sites.

Optional/Good to have

• Client Side Caching of data for offline viewing using SQLite database.

• Advanced filtering options.

Any other suggestions/changes to finalize what the client should have.

[Cliff Ingham]

That's a good start.  The mapping and searching could take a while, though.  These are issues that are currently unsupported in the Open311 api.  If these look like they're going to take the entire summer, we should focus on things that can actually be accomplished in the short time span.

--
You received this message because you are subscribed to the Google Groups "open311-mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open311-mobil...@googlegroups.com.
To post to this group, send email to open311...@googlegroups.com.
Visit this group at http://groups.google.com/group/open311-mobile?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Rick Dietz]

Of those I think Keyword search and Social Network sharing are probably in the optional category.

I will be convening a group on the 19th (probably) to do some brainstorming on UI design.  I will keep you up to date on all of that.

-R

--
~~~~~~~~~~~~~~~~~~~~~~~~~
Rick Dietz, Director
Information & Technology Services Dept.
City of Bloomington, Indiana
812.349.3485 (office) 812.340.7958 (cell)
die...@bloomington.in.gov

[Rajul Bhatnagar]

For mapping I was thinking of using the lat long and address received from get service request to display all the open issues on a map. Similarly we can search for issues by client side processing of the get service request and also get service list returns keywords which can be used to filter results on the client.
I was able to get volley working with okhttp and GSON and I am in the process of porting all the XML parsing code to volley.Most of it can be used as it is.

Also would it be fine if I post some wireframes of my take on a new Holo Inspired UI for the App.

[Cliff Ingham]

As you are already working on code, I'm guessing you are working on your own fork on Github.

If that's true, then awesome.  If not, that's where we'd expect to see the changes.  Remember to commit frequently, so we can follow along.  That way we can head off any trouble early.  In addition, it's much easier to keep the merges up to date as the commits come in.

[Rajul Bhatnagar]

I was thinking that as I am doing extensive rewrite of the networking stack and also the UI and Navigation will also be rebuilt to support Tablets and more Holo compliant, of working on a separate repo on Github instead of working on a work. Package name will remain the same. Because Implementing these changes in a fork of the existing repo would be messy and more work so although I will be utilising some portion of the code I feel it will be better for me to work on a separate repo. What do you think??

[Cliff Ingham]

It is important to not abandon all the knowledge that has gone into the
existing code. This should not be started over from scratch. This
should be modifying the existing code.

For instance, what you are calling an "extensive rewrite of the
networking stack" is all contained in a single class file:
/models/Open311.java. Changing network library and using different
calls should only involve editing or rewriting that file. All the rest
of the code files represent knowledge about the problem that has been
learned over time.

Starting over from scratch means re-implementing all the bugs that have
already been fixed. This should be more of a refactoring than a
complete replacement.

On 06/05/2013 11:53 AM, Rajul Bhatnagar wrote:
> I was thinking that as I am doing extensive rewrite of the networking stack
> and also the UI and Navigation will also be rebuilt to support Tablets and
> more Holo compliant, of working on a separate repo on Github instead of
> working on a work. Package name will remain the same. Because Implementing
> these changes in a fork of the existing repo would be messy and more work
> so although I will be utilising some portion of the code I feel it will be
> better for me to work on a separate repo. What do you think??
>
> On Wednesday, 5 June 2013 19:01:52 UTC+5:30, Cliff Ingham wrote:
>>
>> As you are already working on code, I'm guessing you are working on your
>> own fork on Github.
>>
>> If that's true, then awesome. If not, that's where we'd expect to see the
>> changes. Remember to commit frequently, so we can follow along. That way
>> we can head off any trouble early. In addition, it's much easier to keep
>> the merges up to date as the commits come in.
>>
>>

>> On Wed, Jun 5, 2013 at 2:14 AM, Rajul Bhatnagar <rajulbha...@gmail.com<javascript:>

>>> wrote:
>>
>>> For mapping I was thinking of using the lat long and address received
>>> from get service request to display all the open issues on a map. Similarly
>>> we can search for issues by client side processing of the get service
>>> request and also get service list returns keywords which can be used to
>>> filter results on the client.
>>> I was able to get volley working with okhttp and GSON and I am in the
>>> process of porting all the XML parsing code to volley.Most of it can be
>>> used as it is.
>>>
>>> Also would it be fine if I post some wireframes of my take on a new Holo
>>> Inspired UI for the App.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "open311-mobile" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an

>>> email to open311-mobil...@googlegroups.com <javascript:>.
>>> To post to this group, send email to open311...@googlegroups.com<javascript:>
>>> .

[Rajul Bhatnagar]

Yes I am keeping all that in mind and am using a lot of stuff from that but using volley along with okhttp makes a lot of the hacks redundant.

For instance currently the apache http client is used and there are hacks to get https working and stuff. The okhttp stack automatically falls back to a apache http based client on pre ICS version and a httpurl connection based cleint on ics and above.The also handle SSL certificate validation out of the box. The new repo will be based on the current repo(Package name class names etc ) so it will be mostly like refactoring but from a clean codebase. I'll set up the repo by tomorrow. You have a look and tell me what you think.If you think its fine I'll go ahead with it.

To unsubscribe from this group and stop receiving emails from it, send an email to open311-mobil...@googlegroups.com.
To post to this group, send email to open311...@googlegroups.com.

Visit this group at http://groups.google.com/group/open311-mobile?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
Rajul Bhatnagar
Btech Computer Science & Engineering
VIT University Vellore

[Cliff Ingham]

I agree that Volly is much better and that we should replace the http
hacks that are written. But you're deleting the entire source code and
starting over from scratch when this can all be done by editing a single
file.

In addition, it is very important for the project to be able to track
what's being worked on, and why. Using git and Github provides us with
all of that collaboration capability, but you have to use it.

By forking and working from the existing code, we get the ability to use
the issue tracker, pull requests, code commentary, milestones, and
general project tracking. Starting a separate project means we get none
of that. The new code would not be as trustworthy, and probably would
not be adopted.

[Rajul Bhatnagar]

Ok fine. I'll set up the fork with my changes tomorrow.

--
You received this message because you are subscribed to the Google Groups "open311-mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open311-mobil...@googlegroups.com.
To post to this group, send email to open311...@googlegroups.com.
Visit this group at http://groups.google.com/group/open311-mobile?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Rajul Bhatnagar]

This is the link to my fork.

[Rajul Bhatnagar]

I wanted to ask if there is any particular reason to using static data members in open311 class.

[Cliff Ingham]

My reasoning for the static data members was that I wanted to persist the data across all activities that made calls to the Open311.  I didn't want to have to query the server again.  However, I could be convinced to do the persistence a different way, if it would make more sense.

--

[Rajul Bhatnagar]

On android we can pass data between activities using bundle.This can be done in 2 ways in our case of objects.

1>Using Parcable objects.

2>Serializing the GSON objects to and from strings and passing the primitive strings(Gson serializing and deserializing is quite flast)

3> Use the application instance to store the data.This seems like a good solution.

Static members work but are not elegant.

Persistence to disk will just be too slow.