Bug #423

Feature #117: Support multiple model configs with separate channelconfigs

Channel Description+Number range issue

Added by Hans Cappelle over 5 years ago. Updated about 5 years ago.

Status:ClosedStart date:05/03/2012
Priority:LowDue date:
Assignee:Android Dashboard Developers% Done:

100%

Category:-Estimated time:1.00 hour
Target version:2.0 Multiple modelsSpent time:-

Description

The number in the default description of a channel will fail if for instance description 1 and description 2 exist and then description 1 is deleted. In that case next channel creation will use description 2 being a duplicate description. This is because it's based on the size of the channels collection of a model.


Related issues

Related to Bug #466: Model name + Number range issue Closed 06/08/2012

History

#1 Updated by Espen Solbu over 5 years ago

  • Assignee set to Android Dashboard Developers
  • Target version set to 2.0 Multiple models

Need to be refactored so that it checks for existing name

Pseudocode:

i= numberOfChannels;
while(channelNameAlreadyExistsInThisModel("Description "+i))
{
  i++;
}

#2 Updated by Espen Solbu about 5 years ago

  • Parent task set to #117

#3 Updated by Hans Cappelle about 5 years ago

Espen Solbu wrote:

Need to be refactored so that it checks for existing name

Pseudocode:
[...]

Espen

It would be cleaner to have an autoincrement field in the database. That way you only need to insert a new item to database and read back the id field. Then you'll always end up with unique identifiers.

Kr

Hans

#4 Updated by Espen Solbu about 5 years ago

Would you do it the same if we limit db access to startup and shutdown? I guess you could still do the insert and then read back... just worried that we might spread out the db access code.
But yes, it is a cleaner solution. So we should aim for your way

#5 Updated by Hans Cappelle about 5 years ago

Espen Solbu wrote:

Would you do it the same if we limit db access to startup and shutdown? I guess you could still do the insert and then read back... just worried that we might spread out the db access code.
But yes, it is a cleaner solution. So we should aim for your way

I wouldn't limit to startup/shutdown only. Can be done but then this solution will indeed no longer work.

For the db limiting I was thinking more of having all the models loaded and on every update save them. My biggest concern was related to the way model is saved multiple times on creation etc. Should only be done once after the edit. I have a separate ticket for that now #465. I commited a revision for the Model objects so far. I'll have to look into the Channel objects also.

Besides limiting db access the most important goal for this change (for me) was to make sure we always work on the correct model with it's channels. To avoid the situation we had before adding multiple channels etc.

I did however not find a proper way of getting the next increment form db. I had to insert model and than update. I know for larger db systems like oracle we can get next sequence number. not sure if this is even possible for sqlite.

#6 Updated by Espen Solbu about 5 years ago

Ahh that makes more sense, and prevents loss of information in case of application crash. I was kinda concerned about that. Save to db on every update makes sense.

Regarding this issue,
I cant remember right now if the user can currently cancel without saving the model. If so: we either need to delete the model again (if we insert immediately), or user approach simialar to pseudo code. I think i would still prefer to insert upon going to that activity, then delete if user cancels..

#7 Updated by Hans Cappelle about 5 years ago

Espen Solbu wrote:

Ahh that makes more sense, and prevents loss of information in case of application crash. I was kinda concerned about that. Save to db on every update makes sense.

Regarding this issue,
I cant remember right now if the user can currently cancel without saving the model. If so: we either need to delete the model again (if we insert immediately), or user approach simialar to pseudo code. I think i would still prefer to insert upon going to that activity, then delete if user cancels..

AS IS the channel is created and saved (and even registered) from the moment the channel config activity starts with only model attached, no channel. So the case for new channel creation. For editing channels I'm not sure when save is done.

#8 Updated by Espen Solbu about 5 years ago

Hans Cappelle wrote:

AS IS the channel is created and saved (and even registered) from the moment the channel config activity starts with only model attached, no channel. So the case for new channel creation. For editing channels I'm not sure when save is done.

Hmm, i thought this was the case for Models (no save button on model anymore). But channel still have a save button, if user backs out, the channel is not saved (at least not visible to the user)

I had a desire to make save behavior (from user perspective) consistent across models, channels, alarms etc. but for some reason i did not follow through on that...
I am not sure what is best behavior,
  • provide a save button, cancel if it is not pushed (possibly with notification if "unsaved changes")
  • Do not provide a save button, save automatically, user will need to "back" then delete the channel or model

I like scenario 1 best, but behind the scenes, it would probably have to insert to db to get id's, at least for the model, then if cancelled, it would have to get dropped from db again...

#9 Updated by Hans Cappelle about 5 years ago

Espen Solbu wrote:

I am not sure what is best behavior,
  • provide a save button, cancel if it is not pushed (possibly with notification if "unsaved changes")
  • Do not provide a save button, save automatically, user will need to "back" then delete the channel or model

I like scenario 1 best, but behind the scenes, it would probably have to insert to db to get id's, at least for the model, then if cancelled, it would have to get dropped from db again...

Apart from the DB issue, to insert in order to get an ID, I believe we should go for the best user experience, rather than any technical requirement.

For me, generally speaking, CRUD actions are like this:

1) open a form
2a) if ID is given this is an edit so fields are prefilled with current data and 2 buttons are availabe: update and cancel.
2b) else if no data is given then this is a new item form so all fields are empty. Again 2 buttons but now this could be save or create and cancel.

In case 2b opening the form wouldn't create an element in db unless the user explicitly hits the save/insert/create button. For me this is the most logical solution, no safe unless the user asks for it.

With android there is also the back button. Not sure how to deal with that. Thinking of the options I can find:

1) exit and save
2) exit and ask user if we need to save
3) exit and discard changes

2 and 3 are probably not desired. 2 requires too much interaction from the user. If he pressed back he wants to exit, not to respond to questions. With 3 he might loose all the information he just entered. Unless we save it somewhere (in prefs for instance) but even then it's nog logical to notice our changes didn't go through and still have to restart the created new item activity to actually hit the save button there. So I would opt for the "exit and save option".

Still this is a change regarding the as is situation. I'll have to verify but I really thought the save was done right away on opening the activity without a channel ID. And what with the current behaviour for model then? Do we adapt according to logic for channels or vice versa?

Besides all this we had a form that prefilled the name which required an ID to get the order. Is it an option not to prefill the name?

#10 Updated by Espen Solbu about 5 years ago

Hans Cappelle wrote:

Espen Solbu wrote:

I am not sure what is best behavior,
  • provide a save button, cancel if it is not pushed (possibly with notification if "unsaved changes")
  • Do not provide a save button, save automatically, user will need to "back" then delete the channel or model

I like scenario 1 best, but behind the scenes, it would probably have to insert to db to get id's, at least for the model, then if cancelled, it would have to get dropped from db again...

Apart from the DB issue, to insert in order to get an ID, I believe we should go for the best user experience, rather than any technical requirement.

For me, generally speaking, CRUD actions are like this:

1) open a form
2a) if ID is given this is an edit so fields are prefilled with current data and 2 buttons are availabe: update and cancel.
2b) else if no data is given then this is a new item form so all fields are empty. Again 2 buttons but now this could be save or create and cancel.

In case 2b opening the form wouldn't create an element in db unless the user explicitly hits the save/insert/create button. For me this is the most logical solution, no safe unless the user asks for it.

In theory i agree. I am not sure this is the best way on Android though, see below.

With android there is also the back button. Not sure how to deal with that. Thinking of the options I can find:

1) exit and save
2) exit and ask user if we need to save
3) exit and discard changes

If we save on back, then no need for save/update/create button.
This is the behaviour when editing models as is.
The channels now have a save button. I prefill the name, but only on the object in memory. If you click back. This channel is discarded.

We should do it only one way for all our forms, so either channel form should be changed, or model form.

I think we need to investigate Android guidelines, as I have seen apps work either by saving on back, or by discarding on back. There is probably a preferred action in developer guidelines.
As i see it,
Option 1. We cancel on "back" (as is in channel), we provide save button. No cancel button.
Option 2. We save on "back" (as is in model), we provide no buttons, or at max a cancel button.
Option 3. We cancel on "back", however if form content is different from in memory. (e.g. User changed a value) we notify, asking if user wants to save

I prefer option 1 or 3.

Now that i think of it, this is why i had the parcellable in place in the beginning.
(Option 1 has difficulty with the following scenario:
  • Add model
  • Add Channel
    • Save (inside channel) - what should happen? we do not yet have a model id. Should we now also save the model? should we keep it all in memory with temporary id's, waiting for user to hit "save" on model page before the channels of this model with channels get saved?

Because of this, i added the parcellable interface. I even had it like this for awhile, where the the entire model/channel structure was purely in memory until the user hit "save" on the model form.)

Still this is a change regarding the as is situation. I'll have to verify but I really thought the save was done right away on opening the activity without a channel ID. And what with the current behaviour for model then? Do we adapt according to logic for channels or vice versa?

I am fairly sure that we don't save (updates or creates) when entering the channel form. I dont have the code in front of me now though.

Besides all this we had a form that prefilled the name which required an ID to get the order. Is it an option not to prefill the name?

We prefill the name, this was as mentioned in the ticket, based on the count, not the id. Prefill is just for convenience, and because i do not want it to be empty. The user is free to modify the name.

#11 Updated by Espen Solbu about 5 years ago

Made new ticket for the back button.. see #483

#12 Updated by Hans Cappelle about 5 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100
  • Estimated time set to 1.00

closed by rev #455. The channel id is not linked to one model though so numbers will increase over all models.

Also available in: Atom PDF