Mathieu Tozer's Dev Blog

Words is now network aware, however it is not exactly as I would like it.

See, it would be ideal for it to check the reach-ability of individual servers, rather than just any old server. And as it stands, if one server is unavailable, all servers are made unavailable.

This has to do with bridging the gap between the C and Objective C. I have only worked out a way to make the callback function

<>

Thank-you Shawn!

Network Awareness, It's a bit of a hack, because, one click of define will connect the networkObject, then you would have click again to actually do the definitions if you actually were online. The current implementation is such that it assumes you are offline to begin with, which is not what I want I suppose... the one click should show if you are online or not, then act accordingly. Tried the use of sleep but didn't work. Otherwise it's working pretty well I think.

Memory is probably leaking too. Might try to use the Leopard Developer tools to solve that one.

Yeah so it's a bit of a hack really. But it will work for now methinks.

USe http://www.cocoadev.com/index.pl?ApplicationLinkingIssues when looking at sparkle

Well the whole purpose of this is to get definitions from dictionaries, right?

So let's make Words look up words.

Again back to the UI drawing board.

Words should try to define themselves on awakeFromInsert
They should know when they have been defined (checkbox)

The application should be able to go through a list of words and define all the ones that haven't been defined yet, when the user indicates that it should be done (maybe via a menu system).

So I have to write awakeFromInsert{}

Maybe I need some kind of utility object that any object can just ask for definitions through. Like something awake from nib in the app delegate, and the object can be given to any other object via an accessor.

This way the words themselves and their controllers (like the thing that goes through a list) can use it to define words.

HEY! It worked first try. It's really nice when things JUST WORK!

It's funny though how you can get something working, but then not want to try it out TOO much for fear of breaking it. Well I'd better get over that, because for my app to survive in the real world I can't allow people to tiptoe around it all the time! So let's really try it out.

[] Connect only once per launch, reconnect as needed.

Ok we had some issues. They have to do with failing gracefully. The one noted above about connecting only once per launch, not every time the dictionary entity object is fetched is important.

Another important modification that needs to be made is with the UI of defining dictionaries.

It took a few minutes of beach ball time, but 171 words auto defined at once, right there, but what good is a definition if you can't read it in the table view?

[] eliminate duplicate words when importing.

But shit, look at that. 171 words and the sql lite database is already 1.4 megabytes. I hope core data is up to the challenge! Access time is still reasonable though.

Use sparkle to distribute from the start so that testers are kept up to date with the developments.

I've been looking at the Cocoa APIs which will let my application know about the availability of networks.

This is what I think it should look like


And for word input, there are a few things I need to implement

This part is also important too for the viewing of definitions


I'm dreaming of the time when I can seed testers with my app.

Along with sparkle, I would like to have a 'feature request' and 'comments / suggestions' menu item which emails them right through to me.

Also, when adding a smart group, I'm still getting all the English words in the Chinese words list, which might mean that when I am creating words in the services menu, I am not properly associating them to a language. Or it could be that the smart group is still fetching for all languages from the moc rather than for the currently selected language to which the smart group belongs.
So what's next?

And here's the notes that made it all come about:

I still have to think again about how the dictionaries can associate themselves to more than one language. Right now a to many relationship can not effectively be set because there is only one pivot language.

Maybe playing around with the software will be more effective in determining what will work.

I was thinking it would be nice if the dictionary always translated to your native language. What if I could get that from the system? But I decided that wouldn't be helpful anyway, because it's dangerous to assume that there are going to be always dictionaries available to translate to the user's native language.

Ideally, what kind of setup do I want? I should implement a design. The design should force the implementation, NEVER the other way around.

I've been dangerously creeping toward this so watch out!
------------------------------------------------------------------------------------------------
Checked dictionaries will be used in looking up definitions for JAPANESE
Here are the dictionaries that have Japanese capabilities.


------------------------------------------------------------------------------------------------

Obviously the UI won't be so verbose, but it's helpful in determining what the implementation needs to cough up stating it in this way.

Which means that the display shouldn't only show which

Another problem is that I've set things up to work for lookup in a unidirectional manner... but.... that's kind of what Words does. It's unidirectional. Think about it.

Users say they're learning "Japanese"
But it also means that they're going to want to translate words from English INTO Japanese. How will words support this?

Back to the UI drawing board.

What would be nice is if the program KNEW which language the word being input was.

Ok, so here's what I thought on the way home.

The language will only know to ask along that pipeline for definitions, for whatever it considers a word. Therefore it's left up to the dictionary itself to spit definitions of the word back, or not to.

So the dictionary manager should show the user a list of dictionaries that declare that they have the capabilities in EITHER direction for the currently selected language, and that I have been in error over the 'pivot' language idea.

So I have to modify the predicate to be in accordance with what I have decided here. It might be wise to modify the model to have a 'capabilities' attribute.

So the predicate will be more like:
(capabilities contains[c] 'languagename')

And then the user will be able to check the box to associate it with the currently selected language (ie, connect the pipeline).

yeah! I think I got it working alright.

See, I forgot about an old friend called [App delegate]

Which gives you the object that is pretty much available to everyone, including model objects, which use it all the time when asking for [[App delegate] managedObjectContext];

The next step is to set it up to actually do some word defining.

I'm trying to work out what the filter predicate for the
availableDictionaries arrayController should be.

It should fetch dictionary objects that have a pivot language that
matches the selection of the languageArrayController.

availableDictionaryController.filterPredicate =
languageArrayController.selection.name == Dictionary.pivotLanguage

(name contains[c] $value) or (pivotLanguage contains[c] $value) or
(targetLanguages contains[c] $value)

(name contains[c] $value)

Words: Have made some good progress in dictionary management today.
Still having some issues though. It's stable but I don't know how to
update the view each time a dictionary is added, and I can't get it
to show only those dictionaries that apply to a certain language.

Maybe I can put a clause in to say
if currentLanguage.name is null, then skip this part

I'm also going to have to make a design decision about whether a
dictionary can be used for more than one kind of language or not. As
it is at the moment, a dictionary can only be used by a single
language. But what if a dictionary looks up both Japanese and
English, both ways, and a user is a native Japanese speaker, but
wants to have JPL-JPL and ENG-JPL dictionaries. It doesn't make sense
to have two different ones, it would be best to use the same
dictionary for both 'languages'. So its a many to many relationship
then. The next task is then to, when the selection changes, the
dictionary view updates itself so that all the checkboxes reflect if
the current language is using them or not.

I've run into a bit of trouble with implementing this drag and drop interface for dictionaries, and I think it has to do with the limitations of bindings and core data.

But I just had a thought...

Wouldn't it be better to just have a checkbox to indicate which dictionaries are 'active' or not? This is probably better UI and it's certainly going to be easier to implement too!

But it has been good to fiddle around with this because I've learnt about how the drag and drop mechanism works, and how I can set it up with my other tableViews in the future.

Is setting a relationship the only way to go about it? Is it the best way? Why not have the system merely go though the whole list? There would be less processing and room for error if I set the relationship, and it also ties the dictionary object to a particular language, which is what I want.

The arrayController says, give me all dictionaries for THIS language. The model objects themselves know which language they are applicable to (by language name KVO) and they also know in their model if they are 'in use' or not.

Ok it's talken an afternoon but I think I can see this working.

In fact I got right down into the debugger MAKING SURE that what I thought was happening was actually happening. Asking it things like [[languageController selectedObjects] objectAtIndex:0] which help with seeing whether core data relationships are being set and removed as I want them to.

Going to go to the gym now for a bit of physical activity :-)

Then back to it!