Mathieu Tozer's Dev Blog

It's interesting the swing I've made from spending a heap of time on
UI, to wanting to always get back to the implementation side. It's
probably because before, UI design is all that I really knew how to
do! It's a bit of a mind flip to get back to thinking about UI, and
actually caring about UI.

I had a meeting with Jim Breen yesterday and he said he needed a sure
and fast specifications document, so I'm fleshing it out at the
moment. Mostly rewriting everything really, although I thought I
would be able to rehash the dated stuff. But I need screen shots
now... so off I go!

It's all happening! Here's the Monash project list for second semester, with my own one right in there, and here is the project news site.

My job is to teach the groupController to chuck word objects into the arrayController.

This involves teaching the SmartGroup and ManualGroup entities how to store or fetch certain words, so THEY can tell the groupController that 'I look at these word objects'.

Thank-you Justin! I think you may have solved my problem. Justin Anderson
http://www.tensaimac.com/

I'm getting a proxyObject which, while is keyValueCoding Compliant, will not allow me to use the full functionality of the object.
I need to grab the actual object with
[[controller selectedObjects] objectAtIndex:0]

Ok, so I'm probably adding words to manual groups now, and setting their relationship, it's just that I can't see them!

But from the way it's looking and working at the moment, I think I have finally built a structure that will work.
It's a bit finneky though, and I worry about scalability. But let's work for a proof of concept first.

[]On program launch, update the group view
[]Remove the update button, it is no longer needed.
[]set the first 'language' word to be 'welcome'
[]It is adding a new word each time I click update. Stop that.

My database class is going to help with my data modelling too, since it is teaching me sound database concepts that I'm just faffing through at the moment. It's really really boring, but so powerful and important for data storage. Somehow I've got to make data storage exciting... ;-/


Anyway, back on the bus, I think it's safe to say that NSArrayController doesn't have any delegates, so I should probably try to stop checking, and just get on with connecting things up with outlets.

Fri 28th July
Groups! Oh Groups!

I had been getting a bit emotional about the fact that I couldn't get groups to work. But somehow I've managed to get something like it working. Admittedly the groups don't manage any words yet, but I think I'm well on my way to having that work.
The view is updated each time the language changes to reflect the groups that are associated with that language. You can create and delete the different types of groups.
The next thing to do is to
[]Order the groups by type, with the special 'library' smartgroup at the top.
[]Remove groups o

Project Title: Words - Computer Aided Vocabulary Management for Language Learning.

Learning languages often involves a certain amount of raw vocabulary learning, and the student can often spend much time managing stacks of flash cards, lists of words 'to learn', creating these cards and lists, and looking up definitions for words in dictionaries. The end result is a system which is sluggish and boring for the student, and implementing techniques such as the Sebastian Leitner learning method difficult enough not to bother.
Words will aim to implement a systematic, but flexible, and importantly *usable* system for the user to manage a complete cycle of vocabulary learning for whichever language the student is studying. It will manage the process right from when the user encounters a new word, through its definition and learning (using various techniques, ie quizzing) and revision.

Well, not working, but it is something at least.

When I click the update button, the aggregation of the manual and smart lists go in the same table view. Now to actually get them managing word entities...

Here's today's thinking that led to this discovery....

What I might be mistakenly doing is creating a data entity for something that is actually a controller object. Am I storing something that in fact does not need to be stored? After all, it merely presents the aggregated values of two other entities, and this can be loaded when the program is run. The entity itself doesn't and shouldn't store anything to itself, it should only reflect what is stored elsewhere. Indeed, it is a controller object. So I shouldn't really have one in my data model at all.

TableView
NSObjectController GroupCoordinatorController
Enitity GroupCoordinator

I guess that is what I am making, a controller controller in a sense. So the cascading call is normal.

What a mess.

Had a walk at lunch time and decided this:

Anyway I've decided that the groups controller object need not be persisting anywhere at all. It's just an object to churn out an aggregated list of two different types of group objects so that a tableView can display them. It also keeps track of what is selected in the table view, and pops the selected group, whatever it is, into an ManagedObjectController object that is accessed by the word array controller for it's content set.

This is gold.

I actually did this yesterday, but it reflects what I'm doing:

(Sorry about all the blogging these past few days, I've just been rather active!)
New Project: Groups
I'm starting a new sub development app for Words called Groups in light of what I discussed in my last post.
This would also reduce the run / execute cycle too.

Data modelling. Here's what I propose.
Group is an object that an application can have many of, but a language can only have one group object associated with it.
A group object can have many ManualGroups associated to it, and many smart groups associated to it.
A language can have many words associated to it.
A ManualGroup maintains a list of words that are 'in it'
A SmartList maintains a fetch predicate of words that are 'in it'.

Group, ManualGroup and SmartGroup will be managed by NSManagedObject subclasses which will prove the functionality. The model simply shows who owns what.

Should also create the 'library' smart group programatically at first instance too.

When you 'add' a new group, whether it be a smart or manual, you have to set it's association to the currently selected language's group object.

All these entities will need to be managed with some controlling arrays. That's essentially what they are.

I have set up a groupObjectController in IB to hold whichever instance of Group is active.

I'm getting a bit lost.

Ok.

When you create a new language object, it needs to create a
1. Group object for itself
2. A library smartyPantsGroup object for itself too.
3. Any other default smart groups.
4. The word welcome as the language's new word.

So let's start from there. Subclassing Language to get a feel for what it needs to do, and cascading from there we'll need additional objects and methods which will force us to subclass the other entities in the model.

Heyheyhey! I just discovered a powerpoint in my makeshift Mac Lab with my toe as I stretched! Hooray.

I'm now wrestling with this idea of what the GroupController should be called, because I'm not sure exactly how it will function.
The groupController has to present to the UI a list of all the manual and smart groups that are associated with the Group object that it is controlling. It's an array, but it's probably not ...

When the user clicks addSmartGroup, the message is going to be sent to the groupController, which will
1. Create a new instance of the SmartGroupEntity.
2. Associate this newSmartGroup to itself (toManyRelationship).
3. Somehow show the user a representation of this newSmartGroup in the group list.
4. Set the wordArrayController to answer to the newSmartGroup.

Or am I using the entirely incorrect structre?
Should I, like the CoreRecipes example, make it so that
- Languages can have many group objects, which are managed by a regular NSArrayController
- But a group object can be either a smartgroup or a manualgroup. We don't care which.

Might I create a branch of my new groups project and do this.

Groups is now an abstract entity, whenever you go to create one of these, you actually create a smartList or a ...

damn. Now I just thought of another stucture!

What about if languages themselves can have many smart lists and manual lists, and then I have a subclassed NSArrayController that simply pushes these around?
--
I got three-thirty-itis around 3.30 and went home... I might have another crack at it later.

I would really like my groups and listing system working a bit better. I mean at all.
The wordsArrayController must answer to some as yet undefined 'groupArrayController' object that coordinates what is going to go in the main words array. What it displays depends on
1. Which language is selected
2. Which group is selected.

It needs to maintain an array of two different kinds of objects.
SmartGroup objects and ManualGroup objects. It presents to a tableview the smartGroup objects that are in the system at the moment. These entities are managed by Core Data. An application can have many ManualGroups and many SmartGroups, but only one groupArrayController. What set of groups go in the array controller depends on the currently selected language.

GroupArrayController
|S|M|S|S|M|M| | | | | <<<<<<<<<< LanguageArrayController
.
.
SmartGroup

Here's what it's likely to look and work like:

View GroupTableView
.
.
Control GroupArrayController (subclass to add arrays of smart and manual groups and aggregate them)
. .
. .
Model SmartGroups ManualGroups

Using the (reasonable) success of the Lookup sub project, maybe it's best to develop this system independently of Words and then import it? The controller will contain all of the custom code though.

modify the DictProtocolDictionary class so that handle Definition entities instead of instances of the custom Definition class.
The define method should return an array of these instead of the other types of objects.

MEMORY! Ugh. I was releasing autoreleased objects again. And you think you're doing the right thing! Yuck.

Anyway it's been a bit of a struggle so I haven't been taking notes today, but I've developed what you can see in the following screen shot.


What I think I need next is a 'isConnected' checker method that the system can ask about the network status from where ever.

I'm also going to have to program it to flatted the returned definitions down into a more readable format.
1. See what a variety of dictionaries return in the command line
2. Try removing the \n from the responses.
3. See what it looks like in a tableview

I might have to make a subclass of the tableView to enable more than one line to be visible in a cell. In this way the user will be able to read a few lines of text of the definition.

Also the next step is to start using words for English, French and Italian. I have to start learning some languages!

Here's what the French dictionary responds with:

today t…ôdei] aujourd'hui
English returns

exculpate v : pronounce not guilty of criminal charges; "The suspect was cleared of the murder charges" [syn: {acquit}, {assoil},
{clear}, {discharge}, {exonerate}] [ant: {convict}]

Exculpate \Ex*cul"pate\, v. t. [imp. & p. p. {Exculpated}, p.
pr. & vb. n.. {Exculpating} (?).] [L. ex out + culpatus, p.
p. of culpare to find fault with, to blame, culpa fault. See
{Culpable}.]
To clear from alleged fault or guilt; to prove to be
guiltless; to relieve of blame; to acquit.
[1913 Webster]

He exculpated himself from being the author of the
heroic epistle. --Mason.
[1913 Webster]

I exculpate him further for his writing against me.
--Milman.

Syn: To exonerate; absolve; clear; acquit; excuse; vindicate;
justify.
[1913 Webster]


It would be nice if the dict protocol was more XMLey and tagged metadata to the results returned. Parsing is going to be a bitch because all dictionaries seems to abide by their own format.
Ah. See this http://xdxf.revdanica.com/

This might be the next 'type' or 'protocol' of dictionary that I could support.

Maybe developing dictionary 'packs' are in order. A plugin architecture so that parsers for various specific (and popular) dictionaries can be added and then made to work with Words nicely.

-Reached a milestone for words by implementing lookup for words in dict protocol dictionaries.
-Learnt first hand the perils of incorrect memory management in Cocoa Objective-C.
-Identified limitations and features that need to be implemented beyond the basics that I have working.
-Realised yet again that I should be using the software day to day in order to determine which features are most crucial to the software.
-Found a project which is trying to bring XML to the dict protocol, something which would be desirable in words.
-Considered supporting the protocol in the future.
-Began thinking again about a more advanced grouping system for Words, and laying out an initial design, and conceiving of a proposed framework for the system.
-Started a new sub project separate from the Words project called “Groups” in which to implement the grouping system in isolation.
-Reached a 'kind of working' state for groups, where smart and manual groups were displayed in the same window.
-Jubilantly discovered a power outlet in the spot in building 75 where I'd been lurking for the past few days.
-Doubted myself for diverting from the sample code provided by Apple for implementing smart groups with Core data, as I felt it was convoluted and that there “must be a simpler way”. (It turned out after speaking with the Core Data engineers that this was perfectly fine).
-Wrote the project description for the subject web page, and the project is made officially my final year Project
-Made use of online mailing list forums to solve issues successfully.
-Gained confidence that the group framework I was building was one that will work, although I worried about scalability.
-The ugly emotional side of software development reared its head this week, and I steel myself against times in the future when things just don't work and loose confidence.
-Began Version 2 of Words specification document.
-Noted change from previous heavy UI design to 'under the hood' implementation, back to UI again for the specification document.