iOS GeoReporter app issues

[Marius Constantinescu]

Hello,

I am Marius Constantinescu. I'm a 23 year old student from Romania, currently doing my master studies at the Technical University of Denmark. I've been a member of this group for some time, but I've seen the evolution of this project more from "the outside", without getting involved. Now I am really interested in applying for GSOC for this project (GeoReporter on iOS). 

My first question would be if there is a separate group for that topic (GSOC). There are several issues that I have discovered with the current app, and I wouldn't want to spam the wrong people with my questions :)

I installed GeoReporter (from the AppStore) on an iPhone, and I found several problems that made the app more or less unusable. I think most of them are connected to backwards compatibility, because I tested on an iPhone with iOS 5.1.1 (build 9B206). Also, I cloned the GitHub repo and tested on the iOS Simulator. On a 6.1 simulator it seemed to work fine (didn't get to play very much with the app, though), but on a 5.1 simulator I get almost all the crashes that happen on the physical device. 

Did anyone else experience those problems?

For now, one suggestion could be (until the backwards compatibility problem is fixed), to submit an update to the AppStore, specifying the minimum version of iOS to 6 (or 6.1 or a version on which it runs with no bugs), so that people with older versions of iOS can't install it. This could be a little drastic, but in my opinion it is better than having a buggy app on AppStore.

I have a little experience with iOS, I've played around a bit, and I would like to try to fix at least some of those issues I found. I think this could help me get accustomed to the GeoReporter code and (why not?) maybe get an ahead start for writing a good application for this project for GSOC. Do you think this is a good idea?

Also, in my opinion there are also some usability issues, and I would like to come up with some ideas to improve the user experience after getting a more complete overview of the whole system.

Is there anything I should know regarding this project before trying to fix some of the bugs on iOS 5.1 (for example, possible facts such as: somebody else is already taking care of that, or the bugs are fixed but the update is still pending approval on the AppStore)

Thank you,

Marius

[Cliff Ingham]

This is certainly the group to be discussing such things.  Post as much as you like here!

You are quite correct.  I made no effort to support backward compatibility in the 2.0 update for iOS 6.  I build and test on an old iPhone 3, but the OS on it is kept up to date, so I hadn't seen the crash problems.

Identifying and working on some of the issues is a great idea.  By digging into the code, you'll have a much better, more relevant proposal when it's time to send in the GSoC application.  Feel free to post issues on the Github project for the places where the app crashes or just general usability improvements.

A new update just hit the app store today fixing one crash bug that was reported when viewing a past report.

[Marius Constantinescu]

Hi,

I fixed the iOS 5 crashes I was talking about (after a clean install of the app, when I tried to change the current view, the app crashed). The updated code is in my fork of the repository, at https://github.com/mariusc/open311-mobile.

The problem was that the storyboard had the "Use Autolayout" checkbox selected, and this doesn't work in versions prior to iOS 6. There may be other problems when running on iOS 5, I haven't had the time to investigate them all, but this one is fixed.

In the meantime, I am trying to come up with a new prototype for the interface, which should not be very different than the current one, but should be a bit more easy to use and more intuitive for the user. Some of the issues I found in the current one are:

User experience issues

- we have buttons on the "Home" tab which change the tab (New Report, My Reports are both buttons on "Home" tab and tabbar items); I found this a bit confusing

- the "Settings" in the navigationBar in the Home tab and clicking on "Reporting as" go to the same view; this could be confusing. Also, to me, "Settings" doesn't suggest "Personal Information"

Bugs

- [with no server selected in the "Report To" tab]: if I perform the following sequence of steps: {1. click on "Report to" tab; 2. click on "My Reports" tab; 3. click on "New Report" tab; 4. click on "Home" tab}, it shows the "Home" tab view, but the selected tab in the tabbar is "Report To"

- [with no server selected in the "Report To" tab]: if I go to "Home" -> "Settings" and then press "Back", it returns me to the "Report To" tab, not to the "Home" tab, as I was expecting

- [only on iOS 5] after selecting the server (Bloomington, the one in the AvailableServers.example.plist), clicking on New Report causes the app to crash

Except the last one, all the others happen both in iOS 5 and iOS 6. 

I will try to fix the "New Report" crash on iOS 5 first. 

I'm also thinking of a new prototype for the interface. Regarding this, after I come up with the new prototype, should I: 

1. send it to you, Cliff, in a private e-mail? 

2. send it to this group, so we can all discuss it?

3. send it via google-melange as an official application? (the prototype will, most likely, be a part of my application for this project for GSoC)?

And I have some questions about the "features for development" in the ideas page for GSoC:

1. what do you mean by "Tablet form-factor interface"?

2. What is the status of "Audio capture and submission"? Has any work been done in this direction? Do you plan on using specific libraries for this? What format will we save the audio capture? How should we submit it? Are there any guidelines I should follow if I try to implement this?

3. by map-based browsing, you mean something like: a view with a map, on which there are pins for every non-emergency issue reported?

4. in the current version, is there a way for the user to see the evolution of the issue he reported? I think it would be nice for a user to see that his report has been viewed, then that a solution has been found to fix it, and then that the issue has been fixed. Does open311 api allow this possibility?

Thank you,

Marius

--
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.
 
 

[Cliff Ingham]

How much code complexity would be required to support iOS 5?

The Autolayout is only available for iOS 6, and I guess I should have restricted the build to 6.  Would we have to do away with the Storyboard completely in order to support iOS 5?  If so, is it worth it?

[Marius Constantinescu]

Hi Cliff,

I'm not that experienced so I can't say by heart how much code complexity would be required to support iOS 5, but I'm pretty sure it is not that complicated. Have a look over https://github.com/mariusc/open311-mobile. I fixed there the issues for iOS 5 compatibility. I tested on an iPhone 5.1 simulator and an iPhone 6.1 simulator, and it behaves and appears the same on both of them.
Apart from the Autolayout, there are some small differences in some methods in iOS 6. For example, [tableview dequeReusableCellWithIdentifier:kCellIdentifier forIndexPath:indexPath]in iOS 6 and [tableview dequeReusableCellWithIdentifier:kCellIdentifier] in all versions of iOS. For the purpose of this project, as it is now, there's no loss if we use the old method (the second one). The code in my fork of the repo (https://github.com/mariusc/open311-mobile) works on both versions of iOS. There may be other small backwards compatibility issues, but I haven't found them. However, I'm quite confident that it is not hard to have the app available and working on both iOS 5 and 6. 

Regarding the other questions in my previous mail, can you give me some hints? I'm rewriting them here:

[Cliff Ingham]

A new prototype for the interface would certainly be part of your application for GSoC.  We can discuss that over private email, if you like.

Tablet Interface
---------------------
Right now, the app is designed only for mobile phones.  Adding support for tablets would be nice.  However, that opens up a lot of discusssion about what the tablet interface would be.  Reporting a pothole by taking a picture might be difficult using the forward facing camera.  While table support would be nice, I think much thought needs to be put into a special interface for tablets.

Audio Capture
---------------------
We thought it would be nice for users to record audio of a problem.  It's still in the idea phase, though.  We're not sure what the interface should be, nor do we really know how it would be possible using the Open311 api.

Map-based browsing
---------------------
We want users to be able to see other reports of the same problem while they are reporting something.  So if they're reporting a pothole, we want to show all the other current reports of potholes in their current location.  

We don't really know how best to incorporate this into the interface, though.  Nor do we know if we can even do this using the Open311 api.   Open311 GET Service Requests doesn't include many parameters for filtering the service requests.

Issue status
---------------------
The Open311 api does not currently return any information about the status history of a report.  It is something that's being discussed for the next version of the specification, though.  It would be a nice feature to have, if we could get all the Open311 server developers to do it the same way.

[Marius Constantinescu]

Thank you for the answers, I will have them in mind when writing my application for GSoC. 

I have worked on some other issues (closing the keyboard when tapping outside a textfield or outside the cell of the table which contains the textfield). I have pushed my work on my fork of the repo at https://github.com/mariusc/open311-mobile. Should I send a pull request? Or should I keep working in my forked repo for now?

Thanks,

Marius

--

[Cliff Ingham]

Sure, go ahead and send a pull request. I'll merge the changes and try it out.

[Cliff Ingham]

I will merge the iOS 5 crash fixes directly from your repository.  But send me a pull request for the "Close Keyboard when outside click" feature.

[Marius Constantinescu]

Hi,

I've sent a pull request a couple of days ago, for closing the keyboard when tapping outside the textfields: https://github.com/City-of-Bloomington/open311-mobile/pull/122.

In the meantime, I found a problem in my code for iOS 5 compatibility, and I pushed a new commit which fixes it. The Autolayout in iOS 6 adjusted the height of the labels according to the size of the text in the label, so it would all be shown. My previous commit (the one that is on master at [1]) didn't take that into account (sorry for that, I didn't realize it then) and the labels had only one row, and the text was truncated.

In my pull request, the second commit (1a21c43) fixes that too, but not in a very nice way. I had just moved the position of the TextField or TextView below the label more towards the bottom, and increased the label's height in the storyboard. 

However, in the third commit in that pull request (4e0252c), this problem is fixed in a much nicer way. I compute programatically the expected height of the label, depending on the label's text, and then set the label's frame to match that expected height. I also move the UITextField or UITextView below the label towards the bottom with the same size with which the label's height was increased. This way, the label adjusts its size so all the text can be seen, and the TextView (or TextField) below moves so it doesn't overlap with the label.

Please have a look over my pull request [2] and if you think it's ok, include at least the changes for the label size, because they fix a bug my previous commit on the master branch at [1].

[1] - https://github.com/City-of-Bloomington/open311-mobile

[2] - https://github.com/City-of-Bloomington/open311-mobile/pull/122

Thank you,

Marius

[Cliff Ingham]

I'm beginning to suspect that backwards compatibility with iOS 5 may not be woth all the extra complexity required.  iOS 6 autolayout greatly simplifies dealing with all the UI stuff that needs to stretch and shrink.  And it's just a checkbox on the view in the storyboard.

In order to accomplish this iOS 5, we have to disable it in the storyboard, then write a bunch of layout code everywhere.  All that code is the whole reason Apple added autolayout to iOS 6.  

I wish I could find out somehow what the install base is for iOS 5 vs 6.  I think if iOS 5 is less than 20% now, I'd ben fine just saying the app is iOS 6 only.  There doesn't seem to be any barrier for folks to update to iOS 6, as far as I can tell.  I'm running iOS  on an iPhone 3.

[Marius Constantinescu]

Hello,

I made another push to my fork of the open311 repo, at https://github.com/mariusc/open311-mobile.

This one fixes the crash on iOS 5 when filing a new report. This happened because the call of 

[tableview dequeReusableCellWithIdentifier:kCellIdentifier forIndexPath:indexPath]

is not supported in versions prior to iOS 6 (the second parameter is the difference). So I replaced it with

[tableview dequeReusableCellWithIdentifier:kCellIdentifier]

in ChooseGroupController.m, ChooseServiceController.m and ReportController.m. The current version of the code in my fork of the repo works on both iOS 5 and iOS 6. I haven't seen any other crashes due to backwards compatibility, but if I see, I'll try to fix them.

I've noticed that now, there is no way to close the keyboard in the Personal Info, except for going back to the previous screen. Another issue regarding this is that if I tap on a field in the table (for example, "First name"), the keyboard appears. Then, if I press on "About" on the navigationBar, it goes to the About view. And if I go back, the keyboard is still shown. On the other hand, if I have the keyboard open in the Personal Info and press on the back button on the navigationBar, when I go again to Personal Info, the keyboard is hidden.

I think it would be nice to be able to close the keyboard by tapping outside the tableView in the Personal Info. What do you think? I'll try to do that these days (it shouldn't be complicated, I think I just have to call resignFirstResponder for the textField). 

Also, when you have the time, some comments on my previous e-mail (the long one :) ) would be welcome.

Thank you,

Marius

[Marcelo Mazzotti]

You can always use:

    [self.view endEditing:YES];

to ensure the keyboard is going to be closed, instead of calling resignFirstResponder in all UITextFields