epreston / psarbortouch Goto Github PK

Complete a gap analysis to ensure that this library is a matches the feature set of the original library. The goal is to be equally applicable to the same problem domains when writing applications that target OSX and iOS.

Benefits:

The users of the original library should find this one very familiar. Ensure that this implementation is feature complete.

Category: Functionality

Milestone: Library Code Review

It was recommended in best practices to use post-fix under bar "_" for private member variables in classes. Most Apple framework code uses the prefix under bar. Many other code bases use the postfix under bar. Member variables are postfixed to make it clear when the member variable is being manipulated directly vs. via an accessor method of the same or similar name.

Benefits:

This will avoid the rare occurrence of a name clash and future proof the code. Make it clear when ivars are being used directly because accessors often have the same name with no prefix or suffix.

Category: Coding standards.

Milestone: Library Code Review

Many objects still include API's meant for testing and debugging. The API as a whole needs to be reviewed for conformance, consistency, and completeness.

Benefits:

Easy of use.

Category: Coding standards.

Milestone: Library Code Review

from picking through sample code in the Atlas example -

this json works fine. -
simple drop this into usofa.json and compile
{
"edges": {
"a": {
"b": {},
"c": {},
"d": {},
"e": {},
"f": {},
}
}

}

this goes haywire.

{
"edges": {
"a": {
"b": {},
"c": {},
"d": {},
"e": {},
"f": {},
"g": {},
"h": {},
"i": {},
"j": {},
"k": {},
"l": {},
"m": {},
"n": {},
"o": {},
"p": {},
"q": {},
"r": {},
"s": {},
"t": {},
"u": {},
"v": {},
"w": {},
"x": {},
"y": {},
"z": {},
}
}

}

The a basic NSCoding protocol implementation has been added for classes that will participate in serialisation. This implementation needs to be tested and refined to allow for quick and easy serialisation of state, simulation parameters, and graph data.

Benefits:

The system class abstracts the library user from the implementation details; extending it to support easy save and restore of graphs and system state will make this easier to use. Particularly on the iOS platform where users expect to view and manipulate the graph then quickly switch to another application, reliably saving and restoring state is essential. This will reduce the boiler-plate code required to use the library. Standardising the serialisation interface will allow for future extensions in this area without breaking existing code bases.

Category: Functionality

Milestone: Library Code Review

Complete the Atlas demo. The demo is fairly complete and has been used as a test bed for a new coordinate translation feature. (The ability to select between "stretched" or "scaled" conversion between view and simulation coordinate systems.) The demo currently loads the graph of US States (represented by nodes) and borders (represented by edges). Updating the interface to load other graph data is left as an "easy" exercise for the reader.

Outstanding items include;

• testing, commenting, cleanup
• updating and adopting the final rendering protocol implementation

Review the structure of the code for consistency and best practice. The code should have a logical and functional implementation with clear and intuitive methods.

Benefits:

Improve the quality of the implementation. The code will be easier to understand, maintain, modify, and extend.

Category: Quality

Milestone: Library Code Review

Hi Ed

Thanks for your brilliant work.

I want to use PSArborTouch in some projects and I want to have some predictions about the future of this project
last issue on this project belongs to 10 month ago. Will you continue development on this project?

The library currently uses a set of custom 2D Vector / Point math functions and data types defined in a header file.

Replacing these with those found in the math components of the GLKit framework will bring the benefits of consistency, ease of maintenance, possible performance improvements.

Create the "reference" wiki page to provide high level documentation on structure and usage. This will be a single, clear page of text with public objects, methods, and usage categorised by functional domain.

Review existing test rigs and remove unused / depricated code.

Complete the Echolalia demo. The project contains a graphical representation similar to the original demo. Most of the boiler-plate code has been borrowed from the Atlas demo.

Outstanding items include;

• loading the graph data for each song
• randomly advancing through the different graphs
• testing, commenting, cleanup
• implementing the graft / merge / prune interfaces in the system object
• updating and adopting the final rendering protocol implementation

Update the presentation and make the "test rigs" more consistent. This should include more debug options and ability to modify the key attributes of modules at runtime.

Once the API is finalised, review the "reference" wiki page to ensure it is in-step with the distribution.

Complete the Serialise Example. Demonstrate the system state and graph persistence features of the library.

This might be as simple as persisting the state and graph between launches of the application. For my purposes, the library needs to support a state "stack" either natively or by extension.

Another demo that will add value is a "Parameter Playground". This could be a cut of the debug code and interface that allows users to change simulation parameters to see their effect. In short, the simulation parameters change the behaviour and feel of the simulation. Finding the right set of values currently requires understanding the system and some trial and error.

Outstanding items include;

• create project template in demo folder
• graphical layout and design
• testing, commenting, cleanup
• updating and adopting the final rendering protocol implementation

This will be a demo similar to the original projects' website http://arborjs.org/ will be implemented as "Welcome". A subtitle of "a graph visualization library using GCD and Objective-C" might be appropriate. Links to documentation, source code, and further information will point to this github repository.

Outstanding items include;

• graphical layout and design
• testing, commenting, cleanup
• updating and adopting the final rendering protocol implementation

Complete the Halfviz demo. This project only includes a general template for the moment. This will be the most complex demo showing a number of interface elements and how they interact with the library.

Outstanding items include;

• general interface design to match the original demo
• loading the graph data for the table of contents, then each book as required
• menu code for selecting the graph data to display
• testing, commenting, cleanup
• implementing the graft / merge / prune interfaces in the system object
• updating and adopting the final rendering protocol implementation

I'd like to make use of this library, but I am having trouble compiling it for XCode4.5 and iOS6.0. I was able to change some boxing calls using the @ symbol to convert ints to NSNumber that wouldn't compile, but most of the demos and samples still have issues. The rigs all work and the Atlas demo mostly works, tho changing data sets isn't working for some reason. I think there is enough working that I can probably write some code my own, but just thought I'd see what version and platform this is targeted for and if you have any more experience than I do with making this run with the latest releases.

Structure and simplify the "test rigs".