Closed joereddington closed 6 years ago
It's on. First step is to create a new interface. Which came unstuck a bit when the linker error appered. I've fixed it and committed.
Getting the first note to appear went in sweet as a nut, now trying the moving forward. Which also works. Nice.
So the next step is interesting. Do we put the logic for moving on to the next node:
Or some combination?
It might be the case that all worknodes know, in some sense, their next thing to do. But do we simply 'activate' a node (so activating a Do node calls a function that displays the 'next' thing. Hmmm.
Complicating this is that the dashboard we are using is, in some sense, actualyl simply the 'do' view.
I'm wondering if the answer isn't to have a singleton flowmodel, that is also in charge of keeping track of which is the current node. And pushing relevent displays when needed. But the problem with that is that if the flowmodel is pushing displays, then it locks it much closer to the interface... hmmm.
I've ended up at making the flow model basically all-powerful. We'll see how that works out. Now, how to make it a singleton?
Used http://www.galloway.me.uk/tutorials/singleton-classes/ to make a singleton. Seemed okay.
Committed the singleton, and I've added a question node that works with one small issue, I've also designed the picker node.
That's interesting. There isn't currently a pickerNode. I'll have to make one. And work out where I am from there. Picker nodes take a lot of work though....
Commied with the picker showing blanks. Now for food.
Back. Let's fix the picker.
Fixed and commited. There are some things I'm unhappy with -
Regardless, I now have a working iPhone version that I can make do things.
So what are the things I want to do? Because some of them need the phone as well...
Got the problem menu working (not for double level things, but we can come back to that.
The next logical one is expand, but that's going to need things working on the watch as well. Okay, what are the steps?
I had broke the watch version, I've now committed a fix. I've written the draft of the expansion code, let's see if it works.
If it works on the phone, I'll try on the watch, but that might require a bit reconfigure that I'm unsure if i'm in the mood for. Let's do it anyway.
Ah- more logic needed. Hang on.
I think I've fixed those... and I have! Committing (with a bit of code to change the colour of the button as well)
Now for the watch.
Either the watch is comparatively complex and strange, or I've simply been looking at the other one for too long. Hmm. Certainly the flow model means that more code lives in the relevent places, but it might be an illusion. I've put in a basic expansion and I'm testing it now.
Getting exactly as annoyed by the slow development cycle as I used to. This is rididulous.
While that's happening - theoretically the main watch class should be identical to the main phone class right?
I committed a version of the expand for watch, but it needed a stafty catch. I'm now made some changes to the workflow document, hopefully it will work shortly.
I've actually made a few changes to the workflow, but that's revealed a bug. Hang on.
Okay, my problem is that the code isn't coping with two questions consecutively. It's also failing to cope with starting with a 'non do' node.
These feel like the same problem.
I think I've fixed the problem I was having with the double question and with a following infinate loop. I'll go back to doing the next actions loop.
Okay, I've added the next actions choice, but I've found that it has the same problem as the problems - you need to be able to go back to a save node. I could use the existing node, but this really needs a stack... Let's have a google.
Putting in a stck really sorted out the problem of multiple problems, but NOT the next actions one, because the save was never run. We need to add that to the wider functionality. Hang on.
No, hang on more. What we need is a bit more functionality than that - saving isn't good enought here. Those threads have to go somewhere - it looks like we need an 'add to all' method. Which we shall have to have. (there's a possiblity of an infinate loop if two of the things are already going to the same place. (wait, no, theres a possibility of an infinate loop if one of these things turns out to be already connected in a horrible loop. Hmmm. Either of those area actually quite possible -we may find outselves reconfiguring the whole flow model.
Anyway, this has been a solid day of code, we've build a thing that I like, it's at least most of the way to what I want, and it will be cool. It's opened up enough that we can move forward with it.
NA "Write the 'jump' function"
Some obviosus next actions:
Refactoring: ought about Mrs L - let's make it properly separated - the phone app knows that there is a 'model' object and passes all the information to that. It knows what the interface is and passes simple messages back. Both the watch and the p
So what is the process here? is it that they both can access their own, and it comes from one or the other?
We could have it as starting in the phone and being sent over, or vice versa.
Or we could have a switch in the code which moves it from phone to code.
Or.... we could have another screen on the phone interface that is entirely independent of the dash (except that it looks a lot alike - with slightly different colours) and run it from there... That would work, what's the next action from there tho? When we have that, what do we do?
We either pass the worknode back and fouth (might be big by then), or we build a 'lazy' achitecture, where it only builds the tree when we reach the node (seems a lot of faff).
Oh - or we pass the stack accross - done-done-done-No-option-3, and the other makes it. That could work. We'd have puttons on the phone that said 'push stack' and 'pull stack'.
Okay, so what is the process here?