Progress - faisalmemon/sprintoverflow GitHub Wiki

This page lists the progress of the project. We are at the experimenting/exploring phase so no firm road map is in place, only the overall vision "Making agile development predictable".

In-progress features

Automated screen traversal protocol to project

Now that we have a project screen, we want to be able to jump to this screen via an animation of travelling up to the root level. Also, at this point we need to have a communication to server stimulus so that we chat to the server to clear out nextPush items in a timely manner, as well as updating data table screens when the underlying model is updated.

Done items

Basic infrastructure

The basic infrastructure has been setup. This is the Google App Engine cloud service which provides a dummy initial epic/story/task model. The iOS client app has been created which merely polls the GAE instance (publicly accessible on the Internet) and creates a local data structure which mirrors the server. A JSON based protocol is used to get the data across.

SCM setup

Github hosting and arrangement of the code/metadata is in place so that eclipse (juno) with egit plug-in can pull down the server side code and run/edit/upstream as needed.

Handling network down

The code has a Core Data backup database "LocalModelCache" which stores network results. This is now read in either if the network is not available, or if a simulation flag is set. The idea is that we will have proper unit test cases to simulate various transient faults such as this.

Logo

An initial logo has been designed based off a picture of a Blueblue (also purchased the usage rights for it).

Human Interface Guidelines alignment

I have gone through the Apple HIG document to improve/fix the ui design. Made a fix to get the user up and running quickly by allowing the start screen to take you to pre-populated demo data. Multi-orientation support needs some thought as it may be useful to allow landscape mode to provide a better text entry mode for epics/stories/tasks.

Top level wireframes

The wireframes of the UI have been done. These are a top level sketch because it is a way to get a feel for how its going to fit together and the size of the job in hand.

Initial screens

The welcome screen, create and join screens have their UI and most of the logic. A transaction based system is in place to use server communication with a core data cache back-up for offline usage.

Server side security token storage and https transport

The client now notifies the server that a new project is being created, supplying a project id, project email address, and security token. Switching over to https worked without configuration changes (divergence from documentation that says you need to configure it in). The server now persists using Java Persistence API, and returns the created project.

To get perivalebluebell.com we'd need to setup some certificates. There does not seem any need to do this right now as the setup is working.

Business logic for new project creation

The goal of this feature is to properly document the business logic for a client creating a project, and the server responding in both good and bad scenarios. Then to implement this on both client and server. At the moment whenever a project request is made, it is persisted and then echoed back to the client.

This should form the basis of the other transaction stories as well. We support offline use, and this means merge conflicts will sometimes happen with the server. But its a design goal for the app for feel like a local app, never stalling for a server confirmation. It makes the program a lot more complex, but this is the subtle value add (responsiveness/flexibility) that should make the app stand out from the competition who would do it the simple but laggy way.

Update UI to provide project list

This was a tricky feature because projects can be searched for. This means having logic to persist queries from the client to the server until the server responds with either the project, or a discovery failure. Furthermore, this required addition of a discoverability flag so projects can be guarded by the security token. To do that, an addition to the create screen was done, to include a discoverability setting and a padlock icon to toggle this.

Finally, in order to match up search requests with the result, we had to put in a generation Id parameter. This is used to rationalise the nextPush by deleting entries that match the generation Id of an item in lastFetch. The server copies over the generation Id to indicate a request (nextPush item) has been dealt with.

Now we have the ability to create projects at the server, we can provide project screens which read this information.